G-genの杉村です。本投稿では、 Google Cloud(旧称 GCP)のセキュリティ系サービスの中でも特に重要な VPC Service Controls について解説します。
VPC Service Controls とは
VPC Service Controls は Google Cloud(旧称 GCP)のセキュリティ機能です。
サービス境界(service perimeters)と呼ばれる論理的な囲いを作り、その囲いの外から中へのアクセスを防いだり、逆に囲いの中から外へのデータ流出等を防ぐことができます。
VPC Service Controls には「できること」と「そうでないこと」があり、当機能だけを使えば Google Cloud のセキュリティが万全になるという訳ではありません。
当記事ではこの「境界(囲い)」とは何を示しているのか、どのような仕組みでデータの流出等を防いでいるのかについて開設します。
VPC Service Controls ってできること
できること
VPC Service Controls では、Google Cloud サービスに対する API リクエストの接続元を制限することができます。
API リクエストとはそもそも何か?は後述します。
できることの例
- BigQuery に対するクエリの発行元を制限
- Cloud Storage からのオブジェクト読み取りのアクセス元を制限
- Google Kubernetes Engine(GKE)クラスターの設定変更のアクセス元を制限
できないこと
VPC Service Controls では、例えば VPCへのネットワーク的なアクセスを制限することはできません。それは「VPC ファイアウォール」や「WAF(Cloud Armor)」といった仕組みが担います。
できないことの例
- VM への SSH ログインの接続元 IP アドレスを制限
- Webサイトの管理画面へのアクセスの接続元 IP アドレスを制限
- Web アプリへの攻撃を防御
API リクエストとは
Google Cloud における API リクエストについては、以下の記事で図を使って解説しています。「API リクエストとは」の欄をご参照ください。
簡略化した図のみを再掲します。
例えば Google Cloud を Web コンソール画面から操作したとき、背後では Web API がコールされます。Google Cloud の Web API はインターネットに公開されていますが、誰でも API をコールできるわけではなく、Google アカウントや IAM により認証・認可が行われます。
一方で、以下のようなアクセスは Web API とは関係ありません。
- VM への SSH アクセス
- VM でホストされた Web サイトへの HTTP(S) アクセス
これらの例では、接続元ネットワークから VPC 内のリソースに TCP/IP 的にリーチしています。この違いが、前述の「VPC Service Controls でできること、できないこと」の差に関係しています。
VPC 内のリソースに TCP/IP 的に通信するようなアクセス制御は、VPC ファイアウォールや Cloud Armor が行います。一方で、Google Cloud API へのアクセスの制御を行うのが、当記事で扱う VPC Service Controls です。
仕様
想定構成図
以下の構成を例にとって、 VPC Service Controls でできることを説明してます。
サービス境界
VPC Service Controls ではサービス境界(service perimeters)を定義することで、境界外からの API リクエストを制御します。境界には、任意の Google Cloud プロジェクトの任意の Google サービスを入れることができます。
- 参考 : サービス境界の詳細と構成
- 参考 : サポートされているプロダクトと制限事項
サービス境界は、組織レベルのリソースとして作成します。作成の際、どのプロジェクトのどの Google サービスを境界に入れるかを選択します。例えば「対象プロジェクトは XXX
」「対象サービスは BigQuery
と Cloud Storage
」のように設定できます。
このように設定したとき、XXX
プロジェクト内部の BigQuery と Cloud Storage は同じ境界の中に含まれているので、お互いにデータのやりとりをすることができます。例として、Cloud Storage 上の CSV ファイルを、BigQuery テーブルへロードすることができます。
一方でこの設定では、別のプロジェクトにある BigQuery から境界内の BigQuery や Cloud Storage へのアクセスは拒否されます。 別の Google Cloud プロジェクトである YYY
の BigQuery からは、XXX
プロジェクトの Cloud Storage の CSV ファイルをロードできません。
内向きルール
前述の設定では、例えば開発者が自分のオフィスや自宅から BigQuery にアクセスしようとしても、アクセスは拒否されることになります。
ここで使用するのが内向きルール(Ingress rules や上りルールとも呼称)です。アクセスが内向きルールで定義した条件に合致した場合、境界外からの API リクエストは許可されます。
- 参考 : 上り(内向き)と下り(外向き)のルール
このときの許可条件を定義するオブジェクトをアクセスレベルといいます。アクセスレベルに定義できるのは、IP アドレス、接続元の地域などです。例として「特定の IP アドレスからのアクセスだけを許可」などと設定することができます。このアクセスレベルを作成し、サービス境界内の内向きルールと紐づけることで、アクセス許可します。
有償の Chrome Enterprise Premium(旧称 BeyondCorp Enterprise)ライセンスを購入すれば、PC や iOS、Android デバイスにインストールされた Chrome 拡張機能等から収集される情報をもとにして、デバイスの設定情報などに基づいた条件をアクセスレベルに設定することもできます。
- 参考 : アクセスレベル
- 参考 : アクセスレベルを設計する
また内向きルールには、特定の Google アカウント(グループ)であればアクセスを許可するなど、ID ベースでの許可設定を定義することもできます。ただし、内向きルールで許可されていても、Google Cloud API へリクエストを行うには IAM 権限が引き続き必要です。
外向きルール
逆に、境界内のサービスから外のサービスへの API リクエストをする必要がある場合は外向きルール(Egress rules や下りルールとも呼称)を作成します。
例えば、サービス境界内にある Cloud Run Functions 上で動作するスクリプトが、境界外のプロジェクトの Compute Engine API をコールするときには、外向きルールの定義が必要です。
- 参考 : 上り(内向き)と下り(外向き)の定義
境界ブリッジ
境界ブリッジ(perimeter bridges)は、複数の Google Cloud プロジェクト同士を橋渡しするサービス境界です。
1つの Google Cloud プロジェクトに設定できる通常のサービス境界は1つだけです。そのためプロジェクト XXX
と YYY
にそれぞれ別の境界を定義しているとき、この2つのプロジェクト間での通信は拒否されます。
このようなとき、境界ブリッジを作成することで、2プロジェクト間の通信を許可できます。
境界ブリッジの設定はシンプルで、所属させる複数のプロジェクトを選択するだけです。同じ境界ブリッジに所属するプロジェクト同士は、通信することができるようになります。
- 参考 : ブリッジを使用して境界を越えて共有する
VPC 内のクライアントからの API リクエスト
VPC の VM 等から境界内サービスへの API リクエストも必要になる場合があります。
例えば、 VM インスタンス上のアプリから Cloud Storage へデータをアップロードするというケースを考えます。
このような API リクエストは、以下の両方が満たされた場合に可能です。
- 境界内の Google Cloud プロジェクトに所属する VPC 内部からリクエストすること
- VPC のアクセス可能なサービス(VPC accessible services) でサービスが許可設定されていること
VPC のアクセス可能なサービスは、サービス境界に設定する設定値の1つです。設定値は、以下のいずれかから選択することができます。
No | 名称 | 意味 |
---|---|---|
1 | すべてのサービス | 全サービスにアクセス可能 |
2 | サービスなし | どの Google サービスにもアクセスできない |
3 | すべての制限付きサービス | 境界内のサービスにだけアクセスできる |
4 | 選択したサービス | アクセス可能な境界内サービスを明示的に選択する |
例えば、サービス境界の保護対象サービスとして XXX
プロジェクトの Cloud Storage
だけが選択されているとします。このとき、XXX
プロジェクトの VPC 内の VM から、Google サービスへの API リクエストの成否は以下のようになります。
VPC のアクセス可能なサービスの設定値が すべてのサービス
の場合
VM からは、サービス境界の保護対象サービスとして選択されているか否かに関わらず、すべてのサービスにアクセスできます。
No | 接続先サービス | APIコール成否 |
---|---|---|
1 | Cloud Storage | OK |
2 | BigQuery | OK |
VPC のアクセス可能なサービスの設定値が サービスなし
の場合
VM からは、境界に関係なくどの Google サービスにもアクセスできません。
No | 接続先サービス | APIコール成否 |
---|---|---|
1 | Cloud Storage | NG |
2 | BigQuery | NG |
VPC のアクセス可能なサービスの設定値が すべての制限付きサービス
の場合
VM からは、境界の保護対象サービスとして指定したサービスにだけアクセスできます。
No | 接続先サービス | APIコール成否 |
---|---|---|
1 | Cloud Storage | OK |
2 | BigQuery | NG |
VPC のアクセス可能なサービスの設定値が 選択したサービス
の場合
明示的に選択したサービスへの API リクエストだけが成功します。
オンプレミスからの API リクエスト
内向きルールで定義することにより、オンプレミスサイトから接続元 IP を固定したうえで、インターネット経由でサービス境界内のサービスへアクセスすることができます。
しかし VPC と オンプレミスサイトが VPN や Cloud Interconnect で接続している場合に、プライベートネットワーク経由でアクセスしたいときはどうすればいいでしょうか。
VPN や Cloud Interconnect 経由で、VPC の限定公開の Google アクセスや Private Service Connect の仮想 IP アドレス経由でアクセスすることで、オンプレミスから境界内のサービスへプライベートアクセスすることができます。同時に、前述の VPC 内からのアクセスの条件も満たしている必要があります。
限定公開の Google アクセスや Private Service Connect とは、 VPC 内から Google の内部ネットワーク経由でかつ プライベート IP による接続で Google サービスの API へアクセスできる仕組みです。以下の記事で紹介していますので、ご参照ください。
このようなケースでは、オンプレミスからは「サービス境界内の VPC を経由して Google Cloud API へアクセスさせる」ことになります。
なおオンプレミスから限定公開の Google アクセス経由で API リクエストをする際に、クライアント側から利用する API エンドポイントとして restricted.googleapis.com
を使うことで、VPC Service Controls のサポート対象外のサービスに対するアクセスを拒否することができます。
逆にこのドメイン名を使わないと、VPC Service Controls サポート対象外のサービスへのアクセスが可能になってしまい、統制に抜け・漏れが出るおそれがあります。この仕様は、認定試験である Professional Cloud Network Engineer などでも頻出です。
ユースケースと設定例
VPC Service Controls のユースケースと具体的な設定例をいくつか列挙します。
- Cloud Storage に工場の計測データを保存している。プロジェクトにサービス境界を設定し、社内拠点の固定 IP アドレスからのみアクセスできるように、内向きルールを設定する
- BigQuery に個人情報を含む顧客データを保存している。この BigQuery には VPC 内の VM にホストした BI ツール以外からアクセスされることはない。プロジェクトに境界を設定し、内向きルールは設定しない
- 他社プロジェクトの BigQuery テーブル上の機密データを、自社プロジェクトの BigQuery テーブルにコピーしたい。2社でアクセス制御要件が違うため、2つのプロジェクトで別々のサービス境界を作成する。その後、2つのサービス境界を境界ブリッジで接続する
ドライラン構成
既に稼働中の環境に新しく VPC Service Controls を設定するときや、境界の設定に手を加えるときなどに、テストなしで変更を適用すると、予期せぬ不具合が発生するかもしれません。境界には通常の構成に加えて、ドライラン構成を設定できます。
ドライラン構成を適用すると、サービス境界への違反が発生したときにはそのアクションは拒否されず、Cloud Logging へログのみが記録されます。これは、一般的な WAF 製品等のドライラン機能と似ています。
ドライランを使って事前に影響範囲の確認をしておくことで、設定変更の影響を見極めてから実際の適用をすることができます。
- 参考 : サービス境界のドライラン モード
ドライランの使用方法については、以下の記事もご参照ください。
アクセスポリシー
アクセスポリシーとは
VPC Service Controls には、アクセスポリシー(Access policies)という管理用オブジェクトがあります。アクセスポリシーは、前述のサービス境界やアクセスレベルなどの設定オブジェクトをグルーピングするためのオブジェクトです。
アクセスポリシーは、scoped access policy や scoped policy と呼ばれる場合もあります。
サービス境界やアクセスレベルを作成する先、格納する先のアクセスポリシーを選択します。意識していない場合、default
アクセスポリシーに格納されます。default
アクセスポリシーは、Google Cloud の Web コンソールから初めてサービス境界を作成すると、自動的に作成されます。
アクセスポリシーには、管理を委任するフォルダやプロジェクトを指定できます。これにより、フォルダまたはプロジェクトの管理者に、VPC Service Controls の管理を委任することができます。
- 参考 : アクセス ポリシー
- 参考 : スコープ ポリシーの概要
アクセスポリシーの使い方
例えば、アクセスポリシー development
を作成し、フォルダ dev
を管理スコープとして定義します。また、アクセスポリシー development
の管理者として、開発責任者の Google アカウントである xxx@example.com
を指名します。
このように設定すると、xxx@example.com
はフォルダ dev
の範囲内において VPC Service Controls を管理できます。
このように、組織全体の VPC Service Controls は情シス部門で管理したいが、各開発チームには各チームごとの範囲で VPC Service Controls を管理させたいときなどに利用できます。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it