Cloud Security Foundations

Every major cloud runs on a single organizing idea: the shared responsibility model. The provider secures the cloud itself — the physical data centers, the hypervisor, the network fabric, the managed-service internals. You, the customer, secure what you put in the cloud — your data, your identities, your configurations, your code. The dividing line moves depending on the service model.

The dangerous misreading is to assume "the provider handles security." They handle their half flawlessly and contractually — but a world-class hypervisor does nothing to stop you from leaving a storage bucket public or granting an over-broad role. Amazon, Microsoft, and Google all publish this model explicitly precisely because the top cause of cloud breaches lives entirely on the customer's side of the line.

Ask a beginner what threatens the cloud and they picture the provider getting hacked. In reality, breaches of the hyperscalers' own infrastructure are vanishingly rare. The overwhelming cause of cloud incidents is customer misconfiguration: a storage bucket set to public, a security group open to 0.0.0.0/0, an over-permissive IAM role, logging switched off, a database exposed without authentication.

Several forces conspire to make this the norm rather than the exception:

• Speed over safety. Cloud lets anyone spin up infrastructure in seconds, often without a security review that a physical server would have triggered.
• Defaults and sprawl. Thousands of resources, each with dozens of settings, mutate daily across many accounts. One wrong toggle hides easily.
• Complexity of IAM. Policy languages are powerful and subtle; "make it work" often means "make it too open."

Industry analyses have for years attributed the great majority of cloud security failures to customer-side misconfiguration and mistakes rather than provider flaws. The upshot is empowering: most cloud risk is yours to fix, using tools the provider already gives you.

The most underrated cloud security control is where you draw account boundaries. Each provider has its own top-level container, and that container is the natural blast radius — the boundary a compromise struggles to cross.

• AWS: the account is the isolation unit; large orgs run dozens or hundreds of accounts grouped under AWS Organizations, with guardrails via Service Control Policies.
• Azure: a subscription holds resources, all sitting under an Entra ID (formerly Azure AD) tenant that defines the identity boundary.
• Google Cloud: projects group resources under an organization node, arranged in folders.

The mature pattern is a landing zone: a multi-account structure that isolates production from development, separates workloads by team, and quarantines security tooling and logs in their own accounts. If an attacker pops a developer sandbox, sound account boundaries stop them from touching production billing, data, or identity.

Every cloud service has two distinct surfaces, and confusing them causes real incidents. The control plane is the management layer — the APIs and console you use to create, configure, and destroy resources. The data plane is the resource actually doing work — the bytes in a bucket, the queries hitting a database, the requests served by a function.

They fail in different ways and are defended differently. A control-plane compromise (stolen API credentials, an over-privileged role) lets an attacker reshape your environment: open firewalls, disable logging, snapshot a database and copy it out, or spin up crypto-mining fleets. A data-plane compromise (a public bucket, an app-layer SQL injection) leaks or corrupts the data itself without necessarily touching your account settings.

The distinction matters because your logging and controls must cover both. It is entirely possible to have flawless application security on the data plane while your control plane is wide open through leaked access keys — or vice versa.

In the cloud, the API is the attack surface. Anything you can do to your infrastructure, an attacker with your credentials can do too.

You cannot defend what you cannot see, and in the cloud "seeing" means turning on the right logs before you need them. The foundational one is the control-plane audit log — AWS CloudTrail, Azure Activity Log / Monitor, Google Cloud Audit Logs. It records every API call: who did what, from which IP, when, and whether it was allowed. After any incident, this is the first thing responders reach for.

Layered on top are managed threat-detection services that analyze this telemetry for you. Amazon GuardDuty is the canonical example: it ingests CloudTrail, VPC flow logs, and DNS logs and flags patterns like credential use from an anomalous location, communication with known-malicious IPs, or the tell-tale signs of a compromised instance. Azure and Google offer analogous services (Microsoft Defender for Cloud, Google Security Command Center).

The rule of thumb: enable audit logging in every account and region on day one, forward it centrally, and make it immutable. Logs you turned on after the breach do not exist for the breach.

Because misconfiguration is the dominant risk, an entire tool category exists to hunt for it continuously: Cloud Security Posture Management (CSPM). A CSPM tool inventories every resource across your accounts and evaluates each against a library of rules and benchmarks — CIS Foundations, provider best practices, regulatory frameworks — flagging public buckets, unencrypted volumes, disabled logging, over-broad roles, and thousands of similar findings.

Its real value is catching posture drift: the slow erosion of a secure baseline as engineers make ad hoc changes over months. A resource created securely rarely stays that way if humans keep touching it. CSPM re-checks continuously and re-flags whatever slid out of compliance.

Two organizational controls make all of this tractable at scale:

• Resource groups / hierarchy: logically grouping related resources (an Azure resource group, an AWS resource grouping, a GCP project) so lifecycle, access, and policy apply coherently.
• Tagging: attaching key–value metadata (env=prod, owner=team-x, data-class=pii) so you can attribute cost, target policy, and answer the incident-response question "what is this thing and who owns it?"