Shared responsibility model

In the cloud, we can define stakeholders in two categories:

• Cloud provider: This is the one who provides cloud services
• Cloud consumer: This is the one who consumes cloud services

In cloud security, compliance is defined on the shared responsibility model. Here, the cloud provider is responsible for managing security and compliance at the physical infrastructure level, hypervisor level, physical network level, storage level, and orchestration layer. 

The cloud consumer assumes responsibility for managing security and compliance from the virtual machine level to the application level.

In AWS it's a bit more clarified, and here the security responsibility model is defined in three different categories:

• A shared responsibility model for infrastructure 
• A shared responsibility model for container service 
• A shared responsibility model for abstract service

Let's see the broad shared responsibility models of AWS:

In the shared responsibility model, the cloud provider (AWS) is responsible for managing security and compliance at the data center level or the physical infrastructure level, such as server, storage, and physical network.

The cloud consumers (end users) will be responsible for managing security and compliance from the guest OS level (security patches and updates); VPC security, such as configuration of security groups, network access control lists (ACLs); and other software configuration, as well as the integration of other services (for example, RDS, S3, Simple Queue Service (SQS), Simple Email Service (SES), and more).

In the shared security model, AWS is responsible for the security of infrastructure where all the AWS cloud service offering is running. Here, the infrastructure consists of all the hardware, software, and the physical perimeters.

The customer's responsibility is determined on the basis of the services they subscribe. For example, if the customer subscribed the EC2 instance, they need to ensure security of the guest OS and configuration. For S3, they need to define the ACL and roles. Similarly, for the RDS, they need to define passwords, security group policy, encryption, and backup policy.

For the customers to ensure the security at each level, there are many services that are already available, such as AWS Config, Trusted Advisor, IAM, X-Ray, and Macie, which helps to make your security work easier.

Now, let's look at the previously mentioned categories of the shared responsibility model.

Shared responsibility model for infrastructure 

In this model, AWS is responsible for securing its virtualization, server, storage, physical network, and data center. The customer who has subscribed to the infrastructure service is responsible for defining security from the guest OS, application level, virtual network (VPC) level, data level, and finally, the user access level.

Shared responsibility model for container service

In AWS, we have container-based services. In computing, we have ECS, for databases, we have RDS, and so on. Here, AWS security responsibility goes higher up to the guest OS and platform level. Similar to RDS, AWS is responsible for managing security from the physical level to the database application level. Customers are only responsible for defining security at a subnet level, security group, encryption and password policy, and IAM roles.

Shared responsibility model for abstract services

AWS also provides abstract services such as SQS, SES, Simple Notification Service (SNS), and S3. For all these services, AWS is responsible for the complete security of the physical layer, virtualization layer, network level, storage, OS, software, and so on. Users or consumers need to define only the user-level permission and encryption if it is applicable for the service.

Now, let's understand the shared responsibility model in the cloud from the service perspective.

In IaaS, the cloud provider is responsible for only managing the physical infrastructure and security at the physical level. Being a user, we are responsible for the following:

• VM level security 
• Application and data security
• User management
• Virtual network level security

In the case of IaaS, the API plays a significant role, as all the internal components talk to each other using the API via HTTP methods: GET, PUT, and DELETE. The API enables cloud consumers to access the service using the REST API (available in all the clouds). We will look at the use of APIs in the automation section and also learn about how automation uses APIs to speed up deployment and enhance security.

In the cloud, we have multiple options to apply security on all the aforementioned levels but it completely depends on us as to how we are utilizing it.

In the PaaS model, the cloud provider responsibility increases; it is responsible for managing the platform too. Here, the platform denotes the environment on which our application will run. For example, most of the cloud providers have Database as a Service. Here, the cloud provider is responsible for managing the physical infrastructure, compute, and OS level security. Being a user, we will focus on user management, virtual networks, and data security. 

In the SaaS model, the cloud provider is responsible for providing end-to-end security until the application levels. We are only responsible for ensuring user management and data security. In AWS, there is no SaaS service, which is a part of the AWS cloud offering, but there are many partners who provide SaaS services. AWS equips you to ensure maximum security for your SaaS offering as well.