This document discusses shared security responsibilities between AWS and customers. It begins with an introduction of the author. It then explains that while AWS manages physical infrastructure and network security, customers are responsible for identity and access management, application security, and compliance. The document provides recommendations for securing IAM, S3, and monitoring for suspicious activity. It emphasizes using services like IAM, CloudTrail, and CloudFormation to automate security best practices.
2. 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
4. The minute we gave developers the
power to create infrastructure, security
became their responsibility, too!
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!
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
(http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf)
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
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. 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. 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
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. 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 :-)
17. 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/
