Cloud MonitoringのService Agentを踏み台にしたCloud Run認可回避――Tenableが指摘、Googleは即修正です

今日の深掘りポイント

• クラウドの「サービスエージェント」が持つ横断的な特権は、IAMの表層だけを監査しても見落とす境界です。今回はCloud MonitoringのService Agentが、Cloud Runの認可を迂回する足場になり得た点が本質です。
• 低権限相当のロールから、運用系の機能を経由して実行面の権限に“横滑り”できてしまう設計リスクが露わになりました。クラウドでは「権限×機能」の組み合わせで思わぬ昇格が起きます。
• 緊急の大規模パッチ対応は不要とされますが、検出可能性は高い領域です。監査ログとCloud Runの呼び出しログで、Monitoring由来の不自然な呼び出しを可視化するだけでもリスクは一段下げられます。
• 地政学的にも、プラットフォーム内のサービス間信頼が脆くなると、重要業務の継続性に直結します。委託先のセキュリティのみならず、クラウド事業者のサービス間境界の審査観点を調達要件に織り込むべきです。

はじめに

Tenableが、Google Cloud PlatformのCloud Monitoringにおける特権昇格の脆弱性を公表しました。低権限の攻撃者でも、IAMの制御を迂回して認証が必要なCloud Runサービスを呼び出せる可能性があったという指摘です。Googleは修正を完了し、顧客側の追加対応は不要としています。この種の問題は「設定不備」ではなく「クラウド事業者の機能間連携における境界設計」の問題であり、クラウド利用組織の責務は“急いで直す”より“どう備えるかを再設計する”方向にあります。

総合的に見ると、即応が求められるクリティカルな零日というより、運用と監査の当たり前を一段引き上げる好機です。とはいえ、攻撃に転用された場合のビジネス影響は業務フローに直結するため、SOCとSREが協働して検出・抑止の手当てを先に打っておきたい案件です。

深掘り詳細

何が起きたのか（事実）

• Tenableの報告によれば、Cloud MonitoringのUptime ChecksはHTTPターゲットに対してMonitoringのService Agentが発行するIDトークンで認証でき、このService AgentはデフォルトでCloud Runの認証済みエンドポイントを呼び出す権限（run.routes.invoke相当）を持っていたため、低権限のユーザーでもIAM制御を迂回してCloud Runの呼び出しを行える状況がありました。Googleはこの問題を修正し、特定の権限を持つユーザーだけが当該Service Agentの認証機能を使えるように制限しました。顧客側での追加作業は不要とされています。
• Tenableは、非常に限定的なMonitoringロール（monitoring.uptimeCheckConfigViewer）を持つ主体が、Service Agentのアイデンティティを通じて任意パラメータでCloud Runエンドポイントを呼び出せた点を確認したと述べています。

出典: Tenable Security Research: TRA-2026-05

どこに本質があるのか（インサイト）

• 権限の“所有者”と“実行主体”のズレです。IAM上は低権限でも、運用系のサービス（Monitoring）が代理人（Service Agent）として実行面の権限を持ち、その代理実行を広く解放してしまうと、実質的な昇格が成立します。これはクラウドの「コントロールプレーンとデータプレーンの橋渡し」に潜む典型的な設計リスクです。
• 「認証済みCloud Run」を守るのはIAMのrun.invokerだけではありません。プラットフォームが発行するIDトークンの“誰が・いつ・どこに向けて”の条件を、どの機能がどの粒度で制御できるかが実効的な境界になります。今回の修正は、Monitoring側の利用者制御を締めることでこの境界を復元したものと理解できます（Tenableの説明に基づく推測です）。
• 現場の痛点は検出と説明責任です。たとえベンダ側で修正済みでも、過去に何が呼ばれたか、同様の設計が他サービス間にもないか、説明可能性を持てる体制が信頼を支えます。ログの網羅と相関、委託先・開発部門との運用合意が問われます。

脅威シナリオと影響

以下は、公開情報に基づく仮説のシナリオとMITRE ATT&CKの暫定マッピングです。具体的な技術的前提やログ項目名は環境により異なるため、検証のうえ自組織に当てはめてください。

• シナリオA: 内部の低権限アカウントが運用機能を悪用してCloud Runを不正呼び出し

  • 前提: 攻撃者は監視設定の閲覧・テストに近い低権限（viewer級）を持つアカウントを得ています。
  • 行為: MonitoringのUptime Check等の機能を用いて、Service AgentのIDトークンでCloud Runの認証済みエンドポイントを任意パラメータで呼び出します。
  • 影響: 認可外のビジネス処理実行、データ抽出、状態変更のトリガーなどが成立します。
  • ATT&CK仮説:
    • T1078 Valid Accounts（正規アカウントの使用）
    • T1068 Exploitation for Privilege Escalation（機能設計の欠陥を突いた昇格）
    • T1550 Use of Alternate Authentication Material（プラットフォーム発行トークンの流用）
    • TA0040 Impact（処理実行やデータ取得による業務影響）

• シナリオB: 侵害後の横移動としての“実行代理”悪用

  • 前提: 攻撃者は任意の低権限クラウドIDを掌握済みです。
  • 行為: 監視系サービスが持つ代理実行ルートを見つけ、Cloud Runや他の認証エンドポイントの実行を誘発します。
  • 影響: 高権限ワークロードの実行による情報収集や追加の足掛かり確保が可能になります。
  • ATT&CK仮説:
    • T1526 Cloud Service Discovery（クラウドサービスの探索）
    • T1068 Exploitation for Privilege Escalation
    • T1106 Native API（クラウドAPI経由の機能呼び出し）

• 影響評価の勘所

  • 直撃の被害額はユースケース依存ですが、サプライヤー管理のService Agentが横断的に強権を持つ設計が他領域にも潜む場合、リスクの拡張性は高いです。
  • 検知可能性は相対的に高いと考えます。Cloud Monitoring側の設定・テスト実行と、Cloud Run側のリクエスト・認証主体のログを相関すれば、異常な呼び出し経路を可視化できる可能性が高いです（環境依存のため検証が必要です）。

セキュリティ担当者のアクション

Googleは修正済みで顧客側の即時対応は不要とされますが、以下の予防・検出・説明責任の強化は有効です。

• 可視化と検出

  • Cloud MonitoringのUptime Checkやテスト実行の操作ログと、Cloud Runの呼び出しログを相関し、Monitoring由来の呼び出し頻度・宛先・パラメータのベースラインを作ることをお勧めします。
  • 低権限アカウントによる監視設定の“テスト”操作が、業務の想定外エンドポイントを叩いていないかを継続監査します。
  • 過去90日〜180日程度の履歴から、MonitoringのService Agentが関与するCloud Run呼び出しを棚卸しし、正当性をレビューします。

• 権限と境界の是正

  • 監視系ロールの付与範囲を再確認し、「閲覧だけ」のつもりで実行系の機能にアクセスできていないか検証します。特に、テスト・検証用の操作権は運用者に限定し、分離します。
  • Cloud Runの重要エンドポイントは、IAMの認可だけに依存せず、アプリ層での追加検証（例えばリクエストヘッダの固有検証や二段目のアプリケーション認証）で“正当な呼び出し経路”を縛ることを検討します。

• プロセスとガバナンス

  • サービスエージェントの権限に関するリスク受容・例外申請・年次見直しのプロセスを整備します。クラウド事業者の機能変更に追随できる“権限カタログ”の保守も重要です。
  • SRE/運用とSOCが合同で、監視系機能が業務系に及ぼし得る影響のテーブルトップ演習を行い、検知から封じ込めまでの責任分界を明確化します。

• ベンダー対話

  • 調達・セキュリティレビューで、ベンダー管理のService Agentが持つデフォルト権限、機能間の代理実行経路、顧客側での強制ガードレール（制限設定や組織ポリシー）の有無を質問事項に含めます。

参考情報

• Tenable Security Research: TRA-2026-05「GCP Cloud Monitoring privilege escalation enables unauthorized Cloud Run invocations」（Tenableの公開報告。Googleの修正完了と顧客側の追加対応不要の言及を含みます）: https://www.tenable.com/security/research/tra-2026-05

今回の事案は、クラウドの“便利さ”がもたらす代理実行の影に光を当てました。設定を一段きれいにするだけで終わらせず、境界の考え方をチームで共有し、ログと権限とプロセスを三位一体で整えていくことが、次の一手になります。読者のみなさんの現場に合わせて、上記の打ち手を今日の運用に落とし込んでいただければ幸いです。