[Report] 더욱 진화하는 AWS 네트워크 보안 #AWSSummit

올해 5월 12일~13일 AWS Summit Online Korea 가 개최되었었습니다.
작년과 동일하게 온라인으로 개최되었으며 다양한 세션에서 깊이 있는 강연을 볼 수 있었습니다.
그 중 제가 보았던 <더욱 진화하는 AWS 네트워크 보안> 세션에 대해 리뷰를 해보고자 합니다.
(본 레포트에 사용된 이미지는 별도의 설명이 없다면 해당 세션의 이미지임을 알립니다.)

개요

Amazon VPC 내의 주요 자원을 보호하거나 규정 준수를 위해 사용되어야 하는 보안 어플라이언스의 효율적인 구성을 돕는 AWS Gateway Load Balancer의 사용 방법과 동작 원리를 알려 드립니다. Amazon VPC 내부에서 인터넷 사이트의 접근을 제한하거나 외부로부터의 침입 탐지 및 차단 기능을 사용할 수 있는 IPS 기능을 포함하는 AWS의 관리형 방화벽인 AWS Network Firewall 의 사용 방법과 구성 가능한 다양한 레퍼런스 케이스에 대해서도 설명해 드립니다.

• 발표자
  • 신은수, 시큐리티 스페셜리스트 솔루션즈 아키텍트, AWS
• 난이도
  • 중급 난이도

AWS에서 사용자가 이용할 수 있는 네트워크 보안 기능 중 Gateway Load Balancer와 Network Firewall을 소개하는 강연입니다.
무엇을 개선하기 위해서 서비스를 사용하는지 어떤 식으로 서비스가 적용되는지 등을 이해할 수 있었기 때문에 서비스 이해에 큰 도움이 되었습니다.

강연 리뷰

시작하며

개인정보보호나 규정 준수를 위해 침입차단솔루션(IPS)을 구축하여야 하는데 AWS 환경에서는 어떻게 해야 하나요?

강연의 서두에 제시된 이 의문은 강연에서 설명할 서비스의 사용 이유를 설명합니다.
네트워크 보안 요구 사항에는 네트워크 모니터링 및 제어, 침입 탐지/차단 시스템 구성, 도메인기반 인터넷 접속 제어 등 다양한 요구 사항이 있지만 이 중 인터넷 접속 제어를 위해 AWS 상에서 어떻게 구축할 수 있는지 이번 강연에서 알아봅니다.

Gateway Load Balancer(GWLB)

GWLB가 출시되기 이전에도 보안 문제를 해결하기 위해 3rd 파티 솔루션과 AWS의 서비스들을 활용하여 각 요구 사항에 대응할 수 있었지만 번거로운 과정과 다양한 문제가 있었습니다.
사용하는 이유를 제대로 이해하기 위해 우선 이전에는 어떤 방식으로 구축해왔는지 알아봅니다.

Active - Passive 방식

별도의 ELB 없이 보안 솔루션을 Active-Passive 방식으로 구축한 방식입니다.
보안 솔루션의 Fail Over 발생 시 세션 단절은 최소화 할 수 있지만 ENI의 자동 변경 등 추가적으로 관리해야할 부분이 있었습니다.
또한 로드 밸런서가 없기 때문에 자동 확장하기 어렵고 Fail Over가 제대로 관리되지 않는다면 단일 장애가 전체 서비스 장애로 이어지는 등의 문제가 있었습니다.

ELB 구성

로드 밸런서의 헬스 체크를 활용하여 단일 장애 문제를 해결하고 필요시 확장 기능을 활용할 수 있도록 구성한 방식입니다.
하지만 이 방식은 EC2에서 수신하는 트래픽의 IP 주소는 보안 솔루션의 IP 주소로 인식되기 때문에 클라이언트 IP의 주소를 확인하기 힘들다는 문제점이 있습니다.

GWLB 구성

이러한 문제점들을 개선한 구성이 GWLB를 사용한 구성입니다.
기존의 로드 밸런스들과 똑같이 로드 밸런싱이 가능하며 특이한 점으로는 GWLB의 엔드 포인트가 따로 필요하다는 점입니다.
그리고 사용자 트래픽의 캡슐화를 위해 GENEVE라는 터널링 프로토콜을 사용합니다. 따라서 솔루션에 사용되는 EC2가 이 프로토콜을 지원해야합니다.

GWLB의 트래픽 흐름과 설정

이미지만으로도 트래픽의 흐름이 이해를 할 수 있었습니다.
엔드포인트와 로드 밸런서를 거치면서 트래픽이 캡슐화가 되고 이를 통해 프라이빗 EC2가 해당 트래픽을 수신하더라도 클라이언트 IP를 로깅 할 수 있습니다.

또한 GWLB를 사용하기 위해서는 이미지와 같은 구성이 필요하며 특히 igw와 GWLB의 엔드 포인트, 퍼블릭 서브넷의 ingress의 설정에 주의가 필요합니다.

Network Firewall

AWS의 새로운 관리형 방화벽 서비스이며 주요 보안 기능으로는 다음과 같습니다.

그리고 Cloudwatch를 통하여 매트릭 정보나 로그 정보를 수집/분석 할 수 있습니다.
다른 서비스에서 로그를 활용하는 방식과 마찬가지로 Kinesis에 로그를 보내거나 Athena를 통해 분석하는 등의 활용도 가능합니다.

기존 보안 기능과의 비교

Network Firewall과 가장 비슷한 기존 기능으로는 NACL과 SG의 조합이며 각각 Stateless engine과 Stateful engine에 대응됩니다.
각 엔진을 간략하게 설명하자면 Stateless engine의 액션은 다음과 같으며 NACL과는 다르게 forward 액션이 가능합니다.

• pass : 패킷 검사를 종료하고 타겟으로 바로 전송
• drop : 패킷 검사를 종료하고 접속 차단
• forward : stateless engine 의 검사를 종료하고 stateful engine으로 전송

Stateful engine는 액션 중 pass 와 drop은 동일하며 alert는 패킷은 통과하지만 경보를 설정하는 액션입니다.
또한 SG와는 다르게 프로토콜, IP, 포트 뿐만이아니라 5 튜플이나 도메인이나 Suricata 등의 IPS 정책도 지원합니다.
비교해보면 Network Firewall을 사용하는 것이 좀 더 많은 기능을 지원한다는 것을 알 수 있습니다.

Network Firewall의 라우팅 흐름

Network Firewall을 사용하게 되면 자동으로 GWLB를 사용하도록 구성됩니다.
그리고 라우팅의 흐름은 이전에 설명한 3rd 파티 솔루션과 GWLB를 사용한 구성에서 솔루션을 대신한 구성과 같습니다.
다만 사용자가 로드 밸런서나 엔드 포인트를 생성하지 않더라도 AWS에서 자동으로 생성해줍니다.
GWLB를 사용하기 때문에 위에서 설명한 ingress의 수정 작업은 필요합니다.

엔진의 규칙 설정

Stateless engine의 규칙 설정은 이미지로 모두 설명이 되기 때문에 자세한 설명은 넘어가겠습니다.

Stateful engine은 다음의 3 가지 rule group을 설정할 수 있으며 각 그룹마다 설정 방법이 조금씩 다릅니다.

• 5-Tuple : Protocol, IP, Port 정보를 기준으로 허용/차단
• Domain List : Host Header 나 SNI 정보를 기준으로 허용/차단
• Suricata compatible IPS rules : 사용자 정의 Signature 를 기반으로 허용/차단

각 그룹의 설정 방법은 다음과 같습니다.

엔진의 규칙 검사

트래픽을 수신하고 이를 검사하는 순서는 다음과 같습니다.

규칙은 다음과 같은 원칙이 있습니다.

• 모든 트래픽은 Stateless engine이 먼저 처리합니다. -- 수신한 트래픽이 매칭되는 커스텀 규칙이 없다면 default 규칙으로 처리됩니다.(초기 설정은 forward 입니다)
• Stateful engine은 pass 규칙 > drop 규칙 > alert 규칙 순서로 우선순위가 결정됩니다. -- 이 또한 매칭되는 규칙이 없으면 default 규칙인 pass 로 처리됩니다.

리포트 마무리

접속 차단을 위해 NACL과 SG만을 구상하고 있었지만 다른 옵션을 고려할 수 있게 되었습니다.
이번 세션에서 설명한 두 서비스 모두 별도로 비용이 청구되니 도입을 고민하고 계시다면 꼭 확인해보시길 바랍니다.