SCS-2.2セキュリティモニタリングとアラートのトラブルシューティングを行う。

ヒントボタン

60 秒以内の取り込みと 2 TB/日の処理を 5 つのアカウントで行うには、CloudWatch Logs の cross-account Destination を中央アカウントに置き、各送信元はサブスクリプションフィルタでそこを指すだけにします。Destination 背後の Kinesis Data Firehose は自動スケールで高スループットをさばき、そのまま S3 へストリーミングできるので追加のエージェントや Lambda を挟まずにリアルタイム性を維持できます。

S3 側では SSE-KMS を指定し、Firehose 配信ロールに kms:Encrypt と s3:PutObject だけを許可し、バケットポリシーで GetObject を拒否すれば送信元アカウントからの読み取りを防げます。Firehose は日時プレフィックス付きでオブジェクトを生成するため Glue Data Catalog でパーティションを定義しやすく、Athena や Lake Formation と組み合わせて 365 日分のログを効率的に検索でき、CloudWatch Logs Insights でも 10 分以内のクエリ要求を満たせます。

リアルタイム転送、クロスアカウント集約、SSE-KMS 暗号化、365 日保持、読み取り禁止、CloudWatch Logs Insights と Lake Formation 両立という多面要件を俯瞰すると、CloudWatch Logs → cross-account Destination → Kinesis Data Firehose → S3 の完全マネージド経路が追加開発なしで全条件を同時に充足できるかを総合判断の視点で検討するのが最も合理的です。

ヒントボタン

EKS では API Server や AUDIT などのコントロールプレーンログをボタン一つで有効化でき、数十秒間隔で Amazon CloudWatch Logs にストリーミングされます。CloudWatch Logs グループはカスタマーマネージド KMS キーで暗号化でき、保持期間やエクスポート設定もマネージドで行え、v1.27 でも追加の DaemonSet やサイドカー無しに運用負荷を抑えられる点を思い出してください。

Kubernetes のコントロールプレーンは EKS サービス側で管理されるためワーカーノードの /var/log には存在せず、CloudTrail が記録するのは AWS API 呼び出しに限られ内部 RBAC の許可・拒否は含まれません。Kinesis Data Firehose や SSE-S3 を経由するルートはキー管理やパイプライン保守が増え、既存の CloudWatch 統合とも合わなくなるリスクがあることを意識しましょう。

今回の要件は「1 分以内の収集速度」「顧客管理型 KMS による暗号化」「180 日保持後に S3 Standard-IA へ自動移行」「既存の CloudWatch Logs 基盤を継続利用」という複数条件を同時に満たす必要があります。これらを総合的に照らし合わせ、追加コンポーネントを増やさずマネージド連携だけで完結できる構成が最も合理的かを見極めてください。

ヒントボタン

DNS クエリ本文まで取得したい場合は Route 53 Resolver クエリログが鍵です。CloudTrail が扱うのは API 操作、VPC フローログに含まれるのは 5 タプル情報までで FQDN は残らず、CloudWatch Logs Insights でドメイン名検索を行うにはクエリログが最適で、Inbound と Outbound の両方向を 30〜60 秒程度の遅延で転送できます。
リアルタイム性を要求するなら配送先の違いにも注目です。Route 53 Resolver クエリログを S3 に送ると到達まで 5〜15 分かかり、Glue や Athena のバッチ実行も必要です。それに対し CloudWatch Logs は PutLogEvents 後ほぼ即座に検索できるため、1 分以内で横断的に可視化したいユースケースに適合します。
複数アカウントを束ねて運用負荷を抑えるには、集中管理アカウント側の CloudWatch Logs グループに KMS の CMK と保持 365 日を設定し、Resource Policy で各開発アカウントの Route 53 Resolver からの PutLogEvents を許可する方法がシンプルです。収集速度・暗号化・保持・分析すべてを一手に満たす構成かどうかを総合的に判断しましょう。

ヒントボタン

収集から5分以内にAthenaで検索するには、VPC Flow Logsが吐き出す5分集計ファイルをそのままS3に書き込む方法が最もシンプルで速く、到着後にGlue Crawlerが自動でパーティションとCatalogを更新すれば即時クエリが可能です；CloudWatch Logsのエクスポートは日次になることが多く遅延が大きく、Kinesis Data Firehose経由は最短1分とはいえストリーム転送課金が別途発生するため、レイテンシとコストの両面でS3直行が有利です。

S3側ではSSE-KMSで暗号化しつつLifecycleルールを用い、90日後にGlacier Instant Retrievalへ自動移行してストレージ単価を下げ、365日後に削除することで保存期間を厳守できます；同時にクロスリージョンレプリケーションを設定すれば新規オブジェクトがほぼリアルタイムで大阪リージョンにも複製されるため、別途DataSyncや週次バッチを使わなくてもRPO24時間以内のDR目標を自然に満たせます。

2 TB/日のログ基盤を低コストで運用するには、CloudWatch Logs取り込み費用を回避し、S3＋Glue＋Athenaでサーバーレス分析を構築しながらParquet圧縮とLifecycle、CRRを組み合わせる案が、検索遅延・暗号化・長期保存・災害対策・月額コストという複数の要件を総合的に見渡したとき最もバランスの取れた選択となります。

ヒントボタン

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 へ迂回するのは根本対策ではありません。ポリシー層それぞれの役割を整理して「どこを緩め、どこを締めるか」を見極める総合判断が合格への近道です。