説明
CloudTrailログを保存するだけでは、そのS3バケットへのリクエスト履歴まで収集されるわけではありません。サーバーアクセスログは、監査ログの保存先に対するリクエストの調査に役立ちます。
ログの配信はベストエフォートであり、すべてのリクエストが漏れなく即時に記録される保証はありません。監査が必要なオブジェクト操作については、CloudTrailデータイベントも検討してください。
想定される影響
- アクセス記録が不足すると、ログバケットへのリクエストを調査しにくくなります。
- 監査ログの読み取りや削除の試行を把握するまでに時間がかかるおそれがあります。
対処方法
aws_s3_bucket_loggingでサーバーアクセスログを設定し、実際に配信されることを確認してください。- 同じアカウントとリージョンにある別の保存先バケットに、ログ配信権限を付与してください。ACLが無効な場合はバケットポリシーを使ってください。
- 両方のバケットのアクセス権限、保持期間、削除保護を確認してください。
例
以下は、AWSプロバイダー3.xのインラインloggingとACLの構文を使った例です。現在の構成では個別のロギングリソースと保存先バケットポリシーを使ってください。環境に合ったバケット名とCloudTrailの配信ポリシーを用意し、force_destroy = trueが監査ログの保持要件を満たすかも確認してください。
変更前
hcl
resource "aws_cloudtrail" "example" {
name = "tf-trail-foobar"
s3_bucket_name = aws_s3_bucket.foo.id
s3_key_prefix = "prefix"
include_global_service_events = false
}
resource "aws_s3_bucket" "foo" {
bucket = "tf-test-trail"
force_destroy = true
}
変更後
hcl
resource "aws_cloudtrail" "example" {
name = "tf-trail-foobar"
s3_bucket_name = aws_s3_bucket.foo2.id
s3_key_prefix = "prefix"
include_global_service_events = false
}
resource "aws_s3_bucket" "log_bucket" {
bucket = "my-tf-log-bucket"
acl = "log-delivery-write"
}
resource "aws_s3_bucket" "foo2" {
bucket = "my-tf-test-bucket"
acl = "private"
logging {
target_bucket = aws_s3_bucket.log_bucket.id
target_prefix = "log/"
}
}
説明:
変更後は、CloudTrailの保存先バケットのサーバーアクセスログを別のバケットに送ります。ロギング自体がリクエストを遮断したり、ログの削除を防いだりするわけではありません。