Database Security – Best Practices for Storing Critical Databases on Developer Laptops

databaseSecurity

We have a few givens:

  1. Developers need a replica of the production database on their machines.
  2. Developers have the password to said database in the App.config files.
  3. We don't want the data in said database compromised.

A few suggested solutions and their drawbacks:

  1. Full-disk-encryption. This solves all problems, but degrades the laptop's performance, and we are a start-up, so don't have money for powerhorses.
  2. Creating a VM with encrypted hard disk, and store the database on it. It works well, but it doesn't help too much, since there's a password in Web.Config.
  3. Solution number 2 + requiring the developer to type the database password every time he runs anything. It solves all problems, but it is really cumbersome for developers that sometimes fire up the application multiple times a minute. Also, we have multiple applications that connect to the same database, and implementation of a password screen will have to differ in each.

So, my question is, if there's any common solution to such problem, or any suggestions on how to make any of the above solutions workable?

Best Answer

Not only do you not want a copy of the production database, it may actually be illegal. For example, in the US, you cannot move production data out of the production environment if it contains regulated information like personal health data, financial data, or even data that could be used in identity theft. If you do, you could be fined, lose your compliance standing and therefore be subject to more aggressive audits, or even be named in a lawsuit.

If you need production-scale data for testing, you have a couple options:

  1. Generate all dummy data. This is trickier than it sounds. It's surprisingly difficult and labor-intensive to generate sensible imaginary data.
  2. Anonymize your production data. This may be easier, but proceed with caution.

For option #2

  • In the production environment, an authorized database admin makes a copy of the production data.
  • Still in the production environment, the same authorized admin runs a routine that anonymizes all sensitive data. If in doubt, anonymize.
  • Only then should the data be moved to another environment.