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.
Not least, 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 then use those for interacting with AWS services.
You control the access permissions of the IAM principals in your account. One way you can do this is through identity-based policies that granularly define what actions a principal take take 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 your IAM principals have.
This responsibility extends beyond just identity-based policies. Some AWS 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 services 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 services, you're still interacting with AWS 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 services, it's time to dig into how it applies to the various resources you create under the core AWS services.
Amazon's flagship compute 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 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 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 runtimes they provide.
You're responsible for the security of:
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‚ 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's 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!
Test your skills. Learn something new. Get help. Repeat.Start a FREE 10-day trial