Database Security – Protecting Data from Internal Staff

database-designSecurity

In our database (DB for brevity) we store some very sensitive government data, and would like to secure the data as much as possible.

There are two way to think about security here:

  1. defense from external intruders (essentially making sure PCI-DSS compliance is in place, for instance),
  2. security from internal intruders.

My question is focused on the latter.

The sensitivity of information is considered so high that we're facing a very likely possibility of internal staff getting their hands on the data.

In other words, we're afraid that internal staff can mass-steal the data and trade it (the data is only interesting when stolen altogether, as it's a huge DB of people's private info).

The DB is accessed by our application, on a record-by-record manner. This is considered fine, as using record-by-record manner of accessing data staff is not expected to mass-steal the information.

An obvious solution would be: give "keys to DB" to a single, most trusted man. However our concern is that even in this case someone can put a gun to his head and ask to make the copy of the DB.

Is there any way we could secure the DB, such that even if the DBA is put a gun to his head, he would be physically unable to steal the data?

Note: The database management system we are using is PostgreSQL, but we may easily switch to another one provided it offers the safety guarantees we're seeking.

Best Answer

Gun-against-the-head

Require more heads. This solution scales linearly. Every gun you need to protect against requires one more disinterested head. Consider methods of discrete head positioning. The more work you spend positioning the heads, the more work others have to spend positioning guns. Hide heads for extra obfuscation.

Security is O(n) with heads: MySQL is equally secure with a rock, which is equally as secure as PostgreSQL. That's the best position in a security analogy MySQL has ever been in.

Software Stack Security

  • Network Encryption, use SSL with an AES cipher. Consider layering DB authentication with network authentication using openswan/strongswan.
  • Disk Encryption, use eCryptfs
  • Authentication, use GSSAPI

Database Security

PostgreSQL supports row-level security. I definitely suggest reviewing the DDL security docs. This protects the database against unbridled app-level access. Perhaps all of your data doesn't need to be read by every app? You can even REVOKE or GRANT access to specific columns on the table, see the docs for more info (search for column).

Special notes

You can store encrypted data in the database too. This gets the DBA admin out of the problem entirely. Then the gun-against-the-head switches points of failure to the end-user. This may or may not be a good thing. Certainly, I prefer them to risk the gun-against-the-head scenarios. I just run it.

Related Question