Jay Schulman - Securing Amazon Web Services

The All-in-One Guide to Securing TheDifferent Services that make up AWS

Jay Schulman

Securing Amazon WebServices

Copyright 2015by JaySchulman .

Smashwords Edition

All rights reserved. Printed in the UnitedStates of America. No part of this book may be used or reproducedin any manner whatsoever without written permission except in thecase of brief quotations em- bodied in critical articles orreviews.

This book is based upon data available at thetime of writing and may not have been tested in a productionenvironment. Test all changes to your environment beforeimplementing.

For information: JaySchulman.com

First Edition: December 2015

The All in One Guide

Welcome to the complete guide to securingAmazon Web Services. As I was researching how to secure my AWSresources, I realized there isn't a one-stop guide for securingevery piece of AWS. I've compiled from around the web (includinggreat resources from Amazon, Evident.io, and others) to build thisguide.

This guide will be updated as new servicesarise, configuration changes occur, or other things happen thatrequire an update to the guide.

This is version v0.1 , initialrelease.

The AWS account is the key to the castle. Ifyou're a casual user, it's probably your Amazon.com login. The sameone you use to buy everything else in your life. If you're acorporate user, it's likely a purpose built account. Either way,these suggestions apply.

Disable root API Access Key and SecretKey

In AWS, a root user isthe login credential you used to create your AWS account with.While it would seem logical that this user is required to run yourapplications and infrastructure, it isn't.

You should disable the AWS root API accesskeys that go with that account. Go to the Security Credentials pagesigned in as the root user. Remove or disable any access keys youfind.

Create a backup Root user

You want a limited number of root users, butyou should definitely create a backup administrative user shouldyou need it. In the same section as above, create your secondadministrative user.

Enable Billing and Recovery

While still logged in as the root user, go toMy Account and fill in the following sections: Alternate Contacts;Security Challenge Questions; and IAM User Access to BillingInformation. This will be critically important should you need toreset your account.

Setup Multifactor Authentication (MFA)

You can get started in two simple steps:

• Assign an MFA device to yourIAM users. You can get AWS Virtual MFA for free, which enables you to use any OATH TOTP -compatible application(Google Authenticator, Authy, Duo) on your smartphone.Alternatively, you can purchase a hardware MFA keyfob from Gemalto, Amazon'sthird-party provider.

• Add an MFA-authentication requirement to anIAM access policy. You can attach these access policies to IAMusers, IAM groups, or resources that support Access Control Lists(ACLs): Amazon S3 buckets, SQS queues, and SNS topics.

The policy below is a basic example of how toenforce MFA authentication on users attempting to call the AmazonEC2 API. Specifically, it grants access only if the userauthenticated with MFA within the last 300 seconds.

This policy utilizes thecondition key, aws:MultiFactorAuthAge , whose valueindicates the number of seconds since MFA authentication. If thecondition matches, i.e. the value of aws:MultiFactorAuthAge is less than300 seconds at the time of the API call, then access is granted.More information from Amazon is available here:

http://blogs.aws.amazon.com/security/post/Tx3NJXSBQUB4QMH/Securing-access-to-AWS-using-MFA-Part-2

AmazonS3 (Simple Storage Service) is an onlinefile storage web service. Lots of different things gets stored inS3 on Amazon. Not just file respositories that you setup.Everything in this section refers to a bucket . Buckets are the storage unit(or maybe you'd call it a volume or file directory) that Amazonuses.

Bucket Policies

There are two ways tocontrol access to an S3 bucket -- via the IAM policies or usingBucket Policies. For buckets where I'm just providing documents tothe outside world, bucket policies work. Where a bucket has logs,private information, etc, IAM policies are how I choose to securethem. You can try it out using the AWS Policy Generator to create an AWS S3 Policy to secure your bucket.For bucket policies, refer to Amazon's guide Using BucketPolicies . Bucket Policies can be used in conjunction with IAMPolicies .

No matter which direction you choose, makesure only the right people have access to the right buckets (i.e.your data). Wait, there is one more way...

Access Control List

We can also manage access tobuckets and objects using ACLs that defines which account (or S3group) can access a resource and how. Default behavior is to grantthe creator/owner full control over the bucket. Policies arewritten in XML and contains Owner andGrant elements. A list of possible grantees and permissions (withexamples) is available in the S3 Access Control List overview .

ACLS and Bucket Policiescan be used together , S3 will evaluate bothwhen determining an accounts access permissions to an S3resource.

Final word of warning... it doesn't reallymatter what you do as long as it protects your data. Choose themethod that works for your management technique, security profile,and easy of use.

Query String Authentication

If you have content thatyou'd like to kinda protect, Query String Authentication is right foryou. This is generally used when you want to use an S3 bucket as adownload repository for files. If people have to register on yourwebsite before they can download, QSAs are used to make sure you'reclicking the download link from your site. Is it secure? No. Doesit keep mischief away? Definitely. Remember, you're paying forbandwith, so if you put up a huge file and thousands of usersdownload it, you're paying. You configure this by adding asignature and an expiration date to the query string. This stringwill be valid until the expiration date.

Distributing S3 contents with CloudFront

To deliver content from anS3 bucket to the Internet you use CloudFront. If you want todeliver privatecontent you need to use Origin Access Identity. OAI allowsyou to restrict access to content while distributing them withCloudFront.

To setup OAI, you need to create an OriginAccess Identity for the desired AWS account before you attach it toyour CloudFront distribution. After giving that identity theread/read and download permissions you remove the public accesspolicy from the S3 bucket and the content will be available onlyfrom CloudFront. Additionally to add a little more security, youcan add trusted signer accounts to the distribution configurationto allow access to the Private content only using Signed URLs.

MFA Delete

You can optionally add another layer ofsecurity by configuring a bucket to enable MFA (Multi-FactorAuthentication) Delete, which requires additional authenticationfor either of the following operations.

• Change the versioning state of yourbucket

• Permanently delete an object version

I would only recommend MFA Delete when thedata stored in an S3 bucket is required by regulations (logs,transaction activity, etc) or irreplaceable (images, videos, etc).The idea is that you need to use your two-factor token to deleteany objects. MFA Delete requires two forms of authenticationtogether: