Overview of the AWS Shared Responsibility Model
AWS Shared Responsibility model explains how security is distributed between the customer and AWS
In this article, I am going to explain the AWS Shared Responsibility Model and talk about the practices that involve around this. In today’s competitive world, cloud computing is one the most desired technologies that more and more companies are focused towards. While some companies are lifting and shifting their existing infrastructure to the cloud, some has already been in the process of using the AWS services on a full fledged basis. Being on cloud seems intimidating, however, we need to take special care about security and compliance for the data that resides on the cloud. AWS Shared Responsibility Model is a practice defined by Amazon in regards to the security and compliance in the cloud and defines the responsibilities of the customer and the AWS.
The AWS Shared Responsibility Model is a collection of security practices that is divided between the customer and AWS such that they can stress less and take equal part in the cloud security and compliance. AWS is usually responsible for managing the global infrastructure of the cloud system including the hardware and networking modules. These can span across multiple regions, availability zones etc. The customer is primarily responsible for protecting data in the cloud, and maintaining patches in the operating systems etc. Let us learn more about both the responsibilities in details.
AWS Shared Responsibility Models
On a very high level, the shared responsibility models can be broadly classified into the following categories.
1. Infrastructure Services
2. Container Services
3. Abstract Services
Let us now understand in detail each of the above responsibility models.
Infrastructure Services
When considering infrastructure services, the first service that anyone can think of is an EC2 instance. EC2, also known as Elastic Compute Cloud is a service that allows customers to run virtual machines on the cloud. As we have understood that the primary responsibility of AWS is to provide security of the cloud, this allows AWS to secure their infrastructures across the world including multiple regions, availability zones and edge locations. This also extends to the devices that AWS uses for compute, storage, databases and network.
AWS runs several physical datacentres across the world. The physical access to these datacentres are controlled by AWS along with other facilities that provide necessary backup to these datacentres. For example, access to the power systems, Uninterruptible Power Supplies, HVAC systems, etc. are completely taken care by AWS. As a result, the burden of maintaining these gets rid of the shoulder of the customer and they can focus more on the business of what goes into the cloud.
Having said that, the customer is mostly responsible for managing the client and server side encryption of the EC2 instances, setting up the security groups and allowing specific access to the operating systems. The customers are also responsible for configuring the firewall and setting up the Identity and Access management (IAM) Users. As a best practice, least access should be provided to any user that is going to use the EC2 instances.
Container Services
Container services can be considered as an encapsulation on top of the infrastructure services. In these services, the maintenance of the operating systems are taken care by AWS while the maintaining the security and integrity of the systems is delegated to the customer. In any case, if your service requires to spin up an infrastructure service, it will do it under the hood. For e.g. consider AWS RDS as a container service which does not require the customer to install or maintain any operating systems. However, in the background, AWS already starts an EC2 instance in order to support your RDS instance. Container services are also termed as Platform-as-a-service or (PaaS).
In such an offering, the responsibility of maintaining the hardware and the operating systems is taken care by AWS. Also maintaining the various system patches and other activities like upgrading the systems and software is also done by AWS. The customer, while using the service needs to maintain the data encryption and also do the necessary security configurations like setting up the VPC and other configuration settings. The following diagram explains the responsibility model for the container services.
Abstract Services
The third category to focus within the AWS Shared Responsibility Model is abstract services. These services are also termed as software-as-a-service offerings. In these services, most of the security is handled by AWS itself and few of the features are to be taken care of by the customer. This is very helpful for the customers as they do not need to maintain the operational updates to the systems or the patches to the operating systems. However, the customer is still responsible to protect the data by applying proper IAM roles and policies within it. The customer should also control that no unauthorized access is being made to these services by maintaining healthy checks on the programmatic access credentials.
Amazon S3, DynamoDB, SQS are some of the services which fall under this category. The following diagram depicts some of the security features shared between AWS and the customer in an abstract services model.
Security from a customer’s standpoint
While in the previous sections of the article we have discussed the three layers of the AWS Shared Responsibility Model, let us now discuss some of the other important security features that the customers need to implement irrespective of the various shared responsibility models that they use.
· AWS Account Security Features
· Understanding Security Logs
Let us understand each of the above topics in some detail.
AWS Account Security Features
AWS offers a lot of security features within the AWS Account that the customers are advised to leverage in order to build a secure working environment within AWS. Some of the important features are defining appropriate roles and policies within the organization and then using those roles to assign to users and groups. This helps to control who has control over which services or resources within the AWS account. In order to access cross account resources, the AssumeRole service should be used that can be used to assume the role from another AWS account and perform some activities within another AWS Account.
To learn more about the AWS IAM Role and Policies, follow the official documentation.
Understanding Security Logs
Although we try hard to secure our services and resources within AWS, there are still chances of risking some security incidents. In such cases, it is extremely important to analyze the logs generated by the various services to identify the glitch and take proper actions to fix it so that the vulnerabilities are reduced. AWS offers a service known as CloudTrail using which you can analyze various logs from webservers and other services. To read more about AWS CloudTrail, follow the official documentation.
Conclusion
This article has explained in detail about the AWS Shared Responsibility Model that explains the tasks that take care about the security and compliance of data on the cloud. Although there are benefits in moving your applications to the cloud, there are some risks involved with the same and hence Amazon has featured the AWS Shared Responsibility Model, which explains the parts that the customer has to take care of and the ones that AWS will take care of. Using the AWS shared responsibility model, customers and AWS both are able to manage the security and compliance of the monstrous cloud ecosystem.
To know more about AWS Security and best practices, please read the whitepaper.
