6 mins to read
The Shared Responsibility Model in the Cloud
Gartner predicts that through 2025, 99% of all cloud security failures will be the customer’s fault. A statistic like this can be jarring, maybe even alarming or worrisome, especially if you’re a cloud customer. The cloud is an unyielding force with exponential levels of complexity, and this lends it to be difficult to control. So perhaps, instead of looking at cloud failures as the customer’s fault, we must consider the guidelines around cloud configuration and acknowledge why it is so easy for customers to ineffectively secure their cloud.
The great news is that a large portion of that 99% of cloud failures is actually preventable, if a customer knows exactly what they are responsible for securing in their cloud. This brings us to The Shared Responsibility Model.
What is the Shared Responsibility Model?
The shared responsibility model is a working framework followed by Cloud Service Providers that details the responsibility over an entire cloud environment from infrastructure, to hardware, data, identities, workloads, network, settings, and more. Responsibility is divided between the CSP and the customers. Each provider defines their own respective shared responsibility model. Below we’ll define the basics of two top cloud providers, but first let’s understand the context behind the creation of the shared responsibility model.
Why the Shared Responsibility Model is Important
As organizations migrate to the cloud, new needs for security emerged, including a major need for cloud providers to ensure secure environments. Previously, an organization was entirely responsible for its own datacenters and securing networks and infrastructure. Now, because we outsource the management of a lot of hardware, responsibility has shifted. Service Providers offer customers a safe and stable platform on which to build and grow their businesses. The Cloud Service Provider’s accountability has grown dramatically in recent years, especially after pivotal moments like Azure’s famous vulnerability detected in its managed database service, CosmosDB.
Since then, cloud service providers, like Microsoft Azure, Amazon Web Service (AWS) and Google Cloud Platform (GCP), have worked tirelessly to assure its customers that their environment is as secure as possible.
But this promise can only go so far, and so a line was drawn in the sand. Cloud providers, AWS, specifically, published a clear guide of how far they will go to monitor and regulate their customer’s environment – the birth of the shared responsibility model.
The resulting decision was that the cloud provider is responsible for the security of the cloud, while the customer is responsible for security in the cloud.
Benefits and Challenges of the Shared Responsibility Model
The obvious benefit is less operational burden on your organization. You work together with your CSP to secure your cloud, but there is less burden overhead when it comes to maintaining hardware and operations. In an ideal world where you and your CSP fully understand and uphold your responsibilities, security can be better than ever before.
Conversely, there can be challenges associated with the model. For starters, each CSP has a different model, so if you’re working multicloud, you need to be aware of the differing responsibilities in different clouds. Secondly, there’s different responsibility management depending on what service you’re considering for e.g. IaaS or PaaS. Finally, some things are simply left open to interpretation, and that leaves room for misunderstanding. All this variation and detail can make it difficult to be aware of what you’re responsible for and follow through sufficiently.
Shared Responsibility Model by Cloud Service Provider
AWS Shared Responsibility Model
AWS is focused on the security of AWS infrastructure, including protecting its computing, storage, networking, and database services against intrusions because it can’t fully control how its customers use AWS. AWS is responsible for the security of the software, hardware, and the physical facilities that host AWS services. Also, AWS takes responsibility for the security configuration of its managed services such as AWS DynamoDB, RDS, Redshift, Elastic MapReduce, WorkSpaces, and others.
Customer responsibility depends on what AWS service is being used, but in sum, AWS customers are responsible for the secure usage of services that are considered unmanaged. For example, while AWS has built several layers of security features to prevent unauthorized access to AWS, including multi-factor authentication, it is the customer’s responsibility to make sure multifactor authentication is enabled, particularly for those Identities with the most extensive IAM permissions in AWS.Furthermore, the default security settings of AWS services are often the least secure. Enhancing the default AWS security settings and uniquely configuring your cloud, therefore, is a low-hanging fruit that organizations should prioritize to fulfill their end of AWS shared responsibility model.
Azure Shared Responsibility Model
Azure is focused on the security of the underlying infrastructure, by protecting its computing, storage, networking, and database services against intrusions. Azure is also responsible for the security of the software, hardware, and physical facilities that host Azure services. The Azure cloud security framework takes responsibility for the security configuration of its managed services such as Azure Kubernetes Service (AKS), Container Instances, Cosmos DB, SQL, Data Lake Storage, Blob Storage, and others.
Azure customers are responsible for the security in their own cloud, or more simply put, everything that they instantiate, build and/or use. This responsibility is contingent on what service Azure customers are using and whether it is SaaS, PaaS or IaaS. Per Microsoft, “In an on-premises data center, the customer owns the whole stack. As you move to the cloud some responsibilities transfer to Microsoft Azure.” The following diagram illustrates the areas of responsibility between the customer and Microsoft:
Microsoft clearly defines that the customer always owns all their own data and identities and they are therefore responsible for the security of them as well as the cloud components they control.
The Azure Shared Responsibility model continues by stating the four responsibilities that always fall to the customer:
- Data
- Endpoints
- Account
- Access Management
Google Cloud Platform (GCP) Shared Responsibility Model
Google Cloud splits the responsibility categories into content, access policies, usage, deployment, web app security, identity, operations, access and authentication, network security, data & content, networking, storage and encryption, and hardware. Additionally, they outline the line in the sand according to the service you’re using. For IaaS like Compute Engine, Cloud Storage, Cloud DNS, Cloud VPNs, etc., they express the bulk of responsibility to be on the customer, while they only manage underlying infrastructure and hardware security. PaaS like Google Kubernetes Engine or BigQuery it’s more split 50/50 with customers responsible for application level control or data and identity protection and GCP liable for the same physical hardware and infrastructure, as well as more network controls. For SaaS, like Google Workspace, they express the majority of work on their end, and only detail customer responsibility over controls and data they choose to host in the service.
Best Practices for Implementing the Shared Responsibility Model
- Review the SLA: Responsibilities are different for different clouds so it’s worth reviewing your SLA in depth to understand what you’e agreeing to. This is a time to clarify ambiguity and work with your provider to get on the same page. If you’re multicloud, read each one.
- DevSecOps: Embracing DevSecOps means embracing the continuous lifecycle of security. It shouldn’t be an afterthought, and instead considering security checks throughout development can mean catching things earlier and more efficient processes.
- Focus on data: Your data is your most critical asset, and across all CSPs and all services (IaaS, PaaS, etc.) is always your responsibility. Focus your strategy starting at the core of your business, and work your way out to enforce a strong perimeter. Classify your data, enforce policies, and tailor your plans according to how sensitive the respective data is.
- Keep communication open: Be on the look out for communications from your Service Provider. They regularly make changes like service updates or make additions that could affect your security responsibilities. Ask for help or ask questions if something is unclear. Lean into your security community.
- Outsource a trusted security partner: There are tools dedicated to helping you keep up your end of the deal with the Shared Responsibility Model. Consider looking at solutions like Cloud Infrastructure Entitlement Management (CIEM) for all things securing identity and their permissions, or Data Security Posture Management (DSPM) to lock down critical assets, Cloud Workload Protection for securing workloads and applications, and finally, Cloud Security Posture Management (CSPM) for enforcing secure configurations.
Holding Up Your End of the Deal
Now that you know you’ve got your work cut out for you in securing your cloud environment, how do you hold up your end of the deal? Managing all your data, platforms, applications, identities, networks etc. is overwhelming for any security team. The obvious answer is to turn to help.
Sonrai Security is built to singlehandedly help enterprises remain accountable for their security responsibilities. If you want to see how we approach securing cloud platforms, workloads, and data, all with an identity-first approach, consider a personalized or on-demand demo.
