翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
TLS Network Load Balancer のリスナー
TLS リスナーを使用するには、ロードバランサーに少なくとも 1 つのサーバー証明書をデプロイする必要があります。ロードバランサーはサーバー証明書を使用してフロントエンド接続を終了してから、ターゲットにリクエストを送信する前に、クライアントからのリクエストを復号します。ロードバランサーが復号化せずに暗号化されたトラフィックをターゲットに渡す必要がある場合は、TCPリスナーを作成する代わりに、ポート 443 にTLSリスナーを作成します。ロードバランサーは、リクエストを復号化せずにそのままの状態でターゲットに渡します。
Elastic Load Balancing TLS は、セキュリティポリシーと呼ばれるネゴシエーション設定を使用して、クライアントとロードバランサー間のTLS接続をネゴシエートします。セキュリティポリシーはプロトコルと暗号の組み合わせです。プロトコルは、クライアントとサーバーの間の安全な接続を確立し、クライアントとロードバランサーの間で受け渡しされるすべてのデータのプライバシーを保証します。暗号とは、暗号化キーを使用してコード化されたメッセージを作成する暗号化アルゴリズムです。プロトコルは、複数の暗号を使用し、インターネットを介してデータを暗号化します。接続ネゴシエーションのプロセスで、クライアントとロードバランサーでは、それぞれサポートされる暗号とプロトコルのリストが優先される順に表示されます。サーバーのリストで最初にクライアントの暗号と一致した暗号が安全な接続用に選択されます。
Network Load Balancer はTLS、再ネゴシエーションまたは相互TLS認証 (m) をサポートしていませんTLS。mTLS サポートの場合は、TCPリスナーの代わりにTLSリスナーを作成します。ロードバランサーはリクエストをそのまま渡すため、ターゲットに mTLS を実装できます。
TLS リスナーを作成するには、「」を参照してくださいリスナーの追加。関連するデモについては、TLS「Network Load Balancer のサポート
サーバー証明書
ロードバランサーには X.509 証明書 (サーバー証明書) が必要です。証明書とは、認証機関 (CA) によって発行された識別用デジタル形式です。証明書には、認識用情報、有効期間、パブリックキー、シリアル番号と発行者のデジタル署名が含まれます。
ロードバランサーで使用する証明書を作成するときに、ドメイン名を指定する必要があります。TLS 接続を検証できるように、証明書のドメイン名はカスタムドメイン名レコードと一致する必要があります。一致しない場合、トラフィックは暗号化されません。
証明書には、 などの完全修飾ドメイン名 (FQDN)、www.example.com
または などの apex ドメイン名を指定する必要がありますexample.com
。また、同じドメインで複数のサイト名を保護するために、アスタリスク (*) をワイルドカードとして使用できます。ワイルドカード証明書をリクエストする場合、アスタリスク (*) はドメイン名の一番左の位置に付ける必要があり、1 つのサブドメインレベルのみを保護できます。例えば、*.example.com
は corp.example.com
、images.example.com
を保護しますが、test.login.example.com
を保護することはできません。また、*.example.com
は、example.com
のサブドメインのみを保護し、ネイキッドドメインまたは apex ドメイン (example.com
) は保護しないことに注意してください。ワイルドカード名は、証明書の [サブジェクト] フィールドと [サブジェクト代替名] 拡張子に表示されます。公開証明書の詳細については、AWS Certificate Manager ユーザーガイドの「公開証明書」を参照してください。
AWS Certificate Manager (ACM)
または、TLSツールを使用して証明書署名リクエストを作成し (CSR)、CA によってCSR署名された を取得して証明書を生成し、証明書を にインポートACMするか、 AWS Identity and Access Management () にアップロードすることもできますIAM。詳細については、「 AWS Certificate Manager ユーザーガイド」の「証明書のインポート」または「 ユーザーガイド」の「サーバー証明書の使用」を参照してください。 IAM
サポートされているキーアルゴリズム
RSA 1024 ビット
RSA 2048 ビット
RSA 3072 ビット
ECDSA 256 ビット
ECDSA 384 ビット
ECDSA 521 ビット
デフォルトの証明書
TLS リスナーを作成するときは、証明書を 1 つだけ指定する必要があります。この証明書は、default certificate として知られています。TLS リスナーを作成した後、デフォルトの証明書を置き換えることができます。詳細については、「デフォルトの証明書の置き換え」を参照してください。
証明書リスト で追加の証明書を指定する場合、デフォルトの証明書は、クライアントが Server Name Indication (SNI) プロトコルを使用してホスト名を指定せずに接続する場合、または証明書リストに一致する証明書がない場合にのみ使用されます。
追加の証明書を指定せずに、単一のロードバランサーを介して複数の安全なアプリケーションをホストする必要がある場合は、ワイルドカード証明書を使用するか、追加のドメインごとにサブジェクト代替名 (SAN) を証明書に追加できます。
証明書リスト
TLS リスナーを作成すると、デフォルトの証明書と空の証明書リストが作成されます。リスナーの証明書リストに証明書を追加することもできます。証明書リストを使用すると、ロードバランサーは同じポートで複数のドメインをサポートし、ドメインごとに異なる証明書を提供できます。詳細については、「証明書リストに証明書を追加する」を参照してください。
ロードバランサーは、 をサポートするスマート証明書選択アルゴリズムを使用しますSNI。クライアントから提供されたホスト名が証明書リスト内の単一の証明書と一致する場合、ロードバランサーはこの証明書を選択します。クライアントが提供するホスト名が証明書リストの複数の証明書と一致する場合、ロードバランサーはクライアントがサポートできる最適な証明書を選択します。証明書の選択は、次の条件と順序に基づいて行われます。
-
ハッシュアルゴリズム ( SHAよりも優先MD5)
-
キーの長さ (最大が優先)
-
有効期間
ロードバランサーアクセスログエントリは、クライアントが指定したホスト名とクライアントが提出する証明書を示します。詳細については、「アクセスログのエントリ」を参照してください。
証明書の更新
各証明書には有効期間が記載されています。有効期間が終了する前に、必ずロードバランサーの各証明書を更新するか、置き換える必要があります。これには、デフォルトの証明書と証明書リスト内の証明書が含まれます。証明書を更新または置き換えしても、ロードバランサーノードが受信し、正常なターゲットへのルーティングを保留中の未処理のリクエストには影響しません。証明書更新後、新しいリクエストは更新された証明書を使用します。証明書置き換え後、新しいリクエストは新しい証明書を使用します。
証明書の更新と置き換えは次のとおりに管理できます。
-
によって提供され AWS Certificate Manager 、ロードバランサーにデプロイされた証明書は、自動的に更新できます。ACM は有効期限が切れる前に証明書を更新しようとします。詳細については、AWS Certificate Manager ユーザーガイドの 管理された更新 を参照してください。
-
証明書を にインポートした場合はACM、証明書の有効期限をモニタリングし、有効期限が切れる前に更新する必要があります。詳細については、AWS Certificate Manager ユーザーガイドの 証明書のインポート を参照してください。
-
証明書を にインポートした場合はIAM、新しい証明書を作成し、新しい証明書を ACMまたは にインポートしIAM、新しい証明書をロードバランサーに追加して、期限切れの証明書をロードバランサーから削除する必要があります。
セキュリティポリシー
TLS リスナーを作成するときは、セキュリティポリシーを選択する必要があります。必要に応じてセキュリティポリシーを更新できます。詳細については、「セキュリティポリシーの更新」を参照してください。
考慮事項:
-
ELBSecurityPolicy-TLS13-1-2-2021-06
ポリシーは、 を使用して作成されたTLSリスナーのデフォルトのセキュリティポリシーです AWS Management Console。-
1.3 を含み、1.TLS2 TLS と下位互換性がある
ELBSecurityPolicy-TLS13-1-2-2021-06
セキュリティポリシーをお勧めします。
-
-
ELBSecurityPolicy-2016-08
ポリシーは、 を使用して作成されたTLSリスナーのデフォルトのセキュリティポリシーです AWS CLI。 -
フロントエンド接続に使用されるセキュリティポリシーを選択できますが、バックエンド接続には選択できません。
-
バックエンド接続の場合、TLSリスナーが TLS 1.3 セキュリティポリシーを使用している場合は、
ELBSecurityPolicy-TLS13-1-0-2021-06
セキュリティポリシーが使用されます。それ以外の場合、バックエンド接続にはELBSecurityPolicy-2016-08
セキュリティポリシーが使用されます。
-
-
特定のTLSプロトコルバージョンの無効化を必要とするコンプライアンスおよびセキュリティ標準を満たすため、または非推奨の暗号を必要とするレガシークライアントをサポートするには、いずれかの
ELBSecurityPolicy-TLS-
セキュリティポリシーを使用できます。Network Load Balancer に送信されたTLSリクエストに関する情報のアクセスログを有効にしたり、TLSトラフィックパターンを分析したり、セキュリティポリシーのアップグレードを管理したり、問題をトラブルシューティングしたりできます。ロードバランサーのアクセスログを有効にし、対応するアクセスログエントリを調べます。詳細については、「アクセスログ」および「Network Load Balancer のクエリ例」を参照してください。 -
AWS アカウント および AWS Organizations のサービスコントロールポリシー (SCPs) でそれぞれ Elastic Load Balancing 条件キーを使用することで、 IAMおよび 全体のユーザーが利用できるセキュリティポリシーを制限できます。詳細については、「 ユーザーガイド」の「サービスコントロールポリシー (SCPs)AWS Organizations 」を参照してください。
TLS 1.3 セキュリティポリシー
Elastic Load Balancing では、Network Load Balancer TLS に次の 1.3 セキュリティポリシーが用意されています。
-
ELBSecurityPolicy-TLS13-1-2-2021-06
(推奨) -
ELBSecurityPolicy-TLS13-1-2-Res-2021-06
-
ELBSecurityPolicy-TLS13-1-2-Ext1-2021-06
-
ELBSecurityPolicy-TLS13-1-2-Ext2-2021-06
-
ELBSecurityPolicy-TLS13-1-1-2021-06
-
ELBSecurityPolicy-TLS13-1-0-2021-06
-
ELBSecurityPolicy-TLS13-1-3-2021-06
FIPS セキュリティポリシー
連邦情報処理規格 (FIPS) は、機密情報を保護する暗号化モジュールのセキュリティ要件を指定する米国およびカナダ政府の規格です。詳細については、 AWS クラウドセキュリティコンプライアンスページの「連邦情報処理規格 (FIPS) 140
すべてのFIPSポリシーは、AWS-LC FIPS検証済み暗号化モジュールを活用します。詳細については、暗号化モジュール検証プログラムサイトの AWS-LC
Elastic Load Balancing では、Network Load Balancer に次のFIPSセキュリティポリシーが用意されています。
-
ELBSecurityPolicy-TLS13-1-3-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Res-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04
(推奨) -
ELBSecurityPolicy-TLS13-1-2-Ext0-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Ext1-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-2-Ext2-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-1-FIPS-2023-04
-
ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04
FS がサポートするポリシー
Elastic Load Balancing では、Network Load Balancer に対して次の FS (フォワードシークレット) がサポートするセキュリティポリシーが用意されています。
-
ELBSecurityPolicy-FS-1-2-Res-2020-10
-
ELBSecurityPolicy-FS-1-2-Res-2019-08
-
ELBSecurityPolicy-FS-1-2-2019-08
-
ELBSecurityPolicy-FS-1-1-2019-08
-
ELBSecurityPolicy-FS-2018-06
TLS 1.0~1.2 セキュリティポリシー
Elastic Load Balancing TLS では、Network Load Balancer に次の 1.0~1.2 セキュリティポリシーが用意されています。
-
ELBSecurityPolicy-TLS-1-2-Ext-2018-06
-
ELBSecurityPolicy-TLS-1-2-2017-01
-
ELBSecurityPolicy-TLS-1-1-2017-01
-
ELBSecurityPolicy-2016-08
-
ELBSecurityPolicy-TLS-1-0-2015-04
-
ELBSecurityPolicy-2015-05
( と同じELBSecurityPolicy-2016-08
)
TLS プロトコルと暗号
ALPN ポリシー
Application-Layer Protocol Negotiation (ALPN) は、最初のTLSハンドシェイク hello メッセージで送信されるTLS拡張機能です。ALPN を使用すると、アプリケーションレイヤーは HTTP/1 や /HTTP2 などの安全な接続でどのプロトコルを使用するかをネゴシエートできます。
クライアントがALPN接続を開始すると、ロードバランサーはクライアントALPN設定リストをALPNポリシーと比較します。クライアントがALPNポリシーからのプロトコルをサポートしている場合、ロードバランサーはALPNポリシーのプリファレンスリストに基づいて接続を確立します。それ以外の場合、ロードバランサーは を使用しませんALPN。
サポートされているALPNポリシー
サポートされているALPNポリシーは次のとおりです。
HTTP1Only
-
HTTP/1.* のみをネゴシエートします。ALPN プリファレンスリストは http/1.1、http/1.0 です。
HTTP2Only
-
HTTP/2 のみをネゴシエートします。ALPN プリファレンスリストは h2 です。
HTTP2Optional
-
HTTP/2 よりも HTTP/1.* を優先します (HTTP/2 テストに便利です)。ALPN プリファレンスリストは http/1.1、http/1.0、h2 です。
HTTP2Preferred
-
HTTP/1.* よりも HTTP/2 を優先します。ALPN プリファレンスリストは h2、http/1.1、http/1.0 です。
None
-
をネゴシエートしないでくださいALPN。これがデフォルトです。
ALPN 接続を有効にする
TLS リスナーを作成または変更するときにALPN接続を有効にできます。詳細については、「リスナーの追加」および「ALPN ポリシーを更新する」を参照してください。