Lars Kamp
The shared responsibility model, introduced by AWS in 2011, defines the division of cloud security responsibilities between cloud providers and customers. Cloud providers are responsible for securing their physical infrastructure, while customers are responsible for securing their own data, configurations, and access.
Cloud environments have grown and become much more complex since 2011. As more services become available, customers face increased challenges in fulfilling their obligations from the shared responsibility model. The result is increased risk because of misconfigurations and insecure default settings that leave cloud workloads vulnerable to attackers.
As a customer, it’s important for you to address these issues to meet your security responsibilities and protect your infrastructure and applications. In this post, we’ll explore:
- The origin of the shared responsibility model, how the type of service that you use affects your responsibilities, and how cloud providers implement the model
- The challenge of balancing usability and security, and how collaboration between security and engineering teams is critical in your organization’s effort to fulfill its security responsibilities
- How we at Datadog meet our own responsibilities and can help you meet your responsibilities
Origin of the shared responsibility model
AWS published the first shared responsibility model in May 2011, during the "lift and shift" era of cloud infrastructure, in a blog post by Chief Evangelist Jeff Barr. As organizations moved their infrastructure to the cloud, there was confusion about who was responsible for securing what.
AWS formalized the shared responsibility model to eliminate that ambiguity. The model established a separation of concerns:
- The cloud provider is responsible for security of facilities (for example, data centers and co-location buildings), physical cloud infrastructure (for example, compute, storage, and networking), and the virtualization layer.
- The customer is responsible for securing data, applications, and identities (for example, accounts and users), as well as the operating system (OS) that runs on top of the infrastructure.
As AWS and other providers such as Microsoft Azure and Google Cloud introduced more services with higher levels of abstraction (for example, managed database services and serverless functions), the responsibilities shifted.
Different levels of responsibility by service type
In a traditional on-premises environment, a central security team was responsible for every layer of the stack, typically through a perimeter-based approach that included firewalls and network boundaries to limit exposure to outside threats. Today, with cloud-native infrastructure, the level of responsibility differs by service type: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS).
The following diagram depicts a simplified stack. Depending on the context, you’ll see this diagram with different and more layers to specify the responsibilities for specific cloud services (for example, databases, cloud accounts, monitoring, and container runtimes). For our purpose of explaining how shared responsibility works by service type, we’re using this simplified version.
In the IaaS model, the responsibility for facilities, infrastructure, and the virtualization layer is transferred to the cloud provider. In this model, the customer is responsible for the security of the guest OS, updates and patches to the OS, and all the layers that run on top of the OS. Typical IaaS offerings are compute instances and object storage. For example, a customer might store training data for its AI applications in a storage bucket. The cloud provider is responsible for securing the bucket’s infrastructure, whereas the customer is responsible for the security and compliance of the data that resides in the bucket. The customer also is responsible for controlling which users and models have access to that data.
In the PaaS model, the cloud provider is responsible for managing the infrastructure and platform components such as runtimes, libraries, and operating systems. Meanwhile, the customer is responsible for application security, data security, and user access to the application. A customer can choose to deploy its models on managed AI platforms such as Amazon SageMaker and Google Cloud Run. These AI platforms are considered runtimes, and the data to train the models still resides in a storage bucket or a managed database. In this case, the cloud provider is responsible for the security of the AI platform, storage bucket, and database. However, the customer is responsible for the security of the data, model, and application.
In the SaaS model, the cloud provider is responsible for most security aspects, from the infrastructure all the way to the application. Overall, the customer relies to a great extent on the cloud provider for security, uptime, and system performance. The customer's responsibilities are to manage user access and ensure data and account security. Examples of SaaS services are AI coding assistants such as GitHub Copilot, Amazon Q Developer, and Gemini Code Assist.
In short, as customers move from IaaS to PaaS to SaaS, the cloud provider assumes more of the operational and security burden. When you’re navigating the various cloud offerings, remember this shift of responsibilities. Consider an AWS example, shown in the following diagram, that includes Amazon EC2, Amazon RDS, and Amazon S3.
The three services have different levels of abstraction, or layers of infrastructure that AWS abstracts away. The more AWS abstracts away the inner workings of a service, the less responsibility that you as a customer have. This example is specific to AWS, but it applies similarly for Azure and Google Cloud.
Multi-cloud considerations and model variations
In today’s multi-cloud world, AWS, Azure, and Google Cloud all have their own versions of the shared responsibility model. With 78 percent of enterprises running or planning to run on more than one cloud, enterprises must understand and follow more than one responsibility model. Although the models are similar, today’s cloud services come with unique default settings and security responsibilities.
The matrix of different responsibility models, services, and default settings can make it confusing for customers and sets the stage for suboptimal security practices. For example, Datadog’s most recent State of cloud security report found that nearly half (46 percent) of organizations continue to have unmanaged users with long-lived credentials, which are susceptible to leaks and pose significant security risks.
The first step toward improvement is to close the knowledge gap by understanding the different models of the cloud providers and how responsibilities differ at the service level.
AWS: Security of and in the cloud
AWS separates security of the cloud (AWS handles infrastructure, hardware, networking, and physical facilities) from security in the cloud (customers handle OS patches, application security, identity and access management, and data protection).
The shared responsibility model is also the foundation of the security pillar of the AWS Well-Architected Framework, which describes “key concepts, design principles, and architectural best practices for designing and running workloads in the cloud.”
Azure: Boundaries for IaaS, PaaS, and SaaS
The Azure shared responsibility model closely mirrors the AWS model and specifies additional boundaries based on service types (IaaS, PaaS, and SaaS).
Like the AWS Well-Architected Framework, the Azure Well-Architected Framework has a security pillar “to help ensure the confidentiality, integrity, and availability of your data and systems.”
Google Cloud: Shared responsibility and shared fate
The Google Cloud model includes the delineation of responsibilities by service type and breaks down the stack into additional layers (for example, operations and logging).
Unlike the other providers, Google introduces the concept of shared fate. Google’s point of view is that understanding the shared responsibility model can be challenging because “the model requires an in-depth understanding of each service you utilize, the configuration options that each service provides, and what Google Cloud does to secure the service.”
Google claims that the concept of shared fate aligns the customer and cloud provider in their interest to achieve a successful security transformation. Specifically, this means that Google builds opinionated security defaults into services so that customers are less likely to misconfigure their resources.
The default dilemma: Usability over security
Google’s perspective has merit. The cloud is about speed and agility, and cloud providers want to make it fast and easy for developers to adopt and deploy services. To reduce friction, the providers make some cloud services available with permissive default configurations, prioritizing ease of use over security.
While this approach accelerates adoption, it can also introduce new risks if the service or resource is not explicitly configured. New deployments can introduce new misconfigurations. Every cloud service has different “knobs and whistles,” and it can be difficult to determine the appropriate security configuration. But under the shared responsibility model, that burden of configuration falls on you as the customer.
Cloud providers offer documentation to help solve the dilemma of secure setup. For example, AWS provides security documentation by product category and service. Azure has best practices and patterns, and Google Cloud offers security blueprints to help you deploy cloud resources with recommended configurations. Then there are recommendation services (for example, AWS Trusted Advisor, Azure Advisor, and Google Cloud Active Assist) that inspect your infrastructure and provide security recommendations. Finally, all three cloud providers offer security training and certifications.
In some cases, the providers also offer resource-specific visuals for the shared responsibility model. One example is Amazon ECS with Fargate, which is shown in the following diagram. As you can see, you need to use quite a bit of mental energy to understand the model.
For developers who are trying to move fast, the overhead of navigating documentation pages and recommendation dashboards that contain cloud-specific guidance is unrealistic, especially in multi-cloud environments. The cloud providers have hundreds of different services in their portfolios.
On the flip side, the model of a central security team reviewing infrastructure and gating releases also has limitations. This approach stops working efficiently when infrastructure is managed as code and developers implement new code and deploy new infrastructure many times per day.
Shared responsibility as a team sport
The problem of default configurations and the disconnect between development and security are real. Today, most breaches happen because of deficiencies in customer-owned controls in the shared responsibility model. These breaches are a direct result of cloud misconfigurations and weaknesses in identity and access management (listed as No. 1 and No. 2 in the Cloud Security Alliance’s Top threats to cloud computing report). Data from previous years shows that these issues have persisted.
Security teams are aware of the shared responsibility model and the peril of default configurations. They also know the security and regulatory requirements for the business, in addition to the requirements for protecting confidential data and assets. Developers however, don’t always have this expertise.
To convey that expert knowledge to developers, modern security practices combine a mix of enablement and governance:
- Enablement makes it easier to do the right thing.
- Governance makes it harder to do the wrong thing.
Each organization has its own recipe for these ingredients. Broadly, though, organizations use a combination of paved roads (enablement) and guardrails (governance) to prevent human error and achieve the desired outcomes:
- Paved roads provide standard security approaches for engineers to follow when they build and operate services.
- Guardrails enforce organizational policies and keep developers from stepping outside those security boundaries.
These practices exist because security can no longer be a silo, a separate system bolted on the side of cloud operations. The security team cannot be responsible alone. Security and compliance standards need to be integrated into development and operations, and these standards must become a shared responsibility across the organization.
In a cloud-native organization, good security becomes a product capability and a feature of the platform. It’s an extension of the shared responsibility concept. Shared responsibility between the customer and its cloud providers is not enough. The customer also needs shared responsibility within and among its development, operations, and security teams.
For this extended version of the shared responsibility model to work, customers need to break down silos across development, operations, and security. They should establish a unified view of the environment and implement processes, language, and goals that align their teams. That’s how shared responsibility becomes a team sport.
How we live shared responsibility at Datadog
Every organization is different, and how you implement shared responsibility can depend on a number of dimensions: your cloud usage, your industry, your customers’ industries, regulation, and the countries where you operate. To break down the silos, you can follow the People, Process, and Technology (PPT) framework to compartmentalize the changes you need to make.
Take Datadog as an example. We adhere to the shared responsibility model, of course, but we realized a few years ago that we had to expand on the concept. We needed a more stringent governance process. For context, we run a self-managed, microservices-based infrastructure (the IaaS model) that spans multiple cloud providers and serves customers in regulated industries. Our cloud security team had to deal with a growing number of misconfigurations in our development and experimentation environments. Previously remediated misconfigurations would get reintroduced into our environment through Infrastructure-as-Code (IaC) updates.
The following is a high-level summary of the changes we introduced in relation to the PPT framework:
- People: We combined the SRE and Security organizations into a single Security and Reliability organization, which develops the necessary tools and processes to secure the Datadog platform. Within this single organization, we have teams that focus on security in three key areas: product, internal cloud infrastructure, and operations. You can find out more in the blog post about our combined approach. Additionally, the responsibility for our security controls is shared across two teams. Our security controls administration team maintains our controls to sustain uninterrupted operations. Our security engineering team refines, improves, and expands these controls as our infrastructure grows and changes.
- Process: We shifted to a siloless responsibility model in which each team works on intersectional duties. We also implemented a new methodology that we call Find, Fix, Remediate, Prevent (FFRP). The philosophy behind FFRP is to solve the systemic problems that cause issues in the first place. We scale our security team’s knowledge by embedding business logic into the platforms that manage our infrastructure and cloud environments. This logic provides guardrails with configurable controls and filters that block risky infrastructure configurations or provide warnings before those configurations are put in place. You can find out more details in Securing Datadog’s cloud infrastructure: Our playbook and methodology.
- Technology: A siloless responsibility model can work only when all teams communicate through a unified view that integrates code security, cloud posture management, threat detection, logging, SIEM, remediation, and observability into a single cloud-native experience. It will not come as a surprise that we use Datadog as our unified platform for security. We use Datadog to operationalize our FFRP methodology, report on our posture and compliance status, and detect threats in real time.
We measure the effectiveness of our security programs by tracking compliance baselines and metrics. We also use data from incidents, security testing, threat analysis, and engineering to guide our actions. Since we changed our approach, our security team has reduced the number of open vulnerabilities to zero.
The following list contains some ways that we use Datadog to assume our share of security responsibilities. This list is not an exhaustive reflection of our security architecture and processes:
- Facilities: The security of the data center facilities is the responsibility of the cloud providers. We obviously know where we deploy, and that information matters because our responsibilities for complying with local laws and regulations depend on the countries and sites that we deploy in.
- Infrastructure: Infrastructure security is the responsibility of the cloud providers. However, it’s our responsibility to know what resources are running in our infrastructure. We use Datadog Resource Catalog to understand our cloud estate, ownership, and configuration of resources. With Datadog IaC Security, we alert engineers of risky infrastructure configurations so that they can fix them before deployment. Datadog Cloud Security detects misconfigurations and helps us maintain a strong compliance posture.
- Guest OS and runtime: For real-time threat detection, we use Datadog Workload Protection to perform in-kernel analysis of workloads in our hosts and containers. Our Threat Detection team writes rules in Datadog Cloud SIEM to detect potential security issues. You can read more in How we use Datadog for detection as code.
- Applications: We’re responsible for the security of our applications from code to execution. We scan our code and the libraries we use for vulnerabilities by using Datadog Code Security, and we use Datadog App and API Protection to protect ourselves against application-level attacks.
- Data: Data security and privacy are always customer responsibilities. We use Datadog Sensitive Data Scanner to discover, classify, and redact (where required) sensitive data.
- Identity: We use Cloud Security Identity Risks, a Datadog Cloud Infrastructure Entitlement Management (CIEM) product, to identify overly permissive access privileges.
Finally, products such as Datadog Security Inbox provide a consolidated, actionable list of the most important security findings. With Datadog Workflow Automation, we automatically trigger remediation actions. We define security contacts in Datadog Teams to route prioritized findings to the right team members, which helps prevent our engineering teams from becoming overwhelmed. Developers and security engineers often need the same data, just presented in a different way. Datadog does that for them.
Simplified shared responsibility: How Datadog can help
Regardless of which cloud providers or types of services you use, Datadog can help you meet your security obligations from the shared responsibility model. The same platform, tools, and features that we use to fulfill our own responsibilities can help you:
- Identify, remediate, and prevent security issues such as threats, vulnerabilities, and misconfigurations
- Break down silos and establish a unified view across your development, operations, and security teams
The best time to begin your journey to simplified shared responsibilities is now. Check out our Datadog Cloud Security documentation to get started. If you’re not yet a Datadog customer, you can sign up for a 14-day free trial.
