この記事は公開されてから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オブジェクトアクセスがあった場合の通知ができます
また、AWSの公式ドキュメントにも両者の相違表がまとめられています。ぜひ参照ください。
少しでもどなたかのお役に立てば幸いです。
参考
▼ ログ詳細
▼ 分析 (Athena)
▼ Configルール
▼ ほか
3
