Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS re:Invent 2016: Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service (SEC304)

2,478 views

Published on

This session shows you how to reduce your blast radius by using multiple AWS accounts per region and service, which helps limit the impact of a critical event such as a security breach. Using multiple accounts helps you define boundaries and provides blast-radius isolation. Though managing multiple accounts can be difficult, we will present an upcoming AWS solution that will help automate the process for controlling cross- account access by managing roles across multiple accounts.

Published in: Technology

AWS re:Invent 2016: Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service (SEC304)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Bryan Miller Solutions Builder, Amazon Web Services November 29, 2016 Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service SEC304
  2. 2. What to expect from the session • How AWS manages multiple accounts and how customers can leverage multiple AWS accounts to manage security and reduce the blast radius by deploying a single application into one account per region • Some insight into AWS account and security practices • How to deploy the cross-account manager solution to assist in managing role-based access to these accounts
  3. 3. Production application deployment diagram Application accounts Corporate data center AWS backbone AWS Direct Connect Security account Master (billing) account
  4. 4. Production application deployment on AWS • Two accounts: One for the application and one for security isolation • The main account is owned by the application team and is deployed in a single VPC • The second account is owned by the security team and is used to audit and control access to the first account and control network connectivity between the first account and the on-premises data center • The accounts are connected using VPC peering and access is managed by a federated role-based service
  5. 5. How did we arrive at this conclusion? • Only applies to production, business critical applications, or logical application groups • A trade off between one large account and many small accounts – what is the proper balance? • Managing multiple accounts simplified with role-based user federation solution – cross-account manager solution
  6. 6. Cross-account manager solution Using AWS CloudFormation templates to create and manage roles for a master account and sub accounts
  7. 7. How AWS thinks about AWS • Apply the right levels of control and change management at the right time • Automating the creation and management of resources provides better traceability • Verification and audit of configuration and access is critical for production business-critical applications
  8. 8. How AWS thinks about security • Simple, easily understood security invariants vs. subtle and complex reasoning • Historically have been overindexing on prevention • Bias towards simpler policies and few objects to manage • Shift to detection and response • Turn on all logging and visibility features as possible in the production application account Prevention Detection ResponseAnalysis
  9. 9. How AWS manages identity and access • AWS uses an internal tool to manage employee access to accounts • Users authenticate to corporate directory • Uses IAM roles to control access to resources in each account using AWS STS AssumeRole • Accounts are flagged as production/nonproduction or contain customer data – three tiers with progressively higher levels of control and auditing
  10. 10. How AWS manages usage • Review application use case and in some cases, disallow the use of a specific service for sensitive data • The use of our internal tool does allow us to allow some sensitive data to be delivered to logs since we are comfortable that access to the account is controlled • Use of programmatic tools to quickly determine policy changes and remediate quickly using those tools
  11. 11. How AWS thinks about VPCs and accounts • Use separate VPCs or accounts for things that are clearly separate • For this case, we chose to use two separate accounts, one for the business owner and one for a security gateway • This doesn’t mean that we would hold hard and fast to only one account per application but would make that decision based on similarity of policies, groups, and routing tables required to protect a group of applications
  12. 12. How AWS thinks about decision making • Two-way doors vs. one-way doors – policies can be changed, security groups can be modified, and instance sizes and counts can be adjusted • Often it’s better to deploy quickly and adjust rather than get stuck trying to analyze for the ideal case for too long
  13. 13. How AWS thinks about system design • “Modality is evil” – a system that works one way when things are normal and switches to another mode when there’s a problem • Example: A system that provisions administrator access on failure – when it’s more likely that the failure might keep this from occurring – rather one should provision admin access all of the time and use other mechanisms to make sure it’s being used correctly
  14. 14. Flashback to re:Invent 2015 • SEC315 – AWS Directory Service Deep Dive
  15. 15. Fast forward – Cross-account manager solution • Look familiar? • Using AWS CloudFormation templates to create and manage roles for a master account and sub accounts.
  16. 16. CloudFormation components
  17. 17. Account onboarding
  18. 18. Role onboarding
  19. 19. Simple HTML access links
  20. 20. Demo Live demo of solution here
  21. 21. Get started today! Visit our website - https://aws.amazon.com/answers/ Launch the solution - https://aws.amazon.com/answers/account- management/cross-account-manager
  22. 22. AWS Organizations • New management capability for centrally managing multiple AWS accounts - Simplified billing - Programmatic creation of new AWS accounts - Logically group AWS accounts for management convenience - Apply organization control policies (OCP) • A Consolidated Billing (CB) family automatically migrated to an organization • All organization management activity is logged in AWS CloudTrail • An AWS account can be a member of only one organization • V1 OCP – Control which AWS service APIs accessible in AWS account(s) • Console, SDK, and CLI support for all management tasks Available in limited public preview: http://aws.amazon.com/organizations/preview
  23. 23. Related sessions ARC314 – Enabling Enterprise Migrations: Creating an AWS Landing Zone ENT203 – Enterprise Fundamentals: Design Your Account and VPC Architecture for Enterprise Operating Models SAC319 – Architecting Security and Governance Across a Multi-Account Strategy SAC320 – Deep Dive: Implementing Security and Governance Across a Multi-Account Strategy SAC323 - Centrally Manage Multiple AWS Accounts with AWS Organizations SEC304 – Reduce Your Blast Radius by Using Multiple AWS Accounts Per Region and Service
  24. 24. Thank you!
  25. 25. Remember to complete your evaluations!

×