Organizations — 100個のアカウントを1人で統治する

想像してみてください。あなたは急成長スタートアップのCTOです。3年前は1つのAWSアカウントで全部やってました。でも今、子会社が5つ、事業部が10個、開発チームが15チーム。「あ、うちもう100個アカウント使ってますね」と財務から言われました。100個のアカウント、どうやって統治するの？これがOrganizationsの問題です。1つ1つ管理するなんて不可能。でも放置すると、セキュリティは穴だらけ。

複数アカウント管理。大規模なエンタープライズ環境では、50 個、100 個以上のアカウントを持つのは珍しくない。その管理インフラが Organizations、Control Tower、IAM Identity Center。3層構造。

Organizations の本質

Organizations。階層的なアカウント管理。Root アカウント（管理アカウント）の下に OU（Organization Unit）を作って、その中にメンバーアカウントを配置。木構造。

そこで権限制御が SCP（Service Control Policy）。これが強力。「IAM ポリシー」とは違う。SCP は「権限の上限」。つまり、IAM で管理者権限を付与されていても、SCP で EC2 を禁止されてたら、EC2 操作できない。IAM と SCP、両方で許可されて初めて実行可能。

制約ね。管理アカウントには SCP が効かない。管理アカウントは「絶対権力」。だから、本来のリソースは管理アカウントに置かない。ログアーカイブ、監査ロール、そういった「一時的な」ものだけ。本番アカウント、開発アカウントは別。

SCP の戦略

2 つの戦略。Allow List と Deny List。

Allow List。デフォルトすべて禁止。明示的に許可したサービスだけ使える。厳格。新しいサービス AWS が追加しても、自動的に禁止。セキュリティ的に有利。

Deny List。デフォルトすべて許可。危険なアクション（IAM 削除、Organizations 離脱）だけを禁止。シンプル。だけど、設定漏れリスク高い。

本番環境推奨は Allow List。セキュリティ重視。設定は面倒だけど、価値ある。

OU 設計

パターンいくつかある。セキュリティ重視なら。Root 下に Security OU（ログ・監査アカウント）、Production OU（本番。厳格 SCP）、Staging OU（中程度 SCP）、Sandbox OU（自由。SCP なし）。この階層。

OU は最大 5 レベル。Root を 0 として、深さ 5 まで。実務的には 3 階層で足りることほとんど。

Control Tower

Control Tower。Organizations の上に構築される「自動ランディングゾーン」。何が自動化されるか。Logging アカウント作成。Audit アカウント作成。CloudTrail マルチアカウント・マルチリージョン設定。AWS Config アグリゲータ。SCP 自動適用。盛りだくさん。

ガードレール。3 種類。予防的（SCP ベース）。「CloudTrail 無効化禁止」みたいに、アクション事前に拒否。検出的（Config Rules）。「非暗号化 EBS 発見」みたいに、違反検出・報告。プロアクティブ（CloudFormation Hooks）。テンプレート実行前にポリシー確認。違反あれば、スタック作成拒否。

重要な制約。「既存 Organizations の上に Control Tower 構築」って言ったら、NG。Control Tower は Organizations 全体を上書きします。だから、新規 Organizations 作成が必須。既存OU構造は失われる。ここ、落とし穴。

Account Factory

新しいアカウント自動作成。Service Catalog ベース。「新規開発アカウント必要」って言ったら、ポートフォリオから「開発アカウント」を選んで、メールアドレス入力。自動作成。OU に自動配置。SCP・ガードレール自動適用。便利。

AFT（Account Factory for Terraform）。Terraform で Account Factory を管理。IaC 化。Git で履歴管理。本格的。

IAM Identity Center

IDソース管理。内蔵ディレクトリ（ネイティブ）、Active Directory、SAML、SCIM。複数の IdP 対応。

ここ、重要な制約。IDソース、一度決めたら変更困難。「ネイティブでユーザー作って、あ、やっぱり Active Directory にしよう」。できるけど、既存ユーザーのアカウント孤立。Permission Set 再構成。メチャクチャ。

初期選択は慎重に。企業 AD がある場合は、最初から AD 連携。迷ったら AD か SCIM OIDC。

Permission Set

権限セット。複数 AWS アカウントに同時適用可能。「このDeveloper Permission Set を、Dev Account A、B、C に適用」みたいに。一元管理。効率的。

ポリシー構成。マネージドポリシー参照。カスタムインラインポリシー。Permission Boundary で権限上限。これら組み合わせ。

ABAC（属性ベースアクセス制御）。Session Tags。ユーザー属性に基づいた動的権限制御。「部門ごとに異なる S3 バケットアクセス」。静的 Permission Set より、運用効率化。

試験ポイント

「SCP の評価ロジック」。IAM と SCP の共通部分のみ実効権限。これ、必出。

「管理アカウントに SCP は効かない」。危なそうだけど、実装上、管理アカウントには本来のリソース置かない。設計時点で対応。

「OU 階層上限」。5 レベル。覚えておく。

「Organizations 統合の困難性」。既存 OU 上書き。新規組織作成が正解。

「IDソース変更」。ネイティブから AD へ。大変。初期選択が重要。

「Permission Set の複数アカウント適用」。一元管理メリット。Organizations との相性バッチリ。

できないこと

管理アカウント以外は Organizations 全体設定変更不可。委任管理者制度で一部権限移譲できるけど。

Control Tower が自動作成した SCP は、Control Tower UI から削除できない。Organizations から削除。その後、同期が必要。複雑。

IAM Identity Center は 1 リージョンのみ。複数リージョンの AWS アカウントを管理することはできるけど、管理側は 1 リージョン。通常 us-east-1。

Permission Set 数上限。1 アカウント当たり 40 個。大規模組織だと足りないことも。ABAC で工夫。

まとめ

Organizations + Control Tower + IAM Identity Center。マルチアカウント管理の 3 層インフラ。

次の講義は Cognito と STS。認証・認可・フェデレーション。User Pools（認証）と Identity Pools（認可）の連携。Lambda トリガーの 5秒制限。Confused Deputy 対策。では次の動画で。