【Next Tokyo 25 レポート】クラウド・セキュリティ最前線 〜クラウドを狙う脅威の実態と対策〜
こんにちは、クラウドエース株式会社 第一開発部の阿部です。
今回は、2025 年 8 月 5 日～ 6 日に開催された「Google Cloud Next Tokyo 2025」のセッションから、「クラウド・セキュリティ最前線 〜クラウドを狙う脅威の実態と対策〜」についてレポートします。
セッションの概要は下記からご覧いただけます。
セッションのポイント
- クラウド環境を狙うサイバー攻撃は激化しており、防御が突破され攻撃されていることを前提としたシステム運用が必要
- サイバー攻撃の手法は多様化しており、生成 AI を活用した攻撃や、生成 AI を狙った攻撃も増加している
- Google Cloud では、Security Command Center を活用することで、クラウド環境のセキュリティを強化できる
脅威の現状
NIST Cyber Security Framework 2.0 における対応のステップ
NIST Cyber Security Framework 2.0 (以降、CSF 2.0) によるサイバー攻撃への対応とステップは以下のように分類できます。
| ステップ | 内容 |
|---|---|
| 統治 | 組織のサイバーセキュリティリスクマネジメントの戦略、期待、ポリシーの確立 |
| 識別 | 対策の対象となる資産を洗い出し、セキュリティリスクを特定する |
| 防御 | リスクを低減するための対策を実施する。 ID 管理、認証、アクセス管理、データセキュリティ、プラットフォームセキュリティ等 |
| 対応 | 検知されたサイバーセキュリティに対するアクションの実行 |
| 復旧 | サイバーセキュリティインシデントの影響を受けた資産と業務の復旧 |
このうち、「防御」「対応」「復旧」のステップは、防御が突破されて攻撃されることを前提としています。
旧来のセキュリティ対策はいかに侵入されないかや攻撃を防ぐかを重視していましたが、現在は防御が突破されることを前提に、いかに迅速に対応し、影響を最小限に抑えるかが重要です。
NIST CSF 2.0 のドキュメントは下記のリンクからご覧いただけます。
- 参考リンク 1: NIST Cyber Security Framework 2.0 日本語訳 (IPA 提供)
- 参考リンク 2: セキュリティ関連 NIST 文書一覧 (IPA 提供)
Google Cloud Threat Horizon 2025 年 上半期レポート
Google Cloud Threat Horizon 2025 年 上半期レポートでは、クラウド環境における脅威の動向や新たな攻撃手法について分析されています。
セッションの中で特に注目されたポイントは以下の通りです。
- 初期攻撃 (偵察、侵入)の方法
- 脆弱な認証方法 (45.7%)
- 初期攻撃後におきる活動
- ラテラルムーブメント[1] (62.2%)
レポートの内容は下記のリンクからご覧いただけます。
攻撃者が生成 AI を活用
Google Threat Intelligence Group[2] の調査では、攻撃対象の特定や有効な攻撃方法の選択のために生成 AI を利用することで効率化を図っていることが明らかになっています。
特に、調査や誘導に使うコンテンツの作成やチューニング等で利用されています。
Gemini はマルウェアや攻撃ツールの作成などに関する応答をしないよう調整されているため、攻撃者の攻撃能力を飛躍的に向上するような試みは失敗に終わっています。
Gemini のセキュリティに関する詳細は下記のリンクからご確認ください。
- 参考リンク: 生成 AI の敵対的な不正使用
生成 AI を狙った攻撃
Gemini には安全対策が実装されており、危険なコードの生成などの要求に応答しないようになっていますが、攻撃者は脱獄プロンプトと呼ばれる手法で安全策を回避しようとしています。ただし、公開されている基本的な脱獄プロンプトへの対策は Gemini に実装済みのため、攻撃者の試みは失敗に終わっています。
APT41[3] は Gemini に対するプロンプトで Gemini の基板となるインフラストラクチャとシステムに関する情報を入手しようとしましたが、Gemini に対する Google の保護機能により失敗に終わっています。
対応のポイント
脅威と攻撃対象領域
攻撃者が攻撃を試みる領域(Attack Surface)として、これまで「外部からアクセス可能な VM やコンテナなどのリソース」や「マネージドサービスが提供する API エンドポイント」などがありましたが、ここに「コンシューマー向けに公開して提供している AI サービス」も追加されました。
| Attack Surface | 攻撃シナリオ例 |
|---|---|
| 外部アクセス可能な VM やコンテナ | VM やコンテナの OS、アプリケーションのライブラリ、ツールなどの脆弱性をついて OS 上での実行権限を取得して侵入 |
| マネージドサービスの API エンドポイント | 誤って公開したサービスアカウントのキーや盗んだキーを利用して API を呼び出し操作 |
| コンシューマ向け AI サービス | 外部公開の生成 AI サービスに対してプロンプトインジェクションを行い、悪性の応答を生成したり、生成 AI 経由で秘匿情報を入手する |
予防的統制と発見的統制
セキュリティ対策では、事前に実施する基本的な対策である予防的統制と、予防的統制では防ぎきれない攻撃への対策である発見的統制があります。
今般の脅威の進化から、発見的統制の重要性が増しています。
予防的統制の例
- Firewall、IPS、WAF などのネットワーク・セキュリティ
- OS、コンテナなどのハードニング
- IAM の最小権限
- ログの取得、アラートの整備
- 認証強度の強化 (MFA、セキュリティキー)
- 安全な設定の矯正 (組織ポリシー)
- DDoS 対策
発見的統制の例
- ログの取得、アラートの整備
- システムへの設定変更の記録とアラート
- ログ、イベント分析 (異常検知)
- 異常を検知した後の対応方法の整備
- 機微情報の可視化とデータ移動の検知
Google Cloud における発見的統制の実現方法
Google Cloud では、以下のような方法で発見的統制を実現できます。
| 方法 | メリット | デメリット |
|---|---|---|
| ログ系サービスとアラート通知 (手組み) | 安価、カスタマイズ範囲が広い | ログに出力されない脅威を検知できない、悪性の IP アドレス・ドメインなどの脅威データがないと検知が限定的、設定の手間が多い |
| CSPM、CNAPP などの専用製品の利用 | 設定の手間が少ない、ログ以外の検知も可能(ハイパーバイザーなど)、脅威情報との突き合わせで高い品質の検知が可能 | コストが高い |
| Google Security Operations などの SIEM/SOAR の利用 | 脅威情報との突き合わせで高い品質の検知が可能、クラウド以外の操作端末やオフィスからクラウドまでの途中のログなどとの相関分析が可能 | コストが高い、設定ミスの検知は弱い (CSPM、CNAPP との併用を推奨) |
Security Command Center のメリットと新機能
Security Command Center (以降、SCC) は、Google Cloud 環境の監視カメラのような役割を果たします。
例えば、継続的にクラウド上の設定が安全なものになっているか、VM やコンテナの OS やパッケージに脆弱性がないかを監視します。
SCC は Google Cloud のマネージドサービスであるため、複雑な設定は不要で、有効化するだけですぐセキュリティ監視を開始できます。
また、プロジェクトレベルの有効化とは別に組織レベルでも有効化できるため、組織内の全ての Google Cloud プロジェクトで監視を有効化できます。
SCC で検知するセキュリティ設定のベースラインは CIS Controls などのベストプラクティスに基づいています。
OS、ソフトウェアの脆弱性検査機能
SCC では、公開情報である CVE や CVSS スコアと共に Mandiant が独自に調査している脆弱性がおよぼすインパクト評価を使ってリスクを可視化します。
Mandiant では独自の調査を行っており、脅威アクターが脆弱性を実際に悪用しているか、ツールが存在しているか、といった指標でリスクレベルを決定しています。
Mandiant の調査結果は、Google Threat Intelligence という製品でも脆弱性情報として提供されています。
仮想 Red Team 機能
仮想 Red Team[4] とは、Google Cloud 内でデータを持つ可能性があるリソース (Google Cloud Storage、BigQuery、Cloud SQL など) に外部ネットワークへ開いたポートや脆弱性などを突いて実際にアクセスできるかをシミュレーションする機能です。
Google Cloud のリソースに外部から到達するパスは大きく分けて 2 つあります。
- ロードバランサ、または、 VM に付与されたパブリック IP アドレス
- マネージドサービスの API エンドポイント
これらのパスを参照して実際に侵入可能になっているかをシミュレーションします。
マルチクラウド対応: AWS、Azure
AWS、Azure の設定の問題を検出し、重要なリソースの到達可能性についても Google Cloud と同様に SCC で可視化できます。
新機能 1: SCC 自体にログ取得機能を内蔵
以前はネットワーク関連のセキュリティ監視を使用するために明示的に VPC フローログを取得する設定を有効化する必要がありました。
現在は、SCC 自体が VPC フローログを自動取得して検知する機能が追加されました。
明示的に取得する VPC フローログはロギングのコストが発生しますが、SCC の自動取得は無料で利用できます。
ただし、利用者自身で VPC フローログの詳細を調査したい場合は、引き続き VPC フローログを有効化する必要があります。
この機能の詳細は下記のリンクからご確認ください。
- 参考リンク: 基本的なログソース
新機能 2: AI 関連アセットの自動可視化 (SCC Enterprise)
組織の中で利用されている Vertex AI の API エンドポイントや、生成 AI モデル、データセットを自動的に可視化する機能が追加されました。
組織全体で、API エンドポイントやデータセットがあるかの全量を把握できるため、セキュリティの強化に役立ちます。
また、データセットの内容をスキャンし、機微情報の有無を検出することも可能です。
これらの機能の詳細は下記のリンクからご確認ください。
- 参考リンク 1: AI Protection の発表: AI 時代のセキュリティ
- 参考リンク 2: AI Protection overview
新機能 3: Model Armor
Model Armor は生成 AI モデルのセキュリティを強化するための機能で、プロンプトインジェクションや機密データの漏洩、攻撃的なコンテンツの応答などのリスクを軽減します。
Model Armor は Vertex AI の生成 AI モデルだけでなく、他社の生成 AI モデルの保護にも利用できます。
SCC とは別に単体でも利用可能であり、SCC Enterprise を利用している場合は無料枠が提供されます。
Model Armor の詳細は下記のリンクからご確認ください。
セッションまとめ
このセッションでは、クラウドに対する脅威の現状と、対応のポイント、および、SCC によるセキュリティ強化の方法について説明されました。
- クラウドに対する脅威: 従来の脅威に加えて、生成 AI を利用した脅威、AI をターゲットとした脅威が増加していること
- 脅威への対応のポイント: 公開している AI ベースのアプリケーションは新しい攻撃対象領域になっていることを踏まえ、予防的統制と発見的統制の両方が重要であること
- Security Command Center: SCC は Google Cloud の監視カメラの役割を担っていること、新機能で AI アプリケーション対応を実現していること
セッションの所感
セッションでは、特に生成 AI を利用した攻撃や、生成 AI をターゲットとした攻撃が増加していることが強調されていました。
SCC は以前から Google Cloud のセキュリティ監視の中心的な役割を果たしていましたが、今回の新機能により、AI アプリケーションのセキュリティも強化されていることが印象的でした。
SCC で何ができ、どのように活用できるのかを具体的に理解できたことは、今後のクラウドセキュリティ対策において非常に有益でした。
このセッションレポートを通じて、Google Cloud のセキュリティを知るきっかけになれば幸いです。
Discussion