Google Cloudは、BigQuery、Dataform、Colab Enterpriseのrepository作成処理にMissing Authorization脆弱性が存在したと公表した。識別子はGCP-2026-047、CVE-2026-14934、severityはCriticalである。認証済み攻撃者が権限を昇格し、tenantをまたいでrepositoryをtakeoverできる可能性があった。Googleは影響サービスへmitigationを適用済みとしている。

何が変わったか

2026年7月13日にsecurity bulletinと各product release notesが公開された。脆弱性はrepository作成時の認可に関するもので、攻撃成立時には別tenantのrepositoryを支配できる可能性があった。Googleは顧客側の追加actionは不要で、すべての影響product・serviceへ対策を適用したとしている。

変更前後の差

修正前は認証済み主体が本来許可されないrepositoryへ権限を拡大できる経路が存在した。修正後はGoogle側mitigationにより経路が遮断されている。顧客がsoftware versionを更新する形式ではないため、patch deploymentの確認ではなく、対象期間の操作と権限変更に不審点がなかったかを確認する。

誰に影響するか

BigQuery repositories、Dataform repositories、Colab Enterprise repositoriesを利用する組織が対象である。repository内にSQL、workflow code、notebook、service account参照、接続情報、deployment設定を置く場合、takeoverの影響はcode閲覧や改変だけでなく、下流pipelineやcredential利用へ広がる可能性がある。

期限

Googleは修正済みで顧客action不要としており、patch期限はない。ただしCriticalのcross-tenant問題であるため、内部監査は通常の月次確認を待たず、可能な範囲で早期に行う。ログ保持期間が短い環境では確認を先延ばしにしない。

必要な対応

対象projectとrepositoryを棚卸しし、repository作成、IAM policy変更、owner・editor追加、service account利用、workflow実行、外部接続の履歴を確認する。Googleの案内に反して不要な設定変更を急ぐ必要はないが、不審な主体、想定外tenant、未知のrepository、code改変があればcredentialをrotationし、supportへ連絡する。

実装・移行手順

  1. BigQuery、Dataform、Colab Enterpriseのrepository一覧を取得する
  2. 所有project、region、管理者、service accountを記録する
  3. repository作成とIAM変更のaudit logを確認する
  4. 未知のuser、service account、外部domainを抽出する
  5. code、notebook、workflowの重要な変更をversion管理と照合する
  6. 不審な実行、export、secret参照がないか下流logを確認する
  7. 異常があればcredential rotationとaccess revokeを行う
  8. 証跡を保全し、Google Cloud supportとsecurity窓口へ連絡する

失敗しやすい点

顧客action不要を監査不要と解釈する、Dataformだけを確認してBigQuery・Colab Enterpriseを除外する、repository IAMだけを見て下流service accountやpipeline実行を確認しない、といった問題が起きやすい。反対に、根拠なく全credentialを一斉rotationして業務停止を起こすことも避ける。

リスク

repository codeの閲覧・改変、pipelineへの不正処理挿入、service account経由の追加アクセス、機密queryやnotebookの漏えい、監査log保持期間切れがある。Googleは対策済みとしているが、修正前の悪用有無は各顧客環境のlogと資産に基づいて判断する必要がある。

評価方法

  • 対象repositoryの棚卸し率
  • audit log確認済みproject率
  • 未知のprincipal・外部domain件数
  • 想定外repository作成件数
  • code・workflow改変の不一致件数
  • credential rotationが必要になった件数
  • log保持期間内に確認できた割合
  • support escalation件数
  • 再発防止のIAM改善項目数

ロールバック

Google側mitigationを顧客がrollbackする作業はない。監査中に誤って権限やservice accountを変更した場合は、承認済みIaCまたはIAM backupから最小限を復元する。不審repositoryは削除前に隔離と証跡保全を行い、原因調査を妨げない。

編集部分析

「修正済み・顧客対応不要」は、緊急patchが不要という意味であり、Criticalなcross-tenant takeoverの可能性を無視してよいという意味ではない。クラウド管理面の脆弱性では、顧客ができる最も価値の高い対応は、資産棚卸しと監査logの迅速な確認である。過剰反応ではなく、証拠に基づく確認が必要になる。

実務チェックリスト

  • [ ] 3サービスのrepositoryを棚卸しした
  • [ ] repository作成とIAM変更logを確認した
  • [ ] 未知のprincipalと外部domainを抽出した
  • [ ] code・workflow変更をversion管理と照合した
  • [ ] 下流service accountの利用を確認した
  • [ ] 異常時のrotation対象を定めた
  • [ ] 証跡保全とsupport連絡手順を確認した
  • [ ] 顧客patch不要であることを関係者へ共有した

一次情報