The cloud shared responsibility model for IaaS, PaaS and SaaS

How do cloud shared responsibility models work?

Cloud shared responsibility models define which aspects of a cloud environment a CSP manages and which ones the customer manages.

All the major CSPs, including AWS, Microsoft Azure and Google Cloud, publish shared responsibility models. While they vary a bit in their details, most shared responsibility models state that the CSP takes the lead in managing the following:

• Keeping the software that powers underlying cloud infrastructure up-to-date and safe from security risks.
• Managing the virtualization layer that lets customers create VMs and other resources on top of physical cloud servers.
• Responding to incidents that affect the security or operational effectiveness of physical cloud servers and other infrastructure.
• Protecting servers and network infrastructure within the cloud platform from physical security risks.

Meanwhile, cloud customers are typically responsible for the following:

• Implementing effective security configurations for applications and data hosted in their environments.
• Defining secure identity and access management policies to control access to cloud-based applications and data within their environments.
• Monitoring cloud environments for signs of breaches.
• Updating customer-deployed applications as needed to mitigate security vulnerabilities.

Understanding who does what within the context of cloud security and management is important because the cloud is a different beast from on-premises computing. With traditional on-premises data centers, the organization's IT staff manages everything -- the physical infrastructure, the virtualization layer (if it exists), and any data and applications that reside in the data center. These clearly defined barriers make the whole security process relatively straightforward.

But when they move to the cloud, IT teams must deal with the infrastructure and services that cloud service providers manage, which can complicate an organization's overall security strategy. Once a cloud provider becomes involved, they take on some of the responsibility related to securing the customer's environment -- but not necessarily the data within it. If administrators and developers don't secure their end of things, however, the organization can become vulnerable to breaches.

The key to a successful cloud security strategy is understanding the cloud shared responsibility model to the fullest extent.

How are shared responsibility models different for IaaS, PaaS and SaaS?

At a high level, understanding the shared responsibility model is simple enough: Cloud customers are responsible for managing the resources they control, and the CSP does the rest.

However, this approach can vary depending on which cloud service category -- IaaS, PaaS or SaaS -- is involved.

IaaS

In an IaaS model, CSPs only provide the infrastructure. For example, they might supply customers with an object storage service where they can store data or a cloud server service where they can launch VMs.

Shared responsibility is typically clear-cut with IaaS because the model distinguishes cloud infrastructure from the workloads and data residing on them. The CSP manages physical infrastructure and the virtualization layer, while the customer manages everything else.

PaaS

In a PaaS model, the CSP provides the infrastructure and tools to develop and deploy applications.

Under this model, the CSP manages both the infrastructure and the software development and deployment tooling. Customers manage any applications they create using the PaaS.

In addition, customers are usually responsible for securing PaaS development environments. For instance, imagine a customer chose a poor password for their PaaS account and a malicious actor logged into the PaaS, injected malicious code into the customer's application and then deployed the compromised app. In this case, the customer would be responsible for allowing the breach. Although the CSP manages the PaaS platform, it's not responsible for issues that arise due to the way customers use the platform.

PaaS is the middle ground in the cloud shared responsibility model as it places more responsibility in the hands of the cloud provider. In this scenario, IT teams still deploy and manage their applications and related data, but the provider secures the operation of the underlying infrastructure and overall OSes.

SaaS

In the SaaS model, customers have minimal control and responsibility. This is because SaaS offerings include cloud infrastructure and the software running on top of that infrastructure, all of which the SaaS vendor manages.

This doesn't mean SaaS absolves customers of all responsibility. SaaS application users must still ensure they don't choose configuration options that could lead to security issues, such as granting public access to a word processor file created using a SaaS app.

In addition, although SaaS vendors typically provide data backup and recovery services to protect against data loss incidents that could result from failures in their infrastructure, they usually won't recover data that customers accidentally delete. For this reason, SaaS customers should consider backing up their data.

Blurring the lines

Sometimes, the lines separating IaaS, PaaS and SaaS aren't clear-cut, and neither is the cloud shared responsibility model.

For example, the Amazon Elastic Kubernetes Service manages Kubernetes clusters. In some ways, EKS resembles IaaS because it lets customers deploy applications on cloud servers. Amazon manages the underlying servers, but customers manage the apps they deploy using EKS.

Amazon delivers the core software within EKS, the Kubernetes control plane, as a managed service to deploy, configure and secure the service on the part of customers. This Amazon EKS component feels more like a form of SaaS.

Managing responsibilities effectively in the context of a complicated cloud service like Amazon EKS is possible. However, it requires a nuanced understanding of how the service is architected and what its implications are for shared responsibility.

Challenges of the shared responsibility model

The shared responsibility model is straightforward in principle, but adhering to it can be challenging in practice for the following reasons:

• No hard guarantee against failure. Outsourcing some management responsibilities to cloud providers is attractive, but CSPs can make mistakes that affect customers. For instance, if a cloud provider's data center goes down, your business's services might also go down until the CSP is back online. Typically, cloud service-level agreements (cloud SLAs) allow for a certain level of failure and the CSP offers no compensation for these types of events.
• Cloud tooling limitations. Cloud providers offer a variety of tools to help their customers configure and monitor cloud environments. But just because CSPs provide these tools doesn't mean the tools automatically handle customers' responsibilities for them. Customers must learn to use the tools effectively and know when to turn to third-party offerings to fill gaps in the tools the CSP offers.
• Limited data. While data that helps organizations manage security and other risks is available in an on-premises environment, it isn't always available in the cloud. For example, many cloud services provide access only to certain types of metrics, and because customers don't control the underlying infrastructure, they can't create custom metrics. This leaves customers with a limited data set for monitoring their environments.
• Complex deployments. Some types of cloud services and environments combine elements of IaaS, PaaS and/or SaaS. Understanding how shared responsibility works in this context requires a nuanced assessment of who controls what.

Tips for reviewing SLAs with cloud providers

If you're unsure what a shared responsibility agreement means for your organization, ask your cloud provider to explain the details of the SLA. In particular, you should understand the following:

• What the SLA guarantees. Typically, SLAs promise a certain amount of uptime for cloud services. They might also specify latency or response rates.
• How SLA metrics are calculated. Ask how the CSP determines if it's meeting the SLA. For example, does a service have to be unavailable for a minimum length of time before it triggers a downtime event that counts toward the SLA? Or does the CSP add up every millisecond of downtime and use that calculation to determine whether it meets its uptime commitment?
• What happens if the SLA is violated. CSPs might provide credits or refunds if they fail to meet the SLA. But it's also possible the SLA agreement includes no compensation for falling short of SLA guarantees.
• The CSP's track record of SLA compliance. How often has the cloud provider fallen short of its SLA guarantees in the past? When SLA violations occurred, how extreme were they and were customers compensated?
• SLA change policies. Can the CSP change the SLA terms by, for example, modifying uptime guarantees of its own volition? Or is the CSP locked into its commitments through inalterable SLA guarantees?

Editor's note: This article was updated in October 2024 to improve the reader experience.

Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.

Sara Grier is a former assistant site editor for TechTarget's Cloud/DevOps media group.