[Cloud & CERT] 조사 2. 네트워크 배치(김태형)

🎯 목표 설정

이전 과정(링크)에서 3-Tier Architecture에 대해 학습하고 우리 팀 근두운 인프라에서는 어떻게 적용해야 할지에 대해 고민하는 시간을 가졌다. 이번 과정에는 설계한 서버 및 서비스들이 네트워크에 어떻게 배치되어야 하는지에 대해 학습해 볼 것이다.

🛜 네트워크 배치

이전 과정에서 Web 서버, WAS 서버, DB 서버를 설계했다. 하지만 서버만 존재하고 별도의 네트워크 구성을 해주지는 않았기 때문에 외부의 사용자와 통신을 할 수 없는 상태이다.

통신을 위해서 각각의 서버에 공인 IP를 부여한 다음에 인터넷과 직접 연결한다면 어떻게 될까? 공개된 포트에 대해서 모든 사용자가 해당 서버들로 접근이 가능해지는 문제가 발생한다. 서버 사이드에서 보안을 위한 설계를 하였음에도 잘못된 네트워크 구성으로 인해 보안 위협이 발생할 수 있다는 것이다.

이를 방지하기 위해 우리는 서버를 구축하고 네트워크에 배치할 때 외부에 노출되어야 하는 서버가 무엇인지를 구분하고 분리하여 배치하여야 한다.

Network Segmentation - 네트워크를 나누는 이유

Network Segmentation은 네트워크를 여러 개의 세그먼트나 서브넷으로 나누는 아키텍처 방식으로 각각 소규모 네트워크 역할을 한다.

인터넷과 통신해야 하는 서버와 아닌 서버를 구분하고, Network Segmentataion 원리를 적용하여 서버의 역할과 보안 요구에 따라 네트워크를 영역을 분리, 영역 사이에 통신 정책을 적용하는 것이 중요하다.

Public 영역은 외부에 공개할 서비스를 배치하고, 외부에 직접 공개하지 않을 내부 시스템 자산은 사설 IP 주소 대역만을 사용하는 Private 영역에 격리하는 것이 일반적이다.

만약 모든 서버를 Private 영역에 배치하고 외부 요청을 내부로 전달할 별도의 접점도 구성하지 않으면, 외부 사용자는 서비스를 이용할 수가 없다.

그래서 기업에서는 기업 서비스를 외부 사용자들에게 안전하게 공개하기 위해 서버의 역할에 따라 네트워크 영역을 분리하여 구축한다.

DMZ - 내부 시스템을 안전하게 외부에 공개하는 영역

그러면 어떻게 네트워크 영역을 분리하는 것이 안전한지를 알아보기 위해서는 DMZ의 개념과 방화벽이라는 보안 장비를 알아야 한다.

DMZ는 군사 용어인 비무장 지대에서 유래한 네트워크 보안 개념으로, 외부 인터넷과 내부망 사이에 존재하는 중립의 영역을 말한다. DMZ 영역에 위치한 서버는 외부 인터넷에서의 접근을 허용하고 해당 영역에 위험을 격리 시킨다. 즉, 외부 사용자가 공개된 서비스의 DMZ 영역에 접근한다고 해서, 그 조직의 내부망 까지는 접근하지 못하게 해주는 역할을 한다.

여기서 접근을 허용하고 차단하는 역할을 수행하는 실질적인 장비가 바로 방화벽이다. 방화벽은 관리자가 설정한 정책에 따라, 네트워크 트래픽의 흐름을 허용 또는 차단해주는 네트워크 보안 장비이다.

이 두 가지를 결합해 Web 서버를 DMZ 영역에 두고, 내부망에는 WAS 서버와 DB 서버를 배치하게 되면 외부 사용자는 Web 서버에 접근해 웹 서비스를 이용할 수 있으면서도 내부망에 있는 WAS 서버, DB 서버로의 접근은 제한하는 네트워크 배치를 구성할 수 있게 된다.

VLAN - 가상 네트워크 공간

네트워크를 분리할 때 영역마다 별도의 물리 스위치를 사용할 수도 있지만, 하나의 스위치를 공유하면서 논리적으로 네트워크를 분리할 수 있는데, 이를 도와주는 기술이 바로 VLAN 기술이다.

스위치 장비는 같은 네트워크에 연결된 장비 사이에서 데이터를 전달해주는 데, VLAN 기술을 통해 같은 스위치의 포트들을 서로 다른 네트워크로 분리하여 Config할 수 있다.

예를 들어 Web 서버가 연결된 포트는 DMZ용 VLAN에, WAS와 DB가 연결된 포트는 내부망용 VLAN에 할당할 수 있다. 그리고, 각 VLAN에는 서로 다른 IP 서브넷을 할당해 네트워크를 분리하는 방식이다.

분리된 Web과 WAS 서버가 통신하기 위해서는 라우팅이 필요한데, 이를 지원하는 장비가 바로 라우터이다. 라우터는 L3 계층의 대표적인 장비로, 서로 다른 네트워크 간의 통신을 연결하고, 데이터 패킷이 목적지까지 가는 경로를 찾는 라우팅을 담당한다.

라우팅 기능을 지원하는 방화벽도 있다.

NAT - 주소 변환 기술

외부 사용자에게 서비스를 제공하기 위해 Web 서버를 DMZ에 배치하고, 외부 요청을 전달할 경로와 방화벽 정책을 구성했다. 그런데 내부망의 DB 서버도 OS 패치를 위해 외부 업데이트 서버에 접속해야 한다.

그렇다면 DB 서버를 DMZ로 옮기거나 공인 IP를 직접 부여해야 할까? 그럴 필요는 없다. 사설 IP주소를 사용하는 내부 서버도 NAT를 통해 인터넷과 통신할 수 있다.

NAT(Network Address Translation)는 통신 과정에서 IP 주소를 변환하는 기술이다. 방화벽이나 라우터 등에서 설정할 수 있으며, 내부 서버가 인터넷으로 접속할 때 출발지 사설 IP를 공인 IP로 바꾸는 방식을 SNAT(Source NAT)라고 한다.

여러 내부 서버가 하나의 공인 IP를 공유하는 경우에는 포트 번호도 함께 변환하는 NAPT 또는 PAT를 흔히 사용한다. NAT 장비는 변환 정보를 기록하고, 응답이 돌아오면 이를 이용해 원래 내부 서버로 전달한다.

다만 NAT만 설정한다고 인터넷 통신이 가능한 것은 아니다. DB 서버의 요청과 응답이 오갈 라우팅 경로, 필요한 외부 통신을 허용하는 방화벽 정책도 필요하다. 업데이트에 HTTP나 HTTPS를 사용한다면 해당 대상과 필요한 포트를 허용해 주면 된다.

그렇다면 DB 서버가 인터넷으로 접속할 수 있게 되면, 외부 사용자도 DB 서버로 접속할 수 있을까?

이를 이해하려면 ‘내부에서 시작한 연결에 대한 응답’과 ‘외부에서 시작하는 새로운 연결’을 구분해야 한다. 내부망을 기준으로 밖으로 나가는 트래픽을 Outbound, 안으로 들어오는 트래픽을 Inbound라고 한다. 업데이트 요청에 대한 응답도 방향상으로는 Inbound이지만, 외부 사용자가 새롭게 시작한 DB 접속과는 다르다.

Stateful 방화벽은 이러한 연결 상태를 추적한다. 내부 서버가 정책상 허용된 연결을 시작하면 출발지·목적지 IP, 포트, 연결 상태 등의 정보를 기록하고, 돌아오는 트래픽이 해당 연결에 속하는지 확인하여 허용한다. 여기서 상태는 웹 로그인 세션이 아니라 네트워크 연결 상태를 의미한다.

반면 외부 사용자가 DB 서버로 시작하는 새로운 연결은 기존 업데이트 연결의 응답이 아니므로, 별도의 접근 허용 정책이 없다면, 접속이 불가능해 지는 것이다.

그렇다고 NAT가 외부에서 시작하는 연결을 지원하지 못하는 것은 아니다. DNAT(Destination NAT)나 포트 포워딩으로 공인 주소의 요청을 내부 서버로 전달하고 방화벽에서도 허용하면, 사설 IP 서버를 외부에 공개할 수 있다.

현재 구성에서는 DB 서버의 패치용 통신을 위한 SNAT와 필요한 Outbound 허용 정책을 구성하되, 외부에서 DB 서버로 시작하는 새로운 연결은 차단한다.

여기서 중요한 것은 NAT는 주소를 변환해 주는 기술이고, 접근 허용 여부는 방화벽 정책과 연결 상태 검사가 담당한다는 것이다.

Bastion Host - 관리자를 위한 접속 통로

위 구성에서 외부에서의 접속은 OS 패치를 위한 아웃바운드 요청에 대한 응답만이 가능하도록 되어 있다. 만약 관리자가 집에서 내부 시스템인 DB 서버에 접근하여 관리해야 한다면 어떻게 해야 할까?

방화벽에서 DB 서버의 SSH 포트를 외부에서 접근 가능하도록 정책을 열어주면 가능하다. 하지만, 출발지 IP를 제한하지 않을 경우에는 관리자 뿐만 아니라 모든 외부 사용자들이 해당 포트로 접근할 수 있기 때문에 매우 위험한 설정이다.

그래서 우리는 관리자의 외부 접속을 관리하는 별도의 보안 관문을 하나 세워서 이를 관리 해야하는데, 이를 도와주는 것이 바로 Bastion Host이다. 그리고, Least Privilege, ACL(Access Control List) 을 적용해 보안 관문을 통해 누가 어디까지 통신할 수 있는지를 제한한다.

Bastion Host : 외부의 관리자가 내부망이 서버에 안전하게 원격 접속하기 위해 사용하는 점프 서버 Least Privilege : 업무에 필요한 권한만 부여한다는 설계 원칙(보안에서 매우 중요!) ACL : 누가 어디에 어떻게 통신할 수 있는지를 정하는 허용・차단 규칙 목록

외부에 있는 관리자가 배스천 호스트를 경유하여 DB 서버에 SSH로 원격 접속하는 흐름

위에서 표현한 흐름과 같이 외부 관리자는 Least Privilege 원칙을 적용한 방화벽 정책에 통제를 받으며, Bastion Host를 경유하여 내부망의 DB 서버에 원격 접속이 가능해 진다.


# SSH ProxyJump 옵션을 통해 Bastion을 경유하여 내부 DB 서버로 원격접속하는 명령
ssh -J <Bastion 계정>@<외부 방화벽 공인 IP> <DB 계정>@<DB 사설 IP>

AWS 환경에서는?

지금까지는 온프레미스 환경에서 서버를 네트워크에 배치하고, 관리자의 접속 경로까지 생성하였다. 우리는 AWS 클라우드 환경에서 인프라를 설계하는 것이 목적이기 때문에, 이 과정을 AWS 서비스로 마이그레이션 해본다.

먼저 설계도의 각 구성요소들이 AWS의 어떤 서비스를 통해 구현 되는지를 대응해보자.

온프레미스	AWS	역할
사내 네트워크 영역	VPC	AWS에서 제공하는 격리된 가상의 네트워크이다.
Network Segmentation (DMZ, 내부망)	Subnet	VLAN과 비슷한 개념으로 VPC의 IP 주소 범위를 나누어 네트워크를 분리하는 영역이다. Subnet의 라우팅 테이블에 Internet Gateway로 직접 향하는 경로의 유무에 따라 Public과 Private로 나뉜다.
Routing	Route Table	목적지에 따라 트래픽을 어디로 전달할지 결정한다.
방화벽, ACL	Security Group, NACL	Security Group은 인스턴스 수준에서의 트래픽 허용 규칙을 적용하며, Stateful 방식이다. NACL은 서브넷 수준에서 트래픽 허용/차단 규칙을 적용하며, Stateless 방식이다.
NAT	NAT Gateway	사설 IP 주소대역을 사용하는 리소스의 외부 인터넷 연결을 지원한다.
인터넷 연결 경계	Internet Gateway	VPC와 외부 인터넷 사이의 연결을 제공한다.

AWS에서는 네트워크 스위치 개념 없이 서브넷으로 네트워크를 분리・구성하고 있고, 라우팅 테이블이라는 리소스를 통해 서브넷의 경로를 제어해준다. 현재 구성에서 라우팅 테이블을 작성해 본다면, 다음과 같이 작성해 볼 수 있다.

서브넷	목적지	대상	용도
Public `10.0.10.0/24`	`10.0.0.0/16`	`local`	VPC 내부 통신
Public `10.0.10.0/24`	`0.0.0.0/0`	Internet Gateway	ALB 및 NAT Gateway의 인터넷 통신
Public `10.0.20.0/24`	`10.0.0.0/16`	`local`	VPC 내부 통신
Public `10.0.20.0/24`	`0.0.0.0/0`	Internet Gateway	외부 인터넷 통신
Private `10.0.30.0/24`	`10.0.0.0/16`	`local`	VPC 내부 통신
Private `10.0.30.0/24`	`0.0.0.0/0`	NAT Gateway	외부 접속 및 패치 요청

이 흐름을 이해 한다면, 온프레미스 구조를 AWS 환경에서 그대로 재현할 수 있다.

Lateral Movement - 공격자의 내부 침투 후 다른 시스템을 장악

현재 구조에서 공격자가 웹 취약점을 활용해 WEB 서버의 권한을 획득하게 된다면, DB 서버로 접속할 수 있을까? 그림만 보았을 때는 Private Subnet에 DB 서버가 위치하고 있어 안전한 것으로 보일 수 있지만, Private Subnet은 라우팅 테이블에 Internet Gateway로 직접 향하는 경로가 없는 서브넷을 의미하는 것이지 다른 내부 시스템의 접근까지 차단해주는 것이 아니다.

따라서, 실제 WEB 서버 → DB 서버로의 접근은 서브넷이 Public이든 Private이든 상관 없이, 보안그룹 등의 접근 제어 정책에 따라 결정된다.

지금 구성에서 Private Subnet은 Internet Gateway에 직접 연결되지 않아 North-South Traffic(외부-내부 통신) 중 인터넷에서 내부 서버로 직접 시작하는 접속은 제한된다. 다만 내부 서버가 시작한 인터넷 통신과 그 응답, ALB나 Bastion을 경유하는 허용된 접근은 가능하며, East-West Traffic(내부-내부 통신)도 보안그룹 정책에 따라 허용될 수 있다.

우리는 네트워크 설계를 할 때, 이러한 공격자의 측면 이동을 막기 위해 내부 시스템 사이의 접근을 보안그룹을 통해 통제해야 한다.

그리고 보안그룹 정책을 설정할 때에는 Least Privilege 원칙에 따라 업무상 반드시 필요한 범위의 접근 권한을 부여해야 하고, 보안그룹 ID를 참조하여 보안그룹 간의 접근만을 제어하는 Security Group Chaining 방식을 사용하는 것도 하나의 방법이다.

내부 시스템이라고 무조건 신뢰하는 것이 아니라, 필요한 통신인지를 판단하고, 접근에 대한 인증과 권한을 검증하는 것이 보안 위협을 최소화하는 중요한 포인트다. 이러한 보안 개념을 우리는 Zero Trust 라고 부른다.

그럼 지금 인프라 구조에서는 접근 제어 정책을 어떻게 부여해야 할까?

우리는 이전 과정에서 3-Tier Architecture 구조로 서버를 설계하였다. 해당 구조에서는 WEB → WAS → DB 순서로 접근하여 사용자의 요청을 처리한다.

따라서, 인터넷 → ALB, ALB → WEB, WEB → WAS, WAS → DB에 대해 필요한 서비스 포트만을 접근 제어 정책으로 허용해 주면 된다. 또한, 외부 관리자의 내부 서버 접속을 위한 접근 제어 정책도 허용해 준다.

보안그룹은 화이트리스트 방식으로 허용 규칙만을 정의한다.

이를 표로 정리하면 다음과 같다.

Source	Destination	Port	이유
인터넷 `0.0.0.0/0`	ALB `(SG-ALB)`	TCP 443	외부 사용자가 HTTPS로 웹 서비스에 접속
ALB `(SG-ALB)`	WEB `(SG-WEB)`	TCP 80	사용자의 웹 요청을 전달하고 헬스체크 수행
WEB `(SG-WEB)`	WAS `(SG-WAS)`	TCP 8080	웹 애플리케이션 요청 전달
WAS `(SG-WAS)`	DB `(SG-DB)`	TCP 3306	웹 애플리케이션 요청을 처리하기 위한 데이터 조회・저장
관리자 공인 IP	Bastion `(SG-Bastion)`	TCP 22	외부 관리자의 SSH 접속
Bastion `(SG-Bastion)`	DB `(SG-DB)`	TCP 22	DB 서버 관리
패치 필요 서버	인터넷 `0.0.0.0/0`	TCP 443	OS・패키지 업데이트 (HTTP 필요 시 TCP 80 추가)

💁 마무리

이번 과정에서는 지난 과정에서 설계했던 3-Tier Architecture 구조가 서버 사이드에서 뿐만 아니라, 네트워크 영역에서도 안전한 구조를 가지도록 네트워크를 배치하였다. 이번 과정을 통해 배운 키워드를 팀 근두운 인프라에 적용하여 보안적으로 강력한 네트워크 구성을 할 수 있을 것으로 기대한다.

다음 과정에서는 완성된 서비스와 네트워크에서 발생할 수 있는 보안 위협을 어떻게 기록・탐지・대응하는지 학습해 볼 예정이다.