さまざまな要件に対応したアプリケーション、API の公開とアクセス制御   

はじめに

一言に、Google Cloud 上にアプリケーションを構築して公開するといっても、アプリケーションの用途は不特定多数に向けて公開するものや、特定のネットワークや特定のユーザーに対して限定的に公開する社内アプリケーションなどさまざまです。 

アプリケーションはその目的や公開先などによって、アプリケーションへの接続を許容する通信経路や接続元といった要件が異なります。

また、アプリケーションを構築する基盤となるプロダクトも、Compute Engine VM のような IaaS のこともあれば、Cloud Run のようなサーバーレスを用いる場合もあります。これらのプロダクトによって、アプリケーションへの接続経路や接続元を制御する方法に違いがあります。

アクセス制御の観点は、パブリック クラウドが利用者に提供する API にもあてはまります。Google Cloud では、オブジェクト ストレージやデータ分析、機械学習など、さまざまな API サービスが提供されています。それらの API のエンドポイントは、基本的に外部 IP アドレスを持ったものであり、利用者の置かれている事業環境やセキュリティ要件によっては、パブリックな API ではあるものの API へのアクセスを厳しく制限したいケースもあるでしょう。

本章では、アプリケーションや API の接続要件と、アプリケーション実行基盤として使用する Google Cloud のプロダクトを、どのように組み合わせると、どのようなアクセス制御を講じることができるのかを解説します。

なお本章では、アプリケーションはインターネット（外部 IP アドレス空間）からのアクセスを想定した構成について解説するものとします。VPC 内部に閉じたアプリケーションに対して、Cloud VPN や Cloud Interconnect などの内部 IP アドレス ベースのアクセスについては対象外となります。 

インターネット上の不特定多数のユーザーに対してアプリケーションを公開

インターネット上の不特定多数のユーザーに対して、アプリケーションを公開するパターンを見ていきましょう。例えば、企業のコーポレート サイトや B2C 向けの EC サイト、あるいは期間を限定して公開する新商品のキャンペーンサイトなどがこれにあたります。

アプリケーションやコンテンツをインターネットに対して公開するという目的で利用できる Google Cloud のプロダクトには、ホストできるコンテンツの種別（ここでは主に静的コンテンツ / 動的コンテンツ）によって、大まかに以下のように分類することができます。なお、動的コンテンツをホストできるプロダクトは、必然的に静的コンテンツを配信することもできます。

各プロダクトのエンドポイントを使ったアプリケーションの公開

アプリケーションやコンテンツの公開にあたって、独自の手順を踏む必要がある一部のプロダクト以外は、すべて標準的に外部公開用のエンドポイントが用意されるため、アプリケーションをデプロイする、コンテンツを配備するという手順のみでインターネット上の不特定多数に対してアプリケーションやコンテンツを公開することができます。

独自の手順を踏む必要があるプロダクトは、以下の 3 つです。 

これらは各プロダクトの標準に近い構築パターンであるため、詳細の解説は割愛します。

このパターンの利点としては、単一に近いプロダクトの設定でアプリケーションの公開ができることにあります。その反面、複数プロダクトを同一ドメイン下でパス単位で使い分けたり、DDoS 対策や CDN による静的コンテンツのキャッシュなどの高度な要件には対応していません。

高度な要件を満たすためには、次に解説する外部 HTTP(S) 負荷分散との組み合わせが必要です。

外部 HTTP(S) 負荷分散を使ったアプリケーションの公開

Firebase 以外の各プロダクトは、外部 HTTP(S) 負荷分散とネットワーク エンドポイント グループ（NEG）と組み合わせることで、 URL パスベースのルーティングや、複数のリージョンに同じプロダクトを分散配置した際のリージョンをまたいでのトラフィックの分散ルーティング、Cloud CDN や Cloud Armor、後述する Identity-Aware Proxy（IAP）の追加などに対応することができます。

外部 HTTPS(S) 負荷分散のバックエンドとして利用できるプロダクトと、それらを束ねる NEG の種別ごとのグルーピングを以下の図に示します。 

Identity-Aware Proxy を使ったアクセス制御

解決する課題・使い所

アプリケーションへのアクセス元ネットワークを限定できない在宅勤務向けの社内システムや、エクストラ ネットなどの企業間閉域網で接続されていない企業間取引などでは、アプリケーションのエンドポイントそのものは外部 IP アドレスを持ち、IP レイヤーとしてはインターネットからのリーチャビリティを有するものの、アクセス元を厳密に制限したいケースが多いでしょう。

在宅勤務のケースでは、アクセス元の IP アドレスが動的割当のケースが多くなります。一方、企業間取引では、アクセス元の IP アドレスは固定されているため厳密に制限できるものの、この IP アドレスが相手先企業のインターネット ゲートウェイのものであるため、業務に無関係の相手先従業員までがアプリケーションにアクセスできてしまうという事態も起こりえます。

このような前提条件に対して、接続元 IP アドレスという従来から使われてきた識別情報ではなく、アクセスするアカウントをキーに Google Cloud 上に構築されたアプリケーションへのアクセスを制御することを可能とするプロダクトが Identity-Aware Proxy（IAP）です。  

IAP を使うことで、Google アカウントだけでなく OAuth、SAML、OIDC などに対応するさまざまな ID プロバイダ（IdP）を使ったユーザー認証を、Google Cloud 上のアプリケーションに対して実施することができます。IAP を使ったアクセスの管理については、以下をご参照ください。 

アーキテクチャ

IAP は、既存のアプリケーションに対して手軽にユーザー認証を追加できる機能ですが、2021 年 8 月時点でアプリケーション / コンテンツ公開基盤として挙げたプロダクトのうち、これを利用したアクセス制御が可能なものは、以下のみとなります。

このうち、Google App Engine（以下 GAE） 以外で公開するアプリケーションに IAP を適用する場合、ロードバランサである外部 HTTP(S) 負荷分散を利用する必要があります。GAE では、外部 HTTP(S) 負荷分散を利用する方法のほか、GAE 自身に IAP による保護を有効化する機能があります。

以下で、プロダクトごとに IAPを利用する構成のパターンを解説します。なお、現時点では、Google Cloud 上に構築したアプリケーションだけでなく、オンプレミスや他社パブリック クラウド基盤上に構築したアプリケーションも IAP で保護することが可能となっていますが、本章は Google Cloud 上に構築されたアプリケーションの公開にフォーカスしているため解説を割愛します。

Google Compute Engine パターン

Google Compute Engine（GCE）で IAP を有効化する場合、VM が外部 IP アドレスを持っているか否かで方法が分かれます。 

1) VM が外部 IP アドレスを持つ場合 

Compute Engine VM をインスタンス グループとしてグループピングし、このインスタンス グループをバックエンドとするバックエンド グループと外部 HTTP(S) 負荷分散を作成します。HTTPS でリッスンするフロントエンドを備えた外部 HTTP(S) 負荷分散は、IAP を有効化することができます。IAP を使って Compute Engine VM を保護する方法については、以下のドキュメントをご参照ください。

この構成の模式図は、以下のようになります。

Google Kubernetes Engine パターン

Google Kubernetes Engine（GKE）上で構築したアプリケーションは、Pod と呼ばれる最小単位で構成され、それを公開することでネットワーク サービスとして外部に公開することができます。

公開には、Kubernetes の Service リソース、もしくは Ingress リソースが使用され、Google Cloud 上で Ingress リソースを使用した場合、GKE の Ingress コントローラー は外部 HTTP(S) 負荷分散を Ingress リソースとして起動します。 こうして起動された外部 HTTP(S) 負荷分散は、IAP による保護の対象に含めることができます。外部負荷分散向けに GKE Ingress を構成する方法については、以下のドキュメントをご参照ください。

この構成の模式図は、以下のようになります。

サーバーレス パターン

Cloud Run や Google App Engine（GAE）上で構築したアプリケーションは、特に意識しなくても、インターネットに対してパブリックなエンドポイントが提供されますが、これまでのプロダクトと同じく IAP によって保護することができます。

ほかのプロダクトと同じく外部 HTTP(S) 負荷分散を用いますが、サーバーレス NEG と組み合わせることで、 IAP による保護が可能となります。サーバーレス NEG とは、これまでスタンドアロンで運用せざるを得なかったサーバーレス プロダクトを、負荷分散の下に配置するための NEG です。


注意事項

サーバーレス NEG を使ったロードバランサの設定は、以下のドキュメントをご参照ください。

この構成の模式図は、以下のようになります。

VPC Service Controls による API の保護

ここまでは、Google Cloud のさまざまなプロダクトの上に利用者のカスタム アプリケーションやコンテンツをホストする際に、その公開方法やアクセス制御方法について解説してきました。

そのほか Google Cloud には、BigQuery のようなデータ分析プロダクトや Translation API に代表される機械学習 API など、さまざまな API サービスが提供されています。これらの API は外部 IP アドレスを持っており、プロダクトの操作は基本的に API を操作することで実現しています。

Google Cloud の API は、IAM で呼び出し元を認証することが可能ですが、より複雑な条件（呼び出し元のネットワーク識別情報やユーザー情報、呼び出し先の API など）によって API の利用を厳密に制御し、API を保護するための機能が VPC Service Controls です。  

VPC Service Controls（VPCSC）以外の Google Cloud のリソースに対するアクセス制御にはファイアウォールがありますが、ファイアウォールが VPC 内部のリソース（Compute Engine VM など）を起点、もしくは終点とするレイヤ 3-4 のアクセス制御を行うことを目的としているのに対して、 VPCSC では、以下のとおり API の操作に対するアクセス制御を行うという点で用途が異なります。この違いの模式図は、以下のようになります。

接続元 IP や ID 、デバイス属性に応じたアクセス制御パターン

解決する課題・使い所

特定の API サービスに対して、接続元 IP アドレスやユーザー ID 、デバイス属性に応じたアクセス制御が可能です。例えば、在宅勤務で自宅のネットワークから操作する場合、会社が管理する BigQuery の操作は会社支給の PC からの操作のみ許可する、もしくはデータを共有している取引先のゲートウェイからのみ許可するなどのユースケースに対応することができます。

この構成には、以下のようなメリットがあります。

このパターンの実装については、以下のドキュメントをご参照ください。

社外とデータを共有する境界ブリッジ パターン

解決する課題・使い所

例えば BigQuery など、自社が管理する Google Cloud プロジェクト以外のデータ共有によるコラボレーションが可能なプロダクトは数多くあります。しかし、そのようなケースにおいては、社外からの必要最低限のアクセス以外は厳しく制限することが一般的です。

こうした場合、外部からのアクセスを許可するためのプロジェクトを設け、自社専用のプロジェクトとは分けることで、機密性を確保するなどが考えられます。

しかし、「外部からのデータは Cloud Storage で受け取りたい。受け取ったプロジェクトと自社のプロジェクトは別とする。ただし、受け取ったデータは自社のプロジェクトでにコピーして使いたい。」といったニーズを満たすためには、外部からアクセスできるプロジェクトと自社のプライベート プロジェクトの間の橋渡しが必要です。

これを実現するポイントは、以下のとおりです。

注意事項