Googleが明かす、クラウドセキュリティの「正解」と「不正解」

クラウドとAIの利用が進むにつれて、サイバー攻撃の脅威がますます深刻になってきた。問題はセキュリティの運用管理が複雑化する一方だということだ。簡素化・省力化する良い方法はないだろうか。Googleのセキュリティ専門家が脅威の実態と合わせて、その方法を解説した。

[土肥正弘，キーマンズネット]

グーグル・クラウド・ジャパンの高橋悟史氏

　グーグル・クラウド・ジャパンの高橋悟史氏（「高」は旧字体、カスタマー・エンジニアリング　テクノロジー部門セキュリティ・スペシャリスト）はGoogle Threat Intelligence Groupの調査（2025年上半期版）とGoogle Threat Intelligence Group（Google本体の調査チーム）の調査の結果を引用して、Google Cloudで観測された脅威トレンドを説明した後、Googleが薦めるベストな防御策を紹介した。

Geminiも標的に　生成AIを巡る新たな攻撃とGoogleの防御戦略

Googleが薦める防御策

• 攻撃者が狙っている場所を守る
• 狙われやすい対象領域を防御する「予防的統制」と「発見的統制」とは
• 発見的統制のメリットとデメリット
• クラウドのセキュリティ問題を検出するSecurity Command Centerの活用

　サイバー攻撃のきっかけはさまざまだが、高橋氏によれば、偵察や侵入などの初期攻撃の方法として最も多いのは「脆弱（ぜいじゃく）な認証情報」（45.7％）だ。

　管理コンソールにアクセスできるユーザーIDや、連携システムのサービスアカウントの脆弱なパスワード、アクセスキーといった認証情報が特に狙われやすい。初期攻撃はこの他、設定ミス（34.3％）やAPIやUIの侵害（17.1％）も用いる。

　攻撃者が標的の企業への初期侵入に成功した後、次に行うのが「ラテラルムーブメント（横移動）」だ（62.2％）。侵入したネットワーク内を移動しながら、他のシステムやサーバにアクセスして、価値の高い情報資産を探し出し、攻撃範囲を拡大していく。この一連の行動が「ラテラルムーブメント」と呼ばれる。

　攻撃者は攻撃時に生成AIを使いこなしている。攻撃対象の特定や有効な攻撃方法の選択に生成AIを利用する。「Gemini」などの生成AIを利用して、攻撃対象を特定したり、攻撃方法を選んだりする他、フィッシングメールやSNSメッセージの作成、DDoS攻撃ツールの作成などが目立つ。テキストを作成するだけでなく、ユーザーを誘導して攻撃するコンテンツ作成やチューニングを生成AIに担わせているケースもある。これまでは「日本語の壁」があり、攻撃者の使う不自然な日本語が目立っていた。だが、生成AIによる文脈を考慮した自然な翻訳は、日本語に堪能でない攻撃者も招き入れている。

　DDoS攻撃や脆弱性を狙うツールを生成AIで作れないようにする防止策は働いているのだろうか。高橋氏によればGeminiには不正なプロンプトには応答しないようにするフィルターが設けられているものの、それでも作成を試みる行動が続いているという。

　これは攻撃者が生成AIをツールとして使いこなすだけでなく、生成AIモデルそのものを後略する動きと連動している。

　生成AIサービスの安全対策をかいくぐって、攻撃用コード生成などをもくろむ攻撃者も現れた。プロンプト作成を工夫することによって、生成AIサービスをだまして危険なコードを出力させようとする行動を把握しているという。プロンプトインジェクションや脱獄プロンプトと呼ばれるものだ。

　国家による支援を受けているとみられる攻撃者集団APT41はGeminiに脱獄プロンプトを入力してGeminiの基盤情報を窃取しようとした。これはGeminiに実装された保護機能によって失敗したが、さまざまな生成AIモデルを攻略する方法はGitHubなどにも公開されており、脆弱なAIサービスや自社独自AIサービスを利用する場合には十分な警戒をしなければならない。

攻撃者が狙っている場所を守る

　サイバー防御を考える際、攻撃者が狙う領域（Attack Surface）を考慮しなければならない。

　高橋氏が指摘したのはクラウド環境への攻撃だ。「攻撃の対象領域が防御のポイントになり、そのポイントの脆弱性をなくして、さらに強力な認証をかける必要がある」と強調した。

　同氏は攻撃の対象領域と主な攻撃シナリオの例を3つ挙げた。

　1つ目は外部からアクセス可能なパブリックIPを持つ部分だ。VM（仮想マシン）やコンテナのOS、アプリケーションのライブラリ、ツールなどの脆弱性をついてOSでの実行権限を取得して侵入する攻撃シナリオだ。

　2つ目はAPIエンドポイントだ。クラウドサービスではAPIエンドポイント（URLなど）が公開されているため、ユーザー企業が誤って公開したサービスアカウトのキーや窃取したキーを利用してAPIを呼び出す。こうなると許されていない操作が可能になる。

　3つ目はコンシューマーなどに公開して提供されるAI（生成AI）サービスだ。外部に公開されている生成AIサービスに「脱獄プロンプト」を送り、悪性の応答を生成したり、生成AIを経由して機密情報を入手したりするというシナリオだ。

防御側の準備は2種類に分かれる　予防と発見だ

　狙われやすい対象領域を防御するためには2種類の準備が必要だと高橋氏は説いた。「予防的統制」とそれをかいくぐる攻撃を検知して対処する「発見的統制」だ。それぞれの準備の中身は細かく分かれる。

・予防的統制の例
　・ファイアウォールやIPS、WAFなどのネットワークの他、OSやコンテナなどのハードニング（対策強化）
　・IAM（Identity and Access Management）を用いた権限最少化やログ取得・アラート整備
　・認証強度をMFAやセキュリティキーで高めたり、組織ポリシーに準じた安全な設定を強制したりする
　・DDoS対策

・発見的統制の例
　・ログ取得やアラートの整備、システムへの設定変更の記録とアラート
　・ログ／イベント分析（異常検知）
　・異常を検知した後の対応方法の整備
　・機微情報の可視化とデータ移動の検知

　AIを利用した攻撃は今後さらに増加するだろう。これを考えると、今まで手薄になりがちだった発見的統制に着目した防御対策を強化していくことが欠かせない。

発見的統制のメリットとデメリットは？

　では発見的統制を強化するにはどのような方法があるのだろうか。

　まず考えたいのはログとアラートの仕組みを手組みで構築する方法だという。安価でカスタマイズ性が高い反面、ログに出力されない脅威は検知できず、悪性のIPアドレスやドメインなどの脅威データがないと限定的にしか検知できない。

　次にCSPM（Cloud Security Posture Management） やCNAAP（Cloud Native Application Protection Platform）といった専用のマネージドサービスを利用する方法だ。これはGoogleが提供する「Security Command Center」（SCC）などを利用することに当たる。メリットは設定の手間が少なく、ログ以外の検知も可能なことだ。脅威情報との突き合わせで検知の品質を高めることも可能だ。ただしコストは手組みに比べて高くなりがちだと高橋氏は語った。

　SIEM（Security Information and Event Management）やSOAR（Security Orchestration, Automation and Response）を利用する方法はどうだろうか。Googleも「Security Operations」としてこのようなサービスを提供している。脅威情報と突き合わせることで検知の品質を高めやすく、クラウド以外の操作端末やオフィスとクラウドまでの途中のログなどとの相関分析も可能だ。ただしコストはさらに高くなりがちだ。設定ミスの検知機能は弱く、CSPM、CNAAPとの併用が勧められるという。

Google Cloudに監視カメラを付けるSCC

　発見的統制を強化する3つの方法のメリット／デメリットを比較すると、発見的統制環境を導入するならまずはCSPM／CNAAPの導入から始めることが良いだろうと分かる。

　では、前述のGoogleが提供するCSSを使うのがCSPM／CNAPP導入の早道なのだろうか。

　CSSについて高橋氏は「Google Cloud環境の監視カメラ」のようなものだと分かりやすく説明した。SCCは、さまざまな設定のベストプラクティス（ベースライン）のデータを利用した上、同社が収集した脅威情報（その中には買収したMandiantのデータも含む）を照合する基本的な機能を備えている。

　それらデータを基に、VMやコンテナ、マネージドサービス（BigQuery, Cloud Storageなど）、IAM、VPC（**Virtual Private Cloud）について脆弱性や設定情報、ログを監視して、異常が見つかった際にアラートを出すことが可能だ（図1）。

図1　Google Security Command Center（SCC）がGoogle Cloudを監視するイメージ（提供：グーグル・クラウド・ジャパン）

　SCCはダークWebにある情報も取り込んで補強した高度な脅威情報との突き合わせが可能だ。そのため「SCCの設定画面には設定項目がほとんどなく、オン・オフだけで利用できる」と高橋氏は言う。実際にSCCのライセンスを有効化するとまず約24時間をかけてシステムがスキャンされて、その後はリアルタイムの監視情報が入手できるようになる。クラウド環境ではVMやVPCが頻繁に追加されることが多いが、不適切な設定があれば即座に検出可能だ。プリセットされたSCC設定は組織単位やプロジェクト単位で切り替えることもできる。

　こうした簡単設定で高レベルな監視が実行できるだけでなく、次のような機能も備えている。

OS、ソフトウェアの脆弱性検査機能

　脆弱性の公開情報（CVE、CVSSスコア）とMandiantの独自調査による脆弱性インパクトを用いてリスクを可視化して、脆弱性への対応優先順位付けに利用する。

仮想レッドチーム機能

　脆弱性検査チーム（レッドチーム）のように、外部からユーザーがデータを保有する場所（Cloud Storage、BigQuery、Cloud SQLなど）にアクセスできるかを調査できる（図2）。攻撃パスをシミュレーションして、設定だけでなく被害につながる可能性をリスクスコアとして可視化できる。アプリケーションだけでなくマネージサービスのAPIアクセスも監視対象になる。

図2　仮想レッドチーム機能の内容（提供：グーグル・クラウド・ジャパン）

マルチクラウド対応

　SCC Enterpriseエディションでは、Amazon Web Services（AWS）やMicrosoft Azureといった他のクラウドプラットフォームも監視対象にできる。

機能の拡充が続くSCC

　高橋氏は最後にSCCに最近追加された新機能について説明した。

　まず、SCC自体にログ取得機能を内蔵したことだ。VPCフローログについてユーザー側でのログ取得の必要性をなくして、SCCが自動取得して検知する機能が加わった。リスク検知のためのログ取得コストを削減できる。ただし、このログそのものにはユーザーがアクセスできないため、分析調査をしたい場合はユーザー側でもログ取得が必要になる。

　次にGoogleの「Vertex AI」関連アセットの自動可視化機能だ。Vertex AIでAPIエンドポイントやAIモデル、学習データセットの可視化が可能になった。これはSCC Enterpriseで利用できる。学習内容に個人情報などの機微情報が含まれていないかどうかも可視化できる（図3）。

図3　AI関連アセットの自動可視化機能では機微情報を検知できる（提供：グーグル・クラウド・ジャパン）

　最後にModel Armorだ。これはAIアプリケーションとユーザーの間の「盾」として機能してさまざまな脅威を検出・防御する機能だ。脱獄プロンプトによる不正な生成AI利用を防御できる。高橋氏によれば「生成AIに特化したWAF」だ。自社で構築したAIモデルに対しても、ファイアウォールのように悪性の命令をフィルターできる。単体購入も可能だが、SCCのライセンスに無料枠が付いている。

　SCCが提供するさまざまな機能を活用することによって、クラウド環境でこれから重要性を増していく「発見的統制」を強化できるというのが結論だ。

　なお「予防的統制」も必要だ。予防線を突破してくる攻撃に備えた上述のようなツールなどを用いた対策をコストが高くならないように組み合わせていかなければならない。特に脆弱な認証方法への対策、ラテラルムーブメントの検知とブロック、生成AIの悪用に関して焦点を当てたセキュリティ対策が今こそ求められているという。

本稿は2025年8月6日に開催された「Google Cloud Next Tokyo」でGoogleの高橋氏が講演した「クラウド・セキュリティ最前線 〜クラウドを狙う脅威の実態と対策〜」の講演内容を編集したものです。