はじめに

一言に、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 の種別ごとのグルーピングを以下の図に示します。 

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 を使ったアクセスの管理については、以下をご参照ください。 

• クイックスタート: Google アカウントによるアクセスの管理 | Identity-Aware Proxy

• クイックスタート: 外部 ID によるアクセスの管理 | Identity-Aware Proxy 

アーキテクチャ

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

• Compute Engine の IAP の有効化 | Identity-Aware Proxy

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

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