Topic Overview
The shared responsibility model (SRM) is an understanding between the cloud service provider (CSP) and an end-user of its services. This agreement says that a CSP will be responsible for securing the platform infrastructure of its cloud operations while an end-user is responsible for securing the workloads running on the cloud platform.
Indeed, Gartner underscores the need for customers of CSPs to thoroughly understand the agreement, stating that CSPs cannot offer complete security and security leaders must understand the scope of their responsibilities for security in the cloud. This is especially true for an organization in the process of migrating all or a portion of their workloads to the cloud.
Therefore, it would be most ideal for the architects building a cloud to take into account the specific security implications of the environment in which they want to operate. This will help all stakeholders to get a more complete picture of the risks and responsibilities the business is taking on in migrating to the cloud. A lack of understanding in the concept of SRM as it relates to a specific organization and their CSP could result in the misconception that the CSP is responsible for security of a certain area – which could then lead to misconfigurations and/or improperly secured cloud assets.
Understanding your role in the SRM can help you both uphold your responsibilities with regard to your CSP as well as implement and enforce cloud security best practices like regular vulnerability scanning.
Let's take a look at how some of the top CSPs define SRMs for their environments. After all, this information will be key in finding the best-fitting provider for your organization's unique needs.
This model states that AWS is responsible for the security of the cloud while customers are responsible for security in the cloud. While AWS works to keep its infrastructure safe, customers are in charge of IT controls such as encryption and identity and access management (IAM), patching guest operating systems, configuring databases, and employee cybersecurity training.
This model states that, in an on-premises datacenter, a customer owns the whole stack. As the customer moves to the cloud, some responsibilities transfer to Microsoft. Those responsibilities will vary, depending on the type of stack deployment.
For all cloud deployment types, the customer owns their data and identities. They’re responsible for protecting the security of those data and identities, on-premises resources, and the cloud components they control. Regardless of the type of deployment, the customers will always retain the following data, endpoint, account, and access-management responsibilities.
This model states that an in-depth understanding is required for each service a customer uses, along with the configuration options each service provides and what Google Cloud does to secure the service. Every service has a different configuration profile, and it can be difficult to determine the best security configuration.
The customer is the expert in knowing the security and regulatory requirements for their business and knowing the requirements for protecting confidential data and resources. GCP has also introduced the concept of “shared fate,” which enables a customer to essentially purchase the right to pass a responsibility on to GCP.
Now, let's take a look at how the SRM differs based on the type of cloud model on which a business is running. Under each heading below are listed the components a CSP is responsible for and those for which a customer is responsible.
The thing to remember is that as we move on from top to bottom in each area below, the CSP manages more and more components. Therefore, a customer gains more and more convenience and peace-of-mind, but with less ability to customize.
CSP is responsible for:
Customer is responsible for:
CSP is responsible for:
Customer is responsible for:
CSP is responsible for:
Customer is responsible for:
In a fully custom-built on-prem infrastructure the user would, of course, be responsible for all aspects listed above.
Getting into a more technical summation of what the SRM typically encompasses, many experts would say that the customer is responsible for anything they can change/add/remove/reconfigure in their cloud environment. If they do not have the ability to modify something, odds are the oversight responsibility for that aspect of cloud operations falls to the CSP.
As noted above, however, there can be areas of overlap. These gray areas are also known as shared control areas, and need to be intricately known by both CSPs and their customers for operations to run as smoothly as possible. For example, in terms of AWS, shared control areas would include aspects like patch management, configuration management for infrastructure as code (IaC), and security awareness training. Why are these areas shared?
Specifically, AWS would be responsible for patching and fixing flaws within their infrastructure, while customers are responsible for patching their guest operating system and applications. Similarly, AWS maintains configuration of its infrastructure, but a customer is responsible for configuring its own operating systems, databases, and applications.
Lastly, it is incumbent upon both AWS and its cloud customers to provide security awareness training to their respective employee organizations. These shared control areas only help to strengthen the abilities of both CSPs and their customers to secure the areas for which they are solely responsible.
The benefits of an SRM are fairly defined along the lines of the benefits that migrating to the cloud can yield. As a customer, you're engaging with a partner – just make sure it’s one you can trust.
Best practices will obviously be dependent on your organization's unique needs. So let's take a look at some of the more general best practices of a solid SRM.