Cloud Shared Responsibility Model Explained

In this tutorial, you'll learn about Cloud Shared Responsibility Model Explained. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

The cloud shared responsibility model defines which security controls the cloud provider manages and which the customer must implement, varying by service type from infrastructure-as-a-service to software-as-a-service.

What You Will Learn

How security responsibilities are divided between cloud providers and customers across AWS, Azure, and GCP, with CLI examples showing real boundary enforcement.

Why It Matters

Misunderstanding the shared responsibility model is the leading cause of cloud data breaches. When customers assume the provider secures their data, applications, or network configurations, critical gaps emerge.

Real-World Use

A financial services company encrypts all data at rest using AWS KMS with customer-managed keys. When auditors ask who is responsible for key rotation, the shared responsibility model tells them: the customer.

The Three Layers of Responsibility

Cloud providers divide security into three zones:

1. Provider-owned — physical hardware, regional data centers, network cables, hypervisors
2. Shared controls — patch management, configuration Compliance, awareness training
3. Customer-owned — data classification, identity policies, application code, network traffic encryption

The exact boundary shifts depending on the service model you choose.

Service Model Comparison

flowchart LR
  subgraph On-Premises
    A1[Applications] --- A2[Data] --- A3[Runtime] --- A4[OS] --- A5[Hypervisor] --- A6[Network] --- A7[Storage]
  end
  subgraph IaaS
    B1[Applications] --- B2[Data] --- B3[Runtime] --- B4[OS]
    B5[Hypervisor] --- B6[Network] --- B7[Storage]
  end
  subgraph PaaS
    C1[Applications] --- C2[Data]
    C3[Runtime] --- C4[OS] --- C5[Hypervisor] --- C6[Network] --- C7[Storage]
  end
  subgraph SaaS
    D1[Applications] --- D2[Data] --- D3[Runtime] --- D4[OS] --- D5[Hypervisor] --- D6[Network] --- D7[Storage]
  end
  style B1 fill:#f90,color:#fff
  style B2 fill:#f90,color:#fff
  style B3 fill:#f90,color:#fff
  style B4 fill:#f90,color:#fff
  style C1 fill:#f90,color:#fff
  style C2 fill:#f90,color:#fff

AWS Shared Responsibility

AWS secures the infrastructure that runs its services. You secure your data, platform, applications, and access.

# Check who manages an S3 bucket's encryption
aws s3api get-bucket-encryption --bucket my-secure-bucket
# Output:
# {
#   "ServerSideEncryptionConfiguration": {
#     "Rules": [
#       {"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}
#     ]
#   }
# }

AWS handles the encryption of S3's underlying infrastructure. You configure and manage the encryption settings on each bucket.

Azure Shared Responsibility

Azure uses a similar model with added emphasis on identity. Microsoft secures Azure Active Directory. You secure how you use it.

# Verify Azure policy compliance for a subscription
az policy state list --resource-group prod-rg
# Output:
# [
#   {
#     "policyDefinitionName": "audit-storage-encryption", "#     "complianceState": "NonCompliant"",
#     "resourceId": "/subscriptions/.../storageAccounts/prodstorage]
#   }
# ]

Azure policies help you enforce your side of the responsibility boundary.

GCP Shared Responsibility

Google divides security into four layers: physical, infrastructure, platform, and data. Your responsibilities grow as you move up the stack.

# Review IAM policy to verify customer-side access controls
gcloud projects get-iam-policy my-project --format=json
# Output:
# {
#   "bindings": [
#     {"role": "roles/editor", "members": ["user:admin"@mycompany".com"]},
#     {"role": "roles/viewer", "members": ["user:dev"@mycompany".com"]}
#   ]
# }

Common Mistakes

1. Assuming default encryption is enough: Default provider-managed keys protect against physical theft but not against compromised accounts. Always enable customer-managed keys for sensitive data.
2. Ignoring network configuration responsibilities: The provider secures the physical network. You secure security groups, NACLs, and firewall rules. Misconfigured security groups are among the most common cloud breaches.
3. Believing PaaS means zero security work: PaaS removes OS patching duties but you still manage data classification, identity, network access, and application vulnerabilities.
4. Overlooking shared controls like patching: Both you and the provider share responsibility for patch management. Know which workloads you must patch yourself.
5. Not documenting the responsibility split for audits: Auditors require clear evidence that you understand which controls are yours. Document every service and its responsibility boundary.

Practice Questions

1. In the shared responsibility model, who is responsible for physical data center security?
2. How does the responsibility boundary change when you move from IaaS to SaaS?
3. What customer-side obligation remains constant across all three service models?
4. Why is misconfigured S3 bucket access considered a customer responsibility?
5. How can Azure Policy help enforce your side of the shared model?

Challenge

Map the shared responsibility model for a three-tier web application running on AWS EC2 (IaaS), Azure App Service (PaaS), and GCP Cloud Functions (Serverless). For each tier, list five provider responsibilities and five customer responsibilities. Identify where the boundary shifts across the three deployments.

FAQ