Seagate 15K.2 Self-Encrypting Drives for Servers, NAS, and SAN Arrays - Page 11

Appendix B: Comparing Technologies for, Securing Data on Hard Drives

Page 11 highlights

Self-Encrypting Drives for Servers, NAS and SAN Arrays 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. Figure 6 Key Management and Interoperability Made Simple when needed to decrypt data in a virtualization environment. More shared equipment increases SEDs greatly ease key management because the number of entities that must share a given the encryption key never leaves the drive, thus key, and tracking more keys moving across the there's no need to track or manage the encryption fabric entails greater exposure, complexities and key. In addition, the data center administrator performance issues. 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. Adapters with on-board encryption ASICs entail interoperability challenges with multivendor adapters that do not support on-board encryption. Data encrypted by adapter-mounted Only SEDs eliminate the need for encryption key hardware can only be read by the compatible escrow, because if the drive loses all copies of hardware that uses the same encryption algorithm its encryption key, it is likely the drive has failed, and that can access the same key management which makes its data unreadable in any event. infrastructure. For example, in Figure 6 a blue More encryption keys are automatically added HBA (Host Bus Adapter) in the bottom server with data redundancy-each time the data is cannot read data that's encrypted on the target or mirrored onto another Self-Encrypting Drive, that authenticate with the key manager or encryption drive will have its own set of encrypted encryption switch, because either it can't access the key keys. By contrast, fabric and controller encryption manager or it has incompatible encryption can present challenges in tracking, managing hardware. and escrowing encryption keys to enable the end points to read and write the data. Self-Encrypting Drives inherently provide manageability because the encryption key never There are major challenges with hardware leaves the drive. In addition, it's easy to add encryption that occurs at the switch or on the hard drives with different embedded encryption adapter. Separating the encryption from where the engines to an existing array. Thus the data center data is stored increases the solution complexity, can have a wide variety of encryption engines in increasing the chances for error. For example, the same array, because the encryption algorithm 11 the correct key may not be readily available is transparent to the system. As drive models

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

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