AWS is a fantastic platform; it’s lean, efficient, and highly scalable – but NOT secure out-of-box. Without a few key security measures, you leave your AWS resources at serious risk.
While AWS’ security capabilities are nearly limitless, much of it will require some some real expertise to leverage successfully – but here are three relatively simple tips you can put into action today to secure your AWS accounts from the most common and prolific threats:
1. Enable Multifactor Authentication
I’ve harped on MFA time and again – and AWS is no exception. When opening a new account or creating a new user, enabling MFA should be one of your first moves. Studies from Microsoft have shown that MFA can block 99.9% of all hacking attempts; so even if your forgetful user does something they shouldn’t do and writes down their password on a Post-It note, a malicious actor can’t use that to get through without the second authentication factor.
Read Amazon’s official guide on enabling MFA here.
2. Don’t Use the Root Account.
Your root account is the “One Ring to Rule them All” – very powerful and vastly dangerous. This is the account that has access to do everything – control resources, open/close accounts, modify billing, etc. As such, compromising the root account is the holy grail of AWS account hacking.
Thankfully, the AWS IAM platform is so robust that you should realistically never need to use the root account (with very rare exceptions) after spending a few minutes to set up an IAM admin user instead. This way, you can still exercise effectively full admin control via IAM admin users – but even if the IAM admin were compromised, you’ve still got the root account in your back pocket as Godfather of all AWS.
Find Amazon’s guide to creating an IAM admin user and group here.
3. Apply the Principle of Least Privilege using IAM Permissions
When I once onboarded a client with an AWS instance hosting critical business assets, I almost had a heart attack: they had no MFA, they had a lot of 3rd-party developers with accounts, and they were ALL in the administrators group. Whoever had set them up was extraordinarily lazy and simply slapped admin rights on all the devs so they could do what they needed to do without bothering to consider the risk involved.
Of course, this was a red-alert security issue to the zillionith degree. I immediately set to work figuring out which dev needed some level of control over what assets, removed the blanket admin rights, then carefully assigned IAM permissions allowing each dev ONLY the precise control which was necessary – known as “the Principle of Least Privilege”. This prevents users from having more control than necessary – if an account is compromised, the incident does not have spiral completely out of control.
And of course, I capped off the experience by enabling MFA for all. Guess what? Nobody complained and all the devs continued to do their jobs without issue. It just took the willingness to put in a little work and think things through.
Managing IAM roles and permissions is a little more involved than a short guide can explain in one sitting – you can find AWS’ IAM repository here. Read it over and some research will quickly uncover the steps to address your use case.
Austin Thomé - Cloud & DevOps Engineer 