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?
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.
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
...and uhm, just how do you plan to sync between these in a realistically usable data valume? -also the question was specifically about "site-wide" not some across the legalities of the world data privacy strategy.
I assume no. Then WTF do you need site-wide encryption for? The majority of the content on your network is boring shit. I'd consider selective encryption for documents that matter, like HR data, contracts, C-level email (unless there are legal requirements for any of those categories to be in the clear).
The post here doesn't say very well what is wanted. Is the desire to have possibly a large number of servers, a huge number of files, and a huge number of users, so that every file is encrypted but every authorized user of every file can access the file? In other words is the idea to replace all access control with encryption? That is going to be hard. Or is the idea to possibly encrypt whole servers and somehow have all users able to access the servers, but the server is only encrypted once? Encrypted-hardware disks kinda do this, but have to have some way to get set up and they only protect data in the case of someone stealing a disk drive. The problem of allowing access is still hard.
I once implemented a partial system in which an init process that checked that it was running at boot time by the boot process would start keying everything else. Some of the new "secure boot path" tech is a similar approach. But this is not completely bullet-proof. Disassembly is hard to resist, whatever you do to a piece of code. Wasn't as common ~30 years ago.
A police function would probably want to take entire systems. That suggests that the keys to a disk-crypt system might want to be in someone's mind, possibly requiring several people to cooperate to each load part of the secret. Lotsa luck. Rubber-hose crypto, "duress" keys, decisions when to have the data get lost irrevocably, or how if at all you will have backups, all need to be thought about. The problem stated says nothing.
Let's start simple: what threat are you worried about?
The first thing I'd do is start with files. Then I would add data to said files. Then I would use cryptography to encrypt all of those files containing data. There you have it: 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
The solutions I have help implement are based upon using an internal CA with an HSM device for the master key storage. BUT, there are gotchas on any solution. You have to have a "master key" available for all devices. This can be multiple master keys for each type. You then need the skill and resources to manage the various keys (Certificates).
The other gotcha which is just as complex is there is no one overall solution which fits everything. Sure you can have solutions for each, MDM, Notebook/Desktop Servers, clouds and NAS. You will need skills within each group to manage, maintain, implement and support.
In the end it is a gordian knot of its own. Examples which use PKI for the encryption; Bitlocker, Thales, NetApp, Airwatch.
And don't forget Backup encryption options as well. That and removable devices are a prime source for loss.
- Linux servers
- LUKS full-disk encryption
- All network traffic tunneled tunneled through some form of SSL (e.g. SSH or OpenVPN) with client authentication, and a decent IDS.
- Tiny custom binary in the initramfs that loads the "password" (a random 1024 bit binary string) from a USB serial device
- BIOS boot options locked down (no removable media boot, password required to change settings)
- Arduino with 6x AA batteries for power backup, a 3-axis accelerometer/gyro, an ambient light sensor & the sensor from an optical mouse, riveted to the inside of the chassis' outer shell, with a small hole in the bottom of the case for the optical sensor.
- As long as the Arduino is undisturbed (i.e. registers no movement or sudden change in lighting level) it will provide the decryption key on request, so the server can boot up unattended.
- As soon as the Arduino registers a disturbance (e.g. somebody moves or opens the computer case to reset the BIOS) it wipes the key from RAM and for the next boot you need to fetch a non-volatile copy of the key from a safety deposit box.
You can seize the servers, but by doing so you effectively render the data inaccessible, and nobody's going to remember the random 1024-bit binary string you need to decrypt one of them.
But how should sys-admins implement site-wide file encryption?
I guess I would start with a search for "full disk encryption"
Or with raising the middle finger and telling to encrypt that.
Depends on the day.
"we are all atheists about most of the gods that societies have ever believed in. Some of us just go one god further."
Why would you want to encrypt the entire filesystem, there isn't anything of interest in /usr/bin or other standard system directories.
Encrypt /home , /var and wherever else you have sensitive data. the decryption key should be kept on a off-site server that hands your init.d script (or system.d whatever you are using) the key once it passes a IP address lookup and ssh authentication. If moved off site, the servers will not be able to receive the decryption key because the ip's won't match (you could simply drop connections from anywhere but your ip-block straight from iptables or do something more granular) or you could just shut off the authentication server alltogether
Where I work, all laptops are using BitLocker, with a policy being set by the IT group. Keys are managed by IT, just in case anything happens. Laptops have dedicated HW that make encryption not feel slower than without.
By the way, I am sure there is another better place to ask these questions.
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.
I really don't understand the question. It is very nonsensical.
Slashdot will hate me for saying this, but Microsoft does a really good job with this issue. Bitlocker, their (AES128 or 256) whole disk encryption system stores keys in the TPM chip and Active Directory. Bitlocker is used on servers and workstations alike. It is very nearly seamless for users during daily use, but once the machine is off the network, there's no getting in without the correct password and PIN or 48 character decryption key.
The decryption key is stored in Active directory, by I also maintain a printed list in a secure location, along with important passwords.
On the Linux side, there's no easy way to accomplish the same functionality, at this time. If you use whole disk encryption on these systems you have to maintain a list of passwords or/and keys and manually enter them at boot, unless you leave the USB key plugged in at all times, which kind of defeats the purpose of encryption.
Was wondering if there is a site or blog that has tried to respond or negate each of the findings of the CIA dump?
Its biggest issue is to my knowledge it omly works with windows, but for making life had for leakers this is probably the best bet. When you open documents your computer requests the key for ad, the benefit here is if the user cant connect to AD (i.e. They are at home) the whole process wont work. You can also define users who can decrypt data before emailing if they do meed to share the info. It works well as long as you are tied to the windows ecosystem.
It looks like we know where Marines United is going to be hosted next. :)
This has been bubbling to the surface for years and it really comes down to central key and certificate management; the only optionions that scale and work with both internal and external CA's I've seen are Lemur (Netflix tool that's open sourced) or Venafi, which has support for something crazy like 300 different OS and Appiance combinations and is used by the majority of the Fortune 500.
Implement a blind-password vault. To access data, everyone supplies the vault password. This password, however, does not decrypt data. The vault retains a randomly generated key and the vault software retrieves and decrypts the file. If data is stolen, even those with passwords cannot access it. Further, the vault keys can be backuped and restored on-demand.
If you want your files encrypted 'at rest' so that if someone comes and pulls your HDD (or software equivalent) then you can implement a strategy similar to:
(a)Encrypt all content with individual symmetric keys (one key per piece of content) - prefix each piece of content with a key ID (for key lookup on exit) - there are many ways to associate content with a key - prefixing is just the simplest
(b)Encrypt those keys (which you'll need stored locally for performance reasons) with a randomly generated one-time pad stored on a removable hardware device (HSM/USB for example)
(c)Decrypt files as appropriate as they exit your webserver - observe the key ID of the content, ask a process on your machine to give you the symmetric key for that ID, decrypt the content, send it back to the requesting connection.
Don't store the master key and/or one time pad locally, simply have a daemon/service/long running process on your web server require (at startup) you to plugin your hardware device (e.g. read a file from a mount that is only there when you plug the thing in.) This means that stealing the content doesn't do them much good (if they crack a key it's only for that particular piece of content, they'll have to crack lots of keys), and if they get the locally stored symmetric key file it doesn't do them much good either because you're protecting that with a VERY strong key and/or cipher which is stored air-gapped - they'd have to not only steal all the files involved, they'd have to inject into the service/daemon that issues symmetric keys.
This type of approach has performance implications of course, and to make it truly close to unbreakable requires more specifics (process injection prevention, signing and impersonation attack prevention, both on the key request side and the service/daemon unlocking scheme, et cetera) - this would be quite a discouraging system to attempt to break.
My $0.02, YMMV
Loading...
Put it behind 7 proxies. I hear that works. https://m.youtube.com/results?...
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?
... or any other personal confidential data. Or maybe company IP. There's a pretty broad legal use-case if you think about it.
"Consensus" in science is _always_ a political construct.
I would tell them to use encryption for everything all the time or they would be beaten like a rented mule. Then I would randomly beat an employee or two just to drive home the point.
Note that the directive would apply to ALL communication, including asking a coworker where he/she wanted to go to lunch. For example:
Coworker #1: "aZqk jhwf89 489c32r8934 hfh7 246eg6sd17?"
Coworker #2: "KSJED894nc&HE#%32jhdi."
Coworker #1: "$R^WJFC8ewm4f8u(Y3em90r4c987!!"
Just cruising through this digital world at 33 1/3 rpm...
The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.
Yeah, this is particularly frustrating - the fella gets his question out in front of the community but then forgets to ask a question we can answer.
Protecting the drives from junk salvagers upon decommissioning is such a different problem than protecting the data on the system from the CIA. Your two-layer solution is clever, but it's going to be slow if you have each one in a different jurisdiction. Having the keys in various jurisdictions may protect from a large class of problems without requiring manual intervention or additional cost.
If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to ensure 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?
ensure: make certain that (something) will occur or be the case.
insure: arrange for compensation in the event of damage to or loss of (property), or injury to or the death of (someone), in exchange for regular payments to a company or to the state
If you're writing something, it is presumably with the intent of convincing the reader of whatever it is you have to say. But when a practised reader sees a grammar (or spelling) mistake, it temporarily distracts them as they re-read your writing to ensure they correctly understand what you were trying to say, distracting them from your actual message.
LUKS across all systems, done.
Solves 2 issues.
a) no more Windows.
b) no more Microsoft Updates.
Been running LUKS encryption on almost all our systems for years. Use 2FA to unlock the encrypted partitions - a short-ish passphrase (only 20 characters) + HW token input.
No passphrase (there are 8 different slots for multi-user systems), no unlock.
No HW token, no unlock.
Of course, you need to be there physically during boot to make it work - or have remote USB passthru working.
Check out OnlyKey https://www.amazon.com/OnlyKey... to get started.
While encryption itself is an issue to be worked out, the real question is key/encryption password management: How do you keep the keys off of a server that you worry about being stolen or physically compromised? Specialized hardware exists specifically for this. There are network versions of hardware security modules and you would put one of these in a secure location, apart from your server, but available to your server over a network so if you need to restart the server, it can access its encryption keys (probably with human intervention on the HSM side.)
HSM equipment comes in all sorts of shapes and sizes with the smallest being the chip in your credit card or a TPM chip in your laptop, to big ones which are rack mounted and require multiple key cards to activate.
The fact you mention disk passwords leads me to believe that you are familiar with consumer grade encryption, but probably not enterprise grade encryption management. Microsoft offers some good tools for this, so do many of the other security vendors. Most of these tools have complex, rolling recovery keys for whole disk encryption and assigned users are still able to log in with their normal AD, but you can go the route of additional factors or ways of protecting the identities. If you have need of an additional layer item level file encryption goes a very long way of securing email and documents that might be sensitive. That said, you have to equally protect the user accounts that can decrypt the system with tools like Privileged Access Management, Additional login Factors and threat detection tools. I'd suggest hiring an expert for this endeavor, it's pretty specialized and if you get it wrong, you only make it harder to manage, not more secure. Consulting organizations do this all the time, and depending on what you need, it doesn't have to be insanely expensive.
I really wouldn't want to ever implement and manage WinRM site-wide though until it was super mature.
Some kind of key management fuckup and you're left with a pile of encrypted gibberish.
Do what CryptoLocker did - bots can do the site-wide encryption. Have triggers on servers and local devices, as needed. You can pick the type of files to encrypt, which cryptography to use, and where to store the key(s) - hopefully in a safe place off site. Users will be the most vulnerable part of the process. They have to be clear about the techniques to access and save the files. Which brings to mind another can of worms...
The problem with encryption software is that most of it isn't designed to be centrally managed. I am an OpenBSD user and I use full disk encryption which is slick as owl shit but there is no way to centrally manage, say, several OpenBSD machines. In order to change the passphrase or key I have to go to each and every machine. There are some commercially available software packages that will implement central management tools but I do not trust them. When it comes to encryption, if I cannot see the source code, I do not trust it.
Thanks to everyone who took the time to suggest their ideas. — OP
What type of attack is being mitigated against and how does the risk of failure of the encryption solution compare to that of the attack vector? There are many ways encryption can fail, including loss of keys or too much exposure to the passwords for these keys.
For example, are we talking about hardware theft or software based intrusion?
For hardware theft, then you would probably want to find a solution where no one needs to know the keys, but it is part of the local infrastructure. This would mean that once hardware is taken out of said infrastructure then it can't access the keys it needs to make sense of the data. Just like anything there are still scenarios where this could fail or be a hinderance.
For software there are so many variables and use cases, I am not going to try to list them, but remember there are both internal vectors of attack and external vectors of attack. Sometimes the hardest one to defend against is social engineering.
Jumpstart the tartan drive.
Just one word: Tahoe-LAFS. Deploy, use, relax.
cpghost at Cordula's Web.
I see a number of good ideas already for home-brew solutions so here's one for an enterprise out of the box solution. (usual crypto caveats apply, if you don't build it yourself, how do you know there's no backdoors... otoh, if you do build it yourself, assuming your not Bruce Schneier, how do you know you got it right? Take as directed, evaluate your risks before using)
I've had good success with Gemalto's protectfile product in this space. The NAE device handles the master key storage, temporal keys are stored in the device driver, encrypted by the master key. Accesses can be controlled by user through any of the usual authentication mechanisms, including saying "This is my backups user, it can read only encrypted data" which is a nice feature I don't see often enough on enterprise level encryption. Saves me from having to trust the sketchy encryption on the backup solution which is almost always backed by the "trust us" guarantee.
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Designate Navajo a designated language for classified documentation. Or select some other tribe.
Basically hire entire tribe and make a designated record keeper. Worked as a quasi encryption during ww2, will work now.
And, yes. Go paper. Old secrets can be safely be burned, when no longer relevant.
The best solution is simply ZFS with encryption which is live now. Or VERY soon. Easy peasy. Everything is convoluted, difficult, and will end in tears.
The whole point of a system like this is to exclude those who are unauthorized,
To do this, passwords that may be re-used provide a strong enough security problem to make it unworkable.
The best solution is to use some aspect of the people that is unique to them to provide access.
We have seen that retain and fingerprint are far to easy to beat.
It will likely have to be either chemical (DNA?) or electrical ( brain waves or other aspects of the body?) to be secure enough.
One time us password systems help, but are a bear to maintain and support.
I'm curious what Full Disk Encryption is going to help on a running system.
Are you people retarded?
Basic metric of success is removal of the highest possible portion of overall system from trust path as possible.
The best approach I know of is for all writers to have their data turned into encrypted blobs by means of transmission to separate security server. Writers then store subsequent blob output on the appropriate file or application servers.
All readers present blobs obtained from these systems to security server. Security server authenticates reader and uses blob metadata to check access policy before decrypting content.
This allows for arbitrary complexity of application servers and data storage without compromising content should these systems be compromised.
Security server must be physically secure and vigorously designed with a minimal defensible surface. It must be made as "dumb" as feasible.
The recent demonstration of a combination hack escaping from browser, OS, and VM hypervisor demonstrates how people put too much faith in these "container" abstractions. People who are serious about security have realized this since the beginning, always noting that things like VMs and VLANs are nice for resource management and time-sharing, but probably insufficient to really protect sensitive data. Even on non-virtualized hardware, serious people consider exfiltration by other paths such as compromised firmware, and have costly procedures to scrub and change hardware from one security class to another, e.g. you can't even be confident about wiping a system to redeploy it for a different purpose the next week or next year. Sometimes secure wiping ends with physical destruction as the only way to be sure.
The recent news illustrates how encryption of messages can protect them in flight, but the endpoints can be compromised to snoop on data before/after it passes the encrypted path. Encryption at rest has a similar set of vulnerabilities depending on your threat model. An encrypted disk can save you from physical theft of an inactive disk, but not from the many server compromises which can steal data from inside the server software itself while it is in its normal operating mode. All your elaborate key management techniques are useless if the server can be tricked into serving up the plaintext to an attacker. One nice aspect of whole-disk encryption is that it can turn disk wipe/repurposing into a simple act of key destruction instead of requiring secure scrubbing of every persistent bit.
Secure end systems can encrypt data before it gets to the server, and treat the server like a dumb file clerk. The server never has the keys and can at worst corrupt or lose the data from an availability standpoint (using cryptographic signatures to protect yourself from malicious tampering of data by the server). But a compromised server can still expose you to traffic analysis, potentially revealing data-sharing paths (communication) between clients and other temporal properties which might reveal weakness in the cryptography, e.g. the attacker gets multiple snapshots of the same file over time to see how ciphertext changes with common modification patterns.
Concerns for efficiency, usability, high-availability and disaster recovery all oppose strong data security. If you expect a server fleet to recover from power loss or other failures and resume operation unattended, you make key material easier to steal. Hardware-based key managers seem to be the current best option here, as the key lives in the server but is about as tamper-proof as we know how to build. But having trusted humans (a two man crew?) restart servers and reintroduce keys might be safer. But how do they know the server wasn't tampered while it was off, in order to be confident to reintroduce the key material? Similarly, what about backups and offsite replicas? If you back up the encrypted cipher text, you could easily "erase" all backups by losing your key. If you back up the plaintext, you created many more points on a long path where data can be stolen. If you use the dumb file-clerk approach to storage servers, you risk that individual clients lose their keys and "erase" their data. The administrators cannot recover this data for the unlucky user, unless they also keep another key around which then makes the administrator or administrative systems the juicy target for attack to get the keys to the kingdom.
That is what DAC is for. Automate away your problems...
14 years and a solid v4.2 on the SDK ... what exactly is your definition of mature? Microsoft's big failure wrt RMS is their inability to automate roll-outs. It is way too painful to get set up the first time, but once you have done it a few times, it can be done on a demo network in less than 4 hours. RMS is the only solution that covers your entire corporate data and security stack from authentication to network transport to data-at-rest. Adoption success rate is less than stellar though, not inherently because of the product but because IT shops have a tendency to apply controls beyond those necessary. RMS allows an IT shop to do to your entire network what they normally do to a SharePoint server: lock it down until it is useless.
ZFS has native encryption now so you can do some really sick shit with it... exporting encrypted ZVOL's and iSCSI's, per user / dataset encryption, encrypted replication, etc. PEFS is additional user based homedir encryption. On top of all the usual GELI full disk / block device encryption. Of course you can only get all these things with FreeBSD, because well, that's where it's at.
Windows is what most slashdot users use and is a joke as far as security and surveillance goes.
This may be slightly off-topic, but I use free Let's Encrypt certificates for my httpS websites. Personally, I have never had problems with them, however some browsers and mobiles throw up the same OMG WARNING HAXXXORS screen that you get when using a self-signed cert. This has forced me to turn off server-forwarding rules I had in place to direct folks to the httpS site when they used the http URL.
The irony is that these ill-conceived browser warning messages are herding them to use the un-encrypted site, as supposedly being the "safe" one. Whether the cert is self-signed or LE, it's still ENCRYPTION. That's categorically safer! I know the warning is technically to prevent browsing to a site while being "man in the middle'd", but 9999 out of 10000 times, it's just a perfectly fine SS or LE cert. The browser warnings do nothing but scare people away from safer sites.
This idea isn't novel at all. What solutions have been put into place in places with high security requirements and very deep pockets?
You need to keep in mind is the objective of an attacker is not to defeat the crypto, but to find a way around it and get the plaintext or keys.
Disclaimer: I am the author of the following projects. At Red Hat, we have been researching this problem for the last few years. This has resulted in the creation of the Clevis[1] & Tang[2] projects for automating decryption. This currently ships in Fedora and we plan to ship it in a future RHEL release. This project currently supports both root volumes and removable storage, as well as any other data you want to encrypt and then automatically decrypt. We are working on adding support for non-root volumes as well. For a video on the problem of automated decryption and the architecture of Clevis & Tang, see my recent talk at FOSDEM: Securing Automated Decryption[3]. [1]: https://github.com/latchset/cl... [2]: https://github.com/latchset/ta... [3]: https://fosdem.org/2017/schedu...
Hardware key vault that wipe the keys if compromised. Even works for cloud based VM images
Wrap all of you servers in tinfoil. If you are worried about how to encrypt you entire existence, I'm sure you are very familiar with the stuff.
You wanted "a version of raid for use with servers".
Which is exactly what DRBD and Mars datablock devices are doing.
But they only to RAID1 (replication) accross servers.
For RAID5/6 (1/2 parity out of N-total) isn't supported yet by any direct approach.
Doing software RAID5/6 over iSCSI seems the closest doable with current technologies.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I see four issues here:
Encryption in storage: Technology and practices exist for this already. If there are multiple servers, they can have individual keys.
Encryption in transit: Technology and practices exist for this already. If there are multiple servers, they will need to use the same key.
Proviso: The above can be different systems, requiring a computer to decrypt the data from storage and then encrypt it for transmission. Or conversely, decrypt received data and then encrypt it for storage. It astounds me that no hardware has been built to do this given existing technology, such as GPUs, can perform the bulk of the work. For extra hardening, the keys can be flashed onto the hardware.
Preventing leakage at workstations: There must be some way of preventing users making a local copy on their machines. This means software such as local email clients are disallowed, unless one implements encryption in storage on workstations too. To keep data off the workstation, an X-windows-type terminal needs to implemented via Java and browsers.
Preventing theft of the server: With a well-funded thief able to keep power and RAM alive during a robbery, the server needs to be location aware so it shuts down when it leaves the server room. This can be as simple as a simple ping program on the server: If the server doesn't receive the correctly numbered echo from the network, it shuts down.
Its their web, the world wide wiretap. From a smart phone to a Room 641A https://en.wikipedia.org/wiki/...
So be aware of how the security services seek out your data.
The NSA and GCHQ will try and add their hardware your hardware as a brand imports hardware.
One at a hardware level in a company any network belongs to the security services.
CIA, MI5 also understand the human dimension. Social engineering or a new relationship, new staff.
The amazing new friend, skilled new staff member, potential client who wants a site tour.
Expect devices that will be part of the existing hardware (smart phone) and will pass any expected network usage detection efforts. The security services will alter your hotels networked TV. Staff will have their smart phone, tablet, computer packed with gov malware.
Data might be stored locally for another human to pick up. No use of any network to remove data. The hardware might be altered by a human and then a network is used to collect later. So not always expect to see a new unexpected upload. A human might place the malware and then collect any results. No litter to find.
So a company watching its networks and devices might not see any network changes at all or just "expected" user/staff data going out later.
How to keep your patents ideas, inventions, banking, designs secure from the USA and UK?
Use a one time pad for that very important message. Don't reuse the one time pad code, consider sending staff out to deliver an important message in person.
Only use the internet network for reaching consumers. Don't allow smart phones or other devices near advanced product development.
Be aware of offers of random friendship at a gym, bar, club, art gallery, business or sports event, cult, faith by very friendly strangers.
The distraction could be used to add malware to your smartphone physically so no network trace will show any changes in usage.
Secure your internet servers that interact with consumers to the best new standards that users can still access.
Get any emerging product work away from computers, return to paper and secure face to face meetings for creative ideas.
Don't allow smart phones or watch devices to secure meetings.
Keep all new friends or random staff with consumer electronics from wondering around any secure areas.
Once all that is in place and working, get your legal team ready for a NSL. Understand that a lot of malware can be networked or can be entered by a human.
Domestic spying is now "Benign Information Gathering"
I'd like to suggest something like trevisor, a hypervisor for a single guest VM. Where the user enters a passphrase on boot, and the encryption keys are only stored in debug registers. Though this probably needs some additional work to be production ready.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Use a hardware security module, like a Safenet KeySecure, to manage your keys. Use different keys for different aspects of your systems so that if one key is compromised only some data is compromised. Use versioned keys to allow frequent key rotation without downtime. Separation of concerns is also important. No one person should know how to get all the keys.
Just turn off all IPD/IDS, firewall and anti-virus. In an hour or so the ransomware should have the entire site thoroughly encrypted.
Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
Enforce encryption client-side. Server just hosts encrypted files and has no way to decipher them.
If this is for a serious business and you need to ask /. how it is done then back the fuck away from the keyboard and hire someone that understands this or you will be walking into a world of pain. First check what you are really doing justifies encryption, remembering encryption does not protect you from people installing malware, people social engineering access, unsecured buildings, unpatched systems etc etc and this is usually what is being exploited. First you need to get your businesses tech security in order otherwise all you are doing is adding more complexity with very minimal security improvements (basically you solve the issue of someone stealing a harddrive).
Yea, all that is great ... But I'm just going to compromise one of the poorly written apps that access the data . . . Or shove bamboo springs under your finger and toe nails until you log me in and show me the data I want.
You've neither prevented state sponsored activity or script kiddie automated scans ... But your system is now really complex and likely to fail more often! Yay!
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.
So you 6gb/s ssd drives are limited to a whooping 100mbps. That's slow, bruh. Unless your drives are all IDE this does not scale.
Very sneaky NSA, very sneaky, but you'll have to get up pretty early in the morning to fool this woke fox. I {retracted} my {retracted} with {retracted} {retracted], you yellow bellied sons of {retracted} {retracted}!
The autism-hating, custom EpiPen-hating, Musk-hating Slashdot troll!
How's life in the hypocrite lane?