AWS Intro – 1. Account Setup

This is a guide for starting your AWS setup and by in large covers the areas you must look into to build robust security and cost-optimized AWS setup.

Any single account setup is a bad idea which is going to bring numerous issues as you grow your platforms and applications and not only goes against AWS Best Practices, you are exposing your setup to huge security risks and you won’t be able to properly isolate your AWS setup.

Think of your AWS Account setup the same way medieval castles were designed.

That is, oversimplifying walls within walls isolating critical areas from each other so if one area of the castle was compromised the blast radius of the compromise was contained to that specific area.

How do we apply this principle to AWS, separate the accounts according to logic which isolates them from each other and in case of an account level compromised you have a reduced blast radius of the compromise.

For this above example, your Production environment will be completely isolated from Development and Testing on different AWS Accounts and will have different access levels which give you the advantage, some bullet points:

• Different levels of access at the environment level mean that your Developers can change anything on the Dev Account and only have Read-Only access to the Production environment.
• Development environments are prone to have platforms or applications which aren’t 100% on security bugs etc and are at a higher risk of compromise.
• Having production and development data on the same AWS account is a risk since an error in configurations or code could lead to unwanted consequences, plus the risk of exposure.
• You cannot set proper permissions unless you break development, you have AWS IAM Policies which you can apply to users groups and roles on AWS, but, having 2x environments on the same AWS account means you have to be more restrictive to what developers can do and this will block them.

When you create your AWS Organisation the account you are logged in to will be assigned the role of “Master” where you will create additional Organisation accounts and also add existing accounts if you choose to which will allow you to easily consolidate billing, but also set up your OU (Organisational Unit) structure so you can set up policies and settings accordingly.

Let's now look at the different types and purposes of the AWS accounts; In the case, you have decided to set up your account structure throughout multiple accounts

MASTER AWS ACCOUNT as we mentioned above this is the main account that by design will have access to all other accounts, leave the access to this account only to AWS Administrators with MFA enabled on all accounts as a minimum. I’ve seen some implementations where the user accounts are also here but the users themselves have very specific and limited access, but, configuration errors could cause compromise so we recommend users to be on a separate account.

DEVELOPMENT AWS ACCOUNT we recommend them to be separate accounts as well, the rationale is that DEVELOPMENT is the area for your developers to have the freedom to build and change whatever they want to ensure autonomy as opposed to having very limited and restricted access, we want the developers to have the freedom to experiment and create PoC’s very quickly and autonomy, which is the opposite for any other accounts.

STAGING; INTEGRATION; TESTING AWS ACCOUNT makes sense when there are many different development teams using different dev AWS accounts, you want to have a more stable environment for testing and integration testing (since dev is constantly changing) or for any other valid reason, this type of account will begin to give more limited access, ideally, you can only deploy and change the platform trough your CI/CD pipeline and this gives you a taste of what will happen when you deploy to Production.

COMPLIANCE & GOVERNANCE AWS ACCOUNTS is where all the configurations and logging information from other accounts is stored, a good example is, a hacker will try to delete all tracks to prevent them from being detected and traced, having these accounts isolated and with different levels of access to a very restricted number of users allow you to protect this information much more efficiently and again contribute to a smaller blast radius in case of compromise.

PRODUCTION AWS ACCOUNTS on this example we display 3x different accounts, one for your actual platform where only very limited access is in-place (PRODUCTION AWS ACCOUNT) one for your Data Backup, a most recent Ransome Attack trend involved encrypting the customer data removing its access to it, plus you will secure your data on a different AWS Region (BACKUP AWS ACCOUNT) and lastly your Logs should be stored separately to avoid tampering (LOGS AWS ACCOUNT).

Setting this up by hand is obviously a time-consuming task. This is why AWS introduced AWS Control Tower which allows performing a very advanced setup without the hassle of doing this by “hand”, we will cover this in more detail in another article.

Check out our page on Boldlink.io or follow us on LinkedIn here for a series of articles on the same — on AWS code & Automation and Security.