Seagate 15K.2 Self-Encrypting Drives for Servers, NAS, and SAN Arrays - Page 11
Appendix B: Comparing Technologies for, Securing Data on Hard Drives
UPC - 715663213772
View all Seagate 15K.2 manuals
Add to My Manuals
Save this manual to your list of manuals |
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