There was an incident in the UK recently where an employee became very disgruntled after he was fired. He logged into the company AWS account with credentials stolen from a coworker and proceeded to completely trash the company AWS environment by terminating critical EC2 instances.

After many months, the former employee was tracked down, charged and was sentenced to prison for two years.

A truly horrible story as the company in question was never able to recover the deleted data and as a result lost large contracts, massive amounts of revenue and, most importantly, a severely damaged reputation.

There were many steps that could have been taken to prevent this event from occurring, some of them incredibly simple to configure at no extra cost, yet time and time again I find clients who skip these crucial steps of cloud management altogether.

Whether this happens due to a lack of knowledge, laziness or cost cutting, it is the role of a cloud solutions architect to educate businesses and implement systems and procedures that fully secure and protect cloud environments.

Let’s look at the top four ways to protect your AWS account from malicious intent.”

MULTI FACTOR AUTHENTICATION (MFA)

I get it, MFA is a pain. As if it’s not annoying enough having to remember long passwords, also having to type in a six-digit number that changes right in the middle of your keystrokes is frustrating. And the frustration only increases when you have multiple accounts with MFA enabled.

However, implementing MFA greatly reduces the ability to steal a username and password and login with bad intentions and it doesn’t cost anything to implement in the AWS Management Console.

It should be mandatory for any organization that cares about its resources to implement MFA for any users with administrative access. If the UK company mentioned earlier had a chance to go back-in-time and rethink its user administration policy, I can guarantee that MFA would be the first thing on the checklist.

USER PERMISSIONS

One of the best things about the cloud is the ability to bring your IT environment together under one umbrella. Gone are the days of multiple applications, dashboards or consoles to manage all the various parts of your infrastructure as it can all be controlled centrally from the AWS Management Console.

However, with this centralization comes a potential single point of failure. Your administrators now have access to everything in your AWS account and can delete or change everything from servers to databases, network to storage and everything in between.

AWS provides the ability to get incredibly granular with user permissions and constantly promotes the use of “grant least privilege”, which means only grant the permissions users need to perform their job.

So next time someone new joins the team who needs to build new EC2 instances, rather than blindly grant them full administrator access, only give them EC2 launch permissions, which will greatly limit their influence should they go rogue. You can always add more permissions later as their position grows within your organization.

PASSWORD POLICY

Humans are lazy, we don’t like to use complex passwords that look more like hieroglyphics than the English language. However, forcing us to have some degree of complexity in our chosen password vastly reduces the chance of someone guessing or hacking it.

Also, even though we’ll complain and make disgruntled faces, making us change our passwords periodically and use a new password that we haven’t used in the past couple of years will also protect your environment from intruders.

So, login to IAM now and change the password policy to remove the default powder-puff restrictions.

BACKUPS

Lots of AWS services automatically manage backups on your behalf, for example RDS can provide up to 35 days of point-in-time recovery and services like Route 53 or Elastic Load Balancing are automatically backed up on your behalf.

However, there are a lot of services that do not, for example EC2, and it’s staggering how many times I login to a new clients AWS environment to discover that there are no backups taking place. It’s not like AWS makes it difficult for you to do so, you can take snapshots of your instance volumes manually, use CloudWatch Events, the AWS CLI or even the newly launched AWS Backup service. You can also copy snapshots to other AWS Regions for increased redundancy.

Having these backups in place means that you can easily recover from outages should something go wrong. Combining regular backups and user permissions policies that do not allow administrators to delete snapshots means that you will be completely protected should the worst happen.

Additionally, there are plenty of third-party applications out there that will take images of your EC2 instances and store them offsite for safe keeping.

There are many more things that can be done to protect your AWS environment, but implementing these four strategies will ensure that your business does not become the subject of a security blog post.