この記事でできること
- CloudTrailについて
- CloudTrailの証跡について
- CloudTrailの証跡の作成
- CloudTrailの証跡の稼働確認
はじめに
リスクの監査、ガバナンス、コンプライアンスの支援サービスであるCloudTrail。ですので、個人で自分のために使用する機会はまずないでしょう。が、業務目的で個人アカウントでの検証はしばしばあると思います。設定内容そのものは大したことないのですが、若干面食らう箇所もありますので、そういった箇所も丁寧に解説していきたいと思います。
ゴール
証跡作成後の構成は以下のようになります。

CoudTrailについて
以下画像のとおり、CloudTrailそのものはAWSアカウント取得と同時に裏で稼働しており、設定は不要です。

つまりガバナンス、コンプライアンス、監査のための下準備はAWSが整えてくれているわけです。上記のイベントは90日間保持されます。90日を超えて保持する場合がほとんどでしょうから、その保存先として「S3」(※)となります。次項で説明する「証跡」は簡単に言えば、なんのログをどのS3に送信するか、の設定でしかないです。
※厳密にはCoudWatchLogsも保存は可能ですが、分析目的で転送することがほとんどで料金もS3よりも高いことから、永続的なログ保管先はS3が推奨となります。
CoudTrailの証跡について
証跡において、いくつか大事な項目がありますので、以下参考にしてください。
・プレフィックス
証跡を記録するバケット内でさらに細分化させる場合に指定します。S3バケットのみを指定した場合はCloudTrailは、以下のようにフォルダが自動作成されデータが格納されていきます。
<S3バケット>
└AWSLogs/
└<アカウント番号>
└CloudTrail
└<リージョン名>
└/<year>/<month>/<day>
プレフィックスを指定すると、「S3バケット」と「AWSLogs」の間にもう一階層挟むことができます。すなわち下記のような構造となります。
<S3バケット>
└<プレフィックス>
└AWSLogs
└<アカウント番号>(・・以下同様)
証跡ごとに格納先を分ける場合にプレフィックスを指定します。例えば、管理イベントのみの証跡とデータイベントのみの証跡を作成した場合、一律で同じ場所に格納すると、どっちがどっちか分からなくなります。
以下画像は2種類の証跡を同じバケットに格納した場合の画像です(塗りつぶしの箇所はアカウント番号)。どれがどの証跡かは、少なくとも私には分かりません。

・管理イベント
デフォルトで証跡としてOnになっている項目となります。(もちろんOffにすることもできます)

AWS公式には以下のように説明されています。
管理イベントでは、AWS アカウントのリソースで実行される管理オペレーションについて知ることができます。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html
うーん、、分からない。。
この項目は簡単に言えば、「AWSの操作履歴」と言い換えてよいかと思います。上画像のとおり、記録対象を選択できます。読み取り/書き込み、はそのままの意味で、読み取りのみが行われる管理イベント、書き込みが行われる管理イベント、という意味となります。
「AWS KMSイベントの除外」は、チェックを入れることで「除外」されます。すなわちチェック無しは、記録(S3に格納)されることを意味します。Encrypt、Decrypt、GenerateDataKey などの AWS KMS アクションは大量に発生して、S3へ格納される=課金額が増大する、ことを防ぐための処置だと思われます。
また、Tipsとして、「Encrypt、Decrypt、GenerateDataKey 」は読み取りとして記録されるため、Encrypt、Decrypt、GenerateDataKey が不要で、Disable、Delete、ScheduleKey などのイベントを記録したい場合は、読み取りをOff、書き込みをOn、AWS KMSイベントの除外をOffにすればOKです。文字にするとややこしいですが、図にすると分かりやすいです。状況に応じてカスタマイズしてください。

通常、Encrypt、Decrypt、GenerateDataKey などの AWS KMS アクションは、大容量イベント (99% 以上) を生成します。これらのアクションは、[読み取り] イベントとしてログに記録されるようになりました。Disable、Delete、および ScheduleKey などの小容量の関連する AWS KMS アクション (通常、AWS KMS イベントボリュームの 0.5% 未満を占める) は、Write イベントとしてログに記録されます。Encrypt、Decrypt、GenerateDataKey のようなボリュームの大きなイベントを除外し、Disable、Delete、ScheduleKey などの関連イベントを記録する場合は、[書き込み] 管理イベントを記録することを選択し、[Exclude AWS KMS events] チェックボックスをオフにします。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html
「Amazon RDS のデータAPIイベントを除外」も同じ理屈ですので割愛します。
・データイベント
データイベントは感覚的に分かりやすいかと思います。EC2の起動イベントなどがそれにあたります。AWS公式には以下のように説明されています。
データイベントでは、リソース上またはリソース内で実行されたリソースオペレーションについて知ることができます。
https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html
CoudTrailの証跡の作成
マネジメントコンソールにログイン後、検索ボックス等から「CloudTrail」までいってください。CloudTrailのトップ画面まで行ったら、左上の三本線(下記画像の黄色塗り箇所)をクリックし、メニューを開きます。
メニュー内にある「証跡」をクリックします。
※混乱するので画像には収めませんでしたが、トップ画面右の方に「証跡の作成」があります。仕様はよく分からないのですが、過去に証跡を作成したことが無い場合トップ画面で証跡の作成をクリックすると、「クイック証跡の作成」となるようです(補足1にて説明)。クイック証跡は詳細な設定ができないため、トップ画面では「証跡の作成」はクリックしません。

右にある「証跡の作成」をクリックします。

「証跡名」「ストレージの場所」は必ず必要な情報となります。「ログファイルのSSE-KMS暗号化」は利用しないのであれば、有効のチェックを外します。今回は有効にし、KMSを新規で作成したいと思います。AWS KMSエイリアスは、別名/通称と呼ばれるものですが、あだ名と思えばよいと思います。
その他はデフォルト値で「次へ」をクリックします。(CloudWatchLogsについては、いつか別記事で纏めたいですね)

ログイベントの選択では、今回はデフォルトで「次へ」をクリックします。(「管理イベント」のみにしたいと思います)

確認と作成で設定値を確認して「証跡の作成」をクリックします。
問題なく作成できていることを確認します。

CloudTrailの証跡の稼働確認
S3サービスへ移り、先ほど設定したCloudTrailバケットが作成されていることを確認します。中に入っていくと、以下のようにリージョンごとのフォルダが生成されていることが分かります。(複数リージョンについては補足2で説明します)
画像は割愛しますが、各リージョンフォルダ ⇒ year ⇒ month ⇒ dayの各フォルダへ入っていくことでCloudTrailログにたどり着きます。

さいごに
CloudTrailの証跡についての説明と、実際に証跡を作成してみました。他サービスと連動して初めて意味のあるものになるので、結構記事が巨大になりましたね。おそらく業務でAWSを利用する上でCloudTrailを使用しない選択肢は無いように思います。(閉じた検証環境などであれば不要かもしれませんが)
CloudTrailの設定そのものはそこまで複雑なものではないことが分かってもらえたら良かったです。そのうち、CloudTrailとEventBeidgeの連携(イベント駆動)や、CloudTrailログの読み方、等を記事にしていければいいなと思っています。
補足も是非読んでみてください。
補足1 クイック証跡について
CloudTrail利用前のトップ画面にも証跡の作成があります。仕様はよく分からないのですが、過去に証跡を作成したことが無い場合トップ画面で証跡の作成をクリックすると、「クイック証跡の作成」となるようです。クリック証跡は、証跡名を入力するだけで、証跡が作成できる、というものです。確かにクイック・・。


補足2 マルチリージョンの証跡について
以下画像を見てもらうと分かりますが「マルチリージョンの証跡」というカラムがあります。

このカラムが「いいえ」の場合、指定リージョンのみということになります。つい最近までは、「指定リージョンのみ」or「マルチリージョン」を証跡作成時点で選択することができました。ただし当時から「指定リージョンのみ」は非推奨でした。その理由について以下記載します。
今回ap-northeast-1(東京リージョン)でしか操作をしていません。しかし、東京リージョンしか使っていないつもりでも、AWS的には実は別リージョンも利用しています(利用しているつもりはなくともログ記録されるようなAPIが走っています)。その証拠が以下の「us-east-1」(米国東部:バージニア北部)で記録された、マネージメントコンソールのログインに関するイベントです。

証跡としてバケットにus-east-1が保管されていることも確認できます。

このようにCloudTrailの目的からして、リージョンを絞る、ことは推奨されません。そして、おそらくですが最近「リージョンの指定」はどうやら不可になったようです。少なくともこの記事を書いている中で、リージョンを指定するような項目は見当たりませんでした。念のため、作成した証跡に対して「編集」を押したら、以下のような文言を見つけました。
"コンソールで作成された証跡は、マルチリージョンの証跡です。"

マルチリージョンのみとなったようです。「マルチ」の対象については以下記事を参考にしてください。(有効になっているリージョンが「マルチ」の対象です。)

補足3 KMSについて(リソースベースポリシーについて1)
今回、証跡の作成と同時にKMSを新規で作成しました。作成したKMSが以下です。

ただ、補足として書きたいのは、以下のKMSキーポリシーです(抜粋、塗りつぶし箇所はアカウント番号)。ポリシーの読み方は別記事に纏めるとして、今お伝えしたいのは、これが「リソースベースのポリシー」です。ソリューションアーキテクトの試験でよくよく混乱した記憶があります。このKMSというリソースにポリシーを付与することで、使っていい人/使ってはダメな人/使ってもいいけど条件付き、等の設定をできます。
会社の備品倉庫カギの管理運用で「管理者のみ使用してよい。ただし、管理者の承認があれば管理者補佐も使用してよい。一般部員は一切使用できない」というようなルールを決めておくのと同じことです。

補足4 S3バケットポリシーについて(リソースベースポリシーについて2)
こちらも、リソースベースポリシーです。
CloudTrailログを格納しているS3バケットに行き、「アクセス許可」をクリックしてください。少し下に行ったところでバケットポリシーを確認できるかと思います。バケットポリシーも、「リソースベースのポリシー」です。バケットポリシーは、最後の関所、というイメージで私はいます。というのも、データの取り出し/読み込み/格納、どの操作であれS3はエンドに位置するためです。こういった構成のイメージを持つと、構成変更の際どこに目を付ければいいか当たりが付くようになってきます。この当たりが付くようになってきたら、(そのAWS業務における)中級者という感じですね。

話が逸れましたが、バケットポリシーには「CloudTrail」というサービスを信頼(Principal)し、当該バケットへのGetBucketAcl(アクセス制御リストの読み込み)とPutObject(書き込み)がAllow(許可)されています。他にも条件句が記載されていますが、まずはこれくらいの読み方でいいと思います。
ちなみに、このバケットポリシーを削除するとどうなるか、、、を試してみたいと思います。上図の「バケットポリシー」のすぐ下にある「削除」をクリックして、バケットポリシーを削除します。数分後CloudTrailでは以下のようなエラーが発生していました。

つまり、「暗黙のDeny」ですね。CloudTrailというサービス、つまり分かりやすく言えば他人が自分の持ち物に勝手に書き込みをしようとしている状況なわけですから、エラーになります。言ってしまえばそりゃそうなんですが、こういう検証って地味に大切だと思います。