翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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で mutual を使用すると、確立されたライブラリを使用する証明書ベースのエンティティに対して、組み込みのスケーラブルなマネージド認証を取得できます。
Mutual TLS for Application Load Balancer には、X.509v3 クライアント証明書を検証するための次の 2 つのオプションが用意されています。
注： X.509v1 クライアント証明書はサポートされていません。
相互TLSパススルー： 相互TLSパススルーモードを使用すると、Application Load Balancer はHTTPヘッダーを使用してクライアント証明書チェーン全体をターゲットに送信します。次に、クライアント証明書チェーンを使用して、対応するロードバランサー認証とターゲット認証ロジックをアプリケーションに実装できます。
相互TLS検証： 相互TLS検証モードを使用すると、ロードバランサーが接続をネゴシエートするときに、Application Load Balancer はクライアントの X.509 クライアント証明書認証を実行します。 TLS
パススルーを使用して Application Load Balancer TLSで mutual の使用を開始するには、クライアントからの証明書を受け入れるようにリスナーを設定するだけで済みます。相互TLS検証を使用するには、以下を実行する必要があります。
新しい信頼ストアリソースを作成します。
認証局 (CA) バンドルをアップロードし、オプションで失効リストをアップロードします。
クライアント証明書を検証するように設定されたリスナーに信頼ストアをアタッチします。
Application Load Balancer で相互TLS検証モードを設定する step-by-step 手順については、「」を参照してくださいApplication Load Balancer TLSでの相互 の設定。 Application Load Balancer
Application Load Balancer TLSで相互 の設定を開始する前に
Application Load Balancer TLSで mutual の設定を開始する前に、次の点に注意してください。
- クォータ
Application Load Balancer には、 AWS アカウント内で使用されている信頼ストア、CA 証明書、および証明書失効リストの量に関連する特定の制限が含まれています。
詳細については、「Application Load Balancer のクォータ」を参照してください。
- 証明書の要件
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-PSS with 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 は、相互 を使用してクライアント接続をネゴシエートするときに、
X-Amzn-Mtlsヘッダーを使用して証明書情報を送信しますTLS。ヘッダーの詳細と例については、「」を参照してください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
このセクションでは、相互 を使用してクライアントとの接続をネゴシエートするときに Application Load Balancer が証明書情報を送信するために使用するHTTPヘッダーについて説明します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-----%0AHTTP 検証モードの ヘッダー
相互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このヘッダーには、 notBeforeおよび notAfter日付の ISO8601 形式が含まれます。
ヘッダーの内容の例：
X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Zこのヘッダーには、安全文字+=/として PEM でURLエンコードされた形式のリーフ証明書が含まれています。
ヘッダーの内容例：
X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0AApplication Load Balancer の接続ログ
Elastic Load Balancing は、Application Load Balancer に送信されたリクエストに関する属性をキャプチャする接続ログを提供します。接続ログには、クライアントの IP アドレスとポート、クライアント証明書情報、接続結果、使用されているTLS暗号などの情報が含まれます。これらの接続ログを使用して、リクエストパターンやその他の傾向を確認できます。
接続ログの詳細については、「」を参照してください。 Application Load Balancer の接続ログ
