20210526 AWS Expert Online マルチアカウント管理の基本

© 2021, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon Web Services Japan
Manager, Solutions Architect
Yukitaka Ohmura
2021/05/25
マルチアカウント管理の基本

アジェンダ
1. マルチアカウント管理の必要性と考え⽅
2. マルチアカウント構成のベストプラクティス
3. ControlTowerによるLandingZoneの実現
4. 具体的なガードレールの実装
Appendix
• Organizationsが使えない場合どうするか
• 認証認可をどう実現するか

なぜマルチアカウント管理が
必要なのか

お客様がAWSに求めているもの
ビジネス価値の創出に
フォーカスしたい
アイディア実現を
迅速化したい
セキュアかつ
準拠した（Compliant）
環境を維持したい

お客様が求めている環境
組織のセキュリティや
監査要件に適合する
⾼可⽤性で
スケーラブルな
ワークロードに
対応できる
ビジネス要件の変更に
対応するよう
設定変更が可能

実現するための課題
請求
多数のチーム
セキュリティ /
コンプライアンス統制
ビジネスプロセス
分離

AWS アカウント = リソースのコンテナ（⼊れ物）
アカウント分割で以下の管理が可能
環境ビジネス推進
請求
部⾨単位や
システムの単位で
AWSのコストが
明確に分離できる
開発、テスト、本
番などの環境を
セキュリティや
ガバナンス、規制
のために分離でき
る（PCIなど）
ワークロード
外部向け/社内向け
サービスや、
リスクやデータ分類、
顧客の違いなどに
応じてワークロード
を分離できる
事前定義された
ガバナンスフレー
ムワークの中で
特定のビジネス部
⾨に対する権限の
委譲が⾏える
※VPCの分割はネットワークを分離するのみ。APIを分離するにはアカウントの分割が必要

1アカウントでIAMやVPCによる分離はどうか︖
「グレーな」境界
時間経過に伴って複雑で管理が⾯倒に
リソースのトラッキングが困難
責任の押し付け合いが発⽣
AWS Account
Everything

マルチアカウント管理のポイント

AWSはBuilderを⽀えるプラットフォーム
- Self Service Platform -
Biilderに⾃由を与え、適切な箇所で適切なツールを使えるようにする
それによってビジネス価値を早期に実現できる

Builderに必要なものは︖
Gatekeeper Guardrail
V.S.
ツールの利⽤を事前承認(Gatekeeper)すると管理業務がボトルネックになる。
各システムで⾃由に使わせる⼀⽅で、Builderを守るためガードレール(Guardrail)を⽤意する。
やってはいけない操作を未然に防ぐこと（予防的統制）、逸脱を検知すること（発⾒的統制）の2種類。

Governance at Scale - スケーラブルなガバナンスのために
1. Account Management
1. Policy Automation
2. Identity Federation
3. Account Automation
2. Budget & Cost Management
1. Budget Planning
2. Budget Enforcement
3. Security & Compliance Automation
1. Identity & Access Automation
2. Security Automation
3. Policy Enforcement
https://d1.awsstatic.com/whitepapers/Security/AWS_Governance_at_Scale.pdf

Governance at Scale - 職務に求められる役割
1. Executive
• 予算とセキュリティポリシーを社内全体に割り当てる
• データが収集されコンプライアンスと財務状況を確認できる
2. Senior Leadership
• 担当領域の財務状況を確認できる
• 予算、⼈員、追加のセキュリティポリシーの適⽤に責任
3. Upper Management
• 予算の監視、個⼈へプロジェクトへのアクセスを許可、特定領域向けセ
キュリティポリシーの割り当て
• アプリケーションを担当するビジネスユニットやチームに予算とセキュリ
ティポリシーを割り当てる
4. Employee
• クラウド環境に直接アクセスし、現在の予算消化状況を把握
• 他のプロジェクトへのアクセス、財務あるいはセキュリティポリシーへの
例外、を申請可能

Governance at Scale - 実現にあたって
従来のアプローチ（スケールしない）
• 中央集権的で⼿動の承認プロセス（かつ役職間での受け渡しを伴う）
• 個別AWSアカウントへの、強制されない、⾮集中管理なアクセス
• クラウドブローカーの使⽤
スケールするアプローチの考え⽅
1. マルチアカウントによるシステムごとの分離
2. 管理権限の委譲
3. 中央集権による最低限の予防的・発⾒的ガードレール

マルチアカウント構成のベストプラクティス
2021年3⽉に新しいホワイトペーパーが出ています
Organizing Your AWS Environment Using Multiple Accounts
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html

フルスペックの推奨マルチアカウント構成
AWS Cloud
AWS Organizations
Management Account
Foundational (OU)
Infrastructure
Δ Shared Services
Δ Network
Additional OU
Security

https://aws.amazon.com/jp/builders-flash/202009/multi-accounts-best-practice-2/
フルスペック版の解説

⽤語: Organizational Units (OU)
• AWS アカウントのグループ
• SCPを割り当て可能
• パーミッションのグルーピングに使う
（組織構成のグルーピングには使わない）

⽤語: Service Control Policies (SCPs)
• 予防的統制に使えるOrganizationsの機能
• AWS サービスAPIのアクセス可否を制御
- 許可されるAPI呼び出しを定義 – ホワイトリスティング
- ブロックされるAPI呼び出しを定義 – ブラックリスティング
• SCPの特徴
• すべてのメンバーアカウントから設定が⾒えない。rootユーザを含む
• すべてのメンバーアカウントに適⽤される。rootユーザを含む
• パーミッション
• SCPとIAMパーミッションのANDを取る
• IAM policy simulator は SCP を認識する
• 注意
• Organizations Management Account には適⽤されない
• 1つのOUやアカウントに対してアタッチ可能なSCPは最⼤5つ
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_reference_limits.html#min-max-values

Organizing Your AWS Environment Using Multiple Accounts
AWSアカウント構成のデザイン原則
1. セキュリティと運⽤のニーズに基づいて構成する
2. セキュリティガードレールをアカウントでなくOUに適⽤する
3. 深いOU階層構造を避ける
4. ⼩さく始めて必要に応じて拡張する
5. Organizationsのマネジメントアカウントにワークロードをデプロイしない
6. 本番ワークロードと⾮本番ワークロードを分ける
7. 本番アカウントには1つ、または関連する少数のワークロードのみ割り当てる
8. アカウントへの⼈のアクセス管理を省⼒化するためフェデレーションを使う
9. アジリティとスケールのために⾃動化を⾏う
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/design-principles-for-organizing-your-aws-accounts.html

Patterns for organizing your AWS accounts
1. Production startar organization
2. Basic organization
3. Advanced organization
ご注意
• 次ページから提⽰しているベストプラクティスはマルチアカウント環境のセキュリティ、
ガバナンス、運⽤の要求を実現する近道ですが、ゴールではありません
• 適切な構成はAWSの活⽤フェーズや利⽤規模、カルチャーによって変わり、One-size-
fits-allではありません
• ControlTowerが作るアカウント構成は最⼩限です
• このベストプラクティスをマルチアカウント検討のたたき台としてご利⽤ください
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/patterns-for-organizing-your-aws-accounts.html

1. Production starter organization
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/organizing-your-aws-environment/production-starter-organization.html

2.
Basic
organization
https://docs.aws.amazon.com
/ja_jp/whitepapers/latest/org
anizing-your-aws-
environment/basic-
organization.html

3.
Advanced
Organization
https://docs.aws.amaz
on.com/ja_jp/whitepap
ers/latest/organizing-
your-aws-
environment/basic-
organization.html

ControlTowerによる Landing Zoneの実現

「Landing Zone」の実装
• Landing Zoneとは
• セキュアで事前設定済みのAWSアカウントを提供する仕組みの総称
• ツールを活⽤してスケーラブルかつ⾼い柔軟性を提供
• ビジネスのアジリティとイノベーションを実現
• 実装1: AWS Control Tower
• AWSサービスとして提供される Landing Zone （東京リージョンは未対応）
• 最⼩限のマルチアカウント管理を迅速に開始できる
• 特に新規にAWSを使い始める場合に有効
• 実装2: 独⾃実装の Landing Zone
• マルチアカウント戦略に基づき独⾃に実装する Landing Zone
• ⾃社の⽅針にしたがって⾃由にカスタマイズ可能
• すでに管理の仕組みがあってControlTowerの適合が難しい場合に有効
※AWS Solutionsに掲載されているLanding Zone（Automated Landing Zone）はメンテナンスモードであり今後はControlTowerを推奨します

© 2021, Amazon Web Services, Inc. or its Affiliates.
AWS Control Tower
新規のマルチアカウント AWS 環境をセットアップおよび管理するための
最も簡単な⽅法
ベストプラクティスに
基づくランディングゾ
ーンとガードレール
新規アカウント払い出
しの標準化を⾏うアカ
ウントファクトリー
ポリシー適合状況を可視
化するダッシュボード
マルチアカウント環境の
セットアップを⽀援する
マネージドサービス

AWS Control Tower の特徴
ダッシュボード
ランディングゾーン
ガードレール
Account factory
アイデンティティとアクセス管理
ログアーカイブと監査メンバー⽤
のセットアップ済みアカウント
モニタリング
⾃動アップデート
https://aws.amazon.com/jp/blogs/news/aws-control-tower-set-up-govern-a-multi-account-aws-environment/

ランディングゾーン
Management
Account
AWS Control Tower AWS Organizations AWS Single Sign-On
AWS CloudFormation
StackSets
AWS Service Catalog
(Account Factory)
Core OU Custom OU AWS SSO directory
Log Archive Account Audit Account Provisioned accounts
Account
Baseline
Centralized AWS CloudTrail
and AWS Config logs
Account
Baseline
Security
Notifications
Security Cross-
account roles
Amazon
Config Aggregator
Account
Baseline
Network
Baseline
• ベストプラクティスに基づいたマルチアカウントAWS環境

Account Factory
New Governed AWS account
Network
baseline
Account
baseline
AWS Control Tower
Applied Guardrails
Account factory Defaults
Network
baseline
Network
CIDR
Network
regions
OU Account
baseline
AWS Service
Catalog Automation
①アカウントベースライン定義 ②AWS Service Catalogに
よるアカウント払い出し
③ガードレールの適⽤
• アカウント払い出しの標準化を⾏うテンプレート

ガードレール
• 実施してはいけない操作の禁⽌、危険な設定の監視
• 予防的ガードレール
• 対象の操作を実施できないようにするガードレール
• Organizations Service Control Policy （SCP）で実装
• 発⾒的ガードレール
• 望ましくない操作を⾏なった場合、それを発⾒するガードレール
• 管理しつつ開発のスピードを上げるために効果的
• AWS Config Rulesで実装

ダッシュボード
• AWS環境を視覚的、継続的に確認
• 管理下のOUやアカウント、有効化されたガードレールの数
• ガードレールに違反しているリソースのリスト

アイデンティティとアクセス管理
• AWS Single Sign-On (SSO) のデフォルトのディレクトリを使
⽤した ID 管理
• AWS SSO を使⽤したフェデレーティッドアクセス
• 事前定義済みグループ(e.g., AWS Control Tower
administrators, auditors, AWS Service Catalog end users)
• 事前定義済みアクセス許可セット (e.g., admin, read-only,
write)
• AWS SSO とサードパーティの IDP との統合も可能
(Microsoft Azure AD, PING, OKTA)

利⽤可能なリージョンと料⾦
・利⽤可能リージョン
⽶国（バージニア北部、オハイ
オ、オレゴン）、カナダ、シド
ニー、シンガポール、アイルラ
ンド、フランクフルト、ロンド
ン、ストックホルム、東京、ム
ンバイ、ソウル
AWS Control Tower で有効に
なっているサービス料⾦のみ
お⽀払い(AWS Config rules,
AWS CloudTrailなど)
AWS Control Tower の使⽤
に伴う追加料⾦なし

ControlTowerのカスタマイズ

AWS Control Tower のカスタマイズソリューション
https://aws.amazon.com/jp/solutions/implementations/customizations-for-aws-control-tower/
• ランディングゾーンにカスタマイズを追加するAWSソリューション

ライフサイクルイベントを利⽤したカスタマイズの例
• Account Factoryによるアカウント払い出しの正常終了
(CreateManagedAccount)を契機にLambdaをトリガーし独⾃のカスタマイズ
を⾃動適⽤
Account
Stack
Set
Amazon
GuardDuty
AWS Security
Hub
IAM Roles
Amazon VPC Flow
logs
Account Customizations
1. Launch
Account
Admin
New
Account
2. Account
Created
Amazon
CloudWatch Rule
3. CreateManagedAccount
AWS Lambda
4. Trigger Lambda
AWS
CloudFormation
5. Add a Stack
6a. Trigger customizations
through stack additions
6b. Trigger customizations
Directly
Control Tower
Management
AWS Service
Catalog

Workloads
Workloads Workloads
既存アカウントでも AWS Control Tower を利⽤可能
AWS Cloud
既存アカウント
AWS Control Tower
Existing Payer Account
Dev
Pre-
Prod
Prod
Workloads
Dev
Pre-
Prod
Pro
d
Dev
Pre-Prod
Prod
Dev
Pre-
Prod
Pro
d
Δ Log Archive
Δ Sec Read Only
Δ Sec Break
Glass
Δ Security
Tooling
Δ Shared
Services
Δ Network
Security
Infrastructur
e
Prod
SDLC Prod
SDLC
Workloads
Dev
Pre-Prod
Prod
Workloads
Dev
Pre-Prod
Prod

具体的なガードレールの実装

参考︓ControlTowerのガードレール
• 必須のガードレール
• ControlTowerを正常に稼働させるために必要な禁⽌事項をSCPで定義したもの
• 独⾃に実装する場合は必須ではないが、ログ保存を停⽌させない実装などが参考になる
• 強く推奨されるガードレール
• マルチアカウントのベストプラクティスに基づく制限事項
• SCPの例︓rootユーザでアクセスキーを作らない、rootユーザで操作しないなど
• ConfigRulesの例︓EBSボリュームが暗号化されていること、S3のパブリック読み書き禁⽌など
• 選択的ガードレール
• AWS エンタープライズ環境で⼀般的に利⽤されている制限事項
• SCPの例︓MFAなしのS3バケット削除禁⽌、S3バケットのクロスリージョンレプリカ禁⽌など
• ConfigRulesの例︓MFAなしのIAMユーザアクセス禁⽌、バージョニングのないS3の禁⽌など

予防的ガードレールの設定
• 設定⽅法
• Organizations SCP
• IAM Permission boundary
• IAM Policy
• 特にSCPは本当に禁⽌しなければいけな
い、権限昇格や管理リソースの破壊防
⽌のみにフォーカスすることを推奨
• 頑張ると結局Gatekeeperになる
[注意]
SCPの権限制御は対象アカウントやOUのすべてのユー
ザーに影響を与える可能性がある強⼒な機能です。必要最
低限の設定を⼗分なテストを⾏なって適⽤してください。
https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html

発⾒的ガードレールの設定
• 積極的に使⽤する
• AWSのベストプラクティスと社内セキュリティポリシーをベース
にルールを定め、設定する
• 検知したら誰が何をするか決める
• 設定⽅法
• ConfigRules
• SecurityHub
• GuardDuty
• ルールセット
• ControlTowrの推奨/選択的ガードレール
• ConfigRules ConformancePack
• SecurityHub CIS/AWSベストプラクティス
• Next step
• ControlTowerはガードレールを設定するがRemediationは別途必
要
• 設定後のRemediationには、SecurityHubのドキュメントが参考に
なる
• Remediationの中にはSSM Automationが⽤意されているものも
ある（例:デフォルトセキュリティグループの閉塞）
• 検知されたもののうち何を通知するかよく検討が必要
https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html

ControlTowerの情報源
• ワークショップ
• https://controltower.aws-management.tools/ja/immersionday/
• ⽇本語ブログ
• https://aws.amazon.com/jp/blogs/news/category/management-tools/aws-control-tower/
• https://aws.amazon.com/jp/blogs/news/category/management-tools/
• 英語ブログ
• https://aws.amazon.com/jp/blogs/mt/category/management-tools/aws-control-tower/
• https://aws.amazon.com/jp/blogs/mt/
• 独⾃にLanding Zoneを実装する
• AWS Innovate 2020 [S-7] 増加するシステムをマルチアカウントで効率よく管理するをご参照ください
https://d1.awsstatic.com/events/jp/2020/innovate/pdf/S-7_AWSInnovate_Online_Conference_2020_Spring_MultiAccount.pdf

参考資料（事例）
• [AWS Security Roadshow] ⼤規模AWS共通基盤上の発⾒的統制への挑戦
• https://speakerdeck.com/rtechkouhou/da-gui-mo-awsgong-tong-ji-pan-shang-falsefa-jian-de-tong-zhi-hefalsetiao-zhan
• [AWS Summit 2019] AWSコンサル事例でわかるパーソルが実現したガバナ
ンスとスピードを兼ね備えた次世代型AWS共通基盤とは
• https://pages.awscloud.com/rs/112-TZM-766/images/L2-05.pdf
• ZOZOテクノロジーズさんのマルチアカウント事例祭り
• 第1回 https://zozotech-inc.connpass.com/event/185894/
• 第2回 https://zozotech-inc.connpass.com/event/200890/
• JAWS DAYS 2021のセッション（マルチアカウント周りの話題多し）
• https://jawsdays2021.jaws-ug.jp/timetable/

まとめ
1. マルチアカウント管理の必要性と考え⽅
2. マルチアカウント構成のベストプラクティス
3. ControlTowerによるLandingZoneの実現
4. 具体的なガードレールの実装

Appendix
• Organizationsが使えない場合どうするか
• 認証認可をどう実現するか

Organizationsが使えない場合どうするか

LandingZoneを⾃分で実装するには何が必要か
1. アカウントの発⾏
• 必要な初期設定の済んだアカウントを作成
2. 管理⽤権限の発⾏
• 対象アカウントを管理するための権限を作成
3. 共有サービスへのアクセス
• ADなどの共有サービスやオンプレミスへの接続経路の確保
4. AWSログの集約
• 監査⽤ログの集中かつ安全な保存
5. ガードレールの設置
• 実施してはいけない操作の禁⽌、危険な設定の監視
AWS Innovate 2020 [S-7] 増加するシステムをマルチアカウントで効率よく管理するをご参照ください
https://d1.awsstatic.com/events/jp/2020/innovate/pdf/S-7_AWSInnovate_Online_Conference_2020_Spring_MultiAccount.pdf

Organizations がない場合のLandingZone - 基本⽅針
前提
• 基本的にAWSの各種サービスがマルチアカウント対応の⼀環で
Organizationsを利⽤する⽅向で拡張されている
• 従来からの機能の中にはアカウント個別指定で管理できるものもある
基本⽅針
• 「AWSアカウントを作ったら最初に必ずやるべき最低限のこと」
だけをアカウント個別に指定して集約
• 認証認可 / CloudTrail / Config / GuardDuty / SecurityHub
• 他は無理に集約せずアカウント個別に設定

OrganizationsなしでLandingZoneを実装するには
LandingZoneで特に必要だが Organizationsがないと使えない機能
（１）アカウントの発⾏
（２）SCP
（３）タグポリシー
（４）AWS SSO

AWS Organizations と密接に関連した機能
Organizations が使えない環境での実現⽅式は以下
（１）アカウントの発⾏
・⼿動でアカウントを作成する
・リセラーアカウントの場合、リセラーのオペレーションで発⾏する
１．Organizations でアカウントを作成（CLI,SDK）
２．Organizations SCP の設定
３．ベースライン（基本設定）⽤の CloudFormation Stack を作成
• 管理⽤権限（IAM Role）の発⾏
• AWS Config Rules の設定
• 標準VPCの作成・設定など
マルチアカウント環境におけるアカウント発⾏のベストプラクティス
AWS Organizations無しでは
この部分が実現できない
上記のように、ベースラインを設定したアカウントの⾃動発⾏を実現する仕組みを、
AWSではアカウントファクトリー、またアカウントベンディングマシーン（AVM)として説明している
参考 https://github.com/aws-samples/aws-account-vending-machine

AWS Organizations と密接に関連した機能
Organizations が使えない環境での実現⽅式は以下
（２）SCP
ルートユーザの権限管理だけはSCPが必須
リセラーアカウントの場合ルートユーザを渡さなければ、
IAM Boundaryで同様のことを実現できる
（３）タグポリシー
アカウント内で実現する場合はIAM Policyをカスタムすることで実現する
（４）AWS SSO
外部IdPサービスの利⽤もしくは、
SSO（IDフェデレーション）環境を⾃前で構築
（もしくは踏み台アカウントでSwitch Role）

マルチアカウントの認証認可をどう実現するか

管理⽤権限の発⾏/アクセス環境の実現
対象アカウントを管理するための権限を作成
• ID管理 / アカウントへの
フェデレーティッドアクセス
アプリケーションアカウント
SSO Active
Directory
など
アプリケーションアカウント A
アカウント管理者Role (PowerUser)
LZ管理者Role (Administrator)
参照専⽤Role (ReadOnly)
その他ログ管理等に必要なRole
アカウントA⽤
グループ
LZ管理者
アカウントB⽤
グループ
認証
ロール選択
B
C
• 認証にはIAM Userではなくシングルサインオ
ン(SSO) の仕組みを使い、各アカウントにロー
ルのみを作成することを推奨
⽅法１︓AWS SSO
⽅法２︓IDフェデレーション環境を⾃前で構築
⽅法３︓AWSと連携できる外部IdPを利⽤
＜＝AWS Organizations必須

課題
• 1つの中央IDストアで全システムの全ユーザの認証情報を管理するか︖
• 中央IDストアでは各アカウントの管理者アカウントのみ管理︖
• 各アカウントのIDは、IAM Userで管理してしまう︖別途IDストアとSSOを⽤意︖
IdP Active
Directory
など
アカウント管理者Role (PowerUser)
LZ管理者Role (Administrator)
参照専⽤Role (ReadOnly)
アカウントA⽤
グループ
LZ管理者
アカウントB⽤
グループ
認証
ロール選択
B
C
IdP
アカウント管理者Role
運⽤者Role
LZ側認証
アカウントA
管理者
開発者
開発者IAMUser
アプリ
アカウント側
認証
運⽤者
IdP
AD等
AD等
全ユーザを統⼀管理
アカウント管理者はLZで払い出し
アカウント内のユーザは個別管理

【参考】IDフェデレーション with SAML 概要図
AWS マネジメントコンソール
SAML ⽤の
AWS サインイ
ンエンドポイン
ト
ユーザーがポータルサイ
トをブラウジングする
ユーザー
を認証す
る
認証応答として
SAMLアサー
ションを受信す
る
クライアントを
コンソールに
リダイレクトす
る
1
2
3
4
6
5
企業データセンター AWS Cloud (サービスプロバイダー)
ポータルサイト/
IDプロバイダー
(IdP)
アイデンティ
ティストア
属性情報に基づいて
ロールの⼀時セキュ
リティ認証情報を⽣
成
SAMLアサーションをポスト
ユーザー

シングルサインオンの設計と運⽤
詳しくはBlackBeltを参照
https://aws.amazon.com/jp/blogs/news/webinar-bb-awsaccountsso-2020/

Thank you

20210526 AWS Expert Online マルチアカウント管理の基本

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20210526 AWS Expert Online マルチアカウント管理の基本

Similar to 20210526 AWS Expert Online マルチアカウント管理の基本 (20)

More from Amazon Web Services Japan

More from Amazon Web Services Japan (20)

20210526 AWS Expert Online マルチアカウント管理の基本