Database Encryption: Protecting Data at Rest
Database encryption turns your data into useless gibberish for anyone without the key. It protects sensitive data at rest, like PII or financial records, from direct theft of the database files.
Why it exists
Databases often store sensitive information like customer data or financial records. If an attacker gains access to the server's file system or steals a physical hard drive, they could read this data directly. Database encryption was created to make this stolen data unreadable and worthless without the proper decryption keys, protecting data even when physical or file-level access is compromised.
The mental model
Database encryption transforms readable data (plaintext) into incomprehensible gibberish (ciphertext) using a secret key. It's like writing a diary in a secret code. Even if someone steals the diary, they can't understand it without the codebook (the encryption key). This protection applies to data 'at rest'—when it's sitting on a disk, in a backup, or on other storage media.
How it works
An encryption algorithm (like AES-256) and a secret key are used to encrypt data as it's written to the database and decrypt it when an authorized user or application reads it. The main approaches are: first, Transparent Data Encryption (TDE), where the database encrypts entire files automatically, invisible to the application; second, column-level encryption, where only specific sensitive columns are encrypted; and third, application-level encryption, where the application encrypts data before it even reaches the database. The security of the entire system hinges on securely managing the encryption keys.
When to use it
Use database encryption whenever you store sensitive data that must be protected against theft or unauthorized access at the file system level. This is essential for regulatory compliance like GDPR, HIPAA, and PCI-DSS, and for protecting any Personally Identifiable Information (PII), financial details, or trade secrets.
When not to use it
Encryption introduces computational overhead, slowing down reads and writes. For non-sensitive, public data where performance is critical and the risk of a data-at-rest breach is low, the overhead may not be justified. Importantly, encryption is not a magic bullet; it does not protect against attacks like SQL injection where the attacker uses the application's own legitimate permissions to access data, which the database will dutifully decrypt for them.
One canonical example
A cloud application stores user profiles. The database is protected with TDE. An attacker breaches the cloud provider's storage and downloads the database backup files. When they try to open the files, the data is unreadable ciphertext because they do not have the encryption keys. The data-at-rest protection worked. However, if the attacker had instead used a SQL injection flaw in the web app, the database would have decrypted the data for the query, and the data would have been exposed.
Interview question
Database encryption primarily protects data at rest. Which attack scenario would it not directly prevent?
- a.An attacker steals a database backup tape.
- b.An attacker uses SQL injection to retrieve sensitive data via the application.Correct
- c.Unauthorized access to the database server's file system.
- d.A server's hard drive containing the database is physically removed.
Why? this is the answer
Database encryption protects data when it's stored on disk or in backups by making it unreadable without the key. However, it does not protect against attacks like SQL injection, where an attacker uses the application's legitimate permissions to request data, as the database will decrypt the data before returning it to the authorized (but compromised) application.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #database
- #security
- #encryption
- #architecture
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on database — each one lists the topics its interview covers.
See open roles