この記事で分かること
- CloudTrailログの取得について
- ログの整形について
はじめに
CloudTrailは、リスクの監査、ガバナンス、コンプライアンスの支援をしてくれますが、CloudTrailは言い方を悪くすれば、よく分からんがとりあえず全て保存しとけーー!というものです。そのため、いざ出力されたログを見ると「?」となってしまいます。そこでこの記事では、CloudTrailログの取得から整形の方法までを紹介したいと思います。
CloudTrailログの取得
前提として、当然ですがCloudTrailログがCloudWatch LogsS3へ出力されている必要があります。S3出力のための設定をCloudTrailの「証跡」にて設定します。証跡の作成方法については、以下記事を参考にしてください。

証跡を作成すると、以下パスにログが出力されます。
<S3バケット>
└<プレフィックス>(※)
└AWSLogs/
└<アカウント番号>
└CloudTrail
└<リージョン名>
└/<year>/<month>/<day>
※証跡でプレフィックスを指定しない場合存在しません。
S3オブジェクトのダウンロードについては、以下の記事を参考にしてください。

CloudTrailログの整形
以下がCloudTrailの生データです。(塗りつぶしはアカウントID)

JSON形式で出力されるのですが、なんとびっくり、1行5362桁となっております。上記画像のログを取得したときは、ほとんど操作をしない状態でした。それでこの出力結果ですから、AWSをがっつり使っているときには何倍ものサイズ(桁数?)になっていると思われます。
さて、言うまでもなく、このままでは視認性が極端に低いので整形をします。先に整形結果をお見せすると以下のようになります。

CloudTrailログの整形方法
jqを導入し、「| jq」でCloudTrailログを引き渡して出力させるだけです。導入方法の詳細については以下の記事を参考にしてください。

さいごに
なんの前触れもなく「そうだ、CloudTrailログを確認しよう!」というのはまずあり得ないでしょう。CloudTrailログを確認するきっかけは「CloudWatch Event」もしくは「Amazon EventBridge」による通知かと思います。すなわち、事前に検知イベントを定義しておき、実際の運用において、
・CloudTrailへの書き込み
・CloudWatch Event もしくは Amazon EventBridgeが駆動
・SNS等でユーザへ通知
となって、初めて「ユーザによる調査(CloudTrailログの確認)」が行われるかと思います。そのため、監査部門でもない限り普段からCloudTrailログを調査することはないと思いますので、今回CloudTrailのログの確認方法について纏めました。現時点ではCloudTrailログの取得とその確認といった最低限の内容となっています。jqコマンドの利用方法 / CloudWatch Event / EventBridgeについて別記事に纏めたら、本記事も追記しようと思います。