Encryption at rest

What at rest actually means#

Data has three states and each has its own control. In transit, protected by transport encryption between two endpoints. In use, held in the memory of a running process, where ordinary encryption does not reach. At rest, sitting on storage — a volume, database files, a backup, a snapshot, an object store.

Storage encryption addresses exactly one adversary: somebody who obtains those bytes without going through the application. That adversary is real — hardware is lost, snapshots are copied to the wrong account, drives leave data centres — and the control is worth having. It is simply much narrower than the phrase suggests to most readers.

Three layers, protecting three different things#

Only the third layer keeps a value opaque to a database administrator or to a leaked export, and it costs you the ability to search, sort or join on that field. That is why it is applied to a short list of values that are never queried on — credentials and tokens — rather than to everything.

Does Connect use encryption at rest?#

Yes at the storage layer, and additionally at the application layer for the values that need it. Provider credentials are sealed by the settings store on every save and are never echoed back to a screen — an interface that shows you the secret you saved is an interface that will eventually show it to somebody else. The browser line's own generated password is stored encrypted, served only to its owner and individually revocable.

Files uploaded into a workspace live on the shared media table through one file service, already workspace-scoped and already under row-level security, so they inherit the same isolation as every other record rather than acquiring a second storage story with its own gaps.

One deliberate exception is worth naming, because encryption and reachability are independent properties. Synthesised speech for calls is stored content-addressed and served without a session, by digest — the carrier fetching audio mid-call has no session to present. It is a public read of an unguessable address, and it is that way on purpose rather than by oversight.

What it does not protect against#

• A valid credential. A request that authenticates gets plaintext, because that is the point of the system. Storage encryption never sees that request.
• A query written without a filter. That is what row-level security is for, and it is a different control entirely.
• A backup whose key travels with it. A snapshot copied together with access to its key is a plaintext snapshot with extra steps.
• Data that left the encrypted store. A log line, an error message, an export or a support attachment carrying record content is outside every one of these layers.
• A compromised host. Data in use is in memory, decrypted, by definition.

The practical consequence for anyone reasoning about risk: storage encryption removes an entire category of physical and infrastructure exposure and moves the remaining risk onto credentials, authorisation and what your own system copies elsewhere. Those are where the effort belongs.

Rotation, and what rotating a key does not do#

1. Rotate the master key.

   Result Data keys are re-wrapped. Nothing stored is re-encrypted, and this is fast — which is exactly why it is not the strong action people assume it is.

2. Rotate a data key.

   Result New writes use the new key; existing data has to be re-encrypted to benefit, which is a real operation with a real duration.

3. Consider what an attacker already has.

   Result If plaintext was exfiltrated, no rotation helps — the copy is not encrypted with anything. Rotation limits future use of a key, not past use of the data.

For credentials the equivalent action is different and stronger: revoke and reissue, so the old value stops working rather than merely being protected. See secret management.

Questions#

Related#

• Secret management
• How provider credentials are stored
• Row-level security
• Credential rotation
• Personal data
• Backups and restore
• Public and authenticated surfaces