외부망·내부망 사이의 DMZ, 언제·어떻게 써야 하나 — 사용요건 정리
Summary
“우리 서비스는 인터넷에 열어야 하는데, 그렇다고 내부 DB 랑 직원 PC 까지 인터넷에 노출할 순 없잖아요?” 이 고민을 푸는 표준 답이 DMZ(DeMilitarized Zone, 비무장지대) 예요. 외부망과 내부망 사이에 완충 구간을 하나 끼워 넣고, 외부에서 접근이 꼭 필요한 서버만 거기에 두는 거죠. 그러면 그 서버가 털려도 침해가 내부망으로 바로 못 넘어옵니다.
이 글은 DMZ 를 “언제 쓰고, 무엇을 올리고, 트래픽을 어느 방향으로만 허용해야 하는지” — 즉 사용요건을 정리한 글이에요. 개념부터 방화벽 배치, 실제 트래픽 흐름, 흔한 안티패턴, 마지막에 체크리스트까지 순서대로 갑니다.
💡 이 글에서 다루는 것
- 외부망 / DMZ / 내부망 3영역이 각각 무엇인가
- DMZ 에 두는 것 vs 절대 두면 안 되는 것
- 트래픽을 어느 방향으로 허용/차단해야 하는가 (핵심 요건)
- 방화벽 배치 두 가지 — 싱글 vs 듀얼
- 흔한 안티패턴과 DMZ 도입 체크리스트
1. 왜 DMZ 가 필요한가
네트워크를 신뢰도로 나눠 보면 딱 두 극단이 있어요.
- 외부망(Untrust) — 인터넷. 누가 뭘 보낼지 모르니 아예 신뢰 안 함.
- 내부망(Trust) — 업무 시스템, 데이터베이스, 인증 서버, 직원 PC. 가장 지켜야 할 곳.
문제는, 우리가 외부에 서비스를 열려면 누군가는 인터넷을 마주 봐야 한다는 거예요. 웹서버가 대표적이죠. 그런데 이 웹서버를 내부망에 두면? 인터넷에서 들어오는 트래픽을 받으려고 방화벽에 구멍을 뚫는 순간, 그 구멍이 곧 내부망으로 들어오는 통로가 됩니다. 웹서버 하나가 털리면 같은 망에 있는 DB 와 직원 PC 까지 한 번에 위험해져요.
그래서 그 중간에 제3의 구간을 둡니다. 이게 DMZ 예요.
💡 DMZ 의 핵심 아이디어는 딱 하나예요. “외부에 노출되는 서버는 애초에 신뢰도가 낮은 별도 구간에 격리해 두고, 그 구간이 침해당해도 내부망으로는 못 넘어가게 만든다.” 완충지대에 놓인 서버는 “털릴 수도 있는 것”으로 전제하고 설계합니다.
2. 3영역 구조 — 신뢰도 순서대로 줄 세우기
DMZ 를 도입하면 네트워크가 신뢰도 순으로 세 칸이 돼요.
| 영역 | 신뢰도 | 무엇이 있나 | 침해 전제 |
|---|---|---|---|
| 외부망 | 없음 | 인터넷, 외부 사용자 |
항상 적대적 |
| DMZ | 낮음 | 공개 서비스 서버 |
털릴 수 있음 |
| 내부망 | 높음 | DB · 인증 · 업무 · 직원 PC |
지켜야 함 |
핵심은 신뢰도가 낮은 쪽에서 높은 쪽으로 가는 트래픽을 최대한 막는 것이에요. 외부망 → DMZ 는 어느 정도 열고, DMZ → 내부망 은 거의 다 막고, 외부망 → 내부망 은 아예 직접 통로를 안 만듭니다. 이 “한 칸씩만, 그것도 최소한”이 DMZ 설계의 뼈대예요.
3. DMZ 에 두는 것 vs 두면 안 되는 것
DMZ 사용요건의 절반은 “무엇을 여기 올릴 것인가”로 결정돼요. 기준은 간단합니다. 외부에서 직접 접근이 필요한가? 필요하면 DMZ 후보, 아니면 내부망.
DMZ 에 두는 것 — 외부 대면 서버
- 웹서버 / 리버스 프록시 / WAF
- API 게이트웨이
- 메일 릴레이(외부와 주고받는 SMTP 게이트웨이)
- 외부용 DNS(권한 있는 존만 응답하는 authoritative DNS)
- VPN 게이트웨이, 원격접속 게이트웨이
- 외부 파일 교환용 SFTP 게이트웨이
DMZ 에 두면 안 되는 것 — 내부망에 있어야 할 것
- 데이터베이스 서버(고객/거래 데이터)
- 인증·디렉터리 서버(AD / LDAP)
- 내부 파일서버, 백업 저장소
- 사내 업무 시스템, 직원 PC
- 기밀 데이터 원본
🚨 가장 흔한 사고가 “DB 를 DMZ 에 두는 것”이에요. 웹서버가 DB 를 봐야 하니까 편의상 같이 DMZ 에 올리는 건데, DMZ 는 “털릴 수 있는 구간”으로 전제한 곳이라 여기에 데이터 원본을 두면 격리의 의미가 사라져요. DB 는 반드시 내부망에 두고, DMZ 의 웹서버가 내부망 DB 로 제한된 커넥션만 맺도록 방화벽으로 열어줍니다. (아래 4절)
4. 트래픽 방향 규칙 — 이게 진짜 사용요건이다
DMZ 를 “만들었다”고 끝이 아니에요. 어느 방향으로 무엇을 허용/차단하느냐가 전부입니다. 원칙은 기본 차단(default deny) 하고, 필요한 것만 콕 집어 여는 거예요.
방향별로 정리하면 이렇습니다.
| 방향 | 원칙 | 예시 |
|---|---|---|
| 외부망 → DMZ | 서비스 포트만 허용 |
443 만 열기 |
| DMZ → 내부망 | 원칙 차단, 예외만 |
특정 DB 포트만 |
| 내부망 → DMZ | 관리 목적 제한 허용 |
배포 · SSH |
| DMZ → 외부망 | 최소화 | 패치 · DNS |
| 외부망 → 내부망 | 절대 금지 | (직접 통로 없음) |
| DMZ 서버 간 | 최소화 | 꼭 필요한 것만 |
하나씩 짚을게요.
- 외부망 → DMZ : 공개할 서비스 포트만 엽니다. 웹이면
443(가능하면80은 리다이렉트만). 그 외 포트는 다 닫아요. - DMZ → 내부망 : 여기가 제일 중요해요. 기본은 차단이고, 웹서버가 내부 DB 를 읽어야 하는 것처럼 꼭 필요한 경우에만 “어느 서버가 → 어느 서버의 → 어느 포트로”까지 좁혀서 예외를 줍니다. “DMZ 대역 전체 → 내부망 전체” 같은 광범위 허용은 절대 금물.
- 내부망 → DMZ : 배포·운영·모니터링 때문에 필요하지만, 이것도 관리 대역/특정 포트로 제한합니다.
- DMZ → 외부망 : DMZ 서버가 인터넷으로 나가는 것도 줄여요. OS 패치, 외부 DNS 질의 정도만 허용하고 나머진 막습니다. 침해된 서버가 외부 C2 서버로 콜백하는 걸 막는 효과예요.
- 외부망 → 내부망 : 직접 통로 자체를 안 만듭니다. 외부에서 내부로 가려면 반드시 DMZ 를 한 번 경유해야 해요. 이게 DMZ 의 존재 이유입니다.
- DMZ 서버 간(east-west) : 같은 DMZ 안이라도 서버끼리 다 열어두면 하나 털렸을 때 옆으로 번져요(lateral movement). 필요한 통신만 남깁니다.
⚠️ 트래픽을 열 때는 출발지·목적지·포트·프로토콜 4가지를 다 좁히세요. “포트만 열기”가 아니라 “이 서버에서 저 서버의 이 포트로만”까지 가야 진짜 최소권한이에요. 방화벽 룰은 넓게 열기는 쉽고 좁히기는 어려우니, 처음부터 좁게 시작하는 걸 추천드려요.
5. 단방향 원칙과 프록시 경유
방향 규칙에서 한 발 더 들어가면 두 가지 실무 요건이 나와요.
(1) 데이터는 내부에서 당겨온다(pull), 밖에서 밀어넣지(push) 않는다.
DMZ 서버가 내부망으로 커넥션을 먼저 여는 건 최대한 피하는 게 좋아요. 대신 내부망 쪽에서 DMZ 로 연결을 맺어 데이터를 당겨오는(pull) 구조로 뒤집으면, DMZ → 내부 방향 방화벽을 더 많이 닫을 수 있어요. 파일 교환도 “DMZ 가 내부로 보내는” 게 아니라 “내부가 DMZ 에서 가져가는” 흐름이 안전합니다.
(2) 직접 커넥션 대신 게이트웨이/프록시로 중계한다.
외부 사용자가 내부 시스템을 직접 붙는 일이 없도록, DMZ 에 리버스 프록시 / API 게이트웨이 / 애플리케이션 프록시를 두고 여기서 세션을 끊었다가 다시 맺어요(termination). 외부는 DMZ 의 프록시까지만 알고, 내부 서버의 주소·구조는 전혀 몰라야 합니다. 프록시 지점에서 WAF·인증·로깅을 같이 태우면 검사 포인트도 한 곳으로 모여요.
✅ 정리하면 DMZ 는 단순한 “중간 방”이 아니라 검문소예요. 모든 외부↔내부 트래픽이 여기서 한 번 끊기고, 검사받고, 다시 이어집니다.
6. 방화벽 배치 — 싱글 vs 듀얼
DMZ 를 물리적으로 만드는 방법은 크게 두 가지예요.
싱글 방화벽(three-legged)
방화벽 한 대에 인터페이스를 3개(외부 / DMZ / 내부) 물리는 방식이에요.
[ 방화벽 (3-leg) ]
/ | \
외부망 DMZ 내부망
- 장점: 장비 하나라 저렴하고 관리 단순.
- 단점: 그 방화벽 하나가 뚫리거나 룰 실수가 나면 3영역이 한 번에 위험. 단일 장애점.
듀얼 방화벽(back-to-back)
외부 방화벽과 내부 방화벽 두 대를 두고, 그 사이에 DMZ 를 끼우는 방식이에요.
외부망 ── [외부 방화벽] ── DMZ ── [내부 방화벽] ── 내부망
- 장점: 내부망에 닿으려면 방화벽을 두 번 통과해야 함. 벤더를 다르게 쓰면 한쪽의 취약점이 다른 쪽까지 뚫지 못해요.
- 단점: 장비·운영 비용이 더 듦.
💡 보안 수준이 높아야 하는 환경(예: 금융권)은 듀얼 방화벽 + 서로 다른 벤더 조합을 권장해요. 예산·규모가 작으면 싱글로 시작하되, DMZ 대역과 룰만큼은 명확히 분리해 두세요.
7. 그 밖에 챙겨야 할 요건
방향 규칙과 배치 말고도, DMZ 서버는 “털릴 수 있는 것” 전제라 서버 자체를 단단히 해둬야 해요.
- 최소 서비스·하드닝 — DMZ 서버엔 서비스에 꼭 필요한 데몬만. 안 쓰는 포트·계정·패키지 제거.
- 로깅과 모니터링 — DMZ 는 공격의 최전선이라 로그를 반드시 내부(또는 별도 로그 서버)로 모아 상시 감시. IDS/IPS 를 경계에 두는 것도 여기.
- 패치 경로 확보 — DMZ 서버도 OS·미들웨어 패치가 필요한데, 인터넷 직접 접근을 최소화하려면 내부 패치 서버/저장소를 경유하는 경로를 따로 설계.
- 인증서·비밀 관리 — TLS 인증서, DB 접속 계정 같은 비밀값을 DMZ 서버 파일에 평문으로 두지 말 것. 별도 비밀 관리 체계 사용.
- 세그먼트 분리 — 서비스가 여러 개면 DMZ 안에서도 서브넷을 나눠 east-west 를 끊어요.
8. 흔한 안티패턴
실무에서 자주 보는, DMZ 를 무력화시키는 실수들이에요.
- 🚨 DB·인증서버를 DMZ 에 둠 — 격리의 의미가 사라짐. 원본 데이터는 내부망으로.
- 🚨 DMZ → 내부망을 대역 통째로 허용 — “일단 되게” 하려고 넓게 열어두면 웹서버 하나 털렸을 때 내부망 전체가 노출.
- 🚨 외부 → 내부 직접 포트포워딩 — DMZ 를 건너뛰고 내부 서버로 바로 꽂는 순간 DMZ 가 유명무실.
- 🚨 DMZ 서버 간 전부 오픈 — 하나 뚫리면 옆으로 번짐(lateral movement).
- 🚨 로그를 DMZ 서버 로컬에만 남김 — 침해되면 로그도 같이 지워짐. 로그는 밖으로 빼둘 것.
⚠️ 공통점은 전부 “편의를 위해 경계를 넓게 열었다”는 거예요. DMZ 의 가치는 “얼마나 좁게 막았는가”에서 나오니까, 편의와 보안이 부딪히면 기본은 막는 쪽으로 두고 예외를 최소한으로 여는 습관을 들이는 게 좋아요.
9. 도입 체크리스트
새로 DMZ 를 설계하거나 기존 구성을 점검할 때 훑어보면 좋은 목록이에요.
- 외부 대면 서버만 DMZ 에 있는가 (DB·인증·데이터 원본은 내부망?)
- 외부망 → DMZ 는 서비스 포트만 열려 있는가
- DMZ → 내부망 은 기본 차단 + 출발지·목적지·포트까지 좁힌 예외만 있는가
- 외부망 → 내부망 직접 통로가 없는가
- DMZ → 외부망(아웃바운드)이 최소화돼 있는가
- 외부↔내부 트래픽이 프록시/게이트웨이를 경유하는가
- DMZ 서버가 하드닝돼 있고 최소 서비스만 도는가
- 로그가 DMZ 밖으로 모이고 상시 감시되는가
- 방화벽 룰에 “임시로 넓게 연” 잔여 규칙이 안 남아 있는가
마무리
DMZ 는 결국 “외부에 열되, 그 대가로 내부까지 열리지는 않게” 하는 완충 장치예요. 무엇을 올릴지(3절), 어느 방향으로 흘릴지(4·5절), 어떻게 배치할지(6절)만 원칙대로 잡으면, 서버 하나가 털려도 피해를 그 칸에서 끊을 수 있어요. 핵심 문장 하나만 기억하면 됩니다 — 신뢰도 낮은 쪽에서 높은 쪽으로 가는 길은 기본 차단, 예외는 최소한으로.
일단 오늘은 여기까지…..
다음 글에서는 이 위에 얹는 망분리(물리/논리)와 프록시 경유 접속 이야기를 좀 더 구체적으로 정리해볼게요.
