【Google Cloud Next Tokyo 26】VPC Service Controlsを正しく理解する 〜IAM・VPC Firewallとの守備範囲の違い〜

はじめに

Google Cloud Next Tokyo 26のDeveloper Stageセッション「使いこなそう！VPC Service Controls」（D1-DEV-08）のセッションレポートをお届けします。
Google Cloud上の機密データを守る方法として、まずIAMで権限を絞ることが思い浮かびます。ただ、特定の拠点からだけアクセスさせたい、本番環境から開発環境へデータを持ち出させたくない、といった要件はIAMだけでは表現できません。本セッションは、その隙間を埋めるVPC Service Controls（以下、VPC SC）を概観する内容でした。

セッション概要

冒頭では、AIエージェントを使い始めると人やプログラムよりも自律的にものが動くため、想定外のデータ漏洩が起きやすくなる、という前置きがありました。AIエージェントの時代だからこそデータ保護を考える必要があり、そのうえで役に立つサービスがVPC SCだという立ち上がりです。機能紹介ではなく「なぜいま境界が必要なのか」から入る構成でした。

1. IAMとVPC Firewallだけでは守れない領域

最初に示されたのは、IAMだけの制限では次のような穴が残るという整理です。

• 許可された人やサービスアカウントが、許可していない場所とデータを授受できる
• 外部サービス側で権限を付与するだけで、データが持ち出せてしまう

一方のVPC Firewallは、あくまでVPC内のネットワーク通信を守るものです。Cloud StorageやBigQueryのようにGoogle APIを利用するマネージドサービスへのアクセスはVPCの外側にあるため、VPC Firewallでは制御できない箇所が残ります。

IAMは「誰がアクセスできるか」しか見ていないので、「どこからアクセスされるか」「どこへデータが出ていくか」まで制御したくなる。そこでIAMやVPC Firewallとは別のレイヤーでGoogle APIのデータアクセスを守る仕組みが必要になる、という流れでVPC SCが登場します。機密データを含むデータストアは、IAMの権限制御だけでなくデータの経路も防御する多層防御が重要になる、という整理でした。

2. VPC Service Controlsとは

VPC SCは、Google Cloud上にサービス境界を作成し、許可されていないデータへのアクセスや持ち出しを防ぐ仕組みです。スライドでは「Google API向けのファイアウォールのようなもの」と表現されていました。

動きはシンプルで、守りたいプロジェクトやVPCをサービス境界の中に入れると、境界をまたぐアクセスや境界外へのAPIアクセスは原則として拒否されます。逆に境界内の通信や、ルールとして許可したAPIアクセスは通ります。図では境界内のProject-A・Project-Bに加えて、境界外のProject-C、組織外のProject-Dが並べられ、社外の未許可拠点からのアクセスと、境界外プロジェクトのCloud Storageへのコピーがいずれも拒否される様子が示されていました。

3. VPC SCを構成する6つの要素

続いて、構成要素が6つに分けて解説されました。

① アクセスポリシー

アクセスレベルやサービス境界などのリソースをまとめる箱にあたるものです。組織全体に対するもののほか、フォルダやプロジェクトに限定したScoped Policyも利用でき、権限を分離した管理ができます。VPC SCの設定権限を特定のフォルダだけ委譲したい場合に使う形です。
なお、スライドには「VPC SCの利用には組織が必須となる」と注記されていました。組織を作らずにプロジェクト単体で使っている環境では、そもそも前提を満たしていないことになります。

② サービス境界

VPC SCで保護するプロジェクトもしくはVPCを指定し、保護したいGoogle APIを制限付きサービスとして設定します。
ここで重要なポイントとして挙げられていたのがドライランモードです。すでに動いている環境へ後から設定を入れる場合や大きな変更を加える場合、いきなり適用すると疎通できなくなる影響が出てしまうことがあります。ドライランではエラーログのみが出力され、実際にはトラフィックが拒否されないため、まず影響を確認し、拒否される可能性がある通信が想定どおりかを見てから本適用するのがおすすめとのことでした。

③ アクセスレベル

サービス境界へのアクセスを許可するID・IPアドレス・デバイス情報を設定するものです。社内拠点のIPレンジを条件にする、といった使い方になります。スライドの設定画面では、許可するIPアドレスと許可するVPCを指定する項目が写っていました。

デバイス属性を利用したアクセス制限を行うにはChrome Enterprise Premium（有償）が必要、という注記もありました。IPだけでなく端末の状態まで条件に入れたい場合は、追加のライセンスが前提になるようです。

④⑤ Ingressルール／Egressルール

サービス境界の内外のアクセス許可を設定するものです。Ingressは境界の外から中へ、Egressは境界の中から外へのアクセスを許可します。アクセスレベルよりもきめ細かく、APIやメソッド単位（GETだけ許可する、など）で条件を設定できます。

⑥ 境界ブリッジ

サービス境界間の通信を許可できる仕組みですが、境界間の通信が全許可されてしまうため、Ingress／Egressルールでの代替を推奨するという位置づけでした。登壇者からも「個人的にはおすすめ」という形で、境界間であってもIngress／Egressで書いたほうが意図しない許可が減る、と補足されていました。

4. Google API側の設定も必要になる

VPC SCの設定だけでは完結せず、Google API側の設定も追加で必要になります。Private Google Accessにはprivate.googleapis.comとrestricted.googleapis.comの2種類があり、インターネットを介さずにGoogle APIへアクセスできます。このうちrestricted.googleapis.com側を利用することで、VPC SCがサポートしているAPIとサービスのみに制限できる、という関係です。

実現方法としては、Cloud DNSで限定公開ゾーンを作成し、Google APIへのアクセスをRestricted Google APIに向ける手順が紹介されました。スライドの設定例では*.googleapis.comのCNAMEをrestricted.googleapis.comに向けつつ、accesscontextmanager.googleapis.comだけはprivate.googleapis.comに向けており、「VPC SCに対応していないAPIはPrivate Google APIを向けている（VPC SC保護対象外）」という注記が添えられていました。全部を一律にrestrictedへ向ければ済むわけではない、という実装上の勘所が写っていた1枚です。

5. ユースケース

BigQueryのデータだけを守りたい場合

機密性の高いデータを持つBigQueryのプロジェクトをサービス境界に入れ、制限付きサービスとしてBigQueryを選択する、という粒度の例です。この設定で次のように整理されていました。

そのうえで、データ連携が必要なところだけIngress／Egressルールで許可します。Ingressルールにはアクセスを許可したい端末のIPアドレスや許可するIDを設定し、Egressルールには境界外プロジェクトのデータをBigQueryのジョブから参照したい場合にサービスアカウントIDなどを指定する、という使い分けでした。ここで大事なのは、何を許可するかを最小限に設計することだと強調されていました。

本番環境をまとめて守りたい場合

もう1つ、本番環境全体を境界に入れて守る使い方も紹介されていました。本番環境から開発環境へのデータ持ち出しを止めたい一方で、開発環境で使うコンテナイメージのpull（Artifact Registryなど）は通したい、といった要件があります。この場合も、必要な通信だけをIngress／Egressルールで開けていく形になります。

守る単位をサービスで絞るか環境で括るかという2つの入り口が並べられていて、いずれも「まず境界を引き、必要な例外だけをルールで開ける」という手順は共通していました。

6. 導入前に確認しておきたいこと

サポートされているAPIを確認する

多くのサービスがサポートされているものの、サポートされていないサービスや制限事項を確認したうえで利用するように、という注意点が挙げられていました。確認方法は次の2つです。

• 公式ドキュメントの「サポートされているプロダクトと制限事項」（https://docs.cloud.google.com/vpc-service-controls/docs/supported-products?hl=ja）を見る
• gcloud access-context-manager supported-services listコマンドで確認する

さらに、VPC SCを入れることが要件のシステムでは、VPC SCに対応していることをサービス選定基準の1つにする、という踏み込んだ提案もありました。スライドにはBigQueryの記載例が写っており、サービス名としてbigquery.googleapis.comだけでなくbigquerystorage・bigqueryreservation・bigqueryconnectionが並び、制限事項も個別に列挙されていました。サービス単位で「対応済み」と見えても、関連APIごとに保護の範囲と制限が違うことが分かります。

公開用・非公開用データを混在させない

最後の注意点は、1つのプロジェクト内に公開用データと非公開データのデータストアを混在させると、VPC SCでの統制がとれなくなるという指摘でした。

例として示されていたのはCloud Storageです。1つのプロジェクトにWebサイトの静的コンテンツ（公開）を置いたバケット1と、機微情報（非公開）を置いたバケット2がある構成では、静的コンテンツを公開できるようにルールを設定すると機微情報を守れなくなります。解決策は2つ提示されていました。

印象に残ったポイント

守るレイヤーが1つ増える話

IAMは「誰が」、VPC Firewallは「VPCの中のネットワーク通信」を見ています。VPC SCが担うのは、そのどちらにも入らないGoogle APIへのアクセス経路でした。3つは択一ではなく組み合わせて多層で守るものだという整理が、セッション全体の軸になっていたのが印象的でした。IAMを絞ったから安心、という認識のままだと守備範囲を取り違えることになりそうです。

便利な設定ほど境界が広がる

境界ブリッジよりIngress／Egressルールを推奨する、という話が象徴的でした。ブリッジは境界間をまとめてつなげるぶん楽ですが、許可範囲が広くなり意図しない許可が生まれます。何を許可するかを最小限に設計する、という指針とセットで語られていた点に納得感がありました。

プロジェクト設計がそのまま統制の可否になる

公開用と非公開用のデータを同じプロジェクトに置くと制御が難しくなる、という最後の注意点は、境界がプロジェクト単位の構造物であることの裏返しだと感じました。リソースをどこに置くかという設計判断が、後から引ける境界の形を決めてしまいます。解決策として提示されていたのがどちらもプロジェクト分割か公開方式の変更で、ルールの書き方では解決していない点も示唆的でした。

ドライランは影響確認の手前に置かれていた

VPC SCは通信を拒否する仕組みなので、入れ方を誤ると疎通が止まる側の要因になります。構成要素の説明のなかでドライランモードが「重要なポイント」として先に置かれていたのは、その裏返しだと感じました。境界を引く作業と影響を確認する作業をセットで扱う前提になっていて、稼働中の環境に後入れする際の順序として参考になりました。

さいごに

まとめとして、VPC SCを使うことでGoogle Cloudのデータを境界で守れる、IAMやVPC Firewallだけでなく、Google APIがどこからアクセスされ、どこへデータが出ていくかを制御することでデータ流出リスクを下げられる、という2点が示されました。そして使いこなすためのポイントとして、守るデータと境界を決めること（公開データと機密データを同じ設計に混ぜない）、いきなり設定せずdry runで影響を見ること（ログで確認してから適用する）の2つが挙げられていました。

VPC SCの位置づけ・構成要素・ユースケース・導入前の注意点まで通して押さえられる内容でした。個人的には、AIエージェントのように自律的に動く主体が増えるほど、権限を絞るだけでは想定外の持ち出しを止めきれないという冒頭の問題設定が残りました。認証情報や権限が正しくても、境界の外へ出ていく経路を塞いでおくかどうかは別の設計判断になります。

一方で、既存環境に後から境界を引く場合は、誰も把握していなかった通信が出てくることが避けられません。ドライランは影響確認の手段として紹介されていましたが、暗黙の依存関係を棚卸しするための道具としても効きそうだと感じました。本記事がVPC SCの導入を検討している方の設計の一助となれば幸いです