Aviatrix Gateway로 만든 AWS VPC의 FQDN 아웃바운드 통제 (2019-09)

아웃바운드를 도메인으로 걸러야 했던 이유

쏘카는 성장세를 온프레미스로 따라가기 어렵다고 보고 1년 전부터 클라우드로 옮기고 있었고, 원문 시점에는 중요 서비스의 90% 이상이 이전을 마쳤습니다. 보안 요구 사항을 채우려고 추가 시스템을 고민하던 중 아웃바운드 FQDN 필터링이 필요해졌습니다.

이유는 네 가지였습니다. 멀웨어에 감염됐을 때 C&C 서버 접속과 데이터 유출 시도를 막고, 아웃바운드 트래픽의 무단 활동을 감지하고, google.com처럼 IP 범위가 넓거나 CDN처럼 계속 바뀌는 대상에 대응하고, 보안 그룹의 규칙 한도를 피하기 위해서입니다. 보안 그룹은 규칙이 60개로 제한되는데, updates.ubuntu.com은 IP가 15개이고 GitHub는 12개라서 아웃바운드에는 부족하다고 설명했습니다.

솔루션 선정

요구 사항은 FQDN 필터링, HTTP/HTTPS와 와일드카드 지원, 멀티 계정·멀티 클라우드, 코드형 인프라, 안정성, 낮은 비용이었습니다. 오픈소스인 Squid와 유료인 Palo Alto, Cisco vMX를 검토한 끝에 Aviatrix를 골랐습니다. 국내 레퍼런스는 찾기 어려웠고 해외에는 NASA, Netflix, Hyatt 같은 사례가 있었습니다. FQDN, Transit GW, VPN 서비스의 비용과 IaC 배포·구성이 다른 유료 솔루션보다 유리하다는 점이 결정 이유였습니다.

게이트웨이 구성과 로그로 확인한 동작

시험은 AWS Marketplace의 Free Trial 유형을 CloudFormation 템플릿으로 설치해 진행했습니다. AMI로 직접 설치하면 역할과 네트워크를 따로 설정해야 합니다. 컨트롤러에서 Gateway를 만들면 설치와 환경 구성은 자동으로 진행됩니다.

프라이빗 서브넷의 라우트 테이블에서 0.0.0.0/0 대상을 Aviatrix Gateway의 ENI로 지정해 외부로 나가는 트래픽이 모두 게이트웨이를 지나가게 했습니다. 필터를 화이트리스트로 두고 인스턴스에서 네 개 도메인에 curl을 보냈습니다. 로그에는 www.naver.com이 NOT_WHITELISTED로 차단됐고 google.com 계열은 MATCHED로 남았습니다. 호스트명을 지정하지 않으면 와일드카드로 적용돼 *.google.com과 google.com이 같다고 합니다.

실서버에 적용하기 전에는 Egress FQDN Discovery로 실제 사용 중인 도메인 목록을 먼저 모을 수 있습니다. 대상 게이트웨이는 FQDN 필터에 연결돼 있지 않아야 합니다.

이중화 시험과 IAM 역할 구조

HA는 다른 AZ의 퍼블릭 서브넷에 이중화 게이트웨이를 하나 더 두는 설정으로 켭니다. 컨트롤러가 헬스 체크에 실패하면 AWS 역할로 프라이빗 라우트 테이블의 0.0.0.0/0 대상을 HA 게이트웨이 ENI로 바꿉니다. 시험에서는 게이트웨이를 콘솔에서 강제 중지했고, 프라이빗 서브넷 인스턴스에서 Telegraf로 1초 간격 ICMP를 관찰했습니다. 패킷 손실은 없었고 웹사이트 기준으로 전환을 알아챌 수 없는 수준이었다고 합니다.

CloudFormation 템플릿은 두 역할을 만듭니다. EC2에 붙는 aviatrix-role-ec2는 arn:aws:iam::*:role/aviatrix-*에 대한 sts:AssumeRole을 허용받고, 많은 권한을 가진 aviatrix-role-app을 위임받아 씁니다. 멀티 계정도 같은 방식으로, 다른 계정의 role-app이 컨트롤러 계정을 신뢰하도록 등록합니다.

정리와 남은 우려

저자는 장점으로 마켓플레이스 구매 뒤 수동 작업이 거의 없는 점, Terraform으로 내보내는 기능, 특정 클라우드에 묶이지 않는 점, 사용한 만큼 내는 라이선스를 꼽았습니다. 쏘카는 Transit GW로 트래픽을 중앙 관리하는 구성을 운영 중이라고 합니다.

HTTPS 트래픽의 목적지를 보는 근거는 SNI입니다. TLS 핸드셰이크의 ClientHello에는 접속할 사이트 이름이 암호화되지 않은 평문으로 들어 있어 게이트웨이가 이를 읽습니다. TLS 1.3 최종안에서 Encrypted SNI는 필수가 아닌 확장 기능으로 남았습니다. 원문은 SNI가 암호화되면 FQDN 필터를 어떻게 이어갈지가 지속 가능성의 문제라고 지적했습니다. 앞으로는 로그 분석, DMZ와 VDI, 원격 근무 설계, 인바운드 로그 분석, VM 간 트래픽 관리를 계획한다고 밝혔습니다.