Transit Gateway를 통한 다중 VPC 연결 기반, AWS Network Firewall의 Centralized 구성
1. Introduction
AWS는 네트워크 관련한 매우 다양한 서비스를 제공하고 있으며, 각 서비스는 명확한 목적과 기능을 갖추고 있습니다.
이를 통해 사용자는 매우 다양한 형태의 아키텍처를 구현할 수 있습니다.
또한, 모든 시스템은 보안에 대한 고려사항 검토와 역할에 따른 서비스 구성이 필수적으로 수행되어야 합니다.
이를 위해 네트워크 아키텍처의 고려 단계에서 부터 인터넷 접점, 온프레미스 데이터 센터 접점, 각 VPC간 접점 등의 위치마다 역할 별 보안 서비스의 배포를 고려 해야 하며 이를 네트워크 아키텍처에 적절히 반영해야 합니다.
하지만 각 위치마다 보안 서비스를 배포하면 이는 동일한 서비스의 중복 배포를 야기 시킬 수 있고 이는 아키텍트 및 비용 효율성에 부정적인 영향을 줄 수 있습니다.
이를 해결하기 위해 중앙 집중화된(Centralized) 아키텍트를 구현하여 네트워크 효율성과 보안 서비스 구성을 동시에 달성할 수 있습니다.
네트워크와 보안 관련 다수의 서비스가 구현되면 구조가 복잡해 보이고 이해하기 어려울 수 있습니다. 하지만 원칙을 이해하면 손쉬운 이해가 가능하며 아키텍트의 응용 또한 가능해집니다.
Transit Gateway를 통한 다중 VPC 연결 기반, AWS Network Firewall의 Centralized 구성을 통해 (1) 네트워크 서비스의 배포 및 라우팅 구성 과 (2) AWS Network Firewall의 Ruleset 특징에 대해 알아보겠습니다.
2. Service
* Keyword
(1) 다중 VPC 연결의 네트워크 서비스의 배포 및 라우팅 구성을
(2) AWS Network Firewall의 Standard statefule rule 적용
* 핵심 서비스
(1) VPC , Subnet , route tables , NAT Gateway
(2) Transit Gateway , Transit Gateway Attachment, Transit Gateway route tables
(3) AWS Network Firewall
3. Architecture
* 아키텍처 구성
1. Transit Gateway로 연결된 다수의 VPC (transit gateway 통신의 완전한 방향성 통제를 위해 propagation 사용 X)
2. Internet gateway는 오직 Ingress / Egress용 VPC 에만 할당
3. Ingress/Egress의 통제를 위해 VPC Network Firewall이 구성된 Centralized VPC
우리가 처음 가보는 곳을 갈 때, 지도를 들고 있다고 가정해보겠습니다.
처음부터 도착지를 보고 가는 것이 아니라,
가까운 버스정거장, 그 다음 지하철, 몇 번째 출구, 출구에서 어느 방향으로 이동을 단계별로 이동하게 됩니다.
routing은 언제나 Next Hop을 지정합니다. 도착점인 Destination을 한번에 보는 것이 아니라, 그 다음 갈 곳(hop) 을 지정합니다.
SVC VPC 에서 인터넷을 통해 나가는 서비스는 Ingress / Egress 통신이 모두 AWS Network Firewall을 통과 해야 합니다
이는 Return Packet 도 동일하며, 양 방향 중 한 방향이 다르게 지정된 경우 Asynchronous 통신 발생으로 정상 서비스 구현되지 않습니다
Asynchronous가 나지 않도록 라우팅을 구성하는 것이 매우 중요합니다.
1. VPC-NFW-1는 AWS Network Firewall의 endpoint가 구성된 SBN-NFW-1 subnet과 Transit Gateway Attachment가 구현된
SBN-INT-1/2 로 구성되어 있습니다.
SVC용 VPC에서 Internet으로 나가는 Egress 통신은 TGW를 통해 NFW VPC로 들어옵니다
따라서 TGW Attachment가 있는 SBN-INT-1/2의 라우팅은 0.0.0.0 (인터넷) 연결이 NFW Endpoint를 향해야 합니다
패킷의 최종 Destination이 NFW 인 것이 아니라, 라우팅을 통해 NFW를 반드시 “통과하도록” 라우팅을 지정하는 것이며
return으로 SVC로 돌아오는 패킷 또한 동일하게 NFW를 “통과하도록” 해야합니다.
2. 2,3 역시 1과 같이 모두 NFW를 통과 해야합니다. 3번의 경우 SVC용 VPC간 통신 역시, Centralized 된 NFW를 통과해야합니다.
3. 4 인터넷을 통해 들어온 Ingress 패킷은 NFW를 통해 SVC VPC로 향해야 합니다.
따라서 Ingress VPC 내 route tables은 TGW를 다음 hop으로 지정합니다.
그리고 TGW route table은 SVC로 향하는 패킷을 NFW VPC로 가도록 지정합니다.
* 라우팅 순서
Ingress VPC > (subnet routing) > Ingress VPC TGW Attachement > (TGW routing) > NFW VPC TGW Attachement > (subnet routing) > NFW Endpoint
4. 5,6 SVC VPC의 TGW routing은 인터넷 및 Egress VPC로 향하는 패킷이 모두 NFW VPF Attachment로 향하도록 지정해야합니다.
4. Ingress / Egress Network Flow
Network Flow의 상세 정의 입니다.
1. EC2 > SVC-1 subnet route table > SVC TGW Attachment > TGW
2. TGW > SVC TGW Route table > NFW VPC TGW Attachment > SBN-INT-1/2 subnet route table > NFW endpoint
3. NFW endpoint > SBN-NFW-1/2 route table > NFW VPC TGW Attachment > TGW
4. TGW > NFW TGW Route table > VPC Egress TGW Attachment
5. VPC Egress TGW Attachment > VPC Egress Subnet route table > Internet Gateway
Ingress 역시 위 1 ~ 5 순서의 역방향으로 라우팅 정의에 따라 통신이 수행되어야 합니다.
5. AWS Network Firewall 구성
테스트를 위해 구성한 AWS Network FIrewall 은 Stateful rule groups / standard stateful rule 을 적용했으며
AWS Network Firewall 관련 상세 구성은 별도 기회에서 더 깊게 다루겠습니다.
실습 이미지
적용된 Policy는 ICMP와 SSH에 대한 통신만 허용(Pass) 입니다.
위 아키텍처와 같이 라우팅이 구성된 상태에서, Egress VPC에서 생성된 EC2
에서 SVC VPC 내 존재하는 EC2로 SSH 접속 테스트 한 화면은 아래와 같습니다.
SSH를 통한 접속이 정상적으로 완료되었음을 볼 수 있습니다.
이 상태에서 SSH 허용 rule을 삭제했습니다. ICMP만 허용한 상태입니다.
위 상태에서 다시 수행한 EC2 접근 테스트 입니다.
SSH를 통한 접속은 실패 했으며 ICMP 의 Ping은 여전히 정상임을 확인할 수 있습니다.
6. Result
네트워크 구성에 대한 자세한 설명과 더불어 AWS Network Firewall 서비스를 통해 네트웍과 보안 구성이 동시에 적용된 아키텍트에 대한 학습과 실습을 수행했습니다.
중요한 3가지를 꼭 기억해주십시오
(1) Routing은 Subnet 에 적용되는 subnet route 와 TGW Attachment 에 적용되는 TGW route table이 있습니다. 그 2가지 조합을 통해 통제된 네트워크 라우팅 구성이 가능합니다.
(2) NFW 로의 강제 라우팅을 통해 Centralized 구성이 가능하며 NFW 의 Stateless/Stateful ruleset을 통해 다양한 네트워크 통제가가능합니다.
(3) 인터넷 Ingress/Egress 및 VPC 간 통신도 모두 Centralized NFW를 통과해야하며, NFW VPC는 subnet 간 라우팅이 다르게 적용되어야 합니다.
감사합니다!
