チップス
どんぐり大学卒、一般企業の情報システム部で働く若手エンジニア。
入社1〜3年目らしい悩みを抱えつつ、日々の運用やセキュリティ対応に奮闘中。慌てんぼうだが素直で吸収力が高く、ボスに鍛えられながら着実に成長している。
ボス
セキュリティ、インフラ、運用の修羅場をくぐってきた歴戦のエンジニア。サイバーセキュリティラボの所長でボスと呼ばれている。
現場視点と経営視点の両方から、本当に使えるセキュリティとキャリア戦略を叩き込む。口は悪いが面倒見はよく、若手育成と実践的な情報発信に力を注いでいる。
「ApigeeみたいなAPIゲートウェイのSSRFって、何がそんなに怖いんでしゅか？」
「サービスアカウントトークンが漏れたら、クラウド全体に影響するんでしゅか？」
チップスボス、Google Cloud ApigeeにSSRF脆弱性が出たって聞きましたでしゅが、メタデータエンドポイントが狙われるって、何が起きるんでしゅか？
ボスそうだな。クラウドのメタデータエンドポイントはサービスアカウントトークンを返す経路で、SSRFで触られると環境全体の権限が盗まれかねない。API基盤での発生は影響が大きいぞ。
2026年5月、GoogleはApigeeのSetIntegrationRequestポリシーに存在するSSRF脆弱性CVE-2026-2264を、GCP-2026-034として公表しました。
本記事では、脆弱性の仕組み、クラウド環境への影響、そして利用組織が取るべき対策を整理していきます。
ApigeeはGoogle CloudのAPI管理基盤で、エンタープライズのAPIエコノミーを支える中核製品です。
事件の概要、SSRFの仕組みとクラウドメタデータへの脅威、そして取るべき対策の順に深掘りしていきます。
オススメ案件
【Microsoft 365・Intune環境の設計構築】神保町／セキュリティ・エンドポイント管理
【セキュリティ関連サービスの導入・構築・運用】小川町／EDR・MDM・認証基盤
【情報セキュリティモニタリング・IT資産構成管理支援】虎ノ門（リモート併用）／インフラ経験が活きるセキュリティ案件
【大手保険会社海外拠点向けCrowdStrike導入・IR支援】千代田区（リモート併用）／EDR・セキュリティエンジニア
【セキュリティ製品の運用・新規構築支援】新宿御苑（リモート併用）／WAF・IPS・IDS
【銀行向けセキュリティ対策・AWSクラウド運用支援】勝どき／FISC準拠・AWS（IAM/Backup）
【通信会社向けフリーWiFiシステム構造改革】基本リモート／Splunk（o11y・ITSI）
【大手商社向けSASE（Zscaler/Prisma）導入・構築支援】飯田橋（ハイブリッド）／ネットワーク・セキュリティ
【船舶サイバーセキュリティ規制（IACS UR E26/E27）対応】新浦安／OT・ICSセキュリティ
【某官公庁向けNW・セキュリティ基盤の設計構築】西新橋・23区内DC／Cisco・FortiGate・PaloAlto
本件はGoogleが公式セキュリティブルテンとして公開した、重要度Highの脆弱性です。
クラウド版のApigeeは利用者側の対応不要ですが、自社運用のApigee Hybridは更新が必要です。
製品ごとのパッチ情報を以下の表に整理しました。
| 製品 | 対応すべきバージョン |
|---|---|
| Apigee（Google Cloud版） | リリース1-16-0-apigee-5で修正済み（対応不要） |
| Apigee Hybrid v1.14 | 1.14.4以降 |
| Apigee Hybrid v1.15 | 1.15.2以降 |
| Apigee Hybrid v1.16 | 1.16.1以降 |
チップスSetIntegrationRequestポリシーって、どんな機能でしゅか？うちでも使ってる可能性があるんでしゅか？
ボスApplication Integrationを呼び出すためのポリシーだ。リクエストのregionをフロー変数で動的に組み立てる構成では、攻撃者が変数を操作できれば任意のホストへリクエストを誘導できる仕組みになっていた。
クラウド環境のSSRFは、オンプレ環境とは別格のリスクを抱えます。
クラウドの内部からのみアクセス可能なメタデータエンドポイントは、サービスアカウントトークンを返すため、SSRF経由で触られると致命的です。
典型的に発生し得る被害は以下の通りです。
チップスAPIゲートウェイって、本来はバックエンドを守るための仕組みなのに、入口側が侵害されると、内部に通じる扉になっちゃうんでしゅね。
ボスその通りだ。ゼロトラストの観点では、ゲートウェイ自体も「侵害される前提」で内部APIへの認証を二重化すべきだ。今回はその重要性を再確認させる事案だな。
Google公式セキュリティブルテンを踏まえ、以下の手順で対応するのが現実的です。
SSRFは伝統的な脆弱性ですが、クラウド時代には認証トークン窃取の起点として最大級のリスクになっています。
API基盤の脆弱性公表があった場合は、製品の更新と同時にメタデータエンドポイント周辺の監査を行うのが鉄則です。
ボスクラウド時代のSSRFは、もはやWebアプリのバグではなく、IAM運用そのものへの攻撃だ。脆弱性管理と権限設計を一体で考える必要があるぞ。
チップスAPI基盤の運用ポリシーも、攻撃者目線で見直してみるでしゅ！
オススメ案件
【Microsoft 365・Intune環境の設計構築】神保町／セキュリティ・エンドポイント管理
【セキュリティ関連サービスの導入・構築・運用】小川町／EDR・MDM・認証基盤
【情報セキュリティモニタリング・IT資産構成管理支援】虎ノ門（リモート併用）／インフラ経験が活きるセキュリティ案件
【大手保険会社海外拠点向けCrowdStrike導入・IR支援】千代田区（リモート併用）／EDR・セキュリティエンジニア
【セキュリティ製品の運用・新規構築支援】新宿御苑（リモート併用）／WAF・IPS・IDS
【銀行向けセキュリティ対策・AWSクラウド運用支援】勝どき／FISC準拠・AWS（IAM/Backup）
【通信会社向けフリーWiFiシステム構造改革】基本リモート／Splunk（o11y・ITSI）
【大手商社向けSASE（Zscaler/Prisma）導入・構築支援】飯田橋（ハイブリッド）／ネットワーク・セキュリティ
【船舶サイバーセキュリティ規制（IACS UR E26/E27）対応】新浦安／OT・ICSセキュリティ
【某官公庁向けNW・セキュリティ基盤の設計構築】西新橋・23区内DC／Cisco・FortiGate・PaloAlto
