The shared responsibility model for cloud security
Cloud security is a shared responsibility between cloud providers and customers. The shared responsibility model depends on the specific provider and services used. Typically the customer assumes responsibility for securing their data, operating system, and client-side networking, while the cloud provider is responsible for the infrastructure used to run cloud services.
The cloud offers significant security advantages since it removes the need for organizations to secure their entire data center. In the cloud computing model, some of that responsibility shifts to the cloud provider — but not all. The purpose of the shared responsibility model is to ensure that both parties — the cloud provider and the customer — are aware of the aspects of the environment they are responsible for so security gaps and vulnerabilities are minimized.
What responsibilities does the customer have in the shared responsibility model?
The customer’s responsibilities depend on the cloud provider and the type of cloud deployment. For example, for a software as a service (SaaS) solution the customer is only responsible for their data and application access controls. For an infrastructure as a service (IaaS) solution, the customer takes greater responsibility for application security, network security, and the operating system.
Each of the major public cloud providers operates on a shared responsibility model. Here are some examples of how they uniquely approach this model:
AWS
AWS states, “AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.” Find out more about AWS security here.
Azure
Microsoft Azure takes responsibility for securing physical hosts, network, and the data center, while customers remain responsible for data, devices, and accounts. Responsibility for applications, network controls, and operating systems depends on the type of cloud model.
Google Cloud
Google notes in its security overview white paper that it provides world-class security for its infrastructure. But it too follows a shared responsibility model, “While you're always responsible for securing your data, we are responsible for securing the underlying infrastructure.”
Each vendor has its own specific vision of shared responsibility, but the division of responsibilities in a shared responsibility model transcends the specific vendor. This responsibility matrix diagram displays how the roles and responsibilities vary based on the cloud model — regardless of which vendor you are using.
Shared Responsibility in IaaS, PaaS, CaaS, and IaaS
In addition to vendor-related considerations, the shared responsibility model for security depends on the type of cloud computing solution. These solutions include infrastructure as a service (IaaS), platform as a service (PaaS), containers as a service (CaaS), and software as a service (SaaS).
IaaS
IaaS makes it possible for organizations to quickly scale compute resources up or down without needing to invest in and maintain on-premises resources. The cloud provider operates and manages the infrastructure on which services run. Examples of IaaS include Amazon EC2 and Google Compute Engine (GCE).
Cloud provider responsibilities: Physical security controls over the infrastructure
Cloud customer responsibilities: Applications, operating system, and data
Shared responsibilities: Network controls and the host infrastructure
PaaS
PaaS provides a complete development environment for building tools and applications. These resources include the underlying infrastructure (as with IaaS) along with development tools and database management.
Cloud provider responsibilities: Network controls and host infrastructure
Cloud customer responsibilities: Applications and data
Shared responsibilities: Access and application controls
CaaS
Containers are a mainstream development tool, with over 78% of production workloads being deployed as containers or serverless. CaaS offerings like Amazon Elastic Container Service (ECS) and Azure Container Instances (ACI) make it easier to use containers to run applications in the cloud, without needing to configure or manage the underlying infrastructure. They are similar to PaaS but are not limited to a specific tech stack.
Cloud provider responsibilities: The underlying infrastructure
Cloud customer responsibilities: Application code and container images
Shared responsibilities: Network controls and supply chain
SaaS
SaaS applications are delivered through the internet, allowing organizations to run them via a browser. The provider is responsible for maintaining the underlying servers and infrastructure.
Cloud provider responsibilities: Everything from physical infrastructure security down to application controls.
Cloud customer responsibilities: Sensitive data
Shared responsibilities: Access and authentication management
Regardless of the type of cloud implementation, the cloud provider will likely take on some of the security burden. It’s important to carefully identify and consider any gray areas where security responsibilities are not clearly defined. These gray areas can include:
Applications
Server-based environments allow you to install and run applications, but responsibility for those applications remains with the customer.
Networking
The cloud provider can only secure networks that are directly under their control.
Access management
PaaS solutions provide a control plane for configuration — it’s the responsibility of the customer to establish proper controls around access.
How to protect your cloud environment
We’ve covered the basics of the shared responsibility model for cloud security. The next step is to implement it in your specific use case.
The first thing to note is that, more and more, developers are responsible for setting up and configuring the environments where their applications will run — including both containers and the underlying infrastructure which is increasingly defined using Infrastructure as Code (IaC). This means they need to consider both the application security for any applications they develop and the aspects of cloud security that are relevant under the shared responsibility model.
Finally, they need a way to continuously monitor any live applications or environments for newly uncovered vulnerabilities or misconfigurations.
By incorporating security into development, properly setting up configurations, and continuously monitoring live workloads, organizations can comprehensively secure their cloud environments.
Secure your configurations from IDE to running clouds.
Empower developers to develop cloud infrastructure securely and fix issues from IaC source code
How Snyk can help secure your cloud environments
Snyk’s developer-first security tools can help with security in the cloud by providing developers with the insights they need to uncover, prioritize, and remediate any potential issues within applications or cloud infrastructure.
This shift left security approach is necessary for several reasons.
First, the development process has changed. Agile development methods mean that security needs to be continuously built into the development process (“DevSecOps”).
Second, the application structure itself has changed. Developers are now assembling applications with a mixture of proprietary and open source code, then running that code in containers and deployed using IaC.
Finally, traditional infrastructure has changed. On-premises data centers have been replaced with code that defines where and how an application will run.
Snyk offers several tools that can help address the security risks that come with these changes:
Snyk Open Source: Uncovers open source vulnerabilities and suggests fixes directly within developers’ existing tools.
Snyk Code: A static application security testing (SAST) tool that allows developers to introduce security checks from the very first line of code.
Snyk Container: A container scanning tool that helps identify a secure base image and uncover vulnerabilities before they go into production. Snyk’s partnership with Sysdig extends container security into runtime.
Snyk IaC: An IaC & cloud security tool that uncovers misconfigurations in IaC code before it goes into production, monitors live configurations for drift, simplifies compliance testing, and enables teams to swiftly address cloud issues by automatically connecting them to the relevant IaC source code.
Snyk's set of tools are a natural choice for cloud-native developers since they address the unique security concerns associated with modern applications while integrating with modern development practices such as DevSecOps. This gives organizations new ways to maintain their security posture under a shared responsibility model.
Secure your configurations from IDE to running clouds.
Empower developers to develop cloud infrastructure securely and fix issues from IaC source code