はじめに
クラウドのセキュリティ運用は、脆弱性への対応、アクセス権限（IAM）の点検、認証基盤の統合、機密データの保護、そしてインシデント対応の自動化まで、幅広い領域にまたがります。2026年8月31日〜9月6日の期間は、Cloud Service Mesh の脆弱性対応やバージョンのサポート終了、IAM 構成を AI から分析できる Policy Analyzer MCP サーバーの一般提供（GA）、Google SecOps のインシデント対応機能の拡充などが発表されました。
本記事では、この期間に発表された Google Cloud セキュリティカテゴリの主要アップデートを10トピックに整理し、リリース日の昇順で解説します。サービスメッシュの脆弱性対応（Cloud Service Mesh）、権限分析（Policy Intelligence）、認証統合（Cloud SQL）、機密コンピューティング（Confidential VM / Confidential GKE Nodes）、境界セキュリティ（VPC Service Controls）、セキュリティオペレーション（Google SecOps / SecOps SOAR）まで、セキュリティ担当者・IT 部門が把握しておきたい内容を取り上げます。
特に Cloud Service Mesh のセキュリティ速報 GCP-2026-057 に対応するマネージド構成の自動更新、in-cluster 構成 1.27 系のサポート終了、Policy Analyzer MCP サーバーの GA、Google SecOps の Case playbooks / Reaction triggers（Preview）は、自社環境への影響や適用方針を検討したい内容です。経営層はリスク低減とガバナンス強化の観点から、IT 担当者は適用判断の観点から読み進めていただくと役立ちます。
| 対象期間 |
2026年8月31日〜2026年9月6日 |
| 対象製品 |
Google Cloud |
| 対象カテゴリ |
セキュリティ |
| アップデート件数 |
10件（主要トピック） |
今回のアップデート一覧
アップデート詳細
1. Cloud Service Mesh — in-cluster 構成に 1.30.4-asm.1 が登場、1.27 系はサポート終了
Cloud Service Mesh（サービス間の通信を管理する仕組み。Istio ベースのサービスメッシュ）で、自分でクラスタ内にインストールする in-cluster 構成向けに 1.30.4-asm.1 が利用可能になりました（2026年8月31日）。同じ日に、in-cluster 構成の 1.27 系のサポートが終了したことも案内されています。バージョンの適用判断が必要な内容のため、以下に整理します。
✨ 使えるようになる機能
- in-cluster 構成向けに 1.30.4-asm.1 が利用可能になりました。Istio 1.30.4 の機能を含みます（Cloud Service Mesh がサポートする機能の範囲内という条件付きで案内されています）
- 公式の「サポート対象バージョン」では、1.30 のリリース日が2026年8月31日、最も早い EOL（サポート終了）日が2027年5月31日として掲載されています
- あわせて 1.29（最も早い EOL 日 2027年3月9日）、1.28（同 2026年10月19日）がサポート対象として掲載されています
⚠️ 使えなくなる機能 / 変更点
- 1.30.4-asm.1 では次の機能がサポート対象外と明記されています: DNS クラスタに対する Failover Priority のサポート、ENABLE_WILDCARD_HOST_SERVICE_ENTRIES_FOR_TLS、1 ワークロードあたり複数の CUSTOM 外部認可プロバイダ、DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES フラグ。これらを現在利用している場合は、アップグレード前に代替構成を検討する必要があります
- in-cluster 構成の 1.27 系はサポート対象外になりました（サポート対象外となった日付として2026年8月31日が記載されています）
- 自分でインストールする in-cluster 構成については、Google は現行バージョンと直前2つのマイナーバージョン（n-2）をサポートするモデルが案内されています
- サポート対象外のバージョンを利用している場合、公式ドキュメントでは 1.28 以降へのアップグレードが案内されています
🤔 判断観点
- 緊急性: 1.27 系はサポート対象外となったため、今後の公式サポートの対象範囲がどう変わるかを踏まえて移行時期を検討する観点があります
- 影響範囲: 対象は in-cluster 構成のクラスタです。Google がマネージドで運用する構成（Managed Cloud Service Mesh）は、この告知とは別の更新サイクルで扱われます
- 検証推奨事項: Istio 1.30.4 相当へ上げる場合、既存のトラフィックポリシー・認可ポリシー・可観測性設定が想定どおり動作するかを検証環境で確認する観点があります
- ダウンタイム想定: アップグレードは公式の「Upgrade Cloud Service Mesh」の手順に沿った作業となり、プロキシの再起動を伴う計画を想定する観点があります
- ロールアウト戦略: 開発・ステージング環境で先行適用してから本番へ広げるか、メンテナンス時間帯に一括で適用するかを検討する観点があります
📚 公式ソース
2. Managed Cloud Service Mesh — Gateway API 向けの新プロキシで脆弱性を修正（GCP-2026-057）
Managed Cloud Service Mesh（Google がマネージドで提供するサービスメッシュ）で、Google Kubernetes Engine（GKE）クラスタ上の Gateway API 向けに新しいプロキシバージョン csm_mesh_proxy.20260819_RC00（Envoy 1.37 相当）の使用が開始されました（2026年9月1日、セキュリティ関連の発表）。すべてのリリースチャネルへ順次展開され、セキュリティ速報 GCP-2026-057 に記載された脆弱性の修正を含みます。対応の要否を判断する必要がある内容のため、以下に整理します。
✨ 使えるようになる機能
- GKE クラスタ上の Gateway API 向けに、新しいプロキシバージョン csm_mesh_proxy.20260819_RC00 の使用が開始されました（Envoy 1.37 に相当します）
- このプロキシバージョンは、すべてのリリースチャネルへ順次展開されます
- セキュリティ速報 GCP-2026-057 に記載された脆弱性の修正を含みます。公式リリースノートで新機能としてハイライトされた項目はなく、脆弱性修正が中心の更新です
⚠️ 使えなくなる機能 / 変更点
セキュリティ速報 GCP-2026-057（公開日: 2026年8月26日）では、13件の CVE（High 7件・Moderate 6件）が公開されています。速報では、HTTP/2 のレスポンス処理、RBAC ポリシーの適用、QUIC の実装、認可バイパス、管理用ステータス画面のクロスサイトスクリプティングといった領域に関わる脆弱性が挙げられており、影響範囲については「すべての Cloud Service Mesh バージョンが影響を受ける」と記載されています。速報に掲載されている CVE と深刻度は次のとおりです。
| 深刻度 |
CVE |
| High（7件） |
CVE-2026-73512、CVE-2026-73513、CVE-2026-73547、CVE-2026-73548、CVE-2026-73550、CVE-2026-73552、CVE-2026-73553 |
| Moderate（6件） |
CVE-2026-48521、CVE-2026-50572、CVE-2026-73511、CVE-2026-73546、CVE-2026-73549、CVE-2026-73551 |
対応の要否は、利用している構成によって案内が異なります。速報の「What should I do?」では、マネージド構成（Managed Cloud Service Mesh）については「すべてのバージョンがサポート対象のままであり、今後数週間かけて自動的に更新される」と記載されています。つまり、マネージド構成の利用者に対してバージョンを手動で上げる作業は求められていません（速報では、あわせて MSA の手順に従うことが案内されています）。一方、自分でインストールする in-cluster 構成については、パッチ適用済みバージョン（1.29.7-asm.2 / 1.28.10-asm.24 / 1.27.9-asm.34）へのアップグレードが緩和策として案内されており、1.26 以前を利用している場合は「サポート終了（EOL）に達しているため 1.27 以降へアップグレードする」と記載されています。
🤔 判断観点
- 顧客対応の要否: マネージド構成については、速報どおり Google 側で自動的に更新されるため、利用者側でのバージョンアップ作業は案内されていません。一方 in-cluster 構成を併用している場合は、パッチ適用済みバージョンの適用状況を確認する観点があります
- 影響範囲: 今回の新プロキシ展開は、GKE クラスタ上で Gateway API を利用するマネージド構成が対象です。速報自体は「すべてのバージョンが影響を受ける」としているため、自社の構成（マネージド / in-cluster）の棚卸しが出発点になります
- 優先度の見極め: 認可バイパスなどアクセス制御に関わる脆弱性が含まれるため、外部公開しているゲートウェイの有無や取り扱うデータの機密度に応じて、確認の優先度を決める観点があります
- 検証推奨事項: プロキシが Envoy 1.37 相当へ更新されるため、展開後にサービス間通信の挙動や可観測性の指標へ想定外の変化がないかを監視する観点があります
- ロールアウト戦略: すべてのリリースチャネルへ順次展開されるため、自社クラスタが属するチャネル設定が検証方針（先行検証を重視するか、安定性を重視するか）に合っているかを確認する観点があります
📚 公式ソース
3. Policy Intelligence — Policy Analyzer MCP サーバーが一般提供（GA）
Policy Intelligence（アクセス権限の分析・可視化を担う機能群）で、Policy Analyzer MCP サーバーが一般提供（GA）になりました（2026年9月1日）。MCP（Model Context Protocol）は、AI アプリケーションやエージェントを外部のツール・データに接続するための標準的な仕組みです。これにより、AI エージェントや AI アプリケーションから IAM（Identity and Access Management: 誰に何を許可するかを管理する仕組み）の構成を分析・監査できるようになります。
🔍 何が変わったのか
- Google のインフラ上で動作するリモート MCP サーバーとして提供され、AI アプリケーションやエージェント（Gemini CLI、Claude、ChatGPT、独自アプリケーションなど）から利用できます
- IAM の許可ポリシーを分析し、「誰がどのリソースにアクセスできるか」を調べるツールが提供されます。グループのメンバーを展開して確認することもできます
- 分析結果を BigQuery のデータセットや Cloud Storage のバケットへエクスポートできます
- 利用にあたっては、Policy Analyzer API の有効化、OAuth 2.0 による認証（API キーは利用できません）、および Cloud Asset Viewer や MCP Tool User などの IAM ロールが必要と案内されています
- 公式ドキュメントには注意点として、Model Armor をログ記録付きで有効化した場合にペイロード全体がログに記録される点、および Model Armor のクロス管轄ルーティングがデータレジデンシー（データ所在地）に関する要件へ影響する可能性がある点が記載されています
💼 こんな場面で活用できます（ユースケース）
権限管理・内部監査を担う IT 部門やセキュリティ担当者が対象です。たとえば「特定プロジェクトの BigQuery データセットを削除できるのは誰か」といった問いを、コンソールを何画面もたどるのではなく、AI エージェントへの自然な指示として投げかけ、結果をレポートとして受け取る使い方が公式ドキュメントで示されています。棚卸し結果を BigQuery へ出力すれば、定期的な権限レビューの資料づくりにも活かせます。
✨ 導入メリット
- 権限の調査を対話的に進められるため、監査対応や棚卸しにかかる手作業を減らせます
- 調査手順が特定の担当者の記憶や勘に依存しにくくなり、属人化の解消に寄与します
- 分析結果を BigQuery / Cloud Storage へ蓄積でき、権限の変化を継続的に追跡するガバナンス強化に役立ちます
📚 公式ソース
4. Cloud SQL for MySQL / PostgreSQL — Workforce Identity Federation 認証をサポート
Cloud SQL for MySQL および Cloud SQL for PostgreSQL（Google Cloud のマネージドリレーショナルデータベース）で、Workforce Identity Federation（社内の ID 基盤と Google Cloud を連携させる仕組み）による認証がサポートされました（2026年9月2日）。Microsoft Active Directory や Okta といった外部の ID プロバイダの ID を使って、Cloud SQL インスタンスへ認証できます。
🔍 何が変わったのか
- workforce プール（社内 ID をまとめた単位）に属するプリンシパル（利用者）が、そのまま Cloud SQL インスタンスへ接続できるようになりました
- データベースユーザーの種別として CLOUD_IAM_WORKFORCE_IDENTITY が用いられ、ログイン時に外部 ID の資格情報とプロジェクトレベルの IAM 権限が検証されます
- 接続方法として、gcloud CLI で発行したログイントークンを使う方法、または Cloud SQL Auth Proxy を --auto-iam-authn オプション付きで使う方法が案内されています
- MySQL の場合は MySQL 8.0 以降が必要で、事前に workforce identity federation のプールとプロバイダを構成しておく必要があります
- 公式ドキュメントには制限として、異なる workforce プール間で同一のユーザー ID を区別できない点、およびインスタンスごとに毎分12,000ログインのクォータがある点が記載されています
💼 こんな場面で活用できます（ユースケース）
すでに Microsoft Active Directory や Okta を全社の ID 基盤として運用している企業の IT 部門・データベース管理者が対象です。従来、データベースへのアクセスのために別途ユーザーを作成・管理していた運用を、既存の ID 基盤に寄せられます。入退社や異動の際も、ID 基盤側の停止・変更がデータベースアクセスへ反映される運用に近づけられます。
✨ 導入メリット
- データベース専用のアカウントを個別に増やさずに済み、ID 管理の運用負荷を抑えられます
- 退職者アカウントの棚卸し漏れといったリスクを減らしやすく、セキュリティ強化に寄与します
- 全社の認証ポリシー（多要素認証など ID プロバイダ側の制御）をデータベースアクセスにも活かせます
📚 公式ソース
5. Confidential VM — ローカル SSD 付き C3 マシンタイプで Intel TDX が GA
Confidential VM（機密コンピューティング向けの仮想マシン）で、c3-standard-*-lssd マシンタイプにおける Intel TDX のサポートが一般提供（GA）になりました（2026年9月2日）。Intel TDX（Trust Domain Extensions）は、仮想マシンが処理中のデータ（メモリ上のデータ）を保護する仕組みで、Confidential VM の基盤技術として提供されています。lssd はローカル SSD が付属するマシンタイプを指します。
🔍 何が変わったのか
- ローカル SSD が付属する c3-standard-*-lssd マシンタイプで、Intel TDX を用いた Confidential VM を一般提供（GA）として利用できます
- 対応するマシンタイプや構成の詳細は、公式の「Supported configurations」で確認できます
💼 こんな場面で活用できます（ユースケース）
個人情報や機微な取引データを扱う業務システムを、クラウド上で稼働させたいインフラ・セキュリティ担当者が対象です。処理中のデータ保護（機密コンピューティング）を要件としながら、同時にローカル SSD の高速なディスク性能を必要とするワークロード（大量データの一時展開を伴う処理など）で、選択できる構成が広がります。
✨ 導入メリット
- データ保護要件と性能要件の両立が図りやすくなり、対象ワークロードの選択肢が広がります
- 一般提供（GA）として提供されるため、本番環境での採用を検討しやすくなります
- 機密性の高いデータを扱う業務のクラウド移行を進めるうえでの検討材料が増えます
📚 公式ソース
6. Google Kubernetes Engine — Confidential GKE Nodes でも同マシンタイプが GA
Google Kubernetes Engine（GKE: マネージド Kubernetes サービス）で、c3-standard-*-lssd マシンタイプを Intel TDX 対応の Confidential GKE Nodes として利用できるようになりました（2026年9月3日、一般提供）。Confidential GKE Nodes は、コンテナを動かすノード（サーバー）自体を機密コンピューティング環境として構成する仕組みです。
🔍 何が変わったのか
- Intel TDX 対応の Confidential GKE Nodes として、c3-standard-*-lssd マシンタイプが一般提供（GA）で利用できます
- 構成方法や対応状況は、公式の「Confidential GKE Nodes」ドキュメントで確認できます
💼 こんな場面で活用できます（ユースケース）
コンテナ基盤上で機密データを扱うアプリケーションを運用する開発チーム・プラットフォーム担当者が対象です。前項の Confidential VM と同じマシンタイプが GKE のノードとしても選べるようになるため、仮想マシン中心の環境とコンテナ中心の環境で、機密コンピューティングの構成方針を揃えやすくなります。
✨ 導入メリット
- コンテナ基盤でも処理中データの保護を前提とした構成を選べ、対象業務の幅が広がります
- 仮想マシンとコンテナで同系統のマシンタイプを利用でき、標準化・設計の簡素化に寄与します
- ローカル SSD を活かした性能要件と機密性要件を、同じノード構成の中で検討できます
📚 公式ソース
7. Google SecOps / SecOps SIEM — Bindplane Enterprise ライセンスのセルフサービス取得（Preview）
セキュリティオペレーション基盤 Google SecOps および Google SecOps SIEM（ログを集約して脅威を検知する仕組み）で、Bindplane Enterprise（Google Edition）のライセンスキーをセルフサービスでダウンロードできる機能が Preview 段階で提供されました（2026年9月3日）。Bindplane は、各種システムのログを収集して SecOps へ取り込むためのエージェント（収集ソフト）です。
🔍 何が変わったのか
- ライセンスキーを、プラットフォームのコンソールから直接ダウンロードできるようになりました（画面の SIEM Settings > Collection Agents から取得します）
- 対象は Google Security Operations Enterprise Plus および Google Unified Security（GUS）のご契約者です
- Preview 段階として、米国および EU リージョンのテナントが対象と案内されています
💼 こんな場面で活用できます（ユースケース）
ログ収集基盤の構築・拡張を担う SecOps エンジニアや IT 運用担当者が対象です。新しいサーバー群や拠点からのログ収集を始める際、ライセンスキーの入手を待つ工程が挟まると着手が遅れます。管理画面から自分で取得できれば、エージェントの展開作業をその場で進められます。
✨ 導入メリット
- ライセンス取得の待ち時間を減らし、ログ収集基盤の立ち上げスピードを高められます
- 問い合わせベースのやり取りが減り、運用チームの手間を抑えられます
- 取り込み対象を広げやすくなることで、監視の網羅性向上に寄与します
📚 公式ソース
8. VPC Service Controls — 削除済み IAM プリンシパルを含む境界の管理をサポート（Preview）
VPC Service Controls（データの外部持ち出しを防ぐための境界セキュリティ機能）で、削除済みの IAM プリンシパル（すでに削除されたユーザー・グループ・サービスアカウント）を含むサービス境界の取得・更新が Preview 段階でサポートされました（2026年9月3日）。従来はこうした境界を操作すると「メールアドレスが無効または存在しない」というエラーで失敗していましたが、その事象を回避して管理を継続できます。
🔍 何が変わったのか
- Access Context Manager API で deletedPrincipalSyntax パラメータを DELETED_PRINCIPAL_SYNTAX_SUPPORT_ENABLED に設定することで、削除済みプリンシパルを含む境界を取得・更新できます
- 既定の動作では、削除済みアカウントを含む境界への操作は「The email address is invalid or non-existent」というエラーで失敗すると記載されています
- 公式ドキュメントに記載された制限として、対応するのは IAM の v1 API の削除済みプリンシパルのみ（v2・v3 は対象外）であること、削除済みプリンシパルをアクセスレベルに使用できないこと、1つのアクセスポリシーあたり削除済み ID は最大500件であること、およびコンソールや gcloud CLI ではなく REST / gRPC API から操作する必要があることが挙げられています
💼 こんな場面で活用できます（ユースケース）
サービス境界を設計・運用するセキュリティ担当者・クラウド管理者が対象です。組織の統廃合や退職に伴ってアカウントを削除した後、その ID が境界の設定に残ってしまい、境界の更新作業自体が止まってしまうことがあります。この機能を使えば、まず境界を取得・更新できる状態にしてから、不要になった ID を整理する運用が可能になります。
✨ 導入メリット
- 削除済み ID が原因で境界の更新が止まる事象を避けられ、境界ポリシーの保守を継続できます
- 不要な ID を計画的に棚卸ししやすくなり、境界設定の見通しがよくなります
- 境界の運用が止まらないことで、データ漏えい防止の統制を維持しやすくなります
📚 公式ソース
9. Firestore — Security Rules のシミュレータが Google Cloud コンソールで利用可能
Firestore（サーバーレスのドキュメントデータベース）の Security Rules（データへのアクセス可否を定義するルール）について、シミュレータ機能が Google Cloud コンソールで利用できるようになりました（2026年9月4日）。ドラフト（下書き）状態のルールを、シミュレートしたデータベースリクエストに対してテストでき、認証トークンの内容もデプロイ前に評価できます。
🔍 何が変わったのか
- ドラフトのセキュリティルールを、デプロイ前にシミュレートしたリクエストへ適用してテストできます
- シミュレーションの種類として get / create / update / delete を選択し、対象ドキュメントの場所を指定してテストできます。任意でモックのドキュメントデータや認証情報も設定できます
- 評価結果はルールエディタ上で該当行がハイライトされる形で確認できます
- ルールエディタとシミュレータは、Native モードの Firestore の Standard エディションと Enterprise エディションの双方で利用できます
- 公式ドキュメントには制限として、Google Cloud コンソールからは (default) データベースへのセキュリティルールのデプロイに対応していない（その場合は Firebase コンソールまたは Firebase CLI を使用する）ことが記載されています
💼 こんな場面で活用できます（ユースケース）
モバイルアプリや Web アプリのバックエンドに Firestore を使う開発チーム、およびアクセス制御をレビューするセキュリティ担当者が対象です。「この条件のユーザーは、このドキュメントを更新できてしまうのか」といった懸念を、実際の本番データや稼働中アプリを使わずに確認できます。ルール変更のレビュー時に、想定どおりの許可・拒否になっているかを画面上で示せる点も実務的です。
✨ 導入メリット
- デプロイ前に検証できるため、アクセス制御の設定ミスによる情報公開リスクの低減に寄与します
- テスト作業を画面上で完結でき、ルール改修のスピードと品質を両立しやすくなります
- 許可・拒否の根拠が可視化され、レビューや監査での説明がしやすくなります
📚 公式ソース
10. Google SecOps / SecOps SOAR — Case playbooks と Reaction triggers が Preview で登場
Google SecOps および Google SecOps SOAR（セキュリティ対応の自動化・オーケストレーション基盤）で、Case playbooks と Reaction triggers の2つの機能が Preview 段階で提供されました（2026年9月6日、スポットライト機能）。プレイブックとは、インシデント対応の手順を自動化した処理の流れを指します。あわせて同日、Release 6.3.100 が最初のフェーズのリージョンへロールアウトを開始したことも案内されています。
🔍 何が変わったのか
- Case playbooks（Preview）: 個々のアラート単位ではなく、ケース（関連するアラートをまとめた調査の単位）全体に対してプレイブックの実行や手動アクションの実行ができます。調査時の対応タスクを一本化し、重複作業を削減できると案内されています
- Reaction triggers（Preview）: ケースやアラートのリアルタイムな更新に応じてプレイブックを自動的に発火させる post-ingestion トリガー（取り込み後に作用するトリガー）です。担当者の変更、ケースタグの更新、アラート優先度の変化、新規エンティティの追加などが契機になります
- これらは Release 6.3.100 で提供され、同リリースは最初のフェーズのリージョンからロールアウトが開始されています。リリース内容としては、内部および顧客から報告されたバグの修正が含まれると記載されています
💼 こんな場面で活用できます（ユースケース）
SOC（セキュリティ監視チーム）やインシデント対応担当者が対象です。1つの侵害の疑いに対して複数のアラートが上がる状況では、アラートごとに同じ確認作業を繰り返しがちです。Case playbooks を使えば、ケース単位でまとめて対応を進められます。また Reaction triggers により、「優先度が上がったら自動で追加調査を走らせる」「担当者が変わったら関係者へ通知する」といった運用を、人の操作を待たずに動かせます。
✨ 導入メリット
- ケース単位での対応により重複作業を減らし、インシデント対応のスピード向上に寄与します
- 状況変化を契機とした自動化により、対応の抜け漏れを抑えやすくなります
- 対応手順がプレイブックとして共有され、担当者ごとの対応品質のばらつき（属人化）の解消に役立ちます
🤔 判断観点
- 提供段階: いずれも Preview 段階の機能です。本番運用の主要フローへ組み込むか、まず限定的なケース種別で試すかを検討する観点があります
- 影響範囲: Release 6.3.100 は最初のフェーズのリージョンから順次展開されるため、自社テナントのリージョンで利用可能になる時期を確認する観点があります
- 検証推奨事項: Reaction triggers は更新を契機に自動実行されるため、既存プレイブックとの重複発火や通知量への影響を、限定的な条件で確認する観点があります
📚 公式ソース
その他のアップデート
上記の主要トピック以外にも、この期間には不正防止 SDK の更新や、Google SecOps の検知ルール運用・連携（統合）に関するアップデートが発表されています。自組織の利用状況に応じてご確認ください。
まとめ
2026年8月31日〜9月6日のセキュリティカテゴリは、脆弱性対応・権限分析・認証統合・機密コンピューティング・インシデント対応の自動化という各領域で選択肢が広がりました。とりわけ Policy Analyzer MCP サーバーの一般提供（GA）は、「誰が何にアクセスできるか」という権限の可視化を AI エージェント経由で進められる点で、監査対応や定期レビューの進め方に影響しうるアップデートです。
また、Cloud SQL の Workforce Identity Federation 認証や Confidential VM / Confidential GKE Nodes の対応マシンタイプ拡大、Firestore の Security Rules シミュレータは、既存の ID 基盤やデータ保護要件に沿った構成を組みやすくします。一方で、Cloud Service Mesh の in-cluster 1.27 系のサポート終了や セキュリティ速報 GCP-2026-057 のように、自社の構成を確認しておきたい変更点もあります。なお速報では、マネージド構成については自動的に更新されるとされており、利用者側での手動アップグレードは案内されていません。公式ドキュメントをもとに、自社構成に応じた対応の要否をご確認ください。
関連 XIMIX 記事
Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。
XIMIX からのご案内
XIMIX（サイミクス）は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、セキュリティ強化、データ活用などをご支援しています。本記事で取り上げた Policy Intelligence や Google SecOps、VPC Service Controls、Cloud Service Mesh などの活用にご関心がありましたら、お気軽にご相談ください。
お問い合わせはこちら
参考資料