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

デザイン パターン詳細

はじめに
❏ Identity-Aware Proxy を使ったアクセス制御
❏ VPC Service Controls による 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 のプロダクトには、ホストできるコンテンツの種別(ここでは主に静的コンテンツ / 動的コンテンツ)によって、大まかに以下のように分類することができます。なお、動的コンテンツをホストできるプロダクトは、必然的に静的コンテンツを配信することもできます。

  • 静的コンテンツの公開にのみ対応するプロダクト
    • Google Cloud Storage
    • Firebase Hosting 
  • 静的コンテンツと動的コンテンツの両方の公開に対応するプロダクト
    • Google Compute Engine
    • Google App Engine
    • Google Kubernetes Engine
    • Cloud Run 

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

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

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

  1. 外部 IP アドレスを付与する(Compute Engine)
  2. Service や Ingress を使って Kubernetes クラスター外部にアプリケーションを公開する(Kubernetes Engine)
  3. バケット上のオブジェクトを allUsers から読み込み可能とする(Cloud Storage) 

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

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

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

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

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

  • ネットワーク エンドポイント グループ(NEG)
    プロダクトの種類ごとに各リソースのネットワーク エンドポイント(サービスを提供する IP アドレスとポートの組み合わせと捉えると理解しやすい)をグループ化したもの

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

image

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 Compute Engine
  • Google Kubernetes Engine
  • Google App Engine
  • Cloud Run

このうち、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 を保護する方法については、以下のドキュメントをご参照ください。

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

image

Google Kubernetes Engine パターン

Google Kubernetes Engine(GKE)上で構築したアプリケーションは、Pod と呼ばれる最小単位で構成され、それを公開することでネットワーク サービスとして外部に公開することができます。
公開には、Kubernetes の Service リソース、もしくは Ingress リソースが使用され、Google Cloud 上で Ingress リソースを使用した場合、GKE の Ingress コントローラー は外部 HTTP(S) 負荷分散を Ingress リソースとして起動します。 こうして起動された外部 HTTP(S) 負荷分散は、IAP による保護の対象に含めることができます。外部負荷分散向けに GKE Ingress を構成する方法については、以下のドキュメントをご参照ください。

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

image

サーバーレス パターン

Cloud Run や Google App Engine(GAE)上で構築したアプリケーションは、特に意識しなくても、インターネットに対してパブリックなエンドポイントが提供されますが、これまでのプロダクトと同じく IAP によって保護することができます。
ほかのプロダクトと同じく外部 HTTP(S) 負荷分散を用いますが、サーバーレス NEG と組み合わせることで、 IAP による保護が可能となります。サーバーレス NEG とは、これまでスタンドアロンで運用せざるを得なかったサーバーレス プロダクトを、負荷分散の下に配置するための NEG です。

注意点

  • 同じサーバーレス プロダクトに分類される Cloud Functions では、 IAP を利用できません

  • GAE をバックエンドに使用するとき、外部負荷分散側で IAP を有効にする場合はアプリケーション側で別の IAP ポリシーを有効にしてはいけません

  • Cloud Run を単に外部 HTTP(S) 負荷分散、およびサーバーレス NEG と組み合わせただけでは、インターネットからのトラフィックが外部 HTTP(S) 負荷分散をバイパスすることが可能となってしまうことに注意して下さい。外部 HTTP(S) 負荷分散(および VPC 内部から)経由のリクエスト トラフィックのみを許可するための設定(--ingress internal-and-cloud-load-balancing オプション)を有効にするべきです

  • Cloud Run の IAP によるサポートは 2021 年 8 月時点でプレビューであり、SLA の適用対象外となることに注意して下さい

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

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

image

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 の操作に対するアクセス制御を行うという点で用途が異なります。この違いの模式図は、以下のようになります。 

image

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

解決する課題・使い所

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

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

  • 境界外からのアクセスには IP アドレスやユーザー ID 、デバイス属性などによる厳密な制限が可能

  • 境界内は VPCSC の影響を受けずに従来どおりのアクセスが可能 
image

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

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

解決する課題・使い所

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

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

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

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

  • 外部からのアクセスを許容するプロジェクト(信頼度:低)と自社のプライベート プロジェクト(信頼度:高)を、それぞれ独立した別の境界内に配置する

  •  双方のプロジェクトを接続する境界ブリッジを作成する
image

注意事項

  • VPC Service Controls は、Google Cloud のすべてのプロダクトをサポートしているわけではありません。サポートしているプロダクトについては、以下のドキュメントをご参照ください。サポートされていないプロダクトを利用する場合、そのプロダクトは必ず境界外のプロジェクトで利用して下さい。
  • デバイス属性によるアクセス制御機能は、BeyondCorp Enterprise の機能として提供されているため、 BeyondCorp Enterprise を利用していない環境ではこの機能は利用できません