VPC Service Controls とは ── ネットワーク境界とは別の「API 呼び出しの境界」

本記事では、Google Cloud の VPC Service Controls について解説します。 VPC ファイアウォールや IAM との層の違い、Service Perimeter の構成要素、代表的なユースケース、dry-run を使った段階的な導入手順を順に整理します。 VPC Service Controls の位置付けと設定判断の全体像を把握することで、設計フェーズでの採用可否を判断しましょう。

Google Cloud のセキュリティ層 ── VPC SC が埋める「API の隙間」

Google Cloud のセキュリティは、単一の仕組みで成立しているわけではありません。役割が異なる複数の層が積み重なることで、多層防御の構造を作っています。

ネットワーク防御の 3 層 (エッジ・プライベート境界・マイクロセグメンテーション) は公式ブログ Google Cloud Networking in Depth に詳しい解説があります。これに IAM とデータ保護の層を加えて整理すると、以下のような 4 層構造として捉えられます。

VPC ファイアウォールは VM やコンテナの通信を制御する仕組みです。しかし BigQuery や Cloud Storage のようなマネージドサービスへの API 呼び出しは、VM のネットワーク経路ではなく Google のコントロールプレーンに直接届くため、ファイアウォールルールの対象外になります。

ここに「API の隙間」があります。VPC ファイアウォールがどれだけ厳格に設定されていても、マネージドサービスへの API 呼び出し経路は別軸で制御する必要があります。

IAM との違いも重要です。IAM は「誰が呼べるか」というアイデンティティの制御であり、VPC Service Controls は「どこから呼べるか」というコンテキストの制御です。

公式ドキュメントは「IAM はアイデンティティベースの細粒度制御、VPC SC はコンテキストベースの境界セキュリティ」と説明しており、両方の併用を推奨しています。

公式が示す VPC Service Controls が対象とする脅威モデルは以下の 3 つです。

• 盗まれた認証情報を使った、許可されていないネットワークからのアクセス
• 悪意あるインサイダーや侵害されたコードによるデータ流出
• IAM ポリシーの設定ミスによるプライベートデータの意図しない公開

3 番目が示すように、VPC Service Controls は IAM の設定ミスを最終的に補完する層として設計されています。

VPC SC の構成要素 ── 境界を定義するブロック

VPC Service Controls を理解するには、構成要素をそれぞれ整理しておく必要があります。

Service Perimeter は、同一組織内の複数プロジェクトを 1 つの境界にまとめる単位です。境界の内側にあるプロジェクト間は相互に API を呼び出せますが、境界の外側からのアクセスはデフォルトで拒否されます。

Restricted services は、境界の保護対象として指定するサービスの一覧です。BigQuery・Cloud Storage・Vertex AI・Pub/Sub などが GA サポートの対象として含まれます。サポート対象の全サービスは公式ドキュメントで確認できます。

Access Levels は、境界の外側からのアクセスを許可する条件を定義します。条件の種類は主に 4 つです。

• IP アドレスの範囲
• ユーザー / サービスアカウントの ID
• デバイスの信頼度 (エンドポイント検証)
• Private IP アドレス (Shared VPC 環境向け、内部 IP からの境界外アクセス許可)

Private IP による Access Level は、Shared VPC 環境でサブネットレベルのセグメンテーションを実現します。特定の VPC サブネットからのアクセスのみを境界外からも許可したい場合に活用できます。

Ingress rules / Egress rules は、境界を越える正当な通信を明示的に許可する仕組みです。Ingress rule は「境界の外から内へのアクセスを許可する条件」、Egress rule は「境界の内から外への呼び出しを許可する条件」を、from (送信元の identity / source) と to (送信先のサービス / メソッド) で指定します。

典型例として、Ingress rule では境界外で動く CI/CD のサービスアカウントから境界内 BigQuery への読み取りを許可するパターンが、Egress rule では境界内 Compute Engine から境界外プロジェクトの Cloud Storage バケットへのコピーを許可するパターンが該当します。

Dry-run mode は、境界を実際に enforced にする前に、どの通信がブロックされるかをログで確認できる機能です。useExplicitDryRunSpec: true を設定することで有効になり、ログには metadata.dryRun: True が付与されます。本番適用前の必須ステップとして位置付けられています。

ネットワーク経路の選択にも注意が必要です。restricted.googleapis.com は VPC Service Controls と統合した VIP であり、対応サービスのみですが通信が Google Cloud ネットワーク内に留まります。

これに対し、private.googleapis.com はより広い範囲のサービスに対応しますが、VPC Service Controls との直接統合がなく、データ流出リスクの低減効果は限定的です。マネージドサービスへのアクセスを境界内に収めるには、restricted.googleapis.com を選ぶほうが設計上の整合が取れます。

境界が機能するシーン ── 5 つのユースケース

VPC Service Controls が価値を発揮する代表的な 5 つのシーンを整理します。

(a) マネージドサービスへのデータコピーの防止

境界内の BigQuery テーブルや Cloud Storage バケットに対し、境界外のプロジェクトへのデータコピーを制限できます。bq cp や gsutil cp のような操作が境界を越えようとすると、API 呼び出しがブロックされます。

(b) IAM 誤設定時の被害局所化

roles/owner が誤って付与された場合でも、境界外からの API 呼び出しはブロックされます。クレデンシャルが漏洩しても、攻撃者が許可された Access Level の条件を満たさない限り、境界内のデータには到達できません。

(c) 本番環境と分析環境の分離

「本番 perimeter」と「分析 perimeter」を別々に定義し、Bridge perimeter で制御された共有を実現するパターンです。環境間のデータ移動を一元的に管理できます。

(d) オンプレミス・他社クラウドからのアクセス制御

Access Level には IP アドレス・デバイス信頼・時間帯・地理的位置を組み合わせて条件を設定できます。オンプレミスからは特定の出口 IP からのみ許可、外部 SaaS 連携は特定の時間帯に限定、といった細粒度な制御が可能です。

(e) 規制対応

公式アーキテクチャガイドは PCI DSS 要件 1.3.1 / 1.3.2 (ネットワークセグメンテーション・アクセス制御境界) への対応として、VPC Service Controls を Google Cloud リソース周辺にセキュリティ境界を定義する仕組みとして位置付けています。金融・医療・公共などの規制対応プロジェクトで採用されます。

Commerzbank の事例

ドイツの大手金融機関 Commerzbank (法人向け 26,000 社、個人向け 1,100 万口座) は、BDAA (Big Data and Advanced Analytics) ユニットで VPC Service Controls を 2021 年初頭から運用しています。

同ユニットのリソースの 90% 以上が API 通信であり、従来のファイアウォールではこの 90% がカバーされない状態でした。VPC Service Controls による 3 層データフロー境界 (organization / application / software-stage) を導入することで、API 通信ベースのデータ保護を実現しています。

この事例が示すように、マネージドサービスを中心に構成した Google Cloud 環境では、ファイアウォールだけでは保護できない通信経路が大部分を占めます。

出典: How Commerzbank safeguards its data with VPC Service Controls (Google Cloud Blog)

dry-run から本番適用まで ── 境界を壊さずに導入する手順

VPC Service Controls の導入で最もリスクが高いのは、境界を enforced にした瞬間に予期しない通信がブロックされることです。段階的な適用が不可欠です。

推奨フロー

1. 境界を dry-run mode で作成し、Restricted services を指定する
2. Cloud Audit Logs の VPC Service Controls ログを 1〜2 週間収集し、違反候補の通信を洗い出す
3. 各違反ログの violationReason を確認し、Access Level または Ingress rule の追加で対応する
4. 追加の調整が不要になったタイミングで、境界を enforced に昇格する

代表的なブロックパターン

Cloud Build はテナントプロジェクト (Google 側マネージド) で動作するため、境界内に追加しない限り境界外の扱いになります。

この場合、Cloud Build のサービスアカウントを Access Level または Ingress rule に明示的に追加する必要があります。

BigQuery から Drive / Sheets へのエクスポートは、境界の外に向かう Egress が発生するためブロックされます。

対策として、Egress rule で Drive の API エンドポイントへの通信を許可するか、エクスポート先を境界内の Cloud Storage に変更する設計の見直しが必要です。

管理者の lockout も現実のリスクです。管理者自身が Access Level の条件を満たさない状態で境界を enforced にすると、管理操作まで遮断されます。

対策として、dry-run 期間中に管理者アカウントの Access Level 適用を確認しておく必要があります。

Cloud Shell は、公式が明示的に非サポートとしているため注意が必要です。公式ドキュメントには以下の記載があります。

VPC Service Controls doesn’t support Cloud Shell. VPC Service Controls treats Cloud Shell as outside of service perimeters and denies access to data that VPC Service Controls protects.

出典: Supported products and limitations — Google Cloud Documentation

境界内の作業には Cloud Workstations の利用が推奨されています。

Access Level の identity にグループを直接追加できない点も設定時の制約です。個別のユーザーアカウントまたはサービスアカウントを列挙する必要があります。サービスアカウントへの権限管理をグループ経由で行うか、Workload Identity Federation で external identity を集約するパターンが代替案になります。

violationReason の主要種別

dry-run ログを読み解く際、violationReason のフィールドが設定調整の起点になります。

Violation Analyzer を使うと、UID から特定のリクエストの詳細を追跡できます。ポリシーの内容そのものをログに出力しない設計になっているため、境界の設定情報が漏洩するリスクを避けながらトラブルシュートできます。

Organization Policy・IAM との三層構造 ── VPC SC の立ち位置

「Org Policy を設定したから VPC Service Controls は不要では」という判断は、設計上のリスクになります。この 2 つは役割が明確に異なります。

Organization Policy は「構成の制約」です。特定のサービスを組織内で作成できないようにしたり、リソースの設定値を強制したりする、コンプライアンスコントロールです。

VPC Service Controls は「API 呼び出しの境界」です。サービスが存在することは許可しながら、外部からの不正な API 呼び出しによるデータ流出を防ぎます。

公式ドキュメントはこの違いを以下のように説明しています。

Restricted Service Resource Usage Organization Policy Service alone is not sufficient; you must configure a VPC Service Controls perimeter. VPC Service Controls mitigates data exfiltration paths, and Restricted Service Resource Usage is a compliance control to prevent creating unapproved services inside your environment.

出典: Set up a VPC Service Controls perimeter — Google Cloud Documentation

3 つの仕組みをまとめると、以下のように役割が分離しています。

AWS SCP との比較

AWS の SCP (Service Control Policy) は IAM アクションを組織・OU・アカウント単位で制限する仕組みで、IAM ポリシー評価のフロー内で Allow を上書きする形で機能します。aws:SourceIp のような Condition キーで IP 制限をかけることもできますが、この制限はあくまで IAM 評価ロジックの中の条件式です。

VPC Service Controls は IAM 評価フローの 外側に独立した境界 として動作します。IAM 上で操作が許可されていても、リクエストが境界の Access Level を満たさなければ API 自体が拒否されます。SCP が「縦方向の組織階層で IAM の許可範囲を狭める」のに対し、VPC Service Controls は「横方向に API 通信の外壁を設けて、境界外からの呼び出しをすべて遮断する」設計思想の違いがあります。

VPC Service Controls 自体に追加料金はありません (公式 Pricing で確認できます)。Access Context Manager も追加料金なしで利用できます。

まとめ ── API 境界という第四の層が防ぐもの

Cloud Armor がエッジの攻撃を防ぎ、VPC Firewall が VM 間の通信を制御し、IAM がアイデンティティを検証します。

それでもこれらをすべてくぐり抜けた後、マネージドサービスへの API 呼び出しはまだ手の届く状態に置かれています。

VPC Service Controls はここに最終的な壁を設けます。クレデンシャルが漏洩しても、IAM を誤設定しても、境界外からはデータに触れない。これが「API 呼び出しの境界」という第四の層の役割です。

以下の条件に当てはまる場合、VPC Service Controls の導入を設計フェーズで検討する価値があります。

• BigQuery・Cloud Storage・Vertex AI などマネージドサービスの API を中心にデータ処理をしている
• PCI DSS・FISC・社内セキュリティポリシーなど規制対応が求められる環境がある
• 本番・ステージング・分析などマルチプロジェクト構成でデータの境界分離が必要
• クレデンシャル漏洩や IAM 誤設定を想定した多層防御を設計に組み込みたい

dry-run を使えば既存の通信への影響を把握しながら段階的に適用できます。最初から enforced で設定するのではなく、2 週間程度の dry-run 期間でログを観察し、Access Level と Ingress rule を整えてから本番昇格する流れが現実的です。

参考文献

• VPC Service Controls overview — Google Cloud Documentation
• Service perimeters — Google Cloud Documentation
• Access level design — Google Cloud Documentation
• Ingress and egress rules — Google Cloud Documentation
• Dry-run mode — Google Cloud Documentation
• Supported products and limitations — Google Cloud Documentation
• Troubleshooting VPC Service Controls — Google Cloud Documentation
• VPC Service Controls with Private IPs — Google Cloud Documentation
• VPC Service Controls pricing — Google Cloud
• Google Cloud networking in depth: Three defense in depth principles for securing your environment (Google Cloud Blog)
• How Commerzbank safeguards its data with VPC Service Controls (Google Cloud Blog)
• Announcing VPC Service Controls with Private IPs (Google Cloud Blog)
• PCI DSS compliance in Google Cloud — Architecture Guide

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile