GCP Eventarcの特権昇格―制限権限から任意サービスアカウントのアクセストークン窃取に至る設計リスクです

今日の深掘りポイント

• Eventarcのパイプライン作成フローに起因する権限検証の甘さを突き、Eventarcサービスエージェントの高権限を“肩代わり”してアクセストークンを生成・流出できた事案です。
• 影響は「クラウドの制御プレーン」を介した間接的な特権昇格で、最小権限運用でも“サービスエージェントの権限伝播”が盲点になり得ることを示すケースです。
• 検知のカギは、IAM Credentials APIのGenerateAccessTokenをEventarcのサービスエージェントが実行した痕跡と、当該前後のEventarcパイプライン（またはトリガ）の作成・更新ログの相関です。
• アクセストークン自体は短命でも、仮にそのトークンで永続化（鍵作成・ロール付与）に踏み込まれていれば被害は持続します。監査は「その先の操作」まで追うことが重要です。
• 本件は修正済みですが、クラウド各サービスの「サービスエージェントが保有する特権」と「ユーザーが与えられた構成権限」が交差するポイントの継続的点検が必要です。

はじめに

TenableがGoogle CloudのEventarcで、制限的なEventarc権限しか持たない攻撃者でも、プロジェクト内の任意サービスアカウント（SA）のアクセストークンを抽出できてしまう脆弱性を報告しました。攻撃者はEventarcのパイプラインを作成し、内部で動く特権保持のEventarcサービスエージェントを経由してトークンを生成し、外部へ流出できたとされています。Googleは既にパイプライン作成時の権限チェックを強化して修正済みです。一次情報はTenableの公開に限られますが、クラウドの制御プレーンにおける「権限の間接伝播」というリスクを、実運用に引き寄せて読み解くことが肝要です。

参考: Tenableの公開情報（2026-03-04）です。

• Tenable Research Advisory: TRA-2026-15

深掘り詳細

事実関係（Tenable公表に基づく）

• 対象はGoogle CloudのEventarcです。Eventarc内のパイプライン作成時の権限検証に不備がありました。
• 制限的なEventarc関連権限しか持たない攻撃者でも、Eventarcサービスエージェントの特権を利用し、プロジェクト内の任意SAに対するアクセストークンを生成（窃取）し、外部へ流出させることが可能でした。
• Googleは問題を修正し、パイプライン作成時に必要な権限チェックを強化しています。
• 公表は2026年3月4日で、Tenableはこの日付で初回リリースを行っています。
  （以上はTenableの上記アドバイザリに依拠しています。追加の技術詳細やCVE等は本稿執筆時点で当該公開文書以上の確認情報を持ち合わせていません。）

編集部の視点・インサイト（仮説を含みます）

• 設計上の“権限伝播”が核心です。Eventarcは内部でサービスエージェントを用い、イベント配送や下流サービス呼び出しのために広い権限を保有しがちです。ユーザーが構成可能な項目が、そのサービスエージェントの行為主体に影響すると、表面上は「低権限のユーザー操作」が、裏側では「高権限の実行」に転化します。今回の不備は、この境界での検証が十分でなかった可能性を示しています。
• アクセストークンは通常短寿命ですが、攻撃者はその時間窓で“永続化”に踏み込めます。例えば、より強いロールの自付与、別SAの鍵作成、外部CIに紐づく資格情報の再設定などです。したがって、単に「トークンが短期で失効するから安心」とは言えず、トークン使用直後の管理プレーン操作（SetIamPolicy、CreateServiceAccountKey等）の有無を追跡することが重要です。
• 本件はクラウド一般に通底する教訓を与えます。すなわち、「ユーザーが作成する構成（パイプライン）」と「クラウド側の自動実行主体（サービスエージェント）」が接続する箇所は、最小権限の原則が破れやすいです。SaaS/PaaSの利便性の裏側で、権限の委譲・代行が複雑化し、“見えない昇格パス”が生まれる構造的リスクを、組織として定期的に棚卸しする必要があります。

脅威シナリオと影響

以下は、Tenableの公表内容を起点にした仮説シナリオと、MITRE ATT&CK準拠の観点整理です。

• 想定シナリオ（仮説）

  1. 攻撃者は、当該プロジェクト内で限定的なEventarc権限を持つアカウント（開発者・CI用サービスアカウントなど）を掌握します。
  2. 当該アカウントでEventarcのパイプライン（または近似の実行経路）を作成・変更し、内部でEventarcサービスエージェントが任意のターゲットSAのアクセストークンを生成する経路を組み込みます。
  3. 生成されたアクセストークンを、パイプラインのシンクや後段処理を用いて外部エンドポイントへ流出させます。
  4. 攻撃者は窃取トークンでGCP APIにアクセスし、プロジェクト内の権限拡大、永続化（鍵作成・ロール付与）、別リソースへの横展開を試みます。
  5. その後の痕跡を隠蔽するため、パイプラインを削除または元に戻します。

• MITRE ATT&CKマッピング（仮説）

  • 初期侵入/準備:
    • Valid Accounts: Cloud Accounts（T1078.004）です。限定権限アカウントの不正利用を想定します。
  • 権限昇格:
    • Exploitation for Privilege Escalation（T1068）です。クラウドサービスの権限検証不備を突いた特権昇格です。
  • 資格情報アクセス:
    • Steal Application Access Token（T1528）です。アクセストークンの抽出に該当します。
  • 横移動・防御回避:
    • Use Alternate Authentication Material: Application Access Token（T1550.001）です。パスワード等を用いずトークンでAPI呼び出しを行います。
  • 流出:
    • Exfiltration Over Web Service（T1567）です。シンクや下流サービスを経由した外部送信を想定します。
  • 発見・偵察（任意）:
    • Permission Groups Discovery: Cloud（T1069.003）、Cloud Service Discovery（T1526）です。高価値SAの探索を仮定します。

• 影響評価の視点

  • 直接影響は「任意SAとしてのAPI実行」ですが、実害はターゲットSAの本来権限次第で大きく振れます。ビルド/デプロイ系SAやセキュリティ基盤SA（脆弱性スキャナ、バックアップ、セキュリティハブ連携など）を奪取されると、横断的な変更権を得られる可能性があります。
  • SAトークンを足掛かりに、より強いロール付与、サービスアカウント鍵の作成、外部IdP連携設定の改変といった永続化に成功すると、修正済みであっても被害が続く点が要注意です。
  • 運用面では、Eventarcのようなイベント統合サービスがSOCの監視対象から漏れがちなこともリスク増幅要因です。監視設計のギャップを埋める必要があります。

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

本件は既にGoogleにより修正済みとされていますが、過去分の悪用有無確認と、設計上の再発防止に軸足を置くべきです。優先度順で示します。

• 即時の監査・検知強化

  • Cloud Audit Logsで、EventarcサービスエージェントによるGenerateAccessTokenを特定します。代表的なLogs Explorerフィルタ例です（プロジェクト単位、期間は公表前後に広めに設定します）。

    protoPayload.serviceName="iamcredentials.googleapis.com"
    protoPayload.methodName="google.iam.credentials.v1.IAMCredentials.GenerateAccessToken"
    protoPayload.authenticationInfo.principalEmail =~ "service-[0-9]+@gcp-sa-eventarc\\.iam\\.gserviceaccount\\.com"
    

    可能なら、上記イベントの直後（±5〜10分）に以下の管理操作が無いか相関して確認します（永続化の痕跡です）。
    • iam.googleapis.com SetIamPolicy（ロール付与/変更）
    • iam.googleapis.com CreateServiceAccountKey / DeleteServiceAccountKey
    • cloudresourcemanager.googleapis.com SetIamPolicy（プロジェクト/フォルダ/組織）
  • Eventarcのパイプライン/トリガの新規作成・更新ログを横断検索します（メソッド名は環境差があるため正規表現で網を広げます）。

    protoPayload.serviceName="eventarc.googleapis.com"
    protoPayload.methodName =~ "(Create|Update)"
    

    不審指標は「低権限主体による作成」「普段使わないリージョン」「外部エンドポイントや見慣れないシンクの指定」などです。
  • 監査対象期間内に、上記のアクセストークン生成とパイプライン作成が近接している事例を抽出し、優先度高で事後分析します。

• 権限の是正（サービスエージェント経由リスクの最小化）

  • Eventarcサービスエージェントに付与されている役割と、任意SAへのトークン生成（iam.serviceAccounts.getAccessToken）可否を棚卸しします。
    • すべてのSAについて「誰がroles/iam.serviceAccountTokenCreator等を保有しているか」を組織スコープで検索します（例）。

      gcloud asset search-all-iam-policies \
        --scope=organizations/ORG_ID \
        --query='role:roles/iam.serviceAccountTokenCreator'
      

    • 高価値SA（デプロイ・課金・セキュリティ管理系など）に対し、不要なトークン生成権限の経路（含：サービスエージェント）を遮断します。可能であればIAM Denyポリシーで、特定主体によるgetAccessTokenを明示的に拒否するガードレールを検討します（実環境差があるため検証環境でのテストを推奨します）。
  • 組織ポリシーで「サービスアカウント鍵の作成禁止（constraints/iam.disableServiceAccountKeyCreation）」を有効化し、アクセストークンからの永続化を困難化します。例外は厳格なプロセスで最小化します。

• ログとモニタリングの持続的運用

  • iamcredentials.googleapis.com のData Accessログを有効化し、GenerateAccessToken/GenerateIdTokenの呼び出しを常時可視化します。監査対象はサービスエージェント発行分を優先します。
  • SIEMでの検知ルール例です。
    • 検知A: principalEmailにgcp-sa-eventarcを含み、対象SAが「高価値リスト」に一致するGenerateAccessTokenを高危険度でアラート化します。
    • 検知B: GenerateAccessTokenの5分以内に、当該トークン主体によるSetIamPolicyまたはCreateServiceAccountKeyがあれば連結アラートに格上げします。
    • 検知C: Eventarcのパイプライン/トリガ作成が、通常運用者以外の主体から行われた場合に通知します。

• インシデント対応（疑わしい痕跡が出た場合）

  • 関連SAを一時的に無効化またはローテーションし、当該期間のAPI呼び出しを遡及レビューします。アクセストークン自体は失効しますが、永続化（鍵作成、ロール追加、外部連携設定変更）が無いかを必ず確認します。
  • プロジェクト/フォルダ/組織のIAM変更差分を時間順に再構築し、不要な権限は即時巻き戻します。必要に応じて強制ロールバック用のプレイブックを用意します。

• ガバナンスと設計改善

  • 「サービスエージェントに頼る自動化」の棚卸しを四半期ごとに実施し、ユーザーが構成可能な入力から高権限実行に到達し得る導線を洗い出します。
  • 最小権限は「人とSAの直接付与」だけでなく、「サービスエージェントが成し得る代行権限」まで含めて評価します。アーキテクチャレビューのチェックリストに“サービスエージェントの越権可能性”を常設することを推奨します。

なお、本件は信頼できる一次情報に基づく報告で修正済みとはいえ、性質上、即応と棚卸しの両輪が功を奏します。実務の肌感としても、迅速に行える監査クエリと、持続的な権限ガードレール整備の投資対効果は高いと考えます。優先順位づけの観点でも、即時性と実行容易性が両立している領域から着手すると良いです。

参考情報

• Tenable Research Advisory: TRA-2026-15（GCP Eventarcの特権昇格脆弱性、2026-03-04公開）: https://www.tenable.com/security/research/tra-2026-15

この種の「制御プレーンの境界」に潜む脆弱性は、運用が成熟した組織ほど見落としがちです。今回の機会を、監査クエリの常設化と、サービスエージェント権限の見直しに活かしていきたいところです。クラウドの安全性は、設計と監視の反復で底上げできるはずです。