I would like to make sure at-rest encryption is done in one place and correctly. If there's shared storage, that seems like the right place rather than DAS.

Mainly I'd like to cover the case of drives being recovered without keys and the keys be required when the SAN boots (should be a rare event to not be a pain but also cover the case of someone stealing the whole kit and caboodle).

To attach to the SAN you need iSCSI (with credentials) or be on the FC switch.

This seems like it would cover database and NAS cases.

What's right or wrong with this?

  • First of all... fix your terminology. The SAN is the Storage Area Network. The Storage Subsystem sits on the SAN and is the thing with the RAID controllers and all your disk. Common mistake.
    – MikeyB
    Mar 26, 2011 at 4:33

3 Answers 3


Certain models of Storage Subsystems support full disk encryption, allowing your data to be encrypted while at rest on disks. The encryption keys are either stored on the subsystem controllers or an external central store.

The ones I'm familiar with are from IBM - the DS5000 / DS8000 series. The DS5000 controllers store individual security keys for each drive - one would need to remove the entire controller and drives in order to gain access to the data. Probably not something most companies should be worried about in a risk analysis.

Beyond that, the DS8000 architecture uses an external keyserver to store all the drive encryption keys. This model gives what you ask for - you can set it up to require a password to unlock the central master keystore, but storage subsystems / tape libraries that use it can authenticate and gain access to their encryption keys without intervention.

You can read more about the IBM technology here.


Physical security would be so much easier than encrypting the whole SAN, not to mention the performance hit from constant encryption (or hardware costs for something approaching transparency at SAN throughputs).

  • When implemented correctly, there will be no performance hit - Self-encrypting drives which have the encryption capabilities built in are available for a couple of years now. And mostly, you will see data-at-rest encryption implementations not where you have no physical security (because there would always be weak points without physical security) but in addition to it to cover a number of scenarios that have not been thought of.
    – the-wabbit
    Apr 27, 2011 at 23:21
  • 2
    @syneticon, I did mention that hardware is available that approaches transparent throughput, but it costs more (which is a point that shouldn't be dismissed give the potential benefits, or lack thereof). I'm having an extremely hard time imagining a scenario where encryption would be useful with physical security in place. EM eavesdropping? Really? So much easier to find some other security exploit; or social engineering; or a $5 wrench and kidnapped person who knows the password... See XKCD: Security
    – Chris S
    Apr 28, 2011 at 1:34
  • 1
    Physical or not - security is never perfect. Even if you have physical security in place, a drive might go astray one way or the other - maybe because an engineer has pulled it after it was marked "faulty" and did not look after it. It is good to have a safety net for this kind of threats which have been left unconsidered during the process of the threat modeling. And the typical SED drive will not impose considerable financial strains - a lot of enterprise drives already come with this feature "for free". Implementation costs may be impressive, though.
    – the-wabbit
    May 12, 2011 at 18:08

We've done some lab implementations of a Linux-based iSCSI target with LUKS/dm-crypt-encrypted disks with the capabilities you describe - when started, a key needed to be provided to unlock the encrypted slot.

Compared to the self-encrypting drive approach leveraged by several storage vendors (including LSI and IBM as pointed out by MikeyB) it has the advantage of encrypting data before it is sent to the controller, thus also covering possible electromagnetic emission eavesdropping scenarios. And it suffers the obvious disadvantage of being self-made and unsupported. Sun/Oracle Solaris-based storage would theoretically allow for a similar setup using Zfs encryption features - would be worth asking there whether this is a supported scenario.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.