変更要約: Professional Security Operations Engineer 第6章を新規作成（ドメイン6「可観測性」: 主要セキュリティ分析指標(メトリクス/KPI=MTTD・MTTR/トレンド)・ダッシュボード(Google SecOps SOAR/SIEM/Data Studio)・レポート生成/カスタマイズ、ヘルス監視メトリクス・集約ダッシュボード・しきい値アラート・Cloud Monitoring 通知・Cloud Logging でのヘルス問題特定・サイレントソース検出）。
6.2ヘルス監視とアラート
ヘルス監視/アラートのための重要メトリクスの特定、メトリクスを集約するダッシュボードの作成、特定メトリクスのしきい値アラートの作成、Google Cloud ツール（Cloud Monitoring）による通知の構成、Google Cloud ツール（Cloud Logging）によるヘルス問題の特定、サイレントソース検出の構成を理解します。
セキュリティ基盤自身が健全でなければ、検出は機能しません。ログが止まっていないか、取り込みが滞っていないかを監視します。
6.2.1ヘルス監視としきい値アラート
セキュリティ基盤の ヘルス監視 では、重要な メトリクス（取り込みレート・パイプラインの遅延・エラー率・ストレージ使用量）を特定し、メトリクスを集約するダッシュボード にまとめます。異常を早期に捉えるため、特定メトリクスに しきい値アラート を作成し、超過したら Cloud Monitoring で 通知 します（メール/PagerDuty/Pub/Sub）。基盤側の ヘルス問題 は Cloud Logging のログから特定します。「基盤の健全性を測る＝ヘルス監視メトリクス＋しきい値アラート」「通知＝Cloud Monitoring」を結びます。
6.2.2サイレントソース検出
最も危険なのは「気づかないうちにログが止まっていること」です。あるログソースが 想定どおりにデータを送っていない（=サイレント＝沈黙している）状態を検出する サイレントソース検出 を構成します。例えば、毎分ログを送るはずのファイアウォールが 1 時間無音なら、検出が機能していない（あるいは攻撃者がログを止めた）可能性があるため、アラートします。これにより「検出の盲点（ログが来ていないので何も検知できない）」を防ぎます。「ログが来なくなったソースを検知＝サイレントソース検出」を押さえます。
「要件 → 手段」が頻出。例：「取り込み遅延/エラー率が閾値を超えたら通知」＝しきい値アラート＋Cloud Monitoring、「基盤のヘルス問題をログから特定」＝Cloud Logging、「想定どおりにログを送らなくなったソースを検知」＝サイレントソース検出、「運用メトリクスを一画面に集約」＝集約ダッシュボード。
混同に注意：
①セキュリティ検出（脅威）とヘルス監視（基盤の健全性）は別＝基盤が止まると脅威検出もできない。
②ログが「来ない」のは正常ではない＝サイレントソース検出で盲点を塞ぐ。
③しきい値アラートは「鳴らしすぎ」も「鳴らなさすぎ」も問題＝適切なしきい値にチューニング。
6.2.3この節のまとめ
- 基盤のヘルス監視＝重要メトリクス(取り込みレート/遅延/エラー率)を集約ししきい値アラート
- 通知＝Cloud Monitoring、ヘルス問題の特定＝Cloud Logging
- ログが来なくなったソースを検知＝サイレントソース検出で検出の盲点を防ぐ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 毎分ログを送るはずのファイアウォールが 1 時間無音になった。これを検知して、検出の盲点を防ぎたい。最適なのはどれですか？
Q2. 取り込み遅延やエラー率が閾値を超えたら、メールや PagerDuty で通知したい。最適なのはどれですか？
Q3. セキュリティ基盤側のヘルス問題（パイプラインのエラー等）をログから特定したい。最適なのはどれですか？
Q4. セキュリティ検出（脅威）とヘルス監視（基盤の健全性）の関係として正しいものはどれですか？
Q5. ヘルス監視のダッシュボードを設計するとき、まず行うべきことはどれですか？