How to audit and secure an AWS account

5 min readAug 22, 2021

Data leakage and exposed credentials: these are just a couple of the cloud security concerns that keep cybersecurity pros up at night, according to Statista. Scary stuff indeed. That’s why investing the time in properly auditing and securing cloud environments should remain a top priority for any organization that values its continued existence. In this post, we’ll talk about how to audit and secure an AWS account. But where do you start when it comes to securing your AWS account?

AWS native tooling for securing your environment

Much of what you need to do to secure an AWS account can be done with the AWS-native tools at your disposal. What follows isn’t a comprehensive list, but these are some AWS-native tools that i finds most impactful in some of my work. We’ll talk about some of these tools in greater detail below.

Account and Organizations — This provides the strongest blast radius to limit the impact of a security event.
Access and Identity Management (IAM) — Managed access to services and resources with roles, policies, and users
Logging — Cloudtrail, S3 access logs, flow logs, CloudWatch logs
Infrastructure and Data Protection — VPC, Shield, WAF, Network Firewall, Macie, KMS, Certificate Manager, Secrets Manager
Security assessment, incident response, data protection, and threat detection — GuardDuty, Inspector, Confi, Detective, Artifact, Security Hub

How to audit an AWS account

As we dig into how audit and secure an AWS account, let’s start with auditing. Auditing an AWS account lets you review IAM users, roles, groups, and policies and see if there are any users or tools that have excessive permissions.

Auditing is crucial because you can’t secure what you’re not tracking. An audit is one of the most basic tools for securing an AWS account, but most of security is doing the basic things. (But, of course, the basic things can be hard.)

The things below are all accessible from day one in your environment.

1. Generate and maintain a complete list of assets

What is an asset? In the AWS space, an asset is anything that has an identifier. This could be policies, roles, and servers. We need to have a list of these. Once we have a list, then we can start figuring out what these things do, how we can protect these resources, and if any of them are misconfigured.

How to create an asset inventory

There are different ways to build an asset inventory. You could use third-party tools or CLI scripts, but there’s a quick and easy way: AWS Config. AWS Config lets you record and assess the configurations of your AWS resources.

2. Secure IAM

As part of auditing, take a look at IAM. IAM is often over-privileged, so we want to make sure we have a solid strategy on how we’re going to tackle that.

Identity and Access Management (IAM) basics

Similar to resources, users and roles are quite often over-privileged. Here are some basic considerations you should consider taking as a bare minimum:

Ensure you have password requirements configured.
Enforce MFA for all users, especially the root account!
STOP using the root account. It has no useful function that you can’t do with an actual IAM user or role — with the exception of setting the billing plan and changing its own address.
Use Access Analyzer to look for unintended access. You might see roles that have the ability to be assumed by outside entities, which you might not want…especially if it’s an account you don’t recognize.
Limit the use of IAM users as much as possible. They bring with them extra risk.
Use AWS SSO for human access. And build job-specific roles for humans to assume. It makes life way easier for developers.
Give your users access based on the job role, not the person.
Disable any role that hasn’t been used in 90 days or more. If no one complains in another 90, delete it.
Leverage open-source/third-party tools for IAM analysis.

3. Find public resources

Once you have a list of assets and have done a once-over on IAM, you need to start tackling public resources.

These are anything we’ve identified as public and are therefore points of risk. These can include S3, EBS snapshots, SNS, Databases, and more.

We see things like S3 misconfigurations, but there are other things that may be public that are dangerous but overlooked. For example, sometimes people take snapshots of servers and accidentally configure those to be public. We need to check these things!

Publicly available resources can cause data exfiltration, data loss, and unintended access to accounts and services. (Those are bad.) That’s why we need to identify publicly available resources.

Common resources that are unintentionally public include:

S3 buckets or objects
Snapshots
SNS topics
Databases
EC2 instances

“I’m going to make a very unpopular statement: there is no good reason that an S3 bucket should ever be public,” Don said. “No one has ever given me a good reason.”

To find public resources, you can use open-source tools, third-party tools, or AWS Config. But you have to go remediate them.

Here are some quick and easy wins you can do right out of the box. These are Don’s bare minimum to start with:

Enable S3 Public Access block on the account level
Turn on GuardDuty
Use AWS Firewall Manager to apply common IP security rules to all VPCs
Leverage managed config rules, but don’t be afraid to write your own!

4. Use AWS Organizations

Recommended AWS Organizations structure

AWS Organizations is an area that is one of the most underrated things you can do for security. This is one of the most powerful tools in your security toolbox.

The account is the border. You have to allow things in and out of the account. You can’t say that with anything else that you have in AWS. Even with VPCs, you have to take extra steps to make it more secure than it is out of the box. With an account, by default, nothing comes in or out unless you allow it. We use these as service accounts for specific pieces of our tech stack. Each team or service has an account.

Root / Management Account — hosts the Organization:

Production OU, Pre-Production OU, Build OU, Development OU: Each has one account per service or service
Operations OU: Corp systems accounts (billing, internal IT, etc.), DNS account — delegates subdomains to other accounts
Security OU: Security account — owner of all security tools (GuardDuty, SIEM, Config, etc.), Logging account — source of truth for all logs used by security
Suspended OU: This is where we keep closed or unused accounts, Has SCP to prevent any action from being taken.

Well there's more steps ahead to be explain but i will make it on my Part 2 of this post for how to secure the AWS account, so stay tune and thanks for reading the article! Don't forget to clap and share this article!