1. 개요
AWS에서 VPC 란 사용자가 정의하는 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경을 얘기합니다. VPC는 IGW(Internet Gateway)를 통해서 인터넷 통신을 하며, VGW(Virtual Private Gateway)를 통해서 On-Premise 통신을 합니다. 인터넷을 통해서 서비스가 연결되는 애플리케이션들은, 외부로부터의 여러 위협 및 원치 않은 접근을 제한하기 위한 보안 통제 조치들을 충분히 고려하여 구성할 필요가 있습니다. 이러한 보안 통제 조치들은 애플리케이션의 유형이나, 크기, 요구되는 컴플라이언스 수준, 운영 상의 조건 등 다양한 요구 사항에 따라서 구현될 수 있습니다. 어떤 경우에는 Network Access Control List(NACL)나 Security Group(SG)만을 활용하여도 효과적으로 애플리케이션을 보호할 수 있을 것이며, URL 제어, IPS 패턴 탐지 등 좀 더 다양한 형태의 위협에 대한 대응이 필요할 경우에는 추가적인 방화벽 구성이 필요할 수도 있습니다.
추가적인 보안 요구 사항이 있을 경우 NACL이나 SG 외에 3rd-party UTM 을 구성하여 보안 제어를 할 수 있습니다. 또한 AWS Network Firewall이나, AWS Gateway Load Balancer 같은 새롭게 추가된 서비스들을 활용하여 더욱 유연한 방화벽 아키텍처를 AWS 상에서 설계할 수 있습니다.
이번 포스팅에서는 인터넷에 연결된 애플리케이션들에 대한 인바운드/아웃바운드 트래픽을 보호하기 위해 다양한 방화벽 옵션에 대한 네트워크 구성 방안들을 소개해 보고자 합니다. 즉, 인터넷으로부터의 Ingress flow(예: Internet 에서 VPC로)와 Egress flow(예: VPC에서 인터넷으로)의 구성 아키텍처에 대하여 다룹니다. East/West(즉, VPC에서 VPC로 또는 VPC에서 온프레미스로) 아키텍처는 제외하며, 웹 방화벽(AWS WAF 또는 3rd-party WAF) 구성은 포함하지 않습니다.
2. 네트웍 보안 요구 사항
2.1 추가 보안솔루션 도입 효과
NACL은 서브넷에 대한 Stateless(상태 비저장) 형태의 보호를 제공하며, SG는 Stateful(상태 저장)로 이미 허용된 트래픽에 대한 리턴 트래픽을 자동으로 허용합니다. NACL과 SG만으로는 보안 제어를 함에 있어 다소 제약 사항이 있으며, 아래와 같이 추가적인 보안 조치를 필요로 하는 경우에는 3rd-party UTM 또는 AWS Network Firewall(NFW) 구성을 고려해 보아야 합니다.
● Scale(규모) – 하나의 NACL은 최대 40개의 규칙 항목(Rule entry)을 지원합니다. (기본값은 20개) 그리고 하나의 SG 는 1,000개의 규칙 항목(기본값은 60개)를 허용합니다. SG 의 경우 전체 규칙을 검사하기 때문에 규칙이 많을 경우 성능상 제한이 발생할 수 있고, 이러한 제한을 초과하는 요구가 있다면 추가적인 보안 솔루션을 고려할 필요가 있습니다. 예를 들어서 AWS NFW 은 30,000개의 규칙 항목을 기본적으로 지원하며, 3rd-party UTM 은 벤더에 따라 규칙 항목 지원 여부가 상이하나 대규모의 지원이 가능합니다.
● Inspection Depth(검사의 깊이) : NACL과 SG는 L3 및 L4 계층에서 동작합니다. 즉 IP 주소, 프로토콜, 그리고 포트에 대해서 적용되며 L7 단은 적용되지 않습니다. 따라서 애플리케이션 계층 기반의 보호를 제공하지 않으므로 예를 들어 HTTP/s 접속에 대한 payload 정보를 기반으로 하는 필터링(특정 URL에 대한 허용/차단 등)을 적용할 필요가 있다면 보안 장비를 추가 구성하여 적용이 가능합니다.
● Centralized Management(중앙 집중식 관리) : 규모가 크고 분산되어 있는 환경에서는 다양한 Account 및 VPC에 걸쳐서 존재하는 SG 와 NACL 을 중앙에서 관리하기가 쉽지 않습니다. 중앙 집중 관리가 가능한 형태의 방화벽 (AWS NFW 또는 3rd-Party UTM) 을 구성하여 관리하는 것이 보다 수월할 수 있습니다.
2.2 추가 보안 솔루션 적용 시 고려 사항
방화벽 솔루션을 도입할 때, 방화벽의 기본적인 기능이나 성능 외에도 여러 가지가 고려되어야 합니다. 아래는 일반적으로 네트워크 솔루션이 적용될 때 영향을 끼칠 수 있는 몇 가지 영역들입니다.
● 애플리케이션 타입 – 검토 중인 솔루션이 보호의 대상이 되는 애플리케이션 타입을 지원하도록 하여야 합니다. 예를 들어 Web Application firewall(웹 방화벽)은 HTTP/s 기반의 애플리케이션 보호에는 적합하지만 다른 유형의 트래픽을 보호하는 데는 적합하지 않습니다. 다양한 유형의 애플리케이션을 보호하여야 하는 경우라면 다양한 유형의 애플리케이션을 모두 보호할 수 있는 방화벽 제품을 도입하거나, 혹은 여러 가지 방화벽 솔루션을 조합하여 구성할 필요가 있습니다.
● 운영 규모 – 유입 트래픽에 대하여 방화벽으로 보호할 VPC의 운영 규모를 고려하여야 합니다. 단순히 하나의 VPC만을 보호 대상으로 할지, Multi VPC나 Multi Account 환경이라면 방화벽을 분산시키는 편이 나을지(각 VPC 별로 독자적인 통신 경로와 고유한 방화벽을 구성) 또는 집중화하는 편이 나을지(트래픽이 실제 애플리케이션이 속한 VPC로 전송되기 전에 중앙 집중 형태의 보안 전용 VPC를 거치도록 구성)를 결정해야 합니다.
● 검사의 깊이/암호화– 방화벽에서 검사하는 패킷의 계층을 어디까지 적용할지 고려하여야 합니다. 예를 들어 네트워크 계층에 대한 규칙을 적용하는 것으로 충분한지, 아니면 애플리케이션에 계층에 대한 검사도 필요한지 고려합니다. 또한 인터넷상의 트래픽 대부분은 암호화되어 있으므로, 애플리케이션 계층에서 해당 트래픽을 검사하려면 암호화된 트래픽을 해독할 수 있는 방화벽 솔루션이 필요합니다.
● 운영/자동화 – AWS 네트워크에 추가적인 방화벽들이 구성되면 거기에 따라 운영 상의 오버헤드가 발생합니다. 따라서 방화벽 솔루션들을 선택할 때, 확장성에 따른 관리 및 자동화가 적절히 이루어질 수 있는지 고려하여야 합니다.
3. 네트웍 보안 레퍼런스 아키텍처
중앙 집중 제어 아키텍처에서 AWS 네트워크에 대한 모든 트래픽은 보안 솔루션들이 모여있는 관문 VPC를 통해서 전송될 수 있습니다. 관문 VPC에서 처리된 트래픽들은 이후 Transit Gateway 또는 PrivateLink를 통해 다른 VPC의 Target 애플리케이션으로 전송됩니다. LoadBalancer 가 속한 VPC 와 다른 VPC 의 Target 에 트래픽을 전송할 때는, Target type 으로 반드시 IP를 지정해야 합니다. Network LoadBalancer와 PrivateLink 모두 고정 IP를 가지고 있으므로 이 경우에는 해당 IP가 LoadBalancer의 Target으로 지정될 수 있습니다. 아키텍처에 따라 Target이 Application LoadBalancer에 등록되어 있는 경우라면, Application LoadBalancer가 고정 IP를 가지고 있지 않기 때문에 Application LoadBalancer로 서비스하는 Target의 앞단에서 고정 IP 주소를 얻기 위해 Network LoadBalancer 뒤에 Application LoadBalancer를 배치할 필요가 있습니다.
3.1 ELB Sandwich
3rd-party UTM을 Internet-facing LoadBalancer 하단에 구성하여 Load Balancing 하며, UTM 상단에 Network LoadBalancer를 구성하는 경우 Client IP를 UTM에서 확인/제어 가능합니다. UTM 내 NAT 정책을 통하여 Target을 DNS FQDN으로 등록 가능함에 따라 애플리케이션 앞단 LoadBalancer를 요구 사항에 따라 선택하여 구성할 수 있습니다.
3.1.1 Ingress Traffic Flow
3.1.2 Egress Traffic Flow
3.2 AWS Gateway Load Balancer
AWS는 지난 몇 년 간 VPC 라우팅의 유연성을 위해 신규 기능들을 출시해 왔습니다. Ingress Routing 설정으로 IGW 및 VGW를 통해 통신하는 VPC 트래픽에 별도의 라우팅 테이블을 적용하여 VPC 내 3rd-party UTM으로 트래픽을 흐를 수 있게 하였으며, 라우팅 구체화 기능을 통해 Local 경로보다 더 구체적인 경로를 라우팅 테이블에 적용할 수 있도록 기능이 업데이트 되었습니다. GWLB(Gateway LoadBalancer)는 이러한 라우팅 기능 업데이트와 함께 3rd-party UTM 을 좀 더 효율적으로 관리할 수 있도록 출시된 전용 LoadBalancer 입니다.
GWLB가 출시되기 전에는 3rd-party UTM을 구성하기 위해서는 ELB Sandwich 아키텍처 또는 TGW(Transit Gateway)를 이용한 Security VPC를 구성해야 했습니다. IGW/VGW를 거치는 트래픽에 대해 VPC 내의 3rd-party UTM으로 전달되도록 하기 위해 각각의 라우팅 테이블을 조정하여야 했습니다. 이와 같은 환경에서는 UTM을 VPC 내에서 직접 구성/관리하여야 했으며, AWS 라우팅 및 UTM의 제약 사항으로 가용성 및 확장성을 확보하기가 어려웠습니다.
VPC로 인입되는 트래픽에 IGW Ingress Routing을 적용함으로써 인터넷 연결 LoadBalancer(ALB, NLB)에 도달하기 전에 IGW에서 AWS GWLB Enpoint로 트래픽을 전달합니다. GWLB를 사용함에 따라 ELB Sandwich 아키텍처에 존재하던 복잡한 NAT 구성이 필요 없어지며 트래픽 가시성 확보가 가능합니다. 또한, GWLB를 통해 UTM의 가용성 및 확장성 확보가 가능하며, GWLB Endpoint 및 GWLB는 AWS 완전 관리형 서비스로 유연하게 동작합니다.
3.2.1 구성 아키텍처
3.2.2 Ingress Traffic Flow
3.2.3 Egress Traffic Flow
3.3 AWS Network Firewall
Traffic Flow는 GWLB 구성과 동일하며, 3rd-party UTM을 사용하는 대신 AWS Managed 서비스인 AWS NFW(Network Firewall)로 구성된다는 차이가 있습니다. AWS NFW는 VPC의 보안을 위해 AWS 에서 제공하는 관리형 네트워크 방화벽으로 Stateless/Staeful 정책 적용이 가능하며, IP 주소뿐 아니라 도메인 단위의 필터링 정책도 적용이 가능합니다. AWS NFW 서비스 연동 시 별도의 GWLB Endpoint 가 생성되며, GWLB 아키텍처와 동일하게 Ingress Routing 및 라우팅 구체화 기능을 적용하여 라우팅 테이블을 업데이트하여야 합니다.
3.3.1 구성 아키텍처
4. 마무리
앞서 설명한 아키텍처들은, 인바운드/아웃바운드 트래픽을 효과적으로 필터링하기 위하여 보안 솔루션의 네트워크 통합에 초점을 맞추고 있습니다. 솔루션을 결정할 때는 방화벽의 기능과 함께 방화벽에 요구되는 보안 고려 사항들을 충족하는지도 함께 검토되어야 하며, 심층적인 방어 체계를 구축하기 위해서는 Security Group, NACL뿐 아니라 VPC Routing / Route53 / CloudFront / Global Accelerator 등 네트웍 서비스에 대해 전체적으로 함께 아키텍처 설계가 필요합니다.
5. 참고
