Zenn
🛣️

【GCPでセキュリティの柱を築く】VPC Service Controlsを設計/実装する

2024/08/20に公開
Google Cloud
設計
Security
クラウド
ベストプラクティス
tech

こんにちは。クラウドアーキテクトの山下です。今回はVPC ServiceControlsを実際に設定していきます。

VPC Service ControlsはGoogleCloud内のプロジェクト毎のAPIとVPCを境界を定義してアクセス制御をL7ネットワークで実現できるサービスです。境界を定義して保護したいプロジェクト、APIとVPCを登録していくもので非常にシンプルな構成になります。

しかし、境界に含まれていないものはコンソールを操作するユーザーであってもリソースを操作するサービスアカウントであっても一切通信が行えなくなります。そのため、通信が成立するために境界に穴を開けていきます。具体的な設定方法についてこの記事で触れていきます。

通信設計

まずはプロジェクトのAPI,VPCの通信経路、連携するサービスを特定する必要があります。どの通信を許可して、どの通信は許可されないのかを決める必要があります。この設計内容によって通信制御内容が変わるためです。

考えるべき観点

以下の観点で通信を整理していきます。構成図も設けるとよりイメージがしやすいので、機能要件/非機能要件を満たす設計を行った最後にこちらを行うとより手戻りが少なくなりおすすめです。

また、観点としてはGoogleCloudのプロジェクト外部かどうかになります。プロジェクト外部なのでマネジメントコンソールもCLIも対象となるのがポイントです。

誰が？ どこから？ どこに？ 何をする？
管理者 自社端末 GCPコンソール プロジェクト内のリソース管理
CloudFunctions プロジェクトBのサービスアカウント プロジェクトAのGCSバケット GCSバケットにオブジェクトをアップロードする
… … … …

設定方法

前提

  • GoogleCloudの組織が必要となります。組織を構成した上でこちらを設定していきます。
  • 権限も組織スコープで実施する必要があるため、組織管理者が実施するのか各プロジェクト担当者に最低限の権限を解放して設定させるのかは規模や運用方針に依ります。
  • また、特定のIPアドレスや地域からのアクセスを指定したい場合はAccessContextManagerでの許可設定を予め作成します。

実際の設定

コンソールにて組織を選択した上でVPC Service Controlsと検索しサービスを選択する。

境界を作成する

VPC Service Controlsはドライランモードで「新しい境界」をクリックします。

※ポリシーを分けて定義することも可能ですが、1組織で統制をかける場合はdefaultをそのまま指定でも問題ないです

境界の種別を選択する

境界名を入力し、境界のタイプで標準境界(デフォルト)を選択します。

境界ブリッジは特定のサービス間の通信制御で利用できるものですが、基本的には標準境界の方がより細かいアクセス制御が行えるので推奨です。

境界の範囲を定義する

ADD RESOURCESで境界に含める対象を選択します。

対象リソースはプロジェクトとVPCを選択する事ができますが、以下の２点考慮事項があります。

[考慮事項]

  • プロジェクトは複数を指定する事ができる

    境界にプロジェクトを複数含める事が出来るため、複数プロジェクトで成立するサービスを構成している場合は複数指定もありです。ただし、後述の上り/下りポリシーで通信を制限する事も出来るため、より厳密に定義したい場合は1プロジェクトのみを境界に入れるようにします。

  • 設定できるプロジェクトとVPCの関係

    プロジェクトAにVPC-Aが存在し境界に入れたい場合、保護するリソースに両方を登録する必要があるように一見見えますが、その必要はありません。プロジェクトを保護対象に指定した時点でそのプロジェクトが持つVPCも境界に含まれます。VPC NETWORKを使うポイントは別プロジェクト全体を境界には入れたくないが、別プロジェクトの特定のVPCだけ境界に入れたい場合に利用します。

境界で公開/非公開にするAPIを選択する

境界で保護するAPIを選択します。外部へ無制限に公開するAPIがない限りはすべてのサービスを追加をクリックします。こちらも後述の上り/下りポリシーでAPIの特定の操作のみ外部公開する設定を行えるので、基本的には全てのサービスを含める事を推奨します。

VPC-API間の通信制御方法を選択する

VPCから保護したAPIにアクセスする際の許可/拒否を設定します。基本的にはすべてのサービスまたはサービスなしを選択します。

ここまでと同様に特定のAPIを外部に公開したい場合やアクセス制限したくない場合にこちらの設定を行います。ひとつ前の設定で外部に対してAPIが公開されなくなったため、VPCからAPIにアクセスするにはパブリック通信経由ではアクセスできず、限定公開を通じてしかアクセスできません。

また、VPCから限定公開を通じてアクセスする事を許可するのか、許可しないのか、特定のAPIにだけ限定公開でのアクセスを強制化させるのかを選択できます。一切VPCを用いずサーバレスのみやPaaSのみを利用する場合はサービスなしを選択すると良いでしょう。

AccessContextManagerのアクセス制限を適用する

境界の外からの通信(Ingress)についてACMで許可された通信内容が適用されます。次の上り(内向き)ポリシーでもIngress通信の許可設定を行う事も出来ますが、ここでACMが設定されている時点でACMの許可内容を満たすものであれば通信が無制限に行えます。

例えば、ACMで管理者の端末やVPNのIPアドレスを登録しておけば、追加設定なしにプロジェクトにそのIPアドレスからであればアクセスできます。GoogleCloud外部からの通信でIPアドレスベースでの通信を許可したい場合はこの設定を行いましょう。

上りポリシー(Ingress)を設定する

こちらも境界の外から通信を定義する項目になります。ACMとは異なり、より細かく特定のPrincipal(アクセス元が誰か)を指定する事が出来ます。

またこのPrincipalがどのAPIのどの操作を行えるかをここで設定出来ます。

VPC Service Controlsはホワイトリスト形式のため、APIに対しての許可設定をここで入れていきます。

Principalに指定出来るのはGoogleアカウント/グループとService Accountになります。

任意のIDを選択すると境界がないのと同じ状態になります。特定のゴールデンイメージやコンテナイメージ、パッケージをプロジェクト間で共有したい場合など不特定多数かつ、今後利用が拡大する事が予想されるAPIのみに許可を与える場合に有用です。

任意のユーザーアカウント/サービスアカウントはそれぞれのアカウントへ無制限の許可を与えます。マネジメントコンソールにアクセスするユーザーは制限はしない場合や、サービスアカウントにだけ特定のAPIの閲覧操作だけを開放する場合に用います。

IDとグループを選択を指定する場合は特定のGoogleアカウント/グループ、Service Accountに限定出来ます。より細かな制御を行う場合はこちらを設定します。

一方、ACMでIPアドレスが指定されていてそのIPアドレスからアクセスされる場合は、ここで明示的に設定しなくてもアクセスが許可されています。マネジメントコンソールやプロジェクトのAPIへのアクセス許可設定は別途不用です。

そして接続するプロジェクトとプロジェクトのAPI、そのAPIに対する操作権限をここで設定します。APIの全操作権限を渡す事も全APIへのアクセス権を渡す事も可能です。よりセキュアにするのであれば、開放するAPIと操作を限定するのが望ましいです。

下りポリシー(Egress)を設定する

最後に境界の外への通信を定義します。こちらもホワイトリストなので外部への通信がある場合は許可設定を定義する必要があります。

Egressの通信はIngress同様にどのPrincipal(誰)がどのAPIのどの操作が行えるかを定義できます。ただ、どのAPIとどの操作かというのはあくまで通信先がGoogle Cloudである事を想定したものになります。Google Cloudでない場合は外部のリソースを指定する必要があります。

アクセス元のPrincipal(ID)をIngressと同様に設定出来ます。内容は変わらず、Googleアカウント/グループ、ServiceAccountの指定になります。

一点考慮すべきなのはこれらは境界の中に存在するものという事です。境界内のユーザーアカウントが外部に対して何か行うというケースはあまりなく殆どService Aacountがこちらの対象になる項目です。

境界外部がGoogle Cloudの場合は許可するAPIと操作をこちらで定義します。境界から境界に対して通信する時はそれぞれの許可設定でIngress/Egressを定義する必要があります。

接続先がGoogle Cloudではない場合は以下のように外部接続先を指定出来ます。AWSとAzureのオブジェクトストレージのバケット/コンテナが現在サポートされています。

まとめ

AWS/AzureのVPCエンドポイントに代わる、かつ、それらよりもよりAPIに特化してさらにアクセス制限を行えるサービスです。

しかし、そのシンプルさと全体に適用できる運用性とは裏腹にIngress/Egressのルール設定を適切に行わないと通信が全く行えない状態になりかねません。

境界をどこまでに設定するのか、どのAPIを制限するのか、境界外の登場人物(Principal)を列挙し何をするのか、これらを設計して初めて構成が可能となります。

一方で、気づかない見落としていた通信内容も中にはあります。これを防ぐためにドライランモードを利用する事が出来ます。ドライランモードとデバッグ方法についてはまた別の回で紹介したいと思います。

Discussion