概要

AWS Organizations の組織証跡は、管理アカウントから一度設定するだけで全メンバーアカウントのログを自動収集できる便利な仕組みです。しかし、S3 バケットポリシーと KMS キーポリシーを正しく設定しないと、ログがバケットに届かないという落とし穴があります。本記事では、その仕組みと原因・対処法を解説します。

目次

組織証跡とは何か
設定の流れ
必要な権限設定 ── ここが最重要
なぜ GenerateDataKey が必要なのか
IAM ロールの役割 ── いつ使うのか
組織証跡 vs シングルアカウント証跡
料金について
トラブルシューティングチェックリスト
終わりに
参考文献・参考サイト

1. 組織証跡とは何か

AWS Organizations を使ったマルチアカウント環境では、各アカウントで個別に CloudTrail 証跡を設定する方法と、管理アカウントから組織全体に一括展開する「組織証跡」 を設定する方法があります。

組織証跡の最大のメリットは、新規メンバーアカウントにも自動的に証跡が適用される点です。アカウントが増えるたびに手動で設定する手間が省け、全ログを単一の S3 バケットに集約できるため、セキュリティ監査の一元管理が実現します。

2. 設定の流れ

管理アカウントのコンソールから以下の手順で設定します。

① 管理アカウントで CloudTrail コンソールを開く
② 「証跡の作成」で「組織内のすべてのアカウントで有効にする」にチェック
③ ログ保存先の S3 バケットを指定
④ （任意）SSE-KMS 暗号化を有効にして CMK を指定
⑤ 作成完了 → 全メンバーアカウントに自動展開

CLIで設定する場合は以下のようになります（ap-northeast-1 リージョンを例に使用しています）。

aws cloudtrail create-trail \
  --name my-org-trail \
  --s3-bucket-name my-org-cloudtrail-bucket \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --region ap-northeast-1

設定後、証跡を有効化することを忘れずに。

aws cloudtrail start-logging --name my-org-trail --region ap-northeast-1

3. 必要な権限設定

組織証跡を作成しただけでは、ログがバケットに届かないケースがあります。以下の 2 つのポリシー設定 が揃って初めて正常に動作します。

設定箇所	必要な内容
S3 バケットポリシー	CloudTrail サービスプリンシパルが組織証跡用プレフィックス（`o-xxxxxxxx/`）に `PutObject` できること
KMS キーポリシー	CloudTrail サービスプリンシパルが `GenerateDataKey` と `DescribeKey` を呼び出せること

この 2 つのどちらかが欠けると、ログがバケットに届かなくなります。それぞれの設定例を示します。

S3 バケットポリシーの例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSCloudTrailAclCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::my-org-cloudtrail-bucket",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/my-org-trail"
        }
      }
    },
    {
      "Sid": "AWSCloudTrailWrite",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-org-cloudtrail-bucket/AWSLogs/o-abc123def4/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    }
  ]
}

重要なポイント：Resource のパスに o-abc123def4（組織 ID）が含まれていることに注目してください。これが組織証跡ならではの設定です。

KMS キーポリシーの例

{
  "Sid": "Allow CloudTrail to use the key",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudtrail.amazonaws.com"
  },
  "Action": [
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

4. なぜ `GenerateDataKey` が必要なのか

KMS の設定で「Encrypt ではなく GenerateDataKey を許可する」という点に疑問を持つ方もいるでしょう。これは エンベロープ暗号化（Envelope Encryption） という仕組みによるものです。

日常的なアナロジーで説明すると、「KMS はマスターキーを保管する金庫」で、「データキーは実際に荷物（ログファイル）に鍵をかけるための南京錠」です。金庫から南京錠を借り出して荷物を施錠し、南京錠自体を金庫に返す、というイメージです。

処理の流れを整理すると以下の通りです。

CloudTrail が KMS に GenerateDataKey を呼び出す
KMS が「①平文データキー」と「②暗号化済みデータキー」を返す
CloudTrail が平文データキーでログファイルを暗号化する
暗号化されたログと暗号化済みデータキーを S3 に保存する
平文データキーはメモリ上から即座に破棄される

API	用途	仕組み
`Encrypt`	4KB 以下の小さなデータを CMK で直接暗号化	KMS に平文を送って暗号文を受け取る
`GenerateDataKey`	大きなデータ用にデータキーを生成	KMS がデータキーを作り、クライアント側でそのキーを使って暗号化する

CloudTrail のログファイルは 4KB を超えることがほとんどです。そのため Encrypt API では直接暗号化できず、エンベロープ暗号化の仕組みを使います。CloudTrail は Encrypt API を呼び出しません。GenerateDataKey を許可しないと、暗号化自体ができなくなります。

5. IAM ロールの役割

「CloudTrail が S3 や KMS にアクセスするとき、IAM ロールが必要なのでは？」と思うかもしれません。しかし、CloudTrail は IAM ロールではなく、サービスプリンシパル（cloudtrail.amazonaws.com）として直接アクセスします。

CloudTrail → S3：サービスプリンシパルとして PutObject
CloudTrail → KMS：サービスプリンシパルとして GenerateDataKey

そのため、バケットポリシーやキーポリシーで許可する対象は「IAM ロール」ではなく cloudtrail.amazonaws.com です。

IAM ロールが必要になるのは、CloudTrail → CloudWatch Logs 連携のときです。

シナリオ	認証方式
CloudTrail → S3 にログ保存	サービスプリンシパル（IAM ロール不要）
CloudTrail → KMS で暗号化	サービスプリンシパル（IAM ロール不要）
CloudTrail → CloudWatch Logs にログ送信	IAM ロールが必要

組織証跡で S3 に書き込む場合は IAM ロールは不要です。バケットポリシーとキーポリシーで直接許可するのが正しい方式です。

6. 組織証跡 vs シングルアカウント証跡

比較項目	シングルアカウント証跡	組織証跡
作成場所	各アカウントで個別に作成	管理アカウントから一括作成
対象範囲	そのアカウントのみ	組織内の全アカウント
メンバーアカウントでの操作	各自で設定・削除可能	メンバーは削除・変更不可（読み取りのみ）
S3 保存パス	`AWSLogs/{アカウントID}/...`	`AWSLogs/{組織ID}/{アカウントID}/...`
バケットポリシー	単一アカウントの PutObject を許可	組織 ID プレフィックスへの PutObject を許可する必要あり
展開の手間	アカウントが増えるたびに手動設定	新規アカウントにも自動適用
監査の一元管理	困難（各アカウントからコピーが必要）	1つのバケットに自動集約

S3 パスの違いがバケットポリシーに影響する

# シングルアカウントの場合
s3://my-bucket/AWSLogs/123456789012/CloudTrail/ap-northeast-1/...

# 組織証跡の場合
s3://my-bucket/AWSLogs/o-abc123def4/123456789012/CloudTrail/ap-northeast-1/...
                       ↑ 組織 ID が入る！

この組織 ID プレフィックスが入る点が最大のポイントです。既存バケットをシングルアカウント用のポリシーのまま組織証跡に使い回すと、組織 ID プレフィックスへの PutObject が許可されていないため、ログの書き込みがブロックされます。

7. 料金について

注意：以下の料金は 2025年3月時点の情報です。料金は変動する可能性がありますので、必ず AWS CloudTrail 料金ページで最新情報をご確認ください。

各リージョンにおいて、管理イベントの最初のコピーを S3 バケットに配信するための証跡の作成は無料です。つまり、組織証跡の管理イベント（最初のコピー）は追加料金なしで利用できます。

追加コピーや、データイベント・ネットワークアクティビティイベントを配信する場合は有料になります。

機能	料金（ap-northeast-1）
管理イベント（各リージョンで最初のコピー）	無料
管理イベント（追加コピー）	$2.00 / 100,000 イベント
データイベント	$0.10 / 100,000 イベント
ネットワークアクティビティイベント	$0.10 / 100,000 イベント
CloudTrail Insights（管理イベント）	$0.35 / 100,000 イベント（分析タイプごと）

なお、S3 ストレージ料金は CloudTrail とは別に発生します。また、組織証跡を設定すると、メンバーアカウント側にも証跡が複製されます。メンバーアカウント側で既存の証跡が管理イベントを収集している場合、同じイベントを重複して収集することになり、追加料金が発生する可能性があります。コスト管理の観点から、メンバーアカウントの既存証跡との重複に注意してください。

8. トラブルシューティングチェックリスト

組織証跡を設定したにもかかわらずログが届かない場合、以下のポイントを順番に確認してください。

✅ S3 バケットポリシーに組織 ID（o-xxxxxxxx）プレフィックスへの PutObject が許可されているか
✅ KMS キーポリシーに cloudtrail.amazonaws.com への GenerateDataKey と DescribeKey が許可されているか
✅ 証跡のロギングが start-logging で有効化されているか
✅ 管理アカウントで AWS Organizations と CloudTrail の信頼関係が有効化されているか
✅ メンバーアカウントでの重複証跡による意図しないコスト増加がないか

KMS キーポリシーに GenerateDataKey* ではなく Encrypt しか許可していないケースは特によくあるミスです。エンベロープ暗号化の仕組み上、GenerateDataKey がなければ暗号化自体が行えず、ログは保存されません。

9. 終わりに

本記事では、AWS Organizations の組織証跡設定における S3 バケットポリシーと KMS キーポリシーの正しい設定方法を解説しました。ポイントをまとめます。

S3 バケットポリシー：組織証跡は保存パスに組織 ID（o-xxxxxxxx）が含まれるため、そのプレフィックスへの PutObject を明示的に許可する必要があります。シングルアカウント用の既存ポリシーをそのまま流用すると失敗します。

KMS キーポリシー：CloudTrail はエンベロープ暗号化を使用するため、Encrypt ではなく GenerateDataKey の許可が必要です。DescribeKey もあわせて許可してください。

IAM ロール：S3 や KMS へのアクセスはサービスプリンシパル（cloudtrail.amazonaws.com）で行われるため、IAM ロールは不要です（CloudWatch Logs 連携の場合は別途必要）。

次のステップとして、組織証跡を設定した後は以下の発展的なトピックにも取り組んでみてください。

CloudTrail Lake を使った SQL ベースのログ分析
Amazon Athena と S3 を組み合わせたコスト効率の高いログ分析基盤の構築
AWS Config との組み合わせによるコンプライアンス管理の自動化

参考文献・参考サイト

「AWS CloudTrail とは」AWS Documentation, https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-user-guide.html
「組織の証跡の作成」AWS Documentation, https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/creating-trail-organization.html
「CloudTrail のログファイルの Amazon S3 バケットポリシー」AWS Documentation, https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html
「AWS KMS を使用した CloudTrail ログファイルの暗号化」AWS Documentation, https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/encrypting-cloudtrail-log-files-with-aws-kms.html
「エンベロープ暗号化」AWS Documentation, https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/concepts.html#enveloping
「Managing CloudTrail trail costs」AWS Documentation, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trail-manage-costs.html
「AWS CloudTrail の料金」AWS Documentation, https://aws.amazon.com/jp/cloudtrail/pricing/