Self-Encrypting Drives for
Servers, NAS and SAN Arrays
when needed to decrypt data in a virtualization
environment. More shared equipment increases
the number of entities that must share a given
key, and tracking more keys moving across the
fabric entails greater exposure, complexities and
performance issues.
Adapters with on-board encryption ASICs
entail interoperability challenges with multi-
vendor adapters that do not support on-board
encryption. Data encrypted by adapter-mounted
hardware can only be read by the compatible
hardware that uses the same encryption algorithm
and that can access the same key management
infrastructure. For example, in Figure 6 a blue
HBA (Host Bus Adapter) in the bottom server
cannot read data that’s encrypted on the target or
authenticate with the key manager or encryption
switch, because either it can’t access the key
manager or it has incompatible encryption
hardware.
Self-Encrypting Drives inherently provide
manageability because the encryption key never
leaves the drive. In addition, it’s easy to add
hard drives with different embedded encryption
engines to an existing array. Thus the data center
can have a wide variety of encryption engines in
the same array, because the encryption algorithm
is transparent to the system. As drive models
Appendix B: Comparing Technologies for
Securing Data on Hard Drives
There is no one comprehensive encryption
approach that covers all threats to data at rest.
There are cost, interoperability, performance and
latency issues to consider with each approach,
thus care must be taken when choosing where to
encrypt. Data encryption options come in many
forms, including:
•
Host-based software
•
Encryption hardware appliances
•
Encryption ASICs that reside on the adapter,
switch, RAID controller or hard drive
When evaluating how to protect and where to
encrypt data at rest on the SAN, NAS or the
server’s direct attached storage, the best solution
is to encrypt as close as possible to the storage—
ideally, the hard drive.
Key Management and Interoperability
Made Simple
SEDs greatly ease key management because
the encryption key never leaves the drive, thus
there’s no need to track or manage the encryption
key. In addition, the data center administrator
needn’t escrow the encryption key to maintain
data recoverability, because the drive itself keeps
encrypted copies of the encryption key in multiple
locations on the drive.
Only SEDs eliminate the need for encryption key
escrow, because if the drive loses all copies of
its encryption key, it is likely the drive has failed,
which makes its data unreadable in any event.
More encryption keys are automatically added
with data redundancy—each time the data is
mirrored onto another Self-Encrypting Drive, that
drive will have its own set of encrypted encryption
keys. By contrast, fabric and controller encryption
can present challenges in tracking, managing
and escrowing encryption keys to enable the end
points to read and write the data.
There are major challenges with hardware
encryption that occurs at the switch or on the
adapter. Separating the encryption from where the
data is stored increases the solution complexity,
increasing the chances for error. For example,
the correct key may not be readily available
11
Figure 6
