테일스케일을 사용하여AWS WAF Whitelist 수문장에서 벗어나기까지 (3)
내부의 리소스 접근용 alb를 놔두고 외부 접근용 nlb를 놔두는 방식으로 사용하기로 아키텍쳐를 수정했습니다.
각 리소스들에 대한 옵션 설명을 하자면
- 퍼블릭 Route 53
- Network Load Balancer(NLB) 퍼블릭 서브넷(Eip 사용 가능) 가용영역 A & 가용영역 B
- Application Load Balnacer(ALB)
- 프라이빗 서브넷 가용영역 A & 가용영역 B
- ECS service 프라이빗 서브넷 가용영역 A & 가용영역 B
사용
- 외부와 통신할 일이 있는 서비스는 NLB로 호스팅 하는 주소를 사용( web 깃헙 액션 build)
- Ip를 기반으로 waf에서 허용해 줘야 하는 서비스가 있다면 alb에 연결되어 있는 WAF의 whitelist에서 연결해 주면 문제없는 것으로 확인했습니다.
- 외부와 통신할 일이 없는 서비스(백 오피스)는 ALB로 호스팅 하는 도메인을 사용하도록 한다.
- 이에 따라 내부 백 오피스는 개개인의 ip 주소를 지우고, 오피스 주소와 허용해야하는 외부 접속 서비스의 ip 와 waf 룰만 남기면 됩니다.
- 백오피스는 테일 스케일을 이용하여서 들어오는 것을 기본으로 생각하면 됩니다.
액세스 컨트롤
NLB는 ALB와 다르게 따로 설정할 수 있는 sg와 WebAcls 그리고 WAF가 존재하지 않는다. 그래서 ALB에 붙어있는 WAF에서 조정해 주면 된다.
→ 최근에 NLB에서도 SG를 설정할 수 있는 기능이 추가되었지만, ALB에서 일괄 관리하는 것이 더 편하다고 판단되어서 굳이 건드리지 않겠습니다.
현재까지 위 방법으로 문제가 없이 정상적으로 된 케이스들 정리
NLB 퍼블릭 라우트53 호스팅 주소 사용
- 외부에서 Ip를 기반으로 접근을 허용해 줘야 하는 때에도 ALB에서 추가해 주면 문제가 없었습니다.
- curl 요청을 했을 때 문제없이 응답을 잘 받아왔습니다.
- web에서 빌드를 하는 과정에서 서버 통신 문제없었습니다.
ALB 프라이빗 호스팅 주소 사용
- 백오피스에서 서버와 소통되는것 확인
- 테일스케일로만 서버 접속 가능한 것 확인
위 구조의 장점
- 한 서버에서 nlb alb를 두 개를 붙여서 사용하니, 서버를 두 개 띄우는 거보다 가격이 싸다
- 배포 파이프라인을 internal or inter-facing을 위해서 따로 만들어 줄 필요가 없습니다.
- 서버 관리 포인트가 줄어듭니다.
- 프록시 서버를 따로 둘 필요가 없습니다.
이제 위 아키텍처를 채택하여서 WAF에 ip를 넣는 수고를 덜고, 구성원들이 스스로 내부 리소스에 접근할 수 있도록 하는 시스템을 구축하였습니다.
또한 퍼블릭 서브넷을 사용하였던 서버도 프라이빗 서브넷으로 바꿔서 보안을 더 향상시킬 수 있었습니다.
따로 궁금한점
nlb와 alb와 ecs fargate 서버를 연결을 한 구조를 가지고 있는데 nlb에서는 어떻게 헤더를 포함해서 alb로 요청을 전달할 수 있는 걸까?
NLB (Network Load Balancer)
- L4 (전송 계층)에서 동작: TCP, UDP와 같은 저 수준의 트래픽을 처리합니다.
- 헤더 수정 X: 전송 계층에서의 트래픽은 IP 주소, 포트, 프로토콜 정보 등을 주로 다룹니다. 이 계층에서는 복잡한 헤더나 콘텐츠 수정이 일어나지 않습니다. 따라서 NLB는 수신한 트래픽을 그대로 전달합니다.
ALB (Application Load Balancer)
- L7 (응용 계층)에서 동작: HTTP, HTTPS와 같은 고 수준의 트래픽을 처리합니다.
- 헤더 수정 가능: 응용 계층에서는 트래픽의 내용 (헤더, 본문 등)을 바탕으로 라우팅 결정이나 수정 등의 작업을 할 수 있습니다.
여기서 중요한 점은 NLB가 하는 일입니다.
NLB는 전송 계층에서 동작하므로 복잡한 조작 없이 트래픽을 받아 그대로 다음 목적지 (여기서는 ALB)로 전달합니다.
이렇게 되면 ALB로 가는 트래픽의 헤더나 내용이 NLB에 의해 변경되지 않습니다.
