SCS-2.4ロギングソリューションのトラブルシューティングを行う。

ヒントボタン

InsufficientS3BucketPolicy が表示されているときは CloudTrail が org-trail-logs へ書き込めない状態ですから、サービスプリンシパル cloudtrail.amazonaws.com に対して s3:PutObject を許可し、さらに Condition で s3:x-amz-acl=bucket-owner-full-control を要求する 1 行をバケットポリシーへ加えるだけで、マルチリージョンや SSE-KMS の設定を変更せずとも 50 アカウント環境全体のログ配信を即時復旧でき、同時にバケット所有者による改ざん防止と外部監査要件も満たせると整理してみてください。

パブリックアクセスブロックを無効化して Principal “*” に s3:PutObject を許可すれば CloudTrail も書き込めますが、同時に世界中からの投げ込みやスパムオブジェクトを招き S3 Block Public Access や IAM 最小権限の原則を逸脱するため金融機関のガバナンス的にはリスクが高く、また KMS のキーポリシーだけを緩和してもバケット側で拒否が残れば InsufficientS3BucketPolicy は解消されないという原因切り分けも併せて思い出してみてください。

今回のケースでは Organizations の組織 CloudTrail、SSE-KMS による暗号化、マルチリージョン設定、ログファイル整合性検証といった複数要件が絡み合っていますが、①バケット所有者が常に完全制御を保持できること、②書き込みに必要な権限だけを明示して公開や読み取りを開放しないこと、③設定変更が最小で即効性があること、④50 アカウント規模の監査工数を抑えられること、これらを総合的に満たす案はどれかを俯瞰して選択してください。

ヒントボタン

CloudTrail ログを SSE-KMS で保護するときは AWS KMS のキー ポリシーが最優先で適用され、そこに記載のないプリンシパルは IAM ポリシーで kms:Decrypt を許可していても CMK を呼び出せず AccessDenied となるため、クロスアカウントの AuditRole が鍵リソースに列挙されているかどうかをまず確認してみましょう。
暗号方式を SSE-S3 に変更すれば KMS への Decrypt 権限は不要になりますが、全リージョンの CloudTrail 設定変更や組織の暗号ポリシー見直しといった大規模作業が発生し、また S3 バケットポリシーに kms:Decrypt を書いても S3 は KMS API を評価しないことから、どちらも運用コストや技術的制約の面で適切かを落ち着いて比較してみてください。
追加の運用負荷を最小化するという観点では、一度だけ trail 用 CMK のキー ポリシーに AuditRole をプリンシパルとして追加し kms:Decrypt と kms:DescribeKey を許可しておけば以後の監査処理は自動化でき、毎回 kms:CreateGrant を発行する手順や暗号方式を変えるリスクを負わずに済むため、可用性・安全性・保守性を横断的に評価し最もシンプルな施策を選択するのが望ましいでしょう。

ヒントボタン

CloudTrail が組織証跡でログを書き込む際は、まず S3 へ s3:GetBucketAcl を呼び出してバケットの所有者を確認し、その後 s3:PutObject で AWSLogs/* 配下にファイルを配置する 2 段階の流れになります。このどちらかが欠けると AccessDenied が発生しますので、bucket org-trail-logs には cloudtrail.amazonaws.com サービスプリンシパルに対し両アクションを許可する記述を設ける必要があります。パブリックアクセスブロックが有効でも影響を受けないよう、バケットポリシーで明示的に許可することが確実です。

監査アカウント側で一元的にオブジェクト管理を行うには、CloudTrail が PutObject 時に送る x-amz-acl ヘッダーを bucket-owner-full-control に固定するのが推奨となります。S3 バケットポリシーに Condition で StringEquals s3:x-amz-acl=bucket-owner-full-control を追加すると、ヘッダーが一致しないリクエストは拒否されます。これによりメンバーアカウントが意図しない ACL を付与してもログは保存されず、要件 2 の「ACL 強制」を実現できます。

他サービスや IAM ユーザーからの書き込みを避けるには Principal を cloudtrail.amazonaws.com に限定し、Resource を arn:aws:s3:::org-trail-logs/AWSLogs/* に絞ることが重要です。このうえで PutObject＋Condition を持つステートメントと、GetBucketAcl 専用のステートメントに分けた 2 段構成にすると、最小権限・ACL 強制・第三者排除の三要件を同時に満たすバランスの取れた設計になるという総合判断が導けます。

ヒントボタン

CloudTrail が別アカウントの S3 バケットにイベントを書き込む場合、バケットポリシーに Principal cloudtrail.amazonaws.com を指定し、対象アカウント専用プレフィックス AWSLogs/444455556666/* への s3:PutObject と s3:GetBucketAcl を許可し、さらに Condition で s3:x-amz-acl=bucket-owner-full-control を要求する構文がマニュアルに明記されています。これが欠けているとサービスロールはオブジェクト ACL を適用できず、Organizations の組織トレイル画面には InsufficientS3BucketPolicy というステータスが表示されるため、まずはこのステートメントを追加入力することを検討してください。

S3 Block Public Access は有効のままでも CloudTrail 配信に影響しません。ログ転送の成否を左右するのはバケットポリシーであり、ACL を Everyone へ開放したりブロック設定を解除する必要はないどころか、医療データを扱う SaaS としてはセキュリティ上避けるべきです。ACL に権限を寄せると Block Public Access が自動で拒否するため結局書き込みは失敗しますので、SSE-KMS や既存ロール設定が整っている前提ではポリシーの追記だけで安全に要件を満たせます。

Organizations で集中管理するアーキテクチャを保ちつつ SSE-KMS、サービスロール、リージョン別プレフィックスという条件が既に合致しているなら、残るギャップは新規アカウント ID 用の s3:PutObject 権限を org-cloudtrail-logs のバケットポリシーに付与する一点です。トレイル停止や CloudTrail Lake への切り替えに比べてリスクと工数が最小で、複数要件を俯瞰した総合判断として最もシンプルかつ安全な解決策となります。

ヒントボタン

CloudWatch エージェントが Amazon Linux 2 の EC2 からログを送信するときは、Log group が無ければ logs:CreateLogGroup、インスタンスごとの Log stream を作る logs:CreateLogStream、最後にレコードを書き込む logs:PutLogEvents を順に呼び出します。NetworkACL も SSM 設定も問題ないのに AccessDenied が出る場合、これら 3 つの API いずれかの許可が不足している可能性が高いです。
現在の ProdAppLoggingRole は AmazonEC2RoleforSSM しか持たず CloudWatch Logs への書き込み権限が皆無です。Describe や PutMetricData ではログのアップロードは始まりませんので、必要な 3 アクションをインラインポリシーで追加し、Resource を /prod/app の Log group に限定すれば、最小権限と監査要件を同時に満たせます。
検索を 5 分以内に可能にするには S3 へ一旦保存したり Kinesis Data Firehose を経由する構成は遅延と運用コストを生むだけでメリットが薄く、CloudWatch Logs へ直接プッシュするシンプルな経路が最適です。ログ取込に必須な 3 API を対象リソースだけに許可する方針が、可視性・リアルタイム性・最小特権をバランス良く満たす総合的な解決策となります。

ヒントボタン

CloudWatch Logs エージェントは EC2 で動く awslogs プロセスが /var/log/app.log を tail して差分を送信しますが、logrotate で create だけを書くと Amazon Linux 2 の umask により 0600 の新規ファイルが作成され、root 以外から読めなくなります。awslogs が非 root で動く環境では追記を検知できず可視化が停止するため、create に 0644 など読み取り可能なパーミッションを明示することで即時復旧が期待できます。

ログ未達の切り分けではまず OS 層のファイルアクセスを確認するのが基本です。Kinesis Data Firehose や S3 を経由する多段構成はレイテンシを増やし、CloudWatch Logs の PutRetentionPolicy 追加は保持期間に関わるだけで読み取り不可状態を解消しません。さらに awslogs.conf の file_fingerprint_lines を変えてもファイルが読めなければ無効であり、権限を正すほうが運用負荷も最小です。

監査要件は「30 秒以内の可視化」と「ディスク容量削減」を両立させることですから、Amazon Linux 2 の logrotate 設定だけを調整して CloudWatch Logs への継続送信を確保し、EC2 インスタンスの IAM ロールや外部サービス構成を変えずに済む解決策が総合的に最も適切だと判断できます。

ヒントボタン

CloudWatch Logs への API コールは IAM ポリシー、Interface VPC エンドポイントポリシー、リソースポリシーの三段階で評価され、いずれかに明示的 Deny があると PutLogEvents は必ず拒否されます。IAM ロールの設定を触っていないまま AccessDeniedException が出た場合は、com.amazonaws.ap-northeast-1.logs という PrivateLink のポリシーが原因かを最優先で調べるのが効果的です。ネットワーク ACL や Security Group は認可判断に関与しない点も押さえておきましょう。

CloudWatch Agent は EC2 再起動時などにログストリームを自動生成し、それぞれの ARN に対して CreateLogStream と PutLogEvents を発行します。ストリーム ARN には log-stream: が含まれるため、VPC エンドポイントポリシーを prod-* だけ許可して他を拒否すると、新規ストリーム名が一致せず配送が止まります。サービス側で勝手に変わるリソースをポリシーで細かく絞ると運用コストが急増する、という CloudWatch Logs 特有の振る舞いを覚えておくとトラブルシュートが早まります。

プライベート通信路を保ちながら最小権限を実現するには、Interface Endpoint では logs:CreateLogStream と logs:PutLogEvents など必要最少アクションを Resource “*” でシンプルに許可し、どのロググループに書くかは IAM ロールで限定する分離設計が推奨されています。VPC エンドポイントを過度に厳しくすると本番切替時に停止を招く恐れがあり、ネットワーク経路を変えて Kinesis Data Firehose や S3 へ迂回するのは根本対策ではありません。ポリシー層それぞれの役割を整理して「どこを緩め、どこを締めるか」を見極める総合判断が合格への近道です。

ヒントボタン

CloudTrail のログは KMS で暗号化されつつ S3 に問題なく保存されているのに CloudWatch で SNS の PublishFailed が 100% を示すときは、故障箇所を「S3 から SNS への Publish API 呼び出し」に限定できます。SQS の DeliveryFailure や KMS の GenerateDataKey は無関係であり、オブジェクト作成イベントが発火している事実からもイベント通知自体は成功しているため、残る可能性は SNS が呼び出しを拒否しているケースです。

S3 から SNS へメッセージを送る際は SNS トピックポリシーに Principal を s3.amazonaws.com とし、Condition で aws:SourceArn に arn:aws:s3:::ms-audit を指定する sns:Publish 許可を追加するのが基本形です。この設定がないと SNS は AccessDenied を返し PublishFailed が増えるため SQS に何も届きません。S3 バケットポリシーや KMS キーポリシーをいじってもこの権限不足は解消されません。

最終的には SNS メトリクス、S3 イベントの発火状況、KMS 暗号化の挙動を横串で確認し、最も影響度が高く症状と整合する「S3→SNS のクロスサービス許可欠如」を是正することが最短経路と判断できます。