Post on 08-Sep-2014
description
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/