Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

This is a good list, but I find that people are often confused about this requirement:

> Similar to encryption in transit, practicing data encryption at rest—using standards like AES-256—will ensure that stored data is not accessible to any application or user unless they present the decryption key.

A lot of people seem to have the attitude "Oh, my DB is in Amazon RDS, and they say everything is encrypted, so I'm good". However, if your DB creds get hacked, they can still read all the info in your DB.

What should really be required is a tokenization or app-side encryption scheme, ideally using something like AWS or GCP KMS so that all decryption requests are logged and monitored, for any even remotely sensitive data that is saved to the DB. That can also make it much easier for developers, because it's safe to give out read-only user access if you're sure they can't read any sensitive private data.

View on HN

Assuming that your sensitive data is a key part of your product offering (and if it isn't you shouldn't be storing it imo) - wouldn't logging all decryption requests just generate a lot of noise during the day-to-day operation of your application? I struggle to see a scenario where what you described actually increases the real-world security of your data, beyond allowing you to do a more in depth retrospective of who took what data (which can be achieved without the overhead of double encryption).

In the event that some DB creds get leaked or brute forced or however, to the application/DB those creds will look just as legit and any irregularities would only be discovered at best while the data is being taken

This article from Google explains a little more: https://cloud.google.com/sql/docs/mysql/client-side-encrypti...

I think your latter pattern is referred to as “envelope encryption” or “data key encryption.” This allows you to store ciphertext and decrypt on demand. Bonus points is using a different datakey per customer/logical container/etc while still using one (or more) KMS keys. An example https://encryption-ws.workshop.aws/keymanagement-kms/envelop...

Fine if your sensitive data are infrequently needed in the clear--credit card numbers and the like--but probably not realistic if the sensitive data are part of regular operation. I'll also note that the risk hasn't changed all that much; a compromise of the app server/decryption oracle/etc. having access to the key material is roughly as severe as a compromise of the app server having credentials and network access to the database.

Not just your creds getting 'hacked', but also to secure your data against a court order. AWS can be compelled by a 3-letter government agency to turn over your data without even telling you. Encrypt it. Own your own keys.

Reply on news.ycombinator.com