Google Cloud アップデート情報 | セキュリティ (2026年10月5日〜2026年10月11日)

 2026.10.13  XIMIX Google Cloud チーム

はじめに

2026年10月5日〜11日の Google Cloud セキュリティカテゴリでは、Workforce Identity Federation の利用者のセッションと短期の認証情報を取り消す機能が一般提供(GA)になりました。GKE Sandbox の microVM サンドボックスと、VPC Flow Logs の TCP 接続ログも GA です。一方で、Security Command Center の Artifact guard with CI/CD integration は2026年10月30日に提供終了となることが告知されました。

本記事では、この期間の主なアップデート12件を、リリース日の昇順で解説します。Apigee hybrid のセキュリティ修正(脆弱性への対応)も取り上げます。

取り上げる範囲は、ID 管理(Identity and Access Management)、コンテナ基盤(Google Kubernetes Engine)、API 管理(Apigee hybrid)、リスク検出(Security Command Center)、セキュリティオペレーション(Google SecOps)、ネットワーク(Virtual Private Cloud、VPC Service Controls)、AI 保護(Model Armor)です。このうち4件は、提供終了や移行作業、バージョンの更新に関わる内容です。IT・セキュリティ担当者の方は自社の利用状況の確認に、経営層の方は移行計画の把握にお役立てください。

対象期間 2026年10月5日〜2026年10月11日
対象製品 Google Cloud
対象カテゴリ セキュリティ
アップデート件数 12件(主要トピック)

今回のアップデート一覧

2026年10月5日〜11日の Google Cloud セキュリティアップデート12件の一覧。Workforce Identity Federation のセッション取り消し、Artifact guard の廃止予定などを掲載

アップデート詳細

1. Google Kubernetes Engine — c4-standard マシンタイプで Confidential GKE Nodes(Intel TDX)を利用可能に(GA・2026年10月5日)

Confidential GKE Nodes(処理中のデータをメモリ上でも暗号化して保護する GKE のノード)で、c4-standard-* マシンタイプ(最大 192 vCPU)を Intel TDX(Intel の CPU が提供する、仮想マシンのメモリを隔離・暗号化する技術)とともに使う構成が一般提供(GA)になりました。

🔍 何が変わったのか

  • c4-standard-* マシンタイプ(最大 192 vCPU)を、Intel TDX を使う Confidential GKE Nodes として利用できるようになりました
  • 対応する構成(マシンタイプ、CPU、ゾーン)は、Confidential VM の「Supported configurations」ページに記載されています

💼 こんな場面で活用できます(ユースケース)

個人情報や機密性の高い業務データをコンテナで処理しているプラットフォーム担当者が対象です。保存時や通信時に加えて、処理中のデータも暗号化して扱いたいワークロードを、c4-standard の大きなマシンサイズで動かす選択肢が加わります。

✨ 導入メリット

  • 最大 192 vCPU のマシンタイプで、処理中のデータの保護と処理能力を両立する構成を選べます
  • GA になったことで、本番環境での採用を検討できます

📚 公式ソース

2. Google Kubernetes Engine — Identity Service for GKE の非推奨と GKE 1.37 以降での非サポート(2026年10月5日)

Identity Service for GKE(外部の ID プロバイダのアカウントで GKE クラスタに認証する機能)について、非推奨化の告知が掲載されました。2026年7月1日から GKE バージョン 1.36 以前で非推奨となっており、1.37 以降ではサポートされません。1.37 以降へアップグレードする前に、この機能を無効にして Workforce Identity Federation(外部の ID プロバイダの利用者に Google Cloud へのアクセスを許可する仕組み)へ移行するよう案内されています。

✨ 使えるようになる機能

  • 新機能の追加はありません。移行先として Workforce Identity Federation が案内されています
  • 公式ドキュメントでは、RoleBinding と ClusterRoleBinding を Workforce Identity Federation の識別子の形式に書き換える移行ツール(gke-identity-service-migrator)が紹介されています。手作業での書き換えも可能です

⚠️ 使えなくなる機能 / 変更点

  • 2026年7月1日から、GKE バージョン 1.36 以前で非推奨です。公式ドキュメントでは、これらのバージョンはサポート終了日まで引き続き動作すると説明されています
  • 2025年7月1日以降に作成された組織では、この機能を利用できません
  • GKE バージョン 1.37 以降はこの機能をサポートしません。公式ドキュメントによると、機能を有効にしたままのクラスタは、1.37 以降への自動・手動のアップグレードがブロックされます
  • 機能を有効にしたままマイナーバージョンがサポート終了を迎えると、GKE が自動でアップグレードし、認証が失敗すると説明されています
  • 対象は Google Cloud 上の GKE クラスタです。connect gateway と Google Distributed Cloud(ソフトウェアのみ)の GKE Identity Service は非推奨の対象外です

🤔 判断観点

  • 影響範囲: 自社の GKE クラスタで Identity Service for GKE を有効にしているかを確認する観点があります
  • スケジュール: 各クラスタのマイナーバージョンのサポート終了日と、1.37 以降へのアップグレード予定を照らし合わせる観点があります
  • 移行作業: 権限設定の書き換え、適用後に利用者が同じリソースへアクセスできるかの確認、古い設定の削除という手順を、どの環境から進めるかを検討する観点があります
  • 利用者への影響: クラスタにアクセスする開発者・運用者のログイン方法が変わるため、周知の範囲と時期を決める観点があります

📚 公式ソース

3. Google SecOps — Chronicle API を使う機能で Terraform とクライアントライブラリが利用可能に(2026年10月5日)

Google SecOps(ログを集約して脅威の検知・調査を行うセキュリティオペレーション基盤)で、Chronicle API を使う複数の機能について、Terraform プロバイダ(設定をコードで記述してリソースを作成・管理するツール向けの部品)と Google Cloud クライアントライブラリが利用可能になりました。リリースノートでは Spotlight Feature として紹介されています。

🔍 何が変わったのか

  • 対象の機能は、Feeds、Parsers、Rules、Findings Refinements、Retrohunts、Dashboards、Data Tables、Watchlists、Custom Lists、Environments、Environment Groups、Data Export、SOAR Domains、SOAR Networks です
  • Terraform プロバイダで、Google SecOps のリソースをコードとして作成・管理できます
  • クライアントライブラリで、開発者が使い慣れたプログラミング言語から独自の連携を作り、Google SecOps のワークフローを自動化できます

💼 こんな場面で活用できます(ユースケース)

検知ルールやログの取り込み設定を、複数の環境で同じ内容に保ちたい SecOps 管理者・セキュリティエンジニアが対象です。たとえばルールやフィードの設定をコードで管理すれば、変更の履歴を残し、検証環境と本番環境に同じ設定を展開できます。

✨ 導入メリット

  • 画面操作による設定作業を減らし、設定の再現性を高められます
  • 設定がコードとして残るため、担当者ごとの作業手順の違いによる属人化を抑えやすくなります
  • クライアントライブラリを使って、社内のシステムと Google SecOps の連携を組み立てられます

📚 公式ソース

4. Identity and Access Management — Workforce Identity Federation の利用者のセッション取り消しが GA(2026年10月6日)

Workforce Identity Federation の利用者(プリンシパル)について、すべてのクライアントにわたって、有効なセッションと短期の認証情報を取り消す機能が一般提供(GA)になりました。取り消しは gcloud CLI または REST API で行います。

🔍 何が変わったのか

  • 特定の利用者のセッションと短期の認証情報を取り消せるようになりました。公式ドキュメントでは、Google Cloud コンソールのセッション、セッション Cookie、短期の OAuth 2.0 アクセストークンなどが対象と説明されています
  • 取り消し後、利用者は ID プロバイダで再認証する必要があります。利用者のメタデータやリソースは削除されず、ID プロバイダ側で有効な利用者は再びログインできます
  • 取り消しは利用者(サブジェクト)単位で、対象の ID を指定して実行します
  • 実行には、Workforce Pool Admin ロール(roles/iam.workforcePoolAdmin)に含まれる iam.googleapis.com/workforcePoolSubjects.revokeSessions 権限が必要です

💼 こんな場面で活用できます(ユースケース)

公式ドキュメントでは、認証情報の漏えいが疑われる場合、退職や異動でアクセスを直ちに止める必要がある場合、ID プロバイダ側の権限やグループの変更を再認証によって反映させたい場合が挙げられています。ID 管理を担う IT 部門・セキュリティ担当者が、こうした場面で利用者のアクセスを止める手段として使えます。

✨ 導入メリット

  • 管理者の操作で、対象の利用者に直ちに再認証を求められます
  • 公式ドキュメントによると、ID の削除には30日間の論理削除の期間があります。この期間を待たずにアクセスを止められます

📚 公式ソース

5. Security Command Center — Artifact guard with CI/CD integration が非推奨、2026年10月30日に提供終了(2026年10月6日)

Security Command Center(クラウドのセキュリティリスクを一元的に管理する仕組み)の Artifact guard with CI/CD integration が非推奨になりました。2026年10月30日に提供終了となります。Artifact guard は、コンテナイメージの脆弱性を、ビルド時、レジストリへの保存中、実行中に、調整可能なポリシーと照らし合わせて検出・対処するサービスです。

✨ 使えるようになる機能

  • 新機能の追加はありません
  • リリースノートと Artifact guard の概要ページには、移行先となる代替機能の記載はありません

⚠️ 使えなくなる機能 / 変更点

  • Artifact guard with CI/CD integration は2026年10月30日に提供終了となります
  • Artifact guard の概要ページでは「Artifact guard and CI/CD integration will be shut down on October 30, 2026.」と、リリースノートとは異なる表記で案内されています
  • リリースノートに、既知の不具合・CVE 情報の記載はありません

🤔 判断観点

  • 影響範囲: 自社のビルドパイプラインやコンテナの運用で、Artifact guard をイメージの検査に組み込んでいるかを確認する観点があります
  • スケジュール: リリースノートの公開日(10月6日)から提供終了日(10月30日)までの期間を踏まえて、検査の仕組みの扱いを決める時期を検討する観点があります
  • 代替手段: 移行先は公式に示されていないため、イメージの脆弱性検査をどの仕組みで続けるかを、公式ドキュメントの更新も確認しながら検討する観点があります
  • 記録の更新: セキュリティ基準やパイプラインの設計書に Artifact guard を記載している場合、更新対象に含めるかを検討する観点があります

📚 公式ソース

6. Apigee hybrid — v1.14.9 で16コンポーネントのセキュリティ修正と外部通信の検証強化(2026年10月7日)

Apigee hybrid(API 管理サービス Apigee のランタイムを、利用者が管理する Kubernetes 環境で動かす形態)のセキュリティ修正が公開されました。Apigee hybrid のリリースノートでは、同日に v1.14.9 がリリースされ、16のコンポーネントで脆弱性が修正されたと記載されています。あわせて、クラスタ内部のホスト名への外部通信をブロックする動作の変更も含まれます。

✨ 使えるようになる機能

  • ポリシーで HTTP/2 リクエストの疑似ヘッダー(:path、:authority)を変更できるようになりました

⚠️ 使えなくなる機能 / 変更点

  • 修正対象のコンポーネントは、apigee-asm-ingress、apigee-asm-istiod、apigee-connect-agent、apigee-fluent-bit、apigee-hybrid-cassandra-client、apigee-kube-rbac-proxy、apigee-mart-server、apigee-mint-task-scheduler、apigee-open-telemetry-collector、apigee-operators、apigee-prom-prometheus、apigee-prometheus-adapter、apigee-runtime、apigee-synchronizer、apigee-udca、apigee-watcher の16件です
  • リリースノートに列挙された CVE(公開されている脆弱性の識別番号)は、複数のコンポーネントに重複して記載されたものを1件と数えると34件です。CVE-2025-46392 を除き、すべて CVE-2026 の番号です
  • リリースノートに、深刻度(重大度)の記載はありません。各 CVE の詳細は、リリースノートからリンクされている NVD(米国の脆弱性データベース)のページで確認できます
  • Message Processor から外部への HTTP 通信の検証が強化され、クラスタ内部のホスト名(*.svc.cluster.local)への送信がブロックされるようになりました
  • このほか、VerifyJWT の鍵キャッシュ、AssignMessage、分散トレース、apigee-connect-agent の接続維持に関する不具合が修正されています(セキュリティ以外の修正は計6件)
  • 廃止される機能や、既知の不具合の記載はありません

🤔 判断観点

  • 影響範囲: 自社で Apigee hybrid を運用しているか、運用中のバージョンと修正対象のコンポーネントを確認する観点があります。今回のリリースノートで告知されたバージョンは v1.14.9 です
  • 適用の手順: 公式のアップグレード手順は「Upgrading Apigee hybrid to version v1.14.9」に案内されています。リリースノートでは、Helm チャートでパッチをアップグレードするとイメージは自動で更新され、通常は手動でイメージを変更する必要はないと説明されています
  • 緊急度の判断: 深刻度が公式に示されていないため、NVD の各 CVE の内容と自社の利用コンポーネントを照らし合わせて、適用時期を判断する観点があります
  • ターゲット設定の確認: API プロキシのターゲットに、クラスタ内部のホスト名(*.svc.cluster.local)を指定していないかを確認する観点があります。指定している場合、アップグレード後に通信がブロックされる可能性があります
  • 検証: 本番環境に適用する前に、検証環境で API のトラフィックやモニタリングが従来どおり動作するかを確認する観点があります

📚 公式ソース

7. Google Kubernetes Engine — GKE Sandbox の microVM サンドボックスが GA(2026年10月7日)

GKE Sandbox(信頼できないコードを動かすコンテナを、ほかのワークロードから隔離する GKE の機能)で、microVM サンドボックスタイプが一般提供(GA)になりました。対象は GKE バージョン 1.37.0-gke.4713000 以降のクラスタです。

🔍 何が変わったのか

  • microVM サンドボックスは、ハードウェア仮想化による隔離を提供します。仕組みには Kata Containers と Cloud Hypervisor が使われ、標準的な Linux の機能を備えた完全な Linux カーネルを利用できます
  • 公式ドキュメントでは、従来の gVisor(ユーザー空間で Linux のシステムコールの一部を処理する方式)と比較されています。microVM は Pod ごとに専用のゲストカーネルを持つ一方、Pod あたり 250 mCPU・130 MiB の固定のオーバーヘッドがあり、起動には1〜2秒程度かかります
  • 制約として、GPU・TPU は使えず、hostNetwork を使う Pod はサポートされません。ノードではネストされた仮想化を有効にする必要があり、使えるマシンタイプが限られます

💼 こんな場面で活用できます(ユースケース)

リリースノートでは、信頼できないワークロード、AI エージェントの実行環境、マルチテナント環境が挙げられています。公式ドキュメントでは、生成したコードを人の監視なしに実行する AI エージェントや、完全な Linux カーネルを必要とするワークロードが例示されています。AI エージェントを社内で運用する開発チーム・プラットフォームチームが、実行環境を隔離する手段として使えます。

✨ 導入メリット

  • 信頼できないコードを、専用のカーネルを持つ環境に分けて動かせます
  • gVisor では対応しにくい、完全な Linux カーネルを前提とするワークロードも隔離の対象にできます
  • gVisor と microVM のどちらを使うかを、隔離の強さとオーバーヘッドの比較で選べます

📚 公式ソース

8. Google SecOps Marketplace — Google Chronicle 97.0 の同期処理の更新と、Gitsync 53.0 の Chronicle API 対応(2026年10月7日)

Google SecOps Marketplace(Google SecOps に連携機能を追加するマーケットプレイス)で、2つの連携機能が更新されました。このうち Gitsync 53.0 は REGRESSIVE と表示されており、既存の利用者は更新後にリポジトリのブランチの移行とコンテンツの再エクスポートが必要です。

✨ 使えるようになる機能

  • Google Chronicle 97.0: Google Chronicle Sync Job のアラート同期のロジックが更新されました
  • Gitsync 53.0: 最新の Chronicle API をサポートするよう更新されました

⚠️ 使えなくなる機能 / 変更点

  • Gitsync 53.0 は REGRESSIVE と表示されています。既存の利用者は、更新後にリポジトリのブランチを移行し、コンテンツを再エクスポートする必要があります
  • 移行の手順は、Gitsync のドキュメントの「Chronicle API-enabled environment migration」に案内されています
  • リリースノートに、既知の不具合・CVE 情報の記載はありません

🤔 判断観点

  • 影響範囲: 自社で Gitsync を使って、プレイブックなどのコンテンツを Git リポジトリで管理しているかを確認する観点があります
  • 作業の計画: 更新とブランチの移行、再エクスポートをひと続きの作業として、実施する時間帯と担当者を決める観点があります
  • 検証: Google Chronicle 97.0 の更新後、アラートの同期が想定どおりに行われているかを確認する観点があります

📚 公式ソース

9. Virtual Private Cloud — VPC Flow Logs の TCP 接続ログが GA(2026年10月7日)

VPC Flow Logs(仮想ネットワーク上の通信を記録する機能)で、TCP 接続ログ(connection logging)が一般提供(GA)になりました。対象は VM インスタンスとサーバーレスのエンドポイントです。

🔍 何が変わったのか

  • 外向きの TCP 接続の試行と、受信した接続要求に応答(SYN-ACK)を返した内向きの TCP 接続を記録できます
  • 設定の単位は、サブネット(Network Management API を利用)、VPC ネットワーク、組織の3つです
  • 公式ドキュメントでは、通常のサンプリングでは短時間・少量の TCP 接続を取りこぼすことがあり、この機能はそれを補うものと説明されています
  • 記録の上限は vCPU あたり毎秒100接続、VM あたり毎秒800接続で、上限を超えた接続は記録されない場合があります

💼 こんな場面で活用できます(ユースケース)

不審な通信の調査や、ネットワークの利用状況の監査を担うセキュリティ・ネットワーク担当者が対象です。VM やサーバーレスのサービスがどこへ接続しようとしたかを、短い接続も含めて記録に残せます。

✨ 導入メリット

  • サンプリングで漏れやすい短時間の接続も記録できるため、通信の調査で手がかりを得やすくなります
  • 組織単位で設定できるため、プロジェクトごとの設定漏れを減らせます
  • GA になったことで、本番環境の監視に組み込むことを検討できます

📚 公式ソース

10. VPC Service Controls — 違反アナライザーで修正案を提示(Preview・2026年10月8日)

VPC Service Controls(Google Cloud のサービスの周囲に「サービス境界」を設け、データの持ち出しを防ぐ仕組み)の違反アナライザー(violation analyzer、アクセス拒否の原因を調べる画面)で、修正案(remediation suggestions)を自動で提示する機能が Preview として提供されました。

🔍 何が変わったのか

  • アクセス拒否のイベントを分析し、拒否を解消するための、範囲を絞った設定変更案を作成します。最小権限の原則(必要な権限だけを与える考え方)に沿う形で提案されます
  • 提案の対象は、ingress ルール、egress ルール、VPC からアクセスできるサービスの設定、既存または新規のアクセスレベルです
  • 公式ドキュメントでは、提案は自動では適用されず、内容を確認したうえで「Apply remediation」を選んで適用すると説明されています
  • ログの保持期間(既定で30日)を過ぎたイベントは分析できません。コンソールでは組織レベルでのみ利用できます

💼 こんな場面で活用できます(ユースケース)

サービス境界を運用していて、利用者から「アクセスが拒否された」と問い合わせを受けるクラウド管理者・セキュリティ担当者が対象です。拒否の原因を調べ、ルールを書き起こす作業の出発点として、提案された設定変更案を使えます。

✨ 導入メリット

  • ルールを一から書く手間を減らし、アクセス拒否の解消にかかる時間を短くできます
  • 範囲を絞った変更が提案されるため、必要以上にアクセスを広げる設定を避けやすくなります
  • 提案は確認後に適用する形のため、変更の可否を担当者が判断できます

📚 公式ソース

11. Model Armor — Workspace データ向けのプロンプトインジェクション・ジェイルブレイク検出を強化(2026年10月9日)

Model Armor(生成 AI モデルへの悪意ある入力や望ましくない出力からの保護を担う仕組み)で、Workspace のデータを対象とするプロンプトインジェクション(AI への指示を不正に書き換えようとする入力)とジェイルブレイク(AI の安全上の制限を回避させようとする入力)の検出が強化されました。

🔍 何が変わったのか

  • メール、ドキュメント、ファイルなどの Workspace のコンテンツを検査する際に、検出の精度が上がり、誤検知が減ると説明されています
  • 利用できるのは、米国(us)と EU(eu)のマルチリージョンのエンドポイントです
  • テンプレートとフロア設定で、フィルタのバージョンを v3 以降(Stable、Latest のエイリアスを含む)に設定している場合に適用されます

💼 こんな場面で活用できます(ユースケース)

社内のメールや共有ドキュメントを生成 AI に読み込ませるアプリケーションを開発・運用している担当者が対象です。メールや文書の中に、AI への指示を書き換えようとする文が紛れ込んでいる場合に備えて、検査の仕組みを用意できます。

✨ 導入メリット

  • Workspace のコンテンツを扱う生成 AI アプリケーションで、攻撃的な入力を検出しやすくなります
  • 誤検知が減るため、正当な文書の処理が止められる場面を減らせます

📚 公式ソース

12. Security Command Center — 保持期間による検出結果の削除を Pub/Sub と BigQuery に通知(2026年10月9日)

Security Command Center で、データの保持ポリシーによって検出結果(finding)が削除されたときに、Pub/Sub(メッセージを配信するサービス)と BigQuery(データ分析基盤)への継続エクスポートで通知を受け取れるようになりました。設定には gcloud CLI、securitycenter REST API、クライアントライブラリを使います。

🔍 何が変わったのか

  • 保持ポリシーによる検出結果の削除が、Pub/Sub の通知と BigQuery への継続エクスポートの対象になりました
  • 設定方法は、通知の設定と BigQuery へのエクスポートに関する既存のガイドに案内されています

💼 こんな場面で活用できます(ユースケース)

Security Command Center の検出結果を、Pub/Sub 経由で外部のチケット管理システムに連携したり、BigQuery に蓄積して分析したりしているセキュリティ運用担当者が対象です。Security Command Center 側で検出結果が削除されたことを、連携先でも把握できます。

✨ 導入メリット

  • Security Command Center と連携先で、検出結果の状態を揃えやすくなります
  • BigQuery に蓄積した検出結果の分析で、削除された検出結果を区別できます

📚 公式ソース

まとめ

2026年10月5日〜11日のセキュリティカテゴリでは、Workforce Identity Federation の利用者のセッション取り消しが一般提供(GA)になり、認証情報の漏えいが疑われる場面や退職・異動の際に、管理者の操作ですぐに再認証を求められるようになりました。GKE Sandbox の microVM サンドボックスと VPC Flow Logs の TCP 接続ログも GA となり、AI エージェントの実行環境の隔離や通信の調査に使える選択肢が増えています。VPC Service Controls の修正案の提示(Preview)は、アクセス拒否への対応の手間を減らす機能です。

運用中の環境に関わる項目もあります。Artifact guard with CI/CD integration は2026年10月30日に提供終了となり、Identity Service for GKE を有効にしたクラスタは GKE 1.37 以降へアップグレードできません。Gitsync 53.0 は更新後に移行作業が必要で、Apigee hybrid は v1.14.9 でセキュリティ修正が提供され、クラスタ内部のホスト名(*.svc.cluster.local)への外部通信がブロックされるようになりました。該当する機能を使っているかを確認するところから、公式ドキュメントをもとに進めていただければと思います。

関連 XIMIX 記事

Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。

XIMIX からのご案内

XIMIX(サイミクス)は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、セキュリティ強化、データ活用などをご支援しています。本記事で取り上げた Identity and Access Management や Google Kubernetes Engine、Security Command Center などの活用にご関心がありましたら、お気軽にご相談ください。

参考資料

執筆者紹介

XIMIX Google Cloud チーム
XIMIX Google Cloud チーム
監修:増谷 謙介(クラウドインテグレーション部 テクニカルエキスパート)。2018年よりGoogle Cloudビジネスに携わり、営業からマーケティング、ビジネス立ち上げまで幅広い業務を通じてGoogle Cloudの導入・活用を推進。Google Cloud専業パートナー、コンサル系パートナー企業を経て現職。Google Cloud Partner Tech Influencer Challenge 2025受賞。Google Cloud Next Tokyo 2025に登壇(ITmedia掲載)。保有資格はGoogle Cloud Digital Leader、生成AIパスポート、情報セキュリティマネジメント、GAIQ、Google教育者レベル1など。

BACK TO LIST

   

Recent post最新記事

Popular post人気記事ランキング

Contentsコンテンツ