Application Load Balancer에서 TLS를 사용한 상호 인증
상호 TLS 인증은 Transport Layer Security(TLS)의 변형입니다. 기존 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 클라이언트 인증서를 검증하기 위한 다음 두 가지 옵션을 제공합니다.
참고: 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 인증서 및 인증서 해지 목록의 수와 관련된 특정 제한이 포함됩니다.
자세한 내용은 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는 상호 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
이 섹션에서는 Application Load Balancer가 상호 TLS를 사용하여 클라이언트와의 연결을 협상할 때 인증서 정보를 보내는 데 사용하는 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의 연결 로그 섹션을 참조하세요.
