多くの組織には、内部要件に基づいて、または Assured Workloads の導入の一環として、明示的に承認された API のリストへのネットワーク アクセスを制限するコンプライアンス要件があります。オンプレミスでは、この要件は多くの場合プロキシ制御で対処されますが、Google Virtual Private Cloud（VPC）ではリソース サービスの使用を制限する組織のポリシーで対応できます。このポリシーを使用すると、管理者はリソース階層内で作成できる Google Cloud リソースを定義できますが、この組織のポリシーを効果的に使用するには、環境内でさまざまなネットワーキング コントロールを調整する必要があります。
このドキュメントでは、組織のポリシー サービスやその他のネットワーク制御を使用して、個別に承認された Google API へのアクセスを制限する方法と、オンプレミス プロキシベースのアプローチを Google Cloud サービスに適用する際の課題について説明します。このドキュメントは、VPC ネットワーク エンドポイントから到達できる Google Cloud APIs を制限することを必要とするネットワーク管理者またはセキュリティ チームを対象としています。
Google API へのアクセス制御のためのプロキシに関する課題
オンプレミス ネットワークでは、承認されたサービスとドメインにのみ下り（外向き）トラフィックを許可するというコンプライアンス要件が企業に必要な場合があります。この要件は、ウェブプロキシまたはセキュア アクセス ゲートウェイ経由で下り（外向き）トラフィックをフィルタすることで適用できます。このプロキシはすべての送信トラフィックを傍受し、明示的に承認された API への下り（外向き）のみを許可します。
企業によっては、同様に VPC ネットワークから承認済み Google Cloud APIs へのアクセスを制限するためのコンプライアンス要件がある場合もあります。このようなコンプライアンス管理は、次のようなシナリオで頻繁に発生します。
- 機密性の高いワークロードとコンプライアンス管理のために Assured Workloads を採用している企業があります。
- 企業には内部コンプライアンス要件があります。Google Cloud のネットワーク エンドポイントは、内部プロセスを介して承認された Google Cloud APIs にのみアクセスできます。
- ある企業が、Infrastructure as a Service（IaaS）ワークロードを最小限のリファクタリングで Google Cloud に移行したいと考えています。
- クラウドの制御をまだ開発していない企業が、オンプレミス環境から既存の制御を拡張したいと考えています。
企業はウェブプロキシを使用してオンプレミス ネットワークからウェブサービスへの下り（外向き）を制御することはできますが、VPC ネットワークから Google Cloud APIs へのアクセスの制御にはこのアプローチをおすすめしません。このプロキシ アプローチを使用すると、スケーラビリティの問題が生じ、単一障害点が生まれ、Google Cloud APIs を使用したデータ漏洩のリスクには対応できません。
個々の Google Cloud APIs へのアクセスを選択的に許可するには、プロキシの代わりに Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーを使用することをおすすめします。以降のセクションでは、個々の Google API へのアクセスを制御するウェブプロキシの構築と維持に関連する課題について説明します。
複数の Google API で使用される共有 IP アドレス範囲
単一の IP アドレスにフィルタリングするプロキシまたはファイアウォール ルールで、個別の Google API へのアクセスを制御することはできません。Google では、デフォルト ドメインの IP アドレスの動的範囲を使用しています。これらの IP アドレス内では、専用 IP アドレスと特定の API 間に 1 対 1 の関係はありません。
Google API で使用される共有ドメイン
一部の Google API では、ドメインのトラフィックをフィルタしてもネットワーク アクセスを制御できません。ほとんどの Google API は、パスで特定の API を区別し、URI の先頭に www.googleapis.com が付加されたエンドポイントでアクセスできます。専用のサブドメインを持つエンドポイントを使用する Google API もあります。たとえば、Cloud Storage API リファレンスでは、storage.googleapis.com/storage/v1 エンドポイントに関連する URI が文書化されていますが、同じ API メソッドを呼び出す www.googleapis.com/storage/v1 で始まる URI を使用することもできます。
ドメイン www.googleapis.com にエンドポイントのみを持つ複数の API を使用する場合、下り（外向き）プロキシはドメインのみに基づいて API を区別することはできません。たとえば、Deployment Manager などの一部の Google Cloud APIs や、タグ マネージャーや Google Play Games などのその他の Google API は、www.googleapis.com ドメインでのみアクセスできます。さらに、すべての Google Cloud APIs ではデフォルトで TLS 暗号化が使用されます。これらの API の一つを許可し、他の API をブロックする場合は、プロキシでリクエストを復号して URI パスでフィルタする必要があり、複雑になります。
プロキシに起因するボトルネック
VPC ネットワークから Google API へのすべてのトラフィックが下り（外向き）プロキシを経由する必要がある場合は、プロキシがボトルネックになる可能性があります。VPC ネットワークから Google API へのトラフィックに下り（外向き）プロキシを使用する場合は、高可用性向けのプロキシを構築してサービスの中断を避けることをおすすめします。組織の成長に伴って、プロキシが単一障害点、レイテンシ、スループットの低下を引き起こすことがあるため、プロキシの維持とスケーリングは複雑になる可能性があります。大量のデータを転送するオペレーションでは、特に影響を受ける可能性があります。
サービス間の引き出しのリスク
ウェブプロキシは、VPC ネットワークから Google API に到達できるかどうかを制限できますが、Google API を使用するその他の引き出しパスには対応しません。たとえば、社内の従業員に Cloud Storage 内部バケットを読み取るための正当な IAM 権限が付与されている場合があります。この権限を付与されている場合は、従業員が内部データを読み取り、データを一般公開バケットにコピーすることが可能です。下り（外向き）プロキシは、VPC から発信されていない API 間のトラフィックを制限できません。また、インターネット トラフィックが Google Cloud APIs のパブリック エンドポイントに到達する方法を制御することもできません。
センシティブ データの場合は、VPC Service Controls 境界を使用して、このタイプの漏洩のリスクを軽減できます。VPC Service Controls の境界を適用すると、IAM ポリシーの構成ミス、漏洩、認証情報の不正使用から境界内のリソースを保護できます。
ネットワーク制御を構成して未承認のサービスを制限する
Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーを使用する場合、サービスへのアクセスを効果的に制限するには、VPC ネットワークで下りトラフィックと引き出しパスを制限する方法を検討する必要があります。以下の各セクションでは、ネットワーク設計で Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーを効果的に使用するためのベスト プラクティスについて説明します。
VPC Service Controls を構成する
Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーを使用する場合は、VPC Service Controls も構成することをおすすめします。プロジェクトでこの組織のポリシーを適用すると、そのプロジェクトで使用できるサービスが制限されますが、このプロジェクトのサービスによって他のプロジェクトのサービスと通信が妨げられることはありません。これに対し、VPC Service Controls を使用すると、境界を定義して境界外のサービスとの通信を防止できます。
たとえば、プロジェクトで Compute Engine を許可して Cloud Storage を拒否する組織ポリシーを定義すると、このプロジェクト内の VM はプロジェクトで Cloud Storage バケットの作成や Cloud Storage バケットとの通信ができません。ただし、VM は別のプロジェクトの Cloud Storage バケットに対してリクエストを送信できるため、Cloud Storage サービスでのデータの引き出しは可能です。境界外の Cloud Storage または他の Google サービスとの通信をブロックするには、VPC Service Controls の境界を構成する必要があります。
これらのコントロールを併用することで、環境内で承認済みのサービスを選択的に許可し、未承認のサービスへのさまざまなデータの引き出し経路をブロックします。
インターネットへのパスを削除する
VPC ネットワーク内のリソースがインターネットと直接通信できる場合は、未承認の Google API やブロックしようとしている他のサービスへの代替パスが存在する可能性があります。したがって、VM の内部 IP アドレスのみを使用し、NAT またはプロキシ ソリューションを介した下り（外向き）ルートは許可しないことをおすすめします。Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーでは、公共のインターネットへの引き出しパスが抑制されないため、未承認のサービスに、環境外のサーバーから間接的にアクセスされる可能性があります。
API アクセス用のプライベート エンドポイントを構成する
ネットワーク内の API エンドポイントを制御するには、Private Service Connect を使用して Google API にアクセスすることをおすすめします。限定公開の Google アクセスを構成して、内部 IP のみを持つ VM が Google API にアクセスできるようにすると、VPC Service Controls または Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーでサポートされていない Google API を含むすべての API がアクセス可能になります。限定公開の Google アクセスを、サポートされている API のみに制限するには、vpc-sc バンドルを使用して Private Service Connect を構成します。
たとえば、限定公開の Google アクセスを有効にすると、Google ドライブや Google Maps Platform などのすべての Google API へのプライベート ネットワーク パスが許可されます。従業員は、Google Drive API を使用して Compute Engine インスタンスから個人の Google ドライブにデータをコピーする可能性があります。このデータの引き出しパスを防ぐには、Private Service Connect を vpc-sc で構成して、restricted.googleapis.com のエンドポイントで同じセットの制限付き仮想 IP（VIP）でサポートされるサービスへの接続ができるようにします。一方、all-apis バンドルまたはプライベート VIP（private.googleapis.com）を構成した Private Service Connect エンドポイントである、Google のデフォルト ドメインを使用すれば、限定公開の Google アクセスを使用することでより広範な Google API にアクセスできます。
あるいは、restricted.googleapis.com へのルートの構成も可能です。各リージョンと環境内の VPC ネットワークに Private Service Connect エンドポイントを作成したくない場合は、制限付き VIP を使用することをおすすめします。ただし、VPC ネットワークの内部にエンドポイントを作成できるため、一般に告知されたエンドポイントへのルートを必要とする VIP アプローチよりも、Private Service Connect アプローチをおすすめします。
次のステップ
- 詳細について、Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーを確認します。
- Restrict Resource Service Usage（リソース サービスの使用を制限する）組織ポリシーでサポートされている API を理解します。
- VPC Service Controls でサポートされている API を理解します。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。