セキュリティ & アイデンティティ

境界セキュリティのモダナイズ: VPC Service Controls によるスケーラブルな境界

Fri, 30 Oct 2026 02:40:00 +0000

※この投稿は米国時間 2026 年 10 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

エージェントによって、クラウドの運用に根本的な変化がもたらされています。エージェントは、ユーザーに代わって自律的に行動し、非決定論的にその都度判断を行ったり、プロジェクトをまたいでデータをリクエストしたりします。そして、そのスピードと規模はかつてないレベルに達しています。エージェントは、人間以外の ID（NHI）という独特なカテゴリに位置付けられるため、独自の「セキュアバイデフォルト」方式の保護対策が必要となります。

手動で運用する従来のネットワーク境界は、昨今のマシンスピードの攻撃に対して脆弱です。接続のブロックを回避するために境界を緩めすぎると、データ窃取のリスクが高まりますが、境界を厳格にしすぎると、アクセス拒否が多発して開発の停滞につながります。

このたび、境界の作成、維持、スケーリングを容易にする VPC Service Controls（VPC-SC）の重要な機能強化が行われました。具体的には、境界メンバーシップにフォルダを追加して、フォルダ内の全プロジェクトにポリシーを継承できるようになります。また、きめ細かな例外を作成して管理したり、アクセス拒否が発生したときにガイドに従って一定のスコープ内で修復を行ったりできます。

これにより、データをデフォルトで保護して、境界外への流出を防ぎながら、自律型エージェントを企業全体にスケールすることが可能となります。このアップデートは一般提供となっており、追加料金はかかりません。

アーキテクチャに沿った境界

VPC-SC は、Google Cloud デプロイの周囲にコンテキストアウェアなネットワークセキュリティ境界を提供します。これにより、万が一、認証情報の侵害、Identity and Access Management（IAM）の構成ミス、インサイダー脅威が発生した場合でも、組織をデータ窃取から保護できる仕組みになっています。具体的には、Google Cloud インフラストラクチャのサービス間のやり取りにネットワークレイヤの保護を拡張し、従来のファイアウォールの範疇を超えて、社外ネットワークからのアクセス防御を徹底できます。このたびの機能強化で、管理も簡単になりました。

クラウド管理者は VPC-SC の構成時に境界メンバーシップにフォルダを含めて、フォルダのアクセスポリシーをフォルダ内の全プロジェクトおよびサブフォルダに自動的に適用できるようになりました。新しいワークロードにはデフォルトで保護設定が継承されるため、特に追加の操作は不要です。

図 1: VPC-SC の境界定義を簡素化。

プロジェクトを移動すると境界メンバーシップが自動的に更新されるため、ライフサイクルに伴うメンテナンスが簡素化されます。セキュリティの適用範囲はすでに管理しているリソース階層に従います。そのため、コンプライアンスを検証するには、リソースが階層内で正しく配置されているかどうかを確認するだけで済みます。

ドライランモードはフォルダメンバーシップでもサポートされており、階層全体の境界が本番トラフィックにどう影響するかを事前に評価できます。

上り（内向き）ルールと下り（外向き）ルールでフォルダや組織を指定可能

上り（内向き）と下り（外向き）のルールを詳細に定義してコンテキストアウェアのきめ細かな境界を確立すれば、複雑なマルチプロジェクト環境において運用の柔軟性を維持できます。このたび、これらのルール内で Google Cloud のフォルダや組織を直接指定できるようになりました。1 つの階層を参照するだけで、その配下のプロジェクトセットすべてを参照できるため、ルールを簡潔に保ち、属性数を上限内に収めながら、階層内で後から作成されたプロジェクトにもアクセス制御を自動的に適用することが可能となります。

図 2 : 上り（内向き）/ 下り（外向き）ルールの作成を簡素化。

上り（内向き）ルール、下り（外向き）ルールでの Private Service Connect エンドポイントの使用

現在、エンタープライズを中心に、トラフィックをインターネット上で晒すのを避け、プライベートパス経由でデプロイ内のエンドポイントにアクセスするという方法が広まっています。これを受け、上り（内向き）、下り（外向き）ルールの属性に Google API の Private Service Connect エンドポイントを指定できるようにしました。管理者は、特定のプライベートエンドポイント経由のアクセスを承認するルールを定義し、管理対象の接続アーキテクチャに直接対応するポリシーを生成できます。

図 3: 上り（内向き）、下り（外向き）のルール内で Private Service Connect エンドポイントを指定可能。

Private Service Connect を標準として Network Connectivity Center 経由で環境全体にエンドポイントを伝播させている組織においては、リクエスト元を正確かつ簡潔に表現することが可能となります。

VPC からアクセス可能なサービスのパターン

VPC からアクセス可能なサービスのパターンを使って、プライベートの仮想 IP アドレス（VIP）からアクセスできる Google API をきめ細かく制御できるようになりました。これにより、VPC-SC で統合されているサービス以外との相互運用も可能となります。たとえば、あるワークロードがプライベートパス経由で検証済み API エンドポイントにのみアクセスできるようにしたい場合は、特定の API URL パターンのみを許可します。

さらに、下り（外向き）リクエストに組織制限ヘッダーを追加して、承認済みのドメインとリソースへのアクセスのみを許可することもできます。これにより、下り（外向き）プロキシを管理しなくても、厳密なプライベートパスを維持しつつ正当な運用要件に対応することが可能になります。アクセスを広く許可または禁止するかの二者択一を迫られることはもうありません。

図 4: VPC からアクセス可能なサービスのパターンを指定し、Google API をきめ細かく制御。

違反修復ガイド

VPC-SC 境界ポリシーは保護対象のワークロードとともに進化し続けるため、管理者は、カバーしきれていない正当なアクセスリクエストを定期的に承認する必要があります。このたび、VPC-SC 違反分析ツールに違反修復ガイドが導入され、ブロックされたリクエストに対するポリシー調整および修正案が自動生成されるようになりました。これにより、こうした問題の解決にかかる時間が数日から分単位に短縮されます。この修正案は、まずドライランモードで検証できます。

違反分析ツールは、アクセス拒否の発生時に単に違反理由を診断するだけでなく、該当する境界構成に基づいて評価し、最小権限に則ってスコープを狭めつつ、構成の変更点を提案してくれます。たとえば、上り（内向き）ルール、下り（外向き）ルール、アクセスレベル、VPC からアクセスできるサービスの更新など、トラフィックを許可するための具体的な変更点が示されます。これにより、管理者は、違反を迅速に解決してアプリケーションを動かすためにとりあえず境界を広くするというプレッシャーから解放されます。

BlackLine が違反分析ツールを使用して調査を効率化した事例をご覧ください。

図 5 : VPC-SC の違反を迅速に修復。

使ってみる

VPC-SC を使えば、きめ細かなネットワーク境界保護を簡単かつ自動的にデプロイ、調整して、自律型エージェントにも対応できるようになります。利用方法は次のとおりです。

フォルダのベースラインを確立する: リソース階層内で境界適用対象のフォルダを特定し、その周囲に境界を定義して、新しいワークロードの作成時にポリシーが継承されるようにします。
ドライランモードでリスクなしで実行する: 本番環境のトラフィックを安全に確認し、作業中の開発者がブロックされるのを回避できます。
違反分析ツールと違反ダッシュボードでトラフィックのブロックを解除する: 最小権限に則って自動生成される修正案を使用して、アクセス拒否の問題を解決できます。
自信をもって適用する: ドライランモードのログで、承認済みのクリーンなトラフィックが想定通りにアクセスできることを確認できたら、本番環境に移行して、データ資産全体を保護できます。

VPC-SC によってデータセキュリティポスチャーを簡素化し、自律型エージェント群の安全性を確保する仕組みについて詳しくは、VPC-SC のドキュメントをご覧ください。

- Google Cloud、プロダクトマネージャー、Pratik Bhangale

PHP コアの脆弱性 CVE-2026-109618 および CVE-2026-109619 への対応

Thu, 29 Oct 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 10 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: このブログ投稿は 2026 年 10 月 21 日に更新され、太平洋夏時間午後 3 時 30 分に Cloud Armor に関するガイダンス、午後 4 時 25 分にモニタリング、パッチ適用、修復に関するガイダンスが追加されました。

PHP と Wiz Research はこのたび、PHP コア言語ランタイムにおける 2 つの重大な脆弱性を公表しました。これらの脆弱性により、アプリケーションが認証なしでのリモートコード実行やメモリ漏洩のリスクにさらされる可能性があります。Wiz は複数のモデルを組み合わせて活用し、これらの脆弱性の特定と修復支援を行いました。

特に Gemini 4 Argon は、脆弱性の発見、エクスプロイト開発、攻撃の検知、パッチの検証において計り知れない貢献を果たしました。

Google Cloud 自体はこの脆弱性の影響を受けませんが、Google Cloud 上で PHP を実行しているユーザーの皆様は影響を受ける可能性があります。Google Cloud は、これらの脆弱性の深刻度を重く受け止めており、お客様が迅速にアプリケーションの安全を確保できるよう、対策ガイダンスを公開しています。

脆弱性の背景

PHP は、数多くのウェブサイト、コンテンツマネジメントシステム、ウェブアプリケーションの基盤として広く使われているサーバーサイドスクリプト言語です。2026 年 10 月 21 日、CVE.org はこれらの脆弱性に対して CVE-2026-109618 および CVE-2026-109619 を割り当てました。

各 PHP の脆弱性に対する公式の共通脆弱性評価システム（CVSS）のベーススコアは、9.2 の「緊急」と判定されています。一般的に、この判定は、脅威アクターが対象システムをクラッシュさせて乗っ取ったり、データの窃取、改ざん、消去を容易に行ったりできることを意味します。ただし、緩和要因によって脆弱性の悪用が困難になる場合もあります。

CVE-2026-109618: メモリ不足処理の際、内部リクエストデータが不完全に初期化された状態で PHP の処理が中断される可能性があります。その結果、リクエストのクリーンアップ処理において、この無効なデータが有効なものとして扱われてしまう場合があります。
CVE-2026-109619: リクエストに紐づく内部状態が、バッキングメモリの解放後も残存してしまう可能性があります。同じワーカーが後続のリクエストを処理する際、通常の初期化によってリセットされる前の古い状態を使用してしまう可能性があります。
脆弱性の影響を受けるバージョン: PHP のすべてのバージョン（5.4～8.5.11）。
パッチ適用済み: PHP 8.5.12、8.4.27、8.3.36、8.2.35。
パッチ未適用: PHP プロジェクトは、サポート終了となった PHP 8.1 以前の修正をリリースしていません。
修正: CVE-2026-109618（GHSA-w8hw-w9fx-j79w）と CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）。
お知らせ: PHP は、これら 2 つの脆弱性に関するセキュリティアドバイザリを公開しました。

Wiz Research は、この調査と協調的な開示プロセスに関する詳細な説明を公開しています。

PHP の更新とアプリケーションの再デプロイ

Google Cloud で PHP アプリケーションを運用されているすべてのお客様は、直ちに PHP 8.2 以降に更新し、パッチ適用済みのバージョンを使用してサービスを再デプロイしてください。

これは特に、以下にデプロイされたアプリケーションに適用されます。

App Engine スタンダード環境: サポート対象のランタイムには、自動的にパッチが適用されます。PHP 8.1 以前をご利用の場合は、PHP 8.2 以降にアップグレードのうえ、再デプロイしてください。
App Engine フレキシブル環境: サポート対象のランタイムを使用して、PHP ランタイムを再デプロイしてください。カスタムランタイムをご利用の場合は、PHP の依存関係をパッチ適用済みのバージョンに更新し、アプリケーションを再デプロイしてください。
Cloud Run: ベースイメージの自動更新を有効にしていない場合、または独自のコンテナイメージをデプロイしている場合は、パッチ適用済みの PHP バージョンで再構築し、再デプロイしてください。
Google Kubernetes Engine（GKE）: パッチ適用済みの PHP バージョンでコンテナイメージを更新し、Pod を再デプロイしてください。
Google Cloud Marketplace: コンテンツマネジメントシステムや LAMP スタックなど、PHP を含む Marketplace ソリューションを運用している場合は、ソリューションプロバイダからのアップデートを適用するか、PHP を直接更新してください。

サーバーレスプラットフォームにおける自動パッチ適用

Google Cloud は、App Engine スタンダード、App Engine フレキシブル、Cloud Run、Cloud Run functions、Cloud Functions for Firebase のすべてのサポート対象 PHP バージョンに向けて、更新されたサーバーレスベースイメージのロールアウトを進めています。

お客様への影響:

App Engine スタンダード環境（PHP 8.2 以降）: アプリケーションは自動的に更新されます。ご対応は必要ありません。
App Engine フレキシブル環境（すべての PHP バージョン）: アプリケーションは自動的に更新されません。できるだけ早く、アプリケーションを PHP 8.2 以降に再デプロイしてください。
Cloud Run functions（PHP 8.2 以降）: ベースイメージの自動更新が有効になっている関数は、自動的に更新されます。ベースイメージの自動更新が有効になっていない関数は、再デプロイする必要があります。
Cloud Run （PHP 8.2 以降）: ベースイメージの自動更新が有効になっているサービスは自動的に更新されます。ベースイメージの自動更新を有効にせず構築されたサービスは、パッチ適用済みのランタイムを反映するために再構築と再デプロイを行う必要があります。

重要な考慮事項:

サポート対象外のランタイムにはパッチが適用されません。アップストリームの PHP プロジェクトは、PHP 8.1 以前のバージョンに対してこれらの修正をバックポートしていません。PHP 5.5、PHP 7.2、PHP 7.3、PHP 7.4、PHP 8.1 で動作しているアプリケーションは脆弱性の影響を受けたままとなるため、PHP 8.2 以降へのアップグレードが必須となります。サーバーレスライフサイクルの日付については、以下のランタイムサポートスケジュールをご覧ください。

ご自身で構築したコンテナイメージは、お客様ご自身の責任となります。独自のコンテナイメージを Cloud Run や App Engine フレキシブル環境にデプロイしている場合（カスタムランタイムを使用している場合など）、パッチ適用済みの PHP バージョンで再構築し、再デプロイしてください。

Cloud Armor による CVE-2026-109618 と CVE-2026-109619 のリスク緩和

Cloud Armor では、Cloud Armor マネージドルールを使用した推奨の緩和策を公開しています。マネージドルールを有効にしているお客様は、追加のご対応は不要です。これらの脆弱性に対する保護機能は自動的に適用されます。

Cloud Armor マネージドルールをまだデプロイしていない場合でも、今からデプロイすることで、これらの脆弱性のリスクを緩和できます。Cloud Armor マネージドルールによる保護機能は、自動更新される脅威インテリジェンスルールセットを通じて現在利用可能です。

これらのルールは、グローバルまたはリージョンアプリケーションロードバランサを使用し、インターネットに公開されている PHP アプリケーションやサービスの保護を目的としています。ご利用環境内のすべての脆弱な PHP インスタンスが脆弱性管理プログラムによって更新および検証されるまでの間、最前線の多層防御の緩和策として、以下の手順に沿ってルールを速やかにデプロイしてください。

1. 自動更新用にカナリア版と安定版のマネージドルールをデプロイします（プレビューモードと自動適用モード）。

これらの CVE からワークロードを保護するには、少なくともファイルアップロードカテゴリと RFI カテゴリを有効にする必要があります。カナリア版のすべてのルールセットカテゴリをプレビューモードで構成し、安定版のルールセットカテゴリを自動適用モードで構成することをおすすめします。

2. 構成済みの検査上限を超えるリクエスト本文のリスクを軽減します。

セキュリティポリシーにルールを作成し、検査されていないコンテンツや不要にサイズの大きなコンテンツがバックエンドに到達しないよう対策を講じてください。これらの CVE では、大きなペイロードを使用してメモリ不足状態を引き起こす可能性があるため、この対策は特に重要となります。

アプリケーションにおける WAF ルールの安全性の検証とテレメトリーの使用

PHP アプリケーションやコンテンツ管理プラットフォーム（WordPress や Drupal など）によって、クエリパラメータ、フォーム送信、カスタムエラーハンドラの構造は大きく異なります。そのため、上述のルールをまずプレビューモードでデプロイし、トラフィックを即座にブロックすることなく、予想される影響をテストおよびモニタリングすることを強くおすすめします。

新しいルールがアプリケーショントラフィックに対して期待どおりに動作していることを確認したら、プレビューモードを無効にして、Cloud Armor が deny(403) アクションを実際に強制適用できるようにします。Cloud Armor のリクエストごとのウェブアプリケーションファイアウォール（WAF）テレメトリーは、Cloud Logging のアプリケーションロードバランサログの一部として出力されます。

各リクエストに対する Cloud Armor の決定を検査するには、まずロードバランサのリクエストロギングをバックエンドサービスごとに有効にする必要があります。有効化すると、それ以降の Cloud Armor の適用およびプレビュー判定はすべて、こちらの手順により Cloud Logging でクエリできます。

リスクを最小限に抑え、パフォーマンスを最適化するために、Cloud Armor のベストプラクティスガイドを参照し、サービスの制限事項（前述の検査対象リクエスト本文の最大サイズなど）を考慮することをおすすめします。

モニタリングと監査

Google Cloud および Wiz は、ネイティブのセキュリティサービス全体で継続的なモニタリング、監査、ランタイム検出を提供し、お客様をサポートしています。お客様は以下を使用できます。

On-Demand Scanning API: ローカルコンピュータ上のイメージや Artifact Registry 内のリモートコンテナイメージを手動でスキャンできます。Artifact Analysis をご利用のお客様には、新規および既存のアーティファクト双方についてこれらの脆弱性が通知されるため、リスクのあるワークロードを特定できます。
Security Command Center: GKE の Container Threat Detection と Cloud Run の脅威検出を有効化し、ワークロードへの侵入をモニタリングします。
Google Security Operations: Mandiant Frontline Threats ルールパックに、23 件のキュレーテッド検出が新たに追加されました。このルールパックが有効になっていることを確認し、検出結果をレビューして、環境への潜在的な影響を評価することをおすすめします。

Enterprise Plus をご利用のお客様は、Emerging Threat Center で「GLOBAL.26.015」を検索して詳細を確認することもできます。公開プレビュー版で Threat Hunt Agent を有効化している Enterprise Plus のお客様は、Emerging Threat Center から「GLOBAL.26.015」に対するスレットハンティングを実行することも可能です。

Wiz をご利用のお客様は、PHP2Shell に関する Wiz Threat Intel Center のアドバイザリをご参照いただけます。同アドバイザリには、エージェントレスおよびランタイムでの脆弱性検知、Wiz Defend と Sensor による悪用検知、自動対応ポリシーに加え、修復や脅威ハンティングのガイダンスが含まれています。Wiz を使用した対応手順について詳しくは、こちらをご覧ください。

さらに Mandiant Threat Defense は、Google Security Operations におけるキュレーテッド検出のモニタリングや、このキャンペーンに関連する侵入痕跡のハンティングを通じて、お客様を強力にサポートしています。

パッチ適用と修復

PHP のセキュリティリリースが公開されました。すべてのサーバー環境、コンテナイメージ、デプロイパイプラインで PHP を更新する必要があります。加えて、以下の情報もご確認ください。

Wiz のゼロデイ対応コミットメントの一環として、WizOS PHP イメージ は、今後 60 日間、すべてのお客様に課金対象外でご利用いただけます。WizOS PHP ベースイメージ（標準の Alpine 堅牢化ビルドおよび FIPS 準拠ビルドの両方）はソースから構築されており、CVE-2026-109618 および CVE-2026-109619 に対するパッチがすでに適用されています。
Wiz をご利用のお客様は、Green Agent を活用して PHP2Shell Threat Intel アドバイザリを、個々のリソースに最適化された修復ガイダンスに変換できます。このガイダンスには、適切な PHP パッチバージョンの指定、最適な WAF 緩和策の特定、堅牢化された WizOS PHP イメージへの差し替えの提案、防御にギャップがある場合のランタイムブロックの有効化の推奨などが含まれます。

Google は引き続き状況を注視し、必要に応じて最新情報やガイダンスを提供します。最新の情報と詳細な手順については、Google Cloud のセキュリティに関する公開情報をご覧ください。

- Google Cloud、CISO、Chris Betz

- Google DeepMind、Gemini セキュリティ責任者、Raluca Ada Popa

グローバル規模のハードウェア格納型セキュリティ: NVIDIA Blackwell を搭載した Confidential G4 の一般提供を開始

Tue, 27 Oct 2026 16:00:00 +0000

※この投稿は米国時間 2026 年 10 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

自律型エージェントを本番環境に導入するには、機密データや貴重な知的財産をリアルタイムで処理する必要があります。独自のモデルの重み、ユーザープロンプト、生成された出力を守るには、計算処理を実行している最中のデータを保護するセキュリティが必要です。

企業のセキュリティを確保するための取り組みの一環として、このたび、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した Google Cloud の G4 インスタンスで Confidential Computing の一般提供を開始したことをお知らせいたします。このリリースにより、NVIDIA Confidential Computing が Google Cloud の AI Hypercomputer に直接統合され、プライバシーを損なうことなくスケーリングに必要な動的パフォーマンスを実現します。

今年に入って Confidential G4 のプレビュー版を発表した際、そのグローバルな展開規模についてお話ししました。このたび、36 のゾーンにまたがり、複数の利用モデルに対応したこれらのインスタンスを、Compute Engine VM と GKE ノードにて、一般提供を開始いたしました。

さらに、安全なマルチパーティデータ共有を可能にする Confidential Space のサポートも、今後数週間かけて順次一般提供される予定です。

機密データとモデルを低レイテンシで保護

使用中のデータを保護するために、GPU スループットや運用のアジリティを犠牲にする必要はありません。エクスポート不可のハードウェアキー、検証可能なリモート認証、透過的なメモリ暗号化を統合した Confidential G4 は、エージェント型ワークロードや推論ワークロードへの投資効果を最大化します。企業は、厳格な規制要件やコンプライアンス要件を満たしながら、コストを低く抑えることができます。

「組織がクラウド、オンプレミス、エージェント環境など、ますます複雑化する環境に AI をデプロイするなかで、機密データの保護は極めて重要となっています。また、AI システムがセキュリティを確保したうえで、自社のポリシーに準拠して一貫して動作することを担保しなければなりません。NVIDIA RTX PRO 6000 Blackwell GPU を搭載した Google Cloud Confidential G4 VM は、プライバシー保護型の AI および AI 運用に向けた強力な基盤を提供します。Confidential Core AI は Google Cloud 上で動作し、企業の原則、ポリシー、運用要件を、AI エージェント、モデル、データ、ツールをモニタリングおよび統制するリアルタイムの安全保護対策へと落とし込みます。これらの機能を組み合わせることで、組織は管理、機密性、説明責任を維持しながら、Google Cloud 上で信頼性の高い AI を大規模に展開できます。」- Confidential Core AI、創業者 / CEO、Taher Behbehani 氏

エンタープライズ AI ワークロードにおけるその他のメリットは以下のとおりです。

エンドツーエンドの機密性と分離: ハードウェアによって保護された実行環境でデータとモデルパラメータを暗号化し、知的財産やお客様の入力をホストシステム管理者、ハイパーバイザ、さらにはクラウドプロバイダによるアクセスから保護します。
検証可能な暗号化による信頼: ハードウェアをルートとするリモート認証を活用し、機密データセットの解放やワークロードの実行前に、コード、プラットフォーム構成、環境の整合性を検証します。
コードのリファクタリングが不要: 標準の Ubuntu OS イメージ、NVIDIA ドライバ、NVIDIA CUDA-X ライブラリを使用し、アプリケーションの変更やカスタムビルドを行うことなく、そのままモデルをデプロイできます。

Polaris Cloud にとって、このデプロイの容易さはまさに画期的なものでした。

「Polaris は AI エージェント用のワークスペースを開発しています。お客様は、エージェントの処理が実際にどこで実行されたのか、そしてその過程で暗号技術によって確実に分離されていたかを知る必要があります。Google Cloud Confidential G4 の登場によって、その課題は一気に解決しました。NVIDIA RTX PRO 6000 Blackwell GPU からハードウェア格納型の来歴を取得し、お客様が結果とともに受け取るレシートにバインドしています。それ以外は実質的に何も変わっていません。同じ G4 イメージ、同じ NVIDIA ドライバ、同じコンテナランタイムを使い、起動時にフラグを 1 つ指定するだけで、パフォーマンスもそのままです。これにより、お客様に対する当社の約束は、『お客様のエージェントを実行します』というものから『当社で実行するすべてのワークロードは検証可能です』というレベルへと、一夜にして引き上げられたのです。」- Polaris Cloud、創業者 / CEO、Fred Esere 氏

マルチパーティデータコラボレーション: Confidential Space を使用して、共同分析やモデルの共同トレーニングを安全に行うことができます。複数の関係者が、元となるプライベートデータを互いに開示することなく、機密性の高いデータセットを組み合わせることができます。

「企業は、最も価値のあるデータを AI で活用しながら、その処理中の保護も両立させる必要があります。NVIDIA Confidential Computing は、GPU アクセラレーションワークロードにハードウェア格納型の保護を提供し、使用中の機密データや独自モデルを守ります。Google Cloud と連携し、NVIDIA Blackwell のパフォーマンスとこれらのセキュリティ機能を Confidential G4 VM に導入することで、組織は高いパフォーマンスと検証可能な保護機能を備えた本番環境の AI を大規模に展開できるようになります。」- NVIDIA、アクセラレーテッドコンピューティングプロダクト担当ディレクター、Dave Salvator 氏

パフォーマンスのテスト

メモリ暗号化が運用に与える影響を把握するため、g4-standard-48 マシンシェイプを使用して、Confidential G4 インスタンスと標準の非 Confidential G4 インスタンスの比較分析を行いました。今回のテストでは、広く採用されているオープンウェイトモデルに焦点を当てました。これらのモデルは、お客様が自社の推論パイプラインにおいて、単一の GPU インスタンスによくデプロイしているものです。

Llama 3、Llama 3.3、Resnet-50、SDXL などの主要なモデルを対象としたベンチマークでは、Confidential G4 は AI 推論ワークロードにおいて標準の G4 インスタンスと同等のパフォーマンスを発揮し、スループットの低下は 3.5% 未満（1 秒あたりのトークン数または画像数で測定）であることが示されています。

注: パフォーマンス測定結果は、特定のテスト条件および構成に基づくものです。実際のワークロードのパフォーマンスは、システムのセットアップ、選択するハードウェア、ソフトウェア環境によって異なる場合があります。

Google の分析結果は、機密データを保護し、コンプライアンス要件を満たしながら、スピーディーな展開を可能にします。この両立は、実際の導入現場ですでに実証されています。

「当社のワークロードにおいて、Google Cloud の Confidential G4 と、まったく同じソフトウェアを稼働させた標準の G4 との比較ベンチマークを実施しました。エンドツーエンドのレイテンシ増加はわずか 5.2% にとどまり、その一方で、認証された環境外にいる権限のないユーザーによる会話の盗聴を防ぐ、ハードウェアレベルの保証が得られることがわかりました。このトレードオフなら、何度でも選ぶ価値があります。ユーザーはオンプレミス同等のプライバシーを確保しながら、クラウドの利便性を享受できるからです。」- Vertebrae、CEO、Andy Qin 氏

Confidential G4 を使ってみる

Confidential G4 を活用すれば、モデルの実行やエージェントワークロードにおけるセキュリティを強化するにあたって、パフォーマンス、柔軟性、運用の容易さを犠牲にする必要はありません。スループットの低下をほぼゼロに抑えつつ、検証可能な信頼性と堅牢なハードウェア分離を提供することで、組織は価値の高いモデルを安全にデプロイし、重要なデータアセットをクラウド規模で保護できます。

GPU を使用した Confidential VMs のドキュメントに沿って、今すぐご利用を開始してください。

- Confidential Computing 担当プロダクトマネージャー、Meghna Sreenivasan

- Confidential Computing 担当プロダクトリード、Sam Lugani

Cloud CISO の視点: CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

Thu, 22 Oct 2026 10:00:00 +0000

※この投稿は米国時間 2026 年 10 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

2026 年 10 月最初の投稿となる「Cloud CISO の視点」をご覧いただきありがとうございます。今回は、Stephanie Kiel がポスト量子暗号（PQC）に対する Google のアプローチの最新情報について説明し、CISO や経営幹部が組織の PQC への準備を整えるのに役立つ新しいツールをご紹介します。

これまでのすべての「Cloud CISO の視点」と同様、このニュースレターのコンテンツは Google Cloud 公式ブログに投稿されます。このニュースレターをウェブサイトでご覧になっており、メール版の受信をご希望の方は、こちらからご登録ください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud で取締役向けの重要な情報を得る'), ('body', <wagtail.rich_text.RichText object at 0x7f7de99d3550>), ('btn_text', 'インサイトハブを見る'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

Google Cloud、クラウドセキュリティポリシー、政府関連業務および公共政策責任者、Stephanie Kiel

Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

ポスト量子暗号（PQC）は、セキュリティに関してこの 10 年間で最も緊急性の高い変化の一つであり、最も無視されやすいものでもあります。セキュリティリーダーや政策立案者にとって、この研究内容は、論文やエンジニアリングブログに散在しており、専門的で理解が難しいため、対応するのは困難な場合があります。

そこで、Google の PQC 研究、エンジニアリングブログ、移行ガイダンスを 1 か所にまとめた、Gemini Notebook の公開ノートブック「ポスト量子暗号への準備」をリリースします。質問したり、音声解説を聴いたり、フラッシュカードで理解度をテストしたりして、量子脅威についてすばやく理解を深めましょう。

PQC が今重要な理由

量子コンピューティングは、理論から現実へと急速に移行しています。Willow チップと Quantum Echoes アルゴリズムは、大きな進歩を遂げています。Google Research の推定によると、ECDLP-256 と RSA-2048 の暗号化（オンラインデータの多くを保護する公開鍵暗号スキーム）を破るには、それぞれ約 50 万個と 100 万個の不完全な量子コンピュータコンポーネント（ノイズの多い量子ビット）が必要になります。

そこで、Google の PQC 研究、エンジニアリングブログ、移行ガイダンスを 1 か所にまとめた、Gemini Notebook の公開ノートブック「ポスト量子暗号への準備」をリリースします。

この研究内容は、現在すでに私たちに影響を及ぼしており、昨今のオンラインセキュリティが、将来の量子コンピュータに対して、これまで考えられていたよりも脆弱であることを示しています。

Store Now, Decrypt Later 攻撃は、攻撃者が暗号化されたデータを盗み、十分に強力な量子コンピュータが実現するまで待ってから、そのデータを復号するものです。医療記録、財務データ、知的財産、政府機密など、長年機密情報として扱われてきたデータは、すでに危険にさらされています。

アーキテクチャ、量子アルゴリズム、量子誤り訂正の継続的な進歩により、将来の量子ハードウェアの要件は縮小しているため、デジタルロックのアップグレードを待つことは、現実的な選択肢ではありません。組織が時代の先を行くことができるよう、Google は 2029 年までに PQC に移行する計画を記した移行タイムラインを公開し、他社にも同様の検討を促しています。

テクノロジーの進歩に伴い、政策立案者は、重要インフラの所有者や運営者に、タイムラインの短縮を認識し、既存のリスク軽減計画に PQC への準備を組み込むよう促すことを検討する必要があります。また、政府が世界各国の政府関係者と連携して、標準開発への調和のとれたアプローチを推進し、耐量子に焦点を当てた政策や規制要件の構築に技術やセキュリティの専門家を関与させることも Google は推奨します。

Google の PQC に関する専門知識を 1 つのノートブックに

「ポスト量子暗号への準備」ノートブックは、Google が長年培ってきた専門知識を、誰でも利用できるインタラクティブな入門書にまとめたものです。量子時代、量子コンピューティングのブレークスルー（Willow、Quantum Echoes、表面コードエラー抑制など）、業界の PQC 標準、Google 独自のデプロイ、最新の研究を網羅する、厳選された Google のソースに基づいて作成されています。

このノートブックでは、以下のことができます。

Google のソースに基づく回答を得る。
ポッドキャスト形式の音声解説を聴く。
フラッシュカードで PQC の理解度を確認する。
量子脅威のインタラクティブで視覚的な図を確認する。
簡潔な概要ドキュメントを読む。

以下のプロンプトをお試しください

まずは、ノートブックに次のような質問をしてみましょう。

CISO 向け:「CISO は PQC への移行の最初の 90 日間で何を優先すべき？」
PQC について詳しく知らないユーザー向け:「Store Now, Decrypt Later についてわかりやすく説明して。」
デベロッパー向け:「Chrome でのハイブリッド ML-KEM 鍵交換はどのような仕組み？」

すべての生成 AI と同様に、ノートブックも間違えることがあるため、リンクされたソースと照らし合わせて回答を確認してください。

直面しているリスク

SHA-1 からの移行や TLS のアップグレードなど、過去の暗号移行には 10 年以上かかっています。ウェブトラフィック、ソフトウェアアップデート、デジタル ID、署名などのデジタル要素を保護するうえで公開鍵暗号が重要であることを考えると、暗号解読に適した量子コンピュータが利用可能になるまで移行を待つことは、重大なセキュリティリスクとなります。

CISO の方は、まず以下のことを行うことをおすすめします。

組織内で暗号化が脆弱な場所を把握する。
量子脅威のリスクが最も高いデータとシステムを特定して優先順位を付け、これらのリスクに対処するための計画を策定する。
PQC への移行がシステム全体に及ぼす影響を予測する。
Heartbleed などの過去の経験から得た教訓を活かして、セキュリティ計画に暗号アジリティを組み込む。

これらの推奨事項の詳細については、以前のブログ投稿をご覧ください。

セキュリティコミュニティ全体で、この移行が成功するには、暗号化専門チームを持つ組織だけでなく、誰もがこの知識にアクセスできる必要があります。

Google が PQC を実現している方法

Google は長年にわたって PQC をデプロイしてきました。注目すべき点は以下のとおりです。

Google はまた、Amazon Web Services、Cisco、IBM、NVIDIA などの業界リーダーとともに、Linux Foundation で Post-Quantum Cryptography Alliance（ポスト量子暗号アライアンス）を共同設立し、Open Quantum Safe などのオープンソースツールをサポートしています。

チーム独自の PQC ノートブックを作成する

組織のニーズに合わせて、PQC に関する Google の Gemini Notebook のノートブックと同様のリソースを作成する方法は次のとおりです。

信頼できるソースをキュレートします。まずは、信頼できる研究、標準、ガイダンスを絞り込みます。
中立的なプロンプトを作成します。出力がソースを根拠とするように、指示は事実に基づくものにしてください。
AI の免責条項とウェルカムメッセージを追加します。ノートブックの内容を読者に伝え、AI が間違える可能性があることを注意喚起します。
すべての出力を人間の目で確認します。共有する前に、専門家にすべてのアーティファクトをチェックしてもらいます。

今すぐ準備を始めましょう

量子移行はすでに始まっていますが、組織の準備を始めるにあたり 100 ページのホワイトペーパーを読む必要はありません。まずは脅威を理解し、次に暗号インベントリを評価して、移行ロードマップを構築します。

今すぐ Gemini Notebook の「ポスト量子暗号への準備」ノートブックを確認し、チームと共有しましょう。PQC に対する Google Cloud のアプローチについて詳しくは、専用の Google Cloud PQC リソースハブをご覧ください。

aside_block: <ListValue: [StructValue([('title', '新しいことを学ぶ'), ('body', <wagtail.rich_text.RichText object at 0x7f7de97772d0>), ('btn_text', '今すぐ見る'), ('href', 'https://www.youtube.com/watch?v=Wpo-5ke9uvQ'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

その他の最新情報

セキュリティチームからこれまでに届いた今月のアップデート、プロダクト、サービス、リソースに関する最新情報は以下のとおりです。

マシンスピードの時代にビジネスのアジリティを確保する方法: 最新の脅威の状況について経営幹部が知っておくべきこと、セキュリティチームが取るべき対応、Google AI Threat Defense が役立つ理由について説明します。詳細はこちら。
Gemini 4 Argon が Google Cloud で利用可能に: Google の新しいフロンティアモデルである Gemini 4 Argon が、Google Cloud で誰でも利用できるようになります。防御側の優位性を高めるうえで、これがどのように役立つのかをご紹介します。詳細はこちら。
オンデバイス AI 向けの Android の次世代エンクレーブ: パーソナライズされたオンデバイス AI エクスペリエンスを実現する Android のエンクレーブアーキテクチャについて説明します。詳細はこちら。
Wiz Red Agent が、他のツールでは見逃されていた Fortune 500 企業のデータ漏洩を検出: Red Agent は、攻撃者の視点から、機密データを公開しているページを数分で発見しました。詳細はこちら。
最近の ccTLD レジストリのハイジャックに対する Chrome の対応: 最近発生した .gh、.sl、.as ccTLD ドメインのハイジャックを受け、Chrome は CRLSet を通じて不正な HTTPS 証明書を即座にブロックし、ユーザーを自動的に保護しました。詳細はこちら。
Wiz Blue Agent の視点: AWS と GitHub にわたるデータ盗難の調査: Blue Agent が AWS と GitHub にわたる証拠を追跡し、侵害された認証情報、盗まれたソースコード、カスタムのデータ引き出しツールを明らかにして、マルチプラットフォーム攻撃を数分で調査した方法をご覧ください。詳細はこちら。
Wiz AI SAST のご紹介: ユーザーを理解するアプリケーションセキュリティ: Wiz Research によって支援され、既存のセキュリティプログラムで運用化されている AI コードスキャナを使用して、複雑なビジネスロジックの欠陥を検出、検証、修正します。詳細はこちら。
Kubernetes サプライチェーンを保護する WizOS Helm チャートの導入: WizOS Helm チャートは、Kubernetes 向けに強化、署名された、CVE スキャン済みのチャートにより、隠れた CI / CD リスクやメンテナンスされていない依存関係を排除するのに役立ちます。詳細はこちら。
Wiz サービスカタログの新機能: よりスマートな検出、ガバナンス、サービスレベルのコンテキストにより、サービスカタログをより迅速に構築し、サービスコンテキストを最新の状態に保ち、クラウドのリスクからアカウンタビリティまでの明確な道筋をチームに提供できます。詳細はこちら。

今月公開されたその他のセキュリティ関連の記事については、Google Cloud 公式ブログをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud CISO Community にご参加ください'), ('body', <wagtail.rich_text.RichText object at 0x7f7de9bab950>), ('btn_text', '詳細'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

脅威インテリジェンスに関するニュース

AI 時代の脆弱性の発見と悪用の傾向: 脆弱性の迅速な発見と悪用によるリスクの増大に対抗するには、優先順位がないパッチの一括適用から、脅威インテリジェンスに基づくトリアージに移行し、標的型のエッジ防御とエージェントによる自動修復を組み合わせる必要があります。詳細はこちら。
Citrix NetScaler ADC および Gateway アプライアンスの脆弱性のアクティブな悪用に対する防御: Mandiant Consulting と Google Threat Intelligence Group（GTIG）は、Citrix NetScaler ADC および NetScaler Gateway アプライアンスに影響を及ぼすゼロデイ脆弱性のエクスプロイトが実際に行われていることを確認しました。封じ込めと修復のガイダンスをご紹介します。詳細はこちら。
ShinyHunters、Oracle PeopleSoft を標的とした大規模な脆弱性悪用キャンペーンを再開: Mandiant と Google Threat Intelligence Group（GTIG）は、UNC6240（ShinyHunters）による CVE-2026-35273 の大規模な悪用キャンペーンの再開と、複数のセクターにわたる世界的な標的の拡大を確認しました。詳細はこちら。
コードパイプラインと CI / CD インフラストラクチャの堅牢化によるプロアクティブな防御: ソフトウェア開発ライフサイクル全体を通じて、現在進行形で悪用されている脅威ベクトル、サードパーティのリスク、およびアーキテクチャ上の脆弱性からソフトウェアサプライチェーンを保護するために設計された、ソフトウェア / プラットフォームアーキテクト向けの実践的なガイドラインをご覧ください。詳細はこちら。

今月公開されたその他の脅威インテリジェンス関連の記事については、Google Cloud 公式ブログをご覧ください。

注目の Google Cloud ポッドキャスト

Cloud Security Podcast: AI、エージェント、Rust、タブを使用したブラウザのパッチ適用: Chrome Security の Jasika Bawa と Doug Turner が、Google Chrome が AI エージェントを使用して、これまでにない規模でセキュリティの脆弱性を自律的に特定してパッチを適用し、ブラウザのアップデート頻度を大幅に向上させている方法について説明します。ポッドキャストを聴く。
Cloud Security Podcast: Wiz の AI 脆弱性調査プロジェクト Atlas のすべて: Wiz の脆弱性調査責任者である Nir Orfeld 氏が、クラウドインフラストラクチャにおける深刻なゼロデイ脆弱性を発見するために、チームがマルチエージェント AI システムをどのように活用しているかを詳しく解説します。ポッドキャストを聴く。
Cloud Security Podcast: 脆弱性のクラスを大規模に根絶する Google の手法: AI がコードを記述し、人によるレビューが追いつかない状況下でも、セキュリティを維持できる Google 規模のセキュアなエンタープライズ基盤を構築するにはどうすればよいでしょうか。Google のプリンシパルセキュリティエンジニアである Christoph Kern が、AI 時代における「安全性を重視した設計」の真の意味を探ります。ポッドキャストを聴く。

月 2 回発行される「Cloud CISO の視点」をメールで受信するには、ニュースレターに登録してください。次回も Google Cloud からセキュリティ関連の最新情報をお届けします。

- Google Cloud、クラウドセキュリティポリシー、政府関連業務および公共政策責任者、Stephanie Kiel

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティエージェントと AI 防御機能を提供

Tue, 06 Oct 2026 18:00:00 +0000

※この投稿は米国時間 2026 年 9 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

脅威アクターが AI を利用してサイバー攻撃を加速、開発するケースが増えるなか、企業の防御者は AI と、防御者にとって重要な強みである「自社だけが持つビジネスコンテキスト」の両方を活用する必要があります。

企業のサイバー防御は、ID、ネットワーク、エンドポイント、データ、クラウド、アプリケーションの各レイヤにまたがっており、多くの場合、12 種類以上のプロダクトに分散し、それぞれが独自のコンテキストを持っています。Google Cloud Next では、パートナーが構築したエージェントを Gemini Enterprise に組み込み、セールス、コンテンツおよびクリエイティブワークフロー、人事、セキュリティなどの機能にわたり、専門エージェントを 1 か所で検出してデプロイできるようにしました。

このたび、Gemini Enterprise エコシステムでパートナーが構築したセキュリティサービスカタログを拡充し、単一の統合インターフェースからセキュリティコンテキストを最大限に活用できるようにいたしました。

主要なサイバーセキュリティベンダーが提供するこれらの新たなセキュリティエージェントとインテグレーションは、チームが Gemini Enterprise で直接呼び出すパートナー製セキュリティエージェントと、AI およびエージェント型ワークロードの保護という 2 つの領域にわたっています。これらを Gemini Enterprise に組み込むことにより、Gemini Enterprise 環境で直接、複数ステップのセキュリティワークフローをオーケストレーションできるようになり、AI を活用した機能を防御に取り入れることが可能になります。

Gemini Enterprise で構築された、新たなセキュリティエージェントとエージェント型防御のご紹介

Acalvio: Gemini Enterprise からアクセスできる Acalvio ShadowPlex ディセプションエージェントは、企業ネットワーク全体へのデコイとハニートークンのデプロイを自動化し、ディセプションガードレールを顧客の運用環境に直接埋め込みます。手動での構成は不要です。ShadowPlex は、ネットワークデコイ、ID ハニーアカウント、検索拡張生成（RAG）デコイ、ハニースキル、ハニートークンを大規模にデプロイし、不正なインタラクションを迅速に捕捉します。

Britive: Gemini Enterprise を基盤とする Britive Emergency Termination Agent を使用すると、セキュリティチームは複数のコンソールを操作することなく、単一の自然言語リクエストから、侵害された人間または人間以外の ID を封じ込めることができます。このエージェントは、ID を確認し、アクティブな特権セッションをすべて一覧表示して、人間の承認を得てすべてのセッションを取り消し、ID を無効にして、インシデントチケットの監査コンテキストを収集します。その結果、エージェントの厳格なガバナンスと最小権限アクセスを維持しながら、封じ込めまでの平均時間（MTTC）を大幅に短縮できます。

Check Point: Google Cloud Agent Gateway および Agent Registry と統合された Check Point AI Defense Plane は、エンタープライズ規模の AI で必要とされる重要なセキュリティ管理と可視性を提供します。組織は、AI ワークロードの検出、リスクポスチャーのモニタリング、コンプライアンスに違反する動作の検出に加えて、プロンプトインジェクション、データ漏洩、エージェントの不正な挙動に対するリアルタイムのガードレールの適用が可能になります。Gemini Enterprise 内の Check Point Agent を通じて管理されるこの統合ソリューションは、Gemini Enterprise での AI ワークロードのデプロイを保護し、高速化します。

CrowdStrike: CrowdStrike Falcon® Guardian は、Agent Gateway と統合することでガードレールとランタイム保護を拡張し、Gemini Enterprise で実行されるエージェント型ワークロードをプロンプトインジェクション、機密データの漏洩、悪意のある AI アクティビティなどのリスクから保護します。さらに、CrowdStrike Gemini Enterprise エージェントにより、実務担当者は Gemini Enterprise を通じて CrowdStrike プラットフォームを操作できます。これにより、CrowdStrike のセキュリティコンテキストをエージェント型の調査と対応に組み込み、多数のツールにわたる SOC ワークフローのオーケストレーションを支援します。

Cyberhaven: Cyberhaven Linea エージェントは、エンドポイント、クラウドアプリ、エージェント型ワークフロー全体にわたる機密データの検出と分類を Gemini Enterprise で可能にします。Cyberhaven のデータリネージモデルを活用したこのエージェントは、平易な言葉で表現された意図を適用可能なポリシーに変換し、インタラクションをモニタリングして、マッピングされていないリスクを侵害が発生する前に捕捉します。また、証拠の自動収集により調査が迅速化します。Gemini Enterprise の Antigravity 全体にわたり、Linea エージェントはアラート疲れを解消し、自律型エージェントが機密性の高いアセットを移動するのと同じ速さでセキュリティチームがそれらを保護できるようにします。

Cyera: Gemini Enterprise を基盤とする Cyera Agent Guardian は、Gemini で実行されるエージェントを保護し、データセキュリティポスチャー管理（DSPM）とデータ損失防止（DLP）を提供します。Cyera エージェントは、マシン ID、委任された権限、機密データの分類を相互に関連付け、承認されたエージェント型の動作を検証できるため、組織はエージェントを安全にデプロイし、エンタープライズ規模で運用コンプライアンスを維持できます。

Endor Labs: Endor Labs AURI エージェントは、デベロッパーとセキュリティのワークフロー全体に AI ネイティブのアプリケーションセキュリティをもたらします。同社の静的アプリケーションセキュリティテスト（SAST）トリアージエージェントは、Google Antigravity などのデベロッパープラットフォーム内でコードから検出された問題を自動的に分類し、優先順位を付けることができます。Gemini Enterprise では、セキュリティチームはこれらの検出結果を会話形式でクエリして対応できます。実際に悪用可能なものを確認し、修正を追跡することが可能で、そのすべてが Endor Labs アプリケーションのコンテキストに基づいています。

Exabeam: Exabeam は、Gemini Enterprise を基盤とする次世代の Exabeam Nova を導入しています。これは、セキュリティチームが脅威をより迅速に調査して対応できるようにする、統合マルチエージェント AI システムです。Nova は、ワークフロー全体で共有されている運用コンテキストを維持しながら、行動の分析、リスクの優先順位付け、調査の実施、対応アクションの誘導を行うことができる、専門の AI エージェントと連携します。その結果、アナリストはよりインテリジェントで効率的なエクスペリエンスを得ることができ、組織は既存のセキュリティ運用環境からより大きな価値を引き出すことができます。

Fastly: Fastly Autonomous Edge Defense Agent（AEDA）を使用すると、セキュリティチームは Gemini Enterprise 内で、ログを手動で解析する代わりに、エッジやインフラストラクチャのインシデントを平易な言葉で調査できます。AEDA は、組織独自のテレメトリーと Fastly のグローバルな顧客ベースから得た匿名化されたインテリジェンスを組み合わせ、異常は単発的なものなのか、より広範な攻撃の一部なのかを数秒で判断し、証拠に裏付けられた調査結果と推奨される修正策を返します。

Fortinet: Fortinet FortiAIGate は、Google Cloud のお客様に大規模言語モデル（LLM）のランタイム保護を提供します。Gemini Enterprise と統合され、Google Cloud 環境にデプロイされた FortiAIGate は、組織が高度なエージェント型 AI アプリケーションをデプロイできるよう支援します。これにより、データ、プロンプト、モデルとのインタラクションを新たな脅威から積極的に保護できます。

Menlo Security: Gemini を使用して構築された HEAT Shield Agent は、ウェブコンテンツを分析し、実行時にゼロデイ脅威やプロンプトインジェクションをブロックします。これに加えて、Gemini Enterprise を基盤とする Menlo Security Orchestrator が、セキュリティオペレーションセンター（SOC）のレスポンスを自然言語によるエージェント型ワークフローに変換します。これは、攻撃の再構築、影響範囲の特定、ポリシーの適用を、数時間ではなく数秒で行うことができます。Menlo Agent Runtime Security（MARS）は、このループを完結させ、人間とエージェントおよびエージェント同士のインタラクションを保護することで、エージェント型ワークロード全体で検出と封じ込めが統合された状態を維持します。

Obsidian Security: Gemini Enterprise で Obsidian Security の Risk Analyzer エージェントと Breach Response エージェントを使用すると、セキュリティアナリストはリスクを評価し、侵害に対応できるようになります。組織のクラウドと AI ネイティブアプリケーションポートフォリオを保護するために構築された Obsidian エージェントは、企業環境全体にわたり AI エージェントを検出し、リスクを評価して、ガバナンスのギャップを報告します。また、どのエージェントが昇格された権限や書き込みアクセス権を持っているかといった重要な質問に答えます。

Palo Alto Networks: Palo Alto Networks のクラウド、ネットワーク、AI リスク評価（CLARA）エージェントは、開発のペースを落とすことなく、重要なデータとコンプライアンスを確保した AI 運用を保護できるよう、セキュリティチームを支援します。クラウドインフラストラクチャと AI ワークロードを継続的にスキャンし、隠れた脆弱性を自動的に検出して修正の優先順位を付けることで、クラウドや AI のリスクが侵害に発展する前に発見して修正できます。これにより、セキュリティチームは脅威の検出に費やす時間を減らし、脅威の解消により多くの時間を費やすことができるようになります。

Ping Identity: Gemini Enterprise で利用可能になった Ping Identity の新しい PingID セルフサービスエージェントを使用すると、従業員は多要素認証（MFA）のリセットやデバイスの復元など、ID やデバイスに関する一般的な問題を自然言語で質問して解決できます。ヘルプデスクのチケットは不要です。PingOne を基盤とする、セキュアな委任認証を備えた PingID セルフサービスエージェントは、従業員の ID を管理するためのエンタープライズ対応の手段を IT チームに提供すると同時に、サポート費用の削減とオンボーディングエクスペリエンスの向上を実現します。

Qualys: Qualys ROCky for Gemini Enterprise は、セキュリティチームが Gemini Enterprise 内で会話を使用して脆弱性を管理し、パッチを適用するのに役立ちます。「Log4Shell の影響はどの程度か」、「まず何を修正すべきか」、「CISA KEV の期限を守れているか」といった質問をすると、Qualys TruRisk スコアに基づいてランク付けされた回答が得られます。各ユーザーが所有する Qualys の利用資格に基づいて動作するため、誰でもサポートなしで自ら回答を得ることができます。また、パッチのステージングとデプロイも行えます。

Splunk（Cisco 傘下）: Gemini Enterprise と統合された Splunk Security AI エージェントは、膨大なテレメトリーストリームをセキュリティデータとオブザーバビリティデータ全体にわたるリアルタイムインテリジェンスに変換する自律システムとして機能します。手動によるトリアージを省略して、重大な異常やシステム脅威を即座に表面化させることで、チームは事後対応型の調査からプロアクティブな防御へと転換できます。これにより、プレッシャーの大きなインシデント発生時の認知負荷が軽減され、セキュリティチームはリスクをより迅速に解決できるようになります。

Synk: Gemini Enterprise と Antigravity を使用して構築しているすべての企業が、かつてない速さでコードをリリースしています。Snyk は、コードが作成された後ではなく作成されたその瞬間から、コードがセキュアであることを保証します。Snyk は、AI エージェントが生成したものをリアルタイムで検証し、脆弱性やセキュアでない依存関係がリポジトリに到達する前に検出します。これは、AI がコードを記述する速度に合わせて構築されたセキュリティです。人がかつて記述していた速度に合わせたものではありません。

Thales: Gemini Enterprise と統合された Thales AI Security Fabric は、エージェント型 AI のインタラクション全体にわたって可視性、ランタイム保護、一元化されたガバナンスを提供します。組織は、エージェント型 AI を試験運用から本稼働に移行し、きめ細かなアクセスポリシーを適用して、重要なデータアセットを実行環境で直接保護できます。

Transmit Security: Gemini Enterprise を基盤として構築された Transmit Security Agent Intelligence は、顧客向けアプリケーションとやり取りを行うエージェント型アクティビティを特定します。ユーザーがタスク、トランザクション、権限を AI エージェントに委任することが増えるにつれ、組織は、そのアクティビティの内容、発生元、意図を明確に把握する必要があります。こうしたコンテキストを把握することで、企業は正常なエージェントと悪意のあるエージェントを見分け、許可すべきものとブロックすべきものを判断し、正当な取引を制限することなくリスクを未然に防ぐことができます。

Zscaler: Zscaler Risk360 は、既存の Zscaler のデプロイからデータを取り込み、サイバーリスクを定量化し、リスクポスチャーの詳細なビューを作成して、リスクを軽減するための明確な分析情報を提示する、包括的かつ実用的なフレームワークを提供します。Risk360 Agent は、Gemini Enterprise を使用した ZAgent フレームワーク上に構築された AI 搭載コンパニオンです。自然言語によるやり取りを使用して、Zscaler とパートナーからのシグナルの統合、ゼロトラストリスクの分析、財務的影響の定量化、緩和策の推奨、意思決定に役立つ分析情報を提供します。

パートナーが構築したエージェントやコネクタのエコシステムが拡大する中、Gemini Enterprise は、お客様がすでに利用しているセキュリティツールと連携し、それらを基盤としてカスタムエージェント型ワークフローを構築できるようにします。Google Cloud Marketplace で、現在利用可能なセキュリティエージェントを今すぐご確認ください。

- セキュリティおよび ID パートナーシップ担当ディレクター、Vineet Bhan

- セキュリティ担当パートナーエンジニアリング責任者、Ashish Verma

Secure Source Manager の新機能で CI / CD パイプラインを強化

Thu, 01 Oct 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

レジリエンスを備えたソフトウェアサプライチェーンは、最新のデリバリーの基盤であり、継続的インテグレーションと継続的デリバリー（CI / CD）パイプラインを保護することこそが、イノベーションを安全に推し進める原動力となります。

Wiz の最新のクラウド脅威ハイライトレポートによると、2026 年上半期の注目すべきサプライチェーン攻撃は、2025 年下半期と比較して 2 倍以上に急増しています。

プライベートクラウドにおいて、ソースコードが最も脆弱な部分にならないようにすることが重要です。ソフトウェアサプライチェーンの脅威に、より効果的に対処できるよう、Google Cloud Secure Source Manager（SSM）では、統一された認証と認可の仕組みを使用して、ソースコードと CI / CD システムを管理できます。

Google は、開発と CI / CD ワークフローを簡素化し、セキュリティを高める 2 つの新機能の一般提供を開始しました。

CI / CD システムへの不正アクセス: 攻撃者は、デプロイスクリプトをたった 1 つ改ざんするだけで、CI / CD パイプラインをマルウェアの拡散ルートに変貌させてしまいます。このリスクを軽減するため、SSM は、バージョン管理システムからビルドやアーティファクトのシステム、デプロイツールに至るまで、たとえ企業ネットワークが侵害された場合でも、CI / CD システムへの不正アクセスをブロックできるようになりました。
権限を持つユーザーによるコードの不正な変更: 新しい Code Owners システムは、ファイル単位、ブランチ単位で pull リクエストの承認者セットを管理し、よりきめ細かい Identity and Access Management（IAM）を提供します。Code Owners は、コードの記述、編集、レビューを行うエンジニアを支援します。リポジトリ内のファイルとディレクトリに、ファイル単位またはブランチ単位で追加の保護ルールを適用します。

主な機能

CI / CD パイプラインへのソースコード変更をはじめとして、新しい Code Owners 機能はきめ細かいマージガードを提供します。CODEOWNERS ファイルをリポジトリにチェックインすることで、必要な承認者を極めて詳細に指定できます。

パスごとの承認者セット: 柔軟な glob スタイルのパス指定子を使用して、一致するファイルへの変更に対して、指定されたユーザーセットの 1 人以上による承認を必須にすることができます。
ブランチ固有のガバナンス: セキュリティルールとデプロイルールをブランチ間でスムーズに管理できます。同じファイル内で main や dev に異なるオーナーを定義できるため、既存の CODEOWNERS ソリューションで発生するマージコンフリクトを解消できます。詳しくは、こちらのドキュメントをご覧ください。
ネスト可能な複数ファイルのオーナー設定: 5,000 行にも及ぶような巨大なルートファイル 1 つに縛られる必要はありません。CODEOWNERS ファイルはサブディレクトリにネストできます。SSM は「ローカル優先」ロジックを採用しているため、サブチームがそれぞれのフォルダのオーナー権限を持ちつつ、ルート管理者はリポジトリ全体に対する拒否権を維持できます。
独立した承認セクション: [SectionName][count] 構文（例: [Security Team][2]）により、1 つの pull リクエスト（PR）において、複数の部門からの個別の承認を同時に義務付けることが可能になります。PR 自体はチームのメンバーによってレビューされても、セキュリティチームのメンバー 2 人による承認が揃うまではマージできないようになっています。

ソースコードの準備が整ったら、SSM の新しい Developer Connect 連携により、CI / CD システムとランタイムが異なるプライベートネットワークにある場合でも、セキュアかつ簡単に接続できるようになります。

プライベート CI / CD ブループリントのアーキテクチャは、セキュアな接続経路を採用しています。Secure Source Manager が Private Service Connect に接続し、そこからさらに Cloud Build へと接続されます。リポジトリ、ビルドプール、アーティファクトストレージはすべてプライベートネットワーク内に配置され、VPC Service Controls（VPC-SC）が多層防御を提供することで、プロキシエンドポイントへのアクセスを制限します。

次のステップ

ネットワークを保護するには、新しいプライベートネットワークの統合ガイドに沿って、Developer Connect を使用して SSM を Cloud Build に接続します。

pull リクエストの承認を保護するには、ルート CODEOWNERS ファイルを作成して、一律の IAM「承認者」ロールを、ファイル固有のオーナー権限に置き換えます。

- Google Cloud、プロダクトマネージャー、Logan Henriquez

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

Thu, 01 Oct 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

AI は、かつてないペースでソフトウェア開発を加速させています。しかし、コード生成が拡大するにつれて、コードのセキュリティを確保する課題も増大しています。特に、AI を利用した新たな脆弱性の悪用が懸念されています。こうした課題に対処するため、Google AI およびインフラストラクチャチームは、セキュリティへの取り組み方を変革しています。この記事では、Google が開発した新しい AI ネイティブなエージェント手法について説明します。この手法は、高精度で網羅的な脆弱性スキャンとパッチ適用を、Google のソフトウェア開発ライフサイクルに体系的かつ直接組み込むものです。Google は、インフラストラクチャにデプロイされる数億行に及ぶコードのあらゆる変更を継続的にスキャンすることで、毎月数百件もの脆弱性がコードベースや本番環境に混入するのを未然に防ぎ、グローバルネットワーク、AI インフラストラクチャ、そしてユーザーを保護しています。

ソリューションアーキテクチャと実装

送信前のエージェント型スキャンを徹底: 継続的なソフトウェア開発の一環としてのセキュリティ

従来、テクノロジー業界は、処理に時間がかかり、十分なコンテキストを把握できない単発の大規模なセキュリティスキャンに頼ってきました。その結果、脆弱性の発見が遅れることがよくあります。Google のアプローチでは、これとは異なり送信前スキャンに焦点を当てています。AI エージェントを活用し、スタックのあらゆるレイヤにおいて、コードのチェックインをリアルタイムで評価します。デベロッパーの使い慣れたツールに送信前スキャンを統合することで、セキュリティは、ルールチェッカーや可読性レビューなどのソフトウェア開発ツールと同じように、開発プロセスにおける日常的なルーティン作業になります。また、AI の観点から見ると、個々のコード変更をスキャンする方が、大規模な 1 回限りのスキャンを実行するよりもはるかに少ないコンテキストで済むため、スキャンの効果が大幅に向上します。

ローカライズされた脅威モデルの重要性

この取り組みのために、Google はオープンソースのマルチエージェントレビューハーネスである Mantis を進化させ、ローカライズされた堅牢な脅威モデルのコホートと照合することで、セキュリティエージェントの精度を高めました。脅威モデルは、コードから切り離された静的なドキュメントに依存するのではなく、リアルタイムのコードベースメタデータを使用します。スキャンエージェントは、パッケージやライブラリ間の依存関係コールグラフを使用し、脅威モデルのコンテキストを拡張および洗練させることで、精度をさらに向上させます。脅威モデルを継続的な脆弱性スキャンの一部に組み込むことで、開発者が脅威や依存関係を常に更新するようになり、モデルを最新の状態に保つことができます。ローカライズされた正確な脅威モデルデータを使用することは、精度の劇的な向上に直結しており、場合によっては偽陽性率をわずか 3% にまで抑えることができます。

専門のトリアージエージェントが開発を加速

コードチェックインの一環として脆弱性スキャンを行う場合、エンジニアリングの生産性を妨げないよう、コードを生成する開発者やエージェントに迅速に対応する必要があります。低レイテンシで回答を得るために、2 段階の検証プロセスを実行しています。まず、迅速な軽量スキャンを実行し、その結果を専門のトリアージエージェントで検証します。このエージェントは、コードの実際の構造をプログラムでチェックし（抽象構文ツリーの解析、コールグラフの走査、事前インデックス化されたドメイン安全ルールを使用）、脆弱なパスが実際に攻撃者によって到達可能であることを証明します。このエージェントは 92% 以上の精度を達成し、1 分以内に作業を完了します。次に、夜間の統合テストの一環として、送信後のスキャンが第 2 の防御層として機能し、オフピークサイクルを使用して、複数の変更にわたって導入された可能性のある脆弱性をテストします。

バグ修正エージェントがループを閉じる

脆弱性を見つけることは、解決への道のりの半分にすぎません。Google のソリューションの最後のコンポーネントは、スキャン結果と生成された実証コード（脆弱性がどのように再現されるかを示すコードスニペット）を使用して、Google の社内コーディング標準に合致した正確な修正案を自律的に生成する自動バグ修正エージェントです。エージェントは、元の変更リクエストのレビューの一環として、人間によるレビューのために修正を送信します。これにより、検出から解決までの時間がさらに短縮されます。

学んだことと行動喚起

継続的なスキャンをソフトウェア開発ライフサイクルに直接組み込むことは、Google においてまさにゲームチェンジャーとなりました。AI が提示する修正案は広く採用されており、数多くの脆弱性がコードベースに混入するのを未然に防いでいます。セキュリティ向上を目指す組織であれば、次の原則に従うことで、同様の AI ネイティブなアプローチを導入することが可能です。

システムを分離する: バイアスを防ぐため、開発、スキャン、トリアージの各エージェントのハーネス、ルール、コンテキストを分離します。軽量な AI スキャンと決定的かつ構造的な検証を組み合わせることで、レイテンシを短縮し、精度を向上させます。
コンテキストを賢く使用する: 既存の脅威モデルをエージェントにフィードします。偽陽性を減らすには、正確なコンテキストが不可欠です。また、最新の脅威モデルを使用することで、送信前スキャンの真陽性率が向上し、チームのセキュリティポスチャーの最低基準が引き上げられます。
優れたハーネスを構築する: 基盤となるモデルの選択は重要ですが、マルチエージェントハーネスを使用すると、モデル選択のばらつきを補うことができるため、大きな効果が得られます。
修正を自動化する: エージェントを使用して、人間参加型の修正を提案し、解決までの時間をさらに短縮します。

独自の AI ネイティブなセキュリティ変革を始めたい場合は、Mantis がオープンソースとして公開されていますので、ぜひ活用してそのメリットをお役立てください。また、サイバーセキュリティの基礎や、このエージェント型パイプラインを支える他のプラットフォーム（Google Cloud、Gemini Enterprise、Trillium および Ironwood TPU で実行される Gemini モデル）についても詳しく学ぶことができます。また、Google Cloud のセキュアなソフトウェア開発のライフサイクル（SDLC）の取り組みに不可欠な要素として、エージェント型の脆弱性スキャンと修復が Google Cloud のお客様をどのように保護しているかについても、ヒントを得ることができます。

^{この成果の実現に多大な貢献をした主要メンバーである、Stella Voutsina（リードプログラムマネージャー）、Yulong Zhang（シニアスタッフセキュリティエンジニア、Mantis）、Nick Galloway（スタッフセキュリティエンジニア、Mantis）に心からの敬意を表します。}

- Google、上級エンジニア、Andrés Lagar-Cavilla

- バイスプレジデント兼エンジニアリングフェロー、Parthasarathy Ranganathan

きめ細かい制御が可能な、新しいネイティブセッション管理ツールのご紹介

Mon, 28 Sep 2026 16:00:00 +0000

※この投稿は米国時間 2026 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のセッション管理では、組織のセキュリティポリシーのニーズに基づいてセッション管理を設定できる柔軟なオプションを提供しています。その一環として、セキュリティポスチャーの向上と、認証情報の窃取やアカウント乗っ取り（ATO）リスクの軽減を目的に、Google Cloud をご利用のお客様向けに、デフォルトのセッション時間を 16 時間に設定してロールアウトしました。

このセキュリティ標準は、セッション時間を独自に設定していなかったすべてのお客様への適用を完了しましたが、今日のクラウド環境ではさらに高い精度が求められています。このグローバルロールアウトの完了に伴い、Google Cloud のセッション管理も、広範な管理設定から、コンテキストアウェアアクセス（CAA）の緊密に統合されたきめ細かい機能へと進化しました。

このアップデートにより、管理者はより柔軟に、より優れた自動化を実現し、より自然なセキュリティワークフローを構築できるようになりました。

セッション管理の新機能

1. 自動化ファースト: Terraform、gcloud、API のサポート最新のインフラストラクチャはコードとして管理されます。DevSecOps ワークフローをサポートするため、セッション管理ポリシーの設定は、UI からの手動設定に限定されなくなりました。一般提供が開始されたことにより、以下を使用してプログラムでセッションポリシーを定義、デプロイ、管理できるようになりました。

Terraform: セッション管理をインフラストラクチャマニフェストに直接統合します。
gcloud CLI: コマンドラインからポリシーを管理します。
REST API: 複雑なマルチテナント環境全体でポリシーの適用を自動化します。

2. Google グループによるきめ細かいターゲティング最も要望の多かったアップグレードの一つは、ポリシーを正確にターゲティングする機能でした。以前は、セッション継続時間は組織部門（OU）に関連付けられていました。一般提供が開始されたセッション管理ポリシーでは、Google グループを使用できるようになりました。

この変更により、組織階層内のユーザーの場所に関係なく、特定のユーザークラスタに異なるセッションポリシーを適用できます。たとえば、権限昇格されたユーザー（課金管理者やプロジェクトオーナーなど）には 2 時間のセッションを適用し、一般の開発者には標準の 16 時間のセッションを維持できます。

3. アプリケーションの精密な制御セッション管理ポリシーでは、Google Cloud API スコープを必要とするすべてのアプリケーションに影響する包括的なポリシーではなく、特定のアプリケーションに対して個別にセッション管理を設定できます。これらのアプリケーションには、以下が含まれます。

Google Cloud コンソール
gcloud コマンドラインツール
特定の OAuth アプリケーション

一般提供が開始されたこのアップデートにより、「全か無か（オール・オア・ナッシング）」といった極端なシナリオを防ぐことができます。たとえば、Cloud SDK に厳格なポリシーを適用した結果、OAuth を利用している正当なビジネスインテリジェンスやダッシュボードとの連携まで意図せず遮断されてしまう、といった事態を回避できます。

4. Google Cloud ネイティブのエクスペリエンスこれまで、Google Cloud のセッション継続時間の設定は、Google Workspace 管理コンソールでしか行えませんでした。

Google Cloud のお客様は、お申し込みいただくことで Google Cloud コンソールを使用できるようになり、Access Context Manager（ACM）の他のアクセスレベルやセキュリティバインディングと合わせて、セッションポリシーを管理することも可能になります。プレビュー版として提供されるこのアップデートにより、Google Cloud コンソールでのポリシー管理を好む管理者は、すべての CAA ポリシーをより柔軟に、そして統一された操作感で設定できるようになります。

ご利用方法

セッション制御を静的な組織のデフォルト設定から、動的なコンテキストアウェアポリシーへと進化させることで、セキュリティチームは開発スピードを損なうことなく、最もリスクの高い場面において、認証情報の窃取に対する再認証の制限を厳格化できます。

Terraform、REST API、gCloud を使用してセッション管理を構成する方法については、セッション管理に関するドキュメントをご覧ください。

- プロダクトマネージャー、Senzeni Mpofu

- ソフトウェアエンジニア、Cris Scruggs

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

Wed, 09 Sep 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

AI モデルは、人間の手をほとんど、あるいはまったく介さずに脆弱性を発見して悪用する能力を持っていることが判明しています。防御側が AI を活用して優位性を確保できるよう、Google はソフトウェアの脆弱性の発見、トリアージ、再現、パッチ適用を自動化する Mantis ハーネスを構築しました。

誰でも利用可能なオープンソースフレームワークである Mantis は、マシンスピードでの脆弱性の発見と修正を実現するための Google の社内アプローチの一環として誕生しました。Mantis により、より効果的でスケーラブルかつコンテキストを考慮したリポジトリ分析が可能になります。

AI コードスキャンは精度が低く、ハルシネーションを起こすことが多いため、真陽性率は 7% を下回ります。Mantis は、批評エージェントやレビューエージェントなどの業界標準のエージェント手法とサンドボックス環境での脆弱性の再現を組み合わせてグラウンディングを行うことで、実効性を持たせた設計になっています。

6 月に公開した記事で詳しく解説したとおり、Mantis はリポジトリの履歴を調べて過去のセキュリティに関する修正から学習し、アーキテクチャと脅威モデルのドキュメントが提供されていない場合でも、それらのドキュメントを自動的に作成します。

階層型のセキュリティサマリーツリーを構築し、個々のファイルをディレクトリレベルとルートレベルのサマリーに集約します。この手法により、大規模なリポジトリ全体で重要な構造コンテキストを維持しながら、トークンのオーバーヘッドを 85% 以上削減することに成功しました。

Google が数十年の期間をかけて幅広いコードベースにわたって蓄積してきたサイバーセキュリティの専門知識の結晶である Mantis は、GitHub で入手可能です。Mantis の使用を開始する方法は次のとおりです。

まず、次のコマンドを使用して Mantis リポジトリのクローンをローカルに作成します。

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/google/mantis.git'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f7de955cb50>)])]>

次に、任意のコーディングエージェントを開き、「path/to/mantis にある Mantis フレームワークを使用して、path/to/your/code にあるコードをレビューしたいのですが、やり方を教えてください」というプロンプトを入力します。

Google 社内では、このプロンプトを使用して、多くのコードリポジトリで実際の脆弱性を発見しています。GitHub の Mantis リポジトリには、サンドボックス化のサンプルオプションが含まれています。自社のワークフローに合わせて独自のサンドボックスを実装することもできます。

Mantis は、脆弱性の検出、真陽性のフィルタリング、パッチ適用を簡単に開始できるようにすることを目的としています。AI が検出した脆弱性を把握したら、新しい mantis-advise スキルを使用して、蓄積された知識を活用し、コーディングエージェントに最初から安全なコードを記述させることができます。

AI を活用した脆弱性検出を最大限に活用して開発手法をモダナイズするにあたって、以下に示す 2 つの重要事項の実行を推奨します。

ツールに適切なコンテキストを提供する。Mantis はコミット履歴とコードを自動的に分析してドキュメントを独自に作成することができますが、人間によってキュレートされた知識を得ることで、結果の品質が大幅に向上することがよくあります。たとえば、プログラムをクラッシュさせるようなバグの修正に時間を取られないようにするには、スキャンパイプラインでそうしたバグを確実に検出できるよう、人間によってキュレートされた知識を提供することが非常に重要になります。
脆弱性受け入れ基準を使用してサイバーサンドボックスを構築する。明確な脆弱性再現基準に基づいて脆弱性を再現できる安全なサンドボックス環境を使用すると、知るべきことのみを明らかにし、修正が正しいことを確認することが容易になります。

Mantis について詳しくは、こちらをご覧ください。

- Google、スタッフセキュリティエンジニア、Nick Galloway

- Google、シニアスタッフセキュリティエンジニア、Yulong Zhang

Cloud KMS における耐量子鍵インポートの発表

Wed, 09 Sep 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 8 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

企業の間でマルチクラウドアーキテクチャの採用が広がるなか、Bring Your Own Key（BYOK）は、データ主権の維持と重要なクラウドワークロードの保護において不可欠な柱となっています。同時に、量子コンピューティングは急速に進歩しており、セキュリティチームは、ネットワーク間で暗号鍵を安全に転送する方法を再評価する必要があります。

Cloud Key Management Service（Cloud KMS）における耐量子デジタル署名と耐量子鍵カプセル化メカニズム（KEM）の発表に続き、このたび、ソフトウェアベースの暗号鍵を対象とした Cloud KMS における耐量子鍵インポートのプレビュー版をリリースしました。

ポスト量子暗号（PQC）移行タイムラインの次のフェーズの第一歩となる、更新された耐量子 BYOK 機能は、暗号解読が可能な量子コンピュータ（CRQC）が登場する前に、機密性の高い鍵を保護するのに役立ちます。

転送中の鍵の保護を強化するために耐量子鍵インポートを導入する際は、一般提供が開始された Cloud KMS PQC insights を活用して、ポスト量子に向けた全体的なセキュリティポスチャーをモニタリングすることも可能です。この概要を示すビジュアルでは、使用されているアルゴリズムの分類に基づいて非対称鍵が可視化されます。これにより、将来のモダナイゼーションに向けた計画立案や、長期的なレジリエンスの向上に役立てることができます。

脅威:「今すぐ保存、後で解読」攻撃

従来の鍵インポート方法では、転送中の鍵をラップするために、従来の非対称暗号化標準が使用されます。これらのアルゴリズムは現在の脅威に対しては有効ですが、攻撃者が傍受して保存した鍵を復号できる実用的な量子コンピュータが登場すると、根本的に安全ではなくなります。

耐量子鍵インポートは、鍵を耐量子エンベロープで最初からラップすることで、「今すぐ保存、後で解読」（SNDL）攻撃を軽減するのに役立ちます。

鍵を保護する耐量子エンベロープの構築

Cloud KMS で利用可能になったポスト量子転送メカニズムは、ハイブリッド公開鍵暗号化（HPKE）を使用します。Google の新しいインポート方法では、機密性の高いソフトウェア鍵マテリアルを耐量子転送エンベロープでラップします。このプロセスは既存の Cloud KMS API ワークフローに統合されるため、導入の手間を最小限に抑えることができます。

ジョブの開始: クライアントは、Cloud KMS API を通じて新しいインポートジョブを作成し、ポスト量子 HPKE インポートメソッドをリクエストします。
鍵の生成: Cloud KMS サーバーは、ポスト量子 KEM 秘密鍵を生成し、対応する公開鍵をクライアントに公開します。
クライアントサイドのラッピング: サポートされている暗号ライブラリ（Tink や OpenSSL など）を使用して、クライアントは HPKE Seal() オペレーションを実行します。これにより、共有シークレットを確立するために公開鍵がカプセル化され、HKDF-SHA256 を使用してエフェメラル AES 鍵が導出され、ターゲット鍵マテリアルが暗号化されます。
送信: クライアントは、カプセル化された暗号テキストと暗号化された鍵マテリアルを直接連結して Cloud KMS エンドポイントに送信します。このエンドポイントには、すでに耐量子な転送中データ保護機能が組み込まれています。
ラップ解除: Cloud KMS サーバーは、ラッピング鍵の秘密部分を使用して HPKE Open() オペレーションを実行し、Cloud KMS 境界内で鍵マテリアルを安全に復号して保護します。

KEM レイヤでは、X-Wing、ML-KEM-768、ML-KEM-1024 のいずれかを選択できます。鍵導出レイヤは HKDF-SHA-256 を利用し、最終的な対称ラッパーは、標準の 12 バイトのノンスを備えた AES-256-GCM を採用しています。

インポートジョブの設定、外部暗号ライブラリを使用したローカル鍵マテリアルの準備、耐量子ソリューションの管理の詳細については、Cloud KMS の耐量子鍵インポートに関するドキュメントをご覧ください。

Google Cloud の PQC への取り組みにおける重要なマイルストーン

ポスト量子暗号へのグローバルな移行は、マイルストーンを 1 つずつ達成していくマラソンのようなものです。今すぐ最初の耐量子鍵インポートジョブを作成して、アプリケーションの耐量子化のプロセスを開始できます。

皆様からのフィードバックをお待ちしております。また、貴組織のポスト量子戦略を Google がどのようにサポートできるかについて、ぜひお問い合わせください。

- Cloud KMS、シニアソフトウェアエンジニア、Alessio Buraggina

- Google Cloud、シニアプロダクトマネージャー、Erlander Lo

Fault Injection Testing で復元力テスト戦略を簡素化

Wed, 09 Sep 2026 00:30:00 +0000

※この投稿は米国時間 2026 年 8 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

データベースの障害やネットワークパスの不調が発生しても、ミッションクリティカルなクラウドサービスはオンラインの状態を維持し続けなければなりません。しかし、現代の分散システムは複雑化しており、高可用性の確保はますます困難になっています。

障害発生時にも可用性と信頼性を維持できるよう、Fault Injection Testing のプレビュー版をリリースいたしました。Fault Injection Testing は、開発者やアーキテクトが障害テストを自動化し、サービス中断時にも予測可能な動作を確保できるように設計されています。

意図的に障害を環境に注入することで、実際のサービス停止が顧客に影響を与える前に、安全メカニズムを検証できます。

ネイティブな復元力テストが重要な理由

セルフホスト型のデータセンターとは異なり、クラウドアプリケーションでは、フェイルオーバーテストを容易にするために、基盤となるインフラストラクチャへの直接アクセスが制限されています。

アプリケーションが障害を乗り越えられることを証明するネイティブツールがなければ、信頼性戦略に重大なギャップが生じ、複数のリスクにさらされることになります。

信頼と評判の低下: 障害が頻繁に発生したり、パフォーマンスが低下したりすると、顧客の不満を招き、ブランドイメージに長期的なダメージを与えます。
コンプライアンスと規制によるペナルティ: 多くの業界、特に金融機関では、障害復旧機能を証明できないと、コンプライアンス違反、監査、罰金につながる可能性があります。
移行の遅延: ゾーン障害が発生しても重要なアプリケーションの安定性を維持できることを検証できない場合、大規模な移行プロジェクトは停滞してしまいがちです。

Fault Injection Testing の仕組み

Fault Injection Testing では、テストテンプレートを作成してテストを実行できます。これらのテンプレートはブループリントとして機能し、注入する特定の障害と、テストの対象となるリソースを定義します。

この公開プレビュー版では、次の 2 つの主な障害シナリオをテストできます。

Cloud SQL のフェイルオーバー: この障害は、高可用性 Cloud SQL インスタンスの、プライマリゾーンからスタンバイゾーンへのフェイルオーバーをトリガーします。
アプリケーショントラフィックの劣化: レイヤ 7 ロードバランサを介して、レイテンシと HTTP エラーコードを選択的に追加できます。

Fault Injection Testing では、障害が注入される前に自動ドライランが実行されます。この読み取り専用のシミュレーションでは、権限がチェックされ、影響を受けるすべてのリソースの最新リストが提供されます。

スコープを確認したら、手動で注入を開始できます。テンプレートで定義した期間が経過すると、タイマーが切れて障害が元に戻ります。

テスト中に、アプリケーションが計画どおりに動作していることを確認できます。計画どおりに進まない場合は、停止と復元の機能を使用して、テストを直ちに停止し、リソースを通常の状態に復元できます。

プレビュー期間中は、ベストプラクティスとして、本番環境以外で FIT を使用することをおすすめします。プレビュー版では、サービスが既存のテスト手法にどのように適合し、補完するのかを早期に確認できます。また、プロダクトの改善に役立つフィードバックを Google に提供することもできます。

企業向けに設計

KeyBank や Servier などのパートナーは、すでに Fault Injection Testing を使用してデプロイを検証しています。これらの組織はネイティブなフォールトインジェクションを活用することで、ゾーンの停止といった極めて過酷な障害シナリオをシミュレーションし、サービスの安定稼働を確かなものにしています。

Fault Injection Testing を使ってみる

Fault Injection Testing は、Google Cloud コンソール、gcloud CLI、REST API を介して利用できます。

プレビュー版へのアクセスをリクエストする: Google Cloud アカウントチームに連絡して、プロジェクトをプレビュー版に追加します。
API を有効にする: Google Cloud コンソールで「Fault Testing API」を検索し、有効にします。
ロールを割り当てる: チームに roles/faulttesting.operator ロールがあり、テストを構成して実行できることを確認します。
最初のドライランを実行する: 本番環境以外で Cloud SQL またはロードバランサリソースのテンプレートを作成し、ドライランを実行して潜在的な影響を確認します。

実装の詳細については、Google のアカウント担当者にお問い合わせいただくか、Fault Injection Testing のユーザーガイドをご覧ください。

- Google Cloud、グループプロダクトマネージャー、Toby Owen

Cloud CISO の視点: AI 時代に水道事業者を保護するためのヒント

Tue, 08 Sep 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 9 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

2026 年 8 月、2 回目の投稿となる「Cloud CISO の視点」をご覧いただきありがとうございます。今回は、Chris Sistrunk と Stephanie Kiel が、水道事業者が直面している重大な課題と、OT 運用担当者がインフラストラクチャを保護するために実行できる具体的な手順について詳しく説明します。

これまでのすべての「Cloud CISO の視点」と同様、このニュースレターのコンテンツは Google Cloud 公式ブログに投稿されます。現在ウェブサイトでご覧になっていて、メール版の受信をご希望の方は、こちらからご登録いただけます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud で取締役会向けの重要な情報を得る'), ('body', <wagtail.rich_text.RichText object at 0x7f7de9383ed0>), ('btn_text', 'Insights Hub を見る'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

AI 時代に水道事業者を保護するためのヒント

Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏、および Google Cloud、政府関連業務および公共政策、クラウドセキュリティポリシー責任者、Stephanie Kiel

Chris Sistrunk, Practice Leader, OT, Mandiant Consulting

Google Cloud の脅威インテリジェンスチームは、地政学的紛争の中で、脅威アクターが重要インフラを標的にする際、手口がますます大胆になっていることを確認しています。最近、米国では、インターネットに接続された水道事業のプログラマブルロジックコントローラを標的とした攻撃が増加しています。

Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

これまで、サイバーインシデントによって業務が中断されることはあまりありませんでした。その理由の一つとして、水道事業者が長年にわたり手動オーバーライド機能を備え、水が消費者に届く前に水質検査を実施してきたことが挙げられます。ポンプや配管の故障は、サイバー脅威とは無関係の理由で日常的に発生します。

しかし、これには緊急の対応と、より強力なセキュリティ対策への取り組みが必要であることは確かです。手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防ぐには、基本的なデジタルセキュリティへの取り組みが依然として必要です。特に AI 時代においてはなおさらです。

脅威を把握し、リスクを管理した対応をおすすめします。水道事業者のセキュリティの現状を踏まえると、これらのシステムを安全に保つ独自の運用レジリエンスを考慮して、さらなる対策を真剣に検討する必要があることを示しています。

上下水道事業者が検討すべきアクション

リソースに制約のある公益事業にとって、最も効果的な防御策はサイバーセキュリティの基本に注力することです。これらの基本的な対策を優先することで、システムを大幅に強化し、組織をはるかに攻撃しにくく、復元力の高い標的に変えることができます。これにより、リソースが豊富な脅威アクターでさえ、別の標的を探すようになります。

アセットのインベントリを作成し、露出を評価する: 制御システムがインターネットに安全でない状態で露出しているかどうかを特定します。このような状態により、脆弱性が悪用される可能性が高くなります。
基本的なセキュリティ対策: デフォルトの認証情報を安全なパスワードに置き換え、ファイアウォールを含む、公開されているアクセスポイントを厳格に強化します。
バックアップ: 制御システムを含む重要なシステムが、実績のある 3-2-1 バックアップルール（データのコピーを 3 つ作成し、2 種類のストレージに保存し、少なくとも 1 つのコピーをオフサイトに保存する）に従って保護されていることを確認します。サイバー攻撃によるダウンタイムを最小限に抑えるために、重要な予備機器を確保します。
セグメンテーション: ネットワークセグメンテーションと多要素認証を使用して、必要に応じてリモートアクセスを厳密に制御します。完全な制御が必要ない場合は、読み取り専用アクセスを使用する必要があります。
緊急時計画: サイバーインシデント計画を、FEMA NIMS や産業用制御システムのインシデントコマンドシステムなど、既存の全ハザードインシデントコマンドシステムに統合します。これは、物理的な配管の破損、煮沸水警報、自然災害に対してすでに使用しているのと同じ対応構造です。
サードパーティとベンダーのアクセスの保護: 多くの水道事業者は、自社の IT や OT を管理せず、サードパーティのシステムインテグレータに依存しているため、システムインテグレータやメンテナンス請負業者が使用するリモート接続を監査する必要があります。サードパーティベンダーに厳格なアクセス制御（MFA 標準など）とロギング要件を適用する必要があります。

これらの推奨事項は、米国水道協会、全米地方水道協会、Water-ISAC、環境保護庁、サイバーセキュリティインフラストラクチャセキュリティ庁、FBI のガイダンスを反映しています。

IT および OT リーダーへの推奨事項: ガバナンスのギャップを埋める

IT と OT のリーダーは、統一されたガバナンスフレームワークを構築するために連携する必要があります。また、サイバーフィジカルシステムのレジリエンスを長期的に高めることに注力すべきです。これは、行政機関、民間組織、個人のすべてが一丸となって取り組む必要があることです。これらのシステムをセキュリティが確保され、適応性が高く、中断から迅速に復元できるものにすることが今後の目標です。

ほとんどの場合、PLC は標準的なソフトウェア開発手法の対象外ですが、組織が使用するソフトウェアに対する堅牢なアプローチは、NIST の Secure Software Development Framework（SSDF）で説明されているように、セキュリティポスチャー全体を大幅に強化できます。また、これらはレジリエンスを測定するのに役立つ先行指標の好例でもあります。Google は、先行指標を評価するためのガイドを公開しています。

手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防止するには、特に AI 時代においては、基本的なデジタルセキュリティへの取り組みが依然として必要です。

テクノロジーの進化に伴い、セキュリティのモダナイズが不可欠となっています。事後対応型の手動モデルから、人間の専門知識を意思決定の中心に据えた AI 拡張型アプローチへの移行が必要です。このアプローチは、小規模なセキュリティチームの能力を増強するまたとない機会を提供します。

昨今の脅威に先手を打つには、組織は単純なコンプライアンスチェックリストから脱却し、コンプライアンスを主要な目標ではなく、優れたセキュリティの自然な結果とする、よりアジャイルで脅威を考慮した戦略を採用する必要があります。

Mandiant のオペレーショナルテクノロジー（OT）に関する Theory of 99 は、AI 時代においてさらに重要性を増しています。機会のファネルは大幅に圧縮されていますが、OT に影響を与えるほど深い侵入では、次のようになります。

侵害されたシステムの 99% は、コンピュータワークステーションとサーバー
マルウェアの 99% は、コンピュータワークステーションとサーバーを対象に設計される
フォレンジックの 99% は、コンピュータワークステーションとサーバーで実施される
検出機会の 99% は、コンピュータワークステーションとサーバーに関連するアクティビティ
侵入の滞留時間の 99% は、Purdue レベル 0～1 のデバイスが影響を受ける前に、市販のコンピュータ機器で発生する

その結果、IT ネットワークと OT ネットワークを標的とする脅威アクターが使用する戦術、手法、手順には、多くの場合、大きな重複があります。しかし、Theory of 99 は、AI 時代における防御側の大きな優位性を浮き彫りにしています。高度な AI 機能を使用して中間インフラストラクチャの 99% を保護することで、組織は脅威をプロアクティブに無力化し、物理的な運用プロセスの重要な 1% を確実に保護できます。

サイバー防御のための AI

以前にもお伝えしたように、AI 機能はネットワークセキュリティのバランスを防御側に有利にシフトする機会を提供します。悪意のある行為者が攻撃ライフサイクル全体で AI 機能を活用するケースが増えているため、防御側の優位性はさらに重要になっています。

現在の脅威環境では、防御を自動化することで、人間のセキュリティチームの能力を強化し、意思決定と生産性を向上させ、重大な脆弱性が悪用される前に対処できます。重要インフラプロバイダは、慎重な計画を立てることで、物理的な資産を保護しながら、より復元力のある、脅威を考慮した防御を構築できます。

防御における AI のメリットを効果的に実現するには、AI ツールを構造化された意図的な方法でシステムに統合する必要があります。事業者は、AI が物理プロセスにもたらす特有の脆弱性を理解し、セキュリティの自動化の恩恵を受けられる特定のビジネスユースケースを評価し、継続的なテストとモニタリングのための明確なフレームワークを確立することが重要です。Google のアプローチの一環として、セキュア AI フレームワークを開発しました。これは、分野を問わず、AI 機能のセキュアなインテグレーションとデプロイを実現するのに役立ちます。

最も重要なのは、人間による監視を中核に据えることです。つまり、AI は意思決定をサポートするものであり、安全対策をインシデント対応計画に直接組み込む必要があります。

水の安全の今後

悪意のあるサイバー脅威から水道システムを保護することは、単なる技術的な課題ではなく、公共の安全を守るための基本的な責務です。清潔で信頼できる水へのアクセスは不可欠なサービスであるため、連邦政府、州政府、地方自治体は、サイバー脅威に直面してもこの重要な公共インフラストラクチャの継続性を確保するために、政策議論から断固とした行動へとますます移行していくことが予想されます。

たとえば、国家サイバー長官室はテキサス州と提携して、水道インフラプロバイダをサイバー攻撃から保護するための試験運用プログラムを立ち上げたばかりです。また、米国上院議員は、最近の出来事に対応して新しい法案をすでに提出しています。

Google は、お客様がクラウドおよびハイブリッドクラウドの OT 環境を保護できるよう支援することに尽力しています。重要インフラストラクチャの保護に関する Google のガイダンスについて詳しくは、CISO インサイトハブをご覧ください。

aside_block: <ListValue: [StructValue([('title', '新しいことを学ぶ'), ('body', <wagtail.rich_text.RichText object at 0x7f7de93854d0>), ('btn_text', '今すぐ見る'), ('href', 'https://x.com/googlecloud/status/2090213589558698309?s=20'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

その他の最新情報

セキュリティチームからこれまでに届いた今月のアップデート、プロダクト、サービス、リソースに関する最新情報は以下のとおりです。

高度なセキュリティガバナンスで自律型エージェントを強化: AI エージェントが有用性と安全性を確保するには、アクセス権とガードレールが必要です。Google 最新の AI インフラストラクチャの現状レポートによると、テクノロジーリーダーの 79% が、セキュリティ、ガバナンス、運用のいずれかを推論のスケーリングにおける最大の課題として挙げています。詳細はこちら。
2026 年のクラウドリスクの状況: ほとんどのセキュリティ検出結果は、実際の攻撃者の機会ではない: Wiz Research のテレメトリーにより、重大度の高い検出結果の大部分に侵害への経路がない理由が明らかになりました。詳細はこちら。
Google Cloud Fault Injection Testing のプレビュー版をリリース: データベースに障害が発生し、ネットワークパスが不安定になった場合でも、ミッションクリティカルなクラウドサービスをオンラインに維持する必要があります。Fault Injection Testing（FIT）は、障害テストを自動化し、障害発生時に予測可能な動作を保証するのに役立ちます。詳細はこちら。
Wiz が AI を活用したデータ検出を構築した方法: バケットスキャナをコンテキストエンジンに変えたマルチエージェントパイプラインとフィードバックループの内部。詳細はこちら。
Wiz による FinOps の民主化: Wiz Cloud Cost が費用配分を自動化し、デベロッパー主導の費用最適化を促進して、費用をビジネス価値に結び付ける方法。詳細はこちら。
Google Workspace Studio の多層防御でエージェントのリスクを防御: Studio には、脅威アクターによるリスクを軽減する多層防御と、組織がエージェントを安全に導入できるようにする堅牢なオブザーバビリティツールが組み込まれています。安全性を重視して設計された Google のアーキテクチャを基盤とする Studio は、ネイティブな脅威防御とエコシステムの詳細な可視化を組み合わせて、マルチステップのエージェント型ワークフローを保護します。詳細はこちら。

今月公開されたその他のセキュリティ関連の記事については、Google Cloud 公式ブログをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud CISO Community にご参加ください'), ('body', <wagtail.rich_text.RichText object at 0x7f7de93842d0>), ('btn_text', '詳細'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

脅威インテリジェンスに関するニュース

ロシアが関心を寄せる個人を標的とした複数のクラスタ: Google Threat Intelligence Group（GTIG）は、正規の認証フローを悪用して、ヨーロッパと米国全域の学術機関、航空宇宙、政府機関、シンクタンクで働く個人を標的とする、ロシアのサイバーエスピオナージ脅威クラスタと疑われる 3 つのクラスタを追跡しています。詳細はこちら。
AI インフラストラクチャへの 90 日間にわたる攻撃: Wiz のハニーポットが、RCE、ブラインドプロンプトインジェクション、メモリ認証情報の窃取を通じて LiteLLM、MCP サーバー、AI フレームワークを標的とするアクティブなキャンペーンを明らかにしました。詳細はこちら。
バージョン管理 DFIR: GitHub、GitLab、Bitbucket、Azure DevOps のクイックリファレンス: 主要なバージョン管理サービスにおけるログの可視性、インシデントへの備え、脅威ハンティングに関する実務者向けガイド。詳細はこちら。
arrayref に対する Rust サプライチェーン攻撃: 北朝鮮によるキャンペーンと大幅に重複: arrayref Rust クレート（およびその他）の悪意のあるバージョンが、コンパイル時にバックドアを実行しました。このキャンペーンのインフラストラクチャは、Mastra や axios など、最近の北朝鮮のサプライチェーン攻撃と重複しています。詳細はこちら。

注目の Google Cloud ポッドキャスト(英語)

Cloud Security Podcast: AI、エージェント、Rust、タブを使用したブラウザのパッチ適用: Chrome Security の Jasika Bawa と Doug Turner が、Google Chrome が AI エージェントを使用して、これまでにない規模でセキュリティの脆弱性を自律的に特定してパッチを適用し、ブラウザの更新頻度を大幅に向上させている方法について説明します。ポッドキャストを聴く。
Cloud Security Podcast: Wiz の AI 脆弱性調査プロジェクト Atlas のすべて: Wiz の脆弱性調査責任者である Near Orfeld 氏が、クラウドインフラストラクチャにおける深刻なゼロデイ脆弱性を発見するために、チームがマルチエージェント AI システムをどのように活用しているかを詳しく解説します。ポッドキャストを聴く。
Cloud Security Podcast: 脆弱性のクラスを大規模に根絶する Google の手法: AI がコードを記述し、人によるレビューが追いつかない状況下でも、安全性を維持できる Google 規模のエンタープライズ基盤を構築するにはどうすればよいでしょうか。Google のプリンシパルセキュリティエンジニアである Christoph Kern が、AI 時代における「安全性を重視した設計」の真の意味を探ります。ポッドキャストを聴く。

月 2 回発行される「Cloud CISO の視点」をメールで受信するには、ニュースレター(英語版)にご登録ください。次回も Google Cloud からセキュリティ関連の最新情報をお届けします。

- Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏

- Google Cloud、クラウドセキュリティポリシー、政府関連業務および公共政策責任者、Stephanie Kiel

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティサービスを提供

Mon, 31 Aug 2026 02:00:00 +0000

JBサービス株式会社（以下、JBサービス）は、SOC（Security Operations Center）の運用を通じて、企業のセキュリティ監視サービスを 24 時間 365 日体制で提供しています。近年は SOAR（Security Orchestration, Automation and Response）で、セキュリティ対策の自動化や効率化を推進。さらに Google Threat Intelligence を導入し、SOAR に組み込むことで、セキュリティの脅威をプロアクティブに阻止できる体制を実現しています。Google Threat Intelligence 導入の背景や効果、新たな顧客向けサービスへの展開について、導入プロジェクトを主導した 3 人の担当者にうかがいました。

利用しているサービス:
Google Threat Intelligence

圧倒的な情報量と利便性を評価し、Google Threat Intelligence を導入

JBサービスは、さまざまな企業の DX 推進を支援する JBCCホールディングスの事業子会社として、2007 年に設立。2015 年からセキュリティ事業を展開し、運用センター SMAC（Solution Management and Access Center）を中心とする SOC サービスを通じて、高い評価を得てきました。上級執行役員でセキュリティ事業部事業部長の平田直樹氏は、同社の持ち味を次のように説明します。

「運用センター SMAC は、SOC とヘルプデスクが同一拠点で連携する独自の運用体制を強みに、アラート検知からユーザー対応、改善提案までをワンストップで提供しています。さらに、既存の SOC で培った知見を基盤に、AI セキュリティ領域へとサービスを拡張し、監視・対応・改善を一体化した次世代 SOC の実現に取り組んでいます。」

同社は SOC 業務に約 80 名、セキュリティ事業部全体では約 200 名のスタッフを擁し、きめ細かなサービスを展開してきました。その鍵となっていたのが、SOAR と各ベンダーから提供される脅威情報を連携させたオペレーションです。しかし、平田氏はさらなる安心・安全の確保のために、次の目標を見据えていたと振り返ります。

「そこで注目したのが、Google Threat Intelligence です。Google Threat Intelligence には、弊社のエンジニアたちが以前から見てきた VirusTotal や、定評ある Mandiant の知見、Google Cloud が持つ膨大なデータまで統合されています。特に、単なる脅威情報の収集にとどまらず、世界規模で観測されている攻撃情報や攻撃者の動向を一元的に把握できる点に大きな魅力を感じました。従来は複数の情報ソースを横断して確認していた分析業務も、Google Threat Intelligence を活用することで効率化でき、アナリストがより高度な調査やお客様への提案に時間を割けるようになることが期待できます。」

第一サイバーセキュリティ部部長で、エンドポイントにおける運用チームのマネージャーを務める鈴木祐介氏によれば、インターフェースのわかりやすさや日常業務での使いやすさ、顧客対応の迅速化が期待できる点も、Google Threat Intelligence への評価を高めました。

「Google Threat Intelligence のインターフェースは、VirusTotal の延長線上のような感覚で、エンジニアにとって非常にわかりやすいものでした。しかも Google Threat Intelligence では、IOC（Indicator of Compromise：攻撃や侵害の痕跡を示す指標）も充実しています。評価の際にはアドバンスドライセンスを利用し、攻撃者情報と攻撃手法を関連付けた情報まで参照できました。Google Threat Intelligence で得られる高品質な脅威情報を SOAR に取り込み、自動分析や相関分析に活用することで、アナリストが対応すべきアラートを効率的に絞り込めるようになりました。」

従来は検出できなかった脅威を可視化し、プロアクティブな防御を展開

JBサービスでは、2025 年 3 月から約 2 か月間、PoC（Proof of Concept: 概念実証）を実施したうえで、Google Threat Intelligence の採用を決定。直後に実装へと移り、SOC サービスの効率化や精度向上、既存システムとの API 連携などの検証を自社グループ内で重ねてきました。ネットワーク運用チームのマネージャーを務める第二サイバーセキュリティ部部長の吉永臣作氏は、技術的なポイントをこう説明します。

「もともと弊社では SOAR を活用してセキュリティ運用の自動化を進めていましたが、Google Threat Intelligence の豊富な脅威インテリジェンスを既存の運用に組み込むことは、新たな取り組みでした。導入にあたっては、API を通じて取得できる情報の精度や有用性を検証しながら、Google Threat Intelligence の情報を SOAR へ連携する仕組みを構築し、脅威情報の収集や分析の自動化を実現しました。また、既存のセキュリティ製品が提供する脅威情報との重複を避け、それぞれの強みを生かせる形で運用を設計することも重要なテーマでした。Google Cloud には検証段階から伴走支援いただき、課題を一つひとつ解決しながら、円滑に本番運用へ移行することができました。」

PoC および導入の過程における Google Cloud のサポートは、平田氏も高く評価していました。

「検討段階から Google Cloud のオフィスで丁寧な説明を受け、エンジニアの皆様にも継続的なサポートをいただきました。導入時には細かな確認や調整を重ねる必要がありましたが、その支援のおかげで、PoC から実装、運用開始までを安心してスムーズに進めることができました。」

2025 年 6 月から約 1 年間かけて行われた社内運用では、確かな手応えも得られています。

「特に大きな効果を感じているのは、膨大な EDR（Endpoint Detection and Response）ログに埋もれた脅威を迅速に特定できるようになったことです。従来は多くのログを分析しながら脅威の有無を見極める必要がありましたが、Google Threat Intelligence を活用することで、優先的に対応すべきリスクを効率的に抽出できるようになりました。また、豊富な IOC を活用することで、インシデントが発生する前の兆候を把握し、お客様に対して先回りした対策や提案を行うなど、よりプロアクティブなサービスの提供を実現しています。」（鈴木氏）

「業務の自動化と最適化を進めた結果、アナリストの負荷増加を抑えながら運用効率を高めることができました。また、Google Threat Intelligence が提供する豊富な脅威情報と分析結果を活用することで、検知精度の向上と対応品質の標準化も実現しています。セキュリティ分析は担当者の知識や経験に依存しやすい領域ですが、経験値の差による判断のばらつきを抑え、より迅速かつ一貫性の高い分析が可能になりました。その結果、お客様へ提供するサービス品質の向上と、より高い安心・安全の実現につながると考えています。」（平田氏）

1 年間の運用で得られた成果を基盤に、新たな SOC サービスの提供を開始

実際の作業を通して、機能性や信頼性の高さを改めて確信した同社は、2026 年 7 月、新たな SOC サービスの提供を開始しました。これは Google Threat Intelligence と SOAR を組み合わせて監視・分析・対応の高度化を実現したもので、既存のセキュリティサービスに追加して利用できるようになっています。

平田氏は「高度な脅威インテリジェンスを自社で個別に運用することが難しいお客様でも、JBサービスの SOC サービスを通じて、最新の脅威情報を活用した監視・分析・対応を受けられる点が大きなメリットです」と語ります。

新たなサービスは段階的な提供が計画されています。第 1 弾では、エンドポイントのセキュリティを強化し、その後ファイアウォールやクラウドへも対象を広げていく予定です。顧客に寄り添った独自のサービスをさらに強化し、より高い安心・安全を提供するため、平田氏はダークウェブを対象とするデジタルスレットモニタリングや、生成 AI の活用も視野に入れていました。

「セキュリティを担保する重要性は、ますます高まっています。最近は生成 AI の技術が悪用されるケースも増えていますが、こちらも Google Threat Intelligence と Gemini をさらに活用することで、緻密なセキュリティ保護が提供できるようになるでしょう。もちろん、セキュリティ管理の分野では誤検知をゼロにはできませんし、最終的には、長年培われてきた人間のノウハウや経験値が重要になってきます。弊社のスタッフにも、より高度な、人にしかできない分析に注力してもらいたい。そのためにも Google Threat Intelligence で、運用の効率化や自動化を追求していく予定です。」

JBサービス株式会社
企業の DX 推進を支援する IT 企業、JBCCホールディングスの事業子会社として、現在の JBCC株式会社（旧・日本ビジネスコンピューター株式会社）の会社分割により設立され、2015 年からセキュリティ事業を展開。企業の IT システム運用や情報セキュリティ対策、機器の保守、ヘルプデスク業務に加え、BPO および AI 運用を含むサービスなどを 24 時間 365 日、一元的に代行・支援する。巧妙化するサイバー攻撃への対応、IT 人材不足などの課題を抱える企業に対し、包括的なサポートを提供している。

インタビュイー（写真左から）
・セキュリティ事業部セキュリティサービス本部第二サイバーセキュリティ部部長　吉永臣作氏
・セキュリティ事業部上級執行役員事業部長　平田直樹氏
・セキュリティ事業部セキュリティサービス本部第一サイバーセキュリティ部部長　鈴木祐介氏

その他の導入事例はこちらをご覧ください。

プライバシー重視の AI で脳腫瘍研究を後押し

Fri, 21 Aug 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 8 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

医療と AI の融合は、目覚ましいイノベーションをもたらしています。しかし現在、開発者は患者のプライバシー保護と、実世界の多様なデータに基づく検証と評価を両立させた、信頼性の高い医療 AI ツールを構築するという難題に直面しています。Google Cloud は、戦略的なコラボレーションと Confidential Computing を組み合わせてこの難題にアプローチしています。

検証プロセスにおいて患者のプライバシーと AI モデルの両方を保護するために、Google は MedPerf イニシアチブを通じて MLCommons と連携しています。今年の Google Cloud Next で初めて発表されたこのパートナーシップは、Confidential Computing を活用して、実際の環境で AI モデルをベンチマークするための安全なデータクリーンルームを確立するものです。

課題: データを見ることなく AI を評価する

テクノロジー業界と学術界に 125 以上のメンバーを擁するグローバルコミュニティである MLCommons は、医療 AI の評価を標準化するため、2023 年に MedPerf を立ち上げました。AI モデルのベンチマーク用オープンソースプラットフォームである MedPerf は、連携評価によるモデルテストを通じて臨床研究を推進しています。

Google Cloud Confidential Space を使用すると、ハードウェアで分離された高信頼実行環境（TEE）内で独自の AI モデルを評価できます。この特別な仮想マシンは、実行中のメモリを暗号化し、オペレーティングシステムを強化するため、病院や研究機関、その他の参加者、さらには Google であっても、評価中にモデルコードや患者データを閲覧することはできません。

医療 AI のベンチマークには高いコンピューティング負荷がかかるため、Confidential VM は CPU だけでなく GPU にも拡張されています。GPU 加速推論時においてもモデルの重みと患者データを保護するため、MedPerf は NVIDIA H100 GPU を搭載した Google Cloud の A3 マシンシリーズ上で稼働します。このシステムは、CPU の Intel TDX テクノロジーと GPU の NVIDIA Confidential Computing を組み合わせた構成となっています。

患者データがワークロードに投入される前に、システムは、承認されたコードのみが正規の Confidential Computing ハードウェアで実行されていること、および環境が適切にセキュリティ強化されていることを暗号によって証明します。

実世界における医療 AI の評価: MedPerf と GCP Confidential Computing のデモ

ML Commons MedPerf が Google Cloud Confidential Computing と連携し、医療 AI モデルの安全な実環境評価を実現する仕組みをご紹介しています。

理論を大きな成果へ: 脳腫瘍研究のさらなる進展

このテクノロジーは、Federated Tumor Segmentation（FeTS）イニシアチブを通じて、すでに極めて重要な研究を推進する原動力となっています。膠芽腫などの脳腫瘍は症例数が少ないため、単一の病院だけで AI トレーニングの精度を高めるのに十分なデータを収集することは困難です。

さらに厄介なことに、ある病院では完璧に機能するモデルが、患者の属性、データの取得手法、さらには機器の差異により、別の病院では十分な性能を発揮できないケースがあります。

インディアナ大学の Spyridon Bakas 博士、ノースウェスタン大学の Yury Velichko 博士、カナダのアルバータ大学の Amber Simpson 博士といった先見の明のある研究者の協力を得て、Google Cloud 上の MedPerf は世界各地の脳 MRI の非公開データで AI モデルを検証し、潜在的なパフォーマンスギャップを特定しています。

たとえば、あるサイトでは 95% の精度を発揮するモデルが、別のサイトでは 63% の精度しか達成できない場合があります。Google の協働的アプローチは、臨床現場に届く AI ツールが、特定の層に偏らない真に代表的な患者集団で機能することを保証するものです。

臨床現場での信頼確立と検証

このコラボレーションによる成果は、臨床研究の最前線にいる方々の言葉に最もよく表れています。

ノースウェスタン大学放射線科准教授の Yury Velichko 博士は次のように述べています。「Google Cloud でのフェデレーションラーニングのテストを通じて、医療 AI の未来は、安全かつスケーラブルな、共同研究に適したクラウド環境にあることがわかりました。管理された研究室レベルの環境から一歩踏み出し、本番環境対応のインフラストラクチャでこれらのワークフローを検証できたことは、実際の臨床アプリケーションにおけるフェデレーションラーニングのパフォーマンスとセキュリティを評価する、またとない機会となりました。」

MLCommons の MedPerf リードである Alexandros Karargyris 氏は次のように語っています。「医療 AI は世界中の患者に多大な恩恵をもたらす可能性を秘めています。しかしそれを実現するには、評価に用いるベンチマークが臨床医、研究者、規制当局から信頼されるものでなければなりません。MedPerf を Google Cloud の Confidential Computing インフラストラクチャ上に構築することで、プライバシー、知的財産、ベンチマークの整合性を損なうことなく、実際の患者データで AI モデルを厳密にテストできる未来に向けた大きな一歩を踏み出せました。」

未来：安全な医療のブレークスルーを普及させる

MLCommons と Google Cloud のコラボレーションは、医療 AI における「プライバシーバイデザイン」への根本的な転換を示すものです。Google は、データとモデルを安全に共有、評価しやすくすることで、より迅速かつ安全で公平性の高い医療イノベーションの実現を後押ししています。

Google Cloud 上での MedPerf プラットフォームの活用にご関心のある研究機関や医療モデル開発者の方は、medical@mlcommons.org または担当の Google Cloud アカウントチームまでお問い合わせください。

- Google Cloud、シニアクラウドセキュリティプロダクトマネージャー、Rene Kolga

- Google、ソフトウェアエンジニア、Peter Mattson

PQC をわかりやすく解説: Google Cloud のポスト量子暗号ロードマップ

Thu, 20 Aug 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 8 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

暗号解読に有効な量子コンピュータが将来登場することに備え、インフラストラクチャとサービスを保護することは、Google が 10 年前から目標としてきたことです。Google は、すべての人にメリットをもたらすオープンスタンダードを推進することで、開発者を支援することに取り組んできました。ポスト量子暗号（PQC）が成熟するにつれて、Google は社内サービスとお客様向けサービスの両方で、インフラストラクチャへの PQC のロールアウトを進めてきました。

今回は、2029 年までの PQC 移行に向けた Google Cloud の最新ロードマップをご紹介します。

Google の戦略: 安全性を重視した設計

Google の PQC 移行戦略は、Google 量子脅威モデルに基づいており、3 つの主要なドメイン全体で保護を優先しています。

Store Now, Decrypt Later（SNDL）リスクの軽減: 現在の暗号化されたデータが将来の量子コンピュータによって収集、復号されるのを防ぎます。
偽造に対する完全性の確保: 攻撃者がデータの内容を改ざんしたり ID を偽造したりするのを防ぐために、デジタル署名を強化します。
暗号アジリティの基盤となる機能の強化: 暗号化標準の進化に合わせて、最小限のエンジニアリング作業で新しい暗号化標準を簡単に採用できる柔軟なシステムを構築します。

Google は、規制の期限をはるかに先取りして、社内インフラストラクチャとお客様向けサービスの両方で PQC アルゴリズムへの移行を積極的に進めています。

また、パートナーと協力して、Google Cloud Dedicated（GCD）や Google Distributed Cloud（GDC）などの Sovereign Cloud イニシアチブ全体で PQC ソリューションのデプロイを進めています。同様に、Google の戦略により、AI サービス全体へのポスト量子保護の統合を進めることが可能になり、次世代のクラウドワークロードの安全性を確保できるようになります。

これらの取り組みは、Google Cloud 全体でポスト量子暗号への完全な対応を実現するという Google の包括的な戦略の基本となる柱です。この情勢が変化するにつれて、Google はデプロイスケジュールを継続的に見直し、更新していきます。

Google Cloud PQC ロードマップの図解。Google の取り組みは 2029 年に収束し、それ以降も継続されます。

Google は、取り組みが収束する 2029 年までに PQC への完全な対応を達成する予定です。Google は、より幅広い業界のガイダンスと進化するグローバルスタンダードをサポートするため、これらの取り組みを 2030 年代にかけて継続することを見込んでいます。これらの標準には、CNSA 2.0 や NIST IR 8547 で定義された移行パスが含まれており、2030 年から 2035 年の間に、量子脆弱性のあるレガシーアルゴリズムが最終的に廃止されることが予想されています。

直近の進捗: 2026 年のマイルストーン

量子時代のリーダーシップには、グローバル規模でのデプロイが必要です。Google は、お客様に即時の保護を提供する基盤となるマイルストーンを達成しました。

API エンドポイントの対応: Google Cloud API エンドポイントで耐量子鍵交換が提供されるようになり、将来の復号から受信トラフィックを保護できるようになりました。これらのエンドポイントには google.com と *.googleapis.com が含まれ、いずれも NIST で標準化された ML-KEM（FIPS 203）をハイブリッドモードで実装済みです。
ロードバランサの PQC サポート: アプリケーションロードバランサとプロキシロードバランサで、TLS 1.3 の耐量子ハイブリッド鍵交換（X25519MLKEM768）がサポートされるようになりました。当初はオプトイン方式で提供されるため、お客様は既存のアプリケーションへの影響を最小限に抑えつつ、検証を行うことができます。
大規模な耐量子証明書の試験運用: IETF PLANTS ワーキンググループと協力し、運用チームへの影響を最小限に抑える公開鍵基盤（PKI）の標準を策定しています。Chrome と Cloudflare は、WebPKI で PQC 署名を使用する際の課題に対処するため、Merkle Tree 証明書の試験運用を開始しました。Google は、これらの活動から得られた知見を標準化ワーキンググループと共有しています。
Cloud KMS PQC アルゴリズム: 暗号化鍵と署名鍵に使用する NIST で標準化された PQC アルゴリズム（ML-KEM、ML-DSA、SLH-DSA）の一般提供が開始されました。

2029 年までのロードマップ

Google Cloud では、量子コンピューティングへの対応準備を実現するため、お客様中心の具体的なジャーニーを策定しました。これにより、耐量子イニシアチブの優先順位付けが可能になります。このリスクベースのアプローチを採用することで、セキュリティエキスパートが量子コンピューティングの潜在的な影響を最も受けやすいと特定したコアジャーニーに焦点を当てます。

量子コンピューティングへの対応準備に向けたコアユーザージャーニーのリスクベースの優先順位付け

これらのシナリオは、Google のサービス全体でグローバルなイネーブルメントを確保し、お客様の現在の状況に合わせてサポートを提供できるよう、さまざまなプラットフォームの視点を提供するものです。

各リスクドメインについて、主要なプロダクトとサービスのロードマップをドメイン別に提供します。なお、ここで取り上げているサービスはすべてを網羅したものではありません。ほとんどのサービスは、それぞれのドメインの目標完了日を達成する見込みです。ただし、エンジニアリング要件の進展やサードパーティの依存関係を考慮し、必要に応じて特定のプロダクトのスケジュールが調整される場合があります。

ドメイン 1: Store Now Decrypt Later（SNDL）の軽減

このドメインは、将来の暗号解読に有効な量子コンピュータ（CRQC）が、現在キャプチャされたデータを復号できる可能性があるという、非対称暗号の脆弱性に対処することに重点を置いています。

Google は、お客様の一般的なジャーニーに基づき、段階的な進展を支援しています。

お客様の顧客のワークロードを保護する: Google Cloud サービスと構成済みのロードバランサに量子コンフィデンシャル TLS 1.3 ハンドシェイクを提供し、ユーザーセッションを保護します。
管理者と開発者のフローを保護する: クラウド環境の管理に使用される管理パスウェイを SNDL から保護します。これには、Cloud VPN や Interconnect などのサービスが含まれます。開発者向けには、クライアントライブラリ、SDK、Google のオープンソース暗号ライブラリである Tink などが含まれます。
データパイプラインを保護する: Google の分析プラットフォームとストレージプラットフォームのデータ転送の機密性を確保します。PQC は、これらのシステムを流れる機密性の高い知的財産や顧客データが、現在キャプチャされ、将来的に量子コンピューティング能力を持つ攻撃者によって復号されるのを防ぐために不可欠です。

ロードマップ以下の変更は 2027 年の実施を目標としています。

ジャーニー	利点	代表的なサービス
Store Now, Decrypt Later の軽減（2027 年末）
お客様の顧客のワークロードを保護する	耐量子 Ingress: 標準化されたポスト量子アルゴリズムを使用してクラウド境界を保護します。	アプリケーションとプロキシのロードバランシング[2026 年（完了）]
管理者と開発者のフローを保護する	安全な運用: 管理とデプロイのスタックが新たな暗号化規格を満たしていることを検証します。	量子コンフィデンシャル ALTS[2025 年（完了）]
		API エンドポイント[2026 年（完了）]
		Cloud VPN、Cloud Interconnect、GCE OS Login、Cloud SDK、gCloud CLI、GKE サービスメッシュ、クライアントライブラリ[2026 年 / 2027 年]
データパイプラインを保護する	機密データの転送保護: 量子攻撃者から、機密性の高い知的財産や顧客データを保護します。	Cloud Storage SDK、Storage Transfer Service、BigQuery CLI、Data Transfer Service[2026 年 / 2027 年]

ドメイン 2: 完全性と否認防止

このドメインでは、データの完全性と真正性を損なう可能性のある偽造から保護するために、デジタル署名と証明書の耐量子化に取り組みます。

ソフトウェアサプライチェーンの保護: 量子耐性のある証明書が付与された、信頼できる改ざんされていないイメージのみが本番環境で実行されるようにすることで、量子攻撃者によるビルドの改ざんを防ぎます。これには、Binary Authorization、Cloud Build、Assured Open Source Software などのサービスが含まれます。
耐量子証明書の発行: 内部および外部の認証局（CA）を含む公開鍵基盤（PKI）を移行して、ML-DSA 証明書と、有用な場合は SLH-DSA 証明書をサポートします。この移行は、現在策定中の Internet Engineering Task Force（IETF）の標準化の取り組みに沿って行われます。Google はこうした取り組みに積極的に貢献しており、次のような大規模な実験もいくつか実施しています。

Web PKI 向けの Merkle Tree Certificates などの新たな手法を通じて、証明書チェーンの検証パフォーマンスに影響を及ぼす可能性がある PQC 署名サイズの増大に対処します。
Certificate Authority Service（CAS）などのプライベート CA ソリューションで、ML-DSA / SLH-DSA（純粋な PQC）ベースの証明書をサポートします。
機密保持を目的として、すでに PQC をサポートしている内部トラフィックプロトコル ALTS に加えて、量子認証を追加します。デジタル署名と公開鍵基盤に対する Google のアプローチについて、技術的な詳細をこちらでご確認いただけます。

ID とアクセスの保護: サービスアカウントキーやトークン（JWT / OAuth）などの認証メカニズムが量子偽造に対する耐性を備えるようにします。

ロードマップGoogle は、2028 年までに以下のマイルストーン達成を目標としています。また、特に証明書の分野で進行中の標準化の取り組みについても注視しています。Google は、耐量子証明書の標準に積極的に貢献しており、業界全体がこれらの期限に対応できるよう支援することに尽力しています。

ドメイン / ジャーニー	メリット	代表的なサービス
完全性と否認防止（2028 年末）
ソフトウェアサプライチェーンと署名サービスの保護	耐量子ソフトウェア証明書: 信頼できるイメージのみが本番環境で実行されるようにすることで、不正なビルドの改ざんを防止します。	Binary Authorization、Access Approval（AXA）[2026 年]
		Assured OSS[2027 年]
耐量子証明書の発行	標準化された耐量子トラスト: 量子計算による証明書の偽造から、社内外の通信の真正性を保護します。	量子認証 ALTS[2026 年 / 2027 年]
		Private CA（Certificate Authority Service）[2027 年]
		Google Trust Service: Merkle Tree Certificates[2028 年]
		Google Cloud のプロダクトとインフラストラクチャ全体に PQC 証明書をロールアウト[2027 年 / 2028 年]
ID とアクセスの保護	管理された ID: 監査可能な完全性を確保するため、NIST 標準の署名を使用して、攻撃者による認証情報の偽造リスクを排除します。	Cloud IAM[2028 年]
		インフラストラクチャ全体への耐量子認証とアクセスのロールアウト[2027 年 / 2028 年]

ドメイン 3: 基盤と鍵管理

暗号アジリティは、PQC 移行の基盤です。Google は、この分野への継続的な投資により、鍵管理、ライブラリ、インフラストラクチャの変更に関するエンドツーエンドの戦略を推進しています。

基盤となる鍵管理とライブラリ: Cloud KMS と、BoringSSL や Tink などのライブラリを通じて、NIST 承認済みのアルゴリズムを有効にします。

なお、Cloud KMS は、NIST 標準化 PQC アルゴリズム（ML-KEM、ML-DSA、SLH-DSA）の一般提供（GA）を開始しており、現在は耐量子鍵のインポートの有効化を進めています。

ハードウェアベースの暗号サービス: 量子耐性ルートオブトラストを使用した安全な物理基盤。これには、Confidential Computing サービスの一部としての PQC や Cloud Hardware Security Module（HSM）が含まれます。
鍵の主権とパートナーソリューション: Google Workspace クライアントサイド暗号化（CSE）と External Key Manager（EKM）で PQC オーケストレーションを有効にします。パートナーと連携して、PQC オンプレミス鍵プロバイダをサポートします。

ロードマップGoogle は、2028 年までに以下マイルストーン達成を目標としています。

ドメイン / ジャーニー	メリット	代表的なサービス
基盤と鍵管理（2028 年末）
基盤となる鍵管理とライブラリ	標準化された耐量子鍵: NIST 承認済みの構成要素を提供し、アプリケーションの移行を支援します。	KMS の ML-DSA と SLH-DSA、KMS の ML-KEM とハイブリッド[2025 年（完了）]
		耐量子鍵のインポート（BYOK）[2026 年]
ハードウェアベースの暗号サービス	シリコンに根ざしたハードウェア: 耐量子ハードウェアのルートオブトラストをセキュリティのアンカーとします。	Confidential Compute（証明書と vTPM を含む）[2028 年]

		耐量子 Cloud HSM（FIPS 140-3 L3）[2028 年]
鍵の主権とパートナーソリューション	暗号の来歴: 必要な場所で鍵の制御と来歴を提供します。	外部鍵管理[2028 年]
		パートナーのイネーブルメント（鍵プロバイダとソブリンソリューション）[2028 年]

量子安全における責任の共有

セキュリティは長年にわたり、お客様との共同パートナーシップとして取り組んできました。

Google の責任 - クラウドのセキュリティ: Google は、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTS プロトコルなど、耐量子インフラストラクチャへの移行を管理します。

この責任は、サーバーの PQC 移行をエンドツーエンドで網羅するものであり、基盤となるハードウェアとオペレーティングシステムが量子の脅威から確実に保護されるようにします。Google は、Caliptra v2.1、TPM 2.0 v185、OpenTitan などの耐量子オープンソースのシリコン基盤を通じて、ハードウェアの完全性を維持しています。後者は、初のオープンソースシリコンルートオブトラストであり、すでに耐量子セキュアブートをサポートしています。

2029 年の目標達成に向けて取り組む中、ハードウェアの PQC への移行は、可能な場合は積極的なリプレースと、自然な機器リプレースサイクルの両方を通じて行われます。段階的なアプローチにより安定性を確保していますが、一部の物理コンポーネントのタイムラインは 2029 年以降に延びる可能性があります。

お客様の責任 - クラウドにおけるセキュリティ: 組織は、PQC ハンドシェイクをネゴシエートするためのクライアントサイドソフトウェアの更新や、非対称鍵のライフサイクルの管理など、独自のアプリケーションを管理する必要があります。

さらに、Google Cloud サービス構成を耐量子設定とポリシーで更新する必要があります。

共に進むこれからの道のり

量子への対応に向けた機運を高めるには、即座に実践的な行動を起こす必要があります。まずは、次の 3 つのステップから始めることをおすすめします。

インベントリ: Cloud Asset Inventory や Wiz の暗号化と PQC への対応状況などのソリューションを使用して、暗号リソース（鍵や証明書など）を特定します。組織全体で暗号リソースの使用状況を可視化すると、移行バックログをより正確に定義し、優先順位を付けることができます。
更新: 開発チームとサイト信頼性エンジニアリングチームが、BoringSSL、Chrome、SDK など、PQC アルゴリズムをサポートするソフトウェアを使用していることを確認します。この更新により、エッジで耐量子接続が有効になった際、内部ワークフローがデフォルトでその接続をネゴシエートできるようになります。
検証: Google の耐量子 API とロードバランサを使用して、既存のアプリケーションの動作をテストします。今すぐワークフローを検証することで、主要な本番環境に影響が及ぶ前にアーキテクチャのボトルネックを見つけ出すことができます。

Google Cloud は、この移行の複雑なプロセスを引き受けることで、お客様がイノベーションに注力しながら、規制とコンプライアンスの要件を達成できるよう取り組んでいます。ポスト量子の環境でお客様が主導権を握れるよう、Google は取り組みの進捗状況を共有し始めたばかりです。

Google の PQC アプローチについて詳しくは、ポスト量子暗号（PQC）ハブをご覧ください。

- 規制対象および Sovereign Cloud 担当 VP 兼 GM、Jai Haridas

- Cloud Foundations 担当バイスプレジデント兼ゼネラルマネージャー、Michael Bachman

Best Buy、Workforce Identity 連携で AI ワークロードをスケールし、アクセスを保護

Fri, 07 Aug 2026 02:30:00 +0000

Best Buy のテクノロジーチームは、同社が高度な分析や AI のために Google Cloud の利用を拡大するなかで、スケーリングに関する 2 つの大きな課題に直面しました。それは、Microsoft Entra ID から数千人のバックエンドユーザーを同期する際のリスクの軽減と、管理の煩雑さへの対処です。

この小売業者は、Google Cloud の Workforce Identity 連携を実装することで、両方の問題を解決し、大規模なクラウド拡張への道を開きました。この直接的なアプローチにより、デベロッパーは別の ID ストアを用意することなく、既存の Microsoft 認証情報でクラウドリソースにセキュアにアクセスできるようになりました。これにより、技術部門のリーダーは、アクセスが厳密に制御され、監査可能で、大規模な管理が可能であるという確信を持つことができました。

サービスアカウントを直接連携に置き換える

Best Buy はこれまで、バックエンドユーザーを Entra ID から Google Cloud にコピーするために、複雑な同期パイプラインを維持していました。Google Workspace をデプロイせずに Cloud Identity を使用していたため、より直接的なアプローチが必要でした。以前は、Best Buy における Power BI と BigQuery の連携は、サービスアカウントの認証情報に依存していました。

このパターンは小規模なチームでは機能しますが、チームが拡大するにつれて、いつの間にか負債になっていきます。

サービスアカウントのキーを手動でローテーションするということは、各チームが保持する認証情報を追跡し、すべてのキーが潜在的なセキュリティの脆弱性であることを受け入れることを意味していました。サービスアカウントキーは、Best Buy のセキュリティチームとプラットフォームチームにとって日々の運用の妨げとなっていました。また、データアクセス要件が複雑化するにつれて、技術的負債も蓄積していきました。

数万人のユーザーをサポートするために、Best Buy は ID アーキテクチャをモダナイズしました。チームは、Workforce Identity 連携を採用して、既存の Entra ID の ID を Google Cloud に直接連携しました。

現在、デベロッパーが Power BI を通じて BigQuery にアクセスする際は、既存の Entra ID の ID を使用して本人認証を行います。キーのローテーション、チャットメッセージで認証情報が公開されることの心配、監査ログで誰がアクションを実行したかの推測をする必要はもうありません。

このアーキテクチャは、2 つのコンポーネントが連携して動作します。Entra ID が認証を処理し、Workforce Identity 連携が Entra ID と Google Cloud 間の信頼関係を仲介します。この連携は Google 側ではステートレスです。ユーザーレコードを同期するのではなく、アクセスの時点でトークンを検証します。サービスアカウントキーのレイヤを削除することで、認証情報管理の負担が大幅に軽減されます。

アーキテクチャ

下の図は、Entra ID から Workforce Identity 連携を介して、Best Buy でチームが使用するサービスにどのように ID が流れるかを示しています。以前のアプローチからの主な変更点は、サービスアカウントキーのレイヤが完全に削除されたことです。Entra ID と Google Cloud の間で管理する認証情報はありません。

ID は Entra ID から Workforce Identity 連携を介して、Best Buy のチームが使用するサービスに流れる

実装に関する主な決定事項

このアーキテクチャを実装するにあたり、Best Buy はいくつかの重要な技術的選択を行いました。

Entra ID でプロビジョニングアプリと SSO アプリを分離する: 構成は、Entra ID のプロビジョニングとシングルサインオン（SSO）の設定ガイドに沿っています。Entra ID でプロビジョニングアプリケーションと SSO アプリケーションを分離する必要があります。2 つの異なるエンタープライズアプリとして実行すると、関心の分離がより明確になります。プロビジョニングの変更が SSO 構成に影響を与えることはなく、その逆も同様です。
Automation OU を慎重に配置する: Entra ID プロビジョニングサービスアカウントを別の組織部門（OU）に配置し、その組織部門の SSO を明示的に無効にする必要があります。これにより、ブートストラップの問題（SSO をグローバルに適用すると、プロビジョニングアカウントが認証を行えず、そもそもプロビジョニングの設定ができなくなる）を回避できます。
同期不要とは、Google 側がステートレスであることを理解する: Workforce Identity 連携では、Cloud Identity にユーザーレコードを作成または保持することはありません。アクセスの時点でトークンを検証します。これにより、同期の遅延、古いレコードのクリーンアップ、個別のプロビジョニングパイプラインが不要になるため、Best Buy の目標規模に合ったアーキテクチャが実現します。

デベロッパー向けのセキュアな認証

デベロッパーにとって、この変更は実質的に意識されることはありませんでした。社内の Entra ID 認証情報で一度認証するだけで、Power BI を使用する場合でも、API を直接呼び出す場合でも、BigQuery に自動的にアクセスできます。SSO のエクスペリエンスは、Microsoft ID を使用してアクセスする他のすべてのものと一致します。

セキュリティチームとプラットフォームチームにとって、そのメリットは非常に大きいものです。認証情報管理による攻撃対象領域が消滅します。監査ログには、共有サービスアカウント ID ではなく個々のユーザーが表示されるようになり、手動での鍵のローテーションを待つのではなく、企業の ID ライフサイクルに基づいてアクセスを迅速に取り消すことができます。

現在、デベロッパーの Google Cloud アクセスをサービスアカウントキーで管理しているなら、Workforce Identity 連携への移行を検討する価値は十分にあります。セキュリティ上の大きなメリットが得られ、チームが拡大するにつれて運用が簡素化されます。Best Buy は現在、将来の小売業務を強化するために、このセキュアなアクセスをより幅広い従業員に拡大しています。

Workforce Identity 連携のサポートを拡大

Google Cloud は、あらゆる組織が独自の ID プロバイダを簡単に導入できるように、継続的に取り組んでいます。最近のアップデートにより、Ping Identity ユーザーの設定が簡素化され、オンライン請求先アカウントへのアクセスが拡張されました。

Ping Identity のインテグレーション: Ping Identity を使用している場合は、新しい専用のセットアップガイドに沿って連携を構成できます。このガイドでは、従業員を Google Cloud リソースにセキュアに接続するための手順を説明します。
オンライン請求サポート: Google Cloud は、オンライン請求先アカウントをお持ちのお客様をサポートします。Workforce Identity 連携を使用すると、企業請求契約を結ぶことなく、セキュアで同期不要のアクセスが可能になります。

使ってみる

Google Cloud は、クラウド導入の障壁を取り除き、組織が環境をより簡単に保護できるように取り組んでいます。これらの新機能を試し、組織の ID プロバイダを接続するには、Workforce Identity 連携で ID を直接連携させる方法の詳細を確認し、サポートされている Google Cloud サービスをご覧ください。

- Best Buy、クラウドエンジニアリング担当シニアマネージャー、Kishor Patil 氏

- Google Cloud Security、シニアプロダクトマネージャー、Stephen Cakebread

AlloyDB に追加されたグループ認証により、エンタープライズ規模の運用と AI エージェントのセキュリティを強化

Thu, 06 Aug 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 7 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

データベースセキュリティは従来、開発者が求める緻密なアクセス制御と、数千もの個別データベースパスワードの管理に伴う運用オーバーヘッドとの間の「危ういバランス」に頼ってきました。AI エージェントのアクセス管理、静的認証情報のローテーション、従業員のオンボーディングとオフボーディングの処理、アクセスログの監査など、パスワードは依然として運用上の負担であり、潜在的なセキュリティの脆弱性となっています。

Google Cloud の目標は、データベースアクセスを透過的でセキュア、かつパスワード不要なものにすることです。

Google はその取り組みにおいて重要な一歩を踏み出します。このたび、AlloyDB の Identity and Access Management（IAM）グループ認証がプレビュー版で利用可能になりました。この機能により、エンタープライズワークロードに ID 主導のアクセス制御がもたらされます。

Cloud SQL のお客様は、すでにこの認証パターンを導入して大きな成果を上げており、今回のリリースにより、両サービスでセキュリティ体制が統一されることになります。

個々のスケールに関する問題

長年にわたり、Cloud SQL と AlloyDB は、ネイティブな IAM 認証を使用して、個々の Google Cloud ID をデータベースユーザーに直接マッピングしてきました。しかし、エンタープライズ規模においては、アクセスを個別に管理すると、複雑さが大幅に増す可能性があります。

グループベースの管理を行わない場合、数百のインスタンスと数千のユーザーにスケールすると、次のような課題が生じます。

オンボーディングのボトルネック: 新しいチームメンバーごとにデータベースユーザーのプロビジョニングが必要になります。
オフボーディングのリスク: 分散データベース環境全体で従業員のアクセス権を完全に削除するには、監査が複雑になる可能性があります。
ポリシーの逸脱: 開発、ステージング、本番環境のシステム間で同一の権限を維持すると、エラーが発生しやすくなります。

このような課題に直面すると、アプリケーション全体にサービスを提供するために、単一の強力なユーザーアカウントまたはサービスアカウントを使用したいという誘惑に駆られます。しかし、このような強力なアプリケーションアカウントのアクセスを単純化しすぎると、リスクにさらされ、詳細な監査機能が失われるという代償が伴います。

エージェント型 AI の未来を守る

規模に関する課題は、もはや人間のユーザーだけにとどまりません。組織がデプロイする AI エージェントの数が増えるにつれて、データベースの ID とアクセス制御の管理はより複雑になります。

AI エージェントが汎用の共有アカウントや広範なサービスアカウントを使用してデータベースに接続する場合、混乱した使節の問題を引き起こすリスクがあります。ユーザーの ID を引き継ぐ代わりに、過剰な権限を持つ認証情報を使用すると、エージェントは、アクションをリクエストしたエンドユーザーが閲覧を許可されている範囲を超えてデータにアクセスしたり、データを変更したりする可能性があります。さらに重要なことに、アクションが汎用サービスアカウントに紐付けられるため、監査ログから個別の責任の所在が失われてしまいます。

きめ細かい認証は、このリスクを軽減するのに役立ちます。エージェントはエンドユーザーの特定のアイデンティティと認証スコープをデータベース層まで引き渡すことができるため、クエリはユーザーに代わって実行され、データアクセスはエンドユーザーが許可されているオブジェクトのみに制限されます。

AI エージェントを介してユーザーグループ ID を AlloyDB に渡すことで、データベースはアクセスを承認し、正確な監査証跡を記録できます。

IAM グループ認証は、このアーキテクチャを簡素化します。セキュリティチームは、エージェントとユーザーの組み合わせごとにマイクロ権限を管理する代わりに、最大 200 個の機能的な Google グループ（financial-agents@company.com や regional-analysts@company.com など）を定義できます。Google Cloud のマネージドデータベースインフラストラクチャは、ユーザーのグループコンテキストを検証し、データベースまたはテーブルのレベルでデータアクセスが承認されるようにします。また、監査ログには、アクセスされたデータ、変更されたデータ、誰の代理として行われたかが正確に記録されます。

デジタルリーダーにとっての実証された価値

一元化された ID の原則を採用することで、すでに運用スピードを向上させている企業があります。大手プラットフォームポイントプログラムの Bilt は、Google の統合アプローチを使用して、大規模なデータベース環境のセキュリティ強化に役立てています。

「AlloyDB のグループベースの IAM と、自動化されたグループ管理および Privileged Access Manager（PAM）の権限を組み合わせることで、共有認証情報のリスクを完全に排除しました。データベースとロールのプロビジョニングは、初日から完全にテンプレート化されているため、エンジニアは必要なときに必要なデータにのみ安全にアクセスできます」と、Bilt の CTO である Kosta Krauth 氏は述べています。

パスワードレスアクセスのための統合ブループリント

今回のリリースにより、Google Cloud は Cloud SQL と AlloyDB の両方にわたるアクセス制御の統合アプローチを提供します。組織は、リレーショナルデータベースポートフォリオ全体に対して、標準化された多層防御アクセス戦略を適用できるようになりました。

IAM グループ認証を VPC Service Controls、組織のポリシー、IAM 条件、Private Service Connect などの機能と組み合わせることで、セキュリティチームは、人間のエンジニアによるアクセスか自律型 AI エージェントによるアクセスかを問わず、データベースアクセスが、検証済みの企業 ID とセキュアなネットワーク境界にバインドされるようにすることができます。

ゼロトラストデータベースの未来に向けて

セキュリティによって、エンジニアリングの速度とコンプライアンスの間に妥協が生じるべきではありません。AlloyDB と、Cloud Identity および Workforce Identity 連携を統合することで、データベース管理の摩擦を解消し、よりセキュアなアーキテクチャの実装を支援します。

この機能を今すぐお試しになり、グループベースのデータベースロールを設定する方法をご確認ください。セキュリティとコンプライアンスに関するその他の推奨事項とベストプラクティスについては、ドキュメントをご覧ください。

- プロダクトマネージャー、Bjoern Rost

- プロダクトマネージャー、Alok Srivastava

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

Wed, 29 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

セキュリティチームは、シャドー AI にどのように対応すべきでしょうか？デベロッパーが正式に登録せずにデプロイしたワークロードは、多くの場合、従来のセキュリティスキャナを回避できます。特権 DaemonSet、カーネルレベルのアクセス、Pod 仕様の手動編集を求めることで、開発を遅らせて安定性を損なうことに組織が消極的であるためです。

この行き詰まりを打開するため、Google はこのたび k8s-aibom をオープンソース化いたしました。この特権なしの軽量 Kubernetes コントローラは、クラスタ API とコンテナ環境を継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning Bill of Materials（ML-BOM）を生成します。

k8s-aibom は、ワークロードが正式に登録されているかどうかに関係なく、ランタイム実行から直接、監査に適した可視性を自動的に確保し、デベロッパーに統合の負担をかけることなく AI プロジェクトをパイロットから本番環境に安全に移行できるようチームを支援します。

負担のないアーキテクチャ

k8s-aibom は、総合的な可視性に関する CISO の要件と、クラスタの安定性に関する SRE の要件の両方を尊重するようにゼロから設計されています。k8s-aibom-system Namespace に、特権なしの単一の Deployment としてデプロイされます。デベロッパー側の負担はゼロです。サイドカー、eBPF カーネルモジュール、特権 DaemonSet は不要で、既存のデベロッパー Pod 仕様を変更する必要もありません。

k8s-aibom は AI ワークロードを監視し、BOM を生成します。

検出パイプラインは、次の 4 つの明確な段階を経て実行されます。

クラスタワークロードのスクレイピング: コントローラは、クラスタ全体で KServe リソース、Deployment、StatefulSet、DaemonSet、Job を継続的にモニタリングします。
AI スタックの特定: 高度なパターンマッチングにより、コンテナイメージ、環境変数、コマンドライン引数を検査して、サービングランタイム（vLLM、Triton Inference Server、TGI、Ollama）、自律型エージェントフレームワーク（LangChain、AutoGen、CrewAI）、ベクトルデータベースと RAG ストア（Milvus、Qdrant、pgvector）、分散トレーニングジョブと評価ハーネスを検出します。
標準的なマニフェストの生成: コントローラは、検出されたアーティファクトを正式な OWASP CycloneDX 1.6 Machine Learning Bill of Materials（ML-BOM）ドキュメントにコンパイルします。
シンクへのエクスポート: コントローラは、生成された ML-BOM をクラスタ内の AIBOM カスタムリソース（CR）のカスタムリソースステータス（status.bomDocument）に直接アタッチし、Google Cloud Storage バケットや外部 Webhook エンドポイントなどのオプションの外部シンクにルーティングします。

アプリケーションチームが、Pod 仕様の変更、サイドカーコンテナの挿入、継続的インテグレーションと継続的デリバリー（CI / CD）のパイプラインの変更を行う必要はありません。さらに、k8s-aibom は Kubernetes クラスタの状態を純粋な関数入力として扱うため、同一のクラスタ入力からは、バイト単位で同一の ML-BOM ドキュメントが生成されます。この決定論的プロパティを持つ k8s-aibom は、GitOps ワークフローに最適です。これにより、サイト信頼性エンジニア（SRE）は、AI の依存関係がドリフトしたときに正確な差分を実行し、精密な変更検出アラートをトリガーできます。

既存の AIBOM ツールでカバーできない領域

多くの AI BOM ソリューションはビルド時スキャナを備えており、保存されているアーティファクトから BOM を生成します。これらのツールを使用すると、デプロイする予定だったコードを追跡できます。

商用 AI セキュリティプラットフォームは、クラウドネイティブなポスチャー管理によって可視化できる範囲を拡大しますが、通常はベンダー固有のデータモデルを中心に形成された外部スキャンによってこれを実現します。こうしたツールで、コンプライアンスレビュー担当者、セキュリティ運用（SecOps）チーム、プラットフォームエンジニアが、現在何が実行されているか、どこに接続しているか、アサーションを検証するにはどうすればよいかを把握できることはほとんどありません。

Google は k8s-aibom を、このギャップを埋めるための専用ツールとして構築しました。k8s-aibom は、アーティファクトのスキャンではなく、ライブクラスタの観測から BOM を生成し、ベンダー独自の形式ではなく、より広範な OWASP および Open Source Security Foundation（OpenSSF）サプライチェーンエコシステムと統合する標準準拠の CycloneDX 1.6 ML-BOM を出力します。また、準拠する Kubernetes クラスタで特権なしのコントローラとして実行されるため、既存のビルド時およびポスチャー管理ツールの代わりとなるのではなく、これらを補完するものとなります。

信頼度モデル: 意図と推論の分離

コンプライアンス監査担当者や SecOps エンジニアにとって、未加工のテレメトリーがノイズになることがよくあります。標準的なモニタリングツールは、コンテナが実行中であることを示しますが、AI モデルがプラットフォームエンジニアによって明示的に構成されたのか、実行時に自律スクリプトによって動的に抽出されたのかを証明することはできません。k8s-aibom は、その決定論的な信頼度モデルによってこの曖昧さを解消し、検出されたアセットを明確な階層に分類します。

宣言: ワークロード構成で、顧客またはデベロッパーによって明示的に定義された（例: --model meta-llama/Llama-2-7b など、明示的に渡されたコンテナ引数）。「宣言」の信頼度検出は、人間の明確な意図を表します。
推論: コンテナイメージ、環境変数、実行プロファイルの詳細な検査を通じて、コントローラのパターンマッチングエンジンによって自律的に導出された（例: ^vllm/.* コンテナ署名の特定）。
未解決: アクティブな AI の存在が検出されたが、正確なモデルパラメータ、重み、バージョンを決定論的に確立できないワークロードに適用される。「未解決」の信頼度検出の場合、対象を絞ったセキュリティレビュー向けにワークロードに即座にフラグが付けられます。

この構造化された分類により、コンプライアンスレビュー担当者は、明示的なエンジニアリングの意図と機械の推論を即座に分離し、監査中に揺るぎない信頼の連鎖を確立できます。

不変性と最小権限: 監査に適したセキュリティモデルの構築

侵害されたノードや権限が昇格された管理者によってログや指標が変更、削除、改ざんされる可能性があるため、監査担当者は標準的なオブザーバビリティテレメトリーに対して依然として強い懐疑心を抱いています。k8s-aibom は、厳格な最小権限の分離とデータの不変性をベースにした、監査に適した証拠トレイルを確立します。

このコントローラは、最小限の Identity and Access Management（IAM）Workload Identity にバインドされた専用の Kubernetes サービスアカウントの下で動作します。BOM レコードを外部ストレージシンクに書き込む権限を持つ唯一の ID として機能し、roles/storage.objectCreator 権限のみを必要とします。

Google Cloud Storage の外部シンクの実装では、最も厳格な監査基準と証拠基準を満たすために、オブジェクト作成時に DoesNotExist 事前条件が適用されます。ML-BOM が Cloud Storage バケットに書き込まれると、オブジェクトは暗号化され、変更できなくなります。

侵害されたクラスタアクターや不正なワークロードによって、サイレントに上書き、変更、または遡及的に改ざんされることはありません。SecOps チームは、規制当局に提出された過去の監査ログが、クラスタ実行の変更不可能な記録であることを絶対的に保証できます。

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

k8s-aibom は、標準化された CycloneDX 1.6 ML-BOM の生成を自動化することで、低レベルの Kubernetes ランタイム状態と高レベルのガバナンスフレームワークのギャップを直接的に埋めます。また、主要な国際基準に不可欠な基礎的実証データを提供することで、停滞していた GKE AI のデプロイの道を切り拓きます。

EU AI 規則: 組織が第 12 条（継続的なトレーサビリティのための自動ロギングと記録保持）と第 50 条（AI システムの透明性義務）に準拠できるように設計されています。このツールは、サービングランタイムとエージェントスタックを自動的にカタログ化することで、コンプライアンス監査中に必要となる可能性のある技術的証拠の収集を簡素化します。
NIST AI リスク管理フレームワーク（AI RMF）: ガバナンス、マッピング、測定、管理の各機能を実現する、継続的かつ実証的なアセットの可視性がもたらされ、コンプライアンスワークフローを、純粋な手動チェックから、より自動化されたアセットインベントリトラッキングへと移行できます。
ISO/IEC 42001: AI マネジメントシステムのアセットの検出と追跡に関するコンプライアンスの取り組みをサポートし、インベントリの検証における手動のスプレッドシート入力や定期的なスナップショット監査への依存度を低下させます。

ご利用にあたって

k8s-aibom は、CISO、ガバナンス、リスク、コンプライアンスの各チーム、SecOps チーム、プラットフォームエンジニア、デベロッパーに影響を与えるシャドー AI の多面的な問題の軽減に役立つ数少ない技術ソリューションの一つです。

このコントローラの詳細とカスタムリソース定義について、またオープンソースの k8s-aibom プロジェクトにご協力いただける場合は、k8s-aibom GitHub リポジトリをご覧ください。

- グループプロダクトマネージャー、Glen Messenger

重要な第三者として英国金融セクターのレジリエンス向上に貢献

Tue, 28 Jul 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 7 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は、金融エコシステムにおける自らの役割を非常に重く受け止めています。私たちは、責任あるイノベーションを推進し、維持するためには、オペレーショナルレジリエンスが不可欠であると確信しています。

この度 Google は、英国のお客様に直接関わる、金融セクターに対する継続的な取り組みにおいて重要な節目を迎えました。7 月 10 日、英国財務省は CTP 制度に基づき、Google Cloud EMEA を英国金融セクターにおける重要な第三者（Critical Third Party: CTP）として指定しました。

この指定は、Google Cloud のサービスを利用している英国企業の数や種類、およびそれらのユースケースの重要性を考慮したものです。Google Cloud は、当社のサービスが英国の金融システムに及ぼすシステム的な影響に関する HMT（英国財務省）の判断を真摯に受け止めており、英国金融システムの安定性と信頼性を確保するうえで、自らの責務を果たすことに尽力しています。

金融セクター全体のレジリエンスを強化

Google Cloud EMEA は、CTP として、イングランド銀行、健全性規制機構（PRA）、金融行動監視機構（FCA）による直接的な監督を受けることになります。これらの当局は、総称して英国金融規制当局と呼ばれています。

英国金融規制当局は、CTP を監督するにあたり、金融セクター全体のオペレーショナルレジリエンスの向上を目指します。Google Cloud は、この目標を全面的にサポートします。

より深い連携という新たな段階に入るにあたり、Google Cloud は引き続き英国金融規制当局と建設的な対話を進めてまいります。また、この継続的な対話が、英国金融セクターに具体的なメリットをもたらすものと確信しております。

カスタマーサクセスの実現

Google Cloud は、効果的な監督に向けた当社のコミットメントと並行して、オペレーショナルレジリエンス、アウトソーシング、サードパーティのリスク管理といった英国企業に求められる要件への対応について、お客様を支援することに引き続き尽力してまいります。

SS1/21 ホワイトペーパーでは、PRA 監督声明 1/21 に基づくオペレーショナルレジリエンスの義務を Google Cloud がどのように支援できるかについて詳しく説明しています。
SS2/21 マッピングでは、PRA 監督声明 2/21 に基づく英国企業向けのアウトソーシングとサードパーティのリスク管理の要件に対し、Google Cloud の契約がどのように対応しているかを説明しています。

CTP 制度はこれらの要件に代わるものではありませんが、それらを補完するように設計されています。Google Cloud は、その役割を十分に果たせると確信しています。

今後の対応

CTP 制度の下で、英国の金融規制当局と協力していくことを楽しみにしています。Google Cloud は、お客様とその規制当局に対する現在のアプローチと同様の姿勢で、継続的な透明性と保証への取り組みを堅持してまいります。

この新しい時代が始まっても、私たちの中核的な目標は変わりません。それは、Google Cloud がデジタルトランスフォーメーションにおいて最もセキュアで、スケーラブルかつレジリエンスに優れたプラットフォームであることを保証することです。

- Google Cloud、リスクおよびコンプライアンス担当バイスプレジデント、Jeanette Manfra

- Google Cloud ヨーロッパ、中東、アフリカ担当プレジデント、Tara Brady

CodeMender プレビュー版の提供開始：ソフトウェアの脆弱性を検出および修正

Wed, 22 Jul 2026 01:00:00 +0000

敵対的な AI 活用による脅威がコードへの攻撃を加速させるなか、セキュリティチームには、コードの修復を自動化し、 AI に対して AI で対抗するマシンスピードの防御策でこれらに立ち向かう必要があります。

CodeMender は、Google のマネージドコードセキュリティエージェントです。本日より、コードスキャンおよび修復機能をプレビュー版としてお客様に直接提供を開始します。

CodeMender は、Gemini Enterprise Agent Platform を通じて、一般提供中のモデルを利用できるほか、Google AI Threat Defense のコアコンポーネントとして導入することもできます。

また、CodeMender はマルチモデルアプローチに対応しており、コスト、速度、ディープスキャン性能の最適化に合わせて適切なモデルを選択できます。今年の後半には、サードパーティのフロンティアモデルの選択肢も追加する予定です。

Gemini Enterprise Agent Platform における CodeMender の概要動画をご覧ください。

CodeMender は、受動的なスキャンから自動化されたコード修復への移行を支援し、ゼロデイリスクを低減します。開発速度を損なうことなく、既存のコードセキュリティの問題を次のように検証して修復します。

最適なモデルのデプロイ：コスト、速度、詳細なスキャン、コーディングのパフォーマンスに合わせて、複数のモデルから最適なものを選択できます。
マシンスケールでの自動修復：開発者がプロセスを把握できる状態を維持しながら、手動での検証やパッチ適用による修復のボトルネックを解消できます。
悪用可能性に基づく修復の優先順位付け：概念実証（ PoC ）エクスプロイトを実行してシミュレーションを行い、コード内の脆弱性が悪用可能かどうかを検証した上で、重大な問題の修正にリソースを優先的に割り当てることができます。

AI による脆弱性の検出と修正

Google DeepMind の先駆的な AI 研究から生まれた CodeMender は、ボトルネックとなっていた手作業による脆弱性管理を、自律的かつ高速に処理するシステムへと変換します。開発者やセキュリティ担当者は、ソフトウェアの欠陥を自動的にスキャンし、実行可能なエクスプロイトで検証した上で、テスト済みの修正コードによって修復できます。

「Salesforce において、信頼は最優先の価値であり、お客様のデータを保護することは、リスクの検出、検証、軽減に関する基準を常に高め続けることを意味します。 CodeMender は、検証済みの脆弱性をテスト済みの修正へ迅速につなげることで、セキュリティライフサイクルの重要な部分に AI を導入します。AI が脅威環境を変化させるなか、このような機能はレジリエンスを強化し、お客様が安心してイノベーションを継続できるよう支援します。」

— Iain Mulholland 氏（ Salesforce CISO ）

「CodeMender は、他の AI 対応ツールが完全に見落としていた重大な脆弱性を的確に特定しました。単に理論上の欠陥を発見するだけでなく、直接的なリスクを証明し、コアビジネスロジックを妨げることなく環境を保護する、検証済みの的確な修正を提供します。」

— Scott Ponte 氏（ Robinhood セキュリティオペレーション責任者）

「CodeMender は高速かつ包括的であり、検出から修正までのプロセスを完結させるという意欲的なアプローチを備えています。これにより、チームは開発速度を落とすことなくソフトウェアサプライチェーンの安全性を確保できます。」

— Ashwin Kannan 氏（ Palo Alto Networks CTO オフィスプリンシパル AI エンジニア）

CodeMender エージェントの仕組み

CodeMender を支える実行基盤には、最新のエージェントスキル、セキュリティツール、システムプロンプトを含む Google DeepMind の研究成果を継続的に反映しています。

セキュアバイデザインな Agent Platform 上で動作する CodeMender は、VPC 経由の安全なトラフィックルーティング、データの分離と暗号化、ソースコードデータを保持しないゼロリテンションポリシーなど、エンタープライズグレードの組み込みガバナンスとセキュリティガードレールによって保護されています。

エージェントとして、既存の継続的インテグレーション / 継続的デリバリー（ CI/CD ）ワークフローに組み込むことも、軽量なコマンドラインインターフェース（ CLI ）クライアントを使用してローカルの開発環境で直接実行できます。

また、ユーザーが管理するサンドボックス内でコードをスキャンして分析するように CodeMender を設定することもできます。エージェントはコードリポジトリに接続し、VS Code や Antigravity などの開発者ツールと連携して、ファーストパーティ、オープンソース、サードパーティのソフトウェアを安全に分析します。

スキャン：柔軟なモデルスキャンで隠れた脆弱性を検出

CodeMender は、主要な脆弱性クラスをスキャンし、ソフトウェアリポジトリやアプリケーション独自のコンテキスト、目的、機能を理解します。

スキャン：新たに発見された脆弱性を重大度とタイプ別に分類します。

セキュリティコンテキストを備えた CodeMender のハーネスは、静的解析やモデルのみのスキャンでは見落としてしまう複雑な脆弱性の発見に役立ちます。メモリ破損、インジェクション、Web セキュリティ上の問題、暗号の欠陥、安全でないデータ処理など、検出が困難な脆弱性を探索します。CodeMender は、 C/C++、Go、Java、Python、Ruby、Rust、TypeScript などの一般的なプログラミング言語をサポートしています。

検証：エクスプロイトのシミュレーションと検証によりノイズを削減

CodeMender は、問題を修正する前に脆弱性が現実のリスクをもたらすことを証明することで、アラート疲れや誤検知の削減に貢献します。このエージェントは、顧客が管理する隔離された顧客管理下のサンドボックス内で自身が構築、実行するエクスプロイトコードを用いて攻撃をシミュレートし、単なる静的なコードパターン分析を超えた検証を行います。

検証：検証プランを作成し、ユーザーのサンドボックス環境内でエクスプロイトを構築およびテストします。

エージェントはこの概念実証（ PoC ）エクスプロイトを使用して、セキュリティ上の欠陥が現実のリスクをもたらすことを検証します。この重要な検証フェーズにより、セキュリティ担当者や開発者は誤検知を排除し、検証済みのリスクに優先的に対応できるようになります。

修復：コード修正の自動生成とテスト

リスクのあるセキュリティ上の欠陥を特定することは、対策の半分にすぎません。脆弱性が検証されると、CodeMender は問題を解決するための安全なパッチを自動生成します。修正内容はコードの差分（ diff ）として開発者ツールに直接提供するため、既存の開発ワークフローに組み込むことができます。

修復：開発者のレビューと承認のために、コードの差分（ diff ）を含むコード修正を生成してテストします。

さらに、CodeMender は、LLM-as-a-judge を使用して既存のアプリケーション機能に影響を与えないことを確認し、修正の精度をさらに高めます。また、独自のコーディング規約やスタイルのコンテキストを提供することで、それに沿ったコードを CodeMender に生成させることも可能です。コードがリポジトリにコミットされる前に、開発者が CodeMender のパッチを手動でレビューおよび承認するため、常に開発者が管理権限を維持します。

AI Threat Defense における CodeMender

AI Threat Defense の一部として活用する場合、Wiz はエージェント型のアプリケーションセキュリティをオーケストレートし、アプリケーションを分析して調査の優先順位付けを行います。Wiz は CodeMender を呼び出してコードをスキャンし（近日提供予定）、デプロイコンテキストを用いて Wiz Security Graph 内の検出結果を補強します。さらに、Wiz Red Agent を起動して AI ペネトレーションテストを行い、悪用可能性を検証することで、チームが特に高リスクな脆弱性に集中できるようにします。

AI Threat Defense システム内における Wiz と CodeMender の連動アーキテクチャ図。コードスキャンからペネトレーションテストまでのフローが示されている

Wiz は、AI Threat Defense における修復の管理とスケーリングを行うコマンドセンターとして機能します。Wiz Green Agent は、Security Graph から得られるアプリケーションのコンテキストで強化された高精度なパッチの生成とテストを CodeMender に指示し、このライフサイクルを制御します。このワークフローにより、チームはこれまでにないスピードと精度で複雑な脆弱性を解消できるようになります。

CodeMender を使い始めるには

CodeMender は、Google のマルチモデルアプローチに沿って、コスト、速度、詳細なスキャンパフォーマンスの最適化を支援します。

Agent Platform を通じて一般提供している Google の Gemini モデルで CodeMender を利用できるほか、 AI Threat Defense のコアコンポーネントとして導入することも可能です。

Gemini 3.5 Flash Cyber を搭載した CodeMender は、一部の政府機関や特定の組織および企業向けに提供します。アクセス対象は順次拡大していく予定です。

CodeMender は、継続的かつ自律的で自己修復を行うエージェント型のソフトウェア開発ライフサイクルに向けた重要な一歩であり、本番環境へデプロイする前に、コードの安全性確保、検証、パッチ適用を自律的に実行する未来を拓くものです。

CodeMender の詳細およびドキュメントの確認については、こちらをご覧ください。

セキュリティ & アイデンティティ

境界セキュリティのモダナイズ: VPC Service Controls によるスケーラブルな境界

アーキテクチャに沿った境界

上り（内向き）ルールと下り（外向き）ルールでフォルダや組織を指定可能

上り（内向き）ルール、下り（外向き）ルールでの Private Service Connect エンドポイントの使用

VPC からアクセス可能なサービスのパターン

違反修復ガイド

使ってみる

PHP コアの脆弱性 CVE-2026-109618 および CVE-2026-109619 への対応

脆弱性の背景

PHP の更新とアプリケーションの再デプロイ

サーバーレス プラットフォームにおける自動パッチ適用

Cloud Armor による CVE-2026-109618 と CVE-2026-109619 のリスク緩和

アプリケーションにおける WAF ルールの安全性の検証とテレメトリーの使用

モニタリングと監査

パッチ適用と修復

グローバル規模のハードウェア格納型セキュリティ: NVIDIA Blackwell を搭載した Confidential G4 の一般提供を開始

機密データとモデルを低レイテンシで保護

パフォーマンスのテスト

Confidential G4 を使ってみる

Cloud CISO の視点: CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティ エージェントと AI 防御機能を提供

Gemini Enterprise で構築された、新たなセキュリティ エージェントとエージェント型防御のご紹介

Secure Source Manager の新機能で CI / CD パイプラインを強化

主な機能

次のステップ

ゲーム チェンジャー: エージェント型 AI を使用してインフラストラクチャ コードを保護する

ソリューション アーキテクチャと実装

ローカライズされた脅威モデルの重要性

専門のトリアージ エージェントが開発を加速

バグ修正エージェントがループを閉じる

学んだことと行動喚起

きめ細かい制御が可能な、新しいネイティブ セッション管理ツールのご紹介

セッション管理の新機能

ご利用方法

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

Cloud KMS における耐量子鍵インポートの発表

脅威:「今すぐ保存、後で解読」攻撃

鍵を保護する耐量子エンベロープの構築

Google Cloud の PQC への取り組みにおける重要なマイルストーン

Fault Injection Testing で復元力テスト戦略を簡素化

ネイティブな復元力テストが重要な理由

Fault Injection Testing の仕組み

企業向けに設計

Fault Injection Testing を使ってみる

Cloud CISO の視点: AI 時代に水道事業者を保護するためのヒント

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティ サービスを提供

圧倒的な情報量と利便性を評価し、Google Threat Intelligence を導入

従来は検出できなかった脅威を可視化し、プロアクティブな防御を展開

1 年間の運用で得られた成果を基盤に、新たな SOC サービスの提供を開始

プライバシー重視の AI で脳腫瘍研究を後押し

課題: データを見ることなく AI を評価する

実世界における医療 AI の評価: MedPerf と GCP Confidential Computing のデモ

理論を大きな成果へ: 脳腫瘍研究のさらなる進展

臨床現場での信頼確立と検証

未来：安全な医療のブレークスルーを普及させる

PQC をわかりやすく解説: Google Cloud のポスト量子暗号ロードマップ

Google の戦略: 安全性を重視した設計

直近の進捗: 2026 年のマイルストーン

2029 年までのロードマップ

ドメイン 1: Store Now Decrypt Later（SNDL）の軽減

ロードマップ以下の変更は 2027 年の実施を目標としています。

ドメイン 2: 完全性と否認防止

ドメイン 3: 基盤と鍵管理

ロードマップGoogle は、2028 年までに以下マイルストーン達成を目標としています。

量子安全における責任の共有

共に進むこれからの道のり

Best Buy、Workforce Identity 連携で AI ワークロードをスケールし、アクセスを保護

サービス アカウントを直接連携に置き換える

アーキテクチャ

実装に関する主な決定事項

デベロッパー向けのセキュアな認証

Workforce Identity 連携のサポートを拡大

使ってみる

AlloyDB に追加されたグループ認証により、エンタープライズ規模の運用と AI エージェントのセキュリティを強化

個々のスケールに関する問題

エージェント型 AI の未来を守る

デジタル リーダーにとっての実証された価値

パスワードレス アクセスのための統合ブループリント

ゼロトラスト データベースの未来に向けて

サーバーレスプラットフォームにおける自動パッチ適用

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティエージェントと AI 防御機能を提供

Gemini Enterprise で構築された、新たなセキュリティエージェントとエージェント型防御のご紹介

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

ソリューションアーキテクチャと実装

専門のトリアージエージェントが開発を加速

きめ細かい制御が可能な、新しいネイティブセッション管理ツールのご紹介

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティサービスを提供

サービスアカウントを直接連携に置き換える

デジタルリーダーにとっての実証された価値

パスワードレスアクセスのための統合ブループリント

ゼロトラストデータベースの未来に向けて

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

不変性と最小権限: 監査に適したセキュリティモデルの構築

カスタマーサクセスの実現

スキャン：柔軟なモデルスキャンで隠れた脆弱性を検出