Ali Gardezi

Cloud Shared Responsibility Model – Why is it important

The wide spread appeal for public cloud services and providers has been driven by the speed of innovation and agility provided. Every year new services and features are launched that ensure customers can focus on their business and leave the undifferentiated heavy lifting to the cloud providers. Often one of the assumption customers have when moving to the cloud is that security, resilience and reliability of their application and the entire stack sits with the cloud provider, this is not the case. This is where the Shared Responsibility Model comes into play and understanding it is fundamental to the success of every customer on their cloud journey.

Shared Responsibility Model

The Shared Responsibility Model is a way to divide up the operational responsibilities between the cloud provider and the customer. Security, compliance, reliability and resilience are shared responsibilities between the cloud provider and the customer and it is import to understand where this dividing line sits. As I mentioned earlier, cloud has resulted in ensuring a lot of the undifferentiated heavy lifting of running and maintaining infrastructure and tools is taken care of by the cloud provider and so under the shared responsibility model, the security/compliance “of the cloud” is the responsibility of the cloud provider. Thus the customers is responsible for the security/compliance “in the cloud”.

Security/Compliance “Of the Cloud”

When we talk of cloud, we have to understand that at some point there is some infrastructure running on servers sitting in a number of data centres in different parts of the world connected via a global network using switches, firewalls, routers and running different software to provide the high level services the customers see in their cloud console. So when we say security/compliance “of the cloud” it is refereeing to these underlying building blocks. It is the cloud providers responsibility to ensure these are secure, up to date, compliant, protected, and running in a reliable fashion.

Security/Compliance “In the cloud”

The customer is the expert in knowing the regulatory and security requirements of their business and solution. So when they run their workloads on a cloud provider they are responsible for ensuring they are meeting their compliance and security needs. All cloud providers have a number of different tool and services for providing security controls plus they services they offer have certain compliance certifications for the underlying infrastructure. It is the customers responsibility to ensure they have applied the correct controls and are using the right tools and services based on their security and compliance requirements. For example if they are using AWS EC2 instances or Google Compute Engine VM, it is the customers responsibility to ensure the Operating System is patched regularly and the security groups / firewall rules are setup correctly. At the same time it will be the cloud providers responsibility to make sure the underlying physical host is secure and running a patched hypervisor and also ensure the physical security of the data centre.

Is the SRM the same for all Services

The boundaries of the Shared Responsibility Model change depending on the types of services and workloads. As we move from IAAS to PAAS to SAAS services, more of the responsibility starts to fall with the Cloud Provider. An example for abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions. The following image from Google Cloud illustrates how the responsibilities change as we customers move from on-prem to fully managed SaaS:

Here is an example of how the responsibilites in the SRM change as we apply it to a managed service like Elastic Container Service (ECS) from AWS:

Since more of the infrastructure, configuration and software is controlled and managed by AWS, it falls within their purview to manage and secure hence relieving the customer of the tasks.

Another factor that can affect how the SRM applies to a customer workload is the location the workload is being operated in. Different location have different services available and hence how the SRM applies to the workload will be different.

What is next

Understanding the Shared Responsibility Model is important in order to successfully migrate workloads into the cloud however it can be challenging. It requires an in-depth understating of the services that are going to be used with the workload, the configuration options and where then sit on the scale from IaaS to SaaS. Another factor is the speed and scale at which cloud services are continuously changing and evolving. With each iteration, there is a change in how the configuration of the service is managed so it affect how the SRM applies to the service and thus the customer workload dependent on the service.

This is why the SRM is just the starting point. Most cloud providers have realised over time there is a need to provide an opinionated view of how cloud services should be configured and used with different types of workloads. Google Cloud have given it the most succinct name, they call it Shared Fate.

Shared Fate focuses on how different parties must interact and work together over time to ensure the workloads are making full use of the convenience and services offered by the cloud and continuously improve security, reliability and resilience. In order to achieve this all cloud provider have a number of different programs and services on offer that can help with the decision making process. At a very high level there is the Landing Zone, Cloud Adoption Frameworks, Architecture Frameworks (WAF in AWS and Google Cloud Architecture Framework in GCP) and blueprints developed by the cloud provider.

Landing Zone

The Landing Zone is an opinionated account management framework that most cloud providers provide that is based on years of experience by the cloud providers of helping customers build scale and manage workloads in the cloud. Its usually a set of tools, frameworks, policies, scripts and design principles that help a customer get started in the cloud while making sure they are employing best practices that will help them in the long run. We will dive deeper into the landing zones conceptually and how the different cloud providers implement them but for now here are the landing zone products on the 3 major cloud providers:

Cloud Adoption Frameworks

When it comes to frameworks, there is plenty to choose from in each cloud provider. Each cloud provider has a high level Cloud Adoption Framework that details what capabilities an organisation needs in order to successfully adopt cloud. These capabilities provide best practice guidance that helps improve cloud readiness. This is a topic that I will cover in depth in a future post, but for now here are links to more info on the Cloud Adoption Framework from each of the 3 major cloud providers:

Well Architected Framework

Like the CAF, the WAF is also a framework that has been developed by cloud providers over years of helping customers architect workloads that make full use of the cloud. Where the CAF looks at the entire organisations and processes, the WAF is more focused on individual workloads and making sure they are Well Architected. This is a topic that I will cover in depth in a future post, but for now here are links to more info on the Well Architected Framework from each of the 3 major cloud providers:

I hope you all enjoyed this and if you have any questions or comments please let me know below.

1 comments

Leave a comment