The Shared Responsibility Model

The shared responsibility model is the foundational concept of cloud security. It defines exactly who secures what—and misunderstanding it is behind most cloud breaches.

The Core Principle

Cloud providers secure the cloud infrastructure itself. You secure what you put in it and how you configure it.

Provider Responsibilities (Security OF the Cloud):

• Physical data center security
• Hardware and hypervisor
• Network infrastructure
• Storage systems
• Global backbone

Your Responsibilities (Security IN the Cloud):

• Identity and access management
• Data encryption and protection
• Operating system configuration
• Application security
• Network configuration
• Firewall rules

How It Varies by Service Model

The split changes dramatically based on which service model you use:

Layer	IaaS (EC2, VMs)	PaaS (Lambda, App Service)	SaaS (S3, DynamoDB)
Data	Customer	Customer	Customer
Application	Customer	Customer	Provider
Runtime	Customer	Shared	Provider
OS	Customer	Provider	Provider
Virtualization	Provider	Provider	Provider
Hardware	Provider	Provider	Provider

The more managed the service, the less you're responsible for—but you're ALWAYS responsible for:

• Your data
• Your access controls
• Your configurations

Provider-Specific Models

AWS Shared Responsibility

┌─────────────────────────────────────────────────────┐
│                    CUSTOMER                          │
│  Data, Platforms, Apps, Identity, Encryption        │
│  OS, Network Config, Firewall, Client-side Encryption│
├─────────────────────────────────────────────────────┤
│                      AWS                             │
│  Hardware, Software, Networking, Facilities         │
│  Compute, Storage, Database, Networking Services    │
│  AWS Global Infrastructure, Regions, AZs, Edge      │
└─────────────────────────────────────────────────────┘

Azure Shared Responsibility

Azure uses the same model but emphasizes "shared controls"—areas where both parties have responsibilities:

• Identity management: Microsoft secures Entra ID; you configure it correctly
• Data classification: Azure provides tools; you classify and protect your data
• Endpoint protection: Azure secures their endpoints; you secure yours

GCP Shared Fate

Google introduced the "shared fate" concept, acknowledging that customer security failures hurt everyone:

• GCP provides secure-by-default configurations
• Security Command Center offers continuous monitoring
• Google actively helps customers fix misconfigurations

Common Responsibility Confusion

These misunderstandings cause breaches:

Misconception	Reality
"AWS encrypts my data"	AWS provides encryption tools; YOU must enable them
"My S3 bucket is private"	Default changed to private in 2023, but check YOUR settings
"The firewall protects me"	YOU configure security groups and NACLs
"Updates are automatic"	Only for managed services; EC2 is YOUR responsibility
"My data is backed up"	YOU configure backups; default is often nothing

The Configuration Trap

Here's where 80% of breaches originate—misconfigurations:

# This S3 bucket policy looks reasonable...
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": "*",           # DANGER: Anyone on the internet!
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::my-bucket/*"
    }]
}

The provider gave you the tools. They gave you the defaults (now secure by default for S3). But YOU created this policy. YOU exposed your data.

Your Security Checklist

Based on the shared responsibility model, you must always verify:

1. Identity: Are IAM policies least-privilege?
2. Data: Is sensitive data encrypted (at rest AND in transit)?
3. Network: Are security groups properly restrictive?
4. Logging: Is CloudTrail/Activity Log enabled?
5. Configuration: Are resources using secure defaults?

The provider handles the infrastructure. The configuration is on you.

Next, we'll examine the specific threats targeting cloud environments. :::