Instiq
第2章 · セキュリティのロギングと監視·v2.0.0·更新 2026/6/5·読了目安 約11分

変更要約: SCS-C02 第2章を深掘り(比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応)

2.1ログの収集と保護

この節の要点

ログの設計——CloudTrail(API 監査)、VPC フローログS3/サービスログ組織証跡ログの改ざん防止——を理解します。網羅的かつ改ざん耐性のあるログ基盤を作ります。

セキュリティ監視の土台は網羅的なログです。何を・どこから記録し、いかに改ざんを防ぐかを設計します。

2.1.1ログソースと保護

AWS のセキュリティログを示した図。API 操作の監査=CloudTrail(組織証跡で全アカウント集約)、ネットワークトラフィック=VPC フローログ、サービス固有のログ(S3 アクセスログ/ELB/CloudFront/WAF など)を収集し、専用のログアーカイブアカウントの S3 バケットに集約、S3 オブジェクトロック(WORM)とバージョニング、KMS 暗号化、制限的なバケットポリシーで改ざん・削除を防止する構成を示した図。
ログソースと保護
  • CloudTrailAPI の監査ログ(誰が・いつ・何を)。組織証跡で全アカウントを一元集約。
  • VPC フローログ:ネットワークの通信メタデータを記録(許可/拒否含む)。
  • サービスログS3 アクセスログ/ELB/CloudFront/WAF など用途別のログを有効化。
  • ログの保護専用ログアカウント+S3 オブジェクトロック(WORM)+KMS 暗号化で改ざん・削除を防ぐ。
試験ポイント

「API 監査=CloudTrail(組織証跡)」「ネットワーク=VPC フローログ」「ログの改ざん防止=S3 オブジェクトロック(WORM)+専用ログアカウント」「ログの暗号化=KMS」 は SCS-C02 で頻出です。CloudTrail ログ自体を保護する設計(別アカウント+WORM)が問われます。

SCS-C02 のロギング設計は「網羅性・改ざん耐性・暗号化・集約」を問います。CloudTrail管理イベント(リソース操作)に加え、データイベント(S3 オブジェクトアクセス、Lambda 呼び出しなど高頻度操作)と Insights イベント(異常な API 量)を記録でき、組織証跡で全メンバーの証跡を専用のログアーカイブアカウントへ一元集約します。ログファイル整合性検証(ダイジェスト)で改ざんを検出でき、保管先 S3 は Object Lock(コンプライアンスモードの WORM)+バージョニング+MFA Delete+KMS(SSE-KMS)+制限的なバケットポリシーで守ります。ネットワークは VPC フローログ(ENI/サブネット/VPC 単位、許可/拒否、S3 or CloudWatch Logs へ)、DNS は Route 53 Resolver クエリログ、サービス別に S3 アクセスログ/サーバーアクセスログ、ELB、CloudFront、WAF ログを有効化します。重要なのは、ログを生成元と分離した専用アカウントに集め、最小権限でアクセスを絞り、暗号化と WORM で完全性を担保することで、攻撃者が痕跡を消せないようにすることです。GuardDuty が裏で取り込むログ(フロー/DNS/CloudTrail)は別途有効化不要ですが、調査やコンプライアンスのためには明示的にログを保全します。設計の要は、CloudTrail 組織証跡+VPC フローログ+サービスログを、専用ログアカウントの WORM/KMS で改ざん耐性を持って集約することです。

記録対象ログ要点
API 操作(誰が何を)CloudTrail(組織証跡)管理/データ/Insights イベント・整合性検証
ネットワーク通信VPC フローログENI/サブネット/VPC・許可/拒否
サービス固有S3/ELB/CloudFront/WAF ログ用途別に明示的に有効化
ログの保護専用アカウント+WORM+KMSObject Lock・バージョニング・最小権限
補足

シナリオ:監査要件で「全アカウントの API・ネットワークログを 7 年保管し、管理者でも改ざん/削除できないこと」を満たしたい。→ CloudTrail 組織証跡と各 VPC のフローログ専用ログアーカイブアカウントの S3 に集約し、Object Lock(コンプライアンスモード)+バージョニング+SSE-KMSで WORM 保護、ログファイル整合性検証を有効化。アクセスはバケットポリシー+最小権限で厳しく絞り、長期保管はライフサイクルで Glacierへ移行します。

補足

FAQ:CloudTrail の管理イベントとデータイベントの違いは? 管理イベントは「コントロールプレーン」の操作(リソースの作成/変更/削除、ログイン等)で既定で記録されます。データイベントは「データプレーン」の高頻度操作(S3 オブジェクトの GetObject/PutObject、Lambda の Invoke など)で、量が多くコストもかかるため明示的に有効化します。S3 上のオブジェクトアクセスを監査したいならデータイベントが必要です。

注意

ひっかけ:CloudTrail ログを生成元と同じアカウントの、誰でも消せる S3 に置くのは改ざん耐性がなく誤りです。攻撃者が痕跡を消せます。正解は専用ログアーカイブアカウント+Object Lock(WORM)+KMS。また、インシデント後にログを有効化しても過去のイベントは記録されないため、CloudTrail/フローログ/GuardDuty は事前に常時有効化しておく必要があります。

2.1.2この節のまとめ

  • ログ=CloudTrail(API)/VPC フローログ(NW)/サービスログ
  • 保護=専用ログアカウント+WORM+KMS

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 組織内の全アカウントの API 操作を、一元的に改ざん耐性のある形で記録したい。何を使いますか?

Q2. VPC 内の通信(許可/拒否を含むメタデータ)を記録して調査に使いたい。何を有効にしますか?

Q3. 監査用の CloudTrail ログ自体を、削除や改ざんから保護したい。どうしますか?

理解度を確認第2章「セキュリティのロギングと監視」の問題を解く