네트워크에서 DMZ란 무엇인가?

DMZ는 정의 없이 등장합니다. 보안 점검 체크리스트의 한 항목, 벤더 하드닝 문서의 한 문장, 채용 공고에서 TLS와 최소 권한 옆에 놓인 요구 사항으로.

찾아보면 네트워크 케이블 세 개가 꽂힌 방화벽 다이어그램이 나옵니다. 하나는 인터넷으로, 하나는 서버 여러 대로, 하나는 사무실 LAN으로 이어집니다. 반면 당신이 관리하는 것은 공인 IP 하나에 여분의 네트워크 인터페이스가 전혀 없는, 임대한 서버 한 대입니다.

첫 번째 그림은 진짜 DMZ 아키텍처입니다. 서버 한 대에서도 그 보안 목표의 일부, 즉 인터넷이 닿을 수 있는 범위를 제한하는 부분은 재현할 수 있습니다. 같은 호스트에서 재현할 수 없는 것은 DMZ를 DMZ로 만들어 주는 별도의 네트워크 경계입니다.

요약

• DMZ는 외부인이 반드시 접근해야 하는 서비스를 나머지 운영 자산과 분리합니다.
• 핵심은 배선이 아니었습니다. 공개된 쪽에서 발생한 침해가 거기서 멈춰야 한다는 것이었습니다.
• 방화벽을 설정해 두고도 DMZ가 없을 수 있습니다.
• 공인 IP 하나짜리 서버 한 대도 리버스 프록시, 호스트 방화벽 규칙, 루프백이나 사설 주소 바인딩으로 노출을 줄일 수는 있지만, 별도의 DMZ 구간을 만들지는 못합니다.
• 이 방식은 보호 대상과 커널을 공유하므로, 격리가 아니라 노출 축소로 계산해야 합니다.

이 글이 다루지 않는 것

여기서 다루는 범위는 개념적 모델이며, 인접한 세 가지 주제는 의도적으로 다루지 않습니다.

• 구축 절차는 다루지 않습니다. 리버스 프록시 설정도, 방화벽 규칙 문법도, 어떤 도구를 설치하라는 권장도 없습니다.
• 가정용 공유기 설정도 다루지 않습니다. 가정용 라우터의 "DMZ host" 옵션은 전혀 다른 기능을 가리킵니다.
• 제로 트러스트에 대한 결론도 내리지 않습니다. 네트워크 경계가 여전히 적절한 주요 통제 수단인지는 실제로 논쟁 중인 문제이며, 여기서 결론짓지 않습니다.

DMZ란 무엇이고, 무엇을 위한 것인가?

DMZ, 즉 비무장지대는 신뢰할 수 없는 인터넷과 내부 네트워크 사이에 놓인 네트워크 구간입니다. 웹 서버나 메일 서버처럼 공개적으로 접근 가능해야 하는 서비스가 이곳에 있습니다. 나머지는 모두 두 번째 경계 뒤에 남으므로, 공개 서비스에 도달했다고 해서 나머지에 도달한 것은 아닙니다.

DMZ에 관한 Mozilla 용어집 항목 은 그 핵심 절반을 한 구절로 정리합니다. 정해진 일부 엔드포인트만 노출하고, 외부에서 내부 네트워크로의 접근은 거부한다는 것입니다. 설계 목표는 그것이 전부이며, 어떤 장비도 언급하지 않고 서술되어 있습니다.

전통적으로 그곳에 놓이는 서비스 종류는 이 목표에서 따라 나옵니다. 웹 서버, 메일 서버, FTP 서버, VoIP 서버처럼 외부인이 연결할 수 있어야 하는 것들입니다. 디렉터리 서버, 데이터베이스, 파일 공유, 내부 애플리케이션, 관리 인터페이스는 그 목록에 없습니다. 외부의 누구도 애초에 거기에 닿아서는 안 되기 때문입니다.

그림이 아니라 성질을 붙잡으세요. 세 개의 네트워크 인터페이스는 별도의 신뢰 경계를 만드는 한 가지 방법일 뿐입니다. 클라우드나 단일 서버 설계도 같은 노출 통제 원칙을 다른 방식으로 적용할 수 있지만, DMZ 자체를 재현하는 것은 뚜렷한 경계 구역을 갖춘 설계뿐입니다.

전통적인 3인터페이스 DMZ는 어떻게 동작하는가?

전통적인 DMZ는 두 가지 방식으로 구성됩니다. 단일 방화벽 설계는 방화벽 하나에 인터넷, DMZ, 내부 네트워크로 향하는 세 개의 인터페이스를 둡니다. 이중 방화벽 설계는 별개의 방화벽 두 대 사이에 DMZ를 둡니다. 둘 다 같은 규칙을 강제합니다. 인터넷은 DMZ까지 닿습니다. 인터넷은 결코 내부 네트워크에 닿지 않습니다.

단일 방화벽(3레그) 모델

방화벽 하나, 네트워크 인터페이스 셋. 첫 번째는 인터넷을 향합니다. 두 번째는 공개 서비스가 있는 DMZ를 향합니다. 세 번째는 내부 네트워크를 향합니다. 방화벽은 인터넷에서 DMZ의 특정 포트로 들어오는 트래픽을 허용하고, 애플리케이션이 필요로 하는 경우에 한해 DMZ에서 내부로 향하는 좁은 트래픽을 허용하며, 나머지는 모두 거부합니다.

이 형태의 이름은 3레그 방화벽입니다. 구역 사이를 넘나드는 모든 패킷이 장비 한 대를 거치므로, 그 방화벽은 구역 간 트래픽의 단일 장애점이 됩니다. 방화벽이 죽으면 연결성과 정책 집행은 방화벽의 장애 동작 방식과 마련해 둔 이중화 수준에 따라 영향을 받습니다.

저는 한 ISP에서 십 년간 네트워크 운영을 맡았는데, 사람들이 DMZ 인터페이스에 대해 가장 놀라워한 점은 그것이 얼마나 평범한가였습니다. 방화벽 설정에서 다른 신뢰 레이블이 붙었을 뿐인 평범한 이더넷 포트였죠. 아키텍처는 구리선 안에 있지 않았습니다. 규칙 집합 안에, 그리고 누군가 각 흐름이 어느 방향으로 허용되는지를 신중히 고민했다는 사실 안에 있었습니다.

이중 방화벽(백투백) 모델

방화벽 두 대를 직렬로 두고, 그 사이에 DMZ를 둡니다. 외부 방화벽은 인터넷 트래픽을 DMZ까지만 들여보내고 그 너머로는 보내지 않습니다. 내부 방화벽은 애플리케이션이 필요로 하는 특정한 DMZ에서 내부로의 트래픽만 허용합니다. DMZ에 도달한 공격자는 내부 네트워크에 닿기 전에 여전히 내부 방화벽의 정책 경계를 넘어야 합니다.

방화벽 두 대는 별도로 강제되는 정책 경계 두 개를 제공하지만, 동시에 설정과 패치, 운영 복잡도도 늘립니다. 외부 경계가 무너지거나 뚫려도 내부 경계가 자동으로 사라지지는 않습니다. 물론 보호 수준은 여전히 두 방화벽을 어떻게 설정하고 관리하느냐에 달려 있습니다.

DMZ는 방화벽과 같은 것인가?

아닙니다. DMZ는 별도의 경계 네트워크 또는 네트워크 구간입니다. 방화벽은 그 구역과 인터넷, 내부 네트워크 사이의 트래픽을 통제하는 데 흔히 쓰이는 수단입니다. 평평한 네트워크에서도 DMZ를 만들지 않은 채 방화벽 규칙을 설정할 수 있으므로, 이 차이는 설정의 문제가 아니라 구조의 문제입니다.

혼동은 이해할 만합니다. 방화벽은 로그인해 들어가는 대상이고, 설정 파일과 공급업체와 지원 계약이 붙어 있는 물건이라서, 자신이 만들어 내는 것의 이름까지 가져가 버립니다. 반면 구간에는 아무도 로그인하지 않습니다.

그 결과는 가장 나쁜 순간에 드러납니다. 공개된 웹 서버가 침해당했다고 가정하세요. 언젠가는 실제로 그렇게 되니까요. 평평한 네트워크라면 공격자는 이미 데이터베이스, 파일 서버, 관리 인터페이스와 통신할 수 있는 machine 위에 발판을 얻은 셈이고, 그 사이를 옮겨 다니는 일은 이미 허용된 접근을 쓰는 것에 지나지 않습니다. 이런 옆걸음을 측면 이동이라 부르며, 두 번째 경계는 바로 이것을 막으려고 존재합니다. DMZ는 웹 서버가 침해당하는 것을 막지 않습니다. 침해당한 웹 서버가 나머지 전부에 대한 접근으로 바뀌는 것을 막습니다.

용어가 눈앞에 있는 김에 한 가지 짚자면, 가정용이나 소규모 사무실용 라우터의 "DMZ host" 설정은 전혀 다른 기능입니다. 요청하지 않은 인바운드 트래픽을 내부 장치 한 대로 전달해 그 장치를 인터넷에 그대로 노출시킬 뿐, 별도의 보호된 DMZ 네트워크를 만들지는 않습니다.

서버 한 대에서 DMZ 원칙을 어떻게 적용하는가?

공인 IP 하나짜리 서버 한 대도 DMZ의 노출 통제 목표 가운데 일부는 재현할 수 있습니다. 네트워크 분리는 재현하지 못한 채로 말이죠. 리버스 프록시가 유일한 공개 진입점이 될 수 있고, 기본 거부 방식의 인바운드 방화벽 규칙이 나머지를 막을 수 있으며, 내부 서비스는 공인 주소 대신 루프백이나 사설 인터페이스에서 대기할 수 있습니다.

이 절이 전제하는 제약에서 출발합시다. VPS 한 대, 공인 인터페이스 하나, 그리고 별도의 방화벽 장비 없음 그리고 당신이 통제하는 DMZ 서브넷도 없습니다. 이런 구성에서는 같은 호스트 위에 전통적인 3레그 토폴로지를 재현할 수 없습니다. 호스트 방화벽 규칙, 서비스의 바인딩 선택, 리버스 프록시는 여전히 노출을 줄여 주지만, 동일한 격리 경계를 만들지는 못합니다.

리버스 프록시는 공인 인터페이스의 다음 포트를 차지할 수 있습니다: 80 와 443 그리고 웹 트래픽에 대한 유일한 애플리케이션 계층 진입점이 될 수 있습니다. 이는 공개된 공격 표면을 좁혀 주지만, 별도의 DMZ 인터페이스와 같지는 않습니다. 프록시가 여전히 뒤쪽 서비스들과 같은 호스트를 공유하기 때문입니다.

호스트의 인바운드 방화벽 규칙은 그 두 포트만 허용하고 나머지는 폐기합니다. 머신의 다른 서비스들은 실행 중이고 대기 중일 수 있지만, 외부에서는 그 어느 것에도 연결을 시작할 수 없습니다. 이는 한 호스트 안에서 "의도한 포트만 도달 가능"이라는 정책에 근접한 것이지, 내부 네트워크와의 별도 경계를 만들어 내지는 않습니다.

애플리케이션 서버, 데이터베이스, 관리자 패널은 공인 주소에서 대기해서는 안 됩니다. 프록시가 같은 호스트에 있다면 루프백에서 대기하면 되고, 사설 네트워크의 다른 곳에 있다면 사설 주소에서 대기하면 됩니다. 어느 경우든 공인 인터페이스에는 그 서비스들을 위한 리스너가 없으므로, 그 인터페이스에 인바운드 규칙 하나를 여는 것만으로는 그것들이 노출되지 않습니다.

관리자 접근은 DMZ 쪽이 아니라 내부 쪽에 속합니다. SSH와 관리 인터페이스를 공개 경로 밖, 즉 VPN이나 사설 네트워크 뒤에 두면 공용 인터넷에서 그것들로 직접 연결하는 일을 막을 수 있습니다.

읽기

Linux VPS 보안 방법 | VPS 서버를 보호하는 20가지 방법

DMZ 개념은 VPC 서브넷과 보안 그룹에 어떻게 대응되는가?

전통적인 모델은 클라우드 네트워킹 기본 요소에 개념적으로 상당히 가깝게 대응하지만, 일대일은 아닙니다. DMZ 구간은 퍼블릭 서브넷이 됩니다. 내부 네트워크는 인터넷 게이트웨이로 가는 경로가 없는 프라이빗 서브넷이 됩니다. 방화벽의 규칙 집합은 리소스의 네트워크 인터페이스에 연결되는 보안 그룹과 서브넷에 붙는 네트워크 ACL로 나뉩니다.

클라우드 사업자들이 이 어휘를 직접 쓰고 있다는 점은 이 용어가 여전히 살아 있다는 좋은 증거입니다. AWS의 네트워킹 블로그는 다음을 설명합니다: Amazon VPC 위의 DMZ 아키텍처 공개 서비스를 내부 네트워크로부터 격리하며, 2024년 11월에 출시된 리전 수준 통제 기능인 VPC Block Public Access 위에 구축된 아키텍처입니다.

이 대응 관계에서 하중을 떠받치는 부분은 서브넷입니다. 퍼블릭 서브넷이 퍼블릭인 이유는 라우트 테이블이 인터넷 게이트웨이를 가리키기 때문입니다. 패킷이 어디로 이동할지는 라우트 테이블이 결정합니다따라서 서브넷 배치가 개별 규칙보다 먼저 당신의 노출 범위를 결정합니다.

이 대응은 한 가지 지점에서 어긋납니다. 방화벽 인터페이스는 구간 전체에 대한 경계를 강제했지만, 보안 그룹은 개별 리소스의 네트워크 인터페이스에 붙습니다. 같은 프라이빗 서브넷에 있는 두 머신이 완전히 다른 보안 그룹을 가질 수 있으므로, 강제 지점이 물리 인터페이스가 도달한 적 없는 세밀한 단위로 내려옵니다. 대개는 개선입니다. 동시에 이는 서브넷의 이름이 무엇에 도달 가능한지에 대해, 예전의 네트워크 다이어그램보다 덜 말해 준다는 뜻이기도 합니다.

단일 서버 방식이 부족한 지점

한 호스트 안에서는 외부에 노출된 프로세스와 내부 서비스가 커널과 머신을 공유합니다. 구간이 분리되어 있으면 공격자는 방화벽이 검사하는 네트워크 경계를 넘어야 하지만, 단일 호스트에서는 그럴 필요가 없습니다. 단일 서버 패턴은 노출을 줄입니다. 분리를 재현하지는 않습니다.

리버스 프록시가 공격자에게 코드 실행을 허용하는 방식으로 뚫린다면, 그 코드는 이미 데이터베이스가 도는 바로 그 머신 위에서 실행되고 있습니다. 그때는 루프백 바인딩이 도움이 되지 않습니다. 루프백은 호스트 안에서 얼마든지 닿을 수 있기 때문입니다. 컨테이너나 사용자 격리는 필요한 노력을 높일 수는 있지만, 같은 호스트의 컨테이너는 여전히 그 호스트의 커널을 공유합니다. 전통적인 모델에서 공격자의 다음 걸음은 무언가가 검사하고 있는 선로 위의 패킷이었습니다. 여기서는 로컬 소켓입니다.

실질적인 결론은 판정이 아니라 문턱입니다. 프록시 뒤에 있는 것이 서버 한 대를 더 두는 수고보다 값어치가 커지는 순간, 머신 두 대와 그 사이의 사설 네트워크를 쓰십시오. 그러기 위해 이 글의 내용을 다시 배울 필요는 없습니다. 이 가운데 어느 것도 애초에 하드웨어에 관한 이야기가 아니었으니까요.

보안 정책을 강제할 수 있는 곳이 더 이상 경계뿐인 것은 아닙니다. 제로 트러스트 아키텍처는 네트워크 위치에 근거한 암묵적 신뢰를 없애고, 다음으로 구축한 사설 연결은 WireGuard 또는 Tailscale 공개 노출을 줄일 수 있습니다. 두 접근 모두 세분화나 인가를 자동으로 대체하지는 않습니다. 더 좁은 질문에 대한 제 입장은 분명합니다. 개념적 모델로서, 닿을 수 있는 것과 닿을 수 없는 것을 갈라놓고, 어느 경계가 침해를 가둬 두는지 알아 두십시오. 그 질문은 위에 언급한 모든 아키텍처보다 오래 살아남으며, 그래서 여전히 답할 가치가 있습니다.

자주 묻는 질문

DMZ는 VPN과 같은 것인가?

아닙니다. 둘은 서로 다른 문제를 풉니다. DMZ는 신뢰할 수 없는 외부인이 무엇에 닿을 수 있는지를 통제하며, 소수의 서비스만 노출하고 그 밖에는 아무것도 열지 않습니다. VPN은 신뢰할 수 있는 외부인에게 안으로 들어오는 사적인 통로를 열어 주며, 그들이 아니었으면 닿지 못했을 네트워크에 인증을 거쳐 들여보냅니다. 많은 네트워크가 둘 다 운영하며, 어느 쪽도 다른 쪽을 대신하지 못합니다.

DMZ는 안전한가?

DMZ는 노출된 서비스를 안전하게 만들어 주지 않습니다. 그 서비스가 뚫렸을 때 침해가 어디까지 미치는지를 제한할 뿐입니다. 공개된 서비스는 여전히 공개되어 있고, 여전히 인터넷의 모두에게 열려 있으며, 여전히 그 자체로 패치와 모니터링과 하드닝이 필요합니다. DMZ가 결정하는 것은 그것이 무너진 뒤에 무슨 일이 벌어지느냐이지, 무너질지 아닐지가 아닙니다.

서버가 한 대뿐이라면 DMZ가 필요한가?

전통적인 의미에서는 아니고, 애초에 단일 호스트에서는 만들 수도 없습니다. 3인터페이스 토폴로지는 분리된 네트워크 구간을 필요로 하는데, 공인 IP 하나짜리 서버에는 그런 것이 없습니다. 대신 할 수 있는 일은 노출을 통제하는 것입니다. 리버스 프록시를 유일한 공개 진입점으로 삼고, 나머지 인바운드 포트는 기본 거부하며, 내부 서비스는 루프백이나 사설 주소에서 대기시키십시오. 이는 인터넷이 닿을 수 있는 범위를 줄여 주지만, 공개 서비스를 호스트의 나머지로부터 격리해 주지는 않습니다. 프록시 뒤에 있는 것이 두 번째 머신의 비용보다 값어치가 커지면, 머신 두 대와 그 사이의 사설 네트워크를 쓰십시오.

왜 비무장지대라고 부르는가?

이 용어는 서로 맞선 두 세력 사이의 완충 지대, 어느 쪽도 완전히 장악하지 못하는 지역이라는 군사적 의미에서 빌려 온 것입니다. 네트워크에서의 쓰임도 그 비유를 그대로 간직합니다. DMZ는 신뢰할 수 없는 바깥에도, 신뢰하는 안쪽에도 온전히 속하지 않습니다.