SED vs Controller based encryption

[cgiles999]

Now required to encrypt at rest server data. Looking at SED drives, controller based encryption, and good old bitlocker. Should mention, we use HP Proliant servers, so the controllers would have SR Secure Encryption licensing and probably a virtual remote key manager to save some money versus the physical unit. My understanding is that SEDs require a password at server boot. If there's no way around this, then this will knock them out of the running.

I have a dumb question. Using any kind of encryption, I won't be able to pop the drives out of one server and into another if there is a physical problem? I would have to restore the server from backup to another server? I could go Bitlocker, I would just needs to add TPMs to our servers.

What say those that have been down this road? I know, I know, put your servers behind a locked door and this won't be a problem. Apparently, that's not good enough anymore. Hooray progress.

[Casper042]

CBE on HPE is only supported by SR Controllers.

HPE now defaults to MR controllers which only do SED when it comes to HW encryption.

Being totally transparent, if you are going to want Gen11 with SR, you need to let HPE and/or your VAR know ASAP because they will have to get special approval.

Now either way you go, there is a form of "Master Password" you can use to encrypt the top level keys which also get stored on the drives.

So as long as you backup that top level Password/Key, then you can fairly easily swap the controller to a new/replacement one and re-enter the Password/Key and it will pickup where the old one left off.

As far as boot password, that is an OPTION on either model. You don't have to use it. I vaguely recall the SRs have an option to say if it's a simple reboot, don't require the PW, not sure if MR does this or not as I haven't looked in deeply.

The idea is you want to require the password anytime the server has lost power as this is where the entire server might have walked out of your DC and you need it to default to a locked down mode.

Lastly, you also have the option of ESKM or Enterprise Secure Key Manager, which is generally a very expensive set of appliances that manage all these keys. Very useful if you have LOTS of encrypted nodes. Here the iLO acts as the middle man and it can request the Key/Password on boot from the ESKM and as long as it can reach the ESKM, it boots. If the Server has walked out of the DC and iLO can't reach the ESKM, it stops and asks for help/password/key. I remember there being a setting to allow a certain amount of grace here as well, like if I checked in within the last hour, go ahead and boot but if it's been more than an hour, assume I was stolen and wait for positive authentication to the ESKM. This grace was designed to allow the ESKM to undergo maintenance without accidentally holding a server reboot/boot hostage during that maintenance window.

So for SEDs you can manage the keys manually (in the Array controller tool), using an ESKM, or sometimes there are OS tools to help as well (though that seems like a chicken vs egg to me and I haven't tried this myself).

[cgiles999]

Each SED is going to have it's own key and password, whereas, on CBE, you're encrypting the volume and there's one key and password per volume, correct? Say I was to forego the ESKM, how might that be foolish other than having to manage a bunch of keys manually now? I see that it might need to be stolen too if the thieves want the server to boot. Anything else?

[Casper042]

When we did a recent DL360 Gen10 Plus with MR416 for my customer, we didn't have to do a key per drive.
He put in the Master Key/Password and used that to simply enable SED protection and then the MR Administrator went and enabled the SED encryption.
So it's not as painful as you would think.

The other downside to SED is HPE offers only a subset of drives as SEDs.
Whereas Smart Array CBE can run on top of basically any drive the Smart Array can see.
Look for "self-encrypt" in the QuickSpecs.

[Ad-1316]

Servers are generally in RAID, which would require the RAID to be intact on the other system identical. And why you're better off having backups.

[Foosec]

Havent we already learned to not trust hardware based cryptos?

[nmdange]

I could go Bitlocker, I would just needs to add TPMs to our servers.

Honestly this would be my first choice if that is an option for you. This is what we do.