기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
애플리케이션 로드 TLS 밸런서와의 상호 인증
상호 TLS 인증은 전송 계층 보안의 변형입니다 (TLS). 기존 TLS 방식에서는 서버와 클라이언트 간에 보안 통신을 설정하며, 이 경우 서버는 클라이언트에게 ID를 제공해야 합니다. 상호 통신을 TLS 사용하면 로드 밸런서가 클라이언트와 서버 간의 상호 인증을 협상하면서 협상합니다. TLS Application Load TLS Balancer와 함께 사용하면 인증 관리를 단순화하고 애플리케이션의 부하를 줄일 수 있습니다.
Application Load TLS Balancer와 상호 사용하면 로드 밸런서가 클라이언트 인증을 관리하여 신뢰할 수 있는 클라이언트만 백엔드 애플리케이션과 통신하도록 할 수 있습니다. 이 기능을 사용하면 Application Load Balancer는 타사 CA (인증 기관) 의 인증서를 사용하거나 () 를 사용하여 선택적으로 해지 검사를 통해 클라이언트를 인증합니다. AWS Private Certificate Authority PCA Application Load Balancer는 클라이언트 인증서 정보를 백엔드로 전달하여 애플리케이션이 권한 부여에 사용할 수 있습니다. Application Load TLS Balancer에서 상호 기능을 사용하면 기존 라이브러리를 사용하는 인증서 기반 엔티티에 대해 확장 가능한 내장형 관리형 인증을 얻을 수 있습니다.
뮤추얼 TLS 포 애플리케이션 로드 밸런서는 X.509v3 클라이언트 인증서를 검증하기 위한 다음 두 가지 옵션을 제공합니다.
참고: X.509v1 클라이언트 인증서는 지원되지 않습니다.
상호 TLS 패스스루: 상호 TLS 패스스루 모드를 사용하는 경우 Application Load Balancer는 헤더를 사용하여 전체 클라이언트 인증서 체인을 대상으로 보냅니다. HTTP 그런 다음 클라이언트 인증서 체인을 사용하여 애플리케이션에 해당 로드 밸런서 인증 및 대상 권한 부여 로직을 구현할 수 있습니다.
상호 TLS 확인: 상호 TLS 확인 모드를 사용하는 경우 Application Load Balancer는 로드 밸런서가 연결을 협상할 때 클라이언트에 대해 X.509 클라이언트 인증서 인증을 수행합니다. TLS
패스스루를 사용하여 Application Load TLS Balancer에서 상호 사용을 시작하려면 클라이언트의 인증서를 수락하도록 리스너를 구성하기만 하면 됩니다. TLS상호 검증을 사용하려면 다음을 수행해야 합니다.
새 신뢰 저장소 리소스를 생성합니다.
CA (인증 기관) 번들과 선택적으로 취소 목록을 업로드합니다.
클라이언트 인증서를 확인하도록 구성된 리스너에 신뢰 저장소를 연결합니다.
Application Load Balancer를 사용하여 상호 TLS 검증 모드를 구성하는 step-by-step 절차는 을 참조하십시오. Application Load TLS Balancer에서 상호 구성
애플리케이션 로드 밸런서에서 상호 TLS 구성을 시작하기 전에
Application Load TLS Balancer에서 상호 구성을 시작하기 전에 다음 사항에 유의하십시오.
- 할당량
애플리케이션 로드 밸런서에는 계정 내에서 사용 중인 신뢰 저장소, CA 인증서 및 인증서 취소 목록의 양과 관련된 특정 제한이 포함됩니다. AWS
자세한 내용은 애플리케이션 로드 밸런서의 할당량을 참조하십시오.
- 인증서 요구 사항
애플리케이션 로드 밸런서는 상호 TLS 인증에 사용되는 인증서에 대해 다음을 지원합니다.
지원되는 인증서: X.509v3
지원되는 공개 키: RSA 2K — 8K 또는 secp256r1, secp384r1, secp521r1 ECDSA
지원되는 서명 알고리즘:SHA256, 384, 512 (/포함), 384, 512 (EC 포함) /,384,512 해시 (- 포함) RSA SHA256 SHA256 RSASSA PSS MGF1
- CA 인증서 번들
다음은 인증 기관 (CA) 번들에 적용됩니다.
애플리케이션 로드 밸런서는 각 CA (인증 기관) 인증서 번들을 일괄적으로 업로드합니다. 애플리케이션 로드 밸런서는 개별 인증서 업로드를 지원하지 않습니다. 새 인증서를 추가해야 하는 경우 인증서 번들 파일을 업로드해야 합니다.
CA 인증서 번들을 교체하려면 를 사용하십시오 ModifyTrustStoreAPI.
- 패스스루를 위한 인증서 주문
상호 TLS 패스스루를 사용하는 경우 Application Load Balancer는 헤더를 삽입하여 클라이언트의 인증서 체인을 백엔드 대상에 제공합니다. 표시 순서는 리프 인증서에서 시작하여 루트 인증서로 끝납니다.
- 세션 재개
Application Load Balancer에서 상호 TLS 패스스루 또는 검증 모드를 사용하는 동안에는 세션 재개가 지원되지 않습니다.
- HTTP헤더
애플리케이션 로드 밸런서는 상호 연결을 사용하여 클라이언트 연결을 협상할 때
X-Amzn-Mtls헤더를 사용하여 인증서 정보를 전송합니다. TLS 자세한 내용 및 예제 헤더는 을 참조하십시오. HTTP헤더 및 상호 TLS- CA 인증서 파일
CA 인증서 파일은 다음 요구 사항을 충족해야 합니다.
인증서 파일은 PEM (프라이버시 강화 메일) 형식을 사용해야 합니다.
인증서 내용은
-----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 헤더에 대해 설명합니다. TLS Application Load Balancer에서 사용하는 특정 X-Amzn-Mtls 헤더는 지정한 TLS 상호 모드 (패스스루 모드 또는 검증 모드) 에 따라 달라집니다.
애플리케이션 로드 밸런서에서 지원하는 다른 HTTP 헤더에 대한 자세한 내용은 을 참조하십시오. HTTP헤더 및 애플리케이션 로드 밸런서
HTTP패스스루 모드용 헤더
상호 TLS 패스스루 모드의 경우 애플리케이션 로드 밸런서는 다음 헤더를 사용합니다.
이 헤더는 연결에 표시된 전체 클라이언트 인증서 체인의 URL -encoded 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 모드에서의 상호 호환을 위해 애플리케이션 로드 밸런서는 다음 헤더를 사용합니다.
이 헤더에는 리프 인증서 일련 번호를 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이 헤더에는 01 형식의 및 날짜가 포함되어 있습니다. ISO86 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-----%0A애플리케이션 로드 밸런서의 연결 로그
Elastic Load Balancing은 애플리케이션 로드 밸런서로 전송된 요청에 대한 속성을 캡처하는 연결 로그를 제공합니다. 연결 로그에는 클라이언트 IP 주소 및 포트, 클라이언트 인증서 정보, 연결 결과, 사용 중인 TLS 암호 등의 정보가 포함됩니다. 그런 다음 이러한 연결 로그를 사용하여 요청 패턴 및 기타 추세를 검토할 수 있습니다.
연결 로그에 대한 자세한 내용은 을 참조하십시오. Application Load Balancer의 연결 로그
