We agree that cloud security is a very broad topic. However, there are several security ground rules that we believe all cloud users should be very well aware of and have actually implemented.
Now, let’s dive right into the fundamentals of securing your AWS setup!
Enable Multi-Factor Authentication (MFA) On Your Root Account
It might sound like a cliché to you already: “add MFA to your root account!” But believe us or not, from time to time, we still hear horror stories from our clients. They tell us how they lost access to their root account because of a cracked or leaked password or how someone changed the root email without their knowledge. Changing root email back is possible through AWS Support and the fraud detection department, but it is not instant or effortless.
If that does not sound stressful enough for your taste, how about a compromised root account gaining access to all your AWS resources and storing potentially sensitive data in that account? In such a case, GDPR requires you to inform your local data governance organization about a potential data breach and also – inform your customers too. Now, that does not sound nice, right?
So, our advice is – to add MFA to your root account! But what is that MFA, and why a strong password is not enough? Well, MFA adds a security layer on top of your password. Two factors consist of something you know and something you own. Without having access to your second factor (that’s why it is sometimes called 2FA) – in this case, your unlocked phone – password is useless, and there is no way to log into your account.
So, there is no way around it – you have to do it. Otherwise, the troubles will get to you sooner or later. Fortunately, setting up an MFA isn’t hard at all. Simply log into your AWS Console with a root account, head over to the IAM dashboard, and click on the message stating that your root user has no MFA set up. Then, link a 2FA app like Google Authenticator with this root account, and you are all done here! Here’s a step-by-step guide.
Now, you can sleep better knowing that at least this attack vector is somewhat mitigated. And it wasn’t that hard, agree?
Protect Your Root and IAM Users
As you might know, a root user is not the only type of user in AWS – there also are IAM users. These are used mainly by real people and less often by systems and services. The latter should use roles instead, but we’ll get there in a minute.
Every IAM user is advised to have MFA enabled the same way you did for your root account. You can check the MFA status in the IAM Users view. Kindly ask all your users to be more secure by enabling MFA on their accounts. Alternatively, you could create security policies that require users to have MFA set up in order to access AWS services virtually enforcing the change.
Once MFA is set up on IAM users, you’ve added an additional layer to ingress protection. But security tips are far from over, and we have at least a few more things that can’t be looked over.
Get the latest articles and news about AWS
Use Roles to Access Other AWS Accounts
We mentioned IAM roles very briefly already but now let’s look at them and see why using them is essential and considered the best practice.
A role is a type of credential with permissions policies already attached that are assumed by other AWS services or IAM users. They differ from a regular IAM user because they do not have passwords at all.
So how do they work then? Well, each AWS service or IAM user that wants to assume a specific role has to have permission to do so. AWS services can be assigned to use specific roles, while IAM users have to have a permission policy to assume that specific role by configuring STS (Security Token Service) trust between the user and the role.
This approach is used when another AWS service, for example, an EC2 instance, wants to access an S3 bucket – that EC2 instance would be allowed to assume a particular role with permissions to interact with S3.
In another example, an IAM user would like to access resources in another AWS account. In such a case, that user would simply need to have permission to assume that particular role, while on the other account, a role would be created with required permissions and a condition letting that specific user assume it.
Since roles do not have passwords and only use temporary credentials passed between API calls in a secure manner, roles are much safer to use. Give them a try and set up your first role!
Isolate Your Environments in Different AWS Accounts
Another step towards a more secure AWS setup is to isolate your different environments (think production, staging, development, testing, or other) into different AWS accounts. These are entirely separate AWS cloud entities that share nothing in common.
Operations in such a manner are much more secure as you mitigate the risks of different environments accidentally hijacking resources, namespaces, IPs, databases IO, network balancers, or anything that your production workload uses and that might disturb the user experience that you work for so hard.
We also recommend isolating other important parts of your AWS infrastructure by having a dedicated AWS account for your IAM users so you could manage them from a single pane; and also, to have a safe place to store all your logs. These two accounts should have minimal access so only authorized people could change user permissions or read logs. Important – don’t forget to set MFA for each of the AWS accounts root users!
What about the billing having several AWS accounts then, I hear you ask? Under Cloudvisor, we will easily consolidate your different AWS accounts’ spending into a single consolidated bill, so you don’t have to worry about your expenses being scattered around. On the contrary, you will have clear visibility into the total expenses of each of your environments without the hassle of tagging all the resources.
The Takeaway
So, did you learn anything new today? Although these were just a few of the most important concepts you should employ while working in the AWS cloud, we really do hope so.
We also believe that every customer should take their security seriously – and no, talking is not enough! – to not become another victim of malicious actors because they ignored these few security ground rules. This advice comes from our day-to-day consulting experience and not-so-lucky customer stories, so we strive to raise our customers’ awareness of security by compiling this list.
Stay safe in the cloud!
