COLUMN

2025.3.19 ｜ Writer：NTT東日本　荒井

AWS OrganizationsにおけるCloudTrailの設定について

	こんにちは、荒井です。

Organizationsで管理するアカウントが増えれば増えるほど、アカウント全体に対してどのようにガバナンスを効かせるのかという課題に当たると思います。そのうちの一つに「CloudTrailを使ったアカウント全体のログ収集」があると思いますが、今回はそのCloudTrailをどのように設定すべきなのかという点について考えていきたいと思います。

Organizationsを使って複数のアカウントを管理しているシステム管理者にとって一つの参考となれば幸いです。

AWSのアカウント発行やセキュリティ・ガバナンスの構築などNTT東日本のAWSリセールサービスについてご説明します。お気軽にお問い合わせください。

概要
ログの保存先について: どのアカウントにS3バケットを作成するか; どのように削除や改ざんから保護するか; CloudTrailの改ざん検知（整合性の検証）
Organizationsの全アカウントに対するCloudTrailの設定: CloudTrailの組織証跡機能を使用する; StackSetsを使用したCloudTrailの作成
まとめ

概要

CloudTrailを設定する際の主なポイントとしては、「ログがセキュアに保存されること」、「ログが改ざんや削除から保護されること」、「ログの改ざんを検知できること」になるかと思います。

そのため、保存されるS3バケットをどこに置くのか、削除保護をどのように行うのか、整合性の検証をどのように行うのか、ということをしっかりと検討する必要があります。

以下、それぞれ具体的に見ていきたいと思います。

ログの保存先について

どのアカウントにS3バケットを作成するか

まず、どこにS3バケットを作成するか、ということなのですが、これは基本的にそれ専用のアカウントに作成するのがよいと言われています。

Organizationsの管理アカウントや、CloudTrailの管理委任アカウントにS3バケットを保存する方法も考えられますが、そうしたアカウントから切り離すことで不正なアクセスや誤操作による削除や改ざんの確立を減らすことが可能になります。

CloudTrailの証跡が保存されるS3バケットは専用のアカウントに保存し、アクセス権限も必要最低限にしておくことが望まれます。一度設定すればこのS3専用アカウントにログインすることはほとんどないと思いますので、ログインするための認証情報自体削除しておいてもよいかと思います。

どのように削除や改ざんから保護するか

S3バケットには「MFA削除」や「オブジェクトロック」といった削除や改ざんを防止する機能があります。こうした機能を最大限活用し、セキュアにログを保存することが望まれます。

「MFA削除」は、S3バケットのオブジェクトを削除する際に多要素認証（MFA）を求める設定を行う機能です。この設定を行うことで、誤った操作による削除を防ぐことが可能です。ちなみに、このMFA認証で使用するコードは何かというと、ルートユーザーでAWSマネジメントコンソールにログインする際に使用するコードです。

「オブジェクトロック」は、S3バケットのオブジェクトが一定期間、削除もしくは上書きされないようにする機能です。この設定を行うことで、改ざんや削除を防ぐことが可能です。

以下、それぞれどのように設定するのか具体的に解説します。

S3バケットのMFA削除有効化

S3バケットに対してMFA削除の有効化を行うためには、ルートユーザーのアクセスキーが必要です。そのため、まずはルートユーザーのアクセスキーを作成します。

作成したアクセスキーをコピーもしくはCSVファイルでダウンロードします。なお、セキュリティの関係上、このアクセスキーはMFA削除の有効化完了後に削除することを強く推奨します。

多要素認証（MFA）の箇所に記載されている識別子をコピーしておきます。こちらは後で使用します。

CloudShellを起動し、管理権限へ昇格するため以下のコードを実行します。この際に先ほど作成したアクセスキーIDとシークレットアクセスキーを使用します。

aws configure

管理権限に昇格できたら、以下のコードを実行します。コードの可変部分については以下を参考にしてください。

<backet name>：S3バケット名
<MFAの識別子>：先ほどコピーした多要素認証（MFA）の識別子
<MFAコード>：MFA端末に表示されているコード

aws s3api put-bucket-versioning --bucket <backet name> --versioning-configuration MFADelete=Enabled,Status=Enabled --mfa "<MFAの識別子> ＜MFAコード＞"

※実行して完了した際に「complete」的な表示はありません。

設定が正しく完了しているか確認するため、以下のコードを実行します。

<backet name>にはS3バケット名を記載してください。

aws s3api get-bucket-versioning --bucket <backet name>

画像のように”MFA Delete”：”Enabled”と表示されていればMFA削除は正しく設定されています。

使用したアクセスキーはセキュリティの関係上必ず削除しておきましょう。

オブジェクトロック

Amazon S3から該当のS3バケットを選択し、「プロパティ」タブからオブジェクトロックの「編集」を選択します。

オブジェクトロックの編集画面において保持モードや保持期間といった設定内容を選択し、「変更の保存」を選択します。

保持モードとして「ガバナンス」と「コンプライアンス」がありますが、以下の違いがあります。

ガバナンス：特定のユーザーはオブジェクトの削除や保持期間の変更が可能
コンプライアンス：いかなるユーザーも保持期間中はオブジェクトの削除や保持期間の変更が不可能

基本的にはコンプライアンスモードが推奨されますが、自社の環境によって適切な方を選ぶ必要があります。

この設定を行うことでオブジェクトロックが完了します。

MFA削除の設定およびオブジェクトロックの設定を行うことで改ざんや削除から保護されることになります。

CloudTrailの改ざん検知（整合性の検証）

CloudTrailのログファイルが改ざんされていないか、ハッシュ値を基に整合性検証を行うことが可能です。この機能を有効化するためには、CloudTrailの証跡を設定する際に「ログファイルの検証」を有効にする必要があります。

整合性の検証を行う際は、CloudShellなどのCLI環境から以下のコードを実行することで可能です。可変となる部分は以下を参考にしてください。

<trailARN>：CloudTrail証跡のARN
<start-time>：整合性の検証を行うログの開始時間（UTC）（例：2024-10-01T00:00:00Z）
<CheckAccount-id>：整合性の検証を行う対象のAWSアカウントID

aws cloudtrail validate-logs --trail-arn <trailARN> --start-time <start-time> --account-id <CheckAccount-id>

整合性検証の結果、正常であれば「valid」、異常があれば「INVALID:<内容>」と出力されます。

定期的な整合性検証を行うことで、実際に改ざんが行われていないか確認することが可能です。

Organizationsの全アカウントに対するCloudTrailの設定

CloudTrailをOrganizations全体で適用させていくための方法についても考えていきたいと思います。Organizationsの全アカウントにCloudTrailを設定する方法としては主に以下2つの方法があります。

CloudTrailにおける組織の証跡機能を使用する（簡単に設定可能）
CloudFormation StackSetsを使って各アカウントにCloudTrailの証跡を作成する（手間だが柔軟な対応が可能）

このうち、「CloudTrailにおける組織の証跡機能を使用する」方法は「適用させるのが簡単」というメリットがあります。Organizationsの管理アカウントもしくは管理権限が委任されているメンバーアカウントからCloudTrail証跡を作成する際、「組織内のすべてのアカウントについて有効化」にチェックを入れるだけで設定できるため、最も簡単な方法だと思われます。

しかし、デメリットとして「アカウントごとに柔軟な設定ができない」というのが挙げられます。この機能を使用する場合は強制的に全アカウントに証跡が同じ設定で作成されるため、例えば「一部のアカウントだけ異なるS3バケットにログを出力したい」といったような柔軟な対応を行うことができません。

2つ目の方法として「CloudFormation StackSetsを使って各アカウントにCloudTrailの証跡を作成する」という方法があります。このメリットは上記のデメリットである「アカウントごとに柔軟な設定を行うことが可能」という点です。もし、他のアカウントと異なる設定を行いたい場合、StackSetsの対象から該当アカウントを外せばCloudTrailの証跡が作成されないため、後から独自の設定を行ったCloudTrail証跡を作成することが可能です。

デメリットとしては「設定するのが手間」というのがあります。1つ目に紹介した方法ではチェックボックスにチェックを入れるだけで完了しますが、この方法ではStackSetsのテンプレートを用意したり、保存先のS3バケットに対して適切なバケットポリシーを設定する必要があります。また、作成されたCloudTrail証跡は各アカウントから削除可能であるため、必要に応じてSCPで制限するなどの対応が必要です。

2つの方法でそれぞれメリット・デメリットがありますが、何か特殊な事情があって一部のアカウントに対してはCloudTrailの証跡を作成したくない、もしくは一部のアカウントに対して特殊な設定を行う必要がある、といった要件がないのであれば、CloudTrailの組織証跡機能を使用するのが一般的かと思います。

以下、それぞれ実際の設定方法などについても解説していければと思います。

CloudTrailの組織証跡機能を使用する

組織の証跡を設定することは非常に簡単です。CloudTrailページにおいて「証跡の作成」を選択し、その後の編集画面において「組織内のすべてのアカウントについて有効化」のチェックボックスをチェックした状態で証跡を作成すればOrganizationsの各アカウントにCloudTrail証跡が作成されます。

※S3バケットに対するバケットポリシーの編集もAWS側で勝手に行ってくれます。

この方法で各アカウントに作成されたCloudTrailの証跡にアクセスしてみると、「この証跡は組織の管理アカウントによって作成されました」という表示があり、各アカウントから証跡を削除もしくはログ記録の停止を行うことができないようになっています。

StackSetsを使用したCloudTrailの作成

StackSetsから各アカウントにCloudTrail証跡を作成する場合は、大まかにS3バケットに対する「バケットポリシーの設定」と「StackSetsの作成」の2つが必要になります。

S3バケットへのバケットポリシーの設定

「Amazon S3」のページからCloudTrailのログを格納するS3バケットを選択し、「アクセス許可」タブからバケットポリシーの「編集」を選択します。

バケットポリシーを更新します。

設定するバケットポリシーとしては例えば以下のようなものが考えられます。

このバケットポリシーでは、該当のOrganizationsからの”s3:PutObject”を許可しています。

※あくまで参考ですので、実際に使用する際には適宜修正いただければと思います。

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Sid": "AWSCloudTrailAclCheck",
         "Effect": "Allow",
         "Principal": {
             "Service": "cloudtrail.amazonaws.com"
         },
         "Action": "s3:GetBucketAcl",
         "Resource": "<S3 ARN>",
         "Condition": {
             "StringLike": {
                 "aws:SourceArn": "arn:aws:cloudtrail:<region>:*:trail/*"
             }
         }
     },
     {
         "Sid": "AWSCloudTrailWrite20150319",
         "Effect": "Allow",
         "Principal": {
             "Service": "cloudtrail.amazonaws.com"
         },
         "Action": "s3:PutObject",
         "Resource": "<S3 ARN>/AWSLogs/*/*",
         "Condition": {
             "StringEquals": {
                 "aws:SourceOrgID": "<OrganizationsID>",
                 "s3:x-amz-acl": "bucket-owner-full-control"
             },
             "StringLike": {
                 "aws:SourceArn": "arn:aws:cloudtrail:<region>:*:trail/*"
             }
         }
     }
 ]
}

StackSetsの作成

「CloudFormation」ページの左メニューから「StackSets」を選択し、「StackSetsを作成」を選択します。

編集画面でStackSetsテンプレート（JSONもしくはYAMLファイル）をアップロードするか、もし既にS3バケットにテンプレートが保存されている場合はS3 URLを入力します。

テンプレートとしては、例えば以下のようなものが考えられます。

このテンプレートでは、マルチリージョンのログ取得や整合性の検証が有効化されています。

※あくまで参考ですので、実際に使用する際には適宜修正いただければと思います。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'StackSet for deploying CloudTrail across multiple accounts'

Parameters:
  CloudTrailBucketName:
    Type: String
    Description: 'Name of the S3 bucket to store CloudTrail logs'
  
Resources:
  CloudTrail:
    Type: 'AWS::CloudTrail::Trail'
    Properties:
      IsLogging: true
      IsMultiRegionTrail: true
      IncludeGlobalServiceEvents: true
      EnableLogFileValidation: true
      S3BucketName: !Ref CloudTrailBucketName