Slashdot Mirror
Ask Slashdot: How Would You Implement Site-Wide File Encryption?
Recently-leaked CIA documents prove that encryption works, according to the Associated Press. But how should sys-admins implement site-wide file encryption? Very-long-time Slashdot reader Pig Hogger writes:
If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to insure that you have both maximum uptime (you can access your data if you need to reboot your servers), yet that the keys cannot be compromised... What are established practices to address this issue?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?
The choices include encrypting files (tar/gz/bz archives), directories, whole user directories, whole physical volumes, whole logical volumes, etc. One large enrypted volume means single point of failure: One key/password gives access to every file. More divisions means more keys/passwords, but less access if one is compromised. Therefore, server level encryption is appropriate if one person is responsible for the entire contents on the server(s).
227-3517
If you decide to implement server-level encryption across all your servers,
This is basically simple you can build a server that does all encryption in ram, meaning the OS is loaded once then the encryption key is used to have it decrypt the content for the outside.
To stop tempering you could setup such a server yourself and equip it with various sensors that detect presence of people or tempering, and if detected it could shut down not compromising the encryption key to forensics.
Firewire(because of its DMA) needs to be disabled and unkown devices need to trigger a shut down event and must otherwise be ignored
con:
However this type of server would still emit the key data as radio spectrum.
con2:
The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.
my iscsi-encryption approach
So I can only explain my private approach, I got a root server with big harddrives and those harddrives are exported via iscsi that iscsi-connection is tunneled through ssh.
I de-/encrypt & mount the drives only on my home server and sync the directories with rsync. The harddrives are double encrypted meaning I have two encryption devices and two dependend keys.
This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.
Meaning my root server never "knows" what data is backed up on it - its a "dumb" server
I would suggest a similar approach for the requesters situation, because it solves a first step, separating the encryption key from the encrypted data.
And a second step having two encryption keys making it more difficult to get all two if separated (which is contrary to my use case)
I would expand my approach there to have a "data" server, a level1 encryption server and a level2 encryption server.
level1 decryptes the first encryption layer and level2 does it with the data provided by level1
Usecase:
If only the data server is seized, shut down at least one of the intermediate servers along with its key and the data is inaccessible. And it doesn't matter which "key keeper" server you kill, its a fail-one-fail-all system.
The drawback is however the level2 encryption server shall not be compromised, because there all pure data is accessible.
encrypted backup
With todays highspeed connectivity the servers can be backed up by just cloning the harddrives over iscsi for example, that works quite well.
another idea
Most encryption providers from linux and bsd provide the possiblity of having more than one master key.
Iscsi can also work on image files so you can provide many independed iscsi-volumes and encrpytion can be outsourced to the users computers.
Because by encrypting everything, you A. prevent an attacker from knowing the layout and structure of the filesystem and B. prevent anybody from tampering with your binaries without knowing the password. For example, you don't have to worry a police agent alters /bin/ls or so behind your back, and nuking just the bootloader is much easier than trying to replace the entire unencrypted filesystem afterwards.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
But the chance of losing your data is triple.
I was about to say, "That's not how probability works!" but it turns out that you are actually correct.
If each site has a 1% chance of being seized, then it means each site has a 99% chance of not being seized. Multiplying these probabilities together gives .99^3 = .970299 or about a 97.03% chance that no site will be seized — which means that you've got about a 3% chance of having one or more site seized.
The key here is that 1 – (1 – x)^3 is very close to 3x for small x.
I wish that someone would develop a version of raid for use with servers. Have 3 VPSs in Switzerland, Russia and Holland and each one gets only a 3rd of each file. The chances of any government seizing all 3 is zero.
GlusterFS supports striping across volumes that can be hosted on different servers: https://gluster.readthedocs.io/en/latest/Quick-Start-Guide/Architecture/
Hire someone who knows what they are doing. Seriously, if this is for a business, there are lots of complex issues with compliance and audits in addition to availability and the possibility of sabotage. And this causes enough work that you'll probably need to hire someone anyway, so it might as well be someone who knows this stuff.
Dealing with those requires experience. And the very first thing you need to come to terms with is: what risks are you actually trying to protect against? What tradeoffs are you willing to make and what risks (mainly of data loss) are you willing to accept? How much are you willing to spend on this?
Sounds like Tahoe-LAFS.
"When information is power, privacy is freedom" - Jah-Wren Ryel