|
I'm putting together a server which will contain a few dozen TB of sensitive data and it will need to be encrypted when not in use. Can y'all help with some suggestions? Here's my constraints & current plans: - All the secrets (e.g. private key, passphrase) need to be portable; when the data is at rest and secure the key should not be on the server at all. Ideally it would never touch disk, double-ideally it would stay locked away on a separate local key server. - The encrypted data needs to be portable so it can be backed up to other locations. The other locations do not need to be able to decrypt the data, it would normally be restored to the main server in the case of a failure. - Currently planning on the disks being arranged in a JBOD-like LLVM or similar, since HA is not important enough to justify RAID 5/6 and the entire data set will be backed up regularly. - I'd like to do both full and delta backups, so the deltas would presumably have to be done on the decrypted data, whereas the full backup could be a file copy of the encrypted data for all I care. If it makes sense for them both to be based on the decrypted data then that's OK, so long as the backups are encrypted before they go over the wire to the backup location. If it's horrendously complicated to do strict deltas then an rsync of individually encrypted files would be OK. Worst-case full weekly backups would be OK from a data loss point of view but perhaps not so great for network performance and stress on the disks. - I'm open to choice of OS but likely would be some mainstream Linux unless there's a good reason to do otherwise. - Minimal impact to read/write speed. - The server will be bespoke so dedicated encryption hardware is an option if appropriate / available / not a fortune. - I'm willing to roll my own backup / restore / key management / encryption management software if necessary. (I'm not willing to roll my own crypto, so if we go that route I'd love to get recs on the current state of the art so I can hunt down some libraries.) I think that's about it. Please let me know if you need more info. Jaded Burnout fucked around with this message at 16:47 on Nov 13, 2017 |
#
?
Nov 13, 2017 16:44
|
|
|
|
| # ? Apr 29, 2024 10:12 |
|
|
If you want to save yourself a bunch of headache, BitLocker on windows server is very good. AES-GCM (128 or 256, pick your poison) with AES-NI offload on CPU is going to be about as efficient as you can get without going to a dedicated crypto ASIC card and will work out of box with no fuss and will keep up with anything barring extremely fast flash arrays. Keys are stored in the TPM which will invalidate if there are signs of tampering (BIOS reflash, boot loader changes, firmware changes) and go in to recovery mode to force manual intervention. Or you can manually punch in the decryption key every boot if you don't trust TPMs and want to babysit the hell out of it. Encryption is at the volume level, so if you're running a local agent its going to see the data as decrypted and handle accordingly but if you're doing some kind of snapshotting of disk images or raw volume copy it will stay cipher text.
|
|
#
?
Nov 13, 2017 22:44
|
|
|
Avoiding headache is always high up on my list, but I'll be honest running a Windows server is about as far from that as I can imagine. It's been a very long time since I've admined one (2k3 Server, I believe) and it wouldn't be suitable for the services I need to run on it. But the general approach seems feasible.
|
|
#
?
Nov 13, 2017 22:56
|
|
|
I can't speak too much to what's available on the *nix side of things these days, but I'd put TPM and AES-GCM support on the requirements list. TPM management isn't too difficult, just make sure the hardware has it and re-initialize with a good password. Keep a backup of the volume encryption key in a secure location to recover from a complete chassis loss. Modern Xeons should be able to handle 10gbps+ of AES-GCM with minimal CPU overhead, you shouldn't have much of a problem on that end unless you're looking for some extreme speed. https://software.intel.com/en-us/articles/aes-gcm-encryption-performance-on-intel-xeon-e5-v3-processors
|
|
#
?
Nov 13, 2017 23:12
|
|
|
For *nix your p.much looking at LUKS as the BitLocker stand in.
|
|
#
?
Nov 14, 2017 00:21
|
|
|
Your post isn't totally clear, OP. Is the server going to be running all the time but you need the data to be encrypted (without the server having the key) when you're not accessing it? Or you just want it to be safe when the server is off? If the latter, full disk encryption will work, but if the former obviously it won't. Basically, what type of threat are you actually trying to protect against, and what type of access do you need to the data? If the server might be compromised, then it will be a problem if it ever has the key. Also, If you just do encryption/decryption on the computer you're accessing the data from, you don't need special software on the server at all.
|
|
#
?
Nov 14, 2017 04:24
|
|
|
mystes posted:Your post isn't totally clear, OP. Is the server going to be running all the time but you need the data to be encrypted (without the server having the key) when you're not accessing it? Or you just want it to be safe when the server is off? There's different levels of sensitivity at play which is probably why I wasn't too clear. 1. There's very active services (second-by-second) which don't require any protection beyond their own authentication systems, but there's no harm if they're encrypted. I guess we could call these "level 1". 2. There's frequently active services (couple of times an hour) which require simple protection such as being safe if the machine is stolen while off. Level 2? 3. There's infrequent services which make up the bulk of the data and need to be safe whenever they are not actively being written to or read from. Think 1Password's model of lock/unlock and autolock. Reads from this dataset are maybe a couple times a day, but written to regularly. These level 3 files could be staged at level 2 and batch written into level 3 if it makes life easier. All data needs to be backed up regularly, ideally using at least file-level deltas (since byte-level might be hard with encrypted data), and needs to maintain at least it's original level of encryption when at rest in the backup. It's OK if it's unencrypted when travelling over the local network to the backup device. You're right that full disk encryption would not be appropriate for the level 3 data, except if the "full disk" is a mounted volume which could be unmounted into safe state when not in use. The thing about the keys is tricky. For the level 3 stuff there needs to be two factors involved so access can be revoked remotely even if someone on site knows the passphrase or socially engineers it out of someone. When I've been talking about "key" in the OP I was talking in the GPG sense of a private key unlocked by a passphrase. I understand that disk encryption is usually done by generating a key from a passphrase and then using that passphrase to unlock the drive. That would be fine for level 2 stuff but for the level 3 data the "passphrase" would have to be treated as an ephemeral private key and locked remotely behind another passphrase in order to provide those two factors. I can handle that part if there's not a better way to do it. If someone has access to the running server AND access to the key AND access to the passphrase then, well, we tried our best. Oh, and to your point about encryption/decryption on the client devices, that's probably not feasible due to the varied and often proprietary nature of the software running on them, i.e. they're not all handy Window 10 machines, but maybe you know of something that would make it work. Even so these decryptions would need to be revokable without access to either the devices or the server. One or two of these files being compromised is not the end of the world, the disaster scenario is full untempered access to the data set. As an analogy think 10 credit cards leaked vs 100 million. Jaded Burnout fucked around with this message at 10:03 on Nov 14, 2017 |
|
#
?
Nov 14, 2017 09:58
|
|
|
Da Mott Man posted:For *nix your p.much looking at LUKS as the BitLocker stand in. To expand on this, you can do what amounts to remote key storage and automatic LUKS unlocking with Clevis and Tang. Keys are derived via the Tang server and some fancy math, and Clevis calls up whenever you want it to (boot time, for example). Edit: here's a slideshow about it from Devconf 2017 Sheep fucked around with this message at 00:52 on Dec 31, 2017 |
|
#
?
Dec 31, 2017 00:24
|
|
|
|
| # ? Apr 29, 2024 10:12 |
|
|
Sheep posted:To expand on this, you can do what amounts to remote key storage and automatic LUKS unlocking with Clevis and Tang. Keys are derived via the Tang server and some fancy math, and Clevis calls up whenever you want it to (boot time, for example). I shall investigate, thank you.
|
|
#
?
Dec 31, 2017 05:27
|
|