Guest Contribution by Claire Jane Ward

Amazon Web Services (AWS) is one of the most popular secure cloud services platform, whether it’s for running application servers or hosting dynamic websites. But just because AWS offers good security out-of-the-box, doesn’t mean AWS doesn’t have its own security issues to be aware of.

Thus, the onus is on the end-user to ensure that you are following the best security practices, and there are many great security practices to adopt when dealing with a cloud service platform like AWS – enough to write a manual and offer some kind of webinar training classes. But in this article, we’re going to keep it brief, and highlight just 4 great security practices for AWS you can start practicing today – like, right now, after reading this article.

Go through user privileges with a fine-tooth comb

This security practice commonly applies to many shared-access workstations and environments, and it’s no different in AWS’s Identity and Access Management dashboard. When adding users, you should only grant the minimally required privileges. Even if you personally trust your workers with elevated privileges, giving the minimal privileges necessary will significantly reduce potential damage if any of those user accounts fall into the wrong hands.

To save a little bit of time, you can create user groups instead of going through each individual IAM user. Set the minimal permissions necessary for the IAM group / roles, and then assign individual IAM users to these groups. This not only has the benefit of saving a bit of time, but ensuring that all individual IAM accounts are accounted for and no individual privileges slip through the cracks.

Take proper steps to become PCI compliant

While AWS does offer PCI-friendly solutions, hosting your data on the AWS cloud does not automatically make you PCI-compliant, despite some popular belief. It’s a bit more involved than that, and there are further steps to take to guarantee that your AWS account is PCI compliant – you can find out a lot more information here.

Use the AWS root account only when absolutely necessary

The root account (the main account created during registration to AWS) has the most privileges of any account type, and thus for the sake of security, it should be the least used – as in, it should be used only for actions that absolutely require the AWS root account.

It is recommended to create an alternative administrator account with all the privileges you need, then put the root account behind some type of Indiana Jones and the Temple of Doom security, where a skull-shaped gemstone must be placed on a pedestal at exactly midnight to unlock the stone vault. This isn’t even hyperbole. Lock it up and swallow the key.

Furthermore, you should frequently rotate the root account access keys (and all IAM accounts in general, to be honest), as well as enable MFA (multi-factor authentication). The steps to rotate access keys are fairly simple:

1. Log into the AWS Management Console, and create a second access key.
2. Update all apps to use the new access key, and make sure all apps are still working.
3. Toggle the previous access key to ‘inactive’ state, and re-verify your apps.
4. Delete the inactive access key.

Regularly prune unused IAM accounts

I can’t begin to tell you how many client websites, spreadsheets, company email addresses, and other log-in areas I more than likely have access to, despite not working for some of those clients for months or years. I still periodically get updates in one of my alternate emails from a client’s YouTube account, where we published promotional materials for their online RPG game ~5 years ago.

What if I was a disgruntled employee? See where I’m going with this? There’s no reason I should still have access to any of those accounts, and there’s no reason any of your former workers should still have access to theirs. If somebody no longer works for you, priority one is removing access to company accounts. Even the best-written NDA is pretty complicated to enforce internationally when working with remote teams (especially freelancers).

Monitor event logs and user activity

In AWS, you can track application event logs, and API call logs. The default logging service for AWS resources is CloudWatch, and this allows you to monitor and troubleshoot application errors. It’s highly useful for digging deep into anomalous performance metrics, and figure out any damage being done to your system.

CloudTrail is used for monitoring low-level APIs for AWS services, and is more useful for investigating possible attacks on your system. CloudTrail will track and log API calls to any AWS API, and includes details such as IP address and account that the API calls are being made from.