翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Application Load Balancer での TLS による相互認証
相互TLS認証は、トランスポートレイヤーセキュリティ (TLS) のバリエーションです。従来の TLS は、サーバーとクライアント間の安全な通信を確立します。サーバーはクライアントにアイデンティティを提供する必要があります。相互 TLS では、ロードバランサーは TLS のネゴシエート中にクライアントとサーバー間の相互認証をネゴシエートします。Application Load Balancer で相互 TLS を使用すると、認証管理が簡素化され、アプリケーションの負荷が軽減されます。
Application Load Balancer で相互 TLS を使用することで、ロードバランサーはクライアント認証を管理して、信頼できるクライアントのみがバックエンドアプリケーションと通信できるようにします。この機能を使用すると、Application Load Balancer は、サードパーティー認証局 (CA) からの証明書を使用するか、必要に応じて失効チェックで AWS Private Certificate Authority （PCA) を使用してクライアントを認証します。Application Load Balancer はクライアント証明書情報をバックエンドに渡し、アプリケーションはこれを認証に使用できます。Application Load Balancer で相互 TLS を使用すると、確立されたライブラリを使用する証明書ベースのエンティティに対して、組み込みのスケーラブルなマネージド認証を取得できます。
Application Load Balancer の相互TLSには、X.509v3 クライアント証明書を検証するための次の 2 つのオプションがあります。
注: X.509v1 クライアント証明書はサポートされていません。
相互TLSパススルー： 相互TLSパススルーモードを使用すると、Application Load Balancer は HTTP ヘッダーを使用してクライアント証明書チェーン全体をターゲットに送信します。次に、このクライアント証明書チェーンを使用して、ロードバランサー認証とターゲット認証の対応するロジックをアプリケーションに実装できます。
相互TLS検証： 相互TLS検証モードを使用すると、ロードApplication Load Balancer はクライアントに対して X.509 クライアント証明書認証を実行します。 TLS
パススルーを使用して Application Load Balancer で相互 TLS の使用を開始するには、クライアントからの証明書を受け入れるようにリスナーを設定するだけで済みます。検証で相互TLSを使用するには、以下を実行する必要があります。
新しいトラストストアリソースを作成する。
認証局 (CA) バンドルと、オプションで失効リストをアップロードする。
クライアント証明書を検証するように設定されたリスナーにトラストストアをアタッチする。
Application Load Balancer で相互 TLS 検証モードを設定する step-by-step の手順については、「」を参照してくださいApplication Load Balancer での相互 TLS の設定。
Application Load Balancer で相互TLSの設定を開始する前に
Application Load Balancer で相互 TLS の設定を開始する前に、次の点に注意してください。
- クォータ
Application Load Balancer には、 AWS アカウント内で使用されている信頼ストア、CA 証明書、および証明書失効リストの量に関連する特定の制限が含まれています。
詳細については、「Quotas for your Application Load Balancers」を参照してください。
- 証明書の要件
Application Load Balancer は、相互 TLS 認証で使用される証明書について以下をサポートしています。
サポートされている証明書: X.509v3
サポートされているパブリックキー: RSA 2K – 8K または ECDSA secp256r1、secp384r1、secp521r1
サポートされている署名アルゴリズム: SHA256、384、512 with RSA/SHA256, 384, 512 with EC/SHA256、384、512 hash with RSASSA with PSS MGF1
- CA 証明書のバンドル
以下は、認証局 (CA) バンドルに適用されます。
Application Load Balancer は、各認証局 (CA) 証明書バンドルをバッチでアップロードします。Application Load Balancer は、個々の証明書のアップロードはサポートしていません。新しい証明書を追加する必要がある場合は、証明書のバンドルファイルをアップロードする必要があります。
CA 証明書バンドルを置き換えるには、ModifyTrustStore API。
- パススルーの証明書の順序
相互 TLS パススルーを使用すると、Application Load Balancer はヘッダーを挿入して、クライアント証明書チェーンをバックエンドターゲットに提示します。プレゼンテーションの順序は、リーフ証明書から始まりルート証明書で終わります。
- セッションの再開
Application Load Balancer で相互 TLS パススルーモードまたは検証モードを使用している間は、セッションの再開はサポートされていません。
- HTTP ヘッダー
Application Load Balancer は、相互 TLS を使用してクライアント接続をネゴシエートするときに、
X-Amzn-Mtlsヘッダーを使用して証明書情報を送信します。詳細およびヘッダーの例については、「HTTPヘッダーと相互TLS」を参照してください。- CA 証明書ファイル
CA 証明書ファイルは以下の要件を満たす必要があります。
証明書ファイルには PEM (Privacy Enhanced Mail) 形式を使用する必要があります。
証明書の中身は
-----BEGIN CERTIFICATE-----と-----END CERTIFICATE-----の境界で囲む。コメントは先頭に
#を付け、-を含めない。空白の行は使用できない。
受け入れられない証明書の例 (無効):
# comments Certificate: Data: Version: 3 (0x2) Serial Number: 01 Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Validity Not Before: Jan 11 23:57:57 2024 GMT Not After : Jan 10 00:57:57 2029 GMT Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 00:01:02:03:04:05:06:07:08 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 00:01:02:03:04:05:06:07:08 X509v3 Subject Alternative Name: URI:EXAMPLE.COM Signature Algorithm: ecdsa-with-SHA384 00:01:02:03:04:05:06:07:08 -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----受け入れられる証明書の例 (有効):
-
単一の証明書 (PEMエンコード):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -
複数の証明書 (PEMエンコード):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- # comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----
HTTPヘッダーと相互TLS
このセクションでは、相互 HTTP を使用してクライアントとの接続をネゴシエートするときに、Application Load Balancer が証明書情報を送信するために使用する TLS ヘッダーについて説明します。Application Load Balancer が使用する特定のX-Amzn-Mtlsヘッダーは、指定した相互 TLS モードによって異なります。パススルーモードまたは検証モード。
Application Load Balancer でサポートされている他の HTTP ヘッダーについては、「」を参照してくださいHTTP ヘッダーと Application Load Balancer。
パススルーモードの HTTP ヘッダー
パススルーモードの相互TLSの場合、Application Load Balancer は次のヘッダーを使用します。
このヘッダーには、接続に表示されるクライアント証明書チェーン全体の URL エンコードされた PEM 形式が含まれ、安全文字+=/として が使用されます。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0A検証モードの HTTP ヘッダー
検証モードの相互TLSの場合、Application Load Balancer は次のヘッダーを使用します。
このヘッダーには、リーフ証明書のシリアル番号の 16 進数表現が含まれています。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1このヘッダーには、発行者の識別名 (DN) の RFC2253 文字列表現が含まれています。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=USこのヘッダーには、サブジェクトの識別名 (DN) の RFC2253 文字列表現が含まれています。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=USこのヘッダーには、ISO8601 形式の notBeforeとnotAfter日付が含まれています。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Zこのヘッダーには、安全文字+=/として、リーフ証明書の URL エンコードされた PEM 形式が含まれています。
ヘッダーのコンテンツ例:
X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0AAdvertise Certificate Authority (CA) のサブジェクト名
Certificate Authority (CA) のサブジェクト名は、相互 TLS 認証中に受け入れられる証明書をクライアントが判断できるようにすることで、認証プロセスを強化します。
Advertise CA サブジェクト名を有効にすると、Application Load Balancer は、関連付けられている信頼ストアに基づいて、信頼する認証局 (CAs) サブジェクト名のリストをアドバタイズします。クライアントが Application Load Balancer を介してターゲットに接続すると、クライアントは信頼できる CA サブジェクト名のリストを受け取ります。
TLS ハンドシェイク中に、Application Load Balancer がクライアント証明書をリクエストすると、証明書リクエストメッセージに信頼できる CA 識別名 (DNs) のリストが含まれます。これにより、クライアントはアドバタイズされた CA サブジェクト名に一致する有効な証明書を選択し、認証プロセスを合理化して接続エラーを減らすことができます。
新規および既存のリスナーで、Advertise CA サブジェクト名を有効にできます。詳細については、「HTTPS リスナーを追加する」を参照してください。
Application Load Balancer の接続ログ
Elastic Load Balancing には、Application Load Balancer に送信されたリクエストに関する属性をキャプチャする、接続ログがあります。接続ログには、クライアントの IP アドレスとポート、クライアント証明書情報、接続結果、使用されている TLS 暗号などの情報が含まれます。これらの接続ログは、リクエストパターンやその他の傾向の確認に使用できます。
接続ログの詳細については、「Application Load Balancer の接続ログ」を参照してください。
