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:
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:
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.
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.
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 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.”
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.”
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.
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.
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:
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:
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.
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:
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:
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.
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:
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。