Building a Production-Ready AWS Environment: Identity & Access Management (Pt. I)

As I continued working in my vulnerability management role, I knew that I wanted to move further into the world of engineering – so I decided to embark on the journey of becoming a Cloud Security Engineer.

I began to look at different certifications I could get – but I came to the conclusion that certifications aren’t as important as my ability to carry out the required tasks in practice.

In this series, I’ll document the process of building a project that demonstrates the required skills and components for a secure production-ready cloud environment in AWS.

1. Part I: Foundations – AWS account security, identity, and logging
2. Part II: Networking, private infrastructure, and secure connectivity
3. Part III: Compute, data, and secure service design
4. Part IV: Monitoring, detection, and operational visibility
5. Part V: CI/CD, policy enforcement, and hardening

The Importance of a Secure AWS Account

One of the foundational principles in cybersecurity is the Principle of Least Privilege – the concept that nobody should have greater permissions than they actually require in order to get their work done.

This prevents normal users from being able to carry out administrative or destructive actions, either through malicious intent or unintentionally. It also reduces the blast radius in case a user’s credentials are compromised, as the options an attacker has at their disposal are limited. This will be addressed by creating a dedicated IAM user separate from the root account. Root accounts should only be used for actions like closing down the AWS account or making changes to specific billing settings.

Because of the reasons listed, this project will begin by making sure the AWS account itself is secure using proper IAM methods before moving onto introducing networking and compute aspects.

The project’s environment will make use of roles, which will be given to users. Roles make access easier to rotate and rescind at any time, especially in environments that have a lot of users. IAM users will be grouped, with their permissions assigned at group level – this makes it clear as to who can do what.

Logging will also be an important part of this project, as it is important to be able to investigate incidents or detect misuse by users in the environment. CloudTrail will be enabled in order to track user actions across the environment, allowing for easier auditing.

Creating the Admin

I’ve logged into the AWS Console using my root account and I’m now ready to create a new user.

From here, I give the user the name admin as this will be my admin account. As mentioned earlier, having an admin account that is separate from the root account is a security best practice because in the case of credential compromise, it prevents an attacker from gaining total control over our AWS environment.

I’ve been given the option to set permissions – I’ll do this by adding the admin user to a group.

Here I’ve added the user to the group and given it the AdministratorAccess policy.

I can now review my options and click Create user.

Now that the admin user has been created, we navigate to the Security credentials tab and Assign MFA device.

I’ve given my chosen MFA device a name, and prepare Google Authenticator, which is my choice of authenticator app.

Once I show the QR code, scan it with my phone camera, and type two consecutive MFA codes, I can click Add MFA and my MFA will be setup.

I’ll click Enable console access to allow the admin to log into the AWS Console for this environment.

I’ll autogenerate the password and allow the user to create their own password.

Now that the admin account has been created, there’s no need to be in the root account anymore. I will now log into the admin account to carry out the rest of the process.

I navigate to the Console link, type in my username and autogenerated password, and proceed to reset my password.

Just like that, it’s done.

I’m now logged into the console and on the home page.

Introducing CloudTrail

Now that we’re in the admin account, we’ll enable CloudTrail, an AWS service that logs API calls and actions taken by an account. This creates an audit trail that helps with compliance, troubleshooting, and detecting potential misuse and unauthorised actions.

I’ve disabled Log file SSE-KMS encryption for this walkthrough, but on a production environment, it’s best to enable it.

I can also choose to audit Data events, Insights events, and Network activity events in addition to Management events, but I’ve left these boxes unticked for now.

I can now view my settings and click Create trail.

Now we’ve got a CloudTrail trail and it will log events to our newly created S3 bucket.

CloudTrail event history is powerful on it’s own and a good tool to refer to when tracking account activity.

In the next part, we’ll build a secure VPC with private and public subnets, routing tables, and strong network controls.