Amazon Route 53 Resolver DNS Firewall로 하이브리드 워크로드 보호하기

본 게시물은 AWS Networking & Content Delivery Blog에 Yaniv Rozenboim님, Yossi Cohen님이 공저한 “Securing hybrid workloads using Amazon Route 53 Resolver DNS Firewall” 원문을 한국어로 번역 및 편집한 글입니다.

2021년 출시 이후, Amazon Route 53 Resolver DNS Firewall은 Amazon Web Services(AWS) 사용자가 Amazon Virtual Private Cloud(Amazon VPC) 리소스에서 발생하는 아웃바운드 DNS 쿼리를 모니터링하고 제어할 수 있게 해주었습니다. Route 53 Resolver DNS Firewall에서 도메인 필터링 규칙을 구성하면 DNS 터널링을 통한 데이터 유출, 피싱 및 멀웨어 배포에 사용되는 악성 도메인에 대한 액세스와 승인되지 않거나 규정을 준수하지 않는 대상에 대한 우발적 노출과 같은 보안 위협을 완화하는 데 도움이 됩니다. 또한 AWS Firewall Manager를 사용하면 AWS Organization의 여러 VPC 및 계정에서 Route 53 Resolver DNS Firewall 규칙을 대규모로 중앙에서 구성하고 관리할 수 있습니다. 하지만 하이브리드 AWS 환경에서 온프레미스 워크로드도 포함하도록 DNS 보호 범위를 확장해야 한다면 어떻게 해야 할까요? 이 포스트에서는 AWS DNS Firewall 보호를 온프레미스 워크로드로 확장하여 하이브리드 AWS 환경 전반에 걸쳐 통합되고 일관된 보안 정책을 제공하는 방법을 보여줍니다. 통합된 DNS 필터링 솔루션으로 보안 태세를 강화하고, 규정 준수를 유지하며, 운영 오버헤드를 줄이는 방법을 보여드립니다.

하이브리드 AWS 환경을 위한 DNS 보호 범위 확장

Route 53 Resolver DNS Firewall을 구성하여 AWS 워크로드를 보호하고 조직의 보안 정책에 따라 DNS 쿼리를 필터링한 후, 이 보호를 하이브리드 AWS 환경으로 확장할 수 있습니다. 이 확장을 구현하려면 온프레미스 DNS 서버가 직접 관리하지 않는 모든 도메인에 대해 Amazon Route 53 Resolver 인바운드 엔드포인트로 DNS 쿼리를 전달하도록 구성해야 합니다. 이러한 DNS 쿼리는 퍼블릭 인터넷(Public Internet) 또는 Route 53 Resolver 인바운드 엔드포인트가 포함된 VPC에 프라이빗 네트워크 연결을 통해 전달될 수 있습니다. 다음 섹션에서는 이 두 가지 연결 옵션에 대해 자세히 설명합니다.

AWS Direct Connect 또는 AWS Site-to-Site VPN을 통한 프라이빗 연결

온프레미스 환경과 AWS 간에 프라이빗 연결이 가능한 경우, 프라이빗 네트워크 연결을 통해 보안 DNS 쿼리 전달을 구성할 수 있습니다. 온프레미스 DNS 서버는 AWS Direct Connect 또는 AWS Site-to-Site VPN을 통해 Route 53 Resolver 인바운드 엔드포인트로 DNS 쿼리를 전달합니다. 이 통신 채널을 더욱 보안하기 위해 Direct Connect와 Site-to-Site VPN을 결합하거나, Direct Connect 연결에서 MAC Security를 활성화하는 등의 추가 조치를 취할 수 있습니다.

그림 1: Site-to-Site VPN 또는 Direct Connect를 통한 보안 DNS 쿼리

그림 1은 Direct Connect 또는 Site-to-Site VPN을 통한 보안 DNS 쿼리의 흐름을 보여줍니다:

1.     사내(Corporate) 워크스테이션이 데이터 센터에 위치한 내부 DNS 서버에 DNS 쿼리를 시작합니다.

2.     내부 DNS 서버가 AWS의 Route 53 Resolver 인바운드 엔드포인트로 DNS 쿼리를 전달합니다.

3.     DNS 쿼리는 Direct Connect 또는 Site-to-Site VPN을 통해 Customer Gateway와 AWS Virtual Private Gateway를 거쳐 라우팅됩니다.

4.     필요한 DNS 프로토콜 표준을 유지하는 Route 53 Resolver 인바운드 엔드포인트가 DNS 쿼리를 수신합니다.

5.     Route 53 Resolver DNS Firewall 규칙이 DNS 쿼리를 허용할지 차단할지 결정하고 의심스러운 도메인에 대한 쿼리를 로깅합니다.

6.     Route 53 Resolver DNS Firewall이 쿼리를 차단하지 않을 경우, Route 53 Resolver가 DNS 쿼리를 처리합니다: Amazon Route 53 Private Hosted Zones(PHZ)의 도메인이라면, Resolver는 PHZ를 통해 쿼리를 직접 처리합니다. 외부 도메인일 경우, Resolver는 응답을 얻기 위해 외부 네임 서버로 쿼리를 전달합니다. 이후 응답이 동일한 경로를 역순으로 거쳐 클라이언트로 반환됩니다.

인터넷 경계(Internet-Facing) AWS Network Load Balancer 기반 퍼블릭 연결

프라이빗 연결이 불가능한 시나리오의 경우, 인터넷 경계 AWS Network Load Balancer(NLB)를 통해 DNS 쿼리를 Route 53 Resolver 인바운드 엔드포인트로 라우팅할 수 있습니다. NLB는 온프레미스 DNS 서버에서 인바운드 엔드포인트로 DNS 쿼리를 전달하며, 유입 트래픽은 NLB의 보안 그룹에서 소스 IP 제한을 통해 보호됩니다. NLB는 일반적인 공격에 대한 기본 DDoS 보호를 제공합니다. 추가 보안 계층이 필요하다면, NLB 리소스에 AWS Shield Advanced를 활성화할 수 있습니다.

그림 2: 퍼블릭 인터넷을 통한 보안 DNS 쿼리

그림 2는 인터넷 경계 NLB를 통한 보안 DNS 쿼리의 흐름을 보여줍니다:

1.     사내(Corporate) 워크스테이션이 데이터 센터에 위치한 내부 DNS 서버에 DNS 쿼리를 시작합니다(프라이빗 연결 흐름과 동일).

2.     내부 DNS 서버가 인터넷 경계 NLB의 퍼블릭 IP 주소로 DNS 쿼리를 전달합니다.

3.     DNS 쿼리는 퍼블릭 인터넷을 통해 사내 Network Address Translation(NAT) IP 주소와 Internet Gateway(IGW)를 거쳐 라우팅됩니다.

4.     인터넷 경계 NLB가 DNS 쿼리를 수신하고 이를 프라이빗 서브넷 내 서로 다른 AWS 가용 영역(AZ)에 위치한 Route 53 Resolver 인바운드 엔드포인트의 Elastic Network Interface(ENI) 중 하나로 라우팅합니다. 이 ENI들은 NLB 타겟 그룹(UDP/TCP Port 53)에 IP 대상으로 설정되어 있습니다. 또한 DNS over HTTPS(DoH)를 사용하도록 구성해 웹 기반 보안 제어를 제공할 수도 있습니다.

5.     필요한 DNS 프로토콜 표준을 유지하는 Route 53 Resolver 인바운드 엔드포인트가 DNS 쿼리를 수신합니다(프라이빗 연결 흐름과 동일).

6.     Route 53 Resolver DNS Firewall 규칙이 DNS 쿼리를 허용할지 차단할지 결정하고 의심스러운 도메인에 대한 쿼리를 로깅합니다(프라이빗 연결 흐름과 동일).

7.     Route 53 Resolver DNS Firewall이 쿼리를 차단하지 않을 경우, Route 53 Resolver가 DNS 쿼리를 해석하고, 이후 동일한 경로를 역순으로 거쳐 클라이언트에 응답을 반환합니다(프라이빗 연결 흐름과 동일).

하이브리드 DNS 보호 솔루션을 위한 설계 고려사항

하이브리드 DNS 보호 솔루션을 설계할 때는 아키텍처의 전반의 여러 측면에서 상충되는 우선순위를 균형 있게 고려해야 합니다.

확장성 측면에서, 솔루션은 DNS 쿼리 볼륨을 효율적으로 처리할 수 있어야 합니다. NLB는 초저지연(ultra-low latency) 상태에서 초당 수천만 건의 요청을 처리할 수 있습니다. Route 53 Resolver 엔드포인트는 온프레미스 DNS 쿼리 볼륨과 서비스 할당량을 고려해 적절한 수의 ENI로 구성해야 합니다. 또한 DNS 쿼리 성능은 쿼리 유형, 응답 크기, 대상 네임 서버의 상태, 응답 시간, 왕복 지연(latency) 시간, 사용된 프로토콜 등에 따라 달라집니다.

고가용성을 위해서는 먼저 워크로드 요구사항을 평가해야 합니다. 미션 크리티컬한 온프레미스 워크로드가 외부 종속성을 감내할 수 없다면, 하이브리드 DNS 보호 대상을 최종 사용자 장치(end-user devices)로 한정할 수도 있습니다. NLB와 Route 53 Resolver 엔드포인트의 ENI는 여러 AZ에 분산 배치하고, Site-to-Site VPN 또는 Direct Connect 연결도 이중화해야 합니다. DNS Firewall의 장애 시 동작(failure mode)에 따라, 평가 불가 상태일 때는 기본적으로 쿼리를 차단합니다. 특정 가용성 요구사항과 위험 평가에 따라 이 설정을 조정해야 할 수 있습니다. 퍼블릭 연결 옵션을 사용할 경우, 비용 대비 가용성 요구를 고려해 AWS Shield Advanced 활성화를 검토할 수 있습니다. 자세한 내용은 How to achieve DNS high availability with Route 53 Resolver endpoints을 참조해주십시오.

성능 요구사항은 지리적 분포에 크게 의존합니다. 전 세계적으로 분산된 사용자나 원격 지점이 있다면, AWS Global Accelerator를 통해 DNS 해석 성능을 개선할 수 있습니다(퍼블릭 연결 옵션 사용 시 자세한 내용은 Use AWS Global Accelerator to improve application performance 참조). VPN 연결의 지연을 줄이려면 Site-to-Site VPN Accelerator를 활용할 수 있습니다. NLB를 보안 그룹과 함께 사용할 때는, 연결이 자동으로 추적됨(Amazon EC2 보안 그룹 연결 추적)에 유의해야 합니다. 이로 인해 IP 주소당 초당 최대 쿼리 수가 줄어들 수 있으며(Route 53 Resolver 엔드포인트 서비스 할당량), 이러한 성능 영향을 보안 요구사항과 비교해 평가해야 합니다. 또한 DNS 프로토콜(UDP, TCP, DNS over HTTPS) 선택에 따라서도 성능과 처리량이 달라집니다. 온프레미스 DNS 서버의 캐싱 및 TTL 값을 조정해 응답 시간과 데이터 신선도 간의 균형을 맞출 필요가 있습니다.

보안 측면에서는 위협 모델에 기반한 조치가 필요합니다. NLB에 보안 그룹을 적용하면 소스 IP 제한을 통해 인가된 온프레미스 DNS 서버에서만 쿼리를 보낼 수 있도록 보호할 수 있습니다. 다만 이 구성에서느 연결 추적이 자동으로 활성화되어 DNS 쿼리 처리량에 영향을 줍니다. 성능 요구사항상 더 높은 처리량이 필요하고 위험 평가 결과가 이를 허용한다면, 하나의 완화 방안으로 보안 그룹 없이 NLB을 운영하고, 대신 VPC 네트워크 ACLs(Amazon VPC – Control subnet traffic with network access control lists)을 서브넷 수준에서 적용하여 소스 IP 주소를 제한하는 보완적 제어를 구현할 수 있습니다.

DNS 보안 제어에도 균형을 맞춰야 할 트레이드오프가 존재합니다. 퍼블릭 쿼리를 DNS 스푸핑으로부터 보호하기 위해 DNSSEC 검증(Amazon Route 53 DNSSEC 검증 활성화)을 고려할 수 있지만, 이는 운영 부담을 염두에 두어야 합니다..

DNS 프로토콜 선택 또한 보안과 성능 간의 또 다른 트레이드오프를 의미합니다. 기본 UDP 기능부터 암호화된 DNS over HTTPS까지 선택에 따라 영향을 미칩니다.

또한 가용성과 보안의 균형을 고려할 때, Route 53 Resolver DNS Firewall의 장애 시 동작(failure mode) 설정 역시 중요한 결정 사항입니다. 기본값은 “차단(closed)” 모드로, 쿼리를 평가할 수 없는 경우 차단합니다. 이는 보안을 강화하는 설정이지만, 가용성 요구사항과의 균형 또한 고려해야 합니다.

이러한 아키텍처적 고려사항들은 하이브리드 DNS 보호 솔루션을 구현할 때, 확장성, 고가용성, 성능, 그리고 보안 요구사항을 균형 있게 충족하는 데 도움을 줍니다.

대규모 하이브리드 DNS 보호 관리

그림 3에서 보는 바와 같이, AWS Security Hub, Firewall Manager 및 Route 53 Resolver DNS Firewall을 사용하여 다중 계정 AWS 환경에서 여러 VPC에 DNS 쿼리 보호를 중앙에서 일관되게 관리하고 거버넌스를 수행할 수 있습니다. 이 솔루션의 주요 측면은 다음과 같습니다:

l  모든 보안 정책을 포함하는 DNS Firewall 규칙 그룹(rule group)을 Security Tooling/Audit 계정에서 생성합니다.

l  Firewall Manager 보안 정책을 통해 DNS Firewall 규칙 그룹을 여러 AWS 계정의 VPC에 중앙에서 배포하고 강제할 수 있습니다.

l  Security Hub는 Firewall Manager에서 수집한 DNS Firewall 정책 준수 여부를 비롯한 다양한 소스의 결과를 통합해 보안 태세를 종합적으로 제공합니다. 만약 VPC가 Firewall Manager 정책에 정의된 필수 DNS Firewall 규칙 그룹과 연결되지 않은 경우, Security Hub는 이를 보안 발견 항목으로 표시합니다. 이를 통해 조직 전체의 DNS 보호 공백을 중앙에서 한눈에 파악할 수 있습니다.

l  워크로드 VPC 내 AWS 리소스(예: Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스)에서 발생한 DNS 쿼리는 VPC+2 IP 주소로 라우팅되며, 여기서 Route 53 Resolver가 연결된 DNS Firewall 규칙 그룹을 적용합니다.

l  온프레미스에서 발생한 DNS 쿼리는 NLB을 사용한 퍼블릭 인터넷 또는 Direct Connect나 Site-to-Site VPN 사용한 프라이빗 연결을 통해 하이브리드 DNS 보호 계정의 VPC 내 인바운드 엔드포인트로 라우팅됩니다. 여기서 Route 53 Resolver가 동일한 DNS Firewall 규칙 그룹을 적용합니다.

그림 3: 다중 계정 환경에서 온프레미스 및 VPC DNS 쿼리 보안

이 포스트에서는 Amazon Route 53 Resolver DNS Firewall 보호 범위를 AWS 환경을 넘어 하이브리드 인프라 전반으로 확장하여, 통합된 DNS 보안 전략을 구축하는 방법을 소개했습니다. 프라이빗 연결(AWS Direct Connect 또는 AWS Site-to-Site VPN 사용) 또는 퍼블릭 연결(AWS Network Load Balancer 사용) 중 어느 것을 선택하더라도, 전체 네트워크 전반에 일관된 DNS 필터링 정책을 적용하면서 운영 효율성을 유지할 수 있습니다.

소개한 아키텍처는 여러 전략적 이점을 제공합니다. AWS Firewall Manager를 통한 중앙집중식 DNS 방화벽 관리, AWS 및 온프레미스 워크로드 전반에서의 일관된 정책 적용, 유연한 연결 옵션, 그리고 다중 계정 AWS 환경을 지원하는 엔터프라이즈급 확장성을 확보할 수 있습니다. 점점 정교해지는 DNS 기반 위협에 대응하기 위해 이 하이브리드 DNS 보호 솔루션은 DNS 터널링, 도메인 생성 알고리즘 및 기타 DNS 기반 공격으로부터 조직을 효과적으로 방어하는 데 도움을 줍니다. 또한 본문에서 다룬 아키텍처 고려사항을 따르면, 가용성, 성능 및 보안 요구사항에 부합하는 견고한 DNS 보안 프레임워크를 구축하여 하이브리드 인프라의 보안 태세를 한층 강화할 수 있습니다.

질문이 있으시면 Amazon Route 53 Resolver DNS Firewall re:Post에서 새 스레드를 시작하거나 AWS 지원에 문의하십시오.