Introduction
One of the most misunderstood -- and most important -- concepts in cloud computing is that security in the cloud is a shared job. The cloud provider does not secure everything for you, and you are not left to secure everything yourself. The Shared Responsibility Model draws a clear line between what the provider secures and what the customer must secure, and misunderstanding that line is one of the leading causes of real-world cloud data breaches.
Cricket analogy: Security being a shared job is like ground maintenance and player safety: the stadium authority secures the pitch and stands, but the team is responsible for its own equipment and conduct; confusing who owns what is exactly how avoidable mishaps happen.
Explanation
The model splits responsibility into two broad categories. Security 'of' the cloud is the provider's responsibility: this covers the physical security of data centers (badges, cameras, guards), the physical hardware (servers, storage, networking equipment), and the virtualization/host layer -- the hypervisor that isolates one customer's VMs from another's. The provider patches the hypervisor, secures the physical facilities, and ensures the underlying infrastructure that all customers share is not compromised. Security 'in' the cloud is the customer's responsibility: this covers what you put into the cloud and how you configure it -- your data (encryption, classification, access control), identity and access management (who can log in and what they can do), and, depending on the service model, the guest operating system, network configuration, and application-level security.
Cricket analogy: Security 'of' the ground is the stadium authority's job: fencing, floodlight wiring, and pitch drainage; security 'in' the ground is the team's job: locking the dressing room, controlling who enters the dugout, and protecting player equipment and strategy documents.
Crucially, exactly where that dividing line sits shifts depending on the service model you're using. With IaaS (Infrastructure as a Service), the provider secures the physical hardware, hypervisor, and physical network, but the customer is responsible for nearly everything above that: the guest OS (including patching it), firewall/network configuration, identity and access management, and application and data security. With PaaS (Platform as a Service), the provider takes on more: it manages and patches the underlying OS and runtime, so the customer's responsibility narrows to identity and access management, application code, and data. With SaaS (Software as a Service), the provider manages essentially the entire stack -- infrastructure, OS, and the application itself -- leaving the customer responsible mainly for data, user access management, and how they configure the application's security settings (e.g., who has admin rights, what data is shared).
Cricket analogy: With a rented ground (IaaS-like), the venue secures the structure but the team manages everything from pitch prep to security staffing; with a full-service venue package (PaaS-like), the venue also handles pitch maintenance, leaving the team to manage only strategy and access; with a fully catered hospitality box (SaaS-like), the venue runs everything and the team just manages who gets invited.
Example
IaaS PaaS SaaS
Data Customer Customer Customer
IAM / Access Customer Customer Customer
Application Customer Customer Provider
Runtime Customer Provider Provider
Guest OS Customer Provider Provider
----------------------------------------------------------
Hypervisor Provider Provider Provider
Physical network Provider Provider Provider
Physical hosts Provider Provider Provider
Physical facility Provider Provider Provider
(Customer's slice of responsibility shrinks from IaaS -> SaaS,
but data and IAM remain the customer's job in every model.)Analysis
The single most common real-world security failure under this model is a customer assuming the provider handles something that is actually the customer's job -- most often data exposure from a misconfigured storage bucket or an over-permissive IAM policy, neither of which the provider can fix on your behalf because you control that configuration. Notice that no matter which service model you use, data protection and identity and access management always remain the customer's responsibility -- the provider secures the infrastructure beneath you, but only you know what your data is, who should access it, and how it should be protected. Understanding exactly where the line falls for the service model you're using is therefore a prerequisite for building a secure cloud application, not an optional extra.
Cricket analogy: The most common real failure is a team assuming the ground authority secured their locker room valuables when really the team never locked the door themselves; whichever venue arrangement they use, protecting player equipment and data always remains the team's own job, not the venue's.
Key Takeaways
- Security 'of' the cloud (physical facilities, hardware, hypervisor) is always the provider's responsibility.
- Security 'in' the cloud (data, identity and access management, and depending on the model, guest OS and app) is the customer's responsibility.
- In IaaS, the customer manages the guest OS, network config, IAM, and application/data security.
- In PaaS, the provider manages the OS and runtime, narrowing the customer's job to IAM, application, and data.
- In SaaS, the provider manages nearly the whole stack; the customer mainly manages data and user access configuration.
- Data protection and IAM configuration remain the customer's responsibility across every service model.
Practice what you learned
1. In the Shared Responsibility Model, what does 'security OF the cloud' refer to?
2. Which responsibility remains with the customer in every service model (IaaS, PaaS, and SaaS)?
3. In the IaaS model, who is typically responsible for patching the guest operating system?
4. How does the customer's share of security responsibility change from IaaS to SaaS?
Was this page helpful?
You May Also Like
Cloud Security Fundamentals
Learn the core principles of securing cloud environments, including the shared responsibility model and defense-in-depth.
Identity and Access Management (IAM)
Understand authentication, authorization, and least privilege as the core building blocks of cloud IAM.
Cloud Service Models (IaaS, PaaS, SaaS)
How IaaS, PaaS, and SaaS differ in what the provider manages versus what the customer manages.
Compliance and Governance
Get a conceptual overview of common compliance frameworks like SOC 2, GDPR, and HIPAA in the cloud.