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

2020.07.01

上記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へ保存することが一般的です。

img

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

img

保存形式

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

img

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

img

保存される情報

基本的に 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オブジェクトアクセスがあった場合の通知ができます

また、AWSの公式ドキュメントにも両者の相違表がまとめられています。ぜひ参照ください。

少しでもどなたかのお役に立てば幸いです。

参考

▼ ログ詳細

▼ 分析 (Athena)

▼ Configルール

▼ ほか