Encrypted Databases Do Not Replace Database Access Control

“The database is encrypted with customer-managed keys, so access control is less important.”

Let me stop you there, before that becomes a production exception with a reassuring little key icon beside it.

Database encryption does not authorize a query.

Encryption at rest protects data files and backups when somebody gets at the storage outside your database engine.

Database access control decides whether your application, analyst, administrator or workload in front of the running engine may ask for a table, a row, or an administrative operation.

Different exposure paths.

Transparent Data Encryption is specifically transparent to your application.

That is not a defect.

It is the point.

SQL Server TDE encrypts data and log files at the page level, then performs real-time I/O encryption and decryption so the querying application can keep querying.

A role with SELECT access doesn’t receive a puzzle box.

It receives the row.

Somehow this still surprises people who would never say “the filing cabinet has a lock, so everybody in the office can read every file.”

Put the filing cabinet on encrypted storage and suddenly your application service account is a trusted librarian for all eternity.

It isn’t.

1. “But the Key Is Customer-Managed.”

Good.

Customer-managed keys make key use a separately controlled part of your storage-protection design.

They don’t make a storage key a database-policy engine.

Your database still has to decrypt its protected pages during normal operation.

TDE uses a database encryption key protected by a certificate.

It encrypts and decrypts data and log files as the engine performs I/O.

Your application never receives your database encryption key, because it doesn’t need it.

It sends a query.

The engine checks the connected database principal and its privileges.

If the query is allowed, the engine returns data in the normal result set.

A key governs use of a cryptographic mechanism. A database role governs a request.

Which is why “customer-managed” can’t settle the access question.

The relevant question is not merely who can get a disk image, or invoke a storage key.

It is: which workload can establish a connection, what role does it assume, which tables can it read, which rows can it see, and through which administrative path can those answers change?

Calling a key-management boundary an access model is like calling the safe combination an employee directory.

Both may be useful.

Neither has the other job.

2. “But the Disk Cannot Be Mounted Elsewhere.”

Then your at-rest control is doing one of its jobs.

Worth having.

TDE protects against theft of the physical or virtual storage medium.

It also automatically encrypts backups taken from an encrypted SQL Server database.

Provided your certificate protecting your database encryption key is separately backed up.

That is a very concrete storage-and-recovery property.

Lose your certificate and you own an encrypted backup you can’t restore.

None of it changes a connection that arrives at the running database with a valid account and broad privileges.

The engine is already using the key material it needs to serve your system.

A compromised workload doesn’t need to mount the disk elsewhere.

It needs only the ordinary path you built for it.

The February 2019 Verifications.io exposure makes the category error painfully visible.

Its MongoDB instance was configured with no authentication and reachable on a public address.

No vulnerability was exploited.

No credential was stolen.

No code was injected.

Your database was simply willing to answer queries.

The exposure involved roughly 150 gigabytes and approximately 763 million unique email addresses.

Storage encryption would have been relevant if somebody stole the medium.

Authentication was your control that was absent at your database boundary.

“Cannot read an offline disk” and “cannot run an online query” are not rival descriptions of the same guarantee.

3. “But the Application Is the Only Database User.”

That isn’t the comforting fact it is usually presented as.

Every mainstream relational and document database has an RBAC layer.

A user or service account receives one or more roles, and those roles hold defined privileges.

In the ordinary relational case that is table-scoped.

A role may have SELECT on the customer table, INSERT on another, and no grant on a third.

Your database enforces exactly what the grant list says.

The problem is the word “application.”

An application isn’t a single action.

It reads profiles.

Creates records.

Changes settings.

Serves support staff.

Runs reports.

Moves data to analytics.

And occasionally grows an administration feature everyone promises will be temporary.

If every path shares one database identity with SELECT on the customer table, then every path that can use that identity can read every row in the customer table.

Including a compromised workload.

It does not have to defeat your storage cipher.

Your database recognizes your application identity, observes an allowed privilege, decrypts the necessary page as part of normal I/O, and returns the rows.

That is not cryptographic failure.

It is faithful execution of an overbroad authorization decision.

PCI DSS gives the distinction requirement numbers, because apparently prose was not enough.

Requirement 3 concerns stored account data.

Requirement 7 restricts access to system components and data by documented business need.

Requirement 8 requires unique IDs and, in PCI DSS 4.0, broadly applies MFA to administrative and cardholder-data-environment access.

Three requirements.

Three control problems.

One padlock icon cannot complete all three.

Use distinct application identities where the jobs differ.

Make default-deny real by withholding grants until a role needs them.

Review grants and revocations, rather than letting a one-time convenience role become a permanent capability.

4. “But Row-Level Security Is Difficult to Maintain.”

Sometimes it is.

Your tenant boundary is still present when your policy is inconvenient.

RBAC answers the coarse question: may this role touch this table?

Row-level security answers the finer one: which records in this table may this connection see or modify?

PostgreSQL makes the distinction explicit. `ALTER TABLE …

ENABLE ROW LEVEL SECURITY` enables the control, and a default-deny policy applies until an explicit policy exists.

For a shared multi-tenant table, the canonical pattern is `CREATE POLICY …

USING (tenant_id = current_setting(’app.tenant_id’))`.

The result is not that SQL becomes morally better.

The result is that the engine filters returned rows against the connection’s tenant value, even when the underlying query asks for more.

PostgreSQL also makes policy composition uncomfortably specific, which is exactly what a security control should be.

Permissive policies combine with OR.

A row passes if any applies.

Restrictive policies combine with AND.

A row must pass every one.

That changes the access result.

Treating it as an implementation detail is how a tenant filter becomes an optional decoration on a query.

And do not stop reading after the pleasant part.

Table owners and superusers bypass RLS by default, unless the table uses FORCE ROW LEVEL SECURITY.

Which means approved administrative paths, ownership, superuser assignment and your audit trail around them are part of your tenant-isolation design.

Encryption at rest does not make that qualifier less load-bearing.

A certificate cannot force a superuser to respect a row policy.

5. “But Audit Logs Will Show Misuse.”

After what?

Audit controls are necessary.

You need to reconstruct who accessed what, and review patterns that should not have happened.

They are not a time machine that turns a returned result set back into protected data.

HIPAA makes the distinction unusually blunt.

Under 45 CFR §164.312(b), audit controls are a required implementation specification for systems containing protected health information: you record and examine activity.

Encryption is addressable for a closed, internally controlled network when an equivalent alternative is documented.

Audit logging is not the optional one in that comparison.

PCI DSS says the same at its own layers.

Requirement 10 calls for logging and active monitoring of access to system components and cardholder data.

“Active monitoring” is stronger than retaining logs in a bucket nobody opens.

It still operates after or alongside access.

Requirement 7 is your control that restricts who may have access by business need.

The log records the decision and its use.

The role and row policy constrain the query in the first place.

Which is why audit events have to cover ordinary application identities, not only human administrators.

An application account with broad SELECT has no need to look suspicious to the database.

It is doing what it was granted.

Detection may show you the damage.

Least privilege limits the rows available to take.

6. “But Encrypting Columns Solves the Sensitive Fields.”

It can narrow a storage or handling problem.

It does not remove the query-time decision.

Any decryption path your running application can legitimately invoke is part of your application’s access surface.

If the same broadly privileged workload can select the sensitive field and trigger or receive its decryption, you have changed the bytes at rest without making your workload less privileged.

Your database still has to decide whether that identity may read that column, that table, and those rows.

This is the same separation as transport encryption, in another direction.

Encryption in transit protects traffic between database client and server from network interception.

At-rest encryption protects files and backups.

You can have either without the other.

TDE does not configure TLS on your connection string at all.

TLS has its own protocol layers.

RFC 8446 separates the handshake, which establishes a shared secret and authenticates the server, from your record layer, which protects later application data with a symmetric AEAD cipher.

TLS 1.3 protects the session’s bytes on the wire.

It does not decide whether your application role should receive the customer record after the session reaches your database.

Use both kinds of encryption where their exposure paths exist.

RFC 9325 says implementations must support TLS 1.2 and should support and prefer TLS 1.3, while refusing SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1.

That is a transport configuration question.

It stays separate from the grant that lets a connection issue SELECT.

7. No, This Does Not Mean Access Control Makes Encryption Optional.

It doesn’t.

Access control does not make a stolen backup harmless.

A careful RLS design does not stop somebody who bypasses the engine and obtains storage from attempting to read protected files.

It does not encrypt a network session.

Those are real exposure paths, and encryption exists to cover them.

The inverse matters just as much.

Storage encryption does not constrain the normal database engine that holds the keys it needs.

Transport encryption does not make a role least-privilege once your request reaches the server.

Your controls are complementary because their boundaries differ.

Not because a diagram looks more mature when every box has a check mark.

PCI DSS Requirement 4 handles cardholder data over open, public networks.

Requirement 3 handles stored account data.

Requirement 7 handles documented business-need access.

Requirement 10 handles logging and monitoring.

The standard does not collapse them into “encrypt database.”

It names the layers because a system has to operate them separately.

The same discipline applies to replicas and backups.

A primary database with careful roles, and a backup reachable through a broader path, has moved your data rather than protected it.

An encrypted backup without the separately backed-up TDE certificate may be unavailable to your legitimate recovery process.

Availability, storage confidentiality and query authorization each need their own deliberate design.

8. What You Should Actually Do

Start with the database principals that exist in normal operation. Give distinct application functions distinct identities where their required data differs.

Create least-privilege roles with bounded SELECT, INSERT and administrative privileges.

Review GRANT and REVOKE as the application changes, instead of treating the initial deployment role as a constitutional document.

For shared tables, define the tenant or object boundary explicitly. Enable RLS where the model needs it.

Make the policy predicate a database-enforced constraint rather than a convention in application code.

Account for the default owner and superuser bypass.

Where FORCE ROW LEVEL SECURITY is appropriate, make it a conscious decision; where it is not, restrict and review the identities that bypass the policy.

Restrict database administration to approved paths. Enable database audit events and review them as evidence and detection, not as a replacement for denial.

Treat a broad application role as an incident-enabling condition, even when every connection uses TLS and every page is encrypted at rest.

Apply equivalent policy to backups and replicas. Protect their storage.

Protect the separate TDE certificate required for restore.

Do not create an easier administrative or read path around your primary database’s role model.

Encrypt storage and transport with separately authorized key use.

Then require your database to make an explicit decision about the principal, the operation, the table and the row.

9. The Actual Model Is Not Complicated.

Encryption protects bytes from a party that cannot use the relevant key.

TDE protects pages, log files and encrypted backups at rest.

TLS protects the connection in transit.

Those are properties of storage and transport.

Database access control answers a different question.

Which principal may connect?

Which role may run which operation?

Which table may be read?

Which row may be returned?

Which administrator may change the answer?

RBAC provides the table-scoped grant.

RLS supplies the per-row filter.

Audit controls record and examine activity.

Requirements 3, 4, 7, 8 and 10 keep the compliance vocabulary from pretending those functions are synonyms.

Encryption protects data from parties that cannot use the key. Access control governs the parties and workloads that can ask for data in normal operation.

Use storage encryption.

Use TLS.

Use narrowly scoped roles.

Use row policy where the data model needs it.

Log and review access.

Protect backups and replicas with equivalent policy.

They aren’t duplicates.

They are the load path from protected bytes to a permitted query.