Definition
- Provider responsibility – security "of" the cloud: physical data centers, hardware, hypervisor, and managed-service control plane.
- Customer responsibility – security "in" the cloud: data, identity and access configuration, network rules, encryption settings, OS patching, and application code.
- Service model shift – with IaaS you own from the guest OS up; with PaaS the provider takes over OS and runtime; with SaaS your scope narrows to access and data.
- Never zero – in every model you always own your data and your identity configuration.
- Breach pattern – most cloud security failures are customer misconfiguration and over-permissioned identities, not provider failures.
The cloud provider is the bank building that rents you a safe-deposit box. The bank secures the vault door, walls, guards, and alarm system. But you are given the key to your own box, and you decide whether to lock it and who you hand copies to. If National Bank of India leaves a box wide open and money is stolen, that is not the vault builder's fault.
Understanding the Concepts
What is the Shared Responsibility Model?
The Shared Responsibility Model is the cloud security contract that divides duties between the provider and the customer. The provider is responsible for security of the cloud. The customer is responsible for security in the cloud.
┌──────────────────────────────────────────────────────┐ │ Customer Responsibility │ │ Application code, data, identity/access config, │ │ network rules, encryption settings, OS patching │ ├──────────────────────────────────────────────────────┤ │ Provider Responsibility │ │ Physical data centers, hardware, hypervisor, │ │ managed-service control plane, network backbone │ └──────────────────────────────────────────────────────┘
How does the dividing line shift by service model?
The exact split depends on which service model you use. With IaaS you own the most. With SaaS you own the least. But your responsibility never reaches zero.
| Layer | IaaS (EC2) | PaaS (RDS, Lambda) | SaaS (email, CRM) |
|-------|-----------|-------------------|-------------------|
| Data | Customer | Customer | Customer |
| Identity/Access | Customer | Customer | Customer |
| Application | Customer | Customer | Provider |
| Runtime/Middleware | Customer | Provider | Provider |
| OS Patching | Customer | Provider | Provider |
| Network Config | Customer | Shared | Provider |
| Hypervisor | Provider | Provider | Provider |
| Physical | Provider | Provider | Provider |
package com.bank.security;
public class ResponsibilityClassifier {
public enum Owner { CUSTOMER, PROVIDER, SHARED }
public Owner classify(String serviceModel, String layer) {
// In every model, data and identity are always the customer's
if ("data".equals(layer) || "identity".equals(layer)) {
return Owner.CUSTOMER;
}
// Physical layer is always the provider's
if ("physical".equals(layer) || "hypervisor".equals(layer)) {
return Owner.PROVIDER;
}
// OS patching: customer for IaaS, provider for PaaS/SaaS
if ("os-patching".equals(layer)) {
return "iaas".equals(serviceModel) ? Owner.CUSTOMER : Owner.PROVIDER;
}
return Owner.SHARED;
}
}
Why do most breaches happen on the customer side?
The provider's half is operated at enormous scale by dedicated security teams, independently audited, and standardized. The customer's half is bespoke: every company wires up its own buckets, roles, and firewall rules, and any one of thousands of small choices can open a hole.
Provider side: Customer side:
- Thousands of security - Bespoke per company
engineers - Any one config choice
- Independent audits can open a hole
- Standardized controls - Mistakes are silent
- Rare failures - Most breaches land here
What is misconfiguration and how does it happen?
Misconfiguration means a setting that silently exposes data. Common examples:
# WRONG: S3 bucket made public -- anyone on the internet can read bank statements
aws s3api put-bucket-acl --bucket bank-customer-statements --acl public-read
# This is the #1 cause of cloud data breaches
# CORRECT: block all public access at the account level
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# WRONG: database with a public endpoint and default password
resource "aws_db_instance" "bank_accounts" {
publicly_accessible = true # Reachable from the internet
password = "admin123" # Default password
}
# CORRECT: private subnet, strong credentials from Secrets Manager
resource "aws_db_instance" "bank_accounts" {
publicly_accessible = false
db_subnet_group_name = aws_db_subnet_group.private.name
password = data.aws_secretsmanager_secret_version.db.secret_string
}
What are over-permissioned identities?
Over-permissioned identities have far more power than they need. When that credential leaks, the blast radius is the entire account.
// WRONG: wildcard policy -- grants all actions on all resources
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}]
}
// If this credential leaks, the attacker owns the entire AWS account
// CORRECT: least-privilege policy -- only what this service needs
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::bank-customer-statements/*"
}]
}
// If this credential leaks, the attacker can only read one bucket
How do you defend against these failures?
The defenses are the inverse of the failures.
| Failure | Defense |
|---------|---------|
| Manual console edits | Infrastructure-as-code (reviewed, version-controlled) |
| Public buckets/ports | Automated posture scanning (continuous) |
| Over-permissioned roles | Least privilege, short-lived temporary credentials |
| Unencrypted data | Encryption at rest and in transit by default |
| No visibility | Audit logging everywhere (CloudTrail) |
| Accidental exposure | Guardrail policies (SCPs that block public buckets) |
// SCP guardrail: prevent anyone from creating a public S3 bucket
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": "s3:PutBucketPublicAccessBlock",
"Resource": "*",
"Condition": {
"Bool": {"s3:PublicAccessBlockConfiguration/BlockPublicAcls": "false"}
}
}]
}
What is the difference between provider-owned and customer-owned controls?
package com.bank.security;
import java.util.List;
import java.util.Map;
public class SharedResponsibilityAuditor {
public record Finding(String control, String owner, String status) {}
public List<Finding> audit() {
return List.of(
new Finding("Physical data center security", "PROVIDER", "N/A - provider managed"),
new Finding("S3 bucket public access", "CUSTOMER", "FAIL - public bucket found"),
new Finding("IAM wildcard policy", "CUSTOMER", "FAIL - admin policy on service role"),
new Finding("RDS encryption at rest", "CUSTOMER", "PASS - KMS encrypted"),
new Finding("CloudTrail logging", "CUSTOMER", "PASS - enabled in all regions")
);
// Report only customer-owned findings -- those are the real breach surface
}
}
What are common mistakes with the shared responsibility model?
# WRONG: assuming the cloud provider handles everything
"We're on AWS, so we're secure."
# AWS secures the infrastructure. You secure your data and access.
# WRONG: assuming your responsibility is the same for all services
"We patched the OS on our EC2 instances, so we're done."
# For EC2 yes, but for RDS the provider patches the OS -- you manage access and encryption.
# CORRECT: classify every control by owner and verify the customer-owned ones
# For each service, know exactly where the line falls
What should a senior engineer know?
The senior insight is that your responsibility never drops to zero. In every model you always own your data and your identity configuration. The philosophy is to make the secure configuration the only configuration that is allowed, using guardrail policies so nobody can accidentally create a public bucket or an over-privileged role.
Visual Overview
Shared Responsibility by Service Model
========================================
IaaS PaaS/Managed SaaS
(EC2) (RDS, Lambda) (Email)
┌─────────┐ ┌─────────┐ ┌─────────┐
Customer │ Data │ │ Data │ │ Data │
│ Identity │ │ Identity │ │ Identity│
│ App Code │ │ App Code │ │ │
│ Runtime │ │ │ │ │
│ OS Patch │ │ │ │ │
────────────────┤──────────┤────┤──────────┤──────┤─────────┤
Provider │ Hyper- │ │ Runtime │ │ App │
│ visor │ │ OS Patch │ │ Runtime │
│ Hardware │ │ Hyper- │ │ OS │
│ Physical │ │ visor │ │ Infra │
│ │ │ Hardware │ │ │
│ │ │ Physical │ │ │
└──────────┘ └──────────┘ └─────────┘
Where Breaches Happen
======================
Provider side (rare):
Hardened by thousands of engineers, audited, standardized
Customer side (common):
┌────────────────────────────────┐
│ Public S3 bucket │ ◀── Misconfiguration
│ Default database password │
│ Logging disabled │
│ Wildcard IAM policy │ ◀── Over-permissioned
│ Long-lived access keys │
└────────────────────────────────┘
Key Takeaway
The Shared Responsibility Model splits duties between the cloud provider and the customer. The provider secures the cloud: physical data centers, hardware, hypervisor, and managed-service control plane. The customer secures what they put in the cloud: data, identity and access configuration, network rules, encryption, and application code. The dividing line moves by service model, but your responsibility never reaches zero.
Most breaches land on the customer side because the provider's half is hardened at massive scale while the customer's half is bespoke. The two dominant failures are misconfiguration (public buckets, default passwords, logging off) and over-permissioned identities (wildcard policies that grant all actions on all resources). The defenses are infrastructure-as-code, posture scanning, least privilege, short-lived credentials, encryption by default, and guardrail policies.
At National Bank of India I put all configuration into infrastructure-as-code so settings are reviewed and version-controlled, ran continuous posture scanning to catch public buckets and open ports, and enforced least privilege with short-lived temporary credentials instead of static keys.
Remember one sentence: the provider secures the cloud infrastructure, but you always own your data, your identity configuration, and the misconfigurations that cause most breaches.
---