セキュリティ設計の概要

Cloud Run でセキュリティに関するベスト プラクティスを実装してデータを保護する方法と、これらの機能を使用してセキュリティ要件を満たす方法について説明します。

アーキテクチャ

Cloud Run は、Google が週に何十億ものコンテナをデプロイし、Gmail や YouTube などの世界最大のサイトをホストしている環境と同じ環境の Borg 上で動作します。Cloud Run のコンポーネントは同じインフラストラクチャを共有しているため、他の Google サービスと同じセキュリティ標準で構築されています。

セキュリティに対する Google のアプローチについて詳しくは、Google のセキュリティの概要のホワイトペーパーをご覧ください。

Cloud Run アーキテクチャには、さまざまなインフラストラクチャ コンポーネントが含まれています。次の図は、これらのコンポーネントがサービスへのリクエストCloud Run Admin API 呼び出しにどのように応答するかを示しています。

Cloud Run インフラストラクチャのコンポーネントの図。
図 1. Cloud Run インフラストラクチャのコンポーネントの図。

サービスへのリクエスト

Cloud Run サービスへのリクエストがカスタム ドメイン経由または直接 run.app URL に送信されると、リクエストは次のコンポーネントによって処理されます。

  • Google Front End(GFE): Google のグローバル インフラストラクチャ サービスです。run.app URL へのリクエストの送信時に TLS 接続を終了し、DoS 攻撃に対する保護を適用します。Cloud Run はリージョン サービスであるため、リクエストが run.app URL 経由でアクセスされると、GFE は該当リージョンの Cloud Run にリクエストを転送します。
  • Google Cloud ロードバランサ: カスタム ドメインを処理するために Cloud Load Balancing を設定する際に、前述の GFE 機能を組み込ます。また、トラフィック管理やアクセス制御などの追加機能を実行できるように Google Cloud ロードバランサを構成することもできます。
  • HTTP プロキシ: サンドボックス化されたアプリケーションのインスタンスに対する HTTP 受信リクエストをロードバランスするゾーン コンポーネント。
  • スケジューラ: サンドボックス化されたアプリケーションのインスタンスをホストするアプリサーバーを選択します。
  • アプリサーバー: 各アプリケーションのコンテナのインスタンスを実行するサンドボックスを作成して管理する、ゾーンおよびマルチテナントのコンピューティング ノード。
  • サンドボックス: ユーザーコードをシステムや他のユーザーから分離します。詳しくは、次のコンピューティングのセキュリティをご覧ください。
  • ストレージ: サポートされているコンテナ レジストリからインポートされたコンテナ イメージ用のファイル サーバー インターフェースを公開します。
  • メタデータ サーバー: サンドボックス固有の認証情報とメタデータを提供します。
  • アウトバウンド ネットワーク: サンドボックスで開始されたアウトバウンド トラフィックを管理します。

Cloud Run Admin API 呼び出し

Cloud Run Admin API にリクエストが送信されると、以下のコンポーネントでリクエストが処理されます。

  • Google Front End(GFE): TLS 接続を終了して、DoS 攻撃に対する保護を適用する Google のグローバル インフラストラクチャ サービス。
  • コントロール プレーン: アプリケーションの構成を検証してストレージに書き込みます。
  • 構成ストレージ: アプリケーション構成を SpannerBigtable に保存し、アプリサーバー、スケジューラ、ネットワーキングなどの他のコンポーネントからアクセスできるようにします。

コンピューティングのセキュリティ

Cloud Run コンポーネントは、Google のコンテナ管理システムである Borg で実行されます。Cloud Run では、コンテナに次の 2 つの実行環境が用意されています。

  • 第 1 世代: gVisor このオプションは、コンテナ セキュリティ プラットフォームをベースにしています。コードベースが小さいため、攻撃対象領域が小さくなります。変更はすべてセキュリティ審査の対象であり、ほとんどの変更はメモリセーフな方法で書き込まれます。Secure Computing Mode(seccomp)システムコール フィルタリングを使用することで、セキュリティを強化しています。

  • 第 2 世代: このオプションは Linux マイクロ VM をベースにしています。このオプションを使用すると、カスタム ワークロードの互換性とパフォーマンスが向上します。seccomp システム呼び出しフィルタリングと Sandbox2 Linux 名前空間を使用して、セキュリティを強化しています。

次の図に示すように、これらの実行環境はいずれも、個々の VM と同等のハードウェアをベースにしたレイヤ(x86 仮想化)とソフトウェア カーネル レイヤからなる 2 つのサンドボックス レイヤを使用します。

いずれの実行環境でも、ユーザー コンテナは 2 つのサンドボックス レイヤによって他のワークロードから分離されています。
図 2. いずれの実行環境でも、ユーザー コンテナは 2 つのサンドボックス レイヤによって他のワークロードから分離されています。

サービスでコンテナを保護するためにサードパーティのインフラストラクチャを使用している場合は、第 2 世代の実行環境を使用します。

データ暗号化とストレージ

Cloud Run インスタンスはステートレスです。インスタンスを終了すると、その状態は破棄されます。したがって、新しいインスタンスはすべて白紙の状態から開始されます。

ステートフル データがある場合、次の方法でデータを管理できます。

また、Cloud Run は他の多くの Google Cloud システムと統合され、次のようにデータを管理してアクセスします。

Google Cloud 全体で、すべてのデータが保存時に暗号化されます。

Cloud Run は、アクセスの透明性データ レジデンシーといったデータ保護と透明性に関する Google Cloud 全体のイニシアチブを遵守しています。

ネットワーク セキュリティ

Cloud Run と他のすべての Google Cloud サービスは、転送中のトラフィックをすべて暗号化します。下り(外向き)と上り(内向き)の制御を Cloud Run サービスやジョブに組み込んで、制限のレイヤを追加できます。組織管理者は、組織のポリシーを設定して、下り(外向き)と上り(内向き)を強制的に適用することもできます。

下り(外向き)トラフィック

Cloud Run から出る下り(外向き)トラフィックは、トランスポート レイヤ 4(TCP と UDP)として扱われます。

デフォルトでは、下り(外向き)トラフィックは Cloud Run から送信されるときに、次のいずれかの経路をとります。

  • 対象とする宛先が VPC ネットワークにある場合: トラフィックは、ダイレクト VPC 下り(外向き)またはサーバーレス VPC アクセス コネクタを使用して、プロジェクトの VPC ネットワークや共有 VPC ネットワークに送信されます。このコネクタは、VPC ネットワークに直接配置されたリージョン リソースです。
  • 対象とする宛先が VPC ネットワークにない場合: トラフィックは、Google のネットワークまたは公共のインターネット内の宛先に直接転送されます。
Cloud Run インフラストラクチャのコンポーネントの図。
図 3. 下り(外向き)トラフィックは、コネクタ経由で VPC ネットワークにプロキシ送信できます。VPC または VPC 以外のネットワークに直接送信することもできます(プレビュー)。

下り(外向き)の制御

下り(外向き)トラフィックをさらに制御するには、VPC 下り(外向き)設定を使用して、ダイレクト VPC 下り(外向き)やコネクタですべてのトラフィックを VPC ネットワークに転送します。

VPC ネットワークに到達すると、次のように VPC ツールを使用してトラフィックを管理できます。

組織管理者は、許可された VPC 下り(外向き)設定(Cloud Run)のリスト制約を設定して、下り(外向き)を強制的に適用することもできます。

上り(内向き)トラフィック

下り(外向き)とは対照的に、Cloud Run の上り(内向き)トラフィックはアプリケーション レイヤ 7(HTTP)にあります。

Cloud Run は、次のソースから受信する上り(内向き)トラフィックを受け付けます。

  • 公共のインターネット: リクエストは、一般公開ソースから Cloud Run サービスに直接転送されます。外部 HTTP(S) ロードバランサ経由で転送することもできます。

  • VPC ネットワーク: 限定公開の Google アクセスPrivate Service Connect、または内部アプリケーション ロードバランサを使用して、VPC ネットワークから Cloud Run サービスにトラフィックを転送できます。このタイプのトラフィックは常に Google のネットワーク内にとどまります。

  • Google Cloud サービス: トラフィックは、BigQuery や Cloud Run 自体など、他の Google Cloud サービスから Cloud Run に直接送信されます。これらのサービスを VPC ネットワーク経由で転送するように構成することもできます。このタイプのトラフィックは常に Google のネットワーク内にとどまります。

Cloud Run インフラストラクチャのコンポーネントの図。
図 4. Cloud Run へのレイヤ 7 HTTP ネットワーク上り(内向き)トラフィック。

Cloud Run のネットワーク セキュリティ モデルには、次の上り(内向き)トラフィック プロパティが含まれています。

  • run.app URL に直接送信されるトラフィック: トラフィックが Cloud Run で受信されるように、run.app URL で HTTPS を使用する必要があります。Google のフロントエンド サービスを提供するインフラストラクチャでは、TLS を終了し、暗号化されたチャネルを介してトラフィックを Cloud Run とコンテナに転送します。
  • Google Cloud ロードバランサに関連付けられたカスタム ドメインへのトラフィック: HTTPS トラフィックの場合、Google Cloud の内部ロードバランサと外部ロードバランサが TLS を終了し、暗号化されたチャネルを介してトラフィックを Cloud Run とコンテナに転送します。Google Cloud ロードバランサでは、IAPGoogle Cloud ArmorSSL ポリシーなど、追加のセキュリティ機能を適用することもできます。

Cloud Run に送信される VPC ネットワーク トラフィックの構成について詳しくは、VPC ネットワークからのリクエストを受信するをご覧ください。

上り(内向き)の制御

Cloud Run の上り(内向き)制御は、Cloud Run で受信するトラフィックを管理し、信頼できる送信元からのトラフィックのみを受信できるようにします。

内部クライアントのみにサービスを提供する Cloud Run サービスの場合、「内部」構成を設定すると、次の内部ソースからのトラフィックのみが Cloud Run で受信されます。

  • プロジェクトまたは VPC Service Controls 境界の VPC ネットワーク(すべてのトラフィックを VPC ネットワーク経由で転送する Cloud Run サービスを含む)。
  • Cloud Run サービスが接続されている共有 VPC ネットワーク。
  • プロジェクトまたは VPC Service Controls の境界内にある一部の Google Cloud サービス(BigQuery など)。
  • VPC ネットワークを通過して Cloud Run に到達するオンプレミス クライアントからのトラフィック。

組織管理者は、組織のポリシーを設定して上り(内向き)を強制的に適用することもできます。

上り(内向き)の制御の詳細については、Cloud Run の上り(内向き)の制限をご覧ください。

アクセス制御

アクセス制御は、Cloud Run のサービスとジョブにアクセスできるユーザーを制限するために使用されます。

サービスやジョブを管理できるユーザー

Cloud Run のサービスやジョブを管理するユーザーを制御するために、Cloud Run は IAM を使用してユーザーとサービス アカウントを認証します。

サービスやジョブがアクセスできる対象

Cloud Run ワークロードがネットワーク経由で到達できる対象を制御するには、ネットワーク セキュリティ セクションで説明したように、VPC ファイアウォール ルールを適用して、すべてのトラフィックが VPC ネットワークを経由するようにします。

ダイレクト VPC 下り(外向き)を使用している場合は、ネットワーク タグを Cloud Run リソースに付加して、ファイアウォール ルールでそのネットワーク タグを参照できます。サーバーレス VPC アクセスを使用している場合は、コネクタ インスタンスにファイアウォール ルールを適用できます。

IAM を使用して、Cloud Run のサービスやジョブがアクセスできるリソースを制御します。サービスとジョブは、デフォルトで Compute Engine のデフォルトのサービス アカウントを使用します。機密性の高いワークロードの場合は、専用のサービス アカウントを使用して、ワークロードで作業を行うために必要な権限のみを付与できるようにします。専用のサービス アカウントの管理にサービスごとの ID を使用する方法を確認してください。Cloud Run からユーザーに専用のサービス アカウントの作成を促す方法については、Recommender を使用して Cloud Run サービスを保護するをご覧ください。

サービスの呼び出しやジョブの実行ができるユーザー

Cloud Run には、サービスの呼び出しやジョブの実行をするユーザーを制御するために、いくつかのオプションがあります。

上り(内向き)制御

ネットワーク レベルでの Cloud Run サービスの上り(内向き)の管理については、前のセクションの上り(内向き)の制御をご覧ください。

Cloud Run ジョブはリクエストを処理しないため、ジョブの実行時に上り(内向き)の制御は使用しません。

サービスの IAM

Cloud Run は、リクエストごとに IAM チェックを実行します。

run.routes.invoke 権限を使用して、次の方法で Cloud Run サービスにアクセスできるユーザーを構成します。

  • サービス アカウントまたはグループを選択して、サービスへのアクセスを許可する権限を付与します。すべてのリクエストには、いずれかの承認済みサービス アカウント用に Google によって署名された OpenID Connect ID トークンを含む HTTP 認証ヘッダーが必要です。

  • 未承認のアクセスを許可するすべてのユーザーに権限を付与します。

組織のメンバーのみが Cloud Run サービスを呼び出すことができるように、組織管理者はドメイン制限付き共有の組織のポリシーを設定できます。組織管理者は特定の Cloud Run サービスをオプトアウトすることもできます。ドメインで制限された共有の適用時にパブリック Cloud Run サービスを作成する方法を確認してください。

認証の一般的なユースケースと、Cloud Run が IAM でアクセス制御を使用する方法を確認してください。

サービスのロードバランサのセキュリティ機能

Cloud Run サービスを Google Cloud ロードバランサのバックエンドとなるように構成した場合は、次の方法でこのパスを保護します。

  • いずれかの内部オプションに上り(内向き)を設定して、公共のインターネットから run.app URL への直接的なトラフィックをブロックします。
  • 必要に応じて、Google Cloud ArmorIAPSSL ポリシーなど、Google Cloud ロードバランサのセキュリティ機能を有効にできます。

ジョブの IAM

次のように、run.jobs.run 権限を使用して、Cloud Run ジョブを実行できるユーザーを構成します。

  • ジョブへのアクセスを許可するサービス アカウントまたはグループの選択権限を付与します。ジョブが Cloud Scheduler などの別のサービスによってトリガーされる場合は、使用されるサービス アカウントに対する run.jobs.run 権限が必要です。

  • Google Cloud コンソールからジョブを実行する権限をログイン ユーザーに付与します。ジョブが Cloud Scheduler などの別のサービスによってトリガーされる場合は、使用されるサービス アカウントまたはグループにジョブに対する run.jobs.run 権限が必要です。

組織のメンバーのみが Cloud Run ジョブを実行できるように、組織管理者はドメイン制限付き共有制約を設定できます。組織管理者は特定の Cloud Run ジョブをオプトアウトすることもできます。

VPC Service Controls

Cloud Run サービスを VPC Service Controls 境界の一部にすることができます。これにより、VPC Service Controls を利用してアクセスを制限し、流出リスクを軽減できます。VPC Service Controls の使用について詳しく説明します。

サプライ チェーン セキュリティ

Google Cloud の Buildpack マネージド ベースイメージ

Google Cloud の Buildpack を使用してソースコードからデプロイされるサービスは、Google が提供するベースイメージを使用してビルドされます。Google では、これらのベースイメージを維持し、定期的なパッチを毎週提供しています。重大なセキュリティ リスクを伴う緊急事態が発生した場合、Google は数時間以内にパッチを公開します。

Cloud Run 内部のサプライ チェーン セキュリティ

Cloud Run は Borg 上で動作するため、Gmail や YouTube など、すべての Google サービスで標準的に使用されているサプライ チェーンのセキュリティをすべて実装しています。Google 内部サプライ チェーンの実践について詳しくは、BeyondProdBinary Authorization for Borg のホワイトペーパーをご覧ください。

Binary Authorization

Cloud Run には Binary Authorization のサポートが組み込まれており、信頼できるコンテナ イメージのみが Cloud Run にデプロイされます。詳細については、Cloud Run の設定概要をご覧ください。

ソフトウェア デリバリー シールド

ソフトウェア デリバリー シールドを使用すると、Cloud 管理者は、デプロイされたコンテナのサプライ チェーンのセキュリティ情報を Google Cloud コンソールのパネルから直接表示できます。詳しくは、ソフトウェア デリバリー シールドの詳細を表示するをご覧ください。

次のステップ

ネットワークを設定する方法のエンドツーエンドのチュートリアルについては、Cloud Run のサーバーレス ネットワーキング ガイドをご覧ください。