rights reserved. ORG301: Effective AWS Account Strategy using AWS Organizations Steve Teo Director of Cloud Security Engineering, Horangi Cyber Security www.linkedin.com/in/steveteo
rights reserved. Steve “Potay” Teo • Director of Cloud Security Engineering @ Horangi • CloudDevSecOps Fanatic • 4 years+ working on AWS • AWS Areas of Interests: • AWS Multi-Account Architectures • Cloud Security • Totally uncertified and proud :P
rights reserved. Background • Previous Work ◦ Migrated Legacy Setup of 2 AWS Accounts to 40+ AWS Accounts ▪ March 2017: https://speakerdeck.com/stevepotayteo/a-multi-aws-account- story ◦ Worked on Enterprise AWS Account & VPC Architecture and Strategy ▪ September 2018: https://speakerdeck.com/stevepotayteo/architecting- around-multiple-aws-accounts • Hobby - Continual research into scaling of AWS Multi-Accounts and VPCs
rights reserved. Agenda • What are AWS Accounts • Why should you adopt a Multi-Account Strategy • Introduction to AWS Organizations • Security, Management and Governance Features
rights reserved. Questions • How many of you are Cloud Administrators and responsible for your company’s AWS Account(s)? • How many accounts does your company have? • How many of you are already using AWS Organizations?
rights reserved. AWS Account != VPC • A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud • VPCs == Network containment != AWS Resource Account Security != AWS User Account Security VPC
rights reserved. Why should you adopt a Multi-Account Strategy? • Grouping of resources • Limit Blast Radius in case of Unauthorized Access • Improve your security posture with logical boundaries • Easier to manage user access to different resources
rights reserved. Separate by Business / Dev Team • "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” – Melvin Conway • Need for isolation among workloads • Financial isolation - showback / chargeback • Easily broken when prone to organization changes
rights reserved. Separate by Platform / Service / System / Application • Wide-grained – Platform / Service • Fine-grained – System / Application • Splitting it too fine-grained might not make sense at all • Eg. 1 AWS account just for 1 EC2? ◦ Container optimization?
rights reserved. Separate by Environment • By default you get ◦ network / data containment ◦ user access security • Orthogonal to other ways of separation • Eg. Sandbox / Non-Prod / Prod / DR • Eg. DEV / SIT / QA / STG / PROD / DR
rights reserved. Other Ways • PCI / HIPAA (Regulated vs Non-regulated) • AWS Service Limits / API Rate Limits • Service Tiering (eg. Tier 1, Tier 2 services)
rights reserved. Key Features • Manage and define your organization and accounts • Control access and permissions • Audit, monitor, and secure your environment for compliance • Share resources across accounts • Centrally manage costs and billing
rights reserved. Key Features • Manage and define your organization and accounts • Control access and permissions • Audit, monitor, and secure your environment for compliance • Share resources across accounts • Centrally manage costs and billing
rights reserved. Migrating from consolidated billing • You are already using AWS Organizations • Migrate to use advanced governance and management capabilities. • Every invited account must approve enabling all features by accepting the request! • Seamless transition, no outage https://docs.aws.amazon.com/organizations/latest/userg uide/orgs_manage_org_support-all-features.html
rights reserved. Services that integrate with AWS Organizations • IAM • Artifact • CloudTrail • CloudWatch Events • Config • Control Tower • Directory Service • Firewall Manager • License Manager • Resource Access Manager • Service Catalog • Service Quota • Single Sign-On
rights reserved. Key Concepts and Terms • * Master AWS Account ◦ Account used to create and manage the organization ◦ Payer account • Root ◦ The parent container for all the accounts for your organization. • Organization Unit (OU) ◦ A container for accounts within a root. • Service Control Policy ◦ A policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. * Master AWS Account
rights reserved. Manage and define your organization and accounts • Create new AWS Accounts from console or programmatically • Group accounts into OU for management • Manage Service Quotas for new accounts • Tag AWS Accounts
rights reserved. Prod Audit Group accounts into OU for management AWS Accounts Organizational unit SCP My AWS Organization Root Application Services Infrastructure Security Non-Prod Developers Non-Prod Prod Cowboys Trusted Master Account
rights reserved. Service Quotas • Central management and visibility of AWS service quotas only for the current account • Simplify quota requests for new accounts in AWS Organizations https://aws.amazon.com/about-aws/whats-new/2019/06/introducing-service-quotas- view-and-manage-quotas-for-aws-services-from-one-location/
rights reserved. Service Control Policies • Service Control Policies != IAM Policies • Specify the maximum permissions for an organization, organizational unit (OU), or account • SCP does not affect the master account • SCPs affect all users and roles in attached accounts, including the root user. Test all policies before using them!
rights reserved. Determining Whether a Request Is Allowed or Denied Within an Account https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
rights reserved. Other SCP Use Cases • Deny the use of service(s) for Compliance Reasons • Prevent users from disabling AWS CloudTrail • Prevent users from disabling AWS Config or deleting Config Rules • Do not allow EC2 / RDS Termination in Production Account • Prevent changes to IAM Roles • Prevent Root User Usage • See more examples at https://docs.aws.amazon.com/organizations/latest/userguide/orgs_man age_policies_example-scps.html#example_scp_1
rights reserved. AWS Config • Centrally create, update, and delete AWS Config rules across all accounts in your organization. • Deploy a common set of AWS Config rules across all accounts and specify accounts where AWS Config rules should not be created. • Use the APIs from the master account in AWS Organizations to enforce governance by ensuring that the underlying AWS Config rules are not modifiable by your organization’s member accounts.
rights reserved. Summary • Go for a reasonable multi-account strategy, but don’t go bananas! • Any company (big or small) with more than 1 AWS account can benefit from AWS Organization • Use Service Control Policies to enforce strong guardrails about the operating model of your Cloud Environment • More and more AWS Services will be integrated with Organizations
stevepotayteo
ryomrt
kakehashi
yoshidashingo
shift_evolve
negi111111
kimujun
sansantech
salaboy
nobutomurata
ronnnnn
keithpitt
yeseniaperezcruz
iamctodd
tammyeverts
swwweet
jponch
shpigford
lemiorhan
vanstee
moore
ufuk
jrom
