Security Command Center

解決する課題

クラウド環境が広がるほど、「どこに穴があり、いま何が攻撃されているか」を一望できなくなります。Security Command Center（SCC）は、資産の棚卸し・設定ミスの検出・脅威の検知を1か所に集約してこの問題に答えます。

• プロジェクトが増えすぎて、公開バケットや過剰な権限がどこにあるか把握できない → 組織横断で資産と設定ミスを継続スキャン
• 攻撃を受けても気づけない → ログや挙動から脅威をリアルタイム検知
• ツールが分散して対応が後手に回る → Finding（検出結果）を統一フォーマットで一元管理し、優先度を付けて対処
• 監査やコンプライアンスで「基準を満たしているか」を説明したい → ベンチマークに対する準拠状況を可視化

AWS でいえば、設定評価・横断集約の Security Hub と、脅威検知の GuardDuty を1つにまとめたサービスと考えると理解しやすいです。

主要概念と用語

• 態勢管理（CSPM, Cloud Security Posture Management）: 設定ミスや過剰権限など「攻撃される前の弱点」を継続的に評価する領域。SCC の中核
• 脅威検知: 不審なログイン、暗号通貨マイニング、データ持ち出しの兆候など「いま起きている攻撃」を検出する領域
• Finding（検出結果）: 検出器が見つけた1件の問題。重大度（Critical / High / Medium / Low）、対象リソース、推奨対処を持つ統一フォーマット
• 検出器（Detector / サービス）: Finding を生む機能群。設定ミスを探す Security Health Analytics、脆弱性を探す Web Security Scanner、脅威を探す Event Threat Detection や Container Threat Detection など
• Source（ソース）: Finding の発生元。Google 提供の検出器のほか、サードパーティ製品や自作の検出も Source として取り込める
• Asset（資産）: 監視対象のクラウドリソース（VM、バケット、サービスアカウントなど）とそのメタデータ
• Security Posture サービス: 望ましいセキュリティ態勢を定義（ポリシーのテンプレート化）し、ドリフトを検出する仕組み
• Mute（ミュート）: 既知で許容する Finding を抑制し、ノイズを減らす設定

仕様・制限・クォータ

• 組織レベルで有効化するのが基本。組織配下のプロジェクトを横断して資産・Finding を集約する（プロジェクト単位の利用に限定したエディションもある）
• エディションによって機能が大きく異なる。無償の Standard では基本的な態勢管理が中心で、Premium / Enterprise になるほど脅威検知・脆弱性管理・準拠状況レポートなどが拡張される。試験では「高度な脅威検知や CSPM の多くは上位エディション」という関係を押さえる
• 検出器ごとにスキャンの頻度や対応リソースの範囲が決まっており、すべての設定ミスを即時に拾うわけではない
• Finding は SCC 内に保持されるほか、Pub/Sub への通知や BigQuery へのエクスポートで外部連携できる
• 具体的な保持期間・課金単位・対応リージョンなどの数値は変動するため、最新は公式ドキュメントで確認する

内部の仕組み

SCC は「集める・評価する・知らせる」を組織スコープで回し続けます。

1. 資産インベントリの収集: 組織配下のリソース構成と変更を継続的に取り込み、資産の一覧を最新化する
2. 検出器による評価: 設定スキャン（公開設定・暗号化・過剰権限など）、脆弱性スキャン、脅威検知（ログ・挙動分析）がそれぞれ走り、問題を見つけると Finding を生成する
3. Finding の集約と正規化: 出所の異なる検出結果を統一フォーマットに揃え、重大度・対象・推奨対処を付けてダッシュボードに集約する
4. 通知と連携: Finding を Pub/Sub に流して SOAR やチケット起票へ、BigQuery に出して分析・長期保管へ、といった形で運用パイプラインへつなぐ

設計パターン / ベストプラクティス

• 組織レベルで有効化する: プロジェクト単位ではなく組織全体を対象にし、横断で死角をなくす
• 重大度で優先度を付ける: Critical / High を起点にトリアージし、公開リソースや過剰権限など影響の大きいものから潰す
• Finding を運用に流し込む: Pub/Sub 経由でチケット起票・通知・自動修復（Cloud Functions などのワークフロー）につなぎ、放置を防ぐ
• ノイズを管理する: 許容できる既知 Finding は Mute ルールで抑制し、本当に対応すべきものに集中する
• Security Posture で「あるべき姿」を定義: 望ましい態勢をテンプレート化し、設定ドリフトを検出して逸脱を早期に是正する
• 準拠状況を継続監視: 業界ベンチマークへの適合度をダッシュボードで追い、監査前に慌てない

運用・監視

• ダッシュボードでトリアージ: 重大度・カテゴリ・対象プロジェクトで Finding を絞り込み、対応状況（アクティブ / 解決済み）を管理する
• 通知の自動化: 新規の高重大度 Finding を Pub/Sub やメールで即時に拾い、対応 SLA を回す
• BigQuery で分析: エクスポートした Finding を SQL で集計し、傾向や残存リスクをレポート化する
• Cloud Audit Logs と併用: SCC の脅威 Finding を、誰が何をしたかの監査ログと突き合わせて調査する
• 対応のクローズ: 修復したら Finding を解決済みに更新し、再発を検出器で確認する

コスト

エディションによって料金体系が変わります。一般に Standard は無償で基本的な態勢管理が使え、Premium / Enterprise は有償で高度な脅威検知・脆弱性管理・準拠レポートなどが加わります。加えて、Finding を BigQuery にエクスポートして分析・保管する場合は BigQuery 側の取り込み・保管料が別途かかります。具体的な金額や課金単位は変動するため、最新は公式の料金ページで確認してください。

セキュリティ

• SCC へのアクセスも最小権限で: Finding は機微な弱点情報そのもの。閲覧・対応の権限を IAM で絞り、不要な広域ロールを避ける
• 高重大度を放置しない: 公開バケット・過剰権限・古い脆弱性などの Critical / High は最優先で是正する
• 脅威 Finding は即応: 不審なログインやデータ持ち出しの兆候は、検知から対応までの時間を短くする運用を組む
• 検出範囲を理解する: SCC はすべてを自動で塞ぐわけではなく「見つけて知らせる」役割。実際の修復は IAM・組織ポリシー・暗号化などの設定変更で行う

Well-Architected の観点

• セキュリティ: 態勢管理と脅威検知を統合し、設定ミス・脆弱性・進行中攻撃を一望できる中央コンソールを提供する。最小権限・暗号化・公開制御といったベストプラクティスからの逸脱を継続的に検出し、組織横断のセキュリティ基準を底上げする
• 運用: Finding を統一フォーマットで集約し、Pub/Sub や BigQuery と連携することで、トリアージ・通知・分析・自動修復の運用パイプラインに組み込める

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 組織 ID を確認
gcloud organizations list

# 組織配下のアクティブな Finding を一覧（重大度の高いものから対処する）
gcloud scc findings list ORGANIZATION_ID \
  --filter="state=\"ACTIVE\" AND severity=\"CRITICAL\""

# SCC の通知設定を作成し、新規 Finding を Pub/Sub トピックへ流す
gcloud scc notifications create scc-critical-alerts \
  --organization=ORGANIZATION_ID \
  --pubsub-topic=projects/my-project/topics/scc-findings \
  --filter="severity=\"CRITICAL\" OR severity=\"HIGH\""

# 既知で許容する Finding をミュート（ノイズ削減）
gcloud scc findings set-mute FINDING_ID \
  --organization=ORGANIZATION_ID \
  --source=SOURCE_ID \
  --mute=MUTED