Turn on CloudTrail log file validation for the management-events trail
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 75/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- aws, terraform
調査の方向性
作業は terraform/cloudtrail.tf にあります。aws_cloudtrail.management_events リソースを見つけ、enable_log_file_validation を true に変更してください。その上の2行のコメントとファイルヘッダーのコメントリストを更新します。terraform plan を実行して、そのリソースのみがインプレースで変更されることを確認します。マージ後、提供された aws cloudtrail describe-trails および aws s3 ls コマンドで検証します。
索引モデルが issue の本文から書いたものです。
説明
Overview
We need to turn on CloudTrail log file validation for the management-events trail, so that both of the account's trails produce tamper-evident digest files. Today one trail has it on and the other has it off, which means the trail carrying the account's management events — the higher-value audit record of the two — is the one that cannot be proven unaltered.
Action Items
- In
terraform/cloudtrail.tf, changeenable_log_file_validationfromfalsetotrueon theaws_cloudtrail.management_eventsresource. It is on line 251 as of 2026-09-23 — line numbers drift, so find it by the resource nameresource "aws_cloudtrail" "management_events"rather than by number. - Update the two-line comment immediately above that resource, which currently reads that the inconsistency is "reproduced rather than resolved -- turning it on is a live change and its own ticket." That ticket is this one, so the comment should now say the two trails agree and that validation is on for both. Leave the rest of the file's commentary alone.
- Update the file-header comment near the top of
terraform/cloudtrail.tfthat lists four things deliberately not added by #191. Log file validation is one of the four; remove it from that list and leave the other three (KMS encryption, a CloudWatch Logs destination, a bucket lifecycle configuration) exactly as they are — each is still outstanding. - Confirm the plan shows exactly one resource changing, in place:
aws_cloudtrail.management_events[0]withenable_log_file_validation: false -> true. There must be no replacement and nothing else in the diff. A replacement would destroy and recreate a trail carryingprevent_destroy, so it would fail at plan time — but check rather than rely on that. - Note this resource is gated on
var.iam_only, so it is skipped entirely in a contributor's own AWS account and only applies in CI, whereiam_only = false. A local plan with the default variable will show no change at all; that is expected and is not evidence the edit is wrong. - After the PR merges and the apply runs, confirm both trails report validation on:
aws cloudtrail describe-trails --query 'trailList[].{Name:Name,Validation:LogFileValidationEnabled}' --output table. Both rows must readTrue. - After the PR merges, confirm digest files actually start being written, which is the real proof the setting took effect:
aws s3 ls s3://aws-cloudtrail-logs-035866691871-6539ef03/AWSLogs/035866691871/CloudTrail-Digest/ --recursive | tail. Expect nothing for up to an hour — CloudTrail writes the first digest on its own schedule, not at apply time — so this step is deliberately separate from the one above and may need coming back to later in the day.
Resources/Instructions
terraform/cloudtrail.tf— the only file this ticket touches. Themanagement_eventstrail is the second of the two declared in it; the first,tf_backend_logs, already hasenable_log_file_validation = trueand is the model.- devops-security#191 — imported both trails and both buckets as-is, and deliberately left this inconsistency in place. Its
cloudtrail.tfcomments name this as follow-on work. - Validating CloudTrail log file integrity — what the digest files are and how to verify one with
aws cloudtrail validate-logs. - Digest files are delivered to the same bucket as the logs, under
AWSLogs/<account>/CloudTrail-Digest/, and are billed as ordinary S3 objects. They are small and low-volume relative to the log files themselves, so this adds no meaningful storage cost.
Line numbers above were accurate on 2026-09-23 and may drift; locate the targets by resource name and by the quoted comment text instead.
- 主要言語
- HCL
- スター
- 1
- フォーク
- 14
- 平均マージ
- 1時間 3分
- マージ済み PR(30日)
- 23
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
hackforla/devops-security のほかの issue
-
complexity: small feature: security role: DevOps Engineer size: 2pt
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
hackforla/devops-security#203 ·
-
complexity: medium feature: maintenance role: DevOps Engineer size: 2pt
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
hackforla/devops-security#170 ·
-
complexity: prework Feature: Onboarding/Contributing.md role: missing size: 1pt
難易度 3/5 3〜5日 初心者へのやさしさ 40/100
hackforla/devops-security#200 ·
-
complexity: small feature: AWS user request role: DevOps Engineer size: 1pt
hackforla/devops-security#198 · 担当者 1 名 ·
-
complexity: prework Feature: Onboarding/Contributing.md role: DevOps Engineer role: missing size: 1pt
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
hackforla/devops-security#195 · 担当者 1 名 ·
hackforla/devops-security の issue をすべて見る
似ている issue
-
core dependencies
難易度 1/5 1時間未満 初心者へのやさしさ 80/100
-
bug github_actions
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
registrystack/registry-stack#1393 ·
-
module: core
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
bigbluebutton/bigbluebutton#25849 ·
-
bug engine
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
rocky-data/rocky#2181 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100