変更要約: SCS-C02 第2章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
2.2監視とアラート
リアルタイム監視——CloudWatch（メトリック/ログ/アラーム）、メトリックフィルター、EventBridge、Config（構成監視）、通知——を理解します。異常を即座に検知し通知します。
ログを集めたら監視と通知につなげます。CloudWatch や Config で異常を検知し、即座にアラートします。
2.2.1監視とアラートの仕組み
- CloudWatch：メトリック/ログ/アラーム。閾値超過で通知や自動アクションを起動。
- メトリックフィルター：ログのセキュリティ事象（例: ルートログイン、認可失敗）をメトリック化しアラーム。
- AWS Config：リソース構成の変更とコンプライアンス逸脱（例: S3 公開）を継続監視。
- EventBridge/SNS：検知を受けて通知や自動対応を起動する。
「ログのセキュリティ事象をアラーム化＝メトリックフィルター→CloudWatch アラーム」「構成変更/コンプライアンス監視＝AWS Config」「ルートユーザーのログイン検知」 は SCS-C02 で頻出です。ルートログインや MFA 無効化などはメトリックフィルター/EventBridge で即時に検知・通知します。
SCS-C02 の監視設計は「セキュリティ事象を漏れなく即時に検知し、対応へつなぐ」ことを問います。CloudWatch メトリックフィルターは CloudTrail を流し込んだ CloudWatch Logs から、ルートユーザーのログイン・MFA なしの操作・認可失敗（AccessDenied）の多発・IAM ポリシー変更・セキュリティグループや NACL の変更・CMK の無効化/削除スケジュールといった事象をパターン抽出してメトリック化し、アラームで通知します（CIS AWS Foundations の推奨アラームが代表例）。AWS Config はリソースの構成変更とコンプライアンスを継続評価し、マネージドルール（s3-bucket-public-read-prohibited、restricted-ssh、encrypted-volumes 等）で逸脱を検出、修復アクション（SSM Automation）で自動是正します。状態変化に即応する経路として EventBridge が結節点で、GuardDuty/Config/CloudTrail のイベントを受けて SNS 通知と Lambda/SSM 自動対応を同時に起動します。注意点として、メトリックフィルターは設定後のログにのみ適用され遡及しないこと、構成系の検知は Config、振る舞い系の脅威は GuardDuty、と役割を分けることです。組織横断では Config アグリゲータや Security Hub に集約します。設計の要は、重要なセキュリティ事象（特権操作・構成逸脱）をメトリックフィルター/Config で検知し、EventBridge で即時に通知・自動対応へ確実につなぐことです。
| 検知したいもの | 手段 | 要点 |
|---|---|---|
| 特権/不審な API 操作 | メトリックフィルター→アラーム | ルートログイン・IAM変更・認可失敗（遡及なし） |
| 構成変更/コンプライアンス逸脱 | AWS Config（ルール） | S3 公開・SG 開放等を継続評価・自動修復 |
| 振る舞いベースの脅威 | GuardDuty | C2/異常 API を ML 検知 |
| 通知/自動対応 | EventBridge → SNS/Lambda/SSM | 検知を即時に対応へ |
シナリオ：「ルートユーザーでのログイン」「IAM ポリシーの変更」「CMK の削除スケジュール」を即時に検知して SOC に通知したい。→ CloudTrail を CloudWatch Logs に送り、各事象の メトリックフィルターを作成して CloudWatch アラーム＋SNS 通知。構成系（S3 公開、SG の 0.0.0.0/0 開放）は AWS Config ルールで継続検出し、違反は EventBridge→SSM Automation で自動是正。重要操作の検知は CIS AWS Foundations の推奨アラーム群を参考に網羅します。
FAQ：メトリックフィルターと AWS Config はどう使い分ける？ メトリックフィルターは「ログに現れた事象（API 操作の発生）」を検知します（例: ルートログインという“出来事”）。AWS Config は「リソースの構成状態が望ましいか」を評価します（例: S3 が公開“状態”か）。出来事の検知はメトリックフィルター/EventBridge、状態の評価は Config、と覚えます。
ひっかけ：メトリックフィルターは設定後に到着するログにのみ適用され、過去のログには遡及しません（過去分は Athena/Logs Insights でクエリ）。また「S3 が公開構成になっていないか」を継続評価するのはメトリックフィルターではなく AWS Config。出来事（イベント）と状態（構成）の検知手段を取り違えないこと。
2.2.2この節のまとめ
- 監視＝CloudWatch（メトリックフィルター）＋AWS Config（構成）
- 通知/対応＝EventBridge→SNS/Lambda
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CloudTrail ログにルートユーザーのログインが記録されたら即座にアラートしたい。何を使いますか？
Q2. S3 バケットが誤って公開設定に変更されたことを継続的に検出したい。何を使いますか？
Q3. 検知したセキュリティ事象を、通知に加えて自動対応（Lambda）にもつなげたい。何を使いますか？