Secure your AWS Infrastructure: Part 2 - Setup Password rotation and enforce MFA

This is Part 2 of a series of guiding articles to show common methods used to protect AWS infrastructure.

If you have not isolated your environments yet in different AWS accounts, please read Part 1.

If you are building web applications and hosting on AWS today, chances are that you have different environments such as Internal - dev, testing, pre-prod, benchmark, etc., and External - production-eu, production-us, customer1, customer2, etc.,

It may be convenient to host all of them under 1 AWS account, say in 1 region or different regions. But this approach has severe disadvantages such as:

1. Single point of failure: Say one of your IAM key pairs are compromised. Having all resources in 1 account will put all resources in that account including production environment under risk.

2. Accidental access: If developers are using cloud resources for day to day development cycle, they may accidentally use wrong cloud resource IDs in their scripts or actions and end up modifying production resources which might cause downtime or data loss.

3. Unintentional permissions overload: While inviting users in IAM, it is very difficult to draft IAM policies to isolate resources and give access to them. So admins tend to give them administrator access temporarily to get the task done. This with humane error can stay for long and end up being a risk for the account.

4. Difficult to isolate costs: This is not a security concern but an operational concern. If all environment servers are running in the same AWS account, it is more difficult to analyse costs per environment (staging, test, prod) unless a good tagging system in place to isolate resources and analyse. It is also more difficult to isolate and set budget alerts for each environment.

It is a good step forward if you isolate servers of internal and external environments using different AWS accounts. Say you can have 1 AWS account to host production environment and another one for all your internal environments.

All the above concerns are solved to a great extent or easily handled if resources run in their own environment specific AWS account. No single point of failure, no accidental access, easy way to isolate costs (this time per account) and no permissions overload.

AWS has made it super easy to create and manage multiple accounts. Here is the overview of the process:

1. Create an AWS organisation: From your current single account, create a new AWS organisation. And set the current account as root account. Bills are centrally presented and settled in the root account.

2. In Organisations console from inside the root AWS account, create AWS sub-accounts. Say, one for each environment.

🎉 This will instantly elevate Cloud infrastructure security posture in your company. AWS organisation is free to setup. Checkout their documentation on how to create AWS org and sub accounts: https://aws.amazon.com/organizations/getting-started/

As the icing on the cake, in LocalOps, we have made it very easy for you to connect more than one AWS account as "Connections" and deploy test, staging, production, customer-1-us, customer-2-eu environments across unique AWS accounts. Checkout https://localops.co if you haven't done so and sign up for free if you want to manage environments and accounts seamlessly.

Follow us on X or LinkedIn if you want to stay tuned on next set of articles in this series.