What’s the Big Deal About AWS Security Best Practices?

One of the real differences between cloud providers like AWS and more traditional hosting services is that AWS uses a “pay as you go” model for its services. So, instead of coughing up $40 at the beginning of every month for your webserver, AWS will bill you at the end of the month for services you use during the billing period. Essentially, AWS is providing you with a certain amount of credit, payable at the end of the month. That nice, because the project that you deploy to AWS at the beginning of the month could conceivably pay for itself by the end of the month. You could, very much in theory, start a small online business with no money down. How much credit does AWS provide you? The billing cap for a new account on AWS is $100K. That’s a lot of credit to hand out on the strength of the one credit card number you supplied to create the account.

And this is where IAM and AWS Security Best Practices come into play. Supposing that you were a bit lax in your set up of your AWS account. And supposing that some ne’er do well got access to your root credentials and proceeded to set up crypto mining rigs in every one of the 24 AWS regions. How would you know? Well, you would know by setting up Billing Alerts, but that’s a subject for another rant. Unless you did that you really wouldn’t know. When it came time to pay the bill and you realized that the ne’er do wells had managed to spend the best part of $100K of your credit on their mining rigs, and then taken their ill gotten crypto coin and disappeared into the night, and it turned out that you had not followed AWS best practices for securing your account, how forgiving do you think AWS will be? Not very. Not very at all. Which is why it’s critical that you secure your AWS account and understand the AWS Shared Responsibility Model . The Shared Responsibility Model outlines, in detail, what you the customer are responsible for, and what AWS is responsible for. You ignore this at your peril because in general AWS will not absorb the costs of your neglect. At the very least you should follow AWS best practices so that if your account gets hacked you have a reasonable chance of getting AWS billing to work with you on resolving the incident. Without that you have not much chance at all.

Now that you’re suitably frightened, here is what you need to do:

Everything they tell you .

When you create an AWS account, go to Identity Access Management (IAM) and you’ll see they give you a little table with checkboxes of things to do like:

• Setting up Multifactor Authorization (MFA) for the root account
• Setting up an IAM user with AdminAccess privileges that you use for day to day work
• Setting up MFA for all IAM accounts
• Never using the root account except for user administration
• Set up a Budget in the Billing section of the AWS Console
• Set up Cloudwatch Billing Alerts to notify you the moment your bill goes outside normal parameters

Just go through the list until you have all green checks instead of orange ones, set up a Budget and Cloudwatch Billing Alerts and you should be fine. Don’t give your password out to anyone. If they need access create a new IAM user with only the privileges they need. Read the AWS Shared Responsibility Model linked above and understand your responsibilities. AWS is a great tool for businesses but you have to understand that you’re playing in a bigger sandbox than you are at the more traditional hosting services. If you mess up you can mess up very badly.

Still unsure? Contact us and we can do the work for you.

Contact Lillibolero