1번에서 만든 서버들(Web/App/DB)에 아직 네트워크가 없다는 가정에서 시작. 이번엔 "왜 이렇게 배치해야 하는가"를 순서대로 배우는 대신, 뚫리는 경로를 하나씩 막아가는 관점으로 기록해봤다.
Web, App, DB 세 서버 모두에 공인 IP를 부여하고 인터넷에 바로 연결.
💥 결과: 하루 만에 DB의 3306 포트로 전 세계에서 로그인 시도가 유입됨. 특정 대상을 노린 공격이 아니라, 열린 포트를 찾아다니는 자동 스캐너에 그냥 걸린 것.
🛠 교훈: 공인 IP = 전 인터넷에 대한 접근 허용. DB나 App처럼 외부와 직접 통신할 이유가 없는 서버까지 같은 방식으로 열어둔 게 문제. 통신 필요 여부에 따라 서버를 나눠 배치해야 한다는 최소 권한(Least Privilege) 원칙, 그리고 이를 위한 네트워크 분리(Segmentation) 개념을 확인.
이번엔 정반대로, 2005년식 사내 데이터센터를 가정해 웹 서버·사내 업무 서버·DB·관리자 PC를 전부 사설 IP로 내부망에 몰아넣음.
💥 결과: 안전해졌지만 외부 고객이 웹 서버에 접속 자체를 못 함. 서비스 목적을 상실.
🛠 교훈: 전부 개방/전부 폐쇄 둘 다 답이 아님. DMZ(외부 노출이 필요한 서버만 모아두는 완충 구역)를 인터넷과 내부망 사이에 둬야 함. DMZ ↔ 내부망, DMZ ↔ 인터넷 경계마다 Firewall이 트래픽을 통제하고, 물리 장비는 VLAN으로 논리 분리.
웹 서버는 DMZ, DB는 내부망으로 재배치 완료. 그런데 DB가 OS 패치를 받아야 하는데 내부망이라 인터넷에 나갈 수가 없음.
💥 결과: 보안은 지켰는데 운영(패치, 업데이트)이 마비됨.
🛠 교훈: NAT을 도입. 내부망 서버가 먼저 요청을 보낼 때(Outbound)만 공인 IP로 변환해서 내보내고, 그 요청에 대한 응답만 다시 들여보냄. 요청한 적 없는 트래픽(순수 Inbound)은 여전히 차단 — NAT의 연결 상태 테이블이 "누가 먼저 요청했는지"를 기억하기 때문.
여기서 짚고 넘어간 오해: "NAT이 있으면 외부에서도 DB에 접속되는 거 아니냐" → 아니다. Outbound(내부가 먼저 나가는 것)와 Inbound(외부가 먼저 들어오는 것)는 완전히 다른 방향의 문제이고, NAT은 전자만 허용한다.