Organizations・Control Tower・IAM Identity Center

講義概要

このモジュールでは、AWS のマルチアカウント戦略の中核となる3つのサービスを、試験レベルを超えた深い理解で解説します。

• Organizations: マルチアカウント管理、SCP（Service Control Policy）による権限制御
• Control Tower: ランディングゾーンの自動セットアップ、ガードレール、Account Factory
• IAM Identity Center: IDソース管理、Permission Sets、属性ベースアクセス制御（ABAC）

セキュリティ本試験では、これら3つの連携とその制約条件が頻出です。特に「できないこと」「制限」を正確に理解することが得点につながります。

---

第1部: AWS Organizations の深掘り

1.1 Organizations の基本設計

Organizations はマルチアカウント環境を一元管理するサービスです。本質は 階層的なアカウント管理 + ポリシー適用 です。

組織（Organization）

• ルートアカウント（管理アカウント）
  • OU（組織単位）
    • 本番アカウント A
    • 本番アカウント B
    • 本番アカウント C
  • OU（セキュリティ）
    • ログアーカイブアカウント
    • 監査用アカウント
  • OU（開発）
    • サンドボックスアカウント
    • ステージングアカウント

重要: 組織を作成すると、その時点のアカウント（最初のアカウント）が自動的に「管理アカウント」になります。この役割は変更できません。

1.2 SCP（Service Control Policy）の詳細評価ロジック

SCP は IAM ポリシーではなく、権限の上限（Permission Ceiling） です。

評価ロジックの詳細

最終的な実効権限 = IAM ポリシー ∩ SCP

つまり：

• IAM で許可されていても、SCP で拒否されれば ×
• SCP で許可されていても、IAM で拒否されれば ×
• 両方で許可されて初めて ○

重要な非互換性

SCP ≠ Permission Boundary

• SCP: OU/アカウントに適用。全IAMエンティティを制限
• Permission Boundary: ロール/ユーザーごとに設定。そのロール/ユーザーのみ制限

Allow List 戦略 vs Deny List 戦略

Allow List（推奨）：デフォルトで何も許可しない。必要なサービスだけを明示的に許可

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:*",
        "lambda:*"
      ],
      "Resource": "*"
    }
  ]
}

Deny List（シンプルだが危険）：デフォルトで全て許可。危険な操作だけを拒否

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUser",
        "iam:DeleteRole",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    }
  ]
}

試験で狙われるポイント:

• Allow List は「明示的に許可されたサービスのみ使用可能」だが、Deny List は「設定されたサービス以外は全て使用可能」
• 新しいサービスが AWS に追加された場合、Allow List では それが自動的に制限される（セキュリティ上有利）
• Deny List は設定漏れのリスクが高い

1.3 OU（Organization Unit）の設計パターン

パターン1: セキュリティ重視（推奨）

Root

• Security（最厳格SCP）
  • Audit Account
  • Log Archive Account
  • Security Tools Account
• Production（厳格SCP）
  • Workload A
  • Workload B
• Staging（中程度SCP）
  • Test Workloads
• Sandbox（最小制限SCP）
  • Experimentation Accounts

各 OU には異なるレベルの SCP を適用。開発チームは Sandbox で自由に実験でき、本番環境は強く制限されます。

パターン2: 部門別+環境別（企業向け）

Root

• Engineering
  • Eng-Prod
  • Eng-Staging
  • Eng-Dev
• Finance
  • Fin-Prod
  • Fin-Dev
• HR
  • HR-Prod
  • HR-Dev

部門別に管理者を分離でき、各部門内で環境を分けます。

パターン3: 地域別（グローバル企業向け）

Root

• APAC
  • Japan
  • Singapore
  • Australia
• EMEA
  • Germany
• Americas
  • US-East
  • US-West

地域別のコンプライアンス要件に対応します。

OU階層設計パターン図

1.4 SCP と Organizations の制約

1.5 委任管理者（Delegated Administrator）

AWS Organizations のポリシーは、管理アカウント所有者しか管理できません。しかし、特定のサービスについては、委任管理者 を指定して権限移譲できます。

# CloudTrail の委任管理者を指定する例
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal cloudtrail.amazonaws.com

委任可能なサービスの例:

• AWS Config
• CloudTrail
• SecurityHub
• GuardDuty
• CloudFormation StackSets
• Trusted Advisor
• CloudWatch Events (EventBridge)
• Service Catalog
• Cost Explorer
• Compute Optimizer
• License Manager

重要: 委任管理者は、そのサービスに限定した管理権限を持ちます。全体的な Organizations 管理権はありません。

1.6 その他のポリシータイプ

タグポリシー

アカウント内のタグ値を標準化・制限します。

{
  "tags": {
    "Environment": {
      "tag_key": {
        "@@assign": ["Environment"]
      },
      "enforced_for": {
        "@@assign": ["ec2:*", "rds:*"]
      },
      "tag_value": {
        "@@assign": ["prod", "staging", "dev"]
      }
    }
  }
}

バックアップポリシー

AWS Backup の設定を一元管理。OU 内の全リソースにバックアップルールを適用。

AIサービスオプトアウトポリシー

Claude、Bedrock などの AI サービスについて、学習データとしての使用をオプトアウト。GDPR などコンプライアンス要件への対応。

1.7 信頼されたアクセス（Trusted Access）

特定の AWS サービスに対して、Organizations の API に直接アクセスする権限を与えます。これにより、サービスがアカウント情報を取得し、自動的に機能を展開できます。

aws organizations enable-trusted-access \
  --service-principal cloudtrail.amazonaws.com

Trusted Access が有効になると、そのサービスは Organizations API を呼び出して組織構造を把握し、各アカウントへの自動展開が可能になります。

---

第2部: Control Tower の深掘り

2.1 Control Tower とは

Control Tower は、Organizations の上に構築された ランディングゾーン自動化フレームワーク です。

セットアップすると、以下が自動的に構成されます：

Landing Zone

• Organizations（自動構成）
• Logging Account
  • CloudTrail ログ保管
  • AWS Config ログ保管 ├── Audit Account │ ├── AWS Config アグリゲータ │ └── CloudTrail 一元ビュー ├── OU（自動生成） │ ├── Security OU │ ├── Sandbox OU │ └── Suspended OU └── SCPs（自動適用） ├── 予防的ガードレール └── 検出的ガードレール

### 2.2 ランディングゾーンの自動構成項目

#### 自動作成されるアカウント

1. **管理アカウント**: ユーザーが指定したアカウント
2. **Logging Account**: CloudTrail / AWS Config ログの一元保存
3. **Audit Account**: 監査、コンプライアンス チェック用

#### 自動作成される OU

1. **Root OU**: 直下のアカウント（管理アカウント）
2. **Security OU**: セキュリティ関連アカウント（Logging, Audit）
3. **Sandbox OU**: 実験用アカウント（Account Factory で作成される）
4. **Suspended OU**: 無効化されたアカウント（Account Factory で削除されたアカウント）

#### 自動適用される設定

- CloudTrail マルチアカウント・マルチリージョンログ
- AWS Config アグリゲータ
- SNS トピック（アラート用）
- CloudWatch ログ グループ

### 2.3 ガードレール（Guardrails）

ガードレールは、Control Tower が提供する **セキュリティ・コンプライアンス自動化** です。3種類あります。

#### ガードレール分類表

| 型 | メカニズム | 実装方法 | 効力 | 例 |
|---|-----------|--------|------|-----|
| **予防的（Preventive）** | アクションを事前に拒否 | SCP | 即座に遮断 | ログ無効化防止、リージョン制限 |
| **検出的（Detective）** | 違反を検出・報告 | AWS Config Rules | 事後対応 | 未暗号化データの検出、コンプライアンス状態確認 |
| **プロアクティブ（Proactive）** | CloudFormation 実行時に違反を検出 | CloudFormation Hooks | デプロイ前の検出 | リソース作成時のポリシー確認 |

#### 予防的ガードレール（SCP ベース）

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventCloudTrailDisable",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging"
      ],
      "Resource": "*"
    }
  ]
}

検出的ガードレール（AWS Config Rules ベース）

Config Rules を自動デプロイ。違反検出時は SNS 通知。

例：

• cloudtrail-enabled: CloudTrail が有効か
• mfa-enabled-for-iam-console-access: IAM ユーザーに MFA が有効か
• encrypted-volumes: EBS ボリュームが暗号化されているか

プロアクティブガードレール（CloudFormation Hooks）

CloudFormation テンプレートを実行する前に、ポリシー違反をチェック。違反があれば CloudFormation スタック作成を拒否。

# CloudFormation Hook（例）
Type: AWS::CloudFormation::Hook
Properties:
  Alias: "control-tower/require-rds-encryption"
  Description: "RDS インスタンスは暗号化が必須"
  Rules:
    - Rule: "require-encryption"
      Assertions:
        - Fn::EachMemberEquals:
            - Fn::ValueOf:
                - Resources/MyRDS
                - Properties/StorageEncrypted
            - true

2.4 Account Factory

Account Factory は、新しいアカウントを自動プロビジョニング するサービスです。

Account Factory の流れ

1. アカウント作成リクエスト（Service Catalog ポートフォリオから）
2. 承認ワークフロー（SNS 通知）
3. アカウント自動作成（Organizations API）
4. OU への自動配置
5. SCP・ガードレール自動適用
6. ログ設定自動適用

Account Factory の設定項目

• アカウント名: アカウント表示名
• アカウントメール: 一意のメール アドレス必須
• 組織単位（OU）: Sandbox か Security OU か指定
• IAM ロール: アカウント作成後に自動構成される IAM ロール

2.5 AFT（Account Factory for Terraform）

Account Factory for Terraform は、Terraform を使用してアカウントプロビジョニングを自動化するフレームワークです。

# Terraform コード例
module "account" {
  source = "github.com/aws-ia/terraform-aws-control_tower_account_factory"

  account_name = "my-workload"
  account_email = "workload@example.com"
  organizational_unit = "Production"
  sso_user_email = "admin@example.com"
  sso_user_first_name = "John"
  sso_user_last_name = "Doe"
}

AFT のメリット：

• Infrastructure as Code で Account Factory を管理
• CI/CD パイプラインでアカウント作成を自動化
• Terraform State で バージョン管理

2.6 カスタマイゼーション

Control Tower では、以下の点で カスタマイズが可能 です：

可能なカスタマイズ

1. カスタムガードレール: CloudFormation Hooks で独自ガードレール作成
2. Service Catalog 拡張: アカウント作成後の自動セットアップ（Lambda トリガー）
3. OU 構造の追加: Root 下に新たに OU を作成
4. タグポリシーの追加: Organizations のタグポリシーを組み合わせ

制限されるカスタマイズ

• Control Tower が作成した SCP の削除（予防的ガードレール）
• Logging / Audit アカウントの削除
• Security OU の削除（ただし内部構造の変更は可能）

2.7 Control Tower の制約と制限

2.8 Control Tower のベストプラクティス

1. 新規 Organizations で開始: 既存 Organizations がある場合は、Control Tower 用に新規組織を作成
2. Account Factory を徹底的に使用: 手動アカウント作成は避け、Account Factory で統一
3. ガードレール監視: 検出的ガードレール違反を定期的に確認、改善
4. OU 設計を先に決定: OU 構造が複雑になるほどカスタマイズ負荷が増大
5. AFT で IaC 化: Terraform でアカウント管理をコード化し、Git で履歴管理

---

第3部: IAM Identity Center（旧 AWS SSO）の深掘り

3.1 IAM Identity Center の概要

IAM Identity Center（旧 AWS SSO）は、マルチアカウント・マルチアプリケーション環境での一元的な ID・アクセス管理 を提供します。

IAM Identity Center
├── IDソース（内蔵 / AD / 外部 IdP）
│   └── ユーザー・グループ管理
├── Permission Sets
│   └── AWS アカウント への権限割り当て
└── アプリケーション統合
    └── SaaS アプリケーションへの SSO

3.2 IDソース（Identity Source）の詳細

IAM Identity Center は、複数のアイデンティティソースをサポートしています。

IDソース種別表

重要な制約:

一度 IAM Identity Center ネイティブで構成すると、他のソース（AD/外部 IdP）への変更は非常に困難 です。理由：

• ネイティブで作成したユーザーアカウントが IAM Identity Center 内に蓄積
• 別ソースに切り替えると、既存ユーザーアカウントが孤立
• Permission Sets などの割り当ては、新ソース上で再構成が必要

初期選択時は慎重に。企業 AD 環境がある場合は、最初から AD 連携を選択すべき。

3.3 Permission Sets の詳細

Permission Set は、AWS アカウント内で IAM ロール として展開される権限セット です。

Permission Set の本質

Permission Set は、複数の IAM ポリシーの組み合わせから、実行時に IAM ロールを生成します。

Permission Set
├── マネージドポリシー参照（AWS提供）
│   ├── AdministratorAccess
│   ├── ReadOnlyAccess
│   └── PowerUserAccess
├── カスタムポリシー
│   └── JSON で直接記述
├── インラインポリシー
│   └── Permission Set 内に JSON で定義
└── Permission Boundary
    └── この Permission Set の権限上限を定義

Permission Set のスコープ

Permission Set は、複数の AWS アカウントに同時に適用可能です。つまり、1 つの Permission Set で複数アカウントの権限を一元管理できます。

Permission Set: "DeveloperAccess"
├── ポリシー: "ec2:*, s3:*, lambda:*" など
└── 適用先アカウント:
    ├── Dev Account A
    ├── Dev Account B
    └── Dev Account C

Permission Set と IAM ロール の関係

Permission Set を ユーザー/グループに割り当てると、内部的には IAM ロール が各アカウントに作成されます。

# 内部で自動生成されるロール名
AWSSSORoleNameAssumedByUser-<PermissionSetName>

このロールは、ユーザーが IAM Identity Center ポータルから AWS Management Console にアクセスする際に、自動的に Assume されます。

3.4 Permission Set のポリシー構成パターン

パターン1: マネージドポリシーのみ

{
  "ManagedPolicies": [
    "arn:aws:iam::aws:policy/ReadOnlyAccess"
  ]
}

シンプルで、AWS が更新を管理。ただし細粒度制御ができない。

パターン2: マネージドポリシー + カスタムポリシー

{
  "ManagedPolicies": [
    "arn:aws:iam::aws:policy/ReadOnlyAccess"
  ],
  "InlinePolicies": {
    "AllowS3Write": {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "s3:PutObject",
          "Resource": "arn:aws:s3:::my-bucket/*"
        }
      ]
    }
  }
}

読み取り権限は AWS マネージド、書き込み権限はカスタムで制御。

パターン3: Permission Boundary の設定

{
  "ManagedPolicies": [
    "arn:aws:iam::aws:policy/AdministratorAccess"
  ],
  "PermissionBoundary": {
    "ManagedPolicies": [
      "arn:aws:iam::aws:policy/PowerUserAccess"
    ]
  }
}

AdministratorAccess を付与していても、Permission Boundary で PowerUserAccess に制限。これにより、IAM ロール管理など一部操作はできません。

3.5 属性ベースアクセス制御（ABAC）

Permission Set に Session Tags（セッションタグ） を定義することで、ユーザー属性に基づいた動的なアクセス制御が可能になります。

ABAC の実装例

{
  "SessionDuration": 3600,
  "SessionTags": [
    {
      "Key": "Department",
      "Value": "${aws:username}"
    },
    {
      "Key": "CostCenter",
      "Value": "Engineering"
    }
  ]
}

そして、IAM ポリシーで Session Tags を使用：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::company-data-${aws:SessionTag/Department}/*"
    }
  ]
}

ユーザー alice でログインすると、Session Tag Department=alice が付与され、s3:company-data-alice/ へのアクセスのみ許可。部門ごとの自動分離が実現できます。

3.6 MFA 設定

IAM Identity Center では、ユーザーレベルで MFA 設定ができます。

MFA 設定オプション

1. 必須にしない: ユーザーが任意で MFA を有効化
2. 全員必須: 全ユーザーに MFA が必須
3. Conditional（条件付き）: ユーザー属性やアクセスパターンに基づいて必須か判定

対応 MFA デバイス

• TOTP（Time-based One-Time Password）: Google Authenticator, Authy など
• FIDO2 Security Key: YubiKey, Titan Key など
• 仮想 MFA デバイス（AWS Vault など）

3.7 IAM Identity Center と Organizations の連携

IAM Identity Center は、Organizations と統合 して機能します。

Organizations
├── Accounts
│   ├── Account A
│   ├── Account B
│   └── Account C
└── IAM Identity Center（管理アカウントで有効化）
    ├── Permission Set X → Accounts A, B に適用
    ├── Permission Set Y → Accounts B, C に適用
    └── Permission Set Z → Accounts A, C に適用

アカウント追加時は、IAM Identity Center が自動的に新アカウントを認識し、Permission Set をプロビジョニングできます。

3.8 IAM Identity Center の制約と制限

3.9 IAM Identity Center のベストプラクティス

1. IDソース設計を最初に決定: 企業 AD やカーポレート IdP がある場合は、最初から連携設定
2. Permission Set を粒度よく設計: 部門別・役割別に分け、再利用性を重視
3. ABAC で動的アクセス制御: 部門数が多い場合は、静的 Permission Set より ABAC が運用効率化
4. MFA を全員必須化: セキュリティ観点から、初期設定で全員に MFA を強制
5. 定期的に Permission Set 監査: 不要な Permission Set や割り当てを削除

---

試験で狙われるポイント総括

Organizations

• SCP の評価ロジック: IAM と SCP の共通部分のみ実効権限。管理アカウントには SCP が効かない
• Allow List vs Deny List: Allow List は新サービス追加時に自動的に制限。Deny List は設定漏れリスク
• OU 階層の上限: 5 レベル（Root = 0）
• 委任管理者: 特定サービスのみ権限移譲可能

Control Tower

• ランディングゾーン自動構成: Logging / Audit アカウント自動作成、SCP 自動適用
• ガードレール 3 種類: 予防的（SCP）、検出的（Config Rules）、プロアクティブ（CloudFormation Hooks）
• 既存 Organizations 統合の困難性: Control Tower は既存 OU を上書きする
• Account Factory: Service Catalog ベース。Sandbox OU へのプロビジョニング自動化
• AFT: Terraform で Account Factory を IaC 化

IAM Identity Center

• リージョン唯一: 1 リージョンのみ有効化可能
• IDソース 4 種類: ネイティブ、AD、SAML 2.0、SCIM
• IDソース変更困難: ネイティブから他ソースへの変更は非常に複雑
• Permission Set: 複数アカウントに同時適用可能な権限セット
• ABAC: Session Tags でユーザー属性に基づいた動的制御

---

マルチアカウント運用パターン

シナリオ 1: スタートアップ（< 10 アカウント）

組織
├── 管理アカウント
├── Logging/Audit アカウント
├── 本番アカウント（1-2 個）
├── 開発アカウント
└── サンドボックス

設定：

• Organizations のみ。Control Tower は不要（手動管理で十分）
• Permission Set（IAM Identity Center）は 3-5 個程度
• SCP は Deny List ベース（シンプルさ重視）

シナリオ 2: 成長期企業（10-50 アカウント）

組織（Control Tower）
├── Security OU（Logging/Audit）
├── Production OU
│   ├── Workload A アカウント
│   ├── Workload B アカウント
│   └── Workload C アカウント
├── Staging OU
├── Sandbox OU（Account Factory）

設定：

• Control Tower でランディングゾーン自動化
• Account Factory で新アカウント自動プロビジョニング
• Permission Set は部門別・役割別に設計
• SCP は Allow List ベース（セキュリティ重視）

シナリオ 3: エンタープライズ（> 50 アカウント）

組織（Control Tower + AFT）
├── Security OU
├── Engineering OU
│   ├── Eng-Prod OU
│   ├── Eng-Staging OU
│   └── Eng-Dev OU
├── Finance OU
├── HR OU
└── APAC OU / EMEA OU / Americas OU

設定：

• Control Tower + AFT で Terraform IaC 化
• Permission Set は ABAC で動的制御
• SCP は複数組み合わせ（セキュリティ + 部門別制限）
• IAM Identity Center は Corporate AD / IdP と連携
• 委任管理者を各部門に割り当て

---

実装チェックリスト

Organizations のセットアップ

• Organizations を作成
• 管理アカウント ID を確認（削除不可）
• OU 構造を設計（ビジネス要件に基づく）
• OU を作成
• SCP を OU に適用（Allow List か Deny List か決定）
• 既存アカウントを OU に移動
• CloudTrail マルチアカウント ログ設定

Control Tower のセットアップ

• ランディングゾーン設定を開始
• Logging / Audit アカウント メールアドレスを入力
• プライマリリージョンを指定
• ガードレール有効化（予防的・検出的）
• Account Factory 有効化
• Service Catalog ポートフォリオ確認

IAM Identity Center のセットアップ

• IAM Identity Center 有効化（指定リージョン）
• IDソース選択（ネイティブ / AD / 外部 IdP）
• ユーザー・グループ作成（またはディレクトリ連携）
• Permission Set 設計・作成
• AWS アカウントへ Permission Set 割り当て
• MFA 設定（全員必須にするか判定）
• ユーザーに Permission Set 割り当て
• ブラウザで IAM Identity Center ポータルでテストログイン

---

まとめ

AWS のマルチアカウント戦略は、Organizations（管理）→ Control Tower（自動化）→ IAM Identity Center（認証・認可） の 3 層から成り立ちます。

試験合格の鍵：

1. SCP の評価ロジック を完全に理解（Allow list vs Deny list、管理アカウント例外）
2. ガードレール 3 種類 の違いを正確に区別
3. IDソース変更の困難性 を認識（初期設計が重要）
4. 制約条件 を網羅的に把握（OU 5 レベル上限、リージョン唯一など）

これらを理解できていれば、SCS-C03 試験のマルチアカウント関連問題は確実に得点できるレベルです。