The shared responsibility model is a framework establishing cloud security responsibilities between cloud service providers (AWS, GCP, Azure) and customers.
Wiz Experts Team
5 min read
What is the shared responsibility model?
The shared responsibility model is a framework establishing who is responsible for securing different aspects of the cloud-computing environment between the cloud service provider (CSP) and the customer. The CSP is generally tasked with the security of the underlying infrastructure, while it is on the customer to secure its cloud-hosted data and applications.
CSPs are responsible for securing data centers and all networking equipment. They also handle tasks such as patching and updating operating systems as well as ensuring the availability and reliability of the cloud services. This is known as the "security of the cloud" responsibility.
Customers’ security responsibilities include setting up secure access controls, encrypting data in transit and at rest, managing user accounts and credentials, and implementing application-specific security measures. This is called the "security in the cloud" responsibility.
For instance, as a CSP, Amazon S3 ensures the physical security of their data center and protects against infrastructure-level threats. However, it’s the S3 users’ responsibility to properly configure access control and permissions for their S3 buckets, implement encryption for sensitive data, and regularly monitor and manage access to stored data.
These responsibilities are not widely understood. Although 98% of businesses report a cloud-data breach within the past eighteen months, only 13% understand their cloud-security responsibilities. Many organizations erroneously rely on their CSPs for data protection and application security. Closing this knowledge gap is an essential step toward fulfilling cloud security obligations.
How shared responsibility varies by service type
The level of a CSP customer’s shared responsibility depends on service type: software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS).
In the SaaS model, CSPs bear most security responsibilities. They secure the software application, including infrastructure and networks, and they are responsible for application-level security. Customers’ responsibilities often include managing user access and ensuring data is protected and accounts are secure. In short, customers rely heavily on their cloud service provider for security, uptime, and system performance.
In the PaaS model, CSPs manage infrastructure and underlying platform components, such as runtime, libraries, and operating systems. Customers are responsible for developing, maintaining, and managing data and user access within their applications.
Of the three models, IaaS customers have the highest level of responsibility. The CSP secures the foundational infrastructure, including virtual machines, storage, and networks—while customers secure everything built on the infrastructure, such as the operating system, runtime, applications, and data.
While the responsibilities mentioned above provide a general overview, the exact division of responsibilities varies across CSPs. It’s best practice to refer to specific service-level agreements and documentation provided by CSPs for more information about responsibility distribution..
Customers’ cloud-security responsibilities
Customers, rather than CSPs, often bear responsibility for most cloud-security incidents.
By 2025, 99% of cloud-security failures are forecast to come from customers.
To ensure success in the shared responsibility model, let’s take a look at customer responsibilities.
Ensuring data confidentiality, integrity, and availability is the customer’s purview. Best practices involve implementing proper access controls, encryption, and backups.
User access management
Implement appropriate permissions, enforce strong passwords, and adopt multi-factor authentication to keep user access secure.
Customers are accountable for securing cloud-hosted applications. Follow secure coding practices, conduct regular vulnerability assessments, and implement appropriate security controls to reduce application-level security threats.
Firewalls, virtual private networks (VPNs), security groups, and other network-control configurations are essential customer responsibilities that protect cloud resources from unauthorized access.
Compliance and governance
Meeting regulatory requirements and implementing appropriate governance controls are also customer responsibilities. Each industry has unique regulations and frameworks.
CSPs’ typical cloud-security responsibilities
CSPs’ share of responsibilities usually includes the security of the infrastructure and attendant dependencies. Some of their security responsibilities include the following.
As previously mentioned, CSPs are responsible for securing physical access to their data centers, using tools like surveillance systems, restricted-access areas, and environmental controls.
Each provider is responsible for securing cloud-network infrastructure, including routers, switches, and load balancers by implementing appropriate controls, such as intrusion detection and prevention systems.
CSPs secure underlying host infrastructures, including servers, virtualization layers, and storage systems. They implement proper configuration, patching, and security controls on these resources; update operating systems; and ensure overall availability and reliability of cloud services.
CSPs often undergo independent audits and attain certifications to demonstrate compliance with industry standards and regulations. These measures provide customers with assurances regarding their security practices.
Some responsibilities are shared by both parties based on service type (SaaS, PaaS, or IaaS). For instance, within the Microsoft shared responsibility model, CSPs and SaaS and PaaS customers share responsibility for securing identity and directory infrastructure. Alternatively, application security and network controls are shared under the PaaS model. CSPs clearly define the boundaries of responsibilities through service level agreements (SLAs). Overlaps usually exist in the following areas:
Whether a user brings their own operating system (OS) or deploys an OS provided by the cloud provider, the responsibility of choosing the appropriate OS to meet an organization’s security requirements lies with the user. If the user chooses the CSP’s operating system, then they are responsible for its security. However, if a customer brings their own OS, their organization is responsible for its security.
Native vs. third-party tools
Providers are responsible for deploying, managing, maintaining, and updating services. Though when deploying a third-party tool or application as a workload, the customer is charged with securing the application and its data, while the CSP's responsibility is limited to the infrastructure and virtualization layer.
Server-based vs. serverless computing
In server-based computing, the user is responsible for choosing the operating system, deploying the workload, and configuring the necessary security settings. On the other hand, in serverless or event-based computing, the user is accountable for the deployed code and user-defined security or configuration options provided by the cloud vendor.
Whether deploying their own firewall or using the provider’s, customers are responsible for configuring firewall rules and ensuring proper security-standard configuration.
Major CSPs like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure have established their own shared responsibility models, which outline provider-customer security responsibilities.
The AWS shared responsibility model
The AWS shared responsibility model outlines that AWS is “responsible for protecting the infrastructure that runs all of the services in the AWS Cloud.” They take responsibility for both hardware and software, including physical data centers, networks, edge locations, and virtualization layers.
AWS also secures their managed services, such as AWS DynamoDB, RDS, Redshift, Elastic, and EMR. However, customers are responsible for securing their own applications and data, and managing access controls and configurations within their AWS accounts.
Google Cloud Platform (GCP) follows a shared responsibility and shared fate model. GCP introduced 'share fate' to address the challenges where they believe the shared responsibility model fall short.
GCP secures underlying cloud infrastructures and provides add-on options that customers can leverage to discharge responsibility for securing applications and data, managing user access and permissions, configuring security settings, and implementing appropriate security measures within their projects.
Despite its several benefits, the shared responsibility model also presents the following challenges:
Organizations must always protect customer data. However, the shared responsibility model requires that CSPs have unguarded access to sensitive infrastructure to evaluate security posture, contradicting an organization’s exclusive access to customer data. This has pushed many organizations into implementing role-based access control (RBAC) to ensure that authorized individuals have access to perform only pre-specified duties.
There are important areas of cloud security where the model does not clearly spell out the security responsibilities of each party. For instance, cloud middleware—which sits between organizations and CSPs for cloud security posture management—requires regular updates as new vulnerabilities continue to surface and attack surfaces expand. However, many organizations are barely aware of the required frequency of updates, and this exposes them to preventable attacks. Automating the software patching process is a viable solution to combat this issue.
When cyberattacks occur, identifying which party is responsible for investigation and remediation is critical. Unfortunately, the shared responsibility model does not clearly spell out the delegation of responsibility. Additionally, cyberattacks can be targeted at anyone at either party (customer or CSP), so managing the attack is often slowed down by pinpointing the source and establishing who is responsible for remediation.
Organizations offering multiple services often require multiple CSPs and unifying them into a single system may be cumbersome. Moreover, the multi-tiered nature of cloud deployments often necessitates the intervention of multiple departments, adding complexity to the question of who is responsible for what. Even when CSP versus customer responsibilities are clearly spelled out, identifying departments that are responsible for securing specific aspects of the cloud may be difficult.
A new vision for the shared response to cloud vulnerabilities
In an earlier blog, Wiz CTO Yinon Costica highlights the need for a new shared response model for handling cloud vulnerabilities. Yinon uses ChaosDB as an example of why the current model lacks transparency and clarity in handling vulnerabilities, which leads to confusion and ineffective remediation efforts.
Yinon proposes a new starting point for how CSPs and customers should work together to address new cloud vulnerabilities:
Areas of Responsibility
Cloud vulnerability database
Cloud features and security configuration
Enumerated cloud security benchmark
Threat model change log
Correct cloud configuration
Check out Yinon's blog for a detailed explanation of each of the responsibilities above, and why he thinks this new model will allow CSPs and customer respond more efficiently the new cloud vulnerabilities:
Although cloud service providers and their customers each have specific cloud-security responsibilities, it can be difficult to navigate the boundaries and determine who is responsible for what. Major CSPs advise that customers learn more about these responsibilities and take proactive steps towards cloud security.
Wiz seamlessly integrates with your CSP and provides complete visibility into the security state of your cloud environment. Schedule a demo today.
See Wiz In Action
Learn why CISOs at the fastest growing enterprises secure their cloud with Wiz.
This blog post explores the world of container orchestration tools beyond Kubernetes, highlighting cloud provider tools and open-source alternatives that promise to redefine how we deploy and manage applications.
Microservices security is the practice of protecting individual microservices and their communication channels from unauthorized access, data breaches, and other threats, ensuring a secure overall architecture despite its distributed nature.
We’ll take a deep dive into the MLSecOps tools landscape by reviewing the five foundational areas of MLSecOps, exploring the growing importance of MLSecOps for organizations, and introducing six interesting open-source tools to check out
CSPM focuses on securing cloud infrastructure by identifying and remediating misconfigurations, while CIEM centers on managing and securing user identities and access permissions within cloud environments, addressing threats related to unauthorized access and entitlements.