In the shared security model, aws is responsible for which of the following security best practices

One of the biggest cloud security challenges an organization faces is confusion over the division of security responsibilities. Not knowing who owns which tasks for ensuring security and compliance in a dynamic, distributed cloud environment can quickly lead to blind spots in an organization’s cloud security posture. In fact, according to the Oracle/KPMG Cloud Threat Report, 82% of organizations have experienced a cloud security incident due to confusion over the shared security responsibilities in cloud computing.

To help clarify the division of responsibilities and ease the burden of cloud security, Amazon Web Services (AWS) has established the AWS Shared Responsibility Model. Put simply, the AWS Shared Responsibility Model explains what AWS is responsible for securing in the cloud and what the customer is responsible for securing.

In this article, we’ll explain how the AWS Shared Responsibility Model divides security responsibilities between AWS and the customer, how this breaks down for different AWS services, and essential AWS security best practices to help improve your organization’s cloud security posture.

What are the levels of abstraction in cloud computing?

Before diving into the distribution of security responsibilities in the AWS Shared Responsibility Model, it’s important to define the different areas, or “levels of abstraction,” those responsibilities pertain to.

In cloud computing, levels of abstraction are layers of “encapsulated functionality,” with each level encompassing varying services and degrees of functionality available to the consumer.

To help explain, think about 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 relieved from the business—in other words, “abstracted” away from the business.

Today, cloud service providers offer numerous cloud services at varying degrees of abstraction that can offload responsibilities from the consumer. There are three primary levels of abstraction, otherwise known as the three main categories of cloud computing services: IaaS, PaaS, and SaaS.

Infrastructure as a Service (IaaS)

With IaaS, the cloud provider manages the infrastructure that is typically included in an on-premises data center, including the servers, storage, and networking hardware, as well as the virtualization or hypervisor layer. This is provided to the consumer via virtual machines accessible through the internet. Essentially, it’s a virtual data center in the cloud.

IaaS is the lowest level of abstraction, meaning the consumer has a greater degree of control, but also greater responsibility for security.

One of the most common AWS services at this level of abstraction is Amazon’s Elastic Compute Cloud (Amazon EC2).

Platform as a Service (PaaS)

Like IaaS, PaaS is typically managed by a third-party cloud provider, such as AWS. But with PaaS, the level of abstraction is taken one step further. AWS provides not only the underlying infrastructure (as with IaaS), but also a platform for customers to build, run, and manage applications.

Since the provider handles hosting and maintaining the infrastructure and development platform, developers have more freedom to focus on building and running applications.

PaaS is similar to other cloud computing services, such as function as a service (FaaS) or serverless computing, in that they also ” hide servers” from developers. Some of the most popular AWS services at this level of abstraction include AWS Elastic Beanstalk and AWS Lambda.

Software as a Service (SaaS)

At the highest level of abstraction is SaaS. With SaaS, the provider hosts applications and makes them available for customers to consume over the internet. SaaS is the level of abstraction most widely-known and understood by the general population, given most people interact with SaaS applications on a daily basis. Think Netflix, Salesforce, or Slack.

SaaS removes the need for organizations to install and run apps in their own computers or data centers and usually offers flexible payment structures, scalable usage, and automatic updates.

Bare metal services

Finally, at the other end of the abstraction scale are “bare metal services,” where businesses can deploy EC2 Instances directly onto AWS hardware rather than in a virtualized environment. As described by AWS, bare metal services can be valuable for customers who want “access to the physical resources for applications that take advantage of low-level hardware features that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware.”

This is foundational to the VMware Cloud on AWS service, which brings VMware’s enterprise-class SDDC (software-defined-data-center) software to the AWS Cloud with optimized access to AWS services. This enables IT teams to seamlessly migrate and run business-critical vSphere workloads in a familiar environment and modernize them with AWS services.You can learn more about the advantages of VMware Cloud on AWS here.

The AWS Shared Responsibility Model

So based on the levels of abstraction we just covered, how are security responsibilities in the cloud divided between AWS and the customer?

AWS is responsible for the security of the cloud and the consumer is responsible for security in the cloud.

As a general rule, AWS is responsible for security of the cloud and the consumer is responsible for security in the cloud. Let’s break that down a bit further. Below is a diagram that shows at a basic level the distribution of security responsibilities in the cloud based on the type of AWS services you’re consuming (IaaS, PaaS, or SaaS).

Most cloud consumers will use a combination of services across IaaS, PaaS, and SaaS, and with on-premises or hybrid cloud solutions, so it’s important to be aware of the division of responsibilities across each type of service.

While this diagram provides a solid overview of responsibilities, it can get more nuanced depending on the types of AWS services you’re using. To help provide more clarity, we’ll now cover a few more specific and commonly-used AWS cloud service offerings: EC2, containers, and Lambda.

AWS Shared Responsibility Model for EC2

The AWS Shared Responsibility Model in cloud computing 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’ security model (which parallels that of the IaaS model described above), AWS takes responsibility for the security of its global infrastructure and what it calls its foundation services: compute, storage, database, and networking.

With Amazon EC2, AWS is responsible for the security of:

• AWS foundation services: compute, storage, database, networking
• AWS global infrastructure: regions, availability zones, edge locations

With Amazon EC2, the customer is responsible for the security of:

• Customer data
• Platform, applications, Identity & Access Management (IAM)
• Operating system, network and firewall configuration (security groups)
• Client and server-side encryption
• Network traffic protection

AWS Shared Responsibility Model for containers

While 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 shared AWS security model for EC2 and containers is that AWS has abstracted the operating system and consequently, also assumes responsibility for the security of the operating system.

With containers, AWS is responsible for the security of:

• AWS foundation services: compute, storage, database, networking
• AWS global infrastructure: regions, availability zones, edge locations
• Platform and applications management
• Operating system, network configuration

With containers, the customer is responsible for the security of:

• Customer data
• Identity & Access Management (IAM)
• Firewall configuration (security groups)
• Client and server-side encryption (file system, data integrity authentication)
• Network traffic protection

What can complicate the AWS Shared Responsibility model for containers is the distribution of responsibilities for the control plane (container orchestration layer) and the data plane. Whether a customer is responsible depends on whether they’re launching containers on a user-managed fleet of EC2 instances (in which case, the standard model for EC2 still applies and the customer is responsible for security of the container control plane) or whether containers are launched on one of Amazon’s managed container services, ECS or EKS (in which case, AWS manages the containers’ control plane for the customer).

AWS Shared Responsibility Model for Lambda

In the shared responsibility model for Lambda, another level of abstraction is removed. Instead of businesses having to manage and run a full-blown EC2 instance to run 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.

With AWS Lambda, AWS is responsible for the security of:

• AWS foundation services: compute, storage, database, networking
• AWS global infrastructure: regions, availability zones, edge locations
• Platform and applications management
• Operating system, network configuration
• Data protection provided by the platform for data at rest
• Network traffic protection provided by the platform for data in transit

With AWS Lambda, the customer is responsible for the security of:

• Customer data
• Identity & Access Management (IAM)
• Client-side encryption (data integrity authentication)
• Function code and resource configuration

Learn more about AWS Lambda in our article: Serverless Computing: How to Optimize AWS Lambda Functions

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). Below are examples of controls managed by AWS, AWS customers, and/or both.

Inherited controls: The customer fully inherits these controls from AWS

• Physical and environmental controls

Shared controls: AWS provides the requirements for the infrastructure and the customer must provide their own controls within their use of AWS services. Examples include:

• Patch management: AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their operating systems and applications.
• Configuration management: AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.
• Awareness and 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).

Customer specific: Controls that are solely the responsibility of the customer based on the application they are deploying within AWS services. Examples include:

• Service and communications protection or zone security which may require a customer to route or zone data within specific security environments.

In this article, we’ve outlined the division of security responsibilities in the cloud between AWS and the customer as it applies to the AWS Shared Responsibility Model. There’s no one-size-fits-all solution to cloud security, but we’ll now offer some key best practices that are essential to maintaining a strong cloud security posture with AWS:

• Effective management of AWS accounts, IAM users, groups, and roles so that users have the appropriate levels of permission to access only the resources they need (law of least-privelege).
• Make sure user Access Keys are rotated frequently and that a strong password policy is enforced, such as requiring that passwords be changed at regular timeframes.
• Enable Multi-Factor Authentication for all accounts where possible—but especially those with root account access or that have access to business-critical or sensitive data.
• Encrypt data in transit and (where possible) data at rest to ensure that, if an asset is launched with a vulnerability or misconfiguration, any disclosed data is undecipherable and unusable.
• Limit the scope of users who can modify or delete data. This will avoid a scenario in which business-critical data is accidentally lost or deleted maliciously via a compromised account.
• Enable AWS CloudTrail—an audit trail service that records account activity so you can track changes to resources, demonstrate compliance, or troubleshoot problems.

For more detail and information regarding AWS security best practices, please reference the following resources: