
1. INTRO
네트워크의 가용성과 보안을 높이기 위한 방법 중 하나로 UTM(Unified Threat Management, 통합 위협 관리 시스템) 장비의 이중화 구성이 있습니다. 이중화 구성은 단일 장애 지점을 제거하고, 장애 발생 시에도 서비스가 지속적으로 운영되도록 합니다. 3rd-party UT 장비의 이중화 구성은 일반적으로 Active/Passive 이중화(하나의 UTM 장비가 활성 상태(Active)로 작동하고, 다른 하나는 대기 상태(Passive)로 작동하며 활성 장비에 장애가 발생하면 대기 장비가 자동으로 활성화 되는 것) 또는 Active/Active 이중화(두 UTM 장비가 동시에 활성 상태로 작동하고 트래픽을 분산 처리하면서 하나의 장비에 장애가 발생하면 나머지 장비가 모든 트래픽을 처리하는 것)로 구성됩니다.
이번 글에서는 AWS 상에 3rd-party UTM 장비로 인터넷 Outbound(데이터가 서버 밖으로 나가는 경우) 통신을 Active/Active 구성한 경우의 아키텍처 이중화 구성 방법과 UTM 장비 장애 시 Lambda 등의 AWS 서비스를 통한 자동 FailOver(장애 조치 기능, 시스템 장애 이벤트 발생 시 하나 이상의 예비 백업 시스템으로 자동 전환 되는 것) 설정 방법을 알아보겠습니다..
2. 3rd-party UTM 이중화 아키텍처
1) 참고 구성
인터넷 접점을 위한 External VPC(Virtual Private Cloud, 사용자가 정의한 독립된 가상의 네트워크)를 생성하고, 해당 VPC 내 각각의 Zone에 UTM을 이중화해 구성합니다. 이번 글에서는 UTM을 통한 인터넷 Outbound 통신 FailOver를 위한 Lambda 설정을 살펴볼 예정인데요. 실제 다양한 용도로 사용되는 여러 개의 Internal VPC의 자원들이 한 세트의 UTM을 통해 인터넷으로 통신하는 구성을 가정했습니다.
UTM은 인터넷 통신 시 NAT(Network Address Translation, 네트워크 주소 변환)를 포함해 방화벽 정책이나 IPS(Intrusion Prevention System , 침입 방지 시스템) 기능을 통한 트래픽 보안 모니터링/제어를 위해 [그림 1]처럼 External VPC의 Public Subnet(외부에서 접근이 가능한 네트워크 영역)과 Private Subnet(외부에서 접근이 불가능한 네트워크 영역)에 인터페이스를 구성해 통신 패킷을 통과시키도록 설정합니다. 이때, Internal VPC와는 Transit Gateway(서로 다른 VPC간에 통신이 가능하게 하는 서비스)를 통해 연결되기 때문에 모든 VPC간 통신이 가능하도록 설정합니다. 보안상 이슈가 없도록 Internal VPC에는 Internet Gateway(VPC와 인터넷 간에 통신할 수 있게 해주는 VPC 구성요소)를 연결하지 않으며, 인터넷에서 또는 VPC를 통해 직접 접근이 불가능하도록 설정합니다. 이 과정에서 IP 대역은 임의로 할당됐습니다.

2) 인터넷 통신 경로 (Route Table)
[그림 2]는 인터넷 통신을 하기 위해 각각의 VPC내 Subnet의 Route Table(VPC에 존재하는 서브넷들이 특정 범위의 IP 목적지를 향할 때, Target을 정해주는 역할을 수행)에 어떤 라우팅이 필요한지 간략하게 기입한 그림입니다. 일반적으로 인터넷 통신은 0.0.0.0/0 디폴트 라우팅 설정에 따라 이뤄집니다. 아래 External VPC의 Private Subnet에 연동된 Route Table 설정을 보면, 각각의 Subnet에 도달한 패킷은 UTM을 통과하기 위해 UTM 1번 또는 UTM 2번과 같이 한쪽으로만 통신할 수밖에 없습니다. 따라서 Route Table 설정이 그대로일 때 특정 UTM이 문제가 생긴다면, 문제가 생긴 UTM 하단으로 올라온 인터넷 통신용 트래픽은 통신 불가능한 상태가 됩니다.

이 부분에서 Lambda 서비스를 통해 UTM의 문제를 인지하고, 이후 정상 UTM으로 인터넷 통신이 이뤄질 수 있도록 설정 변경이 필요합니다. Subnet의 라우팅 설정 자체를 바꾸는 방식 보다 문제가 없는 Zone Subnet의 Route Table을 변경하는 심플한 방식을 선택했습니다. 상세한 동작 방식은 아래에서 살펴보겠습니다.
3. FailOver 방식
1) UTM이 정상 동작하는 경우

FailOver를 위해서는 먼저 UTM의 상태가 정상인지 체크해야 합니다. 각각의 UTM은 UTM 기능 동작을 위한 데몬을 특정 TCP(Transmission Control Protocol, 서버와 클라이언트간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜) 포트로 서비스하는데요. 벤더에 따라 각각의 TCP 포트를 통해 UTM 상태체크가 가능하도록 Lambda 설정을 변경합니다.
2) UTM 장애 시 (1번)

[그림4] 1번 UTM에 장애가 발생하게 되면, TCP 포트 확인이 불가하게 됩니다. 이를 인지한 Lambda에서 해당 UTM이 속한 Zone의 Subnet(네트워크 내부의 네트워크)에 Associated Route Table을 2번 UTM이 있는 Route Table로 변경하도록 API를 호출합니다. 이렇게 Route Table이 변경되면, 해당 Route Table의 0.0.0.0/0 디폴트 라우팅 Target인 정상 UTM 쪽으로 통신이 일어나게 됩니다. 이 과정에서 1분 이내의 서비스 단절이 있을 수 있으나 인터넷 통신이 우회되며 정상화됩니다.
3) UTM 장애 시 (2번)

2번 UTM 장애 상황에서도 동작 방식은 2) UTM 장애 시 (1번)과 동일합니다.
4. Lambda 설정 상세
1) SNS → Topic 설정 방법
UTM 장애가 발생해 Lambda가 동작하면, 운영자는 이를 인지할 수 있어야 합니다. Route Table의 수동 원복이 필요하기 때문인데요. 운영자가 SNS(Simple Notification Service, 게시자로부터 구독자(생산자 및 소비자)에게 메시지를 전달하는 관리형 서비스)로 AWS 알림을 받아 볼 수 있도록 Lambda 설정 변경 방법을 [그림 6 ~ 그림 9]를 통해 알아보겠습니다.




해당 과정을 완료 후 운영자가 입력된 Email 주소로 발송되는 메일을 확인해 Confirm한 뒤 SNS 설정을 완료합니다.
2) Lambda Function에서 사용할 Python 코드 작성
이번 글에서는 Python을 활용해 UTM 상태를 체크하고, 문제 발생 시 Route Table을 변경해 운영자에게 Email을 발송하는 SNS 호출 코드를 작성해보겠습니다.



3) Lambda 실행을 위해 필요한 권한 IAM → Role 설정
Lambda가 실행되는 과정에서 Route Table 변경 및 SNS 발송을 위한 API 호출이 필요한데요. 이를 위한 IAM → Role 설정을 알아보겠습니다.

[그림 13]


4) AWS Service API 호출을 위한 VPC endpoint 설정
AWS의 API 호출은 Public 통신으로, VPC 내부에 Lambda를 생성하는 경우 Lambda의 API 호출 경로와 인터넷 통신 경로가 같아집니다. 따라서 UTM 장애 시 Lambda의 API 호출이 동작하지 않을 수 있어 VPC endpoint를 생성해 VPC에서 인터넷이 아닌 내부 API를 호출할 수 있도록 설정해야 합니다.
5) Lambda → Function 설정 (w/ CloudWatch)
[그림 16 ~ 24]을 통해 구체적인 Function 설정 방법을 알아보겠습니다.









5. OUTRO
AWS는 다양한 벤더사의 UTM 이미지를 제공하고 있어 사용자는 보안 향상을 위해 원하는 벤더의 UTM을 AWS VPC내에 구성해 사용할 수 있습니다. 최근에는 3rd-party UTM을 자체적으로 연동해 중앙 집중 관리 방식으로 별도 서비스를 런칭하거나, Gateway Load Balancer를 활용한 3rd-party UTM 연동 아키텍처 등 다양한 서비스를 제공하고 있습니다. 사용자는 각 서비스와 아키텍처의 장/단점, 비용, 요구사항 등을 검토해 최적의 사용 방안을 선택해 사용하면 됩니다.
[참고 문헌]
https://docs.aws.amazon.com/en_us/lambda
https://aws.amazon.com/network-firewall/features/?nc1=h_ls
