Shared Responsibility Intro
Understand the critical boundary between what your cloud provider secures and what you must secure yourself.
This lesson is purely conceptual — no AWS usage required.
How responsibility is split
The provider secures the cloud infrastructure, and you secure what you put in and configure in the cloud.
1) Why this lesson matters
Many people assume: “If it’s cloud, it’s secure by default.”
That assumption causes problems. Cloud providers give strong tools and secure infrastructure, but you can still:
- Make data public by mistake
- Give overly broad permissions
- Expose a service to the internet unintentionally
- Forget to monitor or rotate credentials
The shared responsibility model helps you avoid that trap by making the boundaries clear.
2) What the provider is responsible for (security of the cloud)
At a high level, providers operate and protect:
- Physical data centers (buildings, power, physical access)
- Hardware (servers, storage devices)
- Core networking and the virtualization layer that runs cloud services
In practice: You do not guard the data center door. You do not replace failed disks. You do not patch the provider’s core infrastructure.
3) What you are responsible for (security in the cloud)
You generally control and must protect:
- Your identities (accounts, users, roles) and permissions
- Your data (what you store, where you store it, who can access it)
- Your configurations (public vs private, firewall rules, security settings)
- Your application code and secrets
- Monitoring and alerting that your system needs
A useful anchor: you always own your data and identities, and you must protect them.
4) Responsibilities change with IaaS vs PaaS vs SaaS
The more the provider manages, the more they can secure for you. But you never hand off responsibility for your data and access controls.
- IaaS: You manage the most (often OS, patching, runtime, app)
- PaaS: You manage your app and configuration, provider manages more platform
- SaaS: You mainly manage usage, data, and access settings
“Who handles what?” cheat sheet
Cheat Sheet
Who handles what?
Every layer mapped to who owns it across SaaS, PaaS, and IaaS.
| Layer / Task | SaaSFully managed for you | PaaSYour app, their infra | IaaSYou manage almost all |
|---|---|---|---|
| Infrastructure | |||
| Data center physical security | Provider | Provider | Provider |
| Hardware and core network | Provider | Provider | Provider |
| Virtualization layer | Provider | Provider | Provider |
| Host operating system | Provider | Provider | Provider |
| Platform | |||
| Guest OS (your VM's OS) | Provider | Provider | You |
| Runtime / middleware | Provider | Provider | You |
| Application | |||
| Application code | Provider | You | You |
| App configuration | Shared | You | You |
| Cross-cutting | |||
| Identity and access | Shared | Shared | Shared |
| Data classification and access | You | You | You |
| Encryption and key handling | Shared | Shared | Shared |
| Monitoring what you build | Shared | You | You |
Micro-activity: Sort responsibilities
Who owns this responsibility?
For each item, choose Provider (security of the cloud), You (security in the cloud), or Shared (both contribute).
Physical security of the data center
Deciding whether a storage bucket is public or private
Creating user accounts and controlling permissions
Patching the operating system on a virtual machine you manage
Protecting your API keys and secrets
The provider offering logging and monitoring tools
Turning on alerts for suspicious login attempts
Encrypting data at rest
0 of 8 matched so far.
Mistakes to avoid
- Assuming “cloud = secure,” then leaving public access enabled
- Using broad admin permissions for everything
- Storing secrets in code or sharing keys
- Forgetting monitoring and alerts
- Leaving resources running with no review — idle resources accumulate charges and widen your attack surface