はじめに

クラウド環境では、設定ミスなどにより、意図しないままリソースが外部公開されてしまう可能性があります。インターネットから到達可能なリソースは、攻撃者の自動スキャンによって短時間で発見・悪用される対象になり得ます。

この外部攻撃面(External Attack Surface)の把握を目的とした External Exposure という機能が、Preview として Google Cloud の Security Command Center(以下 SCC)に追加されました。本記事では、この機能を実際に有効化し、検証用に用意した公開リソースに対して何がどのように検知されるかを確認します。

※ 本記事は Preview 時点(2026年6月)の仕様に基づきます。GA までに仕様が変わる可能性があります。

External Exposure とは

External Exposure は、SCC が管理対象の Google Cloud 環境を外部から能動的にスキャンし、インターネットから到達可能なリソースと、その悪用可能性を検出する機能です。単に設定上の公開可否を確認するのではなく、実際にスキャントラフィックを送って到達性と挙動を検証する点が特徴です。

External Exposure は、外部攻撃面管理(EASM, External Attack Surface Management)の考え方を Google Cloud のリソースに適用した機能です。ただし、検出の対象は Security Command Center の対象範囲内にある Google Cloud リソースに限られます。Google Cloud の外にある資産や、対象範囲外のサービスの公開ポイントを、ドメイン名などから横断的に発見するものではありません。

能動スキャン時のリクエストは User-Agent TsunamiSecurityScanner となっており、External Exposure の能動スキャンは Google が開発するオープンソースのネットワークスキャナ Tsunamigoogle/tsunami-security-scanner)をベースにしていると考えられます。

検出は次の観点(モジュール)で行われます。

  • 弱い認証情報(Weak Credentials)
  • リモートコード実行(Remote Code Execution、RCE)
  • 不正なデータ読み取り(Arbitrary Data Read)
  • 公開された UI・Web インターフェース(Exposed UI)
  • 公開された API(Exposed API)

External Exposure は SCC の Premium ティアで利用できます。

参考:

検証環境のセットアップ

検証では、External Exposure 機能を組織レベルで有効化しました。

SCC の他機能と同様、フォルダレベルやプロジェクトレベルで、有効・無効・親から継承 を選択できました。

モジュールは5種類あり、デフォルトで全て有効になっていました。

スキャン構成にて、スキャン対象のポートを追加できるようになっています。

また、以下のような検証用ターゲットを用意しました。

  • 公開 VM(Compute Engine インスタンス、外部 IP 付与、ポート 22/80 を開放)
  • 公開 Cloud Run サービス(hello コンテナ)

公開リソースは External Exposure のスキャナだけでなく、本物の攻撃者にも晒されます。万一侵害された場合でも影響が広がらないよう、ガードレールを設定しました。

  • サービスアカウントを付与しない
  • 専用 VPC に隔離(他リソースへの横移動を防ぐ)
  • 下り(egress)通信を全拒否(持ち出し・マイニング・外部通信を防ぐ)
  • SSH はパスワード認証を無効化(鍵認証のみ)

有効化と初回スキャン

External Exposure を有効化すると、継続的スキャンが自動的に実行されます。スキャンは即時ではなく、ダッシュボードに表示される「前回のスキャン」「次回のスキャン」のタイムスタンプで実行状況と次回時刻を確認できます。

検証では、スキャン間隔はおおむね12時間程度でした。なお、スキャンの頻度・スケジュールは公式ドキュメントには明記されていないため、運用上は「次回のスキャン」を確認するのが確実です。

検出結果

検証用のターゲットに対して、スキャン後に検出が生成されました。いずれも finding クラスは EXTERNAL_EXPOSURE、深刻度は CRITICAL です。(上図)

VM はポート単位で検出される

公開 VM については、開放したポートごとに検出が分かれて生成されました。

  • ポート 80 : カテゴリ EXTERNALLY_EXPOSED_VM_INSTANCE、検出されたサービス SimpleHTTPServer 0.6
  • ポート 22 : カテゴリ EXTERNALLY_EXPOSED_VM_INSTANCE、検出されたサービス OpenSSH 9.2p1


Cloud Run(サーバーレス)も検出対象

公開した Cloud Run サービスは、カテゴリ EXTERNALLY_EXPOSED_SERVERLESS_WORKLOAD として検出されました。

各検出には、公開 IP・ポート・検出サービス・推奨対応(nextSteps)などの情報が含まれます。finding の JSON は項目が多岐にわたるので、継続運用やマルチテナントでの取り扱いを想定すると、必要項目を抽出・整形する仕組みが必要になります。

ログから確認できるスキャンの実態

External Exposure は、到達性の確認だけでなく、既知の脆弱性に対する能動的なプローブ(悪用可能性のテスト)も実行します。検証中、公開リソースのアクセスログには、能動スキャン(User-Agent TsunamiSecurityScanner)による多数のプローブが記録されていました。短時間のうちに、パストラバーサル(/etc/passwd の読み取り試行)や、Grafana・Apache Struts・Oracle WebLogic・MLflow といった既知脆弱性向けのペイロード送信が確認できました。

ログに記録されていたリクエストの例

GET  /etc/passwd
GET  /${(#a=@java.lang.Runtime@getRuntime().exec("... TSUNAMI_PAYLOAD ..."))}/   # Struts2 OGNL RCE
POST /ajax-api/2.0/mlflow/registered-models/create                # MLflow

運用・採用検討上のポイント・注意事項

検証で確認できたポイントや、運用・採用検討の上での注意事項は以下のとおりです。

  • 設定は簡単で、有効化するのみで組織の公開リソースを検出できる。
  • 検出はリアルタイムではなく、定期的なスキャン(実測で概ね12時間間隔)。
  • 外部から到達可能であること自体が CRITICAL として検出される。意図的に公開しているサービスも CRITICAL になるため、ミュートや例外管理を含むトリアージ運用が前提になる。
  • 対象外のリソースの検知はできない。あくまで対象となる Google Cloud リソースのうち、公開されているものを検出する、簡易 ASM 機能。
  • 課金体系は Preview 期間後に別途確認する必要あり。

おわりに

External Exposure は、設定ベースのチェックとは異なる「外部から実際に到達・悪用できるか」という視点を、追加の構成なしに得られる機能です。簡単なセットアップで、公開リソースの検出に加え、既知脆弱性に対する能動的なスキャンにより Attack surface の可視化が可能なことが確認できました。

プレビュー中ではありますが、クラウド環境の安全性を攻撃者目線で手軽に評価できる機能として、今後のさらなるアップデートに注目していきたいと思います。本記事が、Google Cloud環境のセキュリティ対策を検討されている方々のご参考になれば幸いです。