バックエンド認証 TLS とバックエンド mTLS の概要

ロードバランサが Google Cloud内のバックエンドに接続すると、ロードバランサはバックエンドに存在するすべての証明書を受け入れます。このような場合、ロードバランサは証明書の検証を行いません。

バックエンド認証 TLS またはバックエンド認証を使用すると、ロードバランサは接続先のバックエンドの ID を検証できます。バックエンド mTLS を使用すると、ロードバランサはクライアント TLS 証明書を使用して、バックエンドに ID を証明することもできます。

次の図は、フロントエンド mTLS とバックエンド mTLS の違いを示しています。各ケースでのロードバランサの役割に注目してください。フロントエンドの mTLS では、ロードバランサがサーバーとして機能し、クライアントの ID を検証します。バックエンド mTLS では、ロードバランサがクライアントとして機能し、バックエンドに ID を証明します。

フロントエンドとバックエンドの mTLS。
フロントエンドとバックエンドの mTL（クリックして拡大）

mTLS は、フロントエンドとバックエンドで独立して動作します。mTLS は、フロントエンド、バックエンド、またはフロントエンドとバックエンドの両方で構成できます。

このドキュメントでは、バックエンド認証 TLS とバックエンド mTLS の概要について説明します。フロントエンド mTLS の詳細については、相互 TLS の概要をご覧ください。

バックエンド認証 TLS とバックエンド mTLS は、グローバル外部アプリケーション ロードバランサのバックエンド サービス リソースで構成できます。

機能

mTLS は、公開鍵基盤（PKI）を使用して、ネットワーク経由で通信するエンティティの ID を認証します。このインフラストラクチャには、クライアント、サーバー、認証局（CA）の 3 つのコンポーネントが含まれています。バックエンド認証 TLS とバックエンド mTLS により、アプリケーション ロードバランサに次の機能が追加されます。

  • ロードバランサは、バックエンドから提示された証明書を独自のトラスト アンカーと照合して検証できます。複数の信頼アンカーをアップロードして、ダウンタイムなしで以前の PKI から新しい PKI にシームレスに移行できます。

  • ロードバランサは、バックエンドの TLS 証明書を公開ルート オブ トラスト（ウェブ PKI）と照合して検証できます。

  • 信頼アンカーに加えて中間証明書を構成すると、バックエンド証明書検証パスを構築できます。中間証明書を使用すると、バックエンド サーバーが完全な証明書チェーンを提供する必要がなくなります。

  • バックエンド サービスに TLS Server Name Indication（SNI）ホスト名を構成できます。TLS handshake 中に、ロードバランサはバックエンドに送信する ClientHello メッセージにこの SNI ホスト名を含めます。バックエンドは TLS 証明書で応答し、ロードバランサは、この証明書のサブジェクト代替名（SAN）フィールドの少なくとも 1 つが、ホスト名またはバックエンド サービス用に構成された SAN フィールドのいずれかと一致することを確認します。

  • ロードバランサがバックエンドに ID を証明できるように、mTLS を使用するようにロードバランサのバックエンド サービスを構成できます。この認証は、ロードバランサがバックエンドに提示するクライアント（ロードバランサ）証明書を使用して行われます。

証明書の要件

バックエンド認証 TLS とバックエンド mTLS の証明書を構成する場合は、次の要件を満たしていることを確認してください。

  • mTLS 認証の基盤となるのは最新の暗号化ツールです。証明書では、鍵交換に RSA または ECDSA アルゴリズムを使用する必要があります。ハッシュ化アルゴリズムでは、SHA-256 またはより強力な暗号ハッシュ関数を使用する必要があります。MD4、MD5、SHA-1 などのハッシュ化アルゴリズムはサポートされていません。

  • バックエンドから提供されるリーフ サーバー証明書には、次の要件があります。

    • 基本制約の拡張機能には CA=true を含めないでください。
    • 鍵の拡張的用途の拡張機能には、serverAuth を含める必要があります。
    • 鍵の拡張的用途の拡張機能には、codeSigning、timeStamping、OCSPSigning フィールドを含めないでください。
    • 証明書の有効期限が切れていないこと。

  • バックエンド mTLS で使用されるリーフ クライアント（ロードバランサ）証明書の場合、証明書は Certificate Manager 証明書リソースである必要があります。この証明書のスコープを client-auth にする必要があります。これは、この証明書がバックエンド mTLS でクライアント証明書として使用されることを示します。

    • 基本制約の拡張機能には CA=true を含めないでください。
    • 鍵の拡張的用途の拡張機能には、clientAuth を含める必要があります。
    • 鍵の拡張的用途の拡張機能には、codeSigning、timeStamping、OCSPSigning フィールドを含めないでください。
    • 証明書の有効期限が切れていないこと。

  • バックエンド認証 TLS で使用されるルート証明書と中間証明書には、次の要件があります。

    • 基本制約の拡張機能には CA=true を含める必要があります。
    • 鍵の使用の拡張機能は keyCertSign に設定する必要があります。
    • 鍵の拡張的用途の拡張機能には、serverAuth フィールドが含まれている必要があります。
    • 証明書の有効期限が切れていないこと。

バックエンド認証 TLS とバックエンド mTLS の主なコンポーネント

バックエンド認証 TLS を使用すると、ロードバランサは接続先のバックエンドの ID を確認できます。バックエンド サービス プロトコルとして HTTPS または HTTP/2 を使用する HTTP(S) ロードバランサで、バックエンド認証 TLS を構成できます。バックエンド認証 TLS を構成しない場合、ロードバランサはバックエンドからの証明書をすべて受け入れます。バックエンド mTLS を使用すると、独自のクライアント証明書をバックエンドに提示するようにロードバランサを構成できます。バックエンドは、この証明書を使用してロードバランサを認証できます。

バックエンド認証 TLS を構成するには、次の操作を行う必要があります。

  • 信頼構成リソースを作成します。
  • Backend Authentication Config リソースを作成します。
  • バックエンド サービスの TLS 設定属性を更新して、バックエンド認証構成リソースを参照します。

バックエンド mTLS を構成するには、クライアント証明書を作成し、クライアント証明書を Backend Authentication Config リソースに接続する必要があります。Backend Authentication Config リソースの作成後にクライアント証明書を接続することはできません。

次の図は、バックエンド認証 TLS とバックエンド mTLS を有効にする、アプリケーション ロードバランサのバックエンド サービスに接続されているさまざまなコンポーネントを示しています。

バックエンド認証 TLS コンポーネントとバックエンド mTLS コンポーネント。
バックエンド認証 TLS コンポーネントとバックエンド mTLS コンポーネント（クリックして拡大）

以降では、バックエンド認証 TLS とバックエンド mTLS の構成に使用されるこれらのコンポーネントの概要について説明します。

信頼構成

バックエンドがロードバランサに提示するサーバー証明書を認証するには、バックエンドの証明書の発行元との信頼チェーンを確立する X.509 証明書を使用してロードバランサを構成する必要があります。信頼構成は、信頼構成全体を表し、単一のトラストストアを含む TrustConfig リソースを使用して構成します。

トラストストアは、トラスト アンカー（ルート証明書）と、必要に応じて 1 つ以上の中間証明書をカプセル化します。トラスト アンカーは、ルート オブ トラストを表す証明書です。有効なサーバー証明書には、トラストストア内のトラスト アンカーに至る信頼チェーンが含まれている必要があります。

中間証明書は、トラストストア内のトラスト アンカーにつながる信頼チェーンの一部である証明書です。これは、リーフ証明書に含まれる追加の中間 CA とともに、検証プロセス中に信頼チェーンを構築するために使用されます。中間証明書の作成は省略可能です。

自己署名証明書、期限切れの証明書、指定された信頼ルートにチェーンされていない証明書、検証に失敗した証明書を使用する必要がある場合は、そのような証明書を信頼構成の許可リストに追加できます。許可リストに追加できる自己署名証明書を作成することもできます。

信頼チェーンの検証に必要なのは証明書のみであるため、トラストストアには秘密鍵は含まれません。

バックエンド認証構成リソース

ロードバランサのバックエンド サービスに接続されたバックエンド認証構成（BackendAuthenticationConfig）リソースにより、次が可能になります。

  • バックエンド認証 TLS（信頼構成と公開ルートを使用）
  • バックエンド mTLS（クライアント証明書を使用）

バックエンド認証 TLS とバックエンド mTLS を有効にするには、バックエンド認証構成リソースが次のリソースを参照するようにします。

  • 信頼構成（trustConfig）: バックエンドから提供されたサーバー証明書の検証に使用される、接続された信頼構成。

  • パブリック ルート信頼（wellKnownRoots）: ロードバランサが、信頼構成で信頼されている証明書に加えて、パブリック CA によって発行されたバックエンド サーバー証明書を信頼するかどうかを示します。詳細については、公開信頼ルートの使用をご覧ください。

  • クライアント証明書（clientCertificate）: バックエンドへの接続で mTLS を使用する場合、ロードバランサがバックエンドに ID を示すために使用するクライアント証明書。バックエンド認証 TLS（バックエンド認証）の場合、このフィールドは空にできます。この場合、ロードバランサはバックエンドに対してのみバックエンドを認証し、バックエンドに対して自身を認証しません。

バックエンド サービス

バックエンド サービス内で、tlsSettings 属性はバックエンド証明書を検証するために次のリソースを参照します。

  • バックエンド認証構成（authenticationConfig）
  • SNI ホスト名（sni）
  • 使用できる SAN（subjectAltNames）

tlsSettings 属性の SNI（sni）フィールドと SAN（subjectAltNames）フィールドは、証明書の SAN 値に基づいてロードバランサがバックエンドの証明書を検証する方法を制御します。これらのフィールドは、バックエンド認証 TLS が構成されているかどうかに関係なく、検証プロセスに影響します。

SNI フィールドが設定されている場合（tlsSettings.sni）、ロードバランサは次の処理を行います。

  • TLS handshake 中に SNI ホスト名をバックエンド サーバーに送信します。
  • バックエンドの TLS 証明書に SNI ホスト名と一致する SAN が含まれていることを確認します。

デフォルトでは、ロードバランサは、バックエンドの TLS 証明書に SNI ホスト名と一致する SAN が含まれていることを確認します。ただし、バックエンド サービス（tlsSettings.subjectAltNames）に SAN が構成されている場合、ロードバランサは次の処理を行います。

  • SAN の検証で SNI ホスト名を無視します。
  • バックエンドの TLS 証明書に、バックエンド サービスで構成された承認済みの SAN（subjectAltNames）のいずれかに一致する SAN が含まれていることを確認します。

クライアント証明書

バックエンド認証 TLS（バックエンド認証）に加えて、ロードバランサがバックエンドに ID を証明できるように、mTLS を使用するようにロードバランサのバックエンド サービスを構成できます。この認証では、ロードバランサがバックエンドに提示するクライアント（ロードバランサ）証明書を使用します。

バックエンド mTLS を構成するには、次の操作を行う必要があります。

  • クライアント（ロードバランサ）証明書とその秘密鍵を含むクライアント証明書リソースを作成します。
  • クライアント証明書を Backend Authentication Config リソースに接続します。

バックエンド mTLS は、Certificate Manager でマネージド証明書を構成する場合、Compute Engine マネージド ワークロード ID とも互換性があります。公開 PKI マネージド証明書はサポートされていません。すべてのクライアント証明書に client-auth スコープが設定され、証明書の要件を満たしている必要があります。

バックエンドがクライアント証明書をリクエストする場合は、クライアント証明書を受け入れるように構成する必要があります。バックエンドがロードバランサの接続を拒否した場合、ロードバランサはプロキシしているリクエストに対して HTTP 502 ステータス コードを返します。また、一般的なステータスを Cloud Logging にログに記録します。

ロードバランサでバックエンド認証 TLS とバックエンド mTLS を構成する

バックエンド認証 TLS とバックエンド mTLS は、非公開の PKI または公開ルート オブ トラストを使用してロードバランサで構成できます。

プライベート PKI を使用する

プライベート PKI から発行された証明書を使用して、ロードバランサでバックエンド認証 TLS とバックエンド mTLS を構成するために必要な主な手順の概要は次のとおりです。限定公開 PKI には、完全に制御でき、公共のインターネットの PKI システムから分離されているという利点があります。

  1. トラスト アンカー（ルート証明書）とルート オブ トラストとして機能する中間証明書を含む信頼構成リソースを作成します。

  2. バックエンド mTLS を構成するには、クライアント（ロードバランサ）証明書とその秘密鍵を含むクライアント証明書を作成します。

  3. 信頼構成を参照する Backend Authentication Config リソースを作成します。バックエンド mTLS を構成する場合、バックエンド認証構成リソースは信頼構成とクライアント証明書の両方を参照します。

  4. バックエンド認証構成リソースをロードバランサのバックエンド サービスに接続します。

この設定の詳細については、次のガイドをご覧ください。

公開ルート オブ トラストを使用する

バックエンド認証 TLS を有効にするためにプライベート PKI から発行された証明書を使用するだけでなく、公開ルート信頼を使用してバックエンド証明書を検証することもできます。

公開ルート オブ トラストを使用するには、信頼構成を作成してバックエンド認証構成リソースに接続する必要はありません。代わりに、Backend Authentication Config リソースの wellKnownRoots フィールドに値として PUBLIC_ROOTS を設定する必要があります。ただし、信頼構成で信頼されている証明書に加えて、一般公開されている証明書のルートを明示的に含める信頼構成を作成することもできます。

PUBLIC_ROOTS 設定では、ブラウザで信頼されているルート CA のセットと同様に、Google によって管理され、時間の経過とともに変更される一連のルート CA が使用されます。これにより、これらのルートが変わったときにバックエンド証明書が無効になるリスクがあります。一般公開されている証明書を検証する必要がある場合は、確立された信頼できる CA を選択することを検討してください。また、中間クロス署名を使用してバックエンド証明書を発行する CA を選択して、ルート証明書の有効期限切れや取り消しのリスクを軽減します。

サーバー証明書の検証手順

バックエンド認証 TLS またはバックエンド認証中にサーバー証明書を検証するときに、ロードバランサは次の処理を行います。

  1. サーバーが証明書の秘密鍵を所有していることを確認する。

    サーバーは、秘密鍵を使用して情報に署名し、CertificateVerify メッセージの一部としてロードバランサに送信することで、ロードバランサに提示する証明書に関連付けられた秘密鍵を保持していることを証明します。ロードバランサは、サーバーの証明書の公開鍵を使用してこの署名を検証します。署名の検証に失敗した場合は、バックエンド サーバーが証明書に対応する秘密鍵を保持していないことを示します。この場合、ロードバランサはエラーをログに記録せずに TLS handshake を終了します。

  2. 信頼チェーンを検証する。

    信頼構成にトラスト アンカーが 1 つ以上含まれている場合、または wellKnownRoots 属性が PUBLIC_ROOTS に設定されている場合、ロードバランサはサーバー証明書と構成済みのトラスト アンカー間の信頼チェーンの検証を試みます。次のことが検証されます。

    • バックエンドのサーバー証明書、中間証明書（指定されている場合）、構成済みのルート証明書が証明書の要件を満たしている。
    • 信頼チェーン内のすべての証明書で、親証明書のサブジェクト フィールドが子証明書の発行元フィールドと一致している。この検証により、親証明書の ID（サブジェクト）が、子証明書の発行者としてリストされている ID と一致することが確認されます。
    • 信頼チェーン内のすべての証明書について、親証明書のサブジェクト鍵 ID（SKID）が子証明書の認証機関鍵 ID（AKID）と一致している。この一致は、子証明書が正しいルート認証局によって発行されており、証明書の有効性を検証するために AKID でルートの公開鍵が参照されているため、信頼できることを意味します。

  3. バックエンドとの接続を確立します。

    証明書の検証に成功すると、ロードバランサはバックエンドへの接続を続行します。

    ただし、証明書の検証が失敗した場合、ロードバランサはバックエンドへの接続を終了し、HTTP 502 ステータス コードをクライアントに送信し、終了理由を Cloud Logging にログに記録します。証明書の検証エラーが発生すると、その後の受信リクエストによってロードバランサがトリガーされ、バックエンド接続が再開されます。

    バックエンド サーバーが接続を拒否した場合、バックエンド接続に失敗することもあります。バックエンド mTLS では、クライアント証明書が無効であることが検出されたために、このエラーが発生することがあります。バックエンドへの接続に失敗すると、ロードバランサはプロキシされたリクエストに HTTP 502 ステータス コードで応答し、汎用のエラー理由を Cloud Logging にロギングします。

制限事項

  • バックエンド認証 TLS とバックエンド mTLS は、グローバル外部アプリケーション ロードバランサでのみ構成できます。従来のアプリケーション ロードバランサは、バックエンド認証 TLS とバックエンド mTLS をサポートしていません。

  • バックエンド認証 TLS とバックエンド mTLS は、次のバックエンド タイプではサポートされていません。

    • グローバル インターネット NEG バックエンド

    • App Engine バックエンド

  • バックエンド mTLS を有効にするには、バックエンド認証 TLS も構成する必要があります。

  • バックエンド mTLS を有効にする場合は、バックエンド認証構成リソースを構成する前にクライアント証明書を作成する必要があります。

  • バックエンドで使用されるヘルスチェックは、TLS 認証や mTLS 機能を実装していません。HTTP または HTTPS リクエストに応答できるヘルスチェック エンドポイントを使用してバックエンドを構成する必要があります。

  • ロードバランサは、バックエンドに接続するときに、フロントエンド TLS 接続からクライアントの SNI ホスト名を渡しません。ただし、バックエンドはカスタム リクエスト ヘッダーを使用してクライアントの SNI ホスト名にアクセスできます。

  • バックエンド mTLS の場合、クライアント証明書の鍵は次のものに制限されます。

    • RSA 鍵の長さは 2,048～4,096 ビットです。
    • ECDSA 鍵では、P-256 または P-384 曲線を使用できます。

  • バックエンド認証 TLS は、証明書の失効チェックをサポートしていません。

割り当てと上限

  • 1 つのトラストストアには、トラスト アンカーと中間証明書を合わせて最大 200 個保持できます。中間証明書には個別の上限が 100 個あります。同じサブジェクトとサブジェクトの公開鍵情報を共有できる中間証明書は 3 つまでです。

  • 証明書チェーンの最大深度は、ルート証明書とリーフ証明書を含めて 10 個の証明書です。信頼チェーンを構築する際に評価できる中間証明書の最大数は 100 です。

  • バックエンド認証 TLS では、バックエンドから受信する証明書チェーンは 16 KB 以下、10 個の証明書に制限されます。

  • 検証に使用するルート証明書には、10 個を超える名前の制約を含めることはできません。

  • tlsSettings.subjectAltNames[] フィールドで許可されるサブジェクトの代替名の最大数は 5 です。

次のステップ