Cloud Fundamentals
Intermediate 15 min read Cloud Fundamentals

The Shared Responsibility Model

Where the provider's security ends and yours begins

The cloud provider secures the infrastructure; you secure what you build on it. 'It's in the cloud' is not a security strategy — the shared responsibility model draws the exact line.

shared responsibilitysecurityaccess managementpatchescompliance
Prerequisites: Cloud Service Models Regions and Availability Zones
Before we start

What you will learn

  • Draw the responsibility line for a given service model
  • Identify the customer-side controls (IAM, data, patches, config) you can't delegate
  • Map compliance artifacts to responsibilities
In 60 seconds

The provider secures the cloud (physical facilities, host, network); you secure what's in the cloud (access, data, app code, guest OS). The line shifts with the service model, but accountability for your data never transfers.

Introduction

What is this?

The shared responsibility model is the division of security duties between a cloud provider and its customer. Generally the provider secures the physical infrastructure, host OS, virtualization layer and the underlying network. The customer secures identity and access, data, applications, guest OS patching, network configuration, and compliance. As you move from IaaS to PaaS to SaaS, the provider takes over more of the stack — but the customer's obligations for data, users and configuration remain.

Motivation

Why do you need it?

  • The model stops both the 'provider owes me everything' and 'it's in the cloud so it's safe' misreads.
  • Regulators expect documented responsibility ownership per control (who patches the OS? who rotates keys?).
  • The same attack — public S3 bucket, open RDS port, leaked key — stays the customer's even under the most managed services.
  • Audits (SOC 2, ISO 27001, HIPAA) are blessed by providers, but your boundary is what you operate.
Think about it

Mental model

Imagine

Buying a house with a locked front door

Think of

The shared responsibility model

The builder (provider) ensures structure safety, electricity and plumbing. Whether you lock the door, change the locks, and who gets keys is entirely on you. The house being well-built never arms the alarm.

Mechanics

How it works

  • Provider side: physical security, fire suppression, redundant power, host/virtualization isolation, edge network controls.
  • For IaaS you manage the guest OS, runtime, applications, data and network security groups; provider manages through the hypervisor.
  • For PaaS/SaaS the provider also manages runtime + platform but you still own your data, the users and their permissions.
  • Compliance programs (e.g. SOC 2) cover which automation and controls the provider runs; your audit join covers your boundary.
  • The model is documented per service — every provider publishes a per-service responsibility matrix you should verify.

Where responsibility sits across service models.

Always yours
IaaS you manage
Provider manages
PaaS/SaaS shift
Real world

In production

  • A real incident postmortem found a data breach in a 'managed' database: the database was managed, but the customer's open security group was the leak — a customer-side control all along.
  • A SOC 2 audit splits its control list into provider-mapped and customer-mapped; the customer's evidence is everything under its own boundary.
  • A company caught violating an internal rule when a developer enabled public read on a governance-managed bucket — customer-side config, provider-side enforcement existed but wasn't used.
Guidelines

Best practices

  • Write one line per workload: 'provider patches host; we patch data-plane apps, rotating secrets every 90 days'.
  • Apply organization-level guards (allowed regions, denied public storage) so customer-side mistakes are hard to make.
  • Encrypt data at rest and in transit on your side too — provider encryption of the pipe doesn't cover your key hygiene.
  • Prove the boundary quarterly with a tabletop on 'who can see this data and who patched the guest OS'.
Watch out

Common mistakes

  • Pointing at the provider when a customer-configured open bucket leaks data.
  • Assuming a managed database is fully managed — version upgrades and parameter tuning are often still yours.
  • Skipping your own backup of data the provider hosts, because 'they have redundancy'.
  • Blaming the 'shared responsibility model' instead of documenting and testing who really does what.
Root cause analysis

Common issues

Error
SOC 2 control 'patching' always fails for the app tier
Root cause

Control was written assuming provider responsibility, but the app runs in IaaS

Fix

Split the control: provider patches host, your team patches guest OS + apps, with evidence per side.

Error
Pen test found an exposed database port
Root cause

The security group/NACL opened the port during debugging and was never closed

Fix

Follow the principle of least exposure: private subnets by default, port access scoped and timed, verified quarterly.

When things break

Debugging tips

  • When an audit or breach lands, first map the offending control to one side of the line — the fix location follows automatically.
  • Check provider compliance pages (SOC 2, ISO) before claiming a workload is 'compliant' — compliance of the pipe isn't compliance of the cargo.
  • For leaked data, check bucket policies, ACLs and access points before blaming the database service.
  • Classify who should own a control by asking: 'can the provider fix this without access to my account?'
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which control remains the customer's responsibility even under SaaS?

2

A SOC 2-compliant provider makes your workload automatically SOC 2-compliant.

Go deeper

Official documentation

AWS — Shared Responsibility Model
docs
Azure — Shared responsibility in the cloud
docs
Google Cloud — Shared responsibility
docs