Consider the example of RDS. In this case, customers do not have access to the underlying operating system that the RDS databases are running on. As such, customers cannot patch the operating system. This security task has been shifted from the customer to AWS. In addition, platform and application management have also been passed to AWS. This is because RDS is a managed service, and as a result, all the application maintenance is undertaken by AWS. This takes a huge administrative burden off the customer but also simultaneously introduces a level of restriction, as they are only presented with the platform and everything above the stack.
The final model you will examine is the abstract shared responsibility model shown in Figure 1.5:
Figure 1.5: Shared responsibility model for abstract services
Right away, from a visual perspective, it is apparent that the shift in responsibility leans even more heavily toward AWS.
This model retains the level of security AWS must manage from the previous two models (infrastructure and container) and adds server-side encryption and network traffic protection. The following are some examples of services in the abstract model:
These are defined as abstract services as almost all the control and management of the service is abstracted away from the end customer; you access these services through endpoints. Customers do not have access to the underlying operating system (infrastructure) or the actual platform running these services (container). Instead, the customer is presented with the service frontend or endpoint configured as required.
As a result, the customer is totally abstracted away from maintaining security updates for the operating system or any platform patches and security management. This also means that with services that fall in this model, AWS is responsible for implementing and controlling any server-side encryption algorithms, such as Amazon S3 Server-Side Encryption (SSE-S3). Therefore, the customer has no control over the access keys used for this encryption method—it is all managed by AWS.
Further, AWS will manage the secure transfer of data between the service components, for example, when S3 automatically copies customer data to multiple endpoints across different availability zones. As a customer, you have no control over this data transfer, so AWS must secure the traffic.
You have decided to store some static documents and data in multiple S3 buckets since S3 is both optimal for blob storage and cost-effective. AWS already manages the S3 platform and keeps the application and operating system patches up to date.
Once you decide to place one of the documents into a particular bucket, you need to refer to your organizational policies to see if encryption at rest is required. Your first decision is whether you will do client- or server-side encryption. If you decide to use client-side encryption, you will need to generate a pair of keys (if a pair is not already available), encrypt the document, and then upload the encrypted payload to the S3 bucket.
Suppose you decide to go with server-side encryption. In that case, you must either provide your own Customer Managed Key (CMS) using Key Management Service (KMS) or use the Amazon-managed key to encrypt the data once it is placed into the bucket.
Now that the data has been added to the bucket, you, as the bucket administrator, need to decide who will gain access to this bucket and how you will control this access. You can create an IAM policy if access is limited to internal users. If users from another organization need to access the data and documents, you will craft a bucket policy with the correct permissions.
To summarize this example, in the abstract services shared responsibility model, the customer manages their data, who has access to it, and the encryption settings.
With an understanding of the shared responsibility model for abstract services, you can now delve into how using and understanding these models can help you when dealing with audits or auditors.