This model is the way AWS frees the customer from the responsibility of establishing controls at the infrastructure, platform, and services levels by implementing them through their services. In this sense, the customer must provide full control of implementation in some cases, or work in a hybrid model where the customer provides their own solutions by complementing existing ones in the cloud:
The previous diagram shows that AWS is responsible for the security of the cloud; this involves software and hardware infrastructure and core services. The customer is responsible for everything in the cloud and the data they are the owner of.
To clarify this model, we will use a simple web server example and explain for every step which controls are in place for the customer and for AWS:
To create our web server, we will create an instance.
In the EC2 console choose Launch Instance:
Following are the details of the instance:
|
AWS/customer |
|
The previous example is an example of an inherited control (virtualization type) and a shared control (virtual image).
The next screen is for the configuration of the network attributes and the tenancy mode:
The following are the details of instance configuration:
|
AWS
|
Every instance runs in a virtual private cloud (Network) (1); the network is an infrastructure-protected service, and the customer inherits this protection, which enables workload isolation to the account level. |
|
Customer
|
Is possible to segregate the network by means of public and private subnetting, route tables function as a traffic control mechanism between networks, service endpoints, and on-premises networks. |
|
Customer
|
Identity and Access Management is the service dedicated to user management and account access. IAM Roles are meant to improve security from the customer perspective by establishing trust relationships between services and other parties. EC2AccessToS3Role (2) will allow an instance to invoke service actions on S3 securely to store and retrieve data. |
|
AWS/customer |
The Tenancy property (3) is a shared control by which AWS implements security at some layers and the customer will implement security in other layers. It is common to run your instance in shared hosts (multi-tenant), but it can be done on a dedicated host (single tenant); this will make your workloads compliant with FIPS-140 and PCI-DSS standards. |
The virtual private cloud (VPC) is an example of an inherited control, since AWS runs the network infrastructure; nevertheless, segmentation and subnet configuration is an example of a hybrid control, because the client is responsible for the full implementation by performing a correct configuration and resource distribution.
IAM operations are customer-related, and this represents a specific customer control. IAM roles and all the account access must be managed properly by the client.
Making use of dedicated resources is an example of shared controls. AWS will provide the dedicated infrastructure and the client provides all the management from the hypervisor upwards (operating system, applications).
The highlighted components represent the ones relevant for this example. Add a persistent EBS volume to our EC2 instance:
Security at rest for EBS with KMS cryptographic keys
|
AWS/customer |
EBS volumes can be ciphered on demand by using cryptographic keys provided by the Key Management Service (KMS); this way all data at rest will be kept confidential |
The EBS encryption attribute is an example of a shared control, because AWS will provide these facilities as part of EBS and KMS services, but the client must enable this configuration properties because by default, disks are not encrypted. The customer has the ability to use specific controls such as Linux Unified Key Setup (LUKS) to encrypt EBS volumes with third-party tools:
Create a security group to filter the network traffic:
Detail:
|
AWS/customer |
Security groups act as firewalls at the instance level, denying all inbound traffic and opening access only by customer-specified IPs, networks, ports, and protocols. It is a best practice to compartmentalize access by chaining multiple security groups restricting access on every layer. In this example, we create only one security group for the web server in which will be allowed HTTP traffic from any IP address (0.0.0.0/0) and restricted access via SSH only from a management machine—in this case, my IP. |
This is a hybrid control because the function of network traffic filtering is from AWS, but the full implementation is given by the customer through the service API:
Create a key pair to access the EC2 instance:
Detail:
|
AWS/Customer |
Every compute instance in EC2, whether Linux or Windows, is associated with a key pair, one public key and one private key. The public key is used to cipher the login information of a specific instance. The private key is guarded by the customer so they can provide their identity through SSH for Linux instances. Windows instances use the private key to decrypt the administrator's password. |
This is a shared control because the customer and AWS keep responsibility for the guarding of these keys and avoid third-party access that does not have the private key in their possession:
The last step has a dual responsibility:
- The customer must protect the platform on which the application will be running, their applications, and everything related to the identity and access management from the app of the middleware perspective.
- AWS is responsible for the storage and protection of the public key and the instance configuration.