2010-02-19 11:34 AM
In the white paper (NetApp Lifetime Key Management Appliance with Brocade Encryption Solutions), at the end of page 7 - states that with dual power supplies and dual SCSI disks that if there were a single hardware failure, access would still be enabled to all encryption keys from the appliance. What exactly would happen if multiple hardware failures occur (i.e both drives, or both power supplies, etc.)? How would you access the data?
Solved! SEE THE SOLUTION
2010-02-19 11:58 AM
There is no hidden hardware in the box, thus no capacitors to keep the LKMa up and running if both power supplies failed, no 802.11n in case the network cable came unplugged, no micro SD card in case both the drives fail.... nothing like that.
The LKMa would be able to continue operation in the following conditions:
1. One power supply failed (assuming both power supplies are in use).
2. One drive failed.
3. One drive and one power supply failed (assuming both power supplies are in use).
It is further recommended that not less than two LKMa be clustered. By the nature of how the LKMa shares keys, and the encryption appliances being configured to multiple LKMa key sharing would continue.
I hope this makes sense.
2010-02-19 12:33 PM
Also as a follow on to the discussion, page 7 shows the following diagram:
The point being made in the whitepaper is that Key Sharing Groups allow granular movement of the keys from site to site via policy management. This reduces the risk not only of a hardware failure in one NetApp LKM Appliance but also the risk across an entiredata center or geography. This is followed by trustee relationships that can allow up to 16 LKM Aplliances to be linked and keep the encryption keys synchronized with their peers. Also, as page 8 of the same document discusses, the configdbs (configuration databases) are backed up between the linked appliances. Following best practice to have at least two LKM Appliances and keeping them in separate sites would alleviate the issue of a single appliance failing.
Also, remember that the Brocade Encryption Switch generates the encryption key then sends it to the NetApp LKM Appliance. It can also send to multiple LKM Appliances. Thus encrypting and decrypting data in your environment would not stop based on a Best Practice scenario since another LKM would be available to archive and answer requests from the Brocade Encryption Switch for keys.
2010-02-19 01:48 PM
I have yet another follow-up to your original question. As stated earlier, the NetApp Lifetime Key Management appliance (KM500) should be deployed in at least pairs and geographically dispersed for high availability of your data encryption keys. That should address your concerns around loss of a single KM500 or an entire site. Each KM500 also has the ability to manually export it's configuration and keys into cryptographically secure packages which can be stored externally in case all KM500s in your environment are lost. The exported keys are wrapped with AES-256 bit strength keys as to not lower the strength of your encryption keys if this method is chosen. While this is not recommended for normal operations, it is yet another option to have your data encryption keys stored securely. Access to the keys are further protected by requiring a 2 factor authentication scheme in order to restore the keys to a new, replacement, bare-metal KM500.
The manual export method is best used as a tertiary layer of availability. If your environment generates alot of keys over time in a consistent manner (for example, generation of a new encryption key for each tape written through your BES), the manual export method is not practical as you'll always be behind in your key backups. This is where the KM500 ability to automatically store keys and synchronize keys across multiple KM500s gives you the key availability you're looking for.
2010-02-23 11:21 AM
Thank you (all of you) for your explanations. They were very helpful towards understanding how this appliance functions. And if/when we seriously look at encryption on our NetApp filers, I will pursue having at least a high-available (2) configuration.