G-gen の武井です。当記事では、Google Cloud Next '26 のセッションの1つ、「Natively Integrating Wiz CNAPP with Google Security Operations」について、速報レポートをお届けします。

G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。

セッションの概要
Wiz の概要
アタックパスの可視化とトキシックコンビネーションの特定
Google SecOps と Wiz を統合するメリット
アーキテクチャ
- 事例1
- 事例2
おわりに

セッションの概要

本セッションでは、Google Cloud の SIEM/SOAR プロダクトである Google SecOps と、新たに Google ファミリーに加わった Wiz の統合について紹介されました。

登壇者は Google Cloud の David Shao 氏と、Wiz の Matt Zvolensky 氏の2名でした。昨今 Wiz と Google SecOps を組み合わせたときにどのようなシームレスな体験が得られるのかというお問い合わせが増えていることから、今回のセッション開催に至ったとのことです。

参考 : Google Security Operations（SecOps）
参考 : Wiz

Wiz の概要

Wiz は、マルチクラウド、プライベートクラウド、AI ワークロード、データ分析ワークロードまでを幅広く保護するクラウドセキュリティプラットフォームです。

その中核として、クラウド環境全体を可視化・保護する Wiz Cloud の他にも、開発段階からセキュリティを担保するシフトレフト向けの Wiz Code、またシフトライト側では、クラウド環境で実際に発生した脅威への検知・対応を担う Wiz Defend という 3つの製品で構成されています。

セッションでは、Wiz が裏側で稼働させている 3種類のエージェントも紹介されていました。アタックサーフェス（攻撃対象領域）をスキャンして攻撃者が狙う侵入経路を探すレッドエージェント、脅威の進行をプロアクティブに食い止めるブルーエージェント、そしてそれらを統括して「そもそもどう攻撃を未然に防ぐか」を設計するグリーンエージェントの3 つです。

アタックパスの可視化とトキシックコンビネーションの特定

攻撃者は、開発者のサイロやクラウドチームのサイロを個別に狙うのではなく、サイロを横断して侵入経路を組み立てる、という話が印象的でした。インターネットに露出したポートから侵入し、脆弱な VM を踏み台にして深く入り込み、Kubernetes の権限を悪用して最終的に PII へ到達する、といった経路がそのイメージです。

Wiz はこうした攻撃経路（アタックパス）を環境内でマッピングし、個々では問題がなくても組み合わさると危険になる要素、いわゆるトキシックコンビネーションを特定したうえで、対処方法まで提示してくれる、という点が強みとして紹介されていました。

内部ではグラフデータベースがリスクの優先順位付けを行っており、セキュリティ運用チームが「とにかくすべてにパッチを当てる」のではなく、本当に重要なアラートに集中できるようにするのが狙いとのことです。

Google SecOps と Wiz を統合するメリット

Google SecOps に Wiz を組み合わせる理由として、セッションでは次の3点が挙げられていました。

#	理由	意図
1	シフトレフトの実現	攻撃が発生する前にプロアクティブに防御し、特定したリスクを Google SecOps にフィードする
2	SOC の効率化	Wiz が膨大なイベントをフィルタリングし、重要な脅威のみを Google SecOps に送信することで、ノイズを減らす
3	セキュリティの民主化	SOC だけでなく、開発者やクラウドチームが Wiz を使用することで、リスクを低減させる

また、優先順位付けのインパクトを示す顧客事例も紹介されていました。

元のイベント数 : 約4億件
検知に該当 : 1,000 件
クラウドのコンテキストを踏まえた脅威 : 55 件
いますぐ対処すべき重要インシデント : 41 件

4億件近いイベントをすべて Google SecOps に流し込むことは可能ですが、Wiz 側で絞り込んだ 55 件、あるいは 41 件だけをフィードするほうが SOC 運用としてははるかに現実的だ、というのが本パートの主張でした。

アーキテクチャ

事例1

こちらの事例は、Wiz Defend が中心となってクラウド環境やアイデンティティに関する情報を収集し、先程のように優先順位付けを行ったうえで Google SecOps にログを連携し、一方の CrowdStrike やメール、ファイアウォール等のログはすべて Google SecOps が管理するという役割分担です。

Wiz と Google SecOps は API で接続されており、通信は双方向です。SOC 側でステータスを更新したりコメントを追加したりすると、その内容が Wiz 側にも反映されるため、同じインシデントを両プラットフォームから追いかけることができます。

事例2

こちらの事例は、Gemini Code Assist を Wiz と Google SecOps の両方の MCP サーバーに接続し、自然言語で管理します。

「Wiz で何が起きているか？」、「攻撃経路が見つかった場合、Google SecOps を使って対応を自動実行できるか？」といった質問を自然言語で投げ、各プラットフォームの横断した調査と対応につなげられるといったニュアンスで紹介されていました。

参考 : Gemini Code Assist Standard / Enterprise の概要

おわりに

本セッションを通じて語られていたのは、Wiz と Google SecOps の組み合わせが「プロアクティブな防御」と「インシデント発生後の対応」の両方をカバーできるという点でした。

Wiz でアタックパスを事前に発見してシフトレフトを効かせつつ、万一侵害が発生した場合には Google SecOps と Wiz Defend を組み合わせて、被害範囲・攻撃者の狙い・侵入経路・クリーンアップ方針を短時間で把握していく。こうした流れが Wiz と Google SecOps の組み合わせによって生まれるシームレスな体験だとわかりました。