I want to store encrypted data in a database.
- Application-level encryption (encrypting before sending to the DB) is not a reasonable option for my use case.
- The DB providers I'm considering do not allow me to create multiple users/manage permissions at the price point I'll be paying. This means that separating permissions for logs vs reads and writes is not an option.
- Allow MySQL to handle AES encryption (via
aes_encrypt/decrypt) for me (I'm aware of both the ECB block issue and the fact that MySQL logs sensitive data in plain text if not configured correctly)
- Use a DB provider that offers encryption at rest (the kind that happens transparently--automatically encrypt on
SETand decrypt on
Why would I ever choose this type of encryption at rest over
aes_encrypt? (As a note, I'm not storing credit card info or anything else that would encourage me legally to encrypt at rest).
As I understand it, the point of encrypting data in the database is to confront the reality that DB breaches happen. With that in mind, if someone gains access to my DB (meaning they can execute queries), wouldn't this type of encryption at rest actually help them because it would simply decrypt data when they
SELECT? It seems to me it's slowing down queries without adding security.
aes_decrypt, on the other hand, requires that the intruder have access to a key stored on a different machine behind different credentials. Isn't that safer?
In the scenario I described in question 1, an attacker has gained query access to a DB. If that's the case, couldn't they also just enable logging and retrieve the plain text AES key thereby rendering
aes_encrypt useless as well?
(Remember constraint number 2 here.)
Excluding sql injection, are there other scenarios in which an attacker would be able to view what's in my database without executing a
SELECT and therefore without triggering a transparent at rest decryption?
If you have any recommendations that fit within my constraints please let me know. Thank you!