Cloud Foundations & the Shared Responsibility Model

Moving to the cloud is rarely a security upgrade by accident. The hyperscalers operate hardware, hypervisors and global networks better than almost anyone — but you inherit a stack split horizontally between provider and tenant, and every breach headline in the last decade has lived on the tenant side of that line. This chapter installs the foundations: who owns what, how the cloud changes the threat model, and the four heuristics you will reach for in every architecture review for the rest of the course.

The Shared Responsibility Model

The single most useful diagram in cloud security is also the one most often glossed over. AWS, Azure and GCP all publish a near-identical model: the provider is responsible for security of the cloud — the data centres, hypervisors, host OS, the global fibre — and the customer is responsible for security in the cloud — the workload, the data, the configuration, and the identities. The line between them shifts depending on the service model.

What is always yours

Whatever the service tier, three things never cross the line. Data — what you put into the platform, including its classification, retention and encryption keys when you choose to manage them. Identity — who you grant access to, with what privileges, for how long. Configuration — every toggle the provider exposes, from S3 bucket ACLs to Lambda execution roles to CloudFront origin policies. Every public-bucket headline of the last decade was a configuration failure on the customer side of the line.

The IaaS / PaaS / SaaS gradient

On IaaS (EC2, Compute Engine, Azure VM) you still patch the OS, manage the kernel, and run the firewall agent. On PaaS (Cloud Run, App Service, AWS Fargate) the runtime is provider-operated; you bring code and configuration. On SaaS (Workspaces, M365, Salesforce) you own only the data, the users, and the integration settings. The threats change as you move up — kernel exploits become irrelevant on Fargate but token theft and OAuth scope abuse become primary.

The Cloud Threat Landscape — Misconfiguration Dominates

Year after year — Verizon DBIR, IBM Cost of a Data Breach, Mandiant M-Trends, the CSA's Top Threats reports — the same picture appears: in the cloud, exploitation of provider infrastructure is rare; customer misconfiguration and credential compromise account for the overwhelming majority of incidents. The hypervisor escape exists in research papers; the public S3 bucket exists in last week's news.

The Capital One breach (2019) is the textbook study: a misconfigured WAF allowed an attacker to make the EC2 instance perform an SSRF call to the IMDS, retrieve the role's credentials, and then call S3 with broad read permissions. Three customer-side mistakes stacked — WAF rule, IMDS version, role scope — and the provider's part of the stack was untouched. Read the post-mortems: each individual mistake felt small.

The MITRE ATT&CK Cloud matrix

For mapping attacks, MITRE maintains a Cloud sub-matrix of ATT&CK with techniques specific to IaaS, SaaS, Office 365 and Azure AD. Worth bookmarking. Notable cloud-flavoured techniques include T1078.004 (valid cloud accounts), T1098.001 (additional cloud credentials — adding a new access key to a compromised principal), T1530 (data from cloud storage), T1538 (cloud service dashboard), and T1552.005 (credentials from instance metadata). When we get to detection on Day 6, these IDs will be the spine of every rule we write.

Four Heuristics That Survive Any Provider

Cloud APIs change every quarter. The heuristics below are mostly older than the cloud and will outlive whichever console you log into next.

1) Least privilege — and time-bound

Grant the smallest set of actions on the smallest set of resources for the shortest time. The cloud version adds time: long-lived access keys are inherently worse than short-lived STS credentials, and standing admin is worse than just-in-time elevation through a break-glass workflow. Day 1 PM is entirely about how to express this in IAM without making the platform unusable.

2) Blast-radius reduction — segment by failure domain

Assume any single principal, network segment or service will be compromised. Design so the explosion is contained. The strongest tool here is the account boundary — separate AWS accounts, GCP projects or Azure subscriptions per environment, per workload class, per blast radius. A misconfigured policy in prod-payments cannot speak to prod-analytics if they live in different accounts with no shared roles. VPC segmentation, namespaces and service meshes layer below that.

3) Identity is the new perimeter

The corporate firewall used to define inside vs outside. In the cloud, every API call originates from a principal — a user, a role, a workload identity — and is signed and authorized at the API. If your identity story is broken, no amount of network segmentation saves you. Conversely, with strong identity you can run flat networks where every hop is mutually authenticated. This is the core thesis of Zero Trust, NIST SP 800-207 and BeyondCorp; we will spend Day 2 PM on it.

4) Audit by default, immutable, central

Cloud APIs are uniformly logged — CloudTrail, Cloud Audit Logs, Azure Activity Logs. Turn them on for every account, ship them to a separate logging account with object-lock or write-once storage, and retain long enough to cover the typical breach dwell time (Mandiant M-Trends 2024 reported a global median of about 10 days, but cloud-specific incidents often span months because credentials are reused). If logs are retained only in the same account that is compromised, you have no logs.

The CSP Maturity Pyramid

Where is your organization on the journey? A useful framing — popularized by the AWS Well-Architected Security pillar and echoed by GCP's Cloud Adoption Framework — is a five-level maturity model. Most teams skip levels and pay for it later.

• L1 — Inventory. Every account/project/subscription is known, tagged with owner, environment, data classification. Asset registry is automated. Without this, every later level lies.
• L2 — Identity hygiene. No long-lived root keys; SSO with MFA for humans; workload identity (IRSA, Workload Identity Federation) for services; baseline IAM guardrails (SCPs, Org Policies).
• L3 — Network & data. Default-deny SGs, private endpoints for managed services, KMS-managed keys with rotation, encryption-in-transit everywhere.
• L4 — Detection & response. Centralised CloudTrail/audit logs, guardrail-grade detections (GuardDuty, Security Command Center, Defender), runtime detection (Falco, eBPF), 24×7 on-call.
• L5 — Adaptive. Continuous control monitoring (CSPM/CNAPP), purple-team exercises, blast-radius testing, paved-road enforcement at PR time.

The Architecture Review Lens

By the end of this course, every chapter loops back here. When you sit in front of a new architecture diagram, ask the same questions in the same order. They will rarely all be answered well; the gaps tell you where to focus.

1. Trust boundaries. Where does data cross from one trust zone to another? (Internet → VPC, account → account, namespace → namespace, principal → principal.) Each boundary should authenticate, authorize and log.
2. Identity model. Who or what is calling each API? Are credentials long-lived or short-lived? Is the principal scoped to the resources it actually touches?
3. Blast radius. If this component is compromised, what can the attacker reach? Different account? Different region? Same row in the database? Map it explicitly.
4. Data path. Where does sensitive data live, in motion and at rest? Whose key encrypts it, and who can use that key?
5. Detection. What event would tell you this system is being abused? Where would that event land? Who is paged?