The Cloud Shared Responsibility Model Is Not Optional

Every major cloud breach in the last five years has one thing in common: the organization that got breached thought their cloud provider was handling something that was actually their responsibility. The shared responsibility model isn't a suggestion. It's a contract, and misunderstanding it has cost companies hundreds of millions of dollars.

#The Core Principle

Cloud providers secure the infrastructure: the physical data centers, hypervisors, managed service internals, and the global network. You secure everything you put on that infrastructure: your data, your configurations, your access controls, and your applications.

AWS puts it simply: they handle "security of the cloud." You handle "security in the cloud."

#What Changes by Service Model

Your responsibility shifts depending on how much abstraction you're using:

#IaaS: You Own Almost Everything

With services like EC2, Azure VMs, or GCE instances, you're responsible for:

# OS patching — this is on you
sudo apt update && sudo apt upgrade -y
 
# Firewall rules — default-deny, open only what's needed
ufw default deny incoming
ufw allow 443/tcp
ufw enable
 
# Disk encryption — not always on by default
# You must verify and enable it

The provider gives you a virtual machine. Everything from the OS up is yours to secure.

#PaaS: Shared But Not Gone

With managed services like RDS, Cloud Functions, or App Engine, the provider handles OS patching and runtime updates. But you still own:

• Access controls: who can connect to your RDS instance
• Encryption configuration: enabling encryption at rest isn't always the default
• Network exposure: a publicly accessible database is still your mistake
• Backup strategy: managed doesn't mean backed up the way you need

resource "aws_db_instance" "main" {
  engine               = "postgres"
  instance_class       = "db.t3.medium"
 
  # YOUR responsibility: encryption at rest
  storage_encrypted    = true
  kms_key_id           = aws_kms_key.db.arn
 
  # YOUR responsibility: not making it public
  publicly_accessible  = false
 
  # YOUR responsibility: backup retention
  backup_retention_period = 14
}

#SaaS: Less Surface, Same Core Duties

Even with SaaS products, you're responsible for:

• User access management: who has admin access to your SaaS tools
• MFA enforcement: your provider offers it, you must enable it
• Data classification: knowing what sensitive data lives in the service
• Integration security: API keys and OAuth tokens connecting your systems

#Real Breaches That Prove the Point

#Capital One (2019)

A misconfigured WAF on AWS allowed an attacker to exploit an SSRF vulnerability and access S3 buckets containing 106 million customer records. The root cause was overly permissive IAM roles. The compromised service had access to every S3 bucket in the account.

AWS infrastructure was not compromised. Capital One's IAM configuration was.

Cost: $80 million fine + $190 million settlement.

#Twitch (2021)

125GB of internal data (source code, internal tools, and creator payout information) was leaked due to a misconfigured server. The data was stored on infrastructure Twitch controlled and was responsible for securing.

Lesson: your provider secures the storage service. You secure what you put in it.

#The Four Things You Must Get Right

#1. IAM: Least Privilege, Always

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

Rules to enforce on every project:

• No wildcard permissions. "Action": "*" is never acceptable in production.
• MFA on every human account. No exceptions.
• IAM roles over static credentials. EC2 instance profiles, not access keys.
• Regular access reviews. Permissions accumulate; prune them quarterly.

#2. Encryption: At Rest and In Transit

# Verify S3 bucket encryption
aws s3api get-bucket-encryption --bucket my-bucket
 
# Check if RDS encryption is enabled
aws rds describe-db-instances \
  --query "DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]" \
  --output table

#3. Network Configuration

# Find security groups with 0.0.0.0/0 on sensitive ports
aws ec2 describe-security-groups \
  --filters "Name=ip-permission.cidr,Values=0.0.0.0/0" \
  --query "SecurityGroups[*].[GroupId,GroupName]" \
  --output table

A security group open to 0.0.0.0/0 on port 22 or 3389 is a breach waiting to happen. These should be audited weekly.

#4. Patching: The IaaS Tax

If you run IaaS, OS patching is your problem:

#!/bin/bash
# Automated security patching for Ubuntu servers
apt update
apt upgrade -y --only-upgrade
# Log what was updated
apt list --upgradeable 2>/dev/null | tee /var/log/patch-$(date +%F).log

For managed services, the provider handles this. That's one of the strongest arguments for using PaaS/SaaS when you can.

#Operationalizing the Model

Understanding the model isn't enough. You need to enforce it continuously:

• Infrastructure as Code: define security controls in Terraform/Pulumi so they're versioned and reviewable
• Policy as Code: use AWS Config Rules, Azure Policy, or OPA to automatically detect misconfigurations
• CSPM tools: AWS Security Hub, Azure Defender, or third-party tools like Wiz scan continuously for compliance drift
• Audit logging: CloudTrail, Azure Monitor, and GCP Audit Logs should be enabled on every account, with alerts on high-signal events

#Key Takeaways

1. Your provider secures their infrastructure. You secure your configurations. Non-negotiable.
2. The less abstraction you use, the more you own. IaaS means you own almost everything.
3. IAM misconfigurations cause the majority of breaches. Invest time here first.
4. Automate compliance checking. Manual audits don't scale and drift happens between reviews.
5. When in doubt, assume it's your responsibility. That mindset prevents the gaps that cause breaches.