# AWS Organizations でCloudTrail全社監査基盤を作る（2026年版）：組織トレイル・委任管理者・ログアーカイブアカウント・SCP・Control Towerで全アカウントの証跡を集約する

> マルチアカウント環境でCloudTrailを全社統制する設計を公式に忠実に解説。組織トレイルで全メンバーに自動適用、委任管理者で監査チームが運用、専用ログアーカイブアカウントへ集約、SCPで証跡の無効化を防止、Control Tower連携とクロスアカウント分析まで実コードで組む。

- 公開日: 2026-06-27
- 著者: 友田 陽大
- タグ: AWS, CloudTrail, AWS Organizations, マルチアカウント, ガバナンス, Terraform
- URL: https://tomodahinata.com/blog/aws-cloudtrail-organization-trail-multi-account-audit-guide
- カテゴリ: AWS CloudTrail 監査・ガバナンス
- 総合ガイド: https://tomodahinata.com/blog/aws-cloudtrail-audit-logging-governance-security-guide

## 要点

- 組織トレイル(organization trail)は管理アカウントまたは委任管理者アカウントで一度作れば全メンバーアカウントに自動適用される。メンバーはトレイルを参照できるが、ログ停止・削除・変更は一切できず、デフォルトではログファイル自体にもアクセスできない
- 委任管理者(最大3つ)を登録すれば、管理アカウントの認証情報を日常運用に使わずに、監査チームのアカウントから組織トレイルを管理できる。ただしトレイルの所有者は管理アカウントのまま
- ログは専用のログアーカイブアカウントの集中S3バケット(SSE-KMS・整合性検証・最小権限)に集約する。これはAWS Security Reference Architecture(SRA)が推奨する構成
- SCPでcloudtrail:StopLogging/DeleteTrail/UpdateTrail/PutEventSelectorsをDenyし証跡の無効化を組織的に封じる。ただしSCPは管理アカウントには一切効かない——ここが設計上の急所
- Control Towerのランディングゾーンは組織トレイルとログアーカイブ/監査アカウントを自動構成する(landing zone 3.0で各アカウント個別トレイルから組織トレイルへ移行済み)

---

「**全アカウントのCloudTrail、ちゃんと有効になってますか？**」——監査法人にこう聞かれて、即答できる組織は多くありません。

アカウントは増えます。dev・staging・prod、チームごと、プロダクトごと、買収先ごと。気づけば10、20とアカウントが並び、**それぞれで誰かが個別にCloudTrailを設定し（あるいは忘れ）、ログはバラバラのバケットに散らばり、横断調査は不可能**になっている——これがマルチアカウント環境で最もよく見る監査の破綻です。

私はマルチアカウント・多段商流のB2B SaaSや、サーバーレス（Lambda + DynamoDB）の[決済プラットフォームの信頼性レイヤー](/case-studies/payment-platform-reliability)を設計・運用し、**本番二重課金0件**を維持してきました。その経験から断言できるのは、**監査基盤は「各アカウントの善意」ではなく「組織のコードで強制」しないと必ず破綻する**ということです。アカウントは無限に増えてよい。だが**監査は1か所に集約し、改ざんできない形で固定する**。これがマルチアカウント・ガバナンスの中核です。

この記事は、**AWS Organizations を前提に CloudTrail を「全社の監査基盤」として設計する**ための実装ガイドです。組織トレイル・委任管理者・ログアーカイブアカウント・SCP・Control Tower を、Terraform / JSON / CLI の実コードで一気通貫に組みます。

> **この記事の前提と関連記事**：CloudTrail 単体の仕組み（4つのイベント種別／証跡の作り方／SSE-KMS／ログ整合性検証／公式セキュリティBP）は、本記事では繰り返しません。基礎は柱記事 [AWS CloudTrail 完全ガイド](/blog/aws-cloudtrail-audit-logging-governance-security-guide) を参照してください。本記事は**マルチアカウント／組織トレイルに特化**して深掘りします。仕様・料金・条件は **AWS 公式ドキュメント（2026年6月時点）** に照合済みですが、本番投入前に必ず最新ドキュメントを確認してください。アカウントID・組織ID・バケット名は例示です。

---

## 0. メンタルモデル：「アカウントは増える。監査は1か所に集約する」

設計を始める前に、目指す全体像を一行で固定します。

> **全社CloudTrail監査基盤 ＝ 組織トレイルを1本だけ作り、全メンバーアカウントの証跡を、専用のログアーカイブアカウントの集中バケットに、改ざんできない形で集約する。**

図にするとこうです。

```text
AWS Organizations (all features enabled)
│
├─ 管理アカウント (Management account) ── ※SCPが効かない特別なアカウント
│   └─ 組織トレイル(organization trail)を所有
│        └─ 委任管理者(Security/Audit account)へ運用を委譲
│
├─ ログアーカイブアカウント (Log Archive account)
│   └─ 集中S3バケット (SSE-KMS + 整合性検証 + Object Lock)
│        └─ AWSLogs/<組織ID>/<アカウントID>/CloudTrail/<region>/...
│             ↑ 全メンバーのログがここに集まる
│
├─ メンバーアカウント A (prod)  ── トレイルは「見える」が変更不可
├─ メンバーアカウント B (dev)   ── 同上。SCPでStopLogging等をDeny
└─ メンバーアカウント C (...)   ── アカウント追加時に自動でトレイル適用
```

この図の各要素——「組織トレイルを1本」「委任管理者へ委譲」「ログアーカイブアカウントへ集約」「SCPで守る」——を、これから1つずつコードで組んでいきます。まず、なぜアカウント単位の証跡が破綻するのかを言語化します。

---

## 1. なぜアカウント単位の証跡では破綻するか

マルチアカウントで「各アカウントに個別のトレイルを作る」アプローチは、規模が小さいうちは動きますが、必ず4つの問題で崩れます。

| 問題 | アカウント単位トレイルで起きること |
| --- | --- |
| **増殖** | アカウントが増えるたびに手作業でトレイルを作る。設定値（暗号化・リージョン・整合性検証）がアカウントごとにブレる |
| **抜け漏れ** | 新規アカウントでトレイル作成を忘れる。「全アカウント有効」を証明できない（監査で詰む） |
| **改ざんリスク** | 各アカウントの管理者が自分のトレイルを `StopLogging` / `DeleteTrail` できてしまう。侵害された攻撃者が真っ先に証跡を消す |
| **横断調査不能** | ログが各アカウントの別々のバケットに散らばり、「組織全体で誰がIAMポリシーを変更したか」を1クエリで追えない |

この4つを構造的に解決するのが**組織トレイル**です。「全アカウントに自動適用・メンバーは変更不可・ログは1か所に集約」を、組織の機能として実現します。順に見ていきます。

---

## 2. 組織トレイルの仕組み：一度作れば全メンバーに自動適用

### 2-1. 公式が保証する5つの性質

組織トレイルは AWS Organizations と統合された特別なトレイルです。公式ドキュメントが保証する性質を正確に押さえます（出典: [Creating a trail for an organization](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html)）。

| 性質 | 公式の保証 |
| --- | --- |
| **作成元** | 管理アカウント、**または**委任管理者アカウントで作成する |
| **自動適用** | 「組織トレイルを作成すると、組織に属する各メンバーアカウントに、同じ名前のトレイルのコピーが作成される」。後からアカウントが追加されても「組織トレイルとサービスリンクロールが自動で追加され、そのアカウントのログ記録が自動的に開始される」 |
| **メンバーは変更不可** | メンバーアカウントのユーザーは `describe-trails` 等で組織トレイルを**参照できる**が、「組織トレイルを削除したり、ログのオン／オフを切り替えたり、記録するイベント種別を変更したり、その他いかなる変更も行う十分な権限を持たない」 |
| **ログは非参照（既定）** | 「デフォルトでは、管理アカウントのみがトレイルのS3バケットとその中のログにアクセスできる」。メンバーは自分のログすら見られない |
| **共通ARN** | トレイルのARNは全メンバーアカウントで同一（例: `arn:aws:cloudtrail:us-east-1:111111111111:trail/MyOrgTrail`） |

ここが効きます。**メンバーアカウントの管理者であっても、組織トレイルを止められない・消せない**。これが「各アカウントの善意に依存しない」監査基盤の核心です。

### 2-2. 前提条件（CLI/Terraformで作る場合）

公式が要求する前提を満たしていないと、組織トレイルは作れません（出典: [Prepare for creating a trail for your organization](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-an-organizational-trail-prepare.html)）。

- **組織で「すべての機能(all features)」が有効**であること。「一括請求(consolidated billing)のみ」では作れません。
- **CloudTrail の信頼されたアクセス(trusted access)を Organizations で有効化**していること。CLI/API で作るなら手動で有効化が必要です（コンソール作成時は暗黙的に有効化されます）。
- 管理アカウントに **`AWSServiceRoleForCloudTrail`** サービスリンクロールが必要（CloudTrail が各メンバーでログを記録するため）。

> **コスト注意**：組織トレイルは、メンバーアカウントに既存のトレイルがあっても、それに**追加で**作成されます。あるメンバーが「同じ管理イベントを収集する2本目のトレイル」を持つと、**2本目のコピー分は課金されます**（管理イベントのリージョンごと1コピー目は無料）。組織トレイルを入れたら、メンバー側の重複トレイルは整理しましょう。料金の詳細は [CloudTrail料金最適化ガイド](/blog/aws-cloudtrail-pricing-cost-optimization-guide) を参照。

### 2-3. Terraform で組織トレイルを作る

`aws_cloudtrail` リソースに `is_organization_trail = true` を指定します。CLI/Terraform のデフォルトは**シングルリージョン**なので、全社監査では必ず `is_multi_region_trail = true` を明示します。

```hcl
# 管理アカウント(または委任管理者アカウント)のプロバイダで実行する。
# S3バケットとKMSキーは ログアーカイブアカウント側にある(後述)。

resource "aws_cloudtrail" "org" {
  name = "org-audit-trail"

  # ── ログアーカイブアカウントの集中バケット ──
  s3_bucket_name = "org-cloudtrail-logs-central" # Log Archiveアカウントのバケット
  kms_key_id     = var.central_kms_key_arn       # 同アカウントのCMK

  # ── 全社監査の必須設定 ──
  is_organization_trail         = true # ★全メンバーに自動適用
  is_multi_region_trail         = true # ★全リージョンを記録(既定はsingle)
  enable_log_file_validation    = true # ★ログ整合性検証(SHA-256 digest)
  include_global_service_events = true # IAM/STS等のグローバルイベント

  # 管理イベントは全アカウント分を確実に記録
  advanced_event_selector {
    name = "Log all management events"
    field_selector {
      field  = "eventCategory"
      equals = ["Management"]
    }
  }

  depends_on = [aws_organizations_organization.this] # 信頼されたアクセスを先に
}
```

> Terraform AWS provider の `is_organization_trail` は「Can only be created in the organization master account」と明記されています。委任管理者から作る場合も、組織の管理アカウントが所有者になります。

これで「組織トレイル1本」が立ち上がりました。ただしこのままだと、トレイルの所有・運用はすべて**管理アカウント**で行うことになります。次はこれを監査チームに委譲します。

---

## 3. 委任管理者でガバナンスを分離する

### 3-1. なぜ委任管理者が必要か

管理アカウント（請求の親アカウント）は、組織で最も強力なアカウントです。**ここの認証情報を日常運用で使うのは、最小権限の原則に反します**。そこで CloudTrail は**委任管理者(delegated administrator)** をサポートします。

> **委任管理者** ＝ 組織内のメンバーアカウントで、（一部の例外を除き）CloudTrail において管理アカウントと同じ管理タスクを実行できるアカウント（出典: [Delegated administrator](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-delegated-administrator.html)）。

これにより、**セキュリティ／監査チーム専用のアカウントから組織トレイルを運用**し、管理アカウントは「組織の構成変更」だけに限定できます。AWS Security Reference Architecture(SRA) でいう **Security Tooling アカウント**がこの役割を担うのが定石です。

| 項目 | 公式仕様 |
| --- | --- |
| **最大数** | 組織あたり**最大3つ**の CloudTrail 委任管理者 |
| **所有権** | 委任管理者が作成したトレイル等のリソースは、**所有者は管理アカウントのまま**。委任管理者を解除してもリソースは削除されない |
| **登録元** | **管理アカウントの管理者のみ**が委任管理者を登録できる |
| **委任管理者ができないこと** | 委任管理者の追加／削除、組織トレイルのアカウントレベルへの変換 等は管理アカウント専用 |

### 3-2. 委任管理者を登録する（CLI）

CloudTrail のネイティブAPIで登録します（管理アカウントで実行）。

```bash
# 管理アカウントで実行: メンバーアカウント(Security/Auditアカウント)を委任管理者に登録
aws cloudtrail register-organization-delegated-admin \
  --member-account-id 222222222222
```

解除するときは、パラメータ名が `--member-account-id` ではなく **`--delegated-admin-account-id`** に変わる点に注意してください（公式CLIリファレンスで確認済み）。

```bash
# 委任管理者を解除する(管理アカウントで実行)
aws cloudtrail deregister-organization-delegated-admin \
  --delegated-admin-account-id 222222222222
```

> CloudTrail のネイティブCLI/APIで登録すると、必要なサービスリンクロール（`AWSServiceRoleForCloudTrail` など）が自動作成されます。一方、**Organizations 側のCLI/API（`organizations register-delegated-administrator`）で登録すると、CloudTrailのサービスリンクロールは自動作成されません**。CloudTrail のコマンドを使うのが安全です。

### 3-3. 登録に必要なIAM権限

委任管理者を割り当て／解除するIAMプリンシパルには、公式が定める以下のアクションが必要です（出典: [Required permissions to assign a delegated administrator](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-delegated-administrator-permissions.html)）。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssignDelegatedAdminForCloudTrail",
      "Effect": "Allow",
      "Action": [
        "cloudtrail:RegisterOrganizationDelegatedAdmin",
        "cloudtrail:DeregisterOrganizationDelegatedAdmin",
        "organizations:RegisterDelegatedAdministrator",
        "organizations:DeregisterDelegatedAdministrator",
        "organizations:ListAWSServiceAccessForOrganization",
        "iam:CreateServiceLinkedRole",
        "iam:GetRole"
      ],
      "Resource": "*"
    }
  ]
}
```

> 注意：この**委任管理者割り当て用ポリシー**には `organizations:EnableAWSServiceAccess` や `organizations:ListAccounts` は含まれません。それらは「組織トレイルの作成」に必要な別ポリシーの権限です。役割を混同しないこと。CloudTrail の service principal は `cloudtrail.amazonaws.com`、イベントコンテキスト用は `context.cloudtrail.amazonaws.com` です。

これで「運用は監査チームのアカウント、所有は管理アカウント」という権限分離が完成しました。次は、ログの集約先を専用アカウントに固めます。

---

## 4. ログアーカイブアカウントへ集約する（AWS SRA準拠）

### 4-1. なぜ専用アカウントなのか

組織トレイルのログを、管理アカウントや本番アカウントのバケットに置くのは悪手です。AWS Security Reference Architecture(SRA) は、**専用の「Log Archive アカウント」にすべてのセキュリティログを集約する**ことを推奨しています（出典: [Security OU – Log Archive account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html)）。

> 「Log Archive アカウントは、すべてのセキュリティ関連ログとバックアップを取り込み・アーカイブすることに専念する。AWS SRA で示す主要ログには CloudTrail（組織トレイル）が含まれる。」

SRA のアカウント構成は次の3つが基本です。

| アカウント | 役割 |
| --- | --- |
| **Org Management account（管理アカウント）** | 組織を所有。CloudTrail の信頼されたアクセスを許可し、組織トレイルを作成・所有する |
| **Security Tooling account** | セキュリティサービスの委任管理者。ここから組織トレイルを運用する |
| **Log Archive account** | 集中S3バケット＋KMSキーを保持。全アカウントのログがここに集まる |

> **正確を期す（UNVERIFIED に近い注意）**：SRA の権威ある記述では、**組織トレイルそのものは管理アカウントが信頼されたアクセス経由で作成・所有**し、**ログは Log Archive アカウントのバケットに集約**します。「CloudTrail を Security Tooling アカウントに委任管理する」のは可能（§3）ですが、SRA が明示的に委任管理者へ委譲するサービス一覧（Config・GuardDuty・Security Hub 等）に CloudTrail は列挙されていません。委任管理者の利用は有効な選択肢ですが、SRA の標準形は「管理アカウントが組織トレイルを所有し、Log Archive にログを集約」である点を押さえてください。

### 4-2. 組織トレイル用のS3バケットポリシー（HCL）

組織トレイル用のバケットポリシーは、単一アカウントのものと**resource ARN が違います**。公式は3つのステートメントを定義します（出典: [Amazon S3 bucket policy for CloudTrail – organization trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html)）。

- **AclCheck**: `s3:GetBucketAcl`（バケットARN）
- **Write（管理アカウント分）**: `AWSLogs/<管理アカウントID>/*` — 組織トレイルを単一アカウントトレイルに戻したときのため
- **OrganizationWrite**: `AWSLogs/<組織ID>/*` — ★組織のパス（アカウントIDではなく**組織ID** `o-xxxxxxxxxx`）

重要なのは、3つすべての `aws:SourceArn` が**管理アカウントIDを使ったトレイルARN**であることです。公式は「組織トレイルでは `aws:SourceArn` の値は管理アカウントが所有し、管理アカウントIDを使うトレイルARNでなければならない」と明言します。

```hcl
# ログアーカイブアカウントのプロバイダで実行する。
# 例: bucket=org-cloudtrail-logs-central, org=o-abc123example,
#     mgmt account=111111111111, region=us-east-1, trail=org-audit-trail

data "aws_iam_policy_document" "org_trail_bucket" {
  # 1) ACLチェック
  statement {
    sid     = "AWSCloudTrailAclCheck20150319"
    effect  = "Allow"
    actions = ["s3:GetBucketAcl"]
    principals {
      type        = "Service"
      identifiers = ["cloudtrail.amazonaws.com"]
    }
    resources = [aws_s3_bucket.central.arn]
    condition {
      test     = "StringEquals"
      variable = "aws:SourceArn"
      values   = [local.org_trail_arn] # arn:aws:cloudtrail:us-east-1:111111111111:trail/org-audit-trail
    }
  }

  # 2) 管理アカウント分の書き込み(組織トレイル→単一に戻す場合の保険)
  statement {
    sid     = "AWSCloudTrailWrite20150319"
    effect  = "Allow"
    actions = ["s3:PutObject"]
    principals {
      type        = "Service"
      identifiers = ["cloudtrail.amazonaws.com"]
    }
    resources = ["${aws_s3_bucket.central.arn}/AWSLogs/111111111111/*"]
    condition {
      test     = "StringEquals"
      variable = "s3:x-amz-acl"
      values   = ["bucket-owner-full-control"]
    }
    condition {
      test     = "StringEquals"
      variable = "aws:SourceArn"
      values   = [local.org_trail_arn]
    }
  }

  # 3) ★組織全体の書き込み(組織IDのパス)
  statement {
    sid     = "AWSCloudTrailOrganizationWrite20150319"
    effect  = "Allow"
    actions = ["s3:PutObject"]
    principals {
      type        = "Service"
      identifiers = ["cloudtrail.amazonaws.com"]
    }
    resources = ["${aws_s3_bucket.central.arn}/AWSLogs/o-abc123example/*"]
    condition {
      test     = "StringEquals"
      variable = "s3:x-amz-acl"
      values   = ["bucket-owner-full-control"]
    }
    condition {
      test     = "StringEquals"
      variable = "aws:SourceArn"
      values   = [local.org_trail_arn]
    }
  }
}
```

> **`aws:SourceOrgID` も使える**：混乱した代理人(confused deputy)対策として、AWS は `aws:SourceArn` / `aws:SourceAccount` に加え、グローバル条件キー **`aws:SourceOrgID`** をサポートし、組織単位でのアクセス制限に推奨しています（出典: [IAM confused deputy](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)）。`aws:SourceOrgID` を組織IDに設定すると「組織外のCloudTrailログがバケットへ書き込むこと」を防げます。ただし公式の組織トレイル**標準例は `aws:SourceArn` ＋ 組織IDパス**で構成されており、`aws:SourceOrgID` はそれを補強する条件キーとして使うのが正確な理解です。

### 4-3. KMSキーポリシー（CloudTrailがCMKで暗号化できるように）

集中バケットを SSE-KMS で暗号化する場合、CMK のキーポリシーに CloudTrail の暗号化を許可するステートメントが必要です（出典: [Configure AWS KMS key policies for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail.html)）。

```json
{
  "Sid": "AllowCloudTrailEncryptLogs",
  "Effect": "Allow",
  "Principal": { "Service": "cloudtrail.amazonaws.com" },
  "Action": "kms:GenerateDataKey*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:SourceArn": "arn:aws:cloudtrail:us-east-1:111111111111:trail/org-audit-trail"
    },
    "StringLike": {
      "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:111111111111:trail/*"
    }
  }
}
```

`aws:SourceArn` には組織トレイルのARN（管理アカウントID）を、`aws:SourceAccount` 相当には管理アカウントIDを使う点が、組織トレイルならではの注意点です。

### 4-4. 改ざん耐性を「コードで」固める

ログアーカイブバケットは、攻撃者・運用者の双方から守る必要があります。柱記事のセキュリティBPに加え、マルチアカウントでは特に以下を固定します。

- **S3 Object Lock（コンプライアンスモード）** または **MFA Delete**：ログの上書き・削除を物理的に不可能にする。
- **ライフサイクル**：`Glacier` への階層移行とコンプライアンス要件に応じた保持期間。
- **最小権限**：監査チームの読み取り以外、バケットへの書き込みは CloudTrail サービスプリンシパルのみ。
- **`AWSCloudTrail_FullAccess` の付与を最小化**：このマネージドポリシーは最も重要な監査機能を無効化できる。SRA も「付与する人数を可能な限り少なく」と警告しています。

---

## 5. SCPで証跡を守る：「止められない」を組織で強制する

組織トレイルは「メンバーが**そのトレイルを**変更できない」ことは保証しますが、**メンバーが自分のアカウントで別の悪さをする**（例: ログ送信先のバケットを攻撃する、Insights を無効化する）余地は残ります。そこで **SCP(Service Control Policy)** で、CloudTrail の無効化操作そのものを組織的にDenyします。

### 5-1. 証跡無効化を禁止するSCP

AWS Control Tower の必須コントロール「Disallow Configuration Changes to CloudTrail」が、まさにこの目的のAWS純正SCPです。汎用化すると次の形になります。

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

Control Tower の純正版は、自動化ロールを例外にしつつ対象を自社トレイルARNに絞っています（参考: [Control Tower mandatory controls](https://docs.aws.amazon.com/controltower/latest/controlreference/mandatory-controls.html)）。

```json
{
  "Sid": "GRCLOUDTRAILENABLED",
  "Effect": "Deny",
  "Action": [
    "cloudtrail:DeleteTrail",
    "cloudtrail:PutEventSelectors",
    "cloudtrail:StopLogging",
    "cloudtrail:UpdateTrail"
  ],
  "Resource": ["arn:aws:cloudtrail:*:*:trail/aws-controltower-*"],
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/AWSControlTowerExecution"
    }
  }
}
```

### 5-2. 設計上の急所：SCPは管理アカウントに効かない

ここを外すと設計が崩れます。公式が**繰り返し**明言しています（出典: [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)）。

> 「**SCPは管理アカウントのユーザーやロールには影響しない。** メンバーアカウントにのみ影響する。」
> 「SCPで制限できないタスク：**管理アカウントが実行するあらゆるアクション**」

つまり——

- **SCPは「メンバーアカウントが証跡を無効化すること」は防げる**。委任管理者として指定されたメンバーアカウントにもSCPは適用されます。
- **SCPは「管理アカウントで起きること」は一切防げない**。組織トレイルを管理アカウントが所有している場合、SCPでそのトレイルを保護することはできません。管理アカウントのアクセスは別手段（厳格なIAM、認証情報の保管、CloudTrailのイベント監視）で守る必要があります。
- **SCPは「すべての機能(all features)」が有効な組織でのみ使える**。一括請求のみの組織では使えません。

> 管理アカウントの認証情報を日常運用から排除し（§3の委任管理者）、管理アカウントでの操作自体を監視対象にする——「SCPで守れない領域」をどう埋めるかが、ガバナンス設計の腕の見せどころです。AWS公式のSCPサンプルは [aws-samples/service-control-policy-examples](https://github.com/aws-samples/service-control-policy-examples) にも集約されています。

---

## 6. Control Tower を使う場合：自動構成と自前構築の使い分け

ここまでを**自前で**組む代わりに、**AWS Control Tower** のランディングゾーンを使えば、組織トレイルとログアーカイブ/監査アカウントが**自動構成**されます。

### 6-1. Control Tower が自動構成するもの

公式の明言（出典: [Logging with CloudTrail](https://docs.aws.amazon.com/controltower/latest/userguide/about-logging.html)）。

> 「AWS Control Tower はランディングゾーンのセットアップ時に新しい CloudTrail トレイルを設定する。これは**組織レベルのトレイル**で、管理アカウントと全メンバーアカウントのすべてのイベントを記録する。」

| Control Tower が作るもの | 内容 |
| --- | --- |
| **組織トレイル** | 管理アカウントに組織レベルのCloudTrailトレイルをデプロイ（信頼されたアクセス経由） |
| **Log Archive アカウント** | 既定名「Log archive」。全ログを集中保管するS3バケットを持つ共有アカウント |
| **Audit アカウント** | 既定名「Audit」。クロスアカウントのセキュリティ監査用の共有アカウント |
| **必須SCP** | CloudTrail/Config バケットの暗号化・ライフサイクル変更や `StopLogging` 等を禁止するSCPを自動適用 |

> **歴史的な重要変更（確認済み）**：Control Tower は**かつて各メンバーアカウントに個別トレイルを作っていました**が、**landing zone version 3.0 で組織トレイルへ移行**しました。公式は「3.0 に更新すると、CloudTrailトレイルが組織トレイルになる。各アカウントレベルのトレイルは削除されるが、既存のログファイルはS3バケットに保持される」と明記しています。古い記事の「Control Towerはアカウントごとにトレイルを作る」という記述は**現在は誤り**です。

### 6-2. 自前構築 vs Control Tower

| 観点 | 自前(本記事§2-5) | Control Tower |
| --- | --- | --- |
| **立ち上げ速度** | 遅い（自分で全部組む） | 速い（ランディングゾーンが一括構成） |
| **柔軟性** | 高い（要件に完全に合わせられる） | 中（Control Towerの枠内。3.0以降は組織トレイルの管理をオプトアウトして自前運用も可能） |
| **ガードレール** | 自分でSCPを書く | 必須・推奨コントロールが標準装備 |
| **向くケース** | 既存の独自マルチアカウント、IaCで全管理したい | これから組織を立ち上げる、ベストプラクティス準拠を最短で |

> Control Tower が**自前の組織トレイルを使う／自前トレイルを別途運用する**選択肢は、landing zone 3.0以降で提供されています（オプトアウトして自分で CloudTrail を管理可能）。なお Control Tower は自身の組織トレイルを**管理アカウントの信頼されたアクセス**で運用しており、CloudTrailの委任管理者を登録するわけではありません。

---

## 7. 全社の横断調査：クロスアカウントAthenaとLake

ログが1か所に集まったら、**組織全体を1クエリで調査**できます。

### 7-1. クロスアカウントAthena（推奨）

監査担当（Audit アカウント）が、Log Archive アカウントの集中バケットを Athena でクエリする標準パターンです。バケットがKMS暗号化されているため、AWSは**3つの許可**を求めます（出典: [Athena cross-account access](https://docs.aws.amazon.com/athena/latest/ug/cross-account-permissions.html)）。

1. Log Archive アカウントの**S3バケットポリシー**が、Auditアカウントの引き受けロールに `s3:GetObject` / `s3:ListBucket` 等を許可。
2. Log Archive アカウントの**KMSキーポリシー**が、同ロールに `kms:Decrypt` / `kms:DescribeKey` 等を許可。
3. Audit アカウントの**IAMロール**が、対向のバケットとキーへのアクセスを許可。

これが揃えば、組織IDパーティション付きのテーブルに対して、こう問えます。

```sql
-- 組織全体で、過去24時間に「ルートユーザー」が行った操作をすべて洗い出す
SELECT eventtime, recipientaccountid, eventsource, eventname, sourceipaddress
FROM org_cloudtrail_logs
WHERE useridentity.type = 'Root'
  AND eventtime > to_iso8601(current_timestamp - interval '1' day)
ORDER BY eventtime DESC;
```

`recipientaccountid` で**どのメンバーアカウントの操作か**が分かるのが、組織トレイルならではの強みです。Athenaのパーティション設計やパーティション射影の詳細は[柱記事のAthena節](/blog/aws-cloudtrail-audit-logging-governance-security-guide)を参照してください。

### 7-2. CloudTrail Lake の組織イベントデータストア（現状の注意）

CloudTrail Lake の**組織イベントデータストア**は、組織内の全アカウント・複数リージョンのイベントを1か所に集約し、Trino互換のSQLで横断クエリできます。管理アカウントまたは委任管理者から作成でき、委任管理者が作っても実体は管理アカウントに存在します。

> **重要（確認済み）**：**CloudTrail Lake は 2026年5月31日をもって新規顧客の受付を終了しました**（既存顧客は継続利用可）。公式は「Lake は重要なバグ修正とセキュリティ更新のみ受ける」とし、Lakeデータの **Amazon CloudWatch への移行**を推奨しています（出典: [CloudTrail Lake service availability change](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-service-availability-change.html)）。これから全社監査基盤を**新規に**作るなら、分析基盤は **Athena ＋ 集中S3** を本線に据えるのが現実的です。

### 7-3. 検知（脅威検知は別記事へ）

組織トレイルを EventBridge / CloudWatch Logs に流せば、「ルートユーザーのログイン」「`StopLogging` の試行」などを組織横断でニアリアルタイム検知できます。脅威検知・インシデントレスポンスの設計は、姉妹記事 [CloudTrailによる脅威検知とインシデントレスポンス](/blog/aws-cloudtrail-security-threat-detection-incident-response-guide) と、[GuardDutyのマルチアカウント脅威検知](/blog/aws-guardduty-threat-detection-multi-account-terraform-eventbridge-guide) に譲ります。本記事の主眼は「証跡を全社で**集約・保全**する基盤」です。

---

## 8. まとめ：全社CloudTrail監査基盤チェックリスト

マルチアカウントのCloudTrail監査基盤は、「各アカウントの善意」ではなく「組織のコードで強制」して初めて成立します。最後に、本番投入前のチェックリストで締めます。

**組織トレイル**

- [ ] 組織で「すべての機能(all features)」が有効
- [ ] CloudTrail の信頼されたアクセスを有効化
- [ ] 組織トレイルを1本作成（`is_organization_trail = true`）
- [ ] **マルチリージョン**（`is_multi_region_trail = true`、CLI/TF既定はsingle）
- [ ] ログ整合性検証（`enable_log_file_validation = true`）
- [ ] グローバルサービスイベントを含める

**ガバナンス分離**

- [ ] Security/Audit アカウントを委任管理者に登録（管理アカウントの認証情報を日常運用に使わない）
- [ ] 委任管理者は最大3つ・所有者は管理アカウントのまま、を理解

**ログ集約（SRA準拠）**

- [ ] 専用のログアーカイブアカウントに集中S3バケット
- [ ] 組織トレイル用バケットポリシー（`AWSLogs/<組織ID>/*`、`aws:SourceArn`は管理アカウントのトレイルARN）
- [ ] SSE-KMS（CMKキーポリシーに `aws:SourceArn` 条件）
- [ ] S3 Object Lock / MFA Delete・ライフサイクル・最小権限
- [ ] `AWSCloudTrail_FullAccess` の付与を最小化

**証跡の保全**

- [ ] SCPで `StopLogging` / `DeleteTrail` / `UpdateTrail` / `PutEventSelectors` をDeny
- [ ] **SCPは管理アカウントに効かない**前提で、管理アカウントを別手段で防御

**横断調査**

- [ ] クロスアカウントAthena（S3＋KMS＋IAMの3点許可）
- [ ] 新規構築の分析基盤はAthena＋S3を本線に（Lakeは新規受付終了）

---

アカウントは、これからも増えます。事業が伸びれば、チームが増え、買収もあり、環境も分かれる。**増えてよいのです。** 監査が1か所に集約され、改ざんできない形で固定され、組織のコードで強制されている限り。

私は一人 × 生成AI（Claude Code）という体制で、マルチアカウント・多段商流のB2B SaaSや本番二重課金0件のサーバーレス決済基盤を、**速く・安全に**設計・運用してきました。その肝は常に「正しさを運用の注意深さではなく、コードの構造とガバナンスで保証する」ことにあります。本記事の組織トレイル・委任管理者・SCP・ログアーカイブアカウントは、まさにその思想をAWS Organizations 上で具現化したものです。

> **全社AWSガバナンスの相談**：「アカウントが増えて監査が追えない」「ランディングゾーンをコードで設計したい」「監査法人に証跡を求められた」——こうした課題は、組織トレイルとログアーカイブアカウントの設計で構造的に解けます。マルチアカウント・ガバナンス／ランディングゾーン設計のご相談は [お問い合わせ](/contact) からどうぞ。鍵レスCI/CD（[GitHub Actions OIDC](/blog/github-actions-oidc-keyless-cicd-aws-gcp-guide)）やコスト最適化（[Terraform FinOps](/blog/aws-terraform-startup-cost-optimization-finops)）と合わせ、速く・安く・安全なAWS基盤を一気通貫で設計します。