Shared Responsibility #

One of the biggest sources of misunderstanding and security failure when organizations migrate to cloud computing is the assumption that “since everything is already on cloud servers, all security and operational concerns are the provider’s responsibility.” That assumption is deeply wrong and dangerous. In the cloud world, security is a collaborative effort governed by a formal framework called the Shared Responsibility Model. Understanding this division of responsibility precisely isn’t just important for protecting your business’s sensitive data from leaks — it also determines how you design system architecture, choose the right cloud service type, allocate your engineering team’s workload, and respond tactically to real-world security incidents.

What Is the Shared Responsibility Model? #

The Shared Responsibility Model is a matrix dividing tasks and legal/operational responsibility boundaries between the cloud service provider and us as the customer. To make its architecture easier to understand, the model splits the security domain into two main pillars: Security “OF” the Cloud (security of the cloud infrastructure itself) and Security “IN” the Cloud (security of everything we put into and operate inside the cloud).

flowchart TD
    subgraph IN["Security 'IN' the Cloud (User / Our Responsibility)"]
        D["Data & Content (Encryption, Classification, Backup)"]
        A["Applications (Code, API, Third-Party Dependencies)"]
        I["IAM (Authentication, Least-Privilege Access, MFA)"]
        N["Network Configuration (Security Groups, Firewall, Routing)"]
    end
    
    subgraph OF["Security 'OF' the Cloud (Cloud Provider Responsibility)"]
        H["Hypervisor & Host Operating System"]
        N_Phys["Physical Network (Fiber Optics, Backbone Routers)"]
        S_Phys["Physical Server Infrastructure & Storage Arrays"]
        P["Data Center Physical Security (Building, Power, Cooling)"]
    end

Security “OF” the Cloud (Provider Responsibility) #

The cloud provider is fully responsible for the physical and virtualization foundation that supports all cloud services. As customers, we have no physical access to data center buildings, and we can’t touch the physical servers or hypervisor either. Therefore, the provider must guarantee security in the following areas:

• Physical Building Security: Protecting data center facilities from intruders, natural disasters, sabotage, and providing HVAC cooling systems and redundant power supplies (UPS and backup generators).
• Hardware Maintenance: Managing replacement of failed RAM modules, hard drives with bad sectors, and physical destruction of retired storage media (disk decommissioning) so that remnants of old customer data don’t leak to outside parties.
• Virtualization Layer (Hypervisor): Securing the hypervisor software (like KVM or customized Xen) that separates one customer’s Virtual Machine (VM) from other customers’ VMs. The provider must guarantee no cross-tenant memory leaks (for example, from exploiting CPU vulnerabilities like Spectre or Meltdown).

Security “IN” the Cloud (User / Our Responsibility) #

Everything we configure, install, and run on top of the cloud services is entirely our own responsibility. The provider supplies security tools (like encryption, firewalls, and authentication systems), but we’re the ones who must enable and configure them correctly. Our domain includes:

• Data Security: Enabling encryption at rest using encryption keys (KMS) and encryption in transit using secure SSL/TLS protocols.
• Application & Dependency Security: Writing code that’s safe from SQL Injection, XSS, or broken authentication flaws, and ensuring third-party dependencies (npm libraries, Go modules, etc.) are free of active vulnerabilities.
• Identity & Access Management (IAM): Managing which team members may access the cloud management console, restricting access rights based on the least privilege principle, and requiring Multi-Factor Authentication (MFA) for all accounts.
• Virtual Network Configuration: Configuring virtual firewall rules (like Security Groups in AWS or Firewall Rules in GCP) to limit network ports open to the public internet.

Responsibility Division by Service Model #

The demarcation line between our responsibility and the provider’s is never static. The boundary shifts dynamically depending on the cloud service model we choose: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).

flowchart TD
    subgraph Boundary["Shifting Responsibility Boundary"]
        direction LR
        OnPrem["On-Premise<br>(100% Our Responsibility)"] --> IaaS["IaaS<br>(~60% Our Responsibility)"]
        IaaS --> PaaS["PaaS<br>(~30% Our Responsibility)"]
        PaaS --> SaaS["SaaS<br>(~10% Our Responsibility)"]
    end

The table below maps the responsibility division in detail for each infrastructure layer:

Legend: Us = User Team Responsibility | Provider = Cloud Provider Responsibility

IaaS — High Control, High Responsibility #

In the IaaS model (like AWS EC2, Google Compute Engine, or Azure VM), the cloud provider only lends you empty virtual hardware. You’re given root or full administrator access to the VM’s operating system. This offers extraordinary architectural flexibility, but demands maximum operational responsibility from your team.

flowchart TD
    subgraph IaaS_Responsibilities["Our Responsibilities in IaaS"]
        direction TB
        OS["Operating System (Kernel Patching & Updates)"]
        FW["OS Firewall (iptables/ufw) & Antivirus"]
        App["App Stack (Node.js, Nginx, Runtime)"]
        Sec["SSH / RDP Credential Management"]
        Data["VM Data Encryption & Backup"]
    end

Operational Consequences in IaaS #

• OS Patching & Upgrades: If a critical security flaw is found in your VM’s Linux kernel (like the Dirty Pipe or Heartbleed vulnerabilities), the provider won’t automatically update your VM. You must have an automation mechanism (like Ansible playbooks or AWS Systems Manager Patch Manager) to run patching regularly.
• Network Port Hardening: If you open SSH (22) to the public (0.0.0.0/0) with password login instead of SSH keys, and your VM gets hacked by a brute-force attack, that’s entirely your negligence. The provider only guarantees their physical routers are secure, not your VM’s login credentials.

Here’s a simple Bash automation script commonly used to run periodic security patching on Ubuntu/Debian-based IaaS VMs to fulfill your OS security responsibility:

#!/bin/bash
# ✓ CORRECT: Run automatic security patching periodically on IaaS VMs

set -euo pipefail

log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - [SECURITY-PATCH]: $1"
}

log_message "Starting security update check..."

# Update the package list from official repositories
apt-get update -y

# Run upgrades only for security packages
# Prevents accidental breaking changes from general application package upgrades
apt-get install --only-upgrade -y $(apt-get --just-print upgrade | awk '/Inst/ { print $2 }' | grep -i security || true)

log_message "Security updates applied successfully."

# Check whether the VM needs a restart after kernel patching
if [ -f /var/run/reboot-required ]; then
    log_message "VM requires a restart. Scheduling a safe restart..."
    # DO NOT reboot immediately if the VM is serving active production traffic without Load Balancer coordination
    # reboot
fi

PaaS — A Balance of Control and Convenience #

In the PaaS model (like AWS RDS for managed databases, Google App Engine, or Heroku), the cloud provider abstracts away the entire operating system, runtime, and middleware. You no longer have SSH access to the database server or runtime server. Your focus shrinks dramatically to just the application and data.

flowchart TD
    subgraph PaaS_Responsibilities["Our Responsibilities in PaaS"]
        direction TB
        AppCode["Write Secure Application Code"]
        DBAccess["Configure Database Users & Access Rights"]
        SSL["Configure SSL/TLS & Data Encryption"]
        Secrets["Manage API Keys & Secrets Securely"]
    end

Security Advantages in PaaS #

You’re freed from the headache of operating system patching, daily backup configuration at the cron job level, and setting up primary-secondary database replication. All of those can be enabled simply by ticking a configuration option in the cloud provider’s console.

Our Remaining Responsibilities in PaaS #

Even though the database operating system is managed by the provider, you remain responsible for database authorization governance. You must create database user accounts with minimal access rights (least privilege) and forbid your web application from logging in with the database root account. You also must ensure your application code is free of SQL Injection flaws that could expose the database contents to the outside network.

Here’s an example of a declarative Terraform (Infrastructure as Code) configuration to deploy a secure RDS database (PaaS) with KMS encryption enabled, placed in a private subnet (network isolation), and requiring SSL/TLS:

# ✓ CORRECT: Securing a managed database (PaaS) with KMS encryption & network isolation
resource "aws_db_instance" "secure_database" {
  allocated_storage      = 20
  engine                 = "postgres"
  engine_version         = "15.4"
  instance_class         = "db.t3.medium"
  db_name                = "production_db"
  username               = "app_user" # DO NOT use the name 'admin' or 'root'
  password               = var.database_password
  
  # Place the database in a private subnet so it can't be accessed directly from the internet
  db_subnet_group_name   = aws_db_subnet_group.private_subnets.name
  vpc_security_group_ids = [aws_security_group.db_sg.id]
  
  # Enable storage encryption using a KMS Key
  storage_encrypted      = true
  kms_key_id             = aws_kms_key.db_encryption_key.arn
  
  # Absolutely disable public access
  publicly_accessible    = false
  
  # Ensure the database can't be deleted without a backup when removed via terraform
  skip_final_snapshot    = false
  final_snapshot_identifier = "prod-db-final-snapshot"
}

SaaS — Minimal Control, Focused Responsibility #

In the SaaS model (like Google Workspace, Microsoft 365, Slack, or Salesforce), you rent ready-to-use applications. All compute infrastructure, databases, storage media encryption, and application code are fully managed by the provider. Your technical responsibility is nearly zero, but responsibility for data governance and user access management remains 100% yours.

flowchart TD
    subgraph SaaS_Responsibilities["Our Responsibilities in SaaS"]
        direction TB
        Users["User Provisioning (Employee Account Management)"]
        Roles["Role & Permission (Who can view/export data)"]
        MFA["Multi-Factor Authentication (MFA) Enforcement"]
        DataGov["Document Sharing Policies to the Public"]
    end

Critical SaaS Responsibility Areas #

1. User Lifecycle Management: When an employee leaves the company, you must immediately revoke their Google Workspace or Slack account access. If you’re negligent, the former employee can still illegally download sensitive company data — and that’s a governance failure on your side, not a bug in Google’s or Slack’s systems.
2. Enforcing MFA (Multi-Factor Authentication): The biggest data leaks in SaaS applications don’t happen because SaaS servers were hacked, but because users used weak passwords or fell for phishing attacks. You must enforce MFA activation for all employee accounts.
3. Data Sharing Governance: You must set rules in the SaaS admin console so internal company documents can’t be changed to “accessible to anyone with the link” without security team approval.

Practical Implications for Business & Engineering Teams #

How do we apply this understanding of the Shared Responsibility Model to day-to-day engineering team operations?

1. Threat Modeling Methodology #

When designing a new application architecture, your security team must adapt threat scenarios based on the chosen service model. If you migrate from IaaS to PaaS, you can remove the “illegal root OS access” threat from your mitigation list because that responsibility has been taken over by the provider — letting your team focus fully on threat modeling at the API and application data encryption level.

2. Industry Regulation Compliance #

If your company needs PCI-DSS certification (for credit card transactions) or ISO 27001, remember that the provider’s compliance certifications don’t automatically make your application compliant.

• AWS or Google Cloud being ISO 27001 certified only proves their data center buildings are physically secure.
• External auditors will still inspect your internal system configuration: whether your databases are encrypted, whether network ports are configured correctly, and whether your team has audit logging enabled.

Common Mistakes & Anti-Patterns #

Here are some fatal error patterns in the industry caused by misunderstanding shared responsibility:

// ANTI-PATTERN: Assuming everything is automatically secure because "it's in the cloud"
- Uploading credential files (API Keys / Service Accounts) to public git repositories.
- Creating S3 Buckets/Cloud Storage with public access and no encryption to simplify frontend app integration.
- Giving all developers "AdministratorAccess" in IAM without MFA to speed up coding.
- Letting IaaS VMs run for years without OS kernel updates, assuming the cloud provider updates them automatically.

// CORRECT: Manage our side of security responsibility with discipline
- Using a Secret Manager (like HashiCorp Vault or AWS Secrets Manager) to store application credentials.
- Blocking all public access to Object Storage by default, using signed URLs for restricted access.
- Applying the Principle of Least Privilege to IAM and enforcing MFA without exception for all users.
- Building a periodic OS patching automation pipeline with Ansible, Terraform, or Patch Manager.

Summary #

• The provider is responsible for security OF the cloud, while we’re responsible for security IN the cloud — the provider secures physical infrastructure and the hypervisor; we secure data configuration, access systems, and application code.
• The responsibility boundary shifts dynamically — IaaS gives the most control but carries the highest operational responsibility (like OS patching), while SaaS minimizes our technical burden down to user access governance and data classification.
• Data and IAM are always the user’s responsibility — no matter which service model you choose (IaaS, PaaS, or SaaS), data privacy, access authorization, and encryption configuration remain in your hands.
• User misconfiguration is the biggest security hole in the cloud — the majority of large-scale data breach incidents worldwide happen due to user misconfiguration (like public storage buckets or passwords without MFA), not because cloud providers’ physical infrastructure was breached.
• Provider compliance certifications are complementary — a provider’s physical data center security certifications don’t automatically make your application systems industry-compliant without independent auditing of your configuration side.

← Previous: Myths and Misconceptions   Next: Elasticity vs Scalability →