The 3 Keys to AWS Account Security

Posted on June 22, 2018 by PhilZonaPhilZona

Cyber threats can be scary, but security doesn’t have to be. Taking a few basic steps in your AWS account can almost entirely eliminate most of the common threats you’ll face online. Much of the work in implementing security measures comes down to simply having processes in place, and then following them. Bugs will always hide in your application code, and even billion dollar enterprises have fallen victim to misconfiguration errors, but let’s start even simpler than that. Let’s talk about securing your AWS account.
Your Amazon Web Services account is the gateway to all of your infrastructure. Think about this: you use it to perform updates, maintain your application servers, and even to implement security on itself. So how are you protecting your account? Amazon says it plainly in their shared responsibility model: access control is your responsibility. A compromised account spells bad news, whether you’re running personal side projects or business-critical applications. It may result in lost data, lost profit, or even in the tamest of scenarios, a service bill that you can’t afford to pay.
Security in general is complex, but fortunately, AWS account security is not as daunting as it seems. There’s more to it than simply choosing a strong password though. If you want to ensure your data and infrastructure is protected from potentially malicious actors, here are three keys to start you off on securing your AWS account.

Protect your Root Account Credentials

You’ve heard this before: do not log in as your root user for everyday access! It bears repeating because it’s so important. The root user on your account has unlimited access to all Amazon services, including billing and identity and access management (IAM). If someone gets hold of your root password, they can quite literally do whatever they want to your infrastructure. They will have the ability to spin up thousands of dollars’ worth of servers, permanently delete any data you have stored on AWS, and even lock you out of your own account. In other words, you’ll be in for a really bad time.
So what’s the solution? First, ensure you’re using a secure password that includes letters, numbers, special characters, and is fairly complex. Since you should be accessing your root account only on very rare occasions, make it long; I have a 20 character minimum policy, but there’s no harm in using more. Use a password manager you trust to store it. This next part is important: enable multifactor authentication (MFA). Even if someone is able to crack your password, they should be prompted for a second form, which will ideally be a temporary token on your phone or another hardware device.
As Amazon says in their security checklist: protect your access keys the same way you protect your private banking access. Five minutes of time now could save you thousands of dollars in the future.

Create IAM Users with Limited Privileges

So, your root account is protected. Now what? The next step is to create IAM users for everyday activity. This is especially critical on accounts where multiple people will be performing different roles, but it’s important to follow this practice even on your own personal account. Create users with permissions that follow the principle of least privilege: each IAM user should only be allowed to access the services that are necessary to do what they need to do.
On a personal account where you’re the only regular user, you can use the Amazon-managed AdministratorAccess policy. This allows you to perform most tasks without logging in as your root user. For multi-user accounts, such as those in a business, you can assign users to groups that have varying levels of service permissions. For example, a support user who primarily helps customers troubleshoot their EC2 instances will likely not need permission to work with machine learning services, so don’t give it to them. Remember, you can always modify permissions temporarily, so if someone does have a need to access a restricted service, you can make that call on a case-by-case basis.
You can use the IAM console to set password requirements and enable multi-factor authentication, and you can use Access Advisor (within IAM) to analyze when a user last interacted with a given service. This can be a handy tool in evaluating whether their groups and policies are too permissive. Amazon also recommends requiring users to rotate their access keys at least once a year, although depending on what’s in your account, you might want to have them do it more frequently.

Enable CloudTrail Logging

After you’ve locked your access management down with IAM policies and groups, what if someone’s account is compromised? It could certainly happen, although your chances are now much lower. And if it does, logging will be your best friend when determining when and how it occurred. CloudTrail is a service that allows you to monitor every single action taken by every single user with respect to the Amazon Web Services API. If someone creates a new EC2 instance, you’ll know about it. If someone deletes a production database, you’ll know about that too. Just flip a switch, and you’ll start recording activity.
This helps you watch for account compromises, but is also helpful in the event of simple user error. In large accounts with dozens of users, leaving someone’s permissions just a little too open is well within the realm of possibility. And if that person accidentally does something they’re not supposed to, you can figure out when and how it happened. Perhaps they simply clicked the wrong button, or maybe someone else logged into their account somehow. While your next actions in these two situations might be quite different, having a detailed log allows you to determine how to fix the problem.
Keep in mind that CloudTrail log backups can be stored in S3, so be sure to restrict access to both the service as well as the bucket where it stores its data. Enabling CloudTrail will do you no good if a malicious user can log in and either turn it off or cover their tracks, so treat CloudTrail and log bucket access like you would any other critical service.

Next Steps

Security is an ongoing process, of course, and these three tips are only meant as a starting point. While nothing can make you invincible, following these best practices will put you on a path to better AWS account security.
Don’t forget to tune in to our LIVE webinar on Wed, June 27, 2018 at 10:30AM CDT – our Certified AWS Team will be discussing Security Automation as it relates to AWS Services including Config, CloudWatch, CloudTrail, & Lambda.
If you’re looking for further guidance, you’re in luck. We’ve recently announced our newest major content area, Security, which is full of courses to help you ensure you’re following industry best practices with respect to not only Amazon Web Services, but a number of other platforms. We’ll be adding more content to this section with our upcoming content release in July (over 150 new hands-on content!), so be sure to tune in to check out our newest courses and learn how to lock down your systems, protect your data, and rest easy, knowing that you’re safer from attackers.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *