Encryption keys in the cloud, and who actually holds them

Why this matters

"The data is encrypted" is the most common and least informative statement in cloud security. Almost all cloud data is encrypted at rest by default, and that fact defends against a narrow threat: someone obtaining the physical media. Against every threat that matters more — a compromised credential, an over-permissive policy, a malicious insider at the provider, a lawful demand served on the provider — what decides the outcome is who can cause a decryption to happen.

So the examinable question in this objective is never "is it encrypted" but "who holds the key, and who can use it". CAS-005 scenarios are written to that distinction: they describe a requirement about who must be unable to read the data, and the correct answer is the key model that makes that true.

This is also one of the places where an architectural decision cannot be retrofitted cheaply. Choosing a key model after the data exists means re-encrypting everything, which is why it belongs in the architecture domain rather than in engineering.

The lesson

Provider-managed, customer-managed and customer-supplied keys, and the threat each removes

Four models, in increasing order of customer control and operational burden.

Provider-managed keys. The provider creates, stores, rotates and uses the keys. The customer configures nothing beyond "encryption on".

• Removes: risk from physical media theft and from disposal of failed drives.
• Does not remove: anything involving credentials or policy in your own account, because the service decrypts transparently for any authorised caller. It also does not constrain the provider.
• Right for: data where the classification does not demand more, which is most data in most organisations.

Customer-managed keys. The key lives in the provider's key management service but is created and controlled by the customer: you set its policy, its rotation, who may use it, and you can disable or destroy it.

• Adds: a second, independent authorisation check. A caller needs permission on the data and permission on the key, which is a genuine separation of duties, and it means a storage-level misconfiguration alone does not yield plaintext.
• Adds: cryptographic erase as a real capability, and an audit trail of every key use — which is often the most valuable part, because it shows who decrypted what and when.
• Costs: key lifecycle management, and the availability risk that a key policy error takes an application offline.

Customer-supplied keys. The customer generates the key elsewhere and provides it with each request; the provider uses it and does not retain it.

• Removes: the provider holding your key material at rest.
• Costs: you must supply the key on every operation, which limits which services can be used and puts the availability of your data entirely on your own key infrastructure.

Hold-your-own-key / external key store. The key never leaves your infrastructure; the provider calls out to your key service for each cryptographic operation.

• Removes: the provider's ability to decrypt without your live participation, which is the strongest position available — and the strongest answer to a scenario about a third party compelling the provider.
• Costs: the highest. Your key service is now in the availability path of your cloud data, latency is real, and service support is limited.

The selection rule worth memorising: choose the model by naming who must be unable to decrypt. If the answer is "nobody outside the account", customer-managed suffices. If it is "not the provider, ever, without us knowing", you need the key outside their control.

Key hierarchies: envelope encryption, data keys and key-encryption keys

Bulk data is not encrypted directly with a key held in a key management service, and understanding why explains most of how cloud encryption actually works.

Envelope encryption works in layers. A data encryption key encrypts the data itself — fast, symmetric, generated per object or per volume. That data key is then encrypted by a key encryption key, which lives in the key management service and never leaves it. What is stored alongside the ciphertext is the wrapped data key.

To read the object, a caller sends the wrapped data key to the key service, which — if policy permits — returns the unwrapped data key, and the caller decrypts. Three consequences follow, and each is examinable:

• The key service never handles bulk data, so it is not a throughput bottleneck and the data never traverses it.
• Rotating the key encryption key is cheap: re-wrap the data keys, leave the data untouched. Rotating the data keys means re-encrypting, which is why "rotation" in cloud documentation usually means the former.
• Every unwrap is an authorisation decision and an audit event. This is the mechanism behind the key-use audit trail, and it is why customer-managed keys give visibility that provider-managed keys cannot.

Above the key encryption key sits a root key, usually in hardware, which is where the chain terminates. The hierarchy exists so that the highest-value secret is used rarely and never leaves its boundary.

Grasping this also explains a common confusion: disabling a key does not scramble stored data. The ciphertext is unchanged; what stops is the ability to unwrap the data keys. Re-enable the key and the data is readable again, which is what makes disable a safe reversible step and destroy an irreversible one.

HSM-backed keys, external key stores, and hold-your-own-key arrangements

Where the key material physically lives, and what each option buys.

Software-backed keys in a managed key service. Key material is protected by the provider's own mechanisms and never exposed through the API. Adequate for most classifications and the cheapest option with customer control.

HSM-backed keys. Key material is generated and used inside certified hardware security modules, and cannot be exported. The gain is assurance about extraction — including by the provider's own operators — and a validated certification level that some obligations require by name. This is frequently a compliance-driven choice rather than a risk-driven one, and recognising that is useful: when a scenario cites a regulation requiring validated hardware, the answer is the HSM option regardless of the risk analysis.

Dedicated HSM. A single-tenant device allocated to you, giving control over its configuration and operators at substantially higher cost and operational burden — you become responsible for its availability, backup and quorum procedures.

External key store. The provider's key service is a proxy to a key service you run, so cryptographic operations require a live call into your infrastructure. This delivers the strongest separation and introduces a hard dependency: if your key service is unavailable, the data is unavailable. That trade — availability for control — is the examinable point, and scenarios describing a requirement for provider-independent control should also make you state the availability consequence.

Bring your own key is a distinct and weaker idea often confused with the above: you generate key material and import it into the provider's key service. You control the origin of the key, and the provider still holds it. It satisfies obligations about key generation and does not satisfy obligations about the provider being unable to decrypt.

Rotation, revocation and the blast radius of a destroyed key

Key lifecycle is where cloud encryption designs fail operationally, and all three operations need thinking through before they are needed.

Rotation limits the amount of data protected by any single key and the window in which a compromised key is useful. In envelope schemes, rotating the key encryption key re-wraps data keys and leaves ciphertext untouched, which is why automatic annual rotation is cheap and usually correct. Rotation that requires re-encryption should be planned, not automated, because on a large data set it is a project.

The examinable subtlety: old key versions must be retained to decrypt data encrypted under them. Rotation adds a version and does not remove the ability to read history. A design that deletes previous versions on rotation has built an outage.

Revocation and disable. Disabling a key is the emergency control: it stops all decryption immediately, is reversible, and is the correct first response to a suspected key compromise. It is also an outage for everything using that key, which is precisely why the blast radius of a key is an architectural decision. One key for the whole estate makes the emergency response unusable; a key per data classification, per environment, or per business service keeps the response proportionate.

Destruction is irreversible, subject to a mandatory waiting period in most services specifically because it is irreversible, and it is the mechanism of cryptographic erase. Two preconditions decide whether it achieves anything: all copies of the data must have been encrypted with that key and no other, and no plaintext copy may exist elsewhere — which returns to the leakage paths of the previous lesson. Destroying a key while an unencrypted analytics copy exists achieves nothing but the loss of the original.

Two availability controls belong with this. Key policy changes should be treated as production changes, because a misconfigured policy is indistinguishable from an outage. And key material for external stores needs backup with a quorum procedure, since losing it is unrecoverable data loss that no provider can help with.

Reading a scenario for who must be unable to decrypt, which decides the model

The decision procedure, stated as a sequence, because these scenarios are decidable once you look for the right sentence.

Who is the threat the requirement names? Not "is this sensitive", but which party must be excluded.

Then state the cost you have accepted, because the answer is incomplete without it. Customer-managed keys add lifecycle work and a new outage mode. External key stores put your infrastructure in the availability path of your data. A scenario offering a technically stronger option and a simpler one is usually testing whether you will take the strongest without regard to whether the requirement asked for it — and on this exam, proportionality is the professional answer.

Finally check the preconditions hold. A key model only delivers what it promises if every copy of the data is inside it. The analytics extract, the backup in another account, the support bundle and the lower-environment copy from lesson seven are all outside the key boundary unless somebody put them inside it deliberately.