top of page
Writer's picturevP

AWS Shared Responsibility Model - Day 3

Hello readers! Welcome back to our #100DaysOfAWS series! In this third blog, we're revisiting a fundamental concept that forms the bedrock of AWS security – the AWS Shared Responsibility Model. This model is at the core of how AWS ensures security and compliance in the cloud, and it directly impacts how you secure your workloads on AWS. In this blog, we'll dive deeper into the specifics of these responsibilities, providing you with a solid foundation for your AWS journey.

The AWS Shared responsibility model defines what customer and AWS are responsible for when it comes to security and compliance. As a general rule, AWS is responsible for security of the cloud and the consumer is responsible for security in the cloud.


AWS responsibility “Security of the Cloud” - AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.


Customer responsibility “Security in the Cloud” – Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities. For example, a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and, as such, requires the customer to perform all of the necessary security configuration and management tasks. Customers that deploy an Amazon EC2 instance are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance.


The following diagram shows the split of responsibilities between AWS and the customer:

Image Courtesy - AWS

Below are examples of controls that are managed by AWS, AWS Customers and/or both.


Inherited Controls – Controls which a customer fully inherits from AWS.

  • Physical and Environmental controls


Shared Controls – Controls which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives.

In the AWS shared security model, a shared control, AWS provides the requirements for the infrastructure and the customer must provide their own control implementation within their use of AWS services. Examples of shared controls include:

  • Patch Management – AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.

  • Configuration Management – AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.

  • Awareness & Training – AWS trains AWS employees, but a customer must train their own employees.


Customer Specific – Controls which are solely the responsibility of the customer based on the application they are deploying within AWS services.

Examples of customer specific controls include: Service and Communications Protection or Zone Security which may require a customer to route or zone data within specific security environments.


I hope this has provided a better understanding of what is expected from the customer with regards to security, compared to what is supplied and managed by AWS.


Stay tuned for more exciting content in our #100DaysOfAWS series!


Thank you for reading!


*** Explore | Share | Grow ***

43 views0 comments

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page