Operating within the AWS Shared Responsibility Model

When it comes to operating in the AWS cloud, both AWS and you‚ the AWS customer‚ share responsibility for the security of the data that you store and process in the cloud.

You may have heard the mantra, "AWS is responsible for the security of the cloud. You're responsible for security in the cloud." Although this is a handy generalization, it's not entirely accurate, as you'll see shortly.

It's true that AWS is responsible for the security of its services and the infrastructure that runs the AWS cloud. This includes the compute and storage hardware, the network infrastructure, the software that runs AWS cloud services, and the physical security of its data centers.

Practically speaking, the notion that you're solely responsible for "security in the cloud" means that you're solely responsible for the security of the resources you create using AWS. This, however, is not always the case. When it comes to security in the cloud, the line of responsibility changes depending on the service you're using.

In this guide, you'll learn some of the practical considerations for securely storing data and processing your workloads in the AWS cloud.

Let's start with a brief overview of how AWS controls access to its services.

When you create an AWS account, you start out with a single root user that has unlimited power within your account. And you're responsible for everything done under the auspices of the root user. In other words, from the outset, you're overwhelmingly responsible for the security of your AWS resources.

It is important to note that you're responsible for protecting the root user credentials, which AWS recommends not using unless absolutely necessary. Instead, you should use the Identity and Access Management (IAM) service to create IAM identities, or principals with more limited permissions, and use those for interacting with AWS.

You control the access permissions of the IAM principals in your account. One way to do this is through identity-based policies that granularly define what actions a principal takes against an AWS resource. AWS offers managed policies for a variety of common scenarios, and they routinely update them to cover new services and features. You can also craft your own custom policies. Either way, at the end of the day, you're responsible for defining the permissions for your IAM principals.

This responsibility extends beyond just identity-based policies. Some AWS cloud services use resource-based policies to control access to resources. Simple Storage Service (S3) bucket policies are a notable example of a resource based policy, and they're commonly used to grant public, read-only access to files stored in S3. As you might expect, you're totally responsible for configuring your resource-based policies.

Whether you use the root user or an IAM user, you'll access AWS using public or private service endpoints which are secured using HTTPS. One of the most well known public endpoints is for the Simple Storage Service (S3), Amazon's object storage service. For example, [https://s3.us-east-2.amazonaws.com] is the public endpoint for the US-East-2 region. AWS is solely responsible for the security of these endpoints.

Incidentally, when you use the web-based Management Console to manage your AWS, you're still interacting with AWS cloud services using service endpoints, but the Management Console is handling this interaction on your behalf.

Now that you've got the context for how the shared responsibility model applies to accessing AWS, it's time to dig into how it applies to the various resources you create under the core AWS cloud services.

Amazon's flagship computer service is the Elastic Compute Cloud (EC2). EC2 is Amazon's infrastructure-as-a-service offering that lets you create virtual machines called instances. Just as with on-premises virtualization platforms, the EC2 infrastructure includes hypervisors, block storage, pre-built virtual machine templates, and network infrastructure.

In EC2, AWS is responsible for the security of:

• The Xen and Nitro hypervisors that run EC2 instances.
• The physical hardware on which these hypervisors run.
• The Elastic Block Store (EBS) storage system that stores the EBS volumes that instances use for persistent storage.
• The physical network infrastructure that underpins the Virtual Private Cloud (VPC) virtual network infrastructure. This includes network connections to the internet, other regions and edge locations, and Direct Connect locations.

You're responsible for the security of:

• The software running on your instances, including the operating system and application security updates.
• Security groups and network access control lists (NACLs). Security groups control access to your instances and elastic load balancers. NACLs control access to individual subnets within a VPC.
• The network architecture within your VPC. In each region, AWS provides a default VPC that's preconfigured. You can use the default VPC as-is, but you don't have to. You can reconfigure it, or just create a new custom VPC from scratch. Either way, it's up to you to make sure the VPC is secure.

The AWS Lambda service provides functions-as-a-service, more commonly known as "serverless computing." Lambda abstracts away the underlying compute infrastructure, leaving you to concern yourself primarily with code and the runtimes needed to execute it.

You just write your function, using one of the supported programming languages, select the runtime you want to use, and configure a trigger to execute your function. Lambda takes care of the rest. Lambda provides runtimes for C#, PowerShell, Go, Java, Node.js, Python, and Ruby. You can also provide your own custom runtime.

When it comes to Lambda, AWS is responsible for the security of:

• The underlying compute, storage, and networking infrastructure.
• The runtimes they provide.

You're responsible for the security of:

• The code you run on Lambda
• Any custom runtimes you provide

AWS Simple Storage Service (S3) is Amazon's object storage service, which it commonly calls "storage for the Internet." S3 functions as a flat file system and offers two access control methods: access control lists (ACLs) and bucket policies.

For the most part, ACLs are a legacy access control mechanism to control access to individual files. They're not deprecated, though, and can still be dangerous, so it's up to you to make sure they're configured correctly. For your convenience, AWS offers preconfigured ACLs called canned ACLs.

Bucket policies, as noted earlier, are resource-based policies and are the recommended mechanism for controlling access to files in S3. Needless to say, you're responsible for the security implications of how these are configured.

Assuming you configure your ACLs or bucket policies correctly, AWS is responsible for enforcing them. AWS takes this responsibility seriously and has implemented a feature called Block Public Access that removes any ACLs or bucket policies that grant anonymous, unauthenticated access to files. You have to explicitly disable this feature to grant public access to files in your bucket.

AWS Relational Database Service (RDS) offers managed relational databases for a variety of popular database engines including MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, and Oracle. You select the instance and storage class to get the processing power, memory, and performance you need. RDS creates a database instance and gives you access to the database engine running on it.

RDS handles the maintenance and patching of the operating system and database engine. You control network access to the database instance by configuring security groups. You're also responsible for setting up database users and managing their permissions.

AWS is a service provider, not a consultant or an implementer. It is never the responsibility of AWS to ensure that your configurations, applications, or architectures are secure. AWS does offer tools, such as Trusted Advisor, to offer specific recommendations, but the applications you run and how you configure your AWS resources are ultimately your responsibility.

When in doubt about where you fit in the shared responsibility model, just ask yourself, "Can the root user control this?" If the answer is yes, then you're responsible for the security of whatever this is. The major consideration then shifts from "What am I responsible for?" to "How do I secure my AWS resources?" The next step is to learn how to apply security at all levels of your AWS environment. For that, check out my course Architecting for Security on AWS!