CloudTrail S3オブジェクトレベルログ、S3サーバーアクセスログ、どちらを使えば良いか？違いをまとめてみた

川原征大

2020.07.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

上記2つは両方とも S3オブジェクトに対しての操作を記録する機能です。「S3のログ記録機能」としては同じです。どちらを使えばいいか、迷うことあると思います。

両者の違い、使い分けを整理してみました。 (以降「CloudTrail データイベントのオブジェクトレベルのログ記録」を CloudTrail S3ログ、「S3サーバーアクセスのログ記録」を S3サーバーログと呼びます)

まとめ

まずはじめに、まとめを載せます。

より安価なのは S3サーバーログ です。監査の参考やアクセスログ分析のために、まず検討しましょう
CloudTrail S3ログ のほうが情報量が多いです。分析したい情報が S3サーバーログにない場合は使いましょう
監査ログとして S3オブジェクトの完全なアクセスログが必要な場合は CloudTrail S3ログ を推奨します
本番環境で機密性の高い情報を保存しているS3バケットに対しては CloudTrail S3ログ を推奨します
- (ログの話ではありませんが) Amazon Macie を使って機密データを検出、分類、保護することも検討しましょう
CloudTrail S3ログ は CloudWatch Logs + アラームも設定可能。想定外のS3オブジェクトアクセスがあった場合の通知ができます

設定方法

CloudTrailでは、証跡の [データイベント] から設定ができます。

対象のアクション(読み取り or 書き込み)、対象のバケット( 全てのバケット or 特定のバケット )を選択できます。
[現在および将来のすべてのS3バケット] を選ぶことで、今後作成されるバケットについても特に追加設定の必要無くログを収集してくれます。証跡の保存先は CloudWatch Logs, S3バケットのどちらです。長期保存や監査ログとしての使用の場合、S3へ保存することが一般的です。

一方、S3 サーバーログは各対象のバケットの [プロパティ] > [サーバーアクセスのログ記録] で設定を行います。 CloudTrail のように「全てのバケットのサーバーログを有効化」はできません。それぞれのバケット個別に対応する必要があります。ログの保存先は S3バケットです。

保存形式

CloudTrail S3ログは JSON 形式で保存されます。 CloudTrailで一般的に保存されるログと同じです。どのような構造になっているかは例: Amazon S3 ログファイルエントリ | AWSドキュメントにサンプルがあります。

一方、S3サーバーログはスペース区切りの改行区切りレコードとして保存されます。どのような構造になっているか、詳細は Amazon S3 サーバーアクセスログの形式 | AWSドキュメントを参照ください。

保存される情報

基本的に CloudTrail S3ログの方が保存される情報量が多いです。

CloudTrail はS3オブジェクトに対する AWS APIコールを記録します。

リクエストとともに送信されたパラメータ (requestParameters)の情報も確認できます。例えば PutObject した際にオブジェクトACLが付いているかどうか ( x-amz-acl パラメータ) は S3サーバーログでは取得できません。

S3サーバーログで取得できるログは下記の通り。

文字通り「サーバーのアクセスログ」です。 Total Time(サーバーから見たリクエスト転送時間 (ミリ秒) などは CloudTrailのログに無い項目です。

分析方法

S3に保存されたデータに対して、分析をする際に Amazon Athena はよく利用されます。

CloudTrail、S3サーバーログの両方で Athenaによる分析ができます。

マルチアカウント利用

CloudTrail の方が柔軟な設定が可能です。

(S3のログだけでなく、一般的な CloudTrail証跡の機能ですが) マルチアカウントのログを特定の1バケットに集約させたいケースは CloudTrailが向いています。また、Organizationsとの連携機能を使うことで簡単にログの集約できます。

S3サーバーログは他アカウントのバケットをログ格納先にはできません。マルチアカウントで S3サーバログを設定したい場合、基本的にはそれぞれのアカウントで個別にログ格納用のバケットを作成する必要があります。

完全性

CloudTrail はログファイルの整合性を検証することができます。ログファイルが改ざんされていないかどうか、判断できます。

一方 S3サーバログは 以下把握することが大事です 。

サーバーアクセスログレコードの配信は、 ベストエフォート で行われます。ログ記録用に適切にバケットを設定した場合、そのバケットへのほとんどのリクエストについてログレコードが配信されます。ほとんどのログレコードは、記録された時間から数時間以内に配信されますが、配信間隔は短くなる場合もあります。

サーバーログの完全性や適時性は保証されません。リクエストのログレコードが、リクエストが実際に処理されてからかなり後に配信されたり、配信すらされないこともあり得ます。サーバーログの目的は、バケットに対するトラフィックの特性を理解することです。ログレコードが失われることはまれですが、すべてのリクエストが完全に報告されるとは限りません。

– 引用: Amazon S3 サーバーアクセスのログ記録

料金

CloudTrail S3ログの方が高いです。

データイベントは指定した Lambda 関数と S3 バケットについてのみ記録され、イベント 10 万件あたり 0.10USD が課金されます。

– 引用: AWS CloudTrail の料金

CloudTrailは「上記イベントの課金」と「ログ保存の課金(S3ストレージ)」が利用料となります。

一方で S3サーバーログの追加料金はありません。「ログ保存の課金(S3ストレージ)」のみ利用料となります。

他: CloudTrail の CloudWatch アラーム連携

CloudTrailの証跡は CloudWatch Logs へ配信することもできます。 CloudWatch Logs のメトリクスフィルタ、アラームと連携することで「想定外のS3オブジェクトアクセスがあった場合に SNSでメールを送信」など可能です。

機密性の高い情報を保存している S3バケットのアクティビティを監視したい場合、ぜひ活用しましょう。

他: Configルールの活用

AWS Config は AWSリソースの構成を記録、管理するためのサービスです。 EC2インスタンスやセキュリティグループなど、AWSリソースが「いつ、どのような変更がされたか」の履歴を記録してくれます。

また、 AWS Config ルールを利用して AWSリソースの構成の評価ができます。 AWSリソースのあるべき構成を条件としています。条件に違反しているリソースが検出されると「非準拠」フラグが付けられます。

CloudTrail S3ログ、S3サーバーログに関する AWS管理の Configルールがあります。

それぞれ、Configルールでログ記録が有効になっているかどうか、継続的なチェックを行うことができます。セキュリティの運用にぜひ活用ください。

まとめ(再掲)

まとめを再掲します。

より安価なのは S3サーバーログ です。監査の参考にしたい場合や、アクセスログを分析したい場合は、まず検討しましょう
CloudTrail S3ログ のほうが情報量が多いです。分析したい情報が S3サーバーログにない場合は使いましょう
監査ログとして S3オブジェクトの完全なアクセスログが必要な場合は CloudTrail S3ログ を推奨します
本番環境で機密性の高い情報を保存しているS3バケットに対しては CloudTrail S3ログ を推奨します
- (ログの話ではありませんが) Amazon Macie を使って機密データを検出、分類、保護することも検討しましょう
CloudTrail S3ログ は CloudWatch Logs + アラームも設定可能。想定外のS3オブジェクトアクセスがあった場合の通知ができます