Category: AWS Certificate Manager*


애플리케이션 로드 밸런서(ALB) 기반 서버 이름별(SNI) 다중 TLS 인증서 지원

오늘부터 우리는 애플리케이션 로드 밸런서(ALB)에서 서버 이름 표시(SNI)를 사용해 다중 TLS/SSL 인증서 지원을 시작합니다. 이제 단일 로드 밸런서 뒤에서 각각 자체 TLS 인증서를 갖는 다수의 TLS 보안 애플리케이션을 호스팅할 수 있습니다. SNI는 로드 밸런서에서 동일한 보안 리스너로 다수의 인증서를 바인딩하기만 하면 사용할 수 있습니다. 그러면 ALB가 각 클라이언트마다 최적의TLS 인증서를 자동으로 선택합니다. 이러한 새로운 기능은 추가 요금 없이 제공됩니다.

새로운 기능의 사용 방법에 대한 TL;DR을 찾고 있다면 여기를 클릭하십시오. 저처럼 TLS(Transport Layer Security)에 대해서 약간 서툴다고 생각한다면 아래 이어지는 내용까지 계속해서 읽어주십시오.

TLS? SSL? SNI?

SSL과 TLS는 기술적으로 약간 다르기는 하지만 동일한 용어로 사용되는 경우가 많습니다. 기술적인 측면에서 SSL은 TLS 프로토콜의 이전 형태라고 할 수 있습니다. 하지만 쉽게 이해할 수 있도록 이번 포스트에서는 TLS라는 용어를 사용하겠습니다.

TLS는 암호, 쿠키, 신용 카드 번호 같은 데이터를 안전하게 전송하기 위한 프로토콜입니다. 이를 위해 전송되는 데이터의 프라이버시, 인증 및 무결성을 지원합니다. TLS는 인증서 기반 인증 방식을 사용합니다. 여기에서 인증서는 웹사이트에서 ID 카드와 같은 역할을 합니다. 즉 인증서에 서명하여 발급하는 사람, 즉 인증 기관(CA)을 신뢰하기 때문에 인증서 데이터의 정확성까지 신뢰하게 됩니다. 브라우저가 TLS를 지원하는 ALB에 연결되면 ALB가 사이트의 공개 키가 포함된 인증서를 제출합니다. 이 공개 키에는 CA의 서명이 암호화되어 있습니다. 이러한 방식으로 클라이언트는 실제 서버라는 사실을 신뢰하고 사이트의 공개 키를 사용하여 안전하게 연결을 구성합니다.

SNI 지원이 시작되면서 이제는 동일한 ALB에 인증서를 1개 이상 쉽게 사용할 수 있게 되었습니다. 다수의 인증서가 필요한 가장 공통적인 이유는 동일한 로드 밸런서로 여러 도메인을 처리해야 하기 때문입니다. ALB에 와일드카드 인증서와 SAN(Subject-Alternate-Name) 인증서를 사용하는 것은 항상 가능했지만 몇 가지 제약이 따릅니다. 와일드카드 인증서는 단순 패턴이 일치하는 하위 도메인에서만 사용 가능합니다. 또한 SAN 인증서가 다수의 여러 도메인을 지원하기는 하지만 동일한 인증 기관이 각 도메인을 인증해야 합니다. 이 말은 새로운 도메인을 추가할 때마다 인증서를 다시 인증하고 프로비저닝해야 한다는 것을 의미합니다.

포럼과 reddit, 그리고 저의 이메일 수신함으로 가장 자주 도착하는 요청 중 하나가 바로 TLS의 서버 이름 표시(SNI) 확장을 사용하여 클라이언트 인증서를 선택할 수 있도록 해달라는 것이었습니다. TLS는 HTTP 아래 단계인 전송 레이어에 속하기 때문에 클라이언트가 요청하는 호스트 이름을 알지 못합니다. 이때 클라이언트가 처음 연결 시 서버에게 “이것이 내가 인증서를 원하는 도메인입니다”라고 지정할 수 있도록 도와주는 것이 바로 SNI입니다. 그러면 서버가 올바른 인증서를 선택하여 클라이언트에게 응답할 수 있습니다. 오늘날 모든 웹 브라우저와 대다수 클라이언트는 SNI를 지원합니다. 실제로 CloudFront에 연결되는 클라이언트의 99.5% 이상이 SNI를 지원하고 있습니다.

ALB의 스마트 인증서 선택

ALB의 스마트 인증서 선택은 SNI보다 한 걸음 더 나아갑니다. 유효한 도메인 이름 목록이 저장되는 것 외에도 키 교환 유형과 서버가 지원하는 암호화, 그리고 인증서 서명에 사용되는 알고리즘(SHA2, SHA1, MD5)이 인증서에 설명되어 있습니다. TLS 연결을 구성하려면 먼저 클라이언트가 프로토콜 버전, 확장자, 암호 그룹, 압축 방법 등 클라이언트의 기능을 간략히 나타낸 “ClientHello” 메시지를 전송하여 TLS 핸드섀이크를 시작합니다. 그러면 ALB의 스마트 선택 알고리즘이 각 클라이언트가 지원하는 기능에 따라 연결에 적합한 인증서를 선택하여 클라이언트에게 보냅니다. ALB는 고전적인 RSA 알고리즘과 최근에 등장하여 더욱 빠른 속도를 자랑하는 타원 곡선(Elliptic-curve) 기반 ECDSA 알고리즘을 모두 지원합니다. ECDSA 지원이 SNI만큼 클라이언트 사이에 널리 퍼진 것은 아니지만 오늘날 모든 웹 브라우저에서는 이미 지원되고 있습니다. 속도가 더욱 빠를 뿐만 아니라 CPU 사용량도 적기 때문에 지연 시간이 매우 낮은 애플리케이션에 유용할 뿐만 아니라 모바일 애플리케이션에서 사용되는 배터리 양을 절약하는 데도 매우 효과적입니다. ALB가 TLS 핸드섀이크를 통해 각 클라이언트가 지원하는 기능을 알 수 있기 때문에 RSA 인증서와 ECDSA 인증서를 동일한 도메인에 모두 업로드할 수 있습니다. 그러면 ALB가 각 클라이언트마다 가장 알맞은 인증서를 자동으로 선택합니다.

ALB와 SNI의 사용

여기에서 2개의 웹사이트인 VimIsBetterThanEmacs.comVimIsTheBest.com를 예로 들겠습니다. 저는 이 두 도메인을 구매하여 Amazon Route 53에 호스팅한 후 각 도메인에 사용할 인증서 2개를 AWS Certificate Manager(ACM)에 프로비저닝하였습니다. 이때 단일 ALB를 통해 두 사이트를 모두 안전하게 운영하고 싶다면 콘솔에서 인증서 2개를 빠르게 추가할 수 있습니다.

먼저 콘솔에서 내 로드 밸런서를 선택한 후 리스너 탭으로 이동하여 “view/edit certificates”를 선택합니다.

그런 다음 왼쪽 상단 모퉁이에 있는 “+” 버튼을 사용하여 인증서를 선택한 다음 “Add” 버튼을 클릭합니다.

이제 다 끝났습니다. GUI 사용에 익숙하지 않다면 AWS 명령줄 인터페이스(CLI)(또는 SDK)를 사용하여 새로운 인증서를 쉽게 추가하는 방법도 있습니다.

aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<cert-arn>

알아야 할 것들

  • ALB 액세스 로그에는 클라이언트가 요청한 호스트 이름과 사용한 인증서 ARN이 포함됩니다. “hostname” 필드가 비어있다면(“-“로 표시) 클라이언트가 요청에서 SNI 확장을 사용하지 않았기 때문입니다.
  • ACM 또는 IAM에서는 어떤 인증서든 사용할 수 있습니다.
  • 동일한 도메인이라고 해도 다수의 인증서를 보안 리스너로 바인딩할 수 있습니다. 그러면 ALB가 클라이언트 기능을 포함하여 여러 가지 요인에 따라 최적의 인증서를 선택합니다.
  • 클라이언트가 SNI를 지원하지 않으면 ALB가 기본 인증서(리스너 생성 시 지정한 인증서)를 사용합니다.
  • 새로운 ELB API 호출은 AddListenerCertificates, RemoveListenerCertificates, DescribeListenerCertificates 등 세 가지가 있습니다.
  • 로드 밸런서 1개당 바인딩이 가능한 인증서는 최대 25개입니다(기본 인증서 제외).
  • 이번에 새롭게 추가된 기능은 처음부터 AWS CloudFormation에서 지원됩니다.

새로운 기능의 사용 예는 저의 동료인 Jon Zobrist가 만든 웹사이트(https://www.exampleloadbalancer.com/)에서 찾아볼 수 있습니다.

저는 개인적으로 이 기능을 사용할 예정이며 수많은 AWS 사용자들 역시 커다란 이점을 경험하게 될 것입니다. AWS 사용자들을 위해 이처럼 멋진 기능을 개발하느라 수고해 주신 Elastic Load Balancing 팀에게 깊은 감사를 드립니다.

Randall;

이 글은 Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI 한국어 번역입니다.

AWS Certificate Manager, 서울 리전 포함 글로벌 확대!

올해 1월에 AWS Certificate Manager라는 무료 SSL/TLS 인증서 서비스를 시작하였고, 많은 고객들이 매년 SSL 인증서를 구매하고 설치하는 수고 없이 SSL 웹 서버 운영을 할 수 있다는 점에서 큰 호응을 얻었습니다. 오늘 Asia Pacific(Seoul) 리전을 포함한 전 세계 리전에 ACM 서비스가 확대됩니다.

Amazon의 인증 기관(CA)인 Amazon Trust Services (ATS)에서 무료로 인증서를 발급 받고, SSL 서비스가 가능한 Amazon 서비스에 연결만 하면, 별도로 SSL 서버 설치, 인증서 구매, 인증서 설치 및 매년 재발급 및 인증서 재설치의 수고가 필요 없습니다.

즉, SSL 인증에 대한 추가 비용 없이 ACM을 사용하면 몇 분만에 SSL 암호화 기능을 사용할 수 있습니다. 인증서 발급을 요청하면, Elastic Load Balancers 및 Amazon CloudFront에서 몇 번의 클릭으로 설정할 수 있습니다. 그 후 ACM은 자동으로 인증서를 정기적으로 업데이트 합니다.

이번 글로벌 리전 확대를 통해 서울 리전 관리 콘솔에서 바로 ACM 서비스를 사용할 수 있을 뿐만 아니라 그동안 Amazon CloudFront에서만 사용 가능했던 것을 서울 리전 내 Elastic Load Balancing을 통해 SSL 서비스를 제공하는 고객들도 사용하실 수 있게 되었습니다.

AWS Certificate Manager 서비스에 대한 더 자세한 사항은 서비스 상세 페이지를 참고하시기 바랍니다.

이 글은 AWS Certificate Manager now available in more regions의 한국어 편집본입니다.

신규 AWS Certificate Manager – 무료 SSL/TLS 인증 서비스 제공

표면적으로는 단순하지만 그 이면에는 복잡한 구조인 기술이 있습니다! 웹 브라우저에 열쇠 아이콘이 있으면, 웹 사이트 데이터 전송 자체가 암호화되어 있다는 것을 보여줍니다.

웹 브라우저는 왜 녹색 열쇠를 표시할까요? SSL/TLS 인증서로 알려진 디지털 인증 파일이 있기 때문입니다. 이것은 고객과 웹 사이트 간에 인증과 신뢰를 제공하기 위한 전자 문서입니다.

SSL/TLS는 중요한 정보를 교환 할 때마다 필요합니다. 예를 들어, 사이트가 PCI-DSS, FISMA과 같이 규정 준수를 해야 하는 경우 혹은 의료 데이터 전송을 위한 HIPAA 규정에서도 SSL/TLS를 이용하도록 하고 있습니다.

SSL 인증서는 글로벌 인증 기관에서 도메인을 특정하여 발행하는 민간 인증 회사입니다. 여러분의 웹 사이트에 인증서를 취득하고자 할 경우, 인증 회사(Certificate Authority)는 해당 도메인 소유 확인 책임을 담당합니다. 그리고, 일정 기간 유효한 인증서를 발급하고 특정 도메인의 웹 사이트 암호화를 보장합니다. 기존 시스템에 인증서를 설치하는 경우, 유효 기간을 살펴보고 정기적으로 새 인증서를 발급 받아야 합니다. (인증서는 12개월 간 유효하므로 업데이트 필요)

각각의 인증서는 전자 서명되어 있습니다. 이를 통해 정당한 CA에서 발급 된 것이라는 것을 확인할 수 있습니다. 좀 더 자세히 말하면, 웹 브라우저는 인증 회사의 루트 인증서 목록을 사용하여 발급 받은 인증서를 신뢰할 수 있는 지 추적할 수 있고 이러한 정보는 웹 브라우저에서 손쉽게 확인할 수 있습니다.

위와 같이 SSL/TLS 인증서를 설정하고 관리하는 것은 수작업이 많아 쉽게 자동화 할 수 없습니다. 또한, 번거러운 절차를 거쳐서 인증서를 발급 받고 이에 대한 연간 비용을 지불해야 합니다.

이제 이러한 어려운 상황을 바꿀 때가 왔습니다!

신규 AWS 인증 관리자(Certificate Manager) 서비스
AWS 인증 관리자 (ACM) 서비스는 SSL/TLS 인증서 발급 및 관리에 대한 많은 작업을 자동화 하고 단순화 하기 위해 시작되었습니다. ACM에서 제공되는 인증서는 Amazon의 인증 기관(CA)인 Amazon Trust Services (ATS)에서 발급됩니다..

인증서에 발급되는 추가 비용이 발생하지 않습니다. SSL/TLS 인증서는 AWS Certificate Manager에서 무료로 사용하실 수 있습니다.

ACM을 사용하면 몇 분만에 SSL 암호화 기능을 사용할 수 있습니다. 인증서 발급을 요청하면, Elastic Load BalancersAmazon CloudFront에서 몇 번의 클릭으로 설정할 수 있습니다. 그 후 ACM은 자동으로 인증서를 정기적으로 업데이트 해줍니다.

인증서 자동 발급 및 설정
콘솔을 사용하여 인증서 설정 및 구축 단계를 살펴 보겠습니다. (API에서도 사용할 수 있습니다.) 예를 들어, 자신의 도메인 jeff-barr.com에서 확인 해 봅니다. AWS Certificate Manager 콘솔을 열고 Get started을 클릭합니다.

SSL을 설정하고자 하는 웹 사​​이트의 도메인 이름을 입력합니다. 원하는 도메인을 지정하고 모든 하위 도메인을 대상으로 합니다.

요청의 내용을 확인합니다.

도메인 소유자의 이메일을 열고, certificates.amazon.com에서 메일을 확인하고 strong>Amazon Certificate Approvals에 동의합니다.

사이트로 이동하여 I Approve를 클릭합니다:

이제 완료되었고, 콘솔에 인증서를 볼 수 있습니다.

인증서 배포하기
인증서가 발급되면 Elastic Load Balancers 또는 CloudFront 배포 지점에 설치할 수 있습니다.

ELB는 SSL offload를 지원하고 있기 때문에 부하 분산 서비스에 인증서를 구축하는 것이 그 뒤에 구축되는 EC2 인스턴스의 암호화를 굳이 진행할 필요가 없습니다.

CloudFront 배포는 아래와 같이 하실 수 있습니다.

정식 출시

AWS Certificate Manager (ACM)는 US East (Northern Virginia) 리전에서 사용할 수 있습니다. 다른 리전도 준비 중입니다. 이제 인증서 설정, 구축 및 정기적 업데이트를 추가 비용 없이 사용할 수 있습니다.

다른 AWS 서비스와 다른 도메인 확인 방법 등의 추가도 계획하고 있습니다. 제안 및 의견도 요망 사항이 있으면 우선 순위를 정하는 데 도움이 되겠습니다.

만약 AWS Elastic Beanstalk을 사용하신다면, Enabling SSL/TLS (for free) via AWS Certificate Manager 문서도 참고해 보시기 바랍니다.

Jeff;

이 글은 New – AWS Certificate Manager – Deploy SSL/TLS-Based Apps on AWS의 한국어 번역입니다.