Instiq
第6章 · 可観測性·v1.0.0·更新 2026/6/15·読了目安 約13分

変更要約: Professional Security Operations Engineer 第6章を新規作成(ドメイン6「可観測性」: 主要セキュリティ分析指標(メトリクス/KPI=MTTD・MTTR/トレンド)・ダッシュボード(Google SecOps SOAR/SIEM/Looker 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 時間無音なら、検出が機能していない(あるいは攻撃者がログを止めた)可能性があるため、アラートします。これにより「検出の盲点(ログが来ていないので何も検知できない)」を防ぎます。「ログが来なくなったソースを検知=サイレントソース検出」を押さえます。

続きは無料登録で読めます

冒頭を無料で公開中。無料登録でこの節の全文と、第4章以降を含む全参考書・全問題集が読めます。