I had a hard time phrasing the question. I'd rather ask, "How do I comply with GDPR?" But that would probably be too broad of a question. Database encryption concerns me the most, since that's what the client wants.

Let's consider some typical site: front end (Javascript), back end (Ruby, Python, PHP, you name it), and database (for example, PostgreSQL). It may be a single-page app, or the traditional approach (MPA). Most likely database and back end is on the same server.

To me it sounds like it's not worth the effort. Generally, the secret can only be kept on the server. If someone gains access to the database, he will most likely be able to find the secret. Unless probably access is gained via SQL vulnerability, which are mostly gone with today's frameworks. Or so I believe.

So, does it make sense to encrypt the database to comply with GDPR? Where to keep the secret? What are disadvantages of encrypting the database? What information to encrypt? Are there any better approaches?

  • 1
    You're missing one very common exposure risk: backups. Encryption will help a lot if a backup is accessed inappropriately as long as the key is kept separate from the backup. – nbering Apr 15 '18 at 10:36

On Compliance

I'm only loosely familiar with the specifics of the legislation, but as I understand it, there's nothing to indicate that database encryption is required to hold personal information and be in compliance with the General Data Protection Regulation (GDPR).

On the other hand, using appropriate encryption measures will somewhat lessen the privacy impact and notification requirements should there be a breach.

(3) The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

Excerpt from: https://gdpr-info.eu/art-34-gdpr/

On The Benefits of Encryption for Database Security

Encryption can significantly reduce the impact of a data breach. For example, in 2015 Patreon was breached, losing control of 15GB of data. To their credit, Patreon used strong bcrypt hashes to protect passwords, and had used secondary encryption measures to protect sensitive information like Social Security Numbers and tax information.

Had they not encrypted the information, the impact of the breach - both for Patreon and their users - would have been considerably worse.

On Key Management

If your concern is that an attacker would be able to access the key anyway, there are some steps you can take to mitigate that risk.

Ultimately, unless you use a Hardware Security Module (HSM), protecting keys is basically like playing a shell game with the attacker. One reasonably effective way to keep keys protected is not to store them on the server at all. One of my favourite solutions for this is the Azure KeyVault service.

By keeping the keys out of permanent storage on the server and retrieving them only for use from memory, it makes it considerably harder for an attacker to retrieve the key. You'll still need to store keys to access the keys... but adding that extra layer of indirection will make it harder for your attacker.

  • Is it that correct that encrypting the partition with database makes less sense, if any at all? It guards against steeling hard disk or the whole server, doesn't it? Also, can you elaborate on storing keys out of the server? How do I make my site access the keys? Do I need to enter some sort of password for keys to appear in server's memory? Does it mean I've got to do some extra steps to restart the server? Is it available for Linux? – x-yuri Apr 17 '18 at 9:06
  • I never said disk encryption wasn’t a good idea. Disk encryption just protects against offline attacks against your VM’s disk, whereas encrypting the actual value in the database protects you even if someone found a way to connect to your database directly and dump the data. To your second question, you’d store and access key that you use to fetch the encryption key from a different system. Easier to roll the access key if it is breached, than it is to change the encryption key. – nbering Apr 17 '18 at 14:29
  • But if attacker has attained the access key (a key to access the encryption key from the other server), can't we consider the encryption key being breached as well? That is, having the access key (which most likely means you've got some sort of access to the server), it's easy to get the encryption key. Could you imagine a case where it is not so? – x-yuri Apr 24 '18 at 6:15
  • If you have an audit log on the encryption key source (like Azure KeyVault), you could determine if the access key was used to retrieve the encryption key after the attack began. But otherwise yes, you should assume if the access key is breached that you’ll need to roll the encryption key. Frequently rolling the access key in an automated fashion is also cheaper than rolling the encryption key, limiting the impact of an access key breach. For the very advanced, it’s an opportunity to alert on something like “key accessed outside server start event”. – nbering Apr 24 '18 at 10:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.