はじめに
セキュリティの機能追加は、ID 連携、鍵管理、ネットワーク保護、AI 保護といった別々の領域で並行して進みます。2026年9月21日〜9月27日の Google Cloud セキュリティカテゴリも、扱う領域が週のなかで分かれていました。外部の ID 基盤と Looker をつなぐ仕組み、外部鍵の移行、機密コンピューティングの対応マシンタイプの拡大、AI 保護の検出カテゴリ名の変更などが並んでいます。
本記事では、この期間に公開されたリリースノート13件のうち、内容が同一の2件を1つにまとめ、12のトピックに整理して解説します。なお、製品ごとに個別公開されるセキュリティ速報（Security Bulletin）は本記事の対象外です。
取り上げる範囲は、ID・アクセス管理（Access Context Manager / Identity and Access Management / API Keys API）、セキュリティオペレーション（Google SecOps / Google SecOps SIEM / Google SecOps SOAR）、ネットワーク保護（Cloud NGFW）、資産管理（Cloud Asset Inventory）、鍵管理（Cloud Key Management Service / Certificate Manager）、機密コンピューティング（Confidential VM）、AI 保護（Model Armor / Security Command Center）です。リリース日の昇順で並べています。
このうち、Security Command Center の検出カテゴリ名の変更と、Google SecOps SOAR のリリース 6.3.100 の全リージョン提供開始は、自社の設定や運用フローによって確認が必要になりうる内容です。経営層の方には投資判断とリスク管理に、IT・セキュリティ担当者の方には適用判断と検証計画に関わります。
| 対象期間 |
2026年9月21日〜2026年9月27日 |
| 対象製品 |
Google Cloud |
| 対象カテゴリ |
セキュリティ |
| アップデート件数 |
13件（内容が同一の2件を1トピックに統合し、12トピックとして解説） |
今回のアップデート一覧
アップデート詳細
1. Access Context Manager — Workforce Identity Federation で延長セッション長に対応（Preview・2026年9月21日）
Access Context Manager（アクセス条件をポリシーとして定義し、リソースへの到達可否を制御する仕組み）が、Workforce Identity Federation の延長セッション長（extended session length）をサポートしました。本機能は Looker (Google Cloud core) をご利用のお客様向けの Preview として案内されています。
🔍 何が変わったのか
- Workforce Identity Federation（社内やグループ会社の ID 基盤で認証したユーザーに、Google Cloud のリソースへのアクセスを許可する仕組み）で、延長セッション長を構成できるようになりました
- 対象は Looker (Google Cloud core)（Google Cloud のサービスとして提供される Looker）のお客様です
- 提供段階は Preview です。設定手順は公式ドキュメント「Configure extended session length for Workforce Identity Federation」に案内されています
💼 こんな場面で活用できます（ユースケース）
外部の ID 基盤を使って Looker にアクセスしている IT 部門・データ活用の推進担当者が対象です。ダッシュボードを開いて数値を確認し、条件を変えて再度確認する、といった作業は断続的に続くことがあります。セッションの有効期間に関わる設定を選べるようになるため、再認証を求められる頻度と、セッションを短く保つことによる統制の強さとのバランスを、自社の方針に合わせて設計できます。
✨ 導入メリット
- セッションの扱いを自社のポリシーに合わせて構成でき、利便性と統制のバランスを設計しやすくなります
- 既存の ID 基盤を起点としたアクセス制御を維持したまま設定を調整でき、アカウントの二重管理を避ける運用を続けられます
- Preview 段階のため、本番適用の前に検証環境で挙動を確かめる進め方を選べます
📚 公式ソース
2. Identity and Access Management — SCIM のデータを Looker のサインインで利用可能に（Preview・2026年9月21日）
Identity and Access Management（IAM: 誰に何を許可するかを管理する仕組み）で、SCIM（System for Cross-domain Identity Management: ID 基盤の間でユーザーやグループの情報を同期するための標準仕様）のデータを、Looker の OAuth サインインワークフローにおけるユーザークレームとグループクレームの両方のソースとして利用できるようになりました。本機能は Preview です。
🔍 何が変わったのか
- SCIM のデータを、Looker の OAuth サインインワークフローでユーザークレーム（利用者の属性情報）とグループクレーム（所属グループの情報）の両方のソースとして利用できます
- SCIM を利用する場合にも、Extended Session Length（ESL） を併用できます
- 構成手順として、Microsoft Entra ID と Okta のそれぞれについての公式ドキュメントが案内されています
- SCIM のプロビジョニングと同期に関するトラブルシューティングのドキュメントも用意されています
- 提供段階は Preview です
💼 こんな場面で活用できます（ユースケース）
Microsoft Entra ID や Okta を全社の ID 基盤として運用し、Looker のアクセス制御を組織構造に沿って設計したい IT 部門が対象です。誰がどのグループに属するかという情報は、ID 基盤側で人事異動に合わせて更新されます。その情報を SCIM 経由で同期し、サインイン時のグループクレームのソースとして使えるようになるため、Looker 側で別途グループを維持する作業を減らす方向で構成を検討できます。
✨ 導入メリット
- ID 基盤で管理しているユーザー・グループ情報をそのまま活用でき、権限管理の属人化の解消につながります
- グループ単位のアクセス制御を組み立てやすくなり、組織変更への追従にかかる工数を抑えられます
- Entra ID と Okta の構成手順、およびトラブルシューティングのドキュメントが揃っているため、検証の段取りを立てやすくなります
📚 公式ソース
3. Google SecOps / SecOps SIEM — 直接取り込みのログに組織 ID が自動付与（2026年9月21日）
Google SecOps（ログを集約して脅威の検知・調査を行うセキュリティオペレーション基盤）が、Google Cloud direct ingestion（直接取り込み）で取り込んだログに、送信元の Google Cloud 組織 ID を自動的に付与するようになりました。
🔍 何が変わったのか
- 従来、直接取り込みには組織レベルの識別子が含まれていませんでした。複数の Google Cloud 組織を持つお客様は、ログの出所を区別するために Cloud Logging のシンクとフィードを個別に構成する必要がありました
- 本アップデートにより、イベントごとの送信元組織を識別できるようになり、UDM 検索の絞り込み、検知ルールの適用範囲の指定、複数組織環境での Data RBAC や Data Processing Pipelines の構成を、追加の設定なしに行えると案内されています
- UDM イベント（正規化されたイベントデータ）では、組織 ID が metadata.base_labels.ingestion_kv_labels の下に自動的に現れます
| 項目 |
値 |
| key |
gcp_organization_id |
| value |
自社の Google Cloud 組織 ID |
- ロールアウトは2026年9月21日から9月28日にかけて段階的に行われ、利用者側の操作や設定変更は不要と案内されています
💼 こんな場面で活用できます（ユースケース）
複数の Google Cloud 組織を運用し、そのログを1つの Google SecOps に集約している SecOps エンジニア・セキュリティ運用担当者が対象です。グループ会社ごとや事業部ごとに組織を分けている構成では、検知したイベントがどの組織で起きたのかを特定する作業が調査の起点になります。従来はシンクとフィードを分けて構成することで区別していましたが、その構成を組まなくても組織 ID で絞り込めるようになります。
✨ 導入メリット
- 組織を区別するための個別構成が不要になり、取り込み基盤の構成をシンプルに保てます
- UDM 検索や検知ルールを組織単位で絞り込めるため、調査の初動を速められます
- Data RBAC を組織単位で設計しやすくなり、グループ会社間でのログ参照範囲の統制に寄与します
📚 公式ソース
4. Cloud NGFW — Enterprise の高度な脅威防御がクロスリージョン内部アプリケーション ロードバランサに対応（Preview・2026年9月22日）
Cloud NGFW Enterprise（次世代ファイアウォール。通信の許可・拒否だけでなく、通信の中身を検査して脅威を検出する機能を持ちます）の高度な脅威防御（advanced threat prevention）を、クロスリージョン内部アプリケーション ロードバランサと組み合わせて利用できるようになりました。提供段階は Preview です。
🔍 何が変わったのか
- グローバル ネットワーク ファイアウォール ポリシーにセキュリティ プロファイル グループを設定し、ロードバランサの転送ルールを宛先とする受信トラフィックを検査できます
- この統合では、侵入検知防止サービス（intrusion detection and prevention service）と Advanced malware sandbox (WildFire) がサポートされ、ワークロードとバックエンドを保護できると案内されています
- 対応するロードバランサの一覧は、公式ドキュメント「Supported load balancers」に記載されています
💼 こんな場面で活用できます（ユースケース）
複数リージョンにまたがって社内向けアプリケーションを配置しているインフラ担当者・ネットワーク担当者が対象です。クロスリージョンの内部ロードバランサは、災害対策や利用拠点に応じた振り分けを目的に採用されます。これまでこの構成は高度な脅威防御の対象として案内されていませんでしたが、転送ルール宛ての受信トラフィックを検査対象にできるようになります。
✨ 導入メリット
- 可用性を意識した構成と、通信内容の検査による保護を両立でき、設計の選択肢が広がります
- 侵入検知防止とマルウェアサンドボックスを同じポリシーの枠組みで扱えるため、保護設定の管理箇所を集約できます
- グローバル ネットワーク ファイアウォール ポリシーで構成するため、リージョンごとに個別のルールを重ねる運用を避けられます
📚 公式ソース
5. Cloud Asset Inventory — Migration Center のリソースタイプが一般公開（2026年9月23日）
Cloud Asset Inventory（クラウド上の資産＝リソースの一覧や変更履歴を横断的に扱う仕組み）で、Google Cloud Migration Center のリソースタイプが各 API を通じて一般公開（publicly available）されました。
🔍 何が変わったのか
- 追加されたリソースタイプは migrationcenter.googleapis.com/Asset と migrationcenter.googleapis.com/CostAssessmentJob の2つです
- 対象となる API は、ExportAssets、ListAssets、BatchGetAssetsHistory、QueryAssets、Feed、および Search（SearchAllResources、SearchAllIamPolicies）です
💼 こんな場面で活用できます（ユースケース）
オンプレミス環境からのクラウド移行を進めている IT 部門・クラウド管理者が対象です。Migration Center は、移行対象の資産や移行コストの試算を扱う仕組みです。その資産や試算ジョブを Cloud Asset Inventory の API から一覧・検索・エクスポートできるようになるため、移行プロジェクトの進捗把握や棚卸し資料の作成を、他のリソースと同じ枠組みで扱えます。
✨ 導入メリット
- 移行対象の資産を既存の資産管理の仕組みに取り込めるため、管理対象の抜け漏れを減らす方向で運用できます
- 変更履歴（BatchGetAssetsHistory）やフィード（Feed）を通じて、構成変更の検知を自動化しやすくなります
- エクスポートと検索に対応するため、クラウド移行の進捗レポートづくりにかかる工数の削減に寄与します
📚 公式ソース
6. Cloud Key Management Service — Cloud EKM が外部鍵の移行に対応（Preview・2026年9月23日）
Cloud EKM（Cloud External Key Manager: Google Cloud の外部で管理している鍵を使って、Google Cloud 上のデータを暗号化する仕組み）が、外部鍵の移行をサポートしました。提供段階は Preview です。
🔍 何が変わったのか
- EXTERNAL または EXTERNAL_VPC の保護レベルを持つ鍵について、いずれの保護レベルでも新しい鍵バージョンを作成できるようになりました
- 既存の外部鍵バージョンの保護レベルを変更することもできます。これにより、既存の鍵マテリアル（鍵の実体となるデータ）へのアクセス方法を、ダウンタイムなしで、かつアプリケーションを再構成することなく変更できると案内されています
- 移行手順は公式ドキュメント「Migrate external keys」に記載されています
💼 こんな場面で活用できます（ユースケース）
鍵を自社または外部のサービスで管理しながら Google Cloud を利用している IT 部門・セキュリティ担当者が対象です。EXTERNAL はインターネット経由で外部鍵マネージャに到達する方式、EXTERNAL_VPC は VPC ネットワーク経由で到達する方式です。統制方針の見直しやネットワーク構成の変更にともなって到達方法を変えたい場合に、鍵を作り直してデータを再暗号化するのではなく、既存の鍵バージョンの保護レベルを変更する方法を検討できます。
✨ 導入メリット
- 鍵へのアクセス方法をダウンタイムなしで変更できるため、業務を止めずに構成の見直しを進められます
- アプリケーション側の再構成が不要と案内されているため、移行にともなう開発・検証の範囲を絞り込めます
- 鍵管理の方針変更に追従しやすくなり、統制要件の変化に対応する選択肢が広がります
📚 公式ソース
7. Confidential VM — c4-standard-* マシンタイプでの Intel TDX が一般提供（GA・2026年9月23日）
Confidential VM（メモリ上で処理中のデータを暗号化したまま実行できる仮想マシン）で、c4-standard-* マシンタイプ上の Intel TDX のサポートが一般提供（GA）になりました。
🔍 何が変わったのか
- c4-standard-* マシンタイプで Intel TDX（Intel Trust Domain Extensions: 仮想マシンの実行環境をハードウェアで隔離・保護する技術）を利用する構成が、一般提供（GA）になりました
- マシンタイプ・CPU・ゾーンの対応状況は、公式ドキュメントのサポート対象構成の一覧に記載されています
💼 こんな場面で活用できます（ユースケース）
個人情報や取引データなど、取り扱いに配慮が必要なデータを処理するシステムをクラウドへ移行したい IT 部門・インフラ担当者が対象です。保存時と通信時の暗号化に加えて処理中のデータも保護したいという要件は、金融・医療・公共といった分野で挙がります。汎用的な C4 マシンシリーズの標準タイプが対象に加わったことで、一般提供の構成として本番採用を検討しやすくなります。
✨ 導入メリット
- 一般提供（GA）となったため、サポート体制を前提とした本番環境での採用を検討できます
- 処理中のデータ保護を、汎用的なマシンタイプ上で実現でき、対象システムの選択肢が広がります
- クラウド移行にあたって説明を求められる統制項目に対し、ハードウェアによる保護という根拠を示せます
📚 公式ソース
8. Certificate Manager — 作成時にタグを付与できるように（Preview・2026年9月24日）
Certificate Manager（TLS 証明書の発行・更新・配布を管理する仕組み）のリソースに対して、作成時にタグを付与できるようになりました。提供段階は Preview です。
🔍 何が変わったのか
- Certificate Manager のリソースを作成する時点で、タグを付与できます
- タグの作成・管理の手順は、公式ドキュメント「Create and manage tags for Certificate Manager resources」に案内されています
💼 こんな場面で活用できます（ユースケース）
複数のサービスやプロジェクトにまたがって証明書を管理している IT 部門・インフラ担当者が対象です。Google Cloud のタグは、リソースを分類するだけでなく、条件付きのアクセス制御にも使われます。証明書を作成する時点でタグを付けられるようになるため、作成後に付け忘れたまま運用が始まる状況を避けやすくなります。
✨ 導入メリット
- 作成時点で分類を確定でき、タグの付与漏れによる管理の抜けを減らせます
- タグを条件としたアクセス制御やポリシー適用を、証明書リソースにも組み立てやすくなります
- 環境や事業部といった単位で証明書を整理でき、棚卸しやコスト配賦の作業を進めやすくなります
📚 公式ソース
9. Model Armor — メルボルンでデータ所在地要件下のフィルタが利用可能に（2026年9月24日）
Model Armor（生成 AI モデルへの悪意ある入力や望ましくない出力からの保護を担う仕組み）で、メルボルン（australia-southeast2）においてデータ所在地の強制を有効にした状態でも利用できるフィルタが追加されました。
🔍 何が変わったのか
- australia-southeast2 でデータ所在地の強制（data residency enforcement）を有効にしている場合に、次のフィルタを利用できます
- プロンプトインジェクションおよびジェイルブレイクの検出（Prompt injection and jailbreak detection）
- Responsible AI
- リージョンごとの利用可能な Model Armor の機能は、公式ドキュメント「Supported features by region」に一覧化されています
💼 こんな場面で活用できます（ユースケース）
オーストラリアに拠点を持ち、データの保管・処理を特定リージョン内に限定する要件のもとで生成 AI を活用している IT 部門・AI 活用推進の担当者が対象です。プロンプトインジェクションは、利用者の入力を通じて AI に意図しない振る舞いをさせようとする攻撃手法です。データ所在地の要件を満たしたまま、こうした入力の検出と、生成内容に関する Responsible AI のフィルタを適用できます。
✨ 導入メリット
- データ所在地の要件と AI 保護の両方を満たす構成を、同一リージョン内で組み立てられます
- 該当リージョンで生成 AI の活用を検討していた組織にとって、適用範囲の判断材料が増えます
- リージョンごとの対応状況が公式に一覧化されているため、多拠点展開の設計時に確認しやすくなります
📚 公式ソース
10. Security Command Center — AI Protection の検出カテゴリ名が変更（2026年9月24日）
Security Command Center（クラウドのセキュリティリスクを一元的に管理する仕組み）の AI Protection が出力する検出（finding）のカテゴリ名が変更されました。AI Protection がチューニング済みモデル（tuned model）を検出することを明確にし、従来の VERTEX_1P_ 接頭辞を取り除くための変更と案内されています。カテゴリ名を条件に使っている設定がある場合、影響を確認する対象になります。
🔍 何が変わったのか
| 変更前のカテゴリ名 |
変更後のカテゴリ名 |
| VERTEX_1P_TUNED_MODEL_DETECTED |
TUNED_MODEL_DETECTED |
| VERTEX_1P_TUNED_MODEL_NOT_PROTECTED_BY_MODEL_ARMOR |
TUNED_MODEL_NOT_PROTECTED_BY_MODEL_ARMOR |
- 変更の目的は、AI Protection がチューニング済みモデルを検出することを明確にし、従来の VERTEX_1P_ 接頭辞を取り除くことと記載されています
- 本項目は、リリースノート上で非破壊的な変更（NON_BREAKING_CHANGE）として分類されています
💼 こんな場面で確認が必要です（ユースケース）
Security Command Center で AI Protection の検出結果を運用に取り込んでいるセキュリティ担当者・クラウド管理者が対象です。検出結果は、コンソールでの絞り込みだけでなく、BigQuery へのエクスポート、通知連携、ダッシュボード、ミュートルールなどからカテゴリ名で参照されていることがあります。カテゴリ名を条件式に書き込んでいる箇所がどこにあるかを洗い出すことが、確認の出発点になります。
✨ 使えるようになる機能
- 本項目はカテゴリ名の変更に関する内容であり、公式リリースノートでハイライトされた新機能はありません
- カテゴリ名から VERTEX_1P_ 接頭辞が外れ、チューニング済みモデルの検出であることが名称から読み取りやすくなりました
- AI Protection の検出の詳細は、公式ドキュメント「AI Protection overview」および「AI Discovery service findings」に案内されています
⚠️ 使えなくなる機能 / 変更点
- 検出カテゴリ名が VERTEX_1P_TUNED_MODEL_DETECTED から TUNED_MODEL_DETECTED へ、VERTEX_1P_TUNED_MODEL_NOT_PROTECTED_BY_MODEL_ARMOR から TUNED_MODEL_NOT_PROTECTED_BY_MODEL_ARMOR へ変更されました
- 公式リリースノートには、旧名称の並行提供期間や移行期限に関する記載はありません
- 公式リリースノートに、既知の不具合・CVE 情報の記載はありません
🤔 判断観点
- 影響範囲の特定: 自社で AI Protection を有効化しているか、その検出結果を誰が・どの仕組みから参照しているかを確認する観点があります
- 参照箇所の洗い出し: カテゴリ名を条件に使っている箇所（コンソールの保存済みフィルタ、BigQuery エクスポート先に対するクエリ、通知連携、SOAR のプレイブック、ミュートルールなど）を整理する観点があります
- 検証推奨事項: 旧名称で絞り込んでいた処理が新名称でも同じ結果になるかを、検証環境または参照系の処理で確認する観点があります
- ダウンタイム想定: 本項目はカテゴリ名の変更であり、システム停止をともなう作業は案内されていません。設定・クエリの見直しが中心になる点を踏まえて計画する観点があります
- 影響の度合い: AI Protection を利用していない場合、公式リリースノートでは作業は案内されていません。利用状況の確認だけで完了するかどうかを見極める観点があります
- 記録の更新: 運用手順書や監査資料にカテゴリ名を記載している場合、あわせて更新対象に含めるかを検討する観点があります
📚 公式ソース
11. API Keys API — リモート MCP サーバーが Preview で提供（2026年9月25日）
API Keys API（Google Cloud プロジェクトの API キーを作成・管理するための API）のリモート MCP サーバーが Preview として提供されました。MCP（Model Context Protocol）は、AI アプリケーションやエージェントを外部のツール・データへ接続するための標準的な仕組みです。
🔍 何が変わったのか
- AI アプリケーションから API Keys のリモート MCP サーバーへ接続できるようになりました
- 接続後に行える操作として、Google Cloud プロジェクト内の API キーの作成、確認（inspect）、制限（restrict）、ライフサイクルの管理が挙げられています
- 提供段階は Preview です。詳細は公式ドキュメント「API Keys MCP reference」に記載されています
💼 こんな場面で活用できます（ユースケース）
API キーの発行と棚卸しを担う IT 部門・プラットフォームチームが対象です。API キーは、用途ごとに制限（呼び出せる API や参照元の限定）を設定して発行し、不要になったら無効化する運用が求められます。AI アプリケーションから操作できるようになることで、「どのキーにどの制限がかかっているか」を対話的に確認しながら整理を進める運用を検討できます。
✨ 導入メリット
- キーの作成から制限設定、ライフサイクル管理までを同じ接続先から扱え、管理作業を集約できます
- AI アプリケーション経由で確認できるため、棚卸しにかかる調査の手間を抑えられます
- 既存の MCP 対応アプリケーションから接続でき、専用ツールを用意せずに検証を始められます
📚 公式ソース
12. Google SecOps SOAR — リリース 6.3.100 が全リージョンで提供開始（2026年9月26日）
Google SecOps SOAR（セキュリティ対応の自動化・オーケストレーションを担う仕組み）のリリース 6.3.100 が、全リージョンで利用可能になりました。2026年9月6日に第1フェーズのリージョンへ展開が始まっていたリリースが、全リージョンへ行き渡った形です。
🔍 何が変わったのか
- リリース 6.3.100 が全リージョンで提供開始となりました
- リリース 6.3.100 の内容は、SOAR のリリースノート（2026年9月6日の項目）に記載されています。内部および顧客から報告されたバグの修正を含むとされ、あわせて2つの機能が Preview として登場しています
💼 こんな場面で確認が必要です（ユースケース）
SOAR でインシデント対応のプレイブック（対応手順の自動化）を運用している SecOps エンジニアが対象です。リリースが全リージョンへ行き渡ることで、これまで対象外のリージョンを利用していたテナントでも同じバージョンの機能を扱えるようになります。自社のリージョンで提供が始まったか、そして新しく Preview で加わった機能を検証対象に含めるかが、確認のポイントになります。
✨ 使えるようになる機能
- Reaction triggers（Preview）: 調査中にケースやアラートが更新されたタイミング（担当者の変更、タグの変更、アラートの優先度の変更、エンティティの追加など）で、プレイブックを自動的に起動できます
- Case playbooks（Preview）: 個々のアラート単位ではなく、ケース全体を対象にプレイブックの実行や手動アクションの実施ができます。調査中の重複した操作を減らせると案内されています
- 内部および顧客から報告されたバグの修正が含まれます
⚠️ 使えなくなる機能 / 変更点
- 公式リリースノートに、廃止された機能・非推奨化された機能の記載はありません
- 公式リリースノートに、既知の不具合・CVE 情報の記載はありません
- 本項目はリリースの提供リージョン拡大に関する案内であり、利用者側での適用作業は案内されていません
🤔 判断観点
- 提供状況の確認: 自社のテナントが配置されているリージョンで、リリース 6.3.100 が反映済みかを確認する観点があります
- Preview 機能の採用可否: Reaction triggers と Case playbooks はいずれも Preview 段階です。本番のプレイブックに組み込むか、検証環境での試行にとどめるかを検討する観点があります
- 影響範囲: 新機能は既存のプレイブックを置き換えるものではありませんが、Reaction triggers を有効にするとプレイブックの起動条件が増えます。起動頻度と対応負荷への影響を見積もる観点があります
- ロールアウト戦略: ケース全体を対象とするプレイブックへ移行する場合、影響の小さいユースケースから段階的に切り替えるか、まとめて設計し直すかを検討する観点があります
- 検証推奨事項: バグ修正の内容が自社で発生していた事象に該当するかを、運用記録と照らして確認する観点があります
📚 公式ソース
まとめ
2026年9月21日〜9月27日のセキュリティカテゴリは、既存の構成を保ったまま選択肢を増やす更新が中心でした。Cloud EKM の外部鍵移行（Preview）は、鍵へのアクセス方法をダウンタイムなしで変更できると案内されており、統制方針の見直しに追従しやすくなります。Confidential VM の Intel TDX 対応が c4-standard-* マシンタイプで一般提供（GA）になったことは、処理中のデータ保護を本番環境で検討する際の判断材料になります。ID 連携では、Access Context Manager の延長セッション長と Identity and Access Management の SCIM 対応が、いずれも Looker 向けの Preview として登場しました。
運用中の設定に関わる項目もあります。Security Command Center の AI Protection では、検出カテゴリ名から VERTEX_1P_ 接頭辞が外れました。カテゴリ名を条件に使っているダッシュボードや連携処理がある場合は、参照箇所の洗い出しが確認の起点になります。Google SecOps SOAR は、リリース 6.3.100 が全リージョンへ行き渡りました。いずれも自社の利用状況によって必要な作業が変わります。まずは「使っているかどうか」「どこから参照されているか」を確かめるところから、公式ドキュメントをもとに計画づくりを進めていただければと思います。
関連 XIMIX 記事
Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。
XIMIX からのご案内
XIMIX（サイミクス）は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、セキュリティ強化、データ活用などをご支援しています。本記事で取り上げた Confidential VM や Cloud EKM、Security Command Center、Google SecOps などの活用にご関心がありましたら、お気軽にご相談ください。
お問い合わせはこちら
参考資料