How are encryption keys organised and rotated for a database encrypted at rest, and what does envelope encryption — a data key wrapped by a key-encrypting key — buy you?

## The hierarchy Almost every real system uses at least two levels: - **DEK (data-encrypting key)** — the symmetric key that actually encrypts pages, tablespaces or column values. It must be available on every read, so it is cached in the database process's memory. - **KEK / master key** — encrypts ("wraps") the DEK. It lives in a key manager, HSM or cloud key service and ideally never leaves that boundary; the database sends the wrapped DEK and receives the unwrapped one at startup. The wrapped DEK is stored with the database (a keyfile, a control file, a catalog table). Because it is ciphertext, storing it beside the data is safe — which is the elegant part of the design. ## Why two levels **Rotation asymmetry.** Cryptographic hygiene and most compliance regimes ask for periodic key rotation. Re-encrypting terabytes annually is unattractive. With envelope encryption, "rotating the master key" means decrypting one small DEK blob and re-encrypting it under the new KEK: milliseconds, no data rewritten. That satisfies rotation for the key that is most exposed — the one referenced by many systems. Rotating the **DEK** is a different, expensive operation: every page or value must be read, decrypted under the old key and written back under the new one. Reserve it for suspected compromise or very long-lived keys, and run it online: keep both versions valid, tag each artifact with its key version, migrate in throttled batches. **Separation of duties.** The database administrator can read files and run the engine but does not hold the KEK; the key custodian can unwrap keys but has no database privileges. Compromising one role is not enough. Enforce it with key-service policy — the instance's identity may call unwrap, humans may not. **Scoped destruction.** Give each tenant, tablespace or backup set its own DEK. Deleting that DEK renders exactly that data unreadable without touching anything else — crypto-shredding, the only practical way to "delete" a tenant from years of immutable backups. **Audit.** Unwrap calls are logged centrally, so a restore or an unexpected instance startup produces a visible event. ## Operational realities **Availability dependency.** If the key service is unreachable, the instance cannot unwrap its DEK and may fail to start or fail to open a tablespace. Model this in the availability budget: regional redundancy, cached unwrapped keys where the engine allows it, and a documented break-glass path. **Backup restorability.** A backup is encrypted under the DEK version current at backup time. Destroy or lose that version and every backup wrapped by it is unrecoverable. Key retention must therefore be at least as long as backup retention — the most common way teams destroy their own recovery capability. **Key placement.** A key file on the same volume as the datafiles turns encryption into obfuscation, because a thief takes both. Likewise, an application encryption key checked into config beside the connection string protects nothing. **Compromise response.** If a DEK may have leaked, rotating it is necessary but not sufficient: the attacker still holds anything copied while it was valid. The real response is rotation plus assessing what was readable during the exposure window. **Verification.** Test the whole path, not the config: restore a backup in an isolated environment using only the key service, and confirm the audit log shows the unwrap. A key hierarchy never exercised in a restore is an assumption, not a control. ## Say this in an interview "Two-level keys let me rotate the exposed key cheaply and keep custody outside the database, while accepting that data-key rotation is a bulk re-encryption job. The two hard constraints are that the key service is now on the critical path for startup and restore, and that key retention must outlive backup retention."