The AWS Shared Responsibility Model defines the distribution of responsibilities for security in the cloud between Amazon Web Services (AWS) and the customer. It’s important to note the distribution is not static, but varies according to the services deployed on AWS and their level of abstraction.
One of the biggest concerns influencing businesses’ adoption of the cloud is to enhance security. Amazon Web Services (AWS) tries to ease the burden of security in the cloud via the AWS Shared Responsibility Model, in which the company takes responsibility for security in some areas of cloud operations. However, the distribution of responsibilities between AWS and customers isn’t always crystal clear because it’s dependent on the “level of abstraction”.
What are levels of abstraction in cloud computing?
In cloud computing, levels of abstraction are layers of “encapsulated functionality”. To put this into layman’s terms, when businesses started renting physical servers from internet data centers at the start of the century, the hardware was provided by the internet data center and the need for a secure physical hosting environment was abstracted away from the business.
Then, when AWS launched Infrastructure-as-a-Service (IaaS), the hardware level was abstracted. Businesses’ infrastructures were provided for them, and their security responsibilities were confined to the operating systems and applications run on them. Security in the lower layers of encapsulated functionality (i.e. the physical hosting environment and hardware) became the responsibility of AWS.
And so it goes on. Platform-as-a-Service (PaaS) abstracts the operating system, and Function-as-a-Service (FaaS) abstracts the language runtime. As a general rule, the higher the level of abstraction, the more AWS has responsibility for security in the cloud. There are exceptions (i.e. AWS Fargate), but it’s a good basis on which to start explaining AWS’ Shared Responsibility Model.
The AWS Shared Responsibility Model for EC2
The AWS Shared Responsibility Model for EC2 is the model most businesses are familiar with because it’s easier in this model to understand the concept of ‘Security of the Cloud versus Security in the Cloud’. In this version of AWS’ Shared Responsibility Model, AWS takes responsibility for the security of its global infrastructure and what it calls its foundation services: compute, storage, database, and networking. As the table below shows, businesses have responsibility for the security of everything else.
In addition to the distribution of responsibilities for security, there’s also a distribution of responsibilities for controls. AWS’ responsibility relates to its physical and environmental controls. Businesses’ responsibilities relate to service and communications controls (i.e. IAM controls). There’s an element of “shared” responsibility in other areas of control, but these are “shared” in name only. Examples include:
- Patch Management: AWS is responsible for patching and fixing flaws within its global infrastructure, but businesses are responsible for patching their operating systems and applications.
- Configuration Management: AWS maintains the configuration of its infrastructure devices, but businesses are responsible for configuring their own guest operating systems, databases, and applications.
- Awareness & Training: AWS trains AWS employees, but businesses have the responsibility for training their own employees and enforcing cloud security best practices (or engaging a third-party to train employees on their behalf).
The AWS Shared Responsibility Model for Containers
Whereas an EC2 Instance virtualizes a piece of hardware so businesses can run dedicated operating systems, container technology virtualizes an operating system so businesses can run separate applications with different, and often incompatible, software dependencies. So the difference between the AWS Shared Responsibility Models for EC2 and containers is that AWS has abstracted the operating system and consequently assumes responsibility for the security of the operating system.
What complicates the AWS Shared Responsibility Model for containers is the distribution of responsibilities for the control plane and data plane. This depends on whether a business launches containers on a user-managed fleet of EC2 Instances (in which case the model for EC2 still applies) or whether containers are launched on one of Amazon’s container services (i.e. EKS) that eliminates the need for businesses to manage the containers control plane.
The AWS Shared Responsibility Model for Lambda
The AWS Shared Responsibility Model for Lambda sees another level of abstraction stripped away. Instead of businesses having to manage and run a full-blown EC2 Instance to run their code, or having to track software dependencies in a user-managed container, Lambda allows businesses to upload their code and let AWS figure out how to run it at scale. As a result, AWS assumes the responsibility for the security of data at rest on the platform, and data in transit through the platform.
Where bare metal Instances fit in
At the other end of the abstraction scale is “bare metal services” where businesses can deploy EC2 Instances directly onto AWS hardware rather than in a virtualized environment. This end of the scale is similar to the days when businesses would rent physical servers from internet data centers, and consequently businesses assume responsibility for the security of the Foundation Services and each encapsulated functionality above the Foundation Services layer.
Massimo Re Ferre—a Principle Solutions Architect at AWS—visualized the different levels of shared responsibility according to the level of abstraction (below). He states in his blog that businesses who have reached maturity on their cloud journeys are more likely to use highly-abstracted services, while others will likely use less-abstracted services - possibly explaining why CISOs of recently-migrated businesses experience sleepless nights.