5.3 Security posture and the cloud threat model

What this is and why it exists

Security in the cloud is not a mood, it is a list. This topic gives you the list — the handful of routes by which cloud accounts actually get compromised — and then asks the only question that matters: for each one, what specifically stops it in your account. If you can answer that six times, you know more about your posture than most teams do about theirs.

The vocabulary

• Threat model — the written answer to "who would attack this, how, and what would they reach".
• Attack path — a concrete sequence from an entry point to something valuable.
• Audit log — the record of every management action taken in the account: who, what, when, from where. Amazon's CloudTrail, Azure's Activity Log, Google's Cloud Audit Logs.
• Tamper-evident — stored so that alteration or deletion is detectable, even by an administrator.
• Threat detection — services that watch behaviour and raise findings: Amazon's GuardDuty, Azure's Defender for Cloud, Google's Security Command Center.
• Posture management — tooling that inspects your configuration against known-bad patterns and reports what it finds; Amazon's Security Hub is one example.
• Vulnerability scanning — checking images and dependencies against published vulnerability data.

The mental model

The real attack paths are few, and they are boring, which is precisely why they keep working.

An exposed storage bucket. Somebody made it public for a reason that made sense that afternoon. No exploit is involved; the data is served to whoever asks. Prevented by the account-level public-access block and by presigned links for genuine sharing.

A leaked key. A credential in a repository, a build log, a laptop, a screenshot. Automated scanners find published keys within minutes, and the first use is usually to start expensive machines. Prevented by workload roles instead of long-lived keys, by secret scanning on the repository, and by rotation being a rehearsed procedure.

An over-broad role. One component is compromised — an application vulnerability, a dependency, a stolen session — and the role it was given permits far more than that component ever needed. This is the step that turns an incident into a breach. Prevented by least privilege built with the read-the-denial loop, and by guardrails that cap what any policy can grant.

An unpatched image. A machine or container built from a base image nobody has updated, running a known vulnerability with public exploit code. Prevented by rebuilding from patched images on a schedule rather than patching running machines, and by scanning images in the pipeline so that the old base is a build failure rather than a discovery.

A missing second factor on a person. An administrator account with a password and nothing else, phished or reused from a breach elsewhere. Prevented by requiring multi-factor authentication for every human, especially the root or owner account.

And a public administrative port. Remote access exposed to the whole internet, found by automated scanning within minutes of the machine existing. Prevented by the firewall rules of the previous module, and by a bastion or an identity-aware access service where remote administration is genuinely needed.

Logging is the layer that makes all six visible after the fact, and there is one property to insist on. The audit log records every management action — who did what, to which resource, from which address, when — and an attacker's first competent move is to turn it off or delete the evidence. So the log must be tamper-evident: written to a separate account or project that the working account cannot modify, with retention set and deletion protected, and with an alarm on the act of turning logging off. A log an administrator can quietly erase answers the question "what happened" only when the answer is harmless.

Patching responsibility follows the shared responsibility model exactly, and the line moves with the service. On a virtual machine, everything from the operating system upward is yours. On a container platform, the host is theirs and the image contents are yours. On a managed database, the engine is theirs and the schema and access are yours. On a function, the runtime is theirs and your dependencies are yours. Write your services down in that order once, and the patching argument stops being an argument.

Finally, what posture tools cannot see, because their reports are convincing and partial. They read configuration, so they find public buckets, unencrypted volumes, over-broad policies and missing logs — genuinely valuable, and worth turning on. They do not know your business: they cannot tell which bucket is meant to be public, whether a permission is legitimate, or whether the data in a store is sensitive. And they cannot see inside your application, where injection flaws and broken access control live. Treat a clean posture report as "the obvious things are in order", never as "we are secure".

What you should now be able to explain or do

Name six attack paths by which cloud accounts are actually compromised and, for each, the specific control that stops it. Say what tamper-evident logging means concretely and why an administrator being able to delete logs defeats the purpose. Place the patching line for four different service types. State three things a posture tool finds and three it cannot.

Check yourself