Web Security Scanner

解決する課題

公開した Web アプリには、気づかないうちに XSS や安全でないリソース読み込み、古い脆弱なライブラリといった穴が残りがちです。Web Security Scanner は、アプリを実際にクロールしながら擬似的な攻撃入力を送り込み、こうした弱点を自動で洗い出します。

• 公開 URL に XSS や安全でない設定が残っていないかを、人手のレビューに頼らず定期的に確認したい
• 画面やフォームが多く、手動テストでは網羅しきれないページの脆弱性を機械的に巡回して探したい
• 検出結果を散在させず、Security Command Center に集約して他のセキュリティ Finding と一緒に優先度を付けたい
• リリースのたびに回帰的な脆弱性チェックを回し、デグレを早期に捕まえたい

AWS でいえば、稼働中のリソースに対して脆弱性を評価する Amazon Inspector に近い位置づけのサービスと考えると理解しやすいです。

主要概念と用語

• スキャン構成（ScanConfig）: 何を・どう巡回するかの設定。開始 URL、対象とするドメイン範囲、スケジュール、認証方法などを定義する
• クロール（クローリング）: 開始 URL を起点にリンクをたどり、到達できるページ・フォーム・入力フィールドを自動で洗い出す処理
• 擬似攻撃（攻撃ペイロード）: 見つけた入力欄に XSS などの攻撃用文字列を送り、アプリが脆弱な挙動を示すかを検証する手法
• Finding（検出結果）: スキャンが見つけた1件の脆弱性。種別（XSS、混在コンテンツ等）、対象 URL、再現情報を持つ
• スキャン認証: ログインが必要なページを巡回するための設定。Google アカウント、カスタムアカウント（フォームログイン）、IAP などの方式がある
• 除外パターン（除外 URL）: ログアウトや課金・削除など、巡回してほしくない URL を指定して副作用を避ける仕組み
• Security Command Center 連携: Web Security Scanner は SCC の検出器の一つで、結果を SCC の統一フォーマットの Finding として集約する

仕様・制限・クォータ

• 対象は公開された Web アプリ。App Engine、GKE、Compute Engine などで動く、外部からアクセス可能な URL を巡回する。社内限定で外部到達できないエンドポイントは対象外になりやすい
• 検出できる脆弱性の種別は限定的。XSS、混在コンテンツ（HTTPS ページでの平文リソース読み込み）、クリアテキストでの機微情報送信、脆弱・古い JavaScript ライブラリの使用などが代表例で、あらゆる脆弱性を網羅するわけではない
• 能動的スキャンは副作用を伴う。フォーム送信やリンク追跡を実際に行うため、データ作成・更新・削除や通知送信などが起きうる。本番では除外設定やテスト環境の利用が前提
• エディションによる差: マネージドな自動スキャンや一部機能は Security Command Center の上位エディションで提供される。利用できる範囲はエディションに依存する
• クォータ: スキャン構成数や同時実行・1日の実行回数などに上限がある。具体値は変動するため、最新は公式ドキュメントで確認する

内部の仕組み

Web Security Scanner は「巡回して入力を見つけ、擬似攻撃で確かめる」を自動で回します。

1. クロール: 指定した開始 URL を起点に、Chrome ベースのブラウザでページをレンダリングしながらリンク・フォーム・入力欄をたどり、到達可能な箇所を洗い出す
2. 入力の特定: フォーム項目・クエリパラメータなど、攻撃ペイロードを差し込める入力ポイントを抽出する
3. 擬似攻撃の実行: 各入力ポイントに XSS などの検証用ペイロードを送信し、応答や DOM の挙動から脆弱性の有無を判定する
4. Finding 生成と集約: 見つけた脆弱性を Finding 化し、再現に必要な URL や入力情報を添えて Security Command Center に集約する

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

• テスト環境に対して回す: 能動的スキャンの副作用を避けるため、本番ではなくステージングや専用テスト環境を対象にするのを基本とする
• 危険な URL を除外する: ログアウト・削除・送金・通知送信などの URL は除外パターンで巡回対象から外し、意図しない操作を防ぐ
• 専用テストアカウントで認証スキャン: ログイン後の画面を巡回するときは、本番ユーザーではなく使い捨ての専用アカウントを設定し、被害を局所化する
• CI/CD に組み込む: リリース前のパイプラインでスキャンを実行し、新規 Finding が出たらゲートとして扱い回帰を防ぐ
• SCC で優先度付け: 結果を Security Command Center 側で他の Finding とまとめてトリアージし、重大度の高いものから是正する
• 検出範囲を補う: Web Security Scanner は万能ではないため、認証・認可やビジネスロジックの欠陥は手動診断や別ツールで補完する

運用・監視

• スケジュール実行: スキャン構成にスケジュールを設定し、定期的に自動実行して継続的に脆弱性を監視する
• Finding のトリアージ: 検出結果は Security Command Center のダッシュボードで重大度・対象 URL ごとに確認し、対応状況を管理する
• 通知連携: SCC の通知（Pub/Sub など）を使い、新規の脆弱性 Finding を即時に拾ってチケット起票や対応フローへ流す
• 副作用の監視: スキャン実行中はテスト環境のデータ変化やエラー率を観察し、想定外の操作が起きていないかを確認する
• 再スキャンで確認: 修正後に再スキャンを行い、Finding が解消したか・新たな問題が出ていないかを検証する

コスト

Web Security Scanner は Security Command Center の検出器の一つとして提供され、利用できる範囲は SCC のエディションに依存します。マネージドな自動スキャンを含む高度な機能は上位エディションで提供され、基本的な範囲は無償エディションでも使えます。スキャナ自体の課金より、対象アプリ側で発生するリソース消費（スキャン中のリクエスト増による App Engine / GKE などの処理コスト）に注意します。具体的な金額や課金単位は変動するため、最新は公式の料金ページで確認してください。

セキュリティ

• 本番影響を最小化する: 能動的スキャンはデータ変更を起こしうるため、テスト環境利用・除外設定・専用アカウントで影響範囲を限定する
• 認証情報を慎重に扱う: スキャン認証に使うアカウントは最小権限の使い捨てとし、強い権限を持つアカウントを使い回さない
• Finding は機微情報: 検出された脆弱性の詳細は攻撃者に有用な情報そのもの。閲覧権限を IAM で絞り、SCC のアクセス制御と合わせて管理する
• 検出と修復は別: スキャナは弱点を見つけるだけで自動修復はしない。Finding を受けてコード修正や設定変更を行って初めてリスクが下がる

関連サービス・比較

設定ミスや脅威も含めて横断的に管理したい場合は、Web Security Scanner の結果を集約する Security Command Center が中心になります。Web Security Scanner は「公開 Web アプリの脆弱性を能動的に探す」役割、SCC は「各検出器の Finding を集約・トリアージする」役割という分担です。

ハンズオン / CLI例

# スキャン構成を作成（開始 URL とスケジュールを指定）
gcloud scc scan-configs create webapp-scan \
  --display-name="WebApp Vulnerability Scan" \
  --starting-urls="https://staging.example.com/" \
  --schedule-interval-days=7 \
  --project=my-project

# 危険な URL を除外しつつ構成を更新（ログアウト等を巡回対象から外す）
gcloud scc scan-configs update webapp-scan \
  --blocked-urls="https://staging.example.com/logout,https://staging.example.com/delete" \
  --project=my-project

# 作成済みのスキャン構成を一覧
gcloud scc scan-configs list --project=my-project

# スキャンを手動で開始
gcloud scc scan-configs start webapp-scan --project=my-project