AWS 기술 블로그
애플리케이션 로드 밸런서를 위한 mTLS 소개
이 글은 AWS Networking & Content Delivery Blog에 게시된 Introduction mTLS for Application Load Balancer by Ankit Chadha, James Wenzel, and William Wang 을 한국어 번역 및 편집하였습니다.
AWS는 최근 애플리케이션 로드 밸런서(ALB)에 X509 인증서를 제시하는 클라이언트를 상호 인증하는 기능을 지원한다고 발표했습니다. 이 블로그에서는 이 새로운 기능을 구현하기 위한 옵션과 구현 시 고려해야 할 사항에 대해 설명합니다.
ALB는 애플리케이션 계층(OSI 모델에서는 계층 7)에서 작동하며 백엔드 대상으로 수신되는 HTTP/HTTPS 요청의 부하를 분산합니다. 이는 일반적으로 확장 가능하고 안전한 웹 애플리케이션을 만드는 데 사용되며 호스트 이름, URI 전체 경로 또는 HTTP 헤더 조건에 따른 경로와 같은 애플리케이션 속성을 기반으로 부하를 분산할 수 있는 고급 라우팅 규칙을 지원합니다. 자세한 내용은 애플리케이션 로드 밸런서 설명서를 참조하세요.
보안 관점에서 ALB를 사용하면 HTTPS 리스너를 생성할 수 있습니다. HTTPS 리스너를 사용하면 ALB에서 클라이언트의 TLS 세션을 종료합니다. 또한 ALB는 AWS WAF와 기본 통합되어 있어 웹 애플리케이션에 대한 규칙을 생성하고 ALB 뒤에서 실행되는 애플리케이션을 보호할 수 있습니다.
mTLS 컨셉
상호 전송 계층 보안(mTLS)은 네트워크 통신을 보호하는 데 사용되는 TLS 프로토콜을 확장한 것입니다. TLS는 일반적으로 인터넷을 통해 보안 연결을 설정하고 인증, 데이터 기밀성 및 무결성을 보장하는 데 사용됩니다. 하지만 기존 TLS에서는 서버가 클라이언트에 대해 자신을 인증하는 일방적인 인증으로, 클라이언트의 신원은 확인되지 않습니다.
이와는 대조적으로 mTLS는 서버와 클라이언트가 서로를 인증하도록 요구하여 보안 계층을 추가하므로 “상호” 또는 “양방향” TLS라고 부릅니다. mTLS와 관련된 몇 가지 개념은 다음과 같습니다:
- 인증 기관(CA): 비즈니스에 TLS 인증서를 제공하는 조직/기업입니다. CA는 TLS 인증서를 발급하기 전에 도메인 이름 및 소유자 상세 정보를 확인합니다.
- TLS 인증서: 시스템(웹 클라이언트 등)이 다른 시스템(웹 서버 등)의 신원을 확인할 수 있도록 하는 디지털 개체입니다. TLS 인증서의 세부 정보를 통해 클라이언트는 서버에 암호화된 연결을 설정할 수 있습니다.
- 서버 인증서: 서버의 신원을 증명하는 TLS 인증서입니다.
- 클라이언트 인증서: 클라이언트의 신원을 증명하는 TLS 인증서입니다.
- 인증서 신뢰 체인: TLS 인증서의 정렬된 목록입니다. 체인은 왼쪽의 인증서(또는 클라이언트/서버의 TLS 인증서)로 시작하여 루트 인증서로 끝납니다. 리프 인증서와 루트 인증서 사이의 모든 인증서를 중간 인증서라고 합니다. 체인의 각 인증서는 다음 인증서에 의해 식별된 조직/기업이 서명합니다. 이는 그림 1에 나와 있습니다.
그림 1: 인증서 신뢰 체인
- TLS 핸드셰이크: 클라이언트와 서버가 TLS 인증서를 사용하여 서로를 인증하고 암호화 표준에 동의하며 데이터를 전송할 수 있는 보안 채널을 만드는 프로세스입니다. 자세한 내용은 TLS 설명서를 참조하세요. 클라이언트는 TLS 핸드셰이크 중에 TLS 인증서를 서버와 공유합니다. 이를 통해 서버는 클라이언트를 인증할 수 있습니다.
- 인증서 해지 목록(CRL): 신뢰해서는 안 되는 차단 목록에 있는 인증서 목록입니다.
mTLS 프로세스는 일반적으로 스마트 디바이스, API, 마이크로서비스 간의 통신을 보호하는 데 사용되며, 규제 요건을 충족하는 등 양 당사자가 서로의 신원에 대한 신뢰를 구축해야 하는 모든 상황에서 사용됩니다. 또한 가상 사설망(VPN)과 조직 내 내부 통신 보안을 위해서도 사용됩니다.
mTLS를 구현하려면 서버와 클라이언트 모두 신뢰할 수 있는 CA에서 발급한 디지털 인증서를 가지고 있어야 합니다. 이러한 인증서는 동일하거나 다른 CA로 부터 생성할 수 있으며 핸드셰이크 프로세스 중에 각 당사자의 신원을 증명하는 데 사용됩니다.
애플리케이션 로드 밸런서로 mTLS 클라이언트 인증 사용하기
애플리케이션 로드 밸런서는 클라이언트의 인증서 체인이 특정 깊이나 크기 이내일 때 mTLS를 지원합니다. 현재 지원되는 최대 크기 및 깊이를 확인하려면 애플리케이션 로드 밸런서에 대한 할당량 설명서를 확인 하십시오. Amazon CloudWatch 에서 애플리케이션 로드 밸런서의 ClientCertExceedsDepthLimit 및 ClientCertExceedsSizeLimit 메트릭을 각각 사용하여 이러한 제한을 위반하는 모든 요청을 추적할 수 있습니다.
애플리케이션 로드 밸런서는 mTLS에서 mTLS 확인 모드와 mTLS 패스스루 모드의 두 가지 작동 모드를 지원합니다.
mTLS 확인 모드
애플리케이션 로드 밸런서에서 mTLS 확인 모드를 사용하려면 신뢰 저장소를 만들어야 합니다. 신뢰 저장소에는 클라이언트 인증서를 확인하는 데 사용되는 하나의 CA 인증서 번들이 있습니다. 자체 인증서를 가져오거나 AWS Certificate Manager(ACM)를 사용하여 인증서를 생성할 수 있습니다. 애플리케이션 로드 밸런서와 함께 mTLS 확인 모드에 AWS 관리형 CA를 사용할 수 있습니다. AWS Private Certificate Authority 는 조직이 사설 인증서를 사용하여 애플리케이션과 기기를 보호할 수 있도록 지원하는 고가용성 관리형 CA 서비스입니다. 자세한 내용은 인증서 발급 및 관리에 대한 ACM 설명서를 참조하세요.
신뢰하지 않을 클라이언트 인증서를 지정하려면 하나 이상의 인증서 해지 목록(CRL)을 신뢰 저장소와 연결합니다. 해지 목록을 S3 버킷에 업로드하고 신뢰 저장소에서 해당 버킷을 지정합니다. ALB는 S3에서 CRL을 가져오며 모든 CRL 확인은 매번 S3에서 CRL을 가져오지 않고 ALB에서 수행합니다. 따라서 ALB는 CRL에 대해 클라이언트를 인증하는 동안 지연 시간이 추가되지 않습니다. CRL 설정에 대한 자세한 내용은 설명서에서 애플리케이션 로드 밸런서에서 TLS를 사용한 상호 인증 페이지를 확인하세요.
이 모드에서 애플리케이션 로드 밸런서는 신뢰 저장소를 사용하여 클라이언트 인증서를 확인합니다. 이렇게 하면 유효한 인증서로 인증된 클라이언트만 백엔드 대상과 통신할 수 있습니다. ALB는 인증되지 않은 사용자의 요청을 차단합니다. 이를 통해 mTLS 인증에 필요한 컴퓨팅 집약적인 처리를 애플리케이션 로드 밸런서로 분담하고 백엔드 대상의 처리 리소스를 애플리케이션의 서비스 제공에 사용할 수 있습니다. 그림 2는 확인 모드의 아키텍처를 보여줍니다.
그림 2: 애플리케이션 로드 밸런서가 mTLS 확인 모드로 구성
ALB의 확인 모드에서 mTLS의 단계는 다음과 같습니다:
[1] Amazon S3에 CA 인증서 번들을 업로드하고 선택적으로 CRL을 업로드합니다.
[2] 신뢰 저장소를 만들고 CA 인증서 번들에 대한 Amazon S3 경로를 입력합니다. 선택적으로 CRL에 대한 Amazon S3 경로를 입력합니다.
[3] 클라이언트가 ALB와 TLS 세션을 시작합니다. TLS 핸드셰이크 중에 클라이언트가 TLS 인증서를 제시합니다.
[4] TLS 세션이 ALB에서 종료됩니다. TLS 핸드셰이크 중에 ALB는 서버 측 인증서를 제시하고 클라이언트의 인증서를 받습니다.
[5] ALB는 신뢰 저장소를 참조하고 인증서의 유효성을 검사합니다. 클라이언트 인증서가 신뢰할 수 있는 CA에서 서명하지 않은 경우, 인증서가 인증서 해지 목록(CRL)에 포함된 경우 또는 클라이언트 인증서가 만료된 경우 클라이언트 인증은 실패합니다. 애플리케이션 로드 밸런서의 mTLS 확인 모드에서 클라이언트 인증이 실패할 수 있는 전체 시나리오 목록은 애플리케이션 로드 밸런서에서 TLS를 사용한 상호 인증 페이지의 설명서를 참조하세요. 클라이언트 인증에 실패하면 애플리케이션 로드 밸런서는 TLS 연결을 거부합니다. 만료된 인증서의 경우, 선택적으로 이러한 연결을 허용하도록 ALB를 구성할 수 있습니다.
[6] 클라이언트와 ALB 간에 TLS 세션이 성공적으로 설정되었습니다.
[7] ALB가 백엔드 대상에 대해 별도의 세션을 생성합니다.
애플리케이션 로드 밸런서가 TLS 세션을 종료하므로 백엔드 대상에 대한 트래픽 부하 분산에 원하는 ALB의 라우팅 알고리즘을 사용할 수 있습니다. 예를 들어 가중치 기반 라운드 로빈 규칙을 사용하여 웹 애플리케이션의 블루/그린 배포를 생성할 수 있습니다.
애플리케이션 로드 밸런서는 클라이언트 인증을 수행하는 것 외에도 다음 인증서 메타데이터를 백엔드 대상에 보냅니다:
X-Amzn-Mtls-Clientcert-Serial-Number – 리프 인증서 또는 클라이언트 인증서, 일련 번호의 16진수 표현(예: 0ABC1234)
X-Amzn-Mtls-Clientcert-Issuer – X509_NAME_print_ex로 기재된, XN_FLAG_RFC2253 플래그를 포함한 발급자 distinguished name(DN)
X-Amzn-Mtls-Clientcert-Subject – X509_NAME_print_ex 및 XN_FLAG_RFC2253 플래그와 함께 기재된 Subject DN
X-Amzn-Mtls-Clientcert-Validity – notBefore 및 notAfter 날짜의 ISO8601 형식(예: NotBefore=2023-09-21T01:50:17Z; NotAfter=2024-09-20T01:50:17Z)
X-Amzn-Mtls-Clientcert-Leaf – 리프 인증서의 URL 인코딩된 PEM 형식.
이 정보를 사용하면 백엔드 대상에서 이러한 메타데이터 필드를 기반으로 로직을 구현할 수 있습니다. 예를 들어 X-Amzn-Mtls-Clientcert-Leaf 필드를 파싱하여 인증서의 만료 날짜를 가져와서 인증서의 만료 날짜가 가까워지면 클라이언트에 사용자 지정 메시지를 보낼 수 있습니다.
mTLS 패스스루 모드
이 모드에서 ALB는 전체 인증서 체인을 클라이언트 인증을 위한 백엔드 대상에 AMZN-MTLS-CLIENT-CERT라는 HTTP 헤더로 전달합니다. ALB는 리프 인증서를 포함한 전체 인증서 체인을 +, = 및 /를 안전 문자로 사용하여 URL 인코딩된 PEM 형식으로 삽입합니다. 다음은 AMZN-MTLS-CLIENT-CERT 헤더의 예입니다:
X-Amzn-Mtls-Clientcert:
백엔드 대상은 이 HTTP 헤더를 파싱하고 인증서를 추출하여 클라이언트 인증을 수행할 수 있어야 합니다. 클라이언트 인증 프로세스에 대한 제어를 유지하려면 이 모드를 사용합니다. 그림 3은 이 아키텍처를 보여줍니다.
그림 3: 애플리케이션 로드 밸런서가 mTLS 패스스루 모드로 구성
ALB의 패스스루 모드에서 mTLS의 단계는 다음과 같습니다:
[1] 클라이언트가 ALB와 TLS 세션을 시작합니다. TLS 핸드셰이크 중에 클라이언트가 TLS 인증서를 제시합니다.
[2] TLS 세션이 ALB에서 종료됩니다. TLS 핸드셰이크 중에 ALB는 서버 측 인증서를 제시하고 클라이언트의 인증서를 받습니다.
[3] ALB는 백엔드 타깃과 새 세션을 만듭니다. 이 세션은 사용자 구성에 따라 HTTP 또는 HTTPS가 될 수 있습니다. ALB는 전체 인증서 체인을 AMZN-MTLS-CLIENT-CERT라는 HTTP 헤더에 포함합니다.
[4] 백엔드 대상은 클라이언트 인증서를 수신하고 AMZN-MTLS-CLIENT-CERT HTTP 헤더에서 클라이언트 인증서 체인을 파싱하는 로직을 구현해야 합니다. 백엔드 대상은 또한 클라이언트 인증을 수행하는 로직을 구현해야 합니다.
mTLS 패스스루 모드가 활성화되어 있을 때 클라이언트 인증서가 없는 경우, 애플리케이션 로드 밸런서는 추가적인 HTTP 헤더를 추가하지 않습니다. 백엔드 대상은 클라이언트 인증서 없이 들어오는 요청을 처리하는 로직을 구현해야 합니다. AWS CloudWatch에서 애플리케이션 로드 밸런서의 MTLSPassthroughCertNotPresent 메트릭을 사용하여 클라이언트 인증서 없이 들어온 요청 수를 확인할 수 있습니다.
백엔드 대상에서 클라이언트 인증이 실패하면 대상은 HTTP 오류 코드를 애플리케이션 로드 밸런서에 다시 전송해야 합니다. ALB는 이 오류 코드를 클라이언트에 다시 전달합니다.
HTTPS 리스너의 경우, 백엔드 대상은 인증서를 기반으로 클라이언트를 인증하고, 애플리케이션 로드 밸런서는 클라이언트 간의 TLS 연결을 종료하고 백엔드 대상과 다른 TLS 세션을 엽니다. ALB와 백엔드 대상 간의 TLS 세션은 대상에 설치한 인증서를 사용하여 생성됩니다.
ALB가 TLS 세션을 종료하므로 백엔드 대상에 대한 트래픽 부하 분산을 위해 ALB의 라우팅 알고리즘을 사용할 수 있습니다.
일시적으로 인터넷 연결이 끊긴 스마트 자동차처럼 일부 스마트 디바이스는 장시간 오프라인 상태일 수 있습니다. 이러한 경우 백엔드 대상이 만료된 TLS 인증서를 사용하는 로직을 구현해야 합니다.
애플리케이션 기반 쿠키를 구현하는 것도 패스스루 모드를 구현하는 또 다른 사용 사례입니다. 이 사용 사례에서는 백엔드 대상이 인증된 클라이언트에 대한 쿠키를 발급하고 클라이언트는 이 쿠키를 통신에 사용할 수 있습니다. 이렇게 하면 백엔드 대상이 들어오는 각 요청에 대해 전체 인증서 체인을 처리할 필요가 없습니다. 오픈 소스 라이브러리를 사용하여 백엔드 대상에 쿠키를 구현한 다음 쿠키를 기반으로 클라이언트 인증 상태를 추적하는 로직을 구현할 수 있습니다.
모니터링
애플리케이션 로드 밸런서는 로드 밸런서로 전송되는 모든 요청에 대한 연결 로그를 제공합니다. 이러한 로그는 Amazon Simple Storage Service(Amazon S3) 버킷으로 전송되며 클라이언트의 IP 주소, TLS 암호에 대한 세부 정보, 요청이 거부된 경우의 오류 코드 등의 세부 정보를 포함합니다. 자세한 내용은 애플리케이션 로드 밸런서의 연결 로그를 참조하세요.
애플리케이션 로드 밸런서의 mTLS 지원에 대한 CloudWatch 메트릭의 전체 목록은 애플리케이션 로드 밸런서에 대한 CloudWatch 메트릭에서 확인할 수 있습니다.
ALB의 mTLS 모드와 네트워크 로드 밸런서(NLB) 비교
HTTPS 애플리케이션을 사용할때 애플리케이션 수준 라우팅을 수행하려는 경우 ALB 사용을 고려하는 것이 좋습니다. 예를 들어, HTTPS 요청에 대해 가중치 기반 라운드 로빈 부하 분산을 수행하면 블루/그린 스타일 배포를 만들 수 있습니다. 또한 ALB를 사용하면 TLS/mTLS 작업을 분담할 수 있습니다. ALB는 클라이언트의 TLS 세션을 종료하기 때문에 ALB에 클라이언트 인증서를 업로드해야 합니다.
반면 NLB는 전송 계층(OSI 모델의 레이어 4)에서 작동하며 TCP/UDP 연결의 지연 시간이 짧은 부하 분산 기능을 제공합니다. HTTPS 애플리케이션의 경우, 대상 서버에서 클라이언트의 TLS 연결을 종료해야 하는 특정 보안 규정 준수 규칙이 있는 경우 네트워크 로드 밸런서(NLB)를 사용하는 것이 좋습니다.
다음의 표는 애플리케이션 로드 밸런서와 NLB의 패스스루 모드 및 확인 모드 지원과 각 옵션에 대한 고려 사항을 비교한 것입니다.
| ALB + mTLS 확인모드 | ALB + mTLS 패스스루모드 | NLB | |
| 클라이언트 인증 | ALB에서 수행,AWS에서 관리 | 백엔드 대상에 의해 수행되고 고객이 관리 | 백엔드 대상에 의해 수행되고 고객이 관리 |
| 클라이언트의 SSL/TLS 세션 종료 | ALB에서 수행, AWS에서 관리 | ALB에서 수행, AWS에서 관리 | 백엔드 대상에서 수행, 고객이 관리 |
| 라우팅 규칙 기능 | ALB의 애플리케이션 수준 라우팅 규칙 | ALB의 애플리케이션 수준 라우팅 규칙 | NLB의 포트와 프로토콜 기반 라우팅 규칙 |
마무리
이 블로그에서는 애플리케이션 로드 밸런서의 mTLS 확인 및 패스스루 모드와 각 모드를 사용할 때 고려해야 할 사항에 대해 설명했습니다. 클라이언트 인증에 ALB를 사용하려는 경우 애플리케이션 로드 밸런서에서 mTLS 확인 모드를 사용합니다. 백엔드 대상에서 클라이언트 인증을 계속 제어하려는 경우 mTLS 패스스루 모드가 가장 적합합니다. 신뢰 저장소를 사용하는 데는 추가 요금이 부과되며, mTLS를 활성화할 때 애플리케이션 로드 밸런서의 비용을 고려해야 합니다. 자세한 내용은 Elastic Load Balancing 요금제 페이지를 참조하세요.
이 기능은 지금 바로 사용하실 수 있으니 사용해 보시고 질문이나 의견이 있으시면 AWS 지원팀에 알려주세요.