Application Load Balancer での TLS による相互認証
相互 TLS 認証は、Transport Layer Security (TLS) のバリエーションの 1 つです。従来の TLS はサーバーとクライアント間の安全な通信を確立するもので、サーバーはクライアントに自身の ID を提供する必要がありました。相互 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 は、ロードバランサーが TLS 接続をネゴシエートするときに、クライアントに対して X.509 クライアント証明書認証を実行します。
パススルーを使用して Application Load Balancer で相互 TLS を開始するための必要な手順は、クライアントから証明書を受け入れるようにリスナーを設定することだけです。検証で相互 TLS を使用するには、以下を実行する必要があります。
新しいトラストストアリソースを作成する。
認証局 (CA) バンドルと、オプションで失効リストをアップロードする。
クライアント証明書を検証するように設定されたリスナーにトラストストアをアタッチする。
Application Load Balancer で相互 TLS 検証モードを設定する手順については、「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-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 は、相互 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
このセクションでは、相互 TLS を使用してクライアントとの接続をネゴシエートするときに、Application Load Balancer が証明書情報を送信するために使用する HTTP ヘッダーについて説明します。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このヘッダーには、notBefore と notAfter 日付の ISO8601 形式が含まれています。
ヘッダーのコンテンツ例:
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-----%0AApplication Load Balancer の接続ログ
Elastic Load Balancing には、Application Load Balancer に送信されたリクエストに関する属性をキャプチャする、接続ログがあります。接続ログには、クライアントの IP アドレスとポート、クライアント証明書情報、接続結果、使用されている TLS 暗号などの情報が含まれています。これらの接続ログは、リクエストパターンやその他の傾向の確認に使用できます。
接続ログの詳細については、「Application Load Balancer の接続ログ」を参照してください。
