Shared Security Responsibilities in AWS - LA AWS User Meetup - 2014-07-17


Published on

Moving to AWS doesn’t mean you stop thinking about security. AWS does quite a bit more than you’re accustomed to in the data center, but there’s a lot of security responsibilities you’ll need to think about as an AWS user. John will talk about some of those things you’re responsible for and how you can get ahead of the security game and avoid the most common pitfalls.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Shared Security Responsibilities in AWS - LA AWS User Meetup - 2014-07-17

  1. 1. Shared Security Responsibilities in AWS John Martinez, Principal Solutions Architect,
  2. 2. The Obligatory “Me” Slide • Principal Solutions Architect at • 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
  3. 3. Shared Responsibilities???
  4. 4. The minute we gave developers the power to create infrastructure, security became their responsibility, too!
  5. 5. On-Prem Compared to AWS On-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!
  6. 6. The Scary Stuff etc…
  7. 7. Security Responsibilities Where AWS stops and YOU begin Doesn’t have to be scary!
  8. 8. 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 (
  9. 9. 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
  10. 10. The following suggestions are from personal experience, YMMV ⚠️
  11. 11. The Really Long IAM Section.1 AWS 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
  12. 12. The Really Long IAM Section.2 AWS 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
  13. 13. 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
  14. 14. Complimentary Policy Examples IAM User Policy S3 Bucket Policy
  15. 15. 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
  16. 16. 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 :-)
  17. 17. Resources ! AWS Security Resource Center resource-center ! ! ! AWS Security Blog security/blog AWS Security Center
  18. 18. Thank you! @johnmartinez