生成AI導入プロジェクトにおいて、PoC（概念実証）から本番環境へ移行するフェーズで、セキュリティチームから「待った」がかかる瞬間は少なくありません。特に金融や医療、製造業といった機密情報を扱う環境において、懸念の中心となるのは「学習データや推論データの持ち出し（Data Exfiltration）」です。
「IAM（Identity and Access Management）で権限管理は厳格にしています」
現場のエンジニアからよく挙がる声です。確かにIAMは不可欠な要素です。しかし、もし正規の認証情報を持ったユーザーが悪意を持ったらどうなるでしょうか。あるいは、認証情報そのものが流出したらどう防ぐべきでしょうか。IAMだけでは、正規の権限を使った「不正な場所へのデータコピー」を防ぐことは非常に困難です。
今回は、Google Cloud環境、特にVertex AIにおける「最後の砦」とも言えるVPC Service Controls（VPC SC）について解説します。公式ドキュメントは難解な部分もありますが、設計思想を体系的に理解すれば、これほど強力なセキュリティ機能はありません。実務の現場で求められる「誤遮断を起こさないための実践知」を交えながら、論理的かつ分かりやすく紐解いていきます。
なぜIAMだけではVertex AIを守れないのか
まずは、なぜ従来のアクセス制御だけでは不十分なのか、その背景にある脅威を整理します。多くの組織がIAMによる「人（ID）」の管理に注力していますが、AIプロジェクトを安全に推進するためには「データの流れ」そのものを制御する視点が不可欠です。
認証・認可とネットワーク境界の違い
IAMは基本的に「誰が（Who）」リソースにアクセスできるかを制御する仕組みです。例えば、「特定のデータサイエンティストが、特定のBigQueryデータセットを閲覧できる」という許可を与えます。
しかし、IAMは「どこから（Where）」や「どこへ（To Where）」というネットワーク的な制約を強制力を持ってコントロールすることには限界があります。インターネット経由でAPIにアクセスできるGoogle Cloudの特性上、権限さえあれば、世界中のどこからでもデータにアクセスできてしまうリスクが残ります。
データ持ち出し（Data Exfiltration）の具体的脅威シナリオ
IAMだけでは防げない、具体的な2つのシナリオを見てみましょう。
侵害された認証情報の悪用
攻撃者がフィッシングなどで開発者のGoogleアカウント（IDとパスワード）を入手したと仮定します。この開発者が強い権限を持っていれば、攻撃者は外部のPCからgcloudコマンドなどを利用し、機密データや学習済みモデルをローカル環境や、攻撃者が管理する外部のクラウドストレージへコピーできます。IAM上は「正規のユーザーによる操作」に見えるため、遮断されません。悪意あるインサイダーによる持ち出し
退職予定の社員が、AIモデルの学習データを持ち出そうとしたと仮定します。会社のPCから、個人のGmailアカウントで作成したGoogle Cloudプロジェクトのストレージへデータをコピーしようとするケースです。IAMで「データの読み取り」は許可されているため、コピー先が社外のプロジェクトであっても、標準のIAM設定ではこれを防げないことが一般的です。
VPC Service Controls (VPC SC) が解決する課題
ここで登場するのがVPC Service Controlsです。これは、Google Cloudのリソース（BigQuery, Cloud Storage, Vertex AIなど）の周りに「論理的な境界（Service Perimeter）」を作る機能です。
IAMが「入館証」だとしたら、VPC SCは「建物の壁とゲート」とイメージしてください。いくら入館証（IAM権限）を持っていても、壁（境界）の外からはデータに触れませんし、逆に建物内のデータを壁の外へ持ち出すこともできません。
VPC SCを適用することで、以下のことが可能になります。
- 境界外からのアクセスを遮断: 許可されたネットワーク（VPC）以外からのAPIアクセスを拒否。
- 境界外へのデータコピーを防止: 信頼されたプロジェクトから、外部の（個人の）プロジェクトへのデータ転送をブロック。
Vertex AIのように大量のデータを扱う基盤では、Agent Builderや最新のGeminiモデルを活用して高度な処理を行う場合でも、この「データの出口対策」こそが本質的なセキュリティ対策となります。
VPC SC適用の基本原則：境界をどこに引くべきか
VPC SCを導入する際、最初に直面する課題が「どこに線を引くか」です。不適切な境界設計はシステムの稼働停止を招きます。ここでは、Vertex AI環境における境界設計の原則を解説します。
原則1：データとコンピュートリソースの同一境界化
最も基本的な原則は、「データ（Storage/DB）」と「それを使う計算リソース（Compute）」を同じ境界の中に入れることです。特に生成AI活用が進む現在、守るべきリソースの関係性はより密接になっています。
Vertex AIを中心とした開発では、以下のリソースが頻繁に連携します。
- Vertex AI Workbench: データサイエンティストがコードを書くノートブック環境
- Cloud Storage (GCS): 学習データ、モデルアーティファクト、非構造化ドキュメントの保存先
- BigQuery: 構造化データの保存先
- Vertex AI Training / Prediction: 学習ジョブや、Geminiの最新モデルなどを含む推論エンドポイント
- Vertex AI Agent Builder: 検索や会話アプリケーションを構築する際、GCSやBigQuery内のデータを参照するエージェント機能
特に最近では、Vertex AI Agent Builderを使用してRAG（検索拡張生成）システムを構築するケースが増えています。エージェントが社内データ（GCS上のPDFやBigQueryのテーブル）にアクセスする際、これらが別々の境界に分かれていると、通信のたびに複雑な許可設定が必要になり、運用が破綻しやすくなります。
また、Gemini Live APIのような最新のリアルタイムマルチモーダル機能を利用する場合でも、そのバックエンドとなるデータソースやアプリケーション基盤は、可能な限り一つの境界（Perimeter）で囲い込むのが定石です。
原則2：最小権限のネットワークアクセス（Private Google Access）
境界を作ったら、その中での通信はインターネットを経由させないようにします。VPCネットワークの設定で「限定公開のGoogleアクセス（Private Google Access）」を有効にします。
これにより、VPC内のVM（Workbenchのインスタンスなど）は、外部IPアドレスを持たなくてもGoogleのAPI（Vertex AI、GCS、Gemini APIなど）にプライベートIP経由でアクセスできるようになります。データがインターネットという公道に出ることなく、Googleのバックボーンネットワーク内だけで完結するため、盗聴や中間者攻撃のリスクも極小化できます。
原則3：境界ブリッジの慎重な利用
システム規模が大きくなると、「データ分析基盤の境界」と「AI開発基盤の境界」を分けたいという要望が出ることがあります。異なる境界間で通信させるために使うのが「境界ブリッジ（Perimeter Bridge）」です。
しかし、ブリッジはあくまで例外的な措置と考えるべきです。ブリッジを安易に増やすと、結局すべての境界が繋がってしまい、「巨大な一つの境界」と同じ状態になりかねません。これを「境界の形骸化」と呼びます。まずはプロジェクト設計を見直し、可能な限り一つの境界内で完結させるか、本当に必要なデータだけを明示的に共有する設計を心がけることが重要です。
実践ベストプラクティス①：コンテキストアウェアアクセスの統合
境界を作っただけでは、「壁」ができた状態に過ぎません。次は「ゲート（入り口）」の統制を強化します。ここで活用するのがAccess Context Managerによる「コンテキストアウェアアクセス」です。
Vertex AI Studioでのプロンプト共有機能や、Agent Builderによるエージェント開発が急速に進展する中、データへのアクセス元を厳密に統制することは、情報漏洩対策の要となります。
IPアドレスやデバイス状態に基づくアクセス制御
単に「IAM権限があるから通す」のではなく、アクセス元の「コンテキスト（状況）」を見て判断させます。
- IPアドレス制限: 社内のVPNゲートウェイやオフィスの固定IPからのアクセスのみを許可する。
- デバイスポリシー: 組織が管理し、最新のOSパッチが適用され、画面ロック設定がされている端末（Chromeブラウザのステータスなどで判定）からのアクセスのみを許可する。
これをVPC SCの「アクセスレベル（Access Level）」として定義し、境界に適用します。これにより、「正規のIDだが、自宅の私物PCからアクセスしている」という状況をブロックできます。
Access Context Managerの設定パターン
Vertex AI Workbenchや、最新のVertex AI Agent Builderを利用する開発環境においては、以下のようなアクセスレベル設定が推奨されます。
- 基本レベル: 社内ネットワーク（IP範囲指定）からのアクセスのみ許可。
- 高セキュリティレベル: 上記に加え、組織支給のデバイス（証明書インストール済み）であることを必須とする。
特に、Geminiの最新モデルを活用した本番環境へのデプロイや、機密性の高いプロンプトを扱うVertex AI Studioの操作には高セキュリティレベルを要求し、単なるドキュメント閲覧などは基本レベルで許可するなど、業務のリスクに応じた柔軟な制御が可能です。アプリケーション層の統制とネットワーク層の制御を組み合わせることで、強固な多層防御を実現できます。
開発者体験とセキュリティの両立
セキュリティを厳格にしすぎると、開発者の生産性が低下し、プロジェクトのROIに悪影響を及ぼす可能性があります。例えば、リモートワーク時にVPNの接続状況が悪く作業ができない、といった事態は避けなければなりません。
Access Context Managerの利点は、条件を論理式（AND/OR）で柔軟に構成できる点です。「社内IPからのアクセス」OR「承認されたデバイスかつ多要素認証済み」であれば許可する、といった設定にすることで、セキュリティ強度を保ちつつ、現代の柔軟な働き方をサポートする環境が構築できます。
実践ベストプラクティス②：ドライランモードによる影響分析
VPC Service Controls (VPC-SC) の導入において最も警戒すべきは、「設定を適用した瞬間に、本番システムや開発環境が停止すること」です。
特にVertex AIの活用シーンでは、データ持ち出しを確実に防ぐためにPrivate Service Connect (PSC) を組み合わせた閉域網構成をとるケースが推奨されています。このように構成が高度化し、VPC内プライベートエンドポイント経由の通信が増えるほど、意図しない通信遮断（誤遮断）のリスクも高まります。
これを回避するための重要な機能が「ドライランモード（Dry Run Mode）」です。
いきなり適用（Enforce）することのリスク
VPC-SCには、設定を即座に強制する「適用モード（Enforce）」と、実際には遮断せず違反ログだけを出力する「ドライランモード」があります。
Google CloudのAPI依存関係は非常に複雑です。例えば、Vertex AIのコンソール画面を表示するだけでも、バックグラウンドではCloud LoggingやCloud Monitoring、さらにはCloud BuildなどのAPIが連鎖的に呼び出されます。
また、重要な点として、IAMはアクセス権限を制御しますが、認証されたユーザーによる外部へのデータエクスポート（持ち出し）までは防げません。VPC-SCはこの「持ち出し」を防ぐための境界防御ですが、設定を誤れば正当なデータパイプラインやAPI連携まで遮断してしまいます。
プロジェクトマネジメントの観点からも、最初から適用モードにすることは絶対に避けるべきです。
拒否ログの分析プロセス
まずはドライランモードで設定を投入し、少なくとも1〜2週間程度は運用します。その間、Cloud Loggingに蓄積される「ドライランでの拒否ログ」を分析し、システムへの影響を可視化します。
特にVertex AI Agent BuilderやVector Searchを利用する場合、PSC経由のトラフィックが正しくペリメータ内で処理されているかを確認する必要があります。
ログのフィルタリング例：logName="projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Fpolicy"jsonPayload.serviceControlCheckResult.violationReason="NO_MATCHING_BRIDGE"
このログを分析する際は、以下の視点を持つことが重要です：
- 誤遮断の特定: 業務に必要なAPIコールがブロックされていないか。（例：CI/CDパイプラインからのデプロイや、オンプレミスからのVPN経由アクセス）
- IAMとのギャップ確認: 「IAMでは許可されているが、VPC-SCでブロックされた通信」の中に、意図的に防ぐべきデータ持ち出し（例：ローカルPCへのデータダウンロードや外部バケットへのコピー）が含まれていないか。
- PSC接続の確認: プライベートエンドポイント経由の通信が、境界内部の通信として正しく認識されているか。
段階的な移行戦略
安全に本番適用するためのステップは以下の通りです。
- ドライラン設定: まずは理想の構成（Vertex AIとCloud Storageを保護リソースに指定など）をドライランで適用します。
- ログ分析とチューニング: エラーログを確認し、必要な通信許可（Ingress/Egressルール）や、アクセスレベルの調整を行います。
- エラー消滅の確認: 業務サイクルが一巡（月次バッチなども含む）し、予期せぬ拒否ログが出ないことを確認します。
- 本番適用（Enforce）: ここで初めて適用モードに切り替えます。
このプロセスを経ることで、IAMだけでは防げないデータ流出リスクに対処しつつ、システム停止のリスクを最小限に抑えることができます。
避けるべき3つのアンチパターン
実務の現場でよく見られる失敗パターンを紹介します。これらはセキュリティ強度を下げるだけでなく、後の運用を困難にします。
過度に広範な境界設定（Monolithic Perimeter）
「管理を簡略化するために全プロジェクトを一つの境界に入れてしまう」という考え方です。確かに通信エラーは起きにくくなりますが、境界内部での攻撃（ラテラルムーブメント）に対して無防備になります。また、関係ないプロジェクトの変更が全体に波及するため、影響範囲の見極めが困難になります。
対策: データの機密性レベルや、組織（部署）単位で境界を分割し、必要な通信だけをブリッジや明示的な許可ルールで繋ぐ設計にすることが推奨されます。
パブリックIPを持つインスタンスの放置
VPC SCを設定しても、VMインスタンスにパブリックIP（外部IP）が付与されていると、そこが抜け穴になるリスクがあります。ファイアウォール設定ミスなどで、インターネットから直接アクセスされる可能性があるからです。
対策: 組織のポリシー（Organization Policy）で「外部IPアドレスの付与を禁止」する設定を強制します。外部との通信が必要な場合は、Cloud NATを利用して、出口を一箇所に絞ります。
トラブルシュート時の安易な境界解除
開発中にエラーが出た際、「原因切り分けのために一旦VPC SCを無効化しよう」として、そのまま戻し忘れるケースです。あるいは、特定のエラーを解消するために、アクセスレベルを「全てのIPを許可（0.0.0.0/0）」にしてしまうなどの場当たり的な対応です。
対策: トラブルシュート時もドライランモードを活用するか、特定のテスト用サービスアカウントのみを一時的に許可するなど、影響範囲を限定した対応を徹底する運用ルールが必要です。
組織の成熟度別導入ロードマップ
VPC SCは強力ですが、導入にはリソースが必要です。組織のフェーズに合わせて段階的に導入することで、プロジェクトの確実性を高めることができます。
Level 1: 重要なデータセットの保護から開始
まずは全社適用を目指さず、「最も守るべき機密データ」を扱うプロジェクト単体で導入します。例えば、顧客のPII（個人識別情報）を含むBigQueryのデータセットがあるプロジェクトだけを境界で囲います。利用者は限定されるため、調整コストも低く、ノウハウを蓄積できます。
Level 2: Vertex AIパイプライン全体への適用
次に、MLOpsパイプライン全体を保護範囲に広げます。データの取り込みから、学習（Training）、モデル管理（Model Registry）、推論（Serving）までの一連の流れを境界内に入れます。ここでは、Vertex AI PipelinesやCloud Buildなどが境界内で正しく動くよう、詳細な通信制御が必要になります。
Level 3: 自動化された境界管理（IaC化）
最終的には、TerraformなどのIaC（Infrastructure as Code）ツールを用いて、VPC SCの設定をコード管理します。新しいプロジェクトが作成されたら、自動的に適切な境界に追加される仕組みを作ります。
特筆すべき点として、Terraformの最新バージョンやOpenTofuなどの互換ツールでは、セキュリティと運用効率を高める機能が強化されています。
- 機密情報の保護（エフェメラル値など）: 最新のIaCプラクティスでは、アクセストークンなどの機密情報をStateファイルやプラン出力に残さない機能（Ephemeral valuesなど）が利用可能になりつつあります。これにより、IaC自体のセキュリティリスクを低減できます。
- テストフレームワークの活用: 設定コードに対するテスト機能が強化されており、本番適用前にポリシーの整合性を自動検証するフローを組み込むことが容易になっています。
コード管理することで、設定変更のレビューが可能になり、「誰がいつ何のために穴を開けたか」が追跡できるようになります。これができて初めて、持続可能なセキュリティ運用と言えるでしょう。
まとめ
Vertex AIにおけるデータ保護は、IAMという「点」の防御だけでなく、VPC Service Controlsという「面」の防御を組み合わせることで完成します。
- IAMは不正アクセスを防ぐが、持ち出しは防げない
- VPC SCで論理的な境界線を引き、データの出口を塞ぐ
- ドライランモードを活用し、業務を止めずに安全に導入する
セキュリティ対策は、事故が起きてからでは遅すぎます。しかし、過度な対策でビジネススピードを損なうことも避けるべきです。今回解説した「ドライランからの段階的導入」は、そのジレンマを解消し、ROIを最大化するための現実的なアプローチです。
「自社のVertex AI環境にVPC SCを適用したいが、依存関係が複雑すぎて設計できない」「ドライランのログ分析が難しい」といった課題に直面することは珍しくありません。そのような場合は、組織内のセキュリティアーキテクトや外部の専門家と連携し、ビジネスを止めない最適なセキュリティ設計を慎重に進めていくことが推奨されます。
まずは、組織の最も重要なデータが「今、どこからアクセス可能か」を論理的に確認することから始めてみてはいかがでしょうか。
コメント