サービスのセキュリティ

このドキュメントでは、Cloud Service Mesh を使用したサービス セキュリティの概要について説明します。これは、デプロイメントに認証、暗号化、承認を追加する Cloud Service Mesh ユーザーを対象としています。このドキュメントは、Cloud Service Mesh の概要とプロキシレス gRPC アプリケーションについて十分理解していることを前提としています。

Cloud Service Mesh を使用すると、メッシュ内のサービス間の通信を保護できます。メッシュ内では、各サービスに ID が割り当てられています。次の機能は、安全な通信をサポートするのに役立ちます。

  • Envoy を使用する Cloud Service Mesh とプロキシレス gRPC アプリケーションを使用する Cloud Service Mesh の両方で、Transport Layer Security（TLS）と相互 TLS（mTLS）を使用する認証と暗号化。クライアント TLS ポリシーとサーバーの TLS ポリシーは、サービスが互いに ID を証明し、暗号化された通信チャネルを使用する必要があるかどうかを制御します。
  • クライアントとリクエストの特性に基づく認可。認可ポリシーは、サービスから別のサービスへのアクセスを許可するかどうか、および許可されるアクションを制御します。

プライベート認証局（CA）である Google の Certificate Authority Service によって提供される証明書と鍵を使用すると、サービスのセキュリティを容易に維持できます。CA Service は GKE メッシュ証明書を提供します。GKE メッシュ証明書機能と Cloud Service Mesh を使用すると、これらの証明書を自動的にデプロイしてワークロードで使用できるようになります。ワークロードで mTLS 認証情報を受信して使用できるように、Pod を修正します。Cloud Service Mesh サービスのセキュリティは、現在 GKE ベースのワークロードでのみ使用できます。

最新のマイクロサービス ベースのアーキテクチャでは、大規模なモノリシック アプリケーションが的を絞った小規模なサービスに置き換えられています。サービスの呼び出しは、ネットワークを介して相互に通信を行います。これらの呼び出しはモノリシック アプリケーションのインプロセス呼び出しであり、セキュリティ上の課題が発生するため、認証、暗号化、認可を行うことをおすすめします。これらの手順では、トラフィックがネットワーク内部または外部のいずれから発生するかを問わず、すべてのネットワーク トラフィックが危険にさらされていると仮定するゼロトラストの原則をサポートしています。

サービス メッシュ設計パターンは、サービス間通信に関連する複雑性をビジネス ロジックから分離します。代わりに、データプレーンがこの複雑さを処理します。サービス メッシュ設計パターンによって、アプリケーションの複雑性を軽減するのみでなく、この設計パターンを用いなければ実装と管理が困難であることが考えられるセキュリティ パターンを実現することもできます。

このモデルでは、プロキシレス gRPC または Envoy サイドカーが、Cloud Service Mesh から構成情報を取得することによる通信と、CA Service プールから取得した証明書を安全に認証し、暗号化します。

これらのセキュリティ機能により、以下の内容を実現することによって Cloud Service Mesh のデプロイ プロセスを簡易化できます。

  • メッシュ内のすべてのサービスへの鍵と証明書の自動プロビジョニング。
  • 鍵と証明書の自動ローテーションによるセキュリティの強化。
  • Google Kubernetes Engine（GKE）と統合した、デプロイ記述子やラベルなどのすべての機能の使用。
  • Cloud Service Mesh や CA Service が管理するプライベート認証局プールなど、Google マネージド サービスの高可用性。
  • Google Identity and Access Management（IAM）に関連付けられたセキュリティ: 認可済みの Google サービス アカウントに基づくサービス認証。
  • Envoy ベースのワークロードやプロキシレス ワークロードとのシームレスな相互運用性。とえば、サービスは Envoy プロキシの背後にある可能性がありますが、クライアントは gRPC プロキシレス サービス メッシュ セキュリティを使用します。逆に、サービスが gRPC プロキシレス サービス メッシュ セキュリティの背後にある可能性がありますが、クライアントは Envoy プロキシを使用します。

サービス間の通信を保護する

Cloud Service Mesh は、TLS を使用する認証と暗号化によりサービス間のセキュリティを提供します。クライアント TLS ポリシーとサーバー TLS ポリシーを使用すると、サービスで次のことが可能になります。

  • ID を表明して検証する。
  • TLS または mTLS を使用して通信セッションを暗号化する。

サービス メッシュでは、データプレーンがこのタイプのセキュリティを処理するため、アプリケーションを保護するために特別なプロビジョニングを行う必要はありません。

認可ポリシーを使用すると、定義したルールに従ってアクセスを拒否または許可できます。

暗号化に TLS を使用する

サービスが HTTP、HTTP/2、または gRPC プロトコルを使用して別のサービスを呼び出すと、ネットワークを経由するトラフィックは書式なしテキストになります。このトラフィックは中間者攻撃を受ける可能性があり、攻撃者がトラフィックを傍受して、内容を検査、または操作する可能性があります。

この潜在的な問題を軽減するには、Cloud Service Mesh で TLS を介して HTTP、HTTP/2、または gRPC を使用します。TLS を介してこれらのプロトコルを使用する場合、クライアントとサーバー間のトラフィックは、サーバーの証明書に基づく TLS を使用して暗号化されます。トラフィックは平文ではなくなり、攻撃者がコンテンツを傍受、検査、または操作する可能性が低減します。

認証に TLS を使用する

サービスが別のサービスを呼び出す場合は、次の点を考慮してください。

  • クライアントがなりすましではなく、正しいサーバーからレスポンスを受信していることをどのようにして確認しているのか。たとえば、HTTP に基づく一般的なリクエスト / レスポンスのインタラクション場合、クライアントはサーバーの ID を確認しません。

  • 攻撃者がそのトラフィックを傍受した場合、どうなるか。たとえば、HTTP トラフィックは暗号化されないため、トラフィックを受信した任意のユーザーがコンテンツを検査できます。これは「中間者攻撃」として知られています。

この問題を軽減するには、TLS を介して HTTP、HTTP/2、gRPC を使用します。クライアントとサーバー間のこうした交換では、サーバーがサーバー証明書を使用してクライアントに対する ID を証明する必要があります。リクエストとレスポンスは TLS を使用して暗号化されます。

相互 TLS 認証

Cloud Service Mesh がクライアントとサーバーの両方に対してアプリケーション ネットワーキングを構成する場合（たとえば、クライアントサイドで Envoy プロキシを構成し、サーバーサイドで別の Envoy プロキシを構成する場合）、相互認証などの高度な認証パターンを利用できます。

相互認証に基づいていない一般的な HTTP over TLS 交換では、サーバーには、クライアントとサーバーの間の通信の暗号化に使用する証明書があります。クライアントは、TLS handshake 中にサーバーが送り返す署名を確認することで、サーバーの ID を検証できます。ただし、サーバーはクライアントの ID を検証しません。

相互認証が有効になっている場合は、クライアントにも証明書があります。前の段落で説明したように、クライアントはサーバーの ID を検証し、サーバーもクライアントの ID を検証できます。クライアント証明書とサーバー証明書の両方が、通信チャネルを暗号化するために使用されます。また、これにより、サーバーが、検証済みのクライアント ID に基づいてクライアントを認可することもできます。

サービス メッシュでの相互 TLS（mTLS）認証。
サービス メッシュでの相互 TLS（mTLS）認証（クリックして拡大）

サービス呼び出しを認可する

サービスへのアクセスは、認可ポリシーを使用して、許可または拒否できます。Cloud Service Mesh を使用すると、リクエスト パラメータに基づいてアクセスを認可する許可ルールと拒否ルールを定義できます。これらのルールは、レイヤ 3 とレイヤ 7 のパラメータ（mTLS 接続の client-cert から派生したクライアント ID、送信元 IP アドレス、ホストの一致、メソッドの一致、ヘッダーの一致など）に基づいて作成できます。次の図では、Envoy プロキシを使用した認可を示します。このプロセスは gRPC クライアントと類似しています。

サービス メッシュでの認可。
Envoy を使用したサービス メッシュでの認可（クリックして拡大）

認可を使用してアクセスを制限する

サービス メッシュにおけるベスト プラクティスは、最小権限の原則に従うことです。この原則に従うには、サービスへのアクセスを、サービスに依存する呼び出し元のみに制限します。呼び出し元が認可されていないサービスにアクセスしようとすると、その試行は拒否されます。

Cloud Service Mesh を使用すると、定義したルールに基づいてデータプレーンがサービスへのアクセスを許可または拒否できる認可ポリシーを構成できます。これらのポリシーは、次の 2 つのコンポーネントで構成されます。

  • アクション: 許可または拒否
  • ルールのリスト

リクエストまたは RPC が送信されると、呼び出されたサービスの Cloud Service Mesh クライアントは、ルールとの一致があるかどうかを判断します。一致するものがある場合、そのリクエストや RPC は許可または拒否されます。たとえば、次のように属性の一致ルールを定義できます。

  • mTLS が使用されている場合、呼び出し元のサービスの Kubernetes サービス アカウント
  • 呼び出し元のサービスの IP アドレス（またはアドレス範囲）
  • 宛先サービスのポート
  • ホスト名、メソッド、ユーザー定義の HTTP ヘッダーなど、リクエストの HTTP 属性。

安全な命名

追加のセキュリティ メカニズムとして、Cloud Service Mesh を使用して安全な命名を構成できます。これにより、クライアントが接続しようとしている特定のサービスに対して許可された名前のリストまたは SPIFFE（Secure Production Identity Framework For Everyone）の ID を定義できます。TLS の交換中に、サービスのバックエンドはクライアントに X.509 証明書を返します。次に、クライアントは証明書を検査して、X.509 証明書が、名前 / SPIFFE ID のいずれかに一致していることを確認します。SPIFFE ID の詳細については、Secure Production Identity Framework for Everyone をご覧ください。

ゲートウェイでトラフィックを保護する

ゲートウェイを構成するには、Cloud Service Mesh を使用します。ゲートウェイはスタンドアロンの Envoy プロキシであり、通常は次のいずれかとして機能します。

  • メッシュ（または他のドメイン）に着信するトラフィックを処理する Ingress ゲートウェイ
  • メッシュ（または他のドメイン）を出るトラフィックを処理する Egress ゲートウェイ
  • 1 つ以上のサービスで受信トラフィックを分散するリバース プロキシまたは中間プロキシ

トラフィックをメッシュに送信する、またはメッシュから送信することを必要とするクライアントは、トラフィックをゲートウェイに送信します。ゲートウェイは、Cloud Service Mesh で設定したルールに従ってリクエストを処理します。たとえば、上り（内向き）ゲートウェイを介してメッシュに入るトラフィックを TLS を使用して暗号化する必要があります。

セキュリティ コンポーネント

Cloud Service Mesh サービスのセキュリティは、クライアント TLS ポリシー、サーバー TLS ポリシー、認可ポリシーをサポートしています。これらのポリシーを作成して、Cloud Service Mesh でデータプレーンを構成し、セキュリティ機能を有効にできるようにします。これらのポリシーを作成または更新するために、アプリケーションを変更する必要はありません。

暗号化モードとサポートされている認証モード

あるサービスで別のサービスを呼び出す際に、安全な通信を確立するための最初のステップは、各サービスが別のサービスに対して自身の ID を証明することです。サービスが ID を証明するために必要な度合いは、構成した TLS モードに基づきます。

次のセキュリティ レベルを構成できます。

  • 暗号化なし / 未認証
  • TLS
  • 相互 TLS（mTLS）
  • 制限なし: クライアントの接続開始方法に応じて、mTLS または暗号化なし / 未認証のいずれか

証明書と認証局

証明書と信頼できる認証局（CA）は、サービス メッシュなどの分散システムの信頼の基盤となります。サービスで証明書を使用すると、以下のように ID を証明し、提示される ID を検証できます。

  • あるサービスで自身の ID を別のサービスに対して証明する場合、その証明書が他のサービスに提示されます。両方のサービスが信頼する CA により、証明書の署名と証明書の発行が行われます。
  • この証明書を受信したサービスは、証明書が信頼する CA によって発行されたものであることを検証できます。

Cloud Service Mesh は認証局ではありません。安全な通信を有効にするには、次のメカニズムを設定する必要があります。

  • ID と証明書をプロビジョニングする
  • Cloud Service Mesh で構成された証明書を、Envoy プロキシなどの Cloud Service Mesh クライアントで使用可能にする

Cloud Service Mesh は Google の CA Service をサポートしています。この設定手順は、Envoy とプロキシレス gRPC の設定ガイドに記載されています（詳細については、次のステップをご覧ください）。

アーキテクチャとリソース

Cloud Service Mesh には Network Security API 名前空間が含まれ、この名前空間は 3 つの Google Cloud API リソースで構成されており、データプレーンに適用するセキュリティ ポリシーを指定できます。

メッシュ内では、クライアント TLS ポリシーとサーバー TLS ポリシーの 2 つの Google Cloud API リソースが認証をサポートします。3 つ目のリソースである認可ポリシーは認可をサポートします。

Network Services API 名前空間にはエンドポイント ポリシー リソースが含まれており、これによって Cloud Service Mesh で構成（サーバー TLS、クライアント TLS、認可ポリシー）をエンドポイントに提供できます。エンドポイントは、別の Cloud Service Mesh クライアントからのインバウンド通信を終端する Cloud Service Mesh クライアントです。

クライアント TLS ポリシー

クライアント TLS ポリシーを使用すると、データプレーンに適用されるクライアント側 TLS モードと証明書プロバイダ情報を指定できます。クライアント TLS ポリシーは、TLS 認証および mTLS 認証をサポートします。クライアント TLS ポリシーは、グローバル バックエンド サービス リソースに接続する必要があります。

TLS を構成するときは、serverValidationCa API フィールドを使用して、TLS 交換中にサーバーから受け取った証明書をクライアントの検証メカニズムを渡す必要があります。クライアントはこの情報を使用して、サーバー証明書の検証に使用できる検証証明書を取得します。

mTLS を構成する場合は、クライアントが clientCertificate API フィールドを使用して証明書と秘密鍵を取得するメカニズムも用意する必要があります。クライアントは、TLS handshake 中に、この情報を使用してサーバーに証明書を提示します。

このリリースでは、Cloud Service Mesh はマネージド認証局 CA Service をサポートしています。構成は容易に行うことができます。証明書プロバイダを構成する際に google_cloud_private_spiffe プラグイン名を指定します。これにより、xDS クライアントが静的ロケーションから証明書と鍵を読み込みます。前提条件として、CA Service プールを構成し、GKE クラスタでメッシュ証明書を有効にする必要があります。

サーバー TLS ポリシー

サーバー TLS ポリシー（ServerTlsPolicy リソース）を使用して、データプレーンに適用するサーバー側の TLS モードと証明書プロバイダ情報を指定できます。サーバー TLS ポリシーは、TLS、mTLS、Open_or_mTLS 認証のみをサポートしています。サーバー TLS ポリシーは、エンドポイント ポリシー リソースに接続します。

サブジェクトの代替名

グローバル バックエンド サービスの securitySettings フィールドを構成する場合は、subjectAltNames フィールドにサブジェクトの代替名のリストを指定できます。クライアントがサービスのバックエンドのいずれかを使用して TLS handshake を開始すると、サーバーは X.509 証明書を提示します。クライアントは証明書の subjectAltName フィールドを検査します。フィールドに指定された値のいずれかが含まれている場合は、通信が続行されます。このメカニズムについては、前述の安全な命名をご覧ください。

認可ポリシー

承認ポリシー（AuthorizationPolicy リソース）は、サーバーが受信リクエストまたは RPC を認可する方法を指定します。リクエストを送信したクライアントの ID、ホスト、ヘッダー、その他の HTTP 属性など、さまざまなパラメータに基づいて受信するリクエストや RPC を許可または拒否するように構成できます。認可ポリシーは、エンドポイント ポリシー リソースに接続します。

認可ポリシールールには次のコンポーネントがあります。

  • from: ルールで許可されるクライアントの ID を指定します。ID は、相互 TLS 接続のクライアント証明書から取得できます。また、サービス アカウントやセキュアタグなど、クライアント VM に関連付けられたアンビエント ID にすることもできます。
  • to: ルールで許可されるオペレーション（アクセス可能な URL や許可される HTTP メソッドなど）を指定します。
  • when: 遵守する必要のある追加の制約を定義できます。制約を定義するには、Common Expression Language（CEL）式を使用します。
  • action: ルールのアクションを指定します。ALLOW、DENY、CUSTOM のいずれかを指定できます。

制限事項

Cloud Service Mesh サービスのセキュリティは GKE でのみサポートされています。Compute Engine ではサービスのセキュリティをデプロイできません。

リクエストを評価するときに、認可ポリシーは次のいずれかのアクションを実行します。

  • ALLOW: リクエストが認可ポリシー内で定義されたルールと一致する場合、リクエストされたリソースへのアクセスを許可します。リクエストが認可ポリシー内で定義されたルールと一致しない場合、認可ポリシーはリクエストされたリソースへのアクセスをブロックします。リクエストが ALLOW ポリシーと一致しない場合、他のポリシーで許可されている場合でも、リクエストは拒否されます。

  • DENY: リクエストが DENY ポリシー内で指定されたいずれかのルールと一致する場合、リソースへのアクセスをブロックします。リクエストが認可ポリシー内で定義されたルールと一致しない場合、認可ポリシーはリクエストされたリソースへのアクセス権を付与します。リクエストが DENY ポリシーに一致する場合、他のポリシーで許可されている場合でも、リクエストは拒否されます。

  • CUSTOM（Cloud Service Mesh ではサポートされていません）: 複雑な認可の判断を行うために、外部認可システムとの統合を可能にします。CUSTOM アクションは、認可の決定にサービス拡張機能を使用するポリシーで使用されます。

認可ポリシーの評価順序

1 つのリソースに複数の認可ポリシーが関連付けられている場合、リクエストが許可されるか拒否されるかを判断するために、次の順序で評価されます。

  1. CUSTOM アクションを含むポリシー: CUSTOM ポリシーがリクエストを拒否すると、リクエストは直ちに拒否されます。DENY ポリシーまたは ALLOW ポリシーは、構成されている場合でも評価されません。

  2. DENY アクションを含むポリシー: DENY ポリシーがリクエストに一致すると、リクエストは拒否されます。ALLOW ポリシーは、構成されている場合でも評価されません。

  3. ALLOW アクションを含むポリシー: ALLOW ポリシーがない場合、または ALLOW ポリシーがリクエストと一致する場合、リクエストは許可されます。ただし、リクエストに一致する ALLOW ポリシーがない場合、リクエストは拒否されます。

プロキシレス gRPC アプリケーションの制限事項

プロキシレス gRPC サービスのサービス セキュリティには次の制限があります。

  • このリリースは Java、Python、C++、Go に限定されています。

AuthzPolicy の割り当て

  • ゲートウェイごとに使用できる承認ポリシーは合計 5 つまでです。
  • AuthzPolicy リソースは、プロジェクトごとに 20 個までです。
  • 1 つの AuthzPolicy は最大 100 個のゲートウェイを参照できます。

次のステップ