こんにちは。SCSKの松渕です。
今回は、Google CloudでVPC SC(VPC Service Controls)の設定をしたいと思います。
概念だけは知っていましたが、実際に設定するのは初めてでした。
はじめに
VPC Service Controlsとは
VPC SC(VPC Service Controls)とは、Google Cloud リソースの周囲に論理的な境界を確立し、APIレベルでアクセスを制御する高度なセキュリティサービスです。IAMと組み合わせて二重の防御を構築することで、盗まれた認証情報や設定ミスによるデータ流出のリスクを大幅に低減します。
IAMとの併用を推奨や、VPC SCの目的がデータ流出防止である点はGoogle公式ドキュメントにて明記されてます。
VPC Service Controls の概要(Google Cloud ドキュメント)
理解しにくい人のために
要するに、Google Cloud APIの呼び出しを制御するサービスとシンプルに捉えることができますが、私は最初は理解に時間がかかりました。
個人的にVPC SCの理解が難しかった大きな理由が、AWSに同様の機能がないことが挙げられます。サービス単位でいえばS3バケットポリシーとかが近い気がしますが、サービス単位ではなくGoogleCloud全体にまたがるものです。
また、“VPC”と名前につくが、いわゆるネットワークレイヤ（L3,L4）ではない点も混乱する原因かと思っております。
“VPCとは別物だ”と理解したほうが個人的にはしっくりきました。
IAMに近いサービスで、データ漏洩に重点を置いてIAMとで二重の境界線を設定するサービスというイメージで理解しております。
IAM制御との違いと今回の目的
今回は、Google Cloudを利用する際に特定のIPからのアクセス制限を実装するために利用します。
上記サービス説明である通り、似た目的でIAMでの制御でも実装可能な側面もあります。
今回IAMではなくVPC SCを利用した意図としては、権限制御よりデータ漏洩防止に主眼を置いているため、
VPC SCのほうが適していると判断したためです。
| 特徴 | 👤 IAM (Identity and Access Management) | 🛡️ VPC Service Controls (VPC SC) |
| 主眼（目的） | 権限制御とアクセス制御 | データ漏洩防止 |
| 制御の焦点 | 誰が (Who)、何の操作を実行できるか。 | データがどこへ (Where)、どのように移動できるか。 |
| 制御レイヤー | 認証・認可レイヤー（リソースへのアクセスを制御）。 | APIレイヤー（Google Cloud API呼び出しを制御）。 |
| 制御方法 | ユーザー/サービスアカウントにロールを付与し、操作の許可/拒否を定義。 | サービスの周囲に境界を設定し、境界をまたぐAPIリクエストを強制的にブロック。 |
| セキュリティの役割 | 第一の防御線：最小権限の原則を適用する。 | 最後の防御線：IAM設定ミスや認証情報盗難時のデータ流出を阻止する。 |
事前準備
前提条件
VPC SCにせよIAMにせよ、IPアドレスでアクセス制限するにはAccess Context Managerを利用します。
前提として、プロジェクト単体では利用できないため、組織へ所属する必要があります。
実装したい制御方法（要件）の整理
どんな制御したいのか？をイメージしましょう。いかに、基本的なポイントを箇条書きします。
- 制御対象のGoogle Cloudサービス（どのAPIを境界内に入れるか）を検討します。
VPC SCの基本は、保護したいGoogle Cloud プロジェクトを丸ごとサービス境界に含めることです。すべて含めて不都合がなければ基本的にはすべて含めることをお勧めします。 - IPアドレスに加え、アクセス元のデバイスポリシー（暗号化状況など）や特定のリージョン/国といった、より詳細なコンテキストでの制限も可能です。
- 「このユーザはこのIPアドレスから」といったユーザ/グループ といった単位での制御も可能です。
ただし、グループ制御の場合はGoogle Workspace側でグループ作成が必要になります。
default policyの確認
組織のポリシー確認
「セキュリティ」の左カラムから、「ゼロトラスト」の中の「VPC Service Controls」を押下します。
以下のような画面が出たら、プロジェクトが選択されている状態です。
VPC SCの設定は組織が前提になります。「組織スコープに切り替え」を押下して、所属組織を選択します。
同一スコープのポリシーは1つだけ
私がはまった箇所です。
デフォルト状態であれば、以下のように“default policy”というのが選択されている状態になるかと思います。
初期で作成されているポリシーで、組織全体をスコープにしています。境界の設定は入っていないものになります。
「ポリシーを管理」を押下して、中身を確認します。
「組織レベルのポリシーの範囲外」と表記されていれば、組織全体をスコープとしていることを示しており、想定通りです。
今後、この“defaut_policy”を利用します。
同一スコープ（組織全体）での複数ポリシーの作成は不可能です。
defaultポリシー使うのが気持ち悪かったので、組織全体スコープにしたポリシーを別途作成しようとしたのですがうまくいかず。
原因をGeminiに聞いたら上記回答でした。
Access Context Managerの作成
Access Context Managerの作成
境界の設定の前に、境界設定に必要となるAccess Context Manager（ACM）を作成します。
「セキュリティ」の左カラムから、「ゼロトラスト」の中の「Access Context Manager」を押下します。
※プロジェクトではなく、組織を選択した状態で操作します
「アクセスレベルを作成」を押下します。
アクセスレベルを作成します。
ここでの設定は、制御までは設定せずに「どういうアクセス条件を識別するか」のみを設定します。
IP制限を目的としているので、特定IPアドレスからのアクセスであることを識別するようにします。（Trueで返すように設定します）
入力したら「保存」を押下。
なお、デバイスポリシーの設定はChrome Enterprise Premiumが必要になります。
また、GUI以上の細かな制御も詳細設定というもので可能とのことですが、
こちらもChrome Enterprise Premiumが必要。
ACMの一覧画面に戻ります。作成されたことを確認します。
境界の作成
ドライランモードでの作成
VPC SCの画面に戻ります。
「セキュリティ」の左カラムから、「ゼロトラスト」の中の「VPC Service Controls」を押下します。
default policyを選択している状態で、「+新しい境界」を押下します。
サービス境界の作成画面に遷移します。
「テストを実行」を選択して、「続行」を押下します。
境界外からのアクセスがあった際、アクセス拒否はさせないが、監査ログ上でをエラーとして出力するモードです。
設定を入れる前に影響調査のために利用されます。
今回は検証のため、いきなり適用も可能でしたが、ドライランの挙動を確認するためにこのモードを選択しました。
次の画面では、制限する対象プロジェクトを選び、続行を押下します。
次の画面では、制限する対象プロジェクトを選び、続行を押下します。
基本的な考えとしては可能な限り多くのサービスを設定したほうがデータ漏洩リスクは低くなります。
しかし、設定した際の影響も考慮した現実的な検討を行いましょう。
BigQuery、Cloud Storage、Cloud SQL等のリスクが高いサービスから優先的に検討/実装を行うのが現実的です。
VPCネットワーク内部からPrivate Google Accessを利用してGoogle API にアクセスする際の
アクセス先（出口）を制限する設定です。
そのまま続行を押下。
次の画面では、前章で作成したアクセスレベルを追加して、続行を押下します。
特定ユーザのみ等、詳細設定したい場合は次の「上りポリシー」等で設定しましょう。
上りポリシーと下りポリシーの設定画面に移動します。
ここでは、「アクセスレベル」の画面での設定を上書きする例外設定が可能です。
特定ユーザのみは許可を行ったり、特定サービスについては条件緩める等の設定です。
今回は例外はないためそのまま作成します。
ドライランモードでのログ確認
ドライランモードでの作成が完了したら、VPC SCの画面に移動します。
ログでの動作確認のため、右上にある「監査ログ」を押下します。
Cloud Loggingの画面に遷移します。
境界外からのアクセスが確認できるクエリがあらかじめ設定されています！とても便利・・・！
ただ、いくつか設定してあげないといけなかったです。
組織が選択されていると思いますので、「プロジェクト」を選択します。ログ表示の期間を適切に修正します。
そうすることで、画面下部に境界外からのアクセスが確認できました。
今回、私が意図的に境界外からアクセスしていたものをしっかり検知できていました。
ちゃんと動いていそうです。
境界の適用
適用して大丈夫だと判断できたら、ドライランから適用します。
VPC SCの画面から、「ドライランモード」を選択し、適用したい境界を押下します
画面右上の「構成を適用」を押下。
確認画面が出ますので、それもＯＫを押下。
「自動適用モード」に移動すると、境界が表示されており、適用プロジェクト数が選択したプロジェクト数になっています。
これで、適用されております。
動作確認
今回はCloud StorageとNotebook LM Enterpriseで確認します。うまく制御できていることを確認できました。
Cloud Storageの画面
NotebookLM Enterpeiseの画面
まとめ
本記事を通して、VPC Service Controls（VPC SC）は、その名称から連想される従来のネットワーク制御とは一線を画した、Google Cloud 独自の高度なセキュリティレイヤーであることをご理解いただけたかと思います。
1. 役割の明確な区別
- IAM が「誰がリソースにアクセスできるか」という権限を制御するのに対し、VPC SC は「データがどこへ流出するか」というデータ漏洩防止に主眼を置いています。
- AWSには単一のサービスとして相当するものがなく、複数の機能（バケットポリシーなど）を組み合わせる必要があるため、VPC SCの「統一された境界」というコンセプトの理解が難しい原因となっていました。
2. VPC SCの基本と強力な防御
VPC SCは、IAMと連携して二重の防御線を構築します。
- API レベルでの制御: VPC SCは、L3/L4ではなく、Google Cloud APIの呼び出しというL7レベルで機能し、境界外への不正なアクセスやデータ持ち出しを強制的にブロックします。
- Access Context Manager (ACM): ACMのアクセスレベル（IPアドレス、デバイスなど）を VPSC に適用することで、境界へのアクセスをさらに厳格化できます。
- ドライランモード: 導入前にログで影響をシミュレーションできるため、安心して高度なセキュリティを実装できます。
VPC SCは、貴社の機密データをIAMの設定ミスや盗まれた認証情報から守るための「最後の砦」です。データを Google Cloud で安全に扱う上で、この強力なセキュリティ境界の導入をぜひご検討ください。