Encryption, key management and protecting data

Why this matters

Encryption is the control that still works when everything else has failed. If a storage device is stolen, a snapshot is exposed, or a bucket is misconfigured, encrypted data with keys the attacker does not hold is data they did not get.

In a cloud it is also unusually easy: encryption at rest is often a default or a checkbox. That ease is exactly why the interesting question is not whether data is encrypted but who holds the key — because that determines who can actually read it, including the provider, and it determines whether you can make data unreadable on demand.

This lesson also covers secrets management, which is where objectives 2.4, 4.2 and 4.3 all converge: every one of them ends with "fetch it from a secret store at run time", and this is where that store is explained.

The lesson

Encryption at rest, in transit and in use, and which the provider does by default

Three states, three different mechanisms.

At rest. Data on disk, in object storage, in a database, in a backup. Providers encrypt most storage services by default now, usually with AES-256 and provider-managed keys. This protects against physical media compromise and against a raw storage exposure. It does not protect against an attacker with valid credentials, because the platform decrypts transparently for any authorised request. That limitation is the most commonly misunderstood point here: encryption at rest does not stop a misconfigured bucket being read by whoever the misconfiguration permits.

In transit. Data moving across a network. TLS is the mechanism. Public endpoints are TLS by default, and the parts people forget are internal: traffic between services inside a virtual network, replication between regions, and connections to managed databases — which frequently permit unencrypted connections unless you require encryption explicitly. Enforce TLS rather than merely offering it, and reject downgrades.

In use. Data in memory while being processed, and the hardest of the three. Confidential computing addresses it with hardware-based trusted execution environments that keep memory encrypted and inaccessible even to the hypervisor and the provider. It is the answer for genuinely adversarial scenarios — processing data the provider must not be able to see, or multi-party computation between organisations that do not trust each other. Know what it is and what it is for.

The practical instruction: enable at rest everywhere, enforce in transit everywhere including internally, and use confidential computing where the threat model genuinely includes the platform.

Provider-managed, customer-managed and customer-supplied keys, and the control each buys

The key hierarchy in every major cloud works the same way. Data is encrypted with a data encryption key; that key is itself encrypted by a key encryption key held in a key management service. This is envelope encryption, and it is why rotating the top-level key does not require re-encrypting petabytes — you re-encrypt the data keys, not the data.

Three ownership models, in increasing control and increasing responsibility:

Provider-managed keys. The provider creates, stores, rotates and uses the keys. Zero effort, zero cost, and no visibility: you cannot audit key use, cannot control rotation, and cannot revoke access by destroying a key. Fine for low-sensitivity data, and the default.

Customer-managed keys. You create the key in the provider's key management service and control its policy, rotation and lifecycle; the provider still stores it in their HSM-backed service. This is the usual answer for regulated or sensitive data, and it buys three specific things:

• Access control on the key itself — a second, independent gate. Someone with permission to read the data but not to use the key gets ciphertext.
• An audit trail of key use, which is genuinely valuable: unusual decryption activity is a strong signal, and it feeds objective 6.3.
• The ability to destroy the key, which is crypto-shredding (objective 3.1) and the only practical way to render data unrecoverable across copies you cannot enumerate.

Customer-supplied keys. You hold the key entirely and supply it with every request; the provider never stores it. Maximum control, and you own every operational consequence — lose the key and the data is gone permanently, with no recovery path. Also covers bring-your-own-key and hold-your-own-key arrangements, and external key stores where the key never leaves your premises.

The exam mapping: provider-managed = convenience; customer-managed = control, auditability and revocation; customer-supplied = maximum control and maximum risk of permanent loss.

Key rotation, revocation, and the data you can no longer read

Rotation replaces a key with a new one periodically, limiting how much data any single key protects and how long a compromised key is useful.

Envelope encryption makes this cheap: rotating the key encryption key re-encrypts the data keys only, and the old key version is retained so existing data remains readable. Automatic annual rotation is a common default and is usually the right answer for a compliance requirement.

The distinction to hold: rotating a key does not re-encrypt existing data under most schemes. Old data stays encrypted under the old key version, which is retained. If a requirement is that data must be encrypted under a new key — because the old one may be compromised — that means re-encrypting the data, which is a different and much larger operation. Scenarios distinguish these.

Revocation and destruction are the powerful end of key management, and they are irreversible by design:

• Disabling a key makes data unreadable while the key still exists, and is reversible. The correct first response to a suspected key compromise.
• Scheduling deletion starts a waiting period — providers enforce one precisely because the action is unrecoverable — during which it can be cancelled.
• Destruction makes every piece of data encrypted under that key permanently unreadable, everywhere, including backups, snapshots and replicas you may not be able to enumerate. That is the point, and it is the strongest data-deletion control available in a cloud.

Two operational cautions: know what a key protects before you disable it, because the blast radius of disabling a widely-used key is every service that depends on it; and watch cross-region and cross-account availability — a snapshot copied to another region cannot be restored there if the key does not exist in that region, which is a genuinely common disaster-recovery failure (objective 3.2) discovered at the worst moment.

Secrets management for credentials, and the environment variable that leaks them

Keys protect data. Secrets are the credentials that protect access: database passwords, API keys, tokens, certificates and private keys.

Where they must not be: source code, repositories, container images, templates, state files, user data, configuration files, wikis, chat messages — every one of which has been established as a leak path in earlier objectives.

Where they should be: a secret manager, with:

• Encrypted storage, using the key management service above.
• Fine-grained access control, so each workload reaches only its own secrets.
• Automatic rotation, ideally integrated with the target service so the secret is changed in both places without an outage — this is the feature that turns rotation from a project into a setting.
• A full audit trail of who read which secret and when.
• Versioning, so a bad rotation can be rolled back.

The workload retrieves secrets at run time, using its platform identity (objectives 2.4 and 4.2). No stored credential is needed to get the credential, which is the property that makes the whole thing work.

On environment variables, since the heading names them: they are a real improvement over hard-coded values and they are not a safe destination. Environment variables appear in process listings, are inherited by child processes, are captured in crash dumps and error reports, are frequently dumped by debug endpoints, and are visible in orchestrator manifests. Mounted secret files with restrictive permissions are better, and fetching directly from the secret manager in application code is better still.

When a secret does leak, the response is rotate immediately, then investigate. Deleting the commit, the image or the message is not sufficient — assume it was copied. Pair this with automated secret scanning in repositories and pipelines so leaks are caught at the point of introduction.

Classification driving protection, so effort lands where the data justifies it

The organising principle that makes all of the above proportionate.

Data classification assigns each dataset a sensitivity level — commonly public, internal, confidential, restricted — and each level carries defined handling requirements: encryption, key ownership, access control, retention, where it may be stored, and how it is disposed of.

Why it matters practically: without it, an organisation either applies the strictest controls everywhere (expensive, slow, and eventually circumvented) or applies weak controls everywhere (cheap until it is not). Classification lets customer-managed keys, strict access review and long retention go to the data that warrants them, and lets the public marketing site be treated as a public marketing site.

Making it work:

• Classify at creation, and record it as a tag — which connects to objectives 1.8 and 4.1, because tags are how automation finds things.
• Automate discovery. Data classification services scan storage for patterns that look like card numbers, national identifiers or health data, and find sensitive data where it should not be — which is how organisations discover that a copy of production was loaded into a development bucket.
• Derive the controls from the class, automatically where possible. If classification:restricted implies a customer-managed key, private access only, seven-year retention and quarterly access review, that should be enforced by policy rather than by memory.
• Classification drives the objectives elsewhere too: RPO and RTO (objective 3.2), retention (objective 3.1) and residency (objective 4.4) all follow from it.

The related control is data loss prevention, which inspects data in motion and at rest for classified content leaving where it should not — an email with card numbers, an upload to an unapproved destination, a bucket made public containing restricted data.

What to take into the exam

• At rest protects against media and raw storage exposure, not against an attacker with valid credentials. Enforce TLS internally, not just externally. Confidential computing protects data in use, including from the provider.
• Envelope encryption is why rotation is cheap: data keys are re-encrypted, not the data.
• Provider-managed = convenience. Customer-managed = control, key audit trail, and the ability to crypto-shred. Customer-supplied = maximum control, permanent loss if lost.
• Rotation does not re-encrypt existing data. Disable first (reversible); destruction is permanent and is the strongest deletion control.
• A key missing in the destination region breaks cross-region restore.
• Secrets go in a secret manager, fetched at run time by platform identity. Environment variables leak through process lists, crash dumps and debug endpoints; mounted files are better. A leaked secret is rotated, not deleted.
• Classification drives protection — and it is recorded as a tag so automation can enforce it.