Shared Security Responsibilities in AWS

John Martinez, Principal Solutions Architect, Evident.io

The Obligatory “Me” Slide• Principal Solutions Architect at Evident.io

• 4+ years AWS and Cloud Experience (but almost all AWS)

• Worked in two of the largest AWS environments

• Unix & Linux geek

• I am NOT a “SECURITY” guy!

• Passionate about DevOps, Security and helping people out

Shared Responsibilities???

The minute we gave developers the power to create infrastructure, security

became their responsibility, too!

On-Prem Compared to AWSOn-Prem!

• Physical key(cards) to DC

• Firewalls

• Network and Power Cables

AWS!

• API Access Key and Secret

• EC2 Security Groups

• VPC and EC2 APIs

And you still need to allow inbound access to your apps!

The Scary Stuff

etc…

Security Responsibilities Where AWS stops and YOU begin

Doesn’t have to be scary!

AWS Responsibilities*

• Data center access (yes, there’s still data centers back there somewhere!)

• Physical infrastructure (servers, storage, network gear and stuff)

• Network security

• API end-points*Full detail found in the AWS Security Whitepaper

(http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf)

AWS Security Services• Identity and Access Management (IAM)

• Secure Token Service (STS) - used indirectly via IAM with Roles

• EC2 Security Groups

• EC2 Keypairs (SSH)

• VPC Subnet ACLs

• CloudTrail

• CloudHSM

The following suggestions are from personal experience, YMMV

⚠️

The Really Long IAM Section.1AWS provides IAM and STS for you to use, but you have to figure out how to best use them

• Enable MFA for root accounts NOW

• Then, enable MFA for IAM users next

• Enable a password policy for your IAM users

• Switch to using Roles for EC2 instances

• Limit scope of EC2 Instance Profile policies — only allow what apps need to do, nothing more

The Really Long IAM Section.2AWS provides IAM and STS for you to use, but you have to figure out how to best use them

• Limit the amount of people with “Admin” policies attached to their IAM users

• Demand that your 3rd party vendors use cross-account delegation using IAM roles

• Protect the shit out of your API Access Keys and Secret Keys (encrypt laptop drives, do not store on EC2 instances, do not put in GitHub repos, etc., etc.)

• If you’re an enterprise, consider federating Console access with SAML

Notes on S3

• If you’re not careful, you can inadvertently give people access to your secrets…by making the wrong object public

• However, it can be a great place to store and distribute secrets…if protected well and used with features like IAM Roles for EC2

• Configure bucket policies so they are complimentary to IAM policies

• Use object versioning and lifecycle rules to archive to Glacier

Complimentary Policy ExamplesIAM User Policy

S3 Bucket Policy

Be Vigilant of Strange Activity• Instances in a region you’re not normally in (t1.micro are especially

favorites for testing your reaction)

• IAM users you don’t recognize

• Weird behavior form your applications

• More S3 objects and buckets than you remember or missing objects and buckets

• An unexpected increase in your AWS bill

So, What Can I do???• Use CloudFormation to deploy and maintain the state of your

infrastructure (infrastructure *IS* code)

• Use SNS to alert you where possible: CloudFormation, AutoScaling

• Use CloudTrail to keep an eye on API activity

• Maintain blacklists/whitelists on reverse proxies behind ELBs

• And if you suspect the worst, involve AWS Support ASAP

• Subscribe to Evident.io :-)

Resources!

Evident.io AWS Security Resource Center

http://evident.io/aws-security-resource-center

!

!

!

AWS Security Blog

http://blogs.aws.amazon.com/security/blog

AWS Security Center

http://aws.amazon.com/security/

Thank you!

john@evident.io

@johnmartinez

http://www.evident.io/