Cloud data exposure, leakage and remanence

Why this matters

Objective 2.2 is about data in someone else's infrastructure, and it has an unusual property: its failures are overwhelmingly caused by configuration rather than by attack. The public record of cloud data incidents is dominated by storage that was made readable, snapshots shared too widely, and databases exposed with default credentials — not by exploitation of the provider.

That changes what the right control is, and CAS-005 tests whether you know it. The instinct from an on-premises background is to add a perimeter control. The effective answer in cloud is almost always continuous configuration assessment: something that continuously asks whether any resource is exposed, rather than something that inspects traffic at a boundary that no longer bounds anything.

The second theme is that data leaves by routes nobody designed. Logs, backups, analytics exports and support bundles all carry copies of data out of its intended container, and each is created by a system doing its job correctly.

The lesson

Public object storage: the single most repeated cloud data incident, and its causes

Object storage exposed to the internet is the most frequently repeated cloud incident, and the causes are consistent enough to enumerate.

• Made public deliberately for a legitimate reason, then forgotten. A bucket serving a website is public by design; a bucket that once served one and now holds exports is public by accident of history.
• Made public to solve an access problem quickly. Someone could not get permissions working, opened it temporarily, and the temporary state persisted. This is the commonest single cause and it is a symptom of access management being too slow.
• Broad grants that are not obviously public. A permission granted to "all authenticated users" of the provider means any account on that provider, not any account in your organisation — a distinction that has caused real incidents.
• Resource policies that over-reach, such as a wildcard principal added to make an integration work.
• Inherited or default configuration in an account created outside the organisation's guardrails.

The layered answer, in order of strength:

1. Organisational guardrails that prevent public access at the account or organisation level, so an individual cannot make a resource public even with permissions on it. This is preventative and it is the strongest control.
2. Policy as code in the pipeline, from lesson fourteen, rejecting a plan that creates public access.
3. Continuous configuration assessment across every account and region, alerting on transition rather than reporting state.
4. External validation — checking your own estate from outside, as an attacker would, because it is the only method that does not depend on your inventory being complete.

That last point connects to lesson five: an assessment tool enumerating resources through your accounts cannot see an account nobody knows about. A scenario where exposure was found by a researcher rather than by a well-run assessment programme usually turns on an account outside the organisation structure.

Leakage paths that are not misconfiguration: logs, backups, analytics exports and support bundles

Data also leaves through systems working exactly as designed, and these paths are rarely reviewed because nothing is broken.

Logs. Applications log request bodies for debugging, and request bodies contain personal data, tokens and sometimes payment details. Those logs are shipped to a platform with different access control and different retention from the source system, and are often readable by a much wider group. The control is redaction at the point of emission plus classification of the logging platform to match the most sensitive data it could receive.

Backups. A backup of a classified system is data of that classification. It frequently lives in a different account, under different access control, with a retention that exceeds the data's own — the point lesson seven made about retention schedules. Backups are also commonly excluded from data-deletion processes, so a record deleted on request persists in restorable form.

Analytics and data warehouses. Operational data is copied into an analytics estate where access is broad by design, joins recombine fields that were separated for a reason, and the original classification does not travel with the copy. This is where a well-governed production system quietly acquires a poorly-governed twin.

Support bundles and diagnostics. Diagnostic exports contain configuration, logs and sometimes live data, and they are routinely sent to a vendor over a channel nobody classified, by an engineer resolving an outage.

Third-party integrations and browser extensions, which hold delegated access to corporate data — the consent grants from lesson thirteen.

The architectural response is to treat every one of these as a data flow crossing a trust boundary, which is exactly lesson ten's method. If the flow is on the diagram, it gets classification, controls and an owner. The reason these paths persist is that nobody draws them.

Data remanence in shared infrastructure and what a provider can and cannot promise

Remanence is data that persists after it was supposed to be gone. In shared infrastructure, the question becomes what happens to your data on hardware you do not control and cannot inspect.

What a provider can credibly promise, and typically does:

• Logical erasure on deallocation, so a storage block released by one tenant is zeroed or otherwise made unreadable before another tenant receives it.
• Encryption by default with per-tenant keys, which is the mechanism that makes the promise meaningful: even imperfect erasure yields ciphertext.
• Media destruction at end of life, evidenced through their own audit and attestation programme.

What a provider cannot give you:

• Physical verification. You cannot inspect the media, and a right-to-audit clause with a hyperscale provider does not extend to walking the floor. You rely on their attestation — which brings back lesson eleven's point about reading what the attestation actually covers.
• Certainty about every copy. Replication, caching and backup mean your data existed in more places than you directed, and deletion timelines for all of them are the provider's published behaviour rather than something you observe.

The practical control, and the answer scenarios reward: customer-managed encryption keys, so that destroying the key renders every copy unreadable regardless of where it sits or how thoroughly it was erased. This is cryptographic erase, covered properly in domain 3, and in cloud it is the only erasure primitive a customer can actually exercise. Its precondition is that the data was only ever encrypted with keys you control — which is a design decision taken at the start, not a remediation available later.

For regulated data with strict destruction requirements, the remaining options are a provider service offering dedicated hardware with contractual destruction commitments, or keeping the data out of shared infrastructure. That is a cost decision the classification table from lesson seven should already frame.

Insecure storage: unencrypted volumes, snapshots copied across accounts, forgotten regions

Four specific failure modes that recur in scenarios, each with a clean control.

Unencrypted volumes and databases. Encryption at rest is usually a default now, but defaults apply to new resources and estates contain old ones. The control is an assessment rule covering every resource type in every account, and a guardrail preventing creation without it.

Snapshots. These are the most under-governed object in a cloud estate. A snapshot of an encrypted volume may be shareable, and sharing it with another account grants that account the data. Snapshots are also created routinely, rarely deleted, and frequently excluded from the classification applied to the volume. Three rules: snapshot sharing restricted by guardrail, lifecycle policies that expire them, and snapshots inheriting the source's classification explicitly.

Cross-account copying. Data moved to another account — for analytics, for a supplier, for a migration — leaves the controls of the originating account. The destination is frequently less governed, and the copy is frequently permanent. Treat a cross-account copy as an export and govern it as one.

Forgotten regions. Estates that operate in two regions frequently have resources in six, from experiments, defaults, and services that replicate without being asked. Resources in an unmonitored region are outside assessment, outside logging, and outside anybody's mental model — and they may also breach a data residency obligation, turning a hygiene problem into a compliance one. The control is a guardrail restricting which regions may be used at all, which is both simpler and stronger than monitoring every region.

The pattern uniting all four: a control applied to the primary resource that does not follow its copies. That is the same shape as lesson seven's lower environments and lesson five's decommissioning, and recognising it is worth more than memorising the four instances.

Detecting exposure continuously rather than discovering it in a news article

The closing idea, and the one that distinguishes a mature cloud programme.

Cloud configuration changes constantly and can be changed by many people through many routes — console, API, pipeline, a third-party tool with delegated access. A point-in-time assessment describes a state that may not survive the afternoon. So the requirement is continuous, and it has four parts:

• Complete enumeration, across every account, subscription and region, driven from the organisation structure rather than from a list somebody maintains. Completeness is the property that fails first and silently.
• A defined rule per exposure type, machine-evaluable, versioned and reviewed — the same discipline as policy as code, applied to the running estate rather than to the plan.
• Alerting on transition, delivered to the owner of the resource, not a dashboard percentage. The useful event is this became public today.
• A measured time to remediate, because the exposure window is what determines whether the incident is material and notifiable.

Two additions raise the bar further. External validation — scanning your own public surface from outside, and monitoring certificate transparency and provider-hosted endpoints — catches what internal enumeration misses, which is precisely the resources outside your inventory. And honeytokens placed in sensitive stores give an unambiguous signal if the data is ever accessed from an unexpected place, which is one of the few detections that works when every configuration control has already failed.

The scenario shape to recognise: an organisation with encryption everywhere, a strong perimeter, and data exposed for eleven months through a storage container nobody assessed. Nothing was attacked. Nothing alerted, because nothing was watching for the state changing.