SSL(Security Socket Layer) 인증서를 사용하면 클라이언트와 로드밸런서 사이에서 이루어지는
트래픽을 암호화 할 수 있습니다.
클라이언트에서 EC2 인스턴스로 호출할 때 브라우저 (WWW)를 통해 로드 밸런서와 연결합니다.
이럴때 주로 HTTPS를 통해 트래픽을 전달하며, HTTPS는 SSL 인증서를 사용해서 트래픽을 암호화하여 보낸다는 의미입니다.
1) HTTPS 프로토콜을 통해 사용자가 보내는 데이터는 로드 밸런서에 가는 동안 암호화되게 됩니다.(SSL 인증서)
= In-Flight Encryption (데이터가 네트워크를 통과하는 중에 암호화 되며, 발신자와 수신자만 해독이 가능하다)
2) 로드 밸런서는 SSL 인증서 종료 작업을 수행
3) Back-End에서는 EC2 인스턴스와 통신할 수 있음
- HTTP 프로토콜을 사용하기에 SSL 인증 과정이 없어 암호화가 되지 않지만 사설 네트워크인 VPC를 통해 전송되어
어느 정도의 안정성은 보장됩니다.
로드 밸런서는 X509라는 SSL or TLS 서버 인증서를 가져오고 AWS에서는 ACM(Amazon Certificate Manager)를 통해
해당 인증서를 관리하게 됩니다.
HTTPS 리스너에서는 기본 인증서를 지정해야 하며, 다수의 도메인을 지원하는 인증서 선택 목록을 추가할 수 있습니다.
이 과정에서 기본 SSL 또는 TLS 인증서를 ACM으로 할 지 IAM으로 할 지 아니면 다른 인증서를 업로드 할 지 고려하고, 이렇게 기본 인증서가 지정된다면 거기에 맞춰 다수의 도메인을 지원하는 인증서를 선택할 수 있습니다.
클라이언트에서는 SNI(서버 이름 지표)를 통해 해당 도메인을 접근하는, 즉 원하는 웹 사이트에 접속할 수 있게 됩니다.
추가로 SSL 인증 과정에서 in-flight Encryption을 진행할 때, 보안 그룹을 설정해야 하는데
이는 HTTPS에 대한 특정한 보안 정책이며, 로드밸런서와 클라이언트 사이에서 트래픽을 주고 받을때 적용됩니다.
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html
Predefined SSL security policies for Classic Load Balancers - Elastic Load Balancing
Predefined SSL security policies for Classic Load Balancers You can choose one of the predefined security policies for your HTTPS/SSL listeners. We recommend the default predefined security policy, ELBSecurityPolicy-2016-08, for compatibility. You can use
docs.aws.amazon.com
SNI(Server Name Indication)
: 사용자가 원하는 웹사이트에 연결하고자 하는 지표이며 설정된 규칙에 따라서 호스트를 찾아 도메인을 연결하는 역할을 합니다.
명확한 정의로는 한 웹 서버 상에 다수의 SSL 인증서를 발급하여 단일 웹 서버가 여려 개의 웹 사이트를 제공하도록 하는 문제를 해결하는 것이다. 이렇게 설명하면 이해하기 어렵지만 그림을 통해 설명하겠다.
사용자는 도메인 :) exampl1에 접근하고 싶어하는데, 앞서 설명상 클라이언트와 ALB 사이에는 HTTPS 프로토콜로 SSL 인증 과정을 통해
전송된 트래픽은 암호화되어(in-flight encryption) 보내지고 ALB 측에서는 SSL 인증서 종료 작업을 진행합니다.
또한 로드 밸런서(ALB) 입장에서는 각 대상그룹(Target Group)에 해당하는 SSL 인증서 example1, example2를 가지고 있습니다.
ALB에서는 Client가 example1 이라는 서버 이름(SNI)을 표시해서 요청한 것을 체크하고
이에 알맞는 example1 SSL 인증서로 트래픽을 암호화합니다.
또한 정의된 여러 규칙(호스트 이름 관련 내용)을 통해 example1.com 도메인이 올바른 대상 그룹인 것을 알고
사용자와 example1.com 대상그룹과 연결을 시킵니다.
이처럼 SNI는 단일 웹 서버(≒ 백앤드){example1.com, example2.com, .... }에서 여러 개의 웹 사이트를 제공하지 않고
SNI를 통해 어떤 웹 사이트를 제공받기를 희망하는지 확인해서 거기에 맞는 (example1.com) 웹 사이트를 로드 밸런서에
제공하고 결과적으로 사용자가 받을 수 있도록 하는 것입니다.
SNI는 최신 프로토콜로, 클라이언트가 초기 SSL hand shake에서 대상 서버의 Host 이름을 명시해야 합니다.
클라이언트가 어떤 웹 사이트에 연결하는지 알아야 로드 밸런서가 서버로부터 어떤 인증서를 불러올 지 알 수 있고
맞춰서 어떤 웹 사이트에 연결지어야 할 지 알기 때문입니다.
이는 ALB, NLB를 지원하며 Cloud Front에서도 작동합니다.
실습 정리
로드 밸런서에서 리스너를 추가해서 HTTPS 프로토콜을 추가한 뒤 클라이언트와 로드 밸런서 사이에
SSL 인증서 관리 작업을 진행할 것 입니다.
리스너가 어떤 타겟 그룹을 바라보도록 할 지 정의하고, ALB라 여러 타겟 그룹을 셋팅할 수 있지만 우선 하나만 진행하도록 하겠습니다.
stickiness duration은 앞서 정리한 세션, 쿠키 관련된 내용입니다. 꼭 설정할 필요는 없지만 저는 설정했습니다.
그리고 나서 로드 밸런서가 SSL 인증서 설정을 사용할 때, 클라이언트와 연결 작업에서 어떤 보안 그룹을 사용할 지 체크해야 합니다.
이는 앞서 링크 걸어둔 Predefined SSL Security 내용을 참고하면 좋을 것 같습니다.
마지막으로 기본 SSL 인증서를 ACM, IAM으로 할 지 아니면 내가 가지고 있는 인증서를 업로드해 쓸 것인지 정의합니다.
그에 맞는 인증서를 선택해서 같이 업로드하고 SSL 리스너 설정을 추가하면 됩니다.
각각의 규칙에 대해서 별개의 SSL 인증서를 가질 수 있으며 그럴 경우 SNI, 서버 이름 표시를 사용할 수 있기 때문에
다양한 대상 그룹에 대해 다수의 SSL 인증서를 가질 수도 있습니다.
(NLB는 HTTPS가 아니라 TCP를 쓰기 때문에 TLS를 사용)
CLB는 SNI가 제공되지 않고 하나의 대상 그룹에 대해 하나의 SSL 인증서가 지원되지만,
ALB, NLB는 SNI가 제공되고 다중의 SSL 인증서를 지원하고 다수의 도메인을 접근할 수 있습니다.
물론, SNI를 통해 클라이언트가 원하는 웹 사이트를 열고자 서버 이름을 명시하고 거기에 맞는 SSL 인증서를 서버로부터
가지고 오고 대상 그룹과 매핑하여 올바른 결과가 나올 수 있도록 설정되어 있습니다.
'Cloud' 카테고리의 다른 글
| AWS - ASG(1) (0) | 2023.01.19 |
|---|---|
| AWS - Connection Draining (0) | 2023.01.18 |
| AWS - Cross Zone Load Balancing (0) | 2023.01.17 |
| AWS - Sticky Session (0) | 2023.01.17 |
| AWS - ELB(GWLB) (0) | 2023.01.17 |
