セキュリティGoogleのクラウド基盤はなぜ、買収した「Wiz」をKubernetesに組み込んだのか。侵入後の異常を見張る新機能を確かめる
Google Cloudが2026年10月16日に発表した、コンテナ管理サービスGKE向けの新機能「Wiz Runtime Sensor」。侵入後の異常な動きをカーネルレベルで検知する仕組みと、組織全体への導入を強制できる新しいポリシー機能を公式発表から確認した
まず初めに
考えてみてほしい。何百もあるコンテナの集合体(クラスター)一つひとつに、手作業でセキュリティの見張り番を送り込み、各クラスターのAPIキーを律儀に配って回る。キーが漏れたら全クラスター分をローテーションし直す。——もはや現代のIT運用というより、戦国時代の狼煙(のろし)リレーの域である。Google CloudとWizは「それ、もう人間の手でやる仕事じゃないでしょう」と言わんばかりに、鍵の受け渡しも見張り番の配置も、まるごとクラウド側に預けられる仕組みを用意した。地味な話に聞こえるが、深夜のアラート対応に追われるインフラ担当者にとっては、眠れる夜が増えるかどうかを左右する類の「地味だが重要」な話である。※個人の感想です
何が起きているのか
Google Cloudは2026年10月16日、公式ブログで「Wiz Runtime Sensor」アドオンをGKE向けにプレビュー公開したと発表しました。執筆者はGoogle Cloud側のシニアプロダクトマネージャーDaniel L'Hommedieu氏と、Wiz側のプロダクトチームリードShahar Yakov氏です。対応するのは、標準のGKEクラスターと、運用をGoogle側に委ねるAutopilotモードのGKEクラスターの両方です。Wizは2025年にGoogleが買収を発表し、2026年3月11日に買収を完了したクラウドセキュリティ企業で、現在はGoogle Cloud傘下でブランドを維持したまま事業を続けています。
発表文は、これまでのKubernetesランタイム防御(動いているコンテナをリアルタイムで監視する仕組み)には運用上の摩擦が多かったと指摘しています。具体的には、(1)数十から数百に及ぶクラスターそれぞれに、外部ソースからの監視エージェントの導入・維持管理が必要になる「導入・維持管理の摩擦」、(2)APIキーをKubernetes Secretとして配布・ローテーションする際に生じる管理負担とセキュリティリスクである「認証情報の散乱」、(3)新しく作られたクラスターに監視エージェントの導入を義務づける仕組みが無く、徹底されないままになる「組織全体での強制の欠落」、(4)明確な上限を設けないと監視エージェント自体がCPU・メモリーを圧迫してしまう「性能面の負荷」の4点です。
新しいアドオンは、これらの課題に対応する形で複数の機能を備えています。まず、GKEのSecret Manager連携機能を使い、Wizの認証情報をクラスターの外にある一元管理の保管庫に置き、GKE側が自動的に取得してセンサーへ注入する仕組みになりました。保管庫側で鍵を更新すれば、クラスターの再起動なしに自動で反映されます。導入自体もgcloudコマンドやGKEのAPIから行えるようになり、センサーの配置・更新作業はGKEの管理機能側が担います。社内ネットワークで外部への通信を制限している環境向けに、HTTPやmTLSのプロキシ経由で監視データをWizへ送る仕組みも用意されました。さらに、組織のポリシー機能を使い、「Wiz Runtime Sensorを有効にしていない新規クラスターの作成を拒否する」という制約を設定でき、監視をすり抜けるための無断クラスター作成を防げるとしています。
検知の仕組み自体は、eBPFという、Linuxカーネルの内部で動く処理を安全に拡張する技術を使い、システムコール・稼働中のプロセス・ネットワーク接続・ファイルアクセスを継続的に監視します。これにより、リバースシェル(攻撃者が外部から遠隔操作できる状態にする手口)、不正な権限昇格、コンテナエスケープ(コンテナの外側のホスト環境へ侵入する行為)、不審な外部通信といった、侵入後の攻撃行動を検知できるとしています。各ノードに固定のメモリー上限を設けることで、負荷が変動するAI関連の処理などでも性能への影響を抑えられるとしており、センサー自体の更新もクラスターの更新作業とは独立して自動で行われます。
なぜ重要なのか
今回の発表が重要なのは、企業のシステムがクラウド上のコンテナ技術(Kubernetes)に依存する度合いが年々高まる中で、従来「導入が面倒だから後回しにされがちだった」運用時のセキュリティ監視が、クラウド事業者側の標準機能として組み込まれ始めている点です。発表文自身が「標準的な脆弱性スキャンは、保存された状態のファイルの基本的な設定ミスは見つけられるが、いま実際に進行中の攻撃を検知するには、リアルタイムのランタイム防御が必要になる」と説明しているとおり、事前のチェックと事後のリアルタイム監視は役割が異なり、両方が揃わないと攻撃の進行中に気づけないという課題があります。
また、組織のポリシー機能を使って「監視エージェントを入れていないクラスターの作成自体を拒否する」という強制の仕組みを用意した点も注目に値します。これまでは個々の担当者の判断や社内ルールの徹底に頼っていた「抜け漏れのない導入」を、技術的な仕組みで保証できるようになったことは、特に多数のクラスターを運用する大企業にとって、セキュリティ管理の実効性を高める変化です。
なお、WizはGoogleが2026年3月に買収を完了したセキュリティ企業であり、今回の統合は買収後の統合効果が具体的な機能として現れた例の一つでもあります。買収時点では、Wizが特定のクラウド事業者に限らない「マルチクラウド」路線を維持するかどうかが注目されていましたが、今回の発表はひとまずGoogle Cloudの自社サービス(GKE)向けの統合が先行する形になっています。
私たちへの影響
今回のアドオンはGoogle Cloudを利用する企業・開発者向けの機能であり、一般の利用者が直接操作したり設定を変える必要はありません。ただし、私たちが日常的に使っているWebサービスやスマートフォンアプリの多くは、裏側でKubernetesのようなコンテナ基盤の上で動いています。こうした基盤側の防御が強化されることは、利用しているサービス側で情報漏えいや不正アクセスといった被害が起きるリスクを減らす方向に働くという意味で、間接的には私たちにも関係があります。
もっとも、今回のアドオンはプレビュー版であり、実際に有効にするかどうかは各サービスの運営企業の判断に委ねられています。発表文は、既存の脆弱性スキャンだけでは不十分だとした上で、このアドオンを導入することで侵入後の挙動を検知できるようになるとしていますが、全てのサービスが直ちに導入するとは限らない点には留意が必要です。
初心者が知っておくべきこと
「Kubernetes」とは、多数のコンテナ(アプリケーションの実行環境をひとまとめにしたもの)を、複数のサーバーにまたがって自動的に配置・管理するための仕組みです。GKEは、Google Cloudがこの仕組みを管理サービスとして提供しているものです。
「ランタイムセキュリティ」とは、システムが実際に動いている最中の挙動を監視し、怪しい動きをリアルタイムで検知する考え方です。公開前のコードやファイルを静的にチェックする脆弱性スキャンとは役割が異なり、「攻撃者がすでに入り込んで、いま何かをしようとしている」状態を捉えることを目的としています。「eBPF」は、こうした監視をLinuxカーネルの内部で安全に行うための技術で、Wiz Runtime Sensorもこの技術を使って動作しています。
Q. この機能は無料で使えますか。
A. Google Cloudの公式料金説明では、GKEアドオン自体に追加料金はありません。ただしWiz Runtime Sensorの有効なライセンスが必要です。センサーが消費するCPU・メモリに応じて追加ノードが必要になる場合があり、Secret Managerを使う場合はその料金も適用されます。ライセンスの具体的な金額はこの資料に記載されていません。
IT Postの見方――「買ったものを、ちゃんと自社の売り物に仕立て直した」話
IT Postは、今回の発表を「Googleが320億ドルを投じて買ったWizを、ようやく自社サービスの中に実用レベルで組み込んできた」という進捗報告として受け止めている。大型買収をした企業が、買収先の技術を自社サービスへ統合する際に、名前だけ冠した“お飾り機能”で終わらせてしまう例は珍しくない。その点、今回はKubernetesの運用担当者が実際に頭を悩ませてきた「認証情報の管理」「導入の徹底」という地味で実務的な痛点にきちんと手を入れており、買収の実利を感じさせる仕上がりだと評価したい。
一方で、この手の「標準機能化」には別の側面もある。セキュリティ監視の仕組みが、特定のクラウド事業者の管理画面にどんどん統合されていくほど、その事業者から他のクラウドへ移る際の切り替えコストは上がっていく。Wizが買収前に売りにしていた「どのクラウドでも使えるマルチクラウド対応」という看板が、Google Cloudとの統合が進むにつれてどこまで実質を保てるのかは、今回の発表だけでは分からない。便利さの代わりに何を手放すことになるのか、企業のシステム担当者には、そこまで含めて見極めてほしいところだ。※個人の感想です
今後どうなりそうか
Google Cloudは今回の発表時点で、プレビューから一般提供(GA)への移行時期や、Wizライセンスの具体的な金額を明らかにしていません。一方、公式の導入文書は、GKEアドオン自体は追加料金なしとしつつ、Wiz Runtime Sensorの有効なライセンスを必須としています。ノード資源の消費に伴う追加ノードや、Secret Manager利用時の料金にも注意が必要です。IT Postでは、関連する続報が確認され次第、あらためて取り上げます。