As companies continue to invest in cloud transformation, the attack surface and exposure to new threats and unexplored risks can highlight gaps in knowledge and erode the confidence in workloads running in production.

This course highlights key areas of interest for security professionals, cloud engineers, and software developers, by providing a checklist of security best practices and personal recommendations, which can be leveraged to improve security posture while operating in the AWS cloud.

This unofficial AWS course consists of a checklist of security controls and opinions on best practices, which you can put in place to reduce the risk of running production workloads in AWS. It’s not presented in priority order, and you should feel free to skip to the relevant section for your needs. Every individual or business account structure will have their own risk profiles and you are best placed to know whether you should implement any of the recommendations within this course.
To get the most of the material in this course you should have a basic level of knowledge of AWS cloud, if you are just starting out on your AWS journey there may be better suited courses on the AWS Skills Builder platform - that is likely the case for more established security professionals also. However, I will endeavour to make the material as valuable and accessible as possible.
This course is never complete, and I will update it when new information or services are released which are worth writing about. Please feel free to reach out if there is a specific addition you would like to see, or if any of the information presented is outdated.
¡Vamos!

This unofficial AWS course consists of a checklist of security controls and opinions on best practices, which you can put in place to reduce the risk of running production workloads in AWS.

Introduction

Access to the root user account equates to the keys to the kingdom, the root user has unrestricted access to every service and resources within the AWS account. It’s important to protect access to the root user account, and the following options can ensure you can mitigate the risk while allowing for break glass access in the worst case scenarios.
Ensure that no access keys are created for the root user, if you already have access keys attached make sure to remove them. Only use the root account for changing configuration that only the root user can, such as enabling AWS support plans. There is no need for the root account to have API access. You should delegate access to IAM Roles, which can be leveraged by specific principals with the relevant trust policies attached.
Make sure to enable Multi-Factor Authentication (MFA) for the root user account. For an individual running their own AWS accounts a virtual device might be sufficient, but if your root user is for business AWS accounts I recommend using a hardware-based MFA device. You should store the hardware MFA device in a secure location, preferably a safe deposit box which only well-trusted individuals within the business can access - such as the Chief Technology Officer (CTO) and Chief Information Security Officer (CISO).
Use multi-user approved sign-in for the root user account. This is an administrative control where you separate who has access to the MFA device and who has the login credentials for the root user. In the MFA example above we have the CTO and CISO with access to the MFA device, but we wouldn’t want them to have the login credentials. A platform team might be the custodians of the login credentials in a password manager, and would need the CTO or CISO to access the account. This provides an extra level of protection, which may be suitable for companies with a low risk tolerance.
Store the root user credentials in a password manager. By using a password manager you can be restrictive over who has access to the credentials, but not tie them to an individual. It also allows for the password to be as complex as possible without anyone needing to remember it.
If you’re using AWS Organizations with multiple accounts you can now leverage a single root user account, instead of the old way of having a root user for every AWS account.
If you’re using multiple root users across your organization you can implement Service Control Policies (SCPs), which can restrict the root users from performing certain actions in all but the Management account.
Monitor root user activity. By enabling AWS CloudTrail in your account you can capture all API requests which interact with your AWS account, these events can be sent to Amazon CloudWatch for analysis. Within CloudWatch you can create an Event Rule which passes events to SNS through a Lambda or setup a CloudWatch Alarm based on a custom metric taken from the CloudTrail logs.
Utilise Amazon GuardDuty to create findings relating to root user usage. GuardDuty is used for threat detection, with continuous monitoring capabilities. If you’re using GuardDuty it will analyse various log sources within your account, including CloudTrail logs, and there is a finding type within GuardDuty in relation to root user activity “Policy:IAMUser/RootCredentialUsage”, and it will trigger any time the root user is used to invoke an API within your account.
<h2>Useful resources</h2>
<ul>
 <li>Best practices for root users: <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html" target="_blank" rel="nofollow">https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html</a></li>
 <li>Tasks that require root user access: <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks" target="_blank" rel="nofollow">https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks</a></li>
 <li>Centrally managed root user access: <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user-access-management" target="_blank" rel="nofollow">https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user-access-management</a></li>
</ul>

Access to the root user account equates to the keys to the kingdom, the root user has unrestricted access to every service and resources within the AWS account.

Protect the root user credentials

Unless there is an external dependency that relies on IAM Users and long lived credentials, do everything in your power to move away from their use. For principals that are people you should use Amazon Identity Center with short term credentials, and if you are using an external identity provider you can set up federated access with Single Sign On (SSO).
For principals that are services, both internal and external, you should provide access through IAM Roles. Make sure to leverage External IDs within the Trust Policy attached to the role for external access, this will prevent <a href="https://chrisdunne.com/post/prevent-confused-deputy-attacks-in-aws-with-external-ids" target="_blank">Confused Deputy Vulnerabilities</a>.
<a href="https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services" target="_blank" rel="nofollow">For deployment roles you can utilise OpenID Connect OIDC</a>, this can facilitate access through deployment roles which are restricted to only allow them to be assumed within the context of specific repositories in a provider such as GitHub. This is achieved by configuring a trust policy similar to the following on the deployment IAM Role.
<pre><code>{
&nbsp;&nbsp;&nbsp;"Version": "2012-10-17",
&nbsp;&nbsp;&nbsp;"Statement": [
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Effect": "Allow",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Principal": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Federated": "arn:aws:iam::&lt;account_id&gt;:oidc-provider/token.actions.githubusercontent.com"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Action": "sts:AssumeRoleWithWebIdentity",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"Condition": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"StringLike": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"token.actions.githubusercontent.com:sub": "repo:&lt;github_organisation&gt;/&lt;github_repository&gt;"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;},
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"ForAllValues:StringEquals": {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"token.actions.githubusercontent.com:iss": "https://token.actions.githubusercontent.com"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;]
}</code></pre>
Don’t forget about permission boundaries, which can be enforced through <a href="https://chrisdunne.com/post/when-to-use-service-control-policies-in-aws" target="_blank">Service Control Policies</a> (SCP). A permission boundary can allow you to define the maximum permissions a role can have, helping to limit the risk of privilege escalation.
<h2>Useful resources</h2>
<ul>
 <li>Security hardening with OpenID Connect: <a href="https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect" target="_blank" rel="nofollow">https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect</a></li>
</ul>

Unless there is an external dependency that relies on IAM Users and long lived credentials, do everything in your power to move away from their use.

Do not use IAM Users

Amazon S3 has been available to the public as a service since 2006, and it's been the target of some devastating data breaches over the years. It's a fantastic service, and it's what I use to host the frontend of this website, but S3 has also become the go to AWS service for security misconfiguration anecdotes.
It's important to understand how to keep your data secure when leveraging the Amazon S3 service, and one way to reduce the risk is to remove public access altogether for data stored in an S3 Bucket.
S3 Buckets are no longer public by default, and we can now enable <a href="https://aws.amazon.com/s3/features/block-public-access/" target="_blank" rel="nofollow">Amazon S3 Block Public Access</a> at the account level to be explicit in preventing public S3 Buckets. Of course this setting can be changed, but with the magic of <a href="https://chrisdunne.com/post/when-to-use-service-control-policies-in-aws" target="_blank" rel="nofollow">Service Control Policies</a> (SCPs) we can restrict the removal of this guardrail if we want to.
If we have assets that are meant to be publicly accessible, such as media or static web page files, we can provide access through CloudFront and <a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html" target="_blank" rel="nofollow">Origin Access Control</a> (OAC) or <a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html" target="_blank" rel="nofollow">CloudFront signed URLs</a>.
A nice bonus of utilising CloudFront, apart from its caching capabilities, is the ability to attach a WebACL, which is something we can’t do with direct S3 Bucket access.

It's important to understand how to keep your data secure when leveraging the Amazon S3 service, and one way to reduce the risk is to remove public access altogether for data stored in an S3 Bucket.