Shared responsibility model for infrastructure services

The infrastructure shared responsibility model is probably the most common model that AWS engineers are aware of today. It looks as in the following diagram and covers Infrastructure as a Service (IaaS) services, such as Amazon Elastic Compute Cloud (EC2):

Let me break this down a bit further to help explain what this diagram represents. The diagram is split into two very distinct sections—a green area and a yellow area. This color-split defines the division of responsibility between the customer (green) and AWS (yellow).

We can also see that the customer is responsible for maintaining security in the cloud and AWS maintains the security of the cloud. But what does that mean? 

Let's take a look at what AWS is responsible for:

• AWS global infrastructure: You can see that AWS provides security for the global infrastructure, including regions, Availability Zones, edge locations, and regional edge caches. This global infrastructure forms the physical data centers and point-of-presence locations that AWS uses globally to physically store your AWS resources. We as customers do not have physical access to AWS data centers; we are not allowed to turn up at the door of an AWS data center and ask to see our cloud resources. As a result, it is down to AWS to ensure that the physical security of their data centers meets stringent security controls and global security standards. 

• AWS foundation services: AWS also provides foundation services, as defined in the model, covering compute, storage, database, and network components. This means they are physically providing the hardware and underlying infrastructure to allow us as customers to create resources from the pooled hardware that AWS provisions. Again, as customers, we do not have access to these hosts, the physical infrastructure, or the underlying hypervisor software on each host. All access and security to ensure the separation of resources on a single host are controlled and managed by AWS. This helps to prevent their customers' EC2 instances from being aware of other EC2 instances running on the same underlying host, but being used by another customer. This segregation and separation of resources at the hypervisor level is managed by AWS.

So, within this infrastructure shared responsibility model, AWS provides global reach via various data centers, as well as provisioning the underlying hardware and infrastructure required to allow their customers to create cloud resources from the AWS provisioned and pooled hardware resources. These two components effectively make up the AWS cloud; as such, within this model, we can summarize AWS' responsibility as providing the security of the cloud.

Now, let's compare this to the customer's responsibility for providing security in the cloud.

Essentially, anything that we as customers provision by using AWS foundation services across the global infrastructure, we have ultimate security responsibility for:

Using the EC2 service as an example, let's look at each point relating to the customer's responsibilities from the preceding diagram:

• Customer data: The customer has to maintain the security of the data that they import into or create within their AWS environment—for example, any data stored on EC2 volumes, ephemeral or persistent.
• Platform, application, and Identity and Access Management (IAM): Any platform or application installed on top of your EC2 instance has to be secured and protected by controls configured and implemented by you as the customer. In addition to this, you are solely responsible for maintaining any access control to your EC2 instance and applications. AWS provides the IAM service to implement these controls, but it's down to you as the customer to implement effective security measures using the features offered by IAM.
• Operating system and network  and firewall configuration: As we saw, the responsibility of AWS ends at the hypervisor level. EC2 instances fall within the infrastructure model, and so maintaining the security of the operating system itself is the customer's responsibility. As a result, the customer must maintain and implement patching for the relevant operating system. EC2 instances are deployed within a VPC, and therefore, network configuration, including firewall restrictions, such as security groups (which are effectively virtual firewalls operating at the instance level), have to be configured and associated appropriately to protect your EC2 fleet.
• Client-side data encryption and data integrity authentication: This relates to the protection of data generated by or stored on your EC2 instances via an encryption mechanism. If you plan to encrypt your data, you as the customer are responsible for doing so.

• Server-side encryption (filesystem and/or data): Again, if you plan to use any form of encryption to protect your data using server-side mechanisms—perhaps through the use of the Key Management Service (KMS), which will be discussed in-depth in a later chapter—it is down to the customer to use the service effectively for data protection.
• Network traffic protection (encryption/identity/integrity): When network traffic is being sent to and from your EC2 instance, you can configure, where applicable, to encrypt the communications with a protocol such as SSL or HTTPS.

So, in summary, when working with services that fall within the infrastructure shared responsibility model, AWS is responsible for the security of the cloud, which includes everything from the hypervisor stack and below. The customer is then responsible for security in the cloud, which starts from the operating system stack and up.

Understanding each of these models will help you define a more robust security strategy and strengthen your security posture across your AWS account. Fully understanding what you are responsible for and what AWS is responsible for will help to ensure that you are not left open to any unexpected vulnerabilities.