Encryption at rest – Worth the effort for vSphere HCI?

Encrypting data drives makes sense on a laptop. If you turn it off and it gets lost, a key has to be provided to decrypt the data on the drives to make it readable. But what about the disks of a HyperConverged Infrastructure or similar infrastructure that is never turned off?

Arguments for:

Data Security: Encryption at rest protects data stored on disks from unauthorized access. This is particularly important in environments where sensitive information is stored, ensuring that even if physical disks are compromised, the data remains inaccessible without the correct decryption keys.

Compliance: Many industries have regulations that require data to be encrypted at rest. Implementing encryption helps organizations comply with these regulations, avoiding potential legal issues and fines.

Protection Against Data Breaches: Encryption is a robust defense against data breaches. Even if attackers access the storage systems, encrypted data remains unreadable without the decryption keys.

Argument against:

Performance Overhead: Encryption can introduce performance overhead, potentially affecting data access, processing speed, and efficiency.

Complexity and Cost: Implementing encryption requires additional infrastructure and management, such as key management systems. This can increase complexity and costs.

Key Management Challenges: Proper key management is essential for encryption at rest. Mismanagement of encryption keys can lead to data being inaccessible, effectively locking out legitimate users.

Compatibility Issues: Some applications or systems may not be fully compatible with encryption technologies, potentially leading to integration challenges or requiring additional configuration.

Backup and Recovery Complexity: Encryption can complicate backup and recovery processes, as encrypted data must be decrypted before being restored. This can increase recovery times and complexity.

Raid level

If someone takes one drive from a Server platform the data on that drive seldom provides any value.

RAID 0: This level stripes data across multiple disks without redundancy. If you remove a disk from a RAID 0 array, you cannot restore the data because it is incomplete and distributed across all disks.

RAID 1: This level mirrors data across disks. If you remove one disk from a RAID 1 array, the data is intact on the other disk, and you can read it directly.

RAID 5: This level uses parity for redundancy. If you remove one disk, the array can still function, and data can be reconstructed using parity information. However, the removed disk alone does not contain complete data.

RAID 6: Similar to RAID 5 but with additional parity. Removing one disk still allows data recovery using parity, but the single disk won’t have complete readable data.

In other words, the RAID level on your infrastructure defines whether someone can remove a drive and steal the data on it. It is possible to read RAID-level drives without the original controller; it requires the right tools and knowledge of the RAID configuration. RAID 1 is the easiest to access, while RAID 0, 5, and 6 require more complex recovery efforts.

Conclusion

What are you protecting against?
Are you doing it from compliance?
Where are your servers running?
Who has access to the data center?

All are vital questions, whether you should encrypt or not. If you are running in a public datacenter where many people have access to the cabinets your hardware is running in, or if the hardware is in a private data center with limited access, the answer may differ. I do not say you should encrypt or not. What I suggest is that you create a risk profile and act on that. If the risk is low, maybe unencrypted is the correct answer. If it is high, perhaps encryption is the answer? Does your budget allow for performance loss? Can you purchase more hardware, etc?


Leave a Reply

Your email address will not be published. Required fields are marked *

Share on Social Media