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.
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. Production application deployment diagram
Application accounts
Corporate data center
AWS backbone
AWS Direct Connect Security account
Master (billing) account
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. 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
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. 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. 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. 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. 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. 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. 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
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.
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. 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. 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