Greetings, * Scott Marlowe (scott.marlowe@xxxxxxxxx) wrote: > On Tue, Aug 22, 2017 at 3:13 PM, PT <wmoran@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, 22 Aug 2017 12:48:13 -0700 (MST) > > rakeshkumar464 <rakeshkumar464@xxxxxxxxxxx> wrote: > >> We have a requirement to encrypt the entire database. What is the best tool > >> to accomplish this. Our primary goal is that it should be transparent to the > >> application, with no change in the application, as compared to un-encrypted > >> database. Reading about pgcrypto module, it seems it is good for few columns > >> only and using it to encrypt entire database is not a good use-case. > >> > >> Is this which can be done best by file level encryption? What are the good > >> tools on Linux (RHES), preferably open-source. There's been discussion and work to add the ability to have encryption at the database instance level instead requiring on filesystem-level or harddisk-level encryption, but nothing has gone into PG yet to support this. I'm hopeful that there will be progress towards this in the next round of PG development, ideally landing in PG11. > > On multiple occasions, I demonstrated that an unecrypted database was the > > least likely disclosure vector for sensative data, and that we shouldn't > > waste any time on it until we had ensured that all other breach vectors had > > been fixed. Over the course of 4 years at that job, we never managed to get > > all the other (more likely) breach vectors secured. While that's interesting, I don't find it particularly relevant- fix the breach vectors you can reasonably. If you're worried that backups or hard drives might not be properly handled and may fall into an attacker's hands and adding encryption to address that is straight-forward and simple to do then it's entirely reasonable to do so, even if your application isn't as secure as you'd like it to be. > > As a result, my opinion would be that you use filesystem encryption. It's > > very efficient, low management overhead, and proven technology that doesn't > > interfere with anything else you're doing. You can then check that box on > > whatever form you have to fill out and the beaurocrats will leave you alone. > > On top of that, it effectivley protects againts possible breach vectors that > > don't require changing the application. If PG-level encryption was also efficient, low management overhead and based on proven technology that didn't interfere with anything else then it would be an entirely good thing to consider doing. We don't have that today, but that doesn't make it unreasonable to ask for. > > Real security will require changing the application. But take my word for it, > > nobody wants to hear the list of breach vectors that can only be fixed by > > modifying the application. Because people aren't interested in real security, > > they're just interested in checking boxes on a form. If it's trivial to address a certain set of attack vectors, then it makes sense to do so, even if it's a relatively unlikely vector to be hit with. I agree that non-trivial efforts to address unlikely attack vectors is a bad idea when there are more likely vectors to consider addressing first. > This. Without a much stricter definition of the attack vectors you're > trying to defeat "encrypt the whole database" is a very hand-wavy > proposition. Are you protecting against people getting into the data > center and stealing your hard drives? Rogue applications getting > access to the db? Someone sniffing the passwords or unencrypting them > on the servers etc etc. This continues to come up in discussions which outline the attack vectors that database-level encryption addresses. We know the vectors which database/filesystem-level encryption addresses, we don't need to beat up people asking for it by telling them that they don't know- let's just make it clear that there's only a subset of vectors addressed by database of filesystem encryption and ensure that everyone understands what those are and then individuals can weigh the choice themselves as to if it makes sense for their particular situation to address those vectors through database/filesystem-level encryption or not. > OP: It's just generic a requirement to take seriously. Sit down, come > up with possible attack vectors and possible ways to thwart them. This is certainly a good exercise, but "someone stole the backups" is absolutely an entirely reasonable attack vector to consider and database-level encryption is one approach which could (if implemented properly) address that vector. There are certainly other approaches to address that vector as well, of course, such as using backup technology which provides its own encryption, though that requires managing a different set of keys possibly, or run the backup through GPG or similar but that gets painful quickly, et al. > Security isn't something you do one time and you're done, it's a > constant process of design, review, updates, and education. Agreed. Thanks! Stephen
Attachment:
signature.asc
Description: Digital signature
