[ 머리말 ]
은행권에서 망분리는 매우 중요한 네트워크 요건입니다. 하지만 결국 네트워크의 안전을 위해서 내/외부망의 경로를 분리하는 건
꼭 은행권 만이 아니라, 다수의 서비스를 활용하는 고객에게 지켜져야 할 항목입니다.
보안이라는 건 때와 상황에 따라 레벨을 낮게, 불완전하게 가져갈 수 있는 것은 아닙니다.
이번 화에서는 TGW를 통해 랜딩존에서 구현되는 망분리 아키텍트와 , 이를 위한 라우팅 구성 방안등을 논의해 보겠습니다.
[ 핵심 구성 요건 ]
1. Landing Zone Architecture – Multi Account 기반의, Network account가 독립적으로 구현된 아키텍처
2. Multiple TGW 와 ip 기반으로 구성된 TGW Route
3. VPC 내 목표에 따라 분리된 Subnet 과 routing
[ 아키텍처 ]
On prem 에서 운영 VPC로 네트워크가 흐르기 위해선 다음과 같은 설정이 필요합니다.
(1) Direct Connect 전용선 > (2) Network Account/Internal VPC/Private routing > (3) TGW attachment routing 1 > (4) TGW > (5) PRD VPC / Internal VPC / Private routing입니다.
*Tips!
네트워크의 라우팅에 대해 이해하기 어려워하시는 분들이 있습니다. 라우팅은 네트워크의 흐르는 방향을 알려주는 길잡이입니다.
여러분들이 길을 찾아가실 때 휴대폰에 지도를 보시는 것과 같습니다.
“내가 있는 위치”에서 다음으로 가야 할 “위치”와 “가는 법”을 알려주는 것입니다.
예를 들어, 192.168.168.1로 가고 싶다면, tgw-111111로 가시오. 와 같습니다.
단, 구조 상 처음부터 끝점을 알려주는 것이 아니라 딱 환승해야 할 다음 위치까지만 보여주고 그곳에서 다음 위치를 알려준다라고 이해하면 됩니다.
(1) Public / Private VPC
Public VPC 와 Private VPC를 나누는 기준은 IGW의 연계 여부와, 0.0.0.0 라우팅의 존재 등 VPC를 활용하려는 목적과 그를 위한 설정으로 볼 수 있습니다. Public Subnet 과 Private Subnet 역시 동일합니다.
On-prem의 router에서 Direct Connect를 타고 Internal VPC로 연결
> On-prem의 router(물리적 장비) – Destination : AWS 대역 / Target : DirectConnect Network Partner의 Router 지정
> Direct Connect Network Partner ( Kinx, LGU+ ) 의 정보에 따라 생성된 VIF와 VPC 내 배포된 VPG(Virtual Private Gateway)의 할당, 연계
단 Direct Connect Gateway를 구성할 경우 특정 VPC, VGW가 아닌, DCG로의 연계 진행
Internet을 통한 외부 접속은 IGW를 타고 External VPC로 연결
> AWS내 리소스는 External VPC 내 Public Subnet을 통해 Public IP를 가지고 IGW로 이동
*Tips?
-Direct connect는 사설 network의 확장 개념입니다. 내부 routing 및 BGP 설정을 통해 사설 IP 대역으로 온프레미스와 VPC간 통신이 가능합니다.
DX 연결 시엔 DX network partner와 협력을 통해 구성해야 합니다. BGP 구성 및, Network Partner 가 보유한 장비와 연결을 위한 별도의 IP 설정 등
AWS 내부 설정이 아닌 추가 설정 사항이 존재합니다.
-IGW를 통한 인터넷 통신을 구성하려는 경우, 인터넷으로 나간 통신이 공인 router를 통해 주소를 찾아가고, 찾아오는 만큼 반드시 source / destination이 Public IP를 보유하고 있어야 합니다. Private IP를 보유한 채로는 인터넷 통신을 사용할 수 없습니다.
따라서 NAT Instance, NAT Gateway 또는 Internet facing ELB, Elastic IP 등 Public IP로 NAT를 걸어주거나 또는 source 자체가 Public IP를 보유하고 있어야 인터넷 통신이 가능합니다.
(2) VPC 내 Routing Table
VPC 내 Subnet은 단순하게는 Web-Was-DB 3티어에 맞춰 분할되어 있거나, Container 환경의 경우 Pod 전용 Network를 고려한 4개 subnet에 할당되는 등, 시스템의 특징에 따라 다양한 형태로 존재합니다.
Routing table은 그 목적에 맞춰 (1) Subnet 별로 분류하거나 (2) AZ 별로 분류하거나 (3) external / internal으로 나뉘어 구성할 수 있습니다. Routing table은 subnet 과의 연계 없이도 독립적으로 생성할 수 있기 때문에, 사용자의 판단에 의해 자유로운 구성이 가능합니다. 이 특징을 활용하여 네트워크 이중화 구성 시 Route table에 연계된 subnet을 변경하는 방식으로 활용할 수 있습니다.
Public VPC의 경우 Ext routing은 0.0.0.0 (internet) / IGW로 지정되어야 합니다.
Internet routing은 UTM과 같은 3rd party 보안 솔루션을 사용하느냐에 따라 달라질 수 있으며 이 경우 0.0.0.0의 도착점은 보안 솔루션의 ENI가 됩니다. NAT GW를 사용할 경우, 위의 아키텍처와 같이 0.0.0.0 / NAT GW로 지정됩니다. AWS 내부에 위치한 VPC 간 통신은 TGW로 destination이 지정됩니다.
예 ) 0.0.0.0 / NAT Gateway 192.168.0.0/24 / TGW ( internet )
* Tips !
내부망 / 외부망을 분리하기 위해 별도의 VPC를 만든 것처럼, TGW도 인터넷과 내부망을 나눠야 합니다. 그를 통해 네트워크 통신에 따른 완전 분리가 가능해집니다. 인터넷 접속을 위한 통신은 TGW(외부용) 내부망 통신을 위한 통신은 TGW(내부용)으로 라우팅을 해줘야 합니다.
Private VPC의 경우 단일 routing을 보유합니다. 외부가 존재하지 않기 때문입니다. AWS 간의 통신은 모두 TGW(내부용)으로 지정되어야 합니다.
* Tips!
여기서 주의해야 할 점은, 네트워크는 찾아오는 패킷이 있고 찾아나가는 패킷이 있습니다. 그러나 라우트 테이블은 1개입니다. 따라서 라우팅은 양쪽 방향성을 모두 정의하고 있어야 합니다.
예 ) On-prem 사설망 대역 / Direct connect 용 VGW
AWS 내부 대역 / TGW (내부용)
(3) TGW & TGW route table
TGW를 구현 시 주의해야 하는 점은 2가지가 있습니다.
Attachement를 어느 subnet에 연결했느냐와 TGW route tables의 설정입니다.
Attachment를 어느 subnet에 붙였는지는 해당 subnet을 통해 proxy 되어야 하는 연결의 경우 routing이 정확하게 정의되어야 합니다.
*Tips!
Public VPC의 경우 TGW attachment를 internal subnet에 붙이고 해당 subnet에 별도의 0.0.0.0 라우팅을 설정하지 않을 경우 인터넷 연결은 정상적으로 구현되지 않습니다.
잊지마세요! 라우팅은 그다음 도착지점만을 알려줄 뿐 최종 도착점을 찍어주지 않습니다.
TGW Attachment가 생성된 Subnet에서 패킷을 받아주고 Public IP로 NAT를 해줄 매개체(EC2, NAT GW, NAT Instance, Endpoint Interface 등) 와 적절한 라우팅이 필요합니다.
TGW route tables는 특별한 설정 변경 없이 attachement를 통해 VPC 연결 시 Propagation을 통해 VPC 간 라우팅이 TGW route table에 등록되고 별도의 설정 없이도 VPC 간 통신이 구성됩니다. 때론 TGW route table의 존재를 모르는 경우도 있습니다. TGW의 Propagation의 설정을 사용하지 않고, 통신이 필요한 VPC 간 Static IP를 활용한 routing을 활용하면, 더욱 면밀한 망분리를 구현할 수 있습니다.
[ 아키텍처 ]
* Tips!
TGWA는 생성 시 반드시 Route table이 연계됩니다. 해당 route table은 패킷이 출발하는 쪽에서 VPC를 벗어날 때 참고하게 됩니다. 따라서 Static IP 기반으로 TGW 간 route table이 구성된 경우, 통신 이슈 발생 시 해당 VPC 대역이 빠져있는 것은 아닌지 확인해야 합니다.
(4) 도착 VPC 내 Routing Table
여기까지 네트워크 패킷이 전달되어 왔다면 다 온 것입니다. 지금까지의 설정을 다시 검토해 봅니다.
예시) 내부 VPC Route table – 내부 VPC A 대역 / TGW(내부) > 내부 VPC에서 VPC B의 대역은 TGW로 이동
TGW Route table – 내부 VPC A 대역 / VPC B용 TGW Attachement > TGW에서 VPC 대역은 VPC B attachement로 이동
VPC B Route table – VPC B 대역 / local > VPC B 에서 local 설정으로 대역 내 찾아감
[ 결론 ]
VPC 의 subnet routing 외에도 TGW route table을 활용하면 더욱 상세한 라우팅 설정이 가능합니다.
내부 / 외부 접근용 VPC를 분리한 후 TGW를 2개 분리해서 생성하면 더욱 망분리를 높은 보안 수준으로 완성할 수 있습니다.
때론 단지 내부 / 외부만 나누는 것이 아닌, 운영망 개발망까지 분리한 복합적 구성 역시 가능합니다.
