한 문장 요약: 외부 요청을 받는 입구만 공개하고, 나머지 서버는 역할별로 나눈 뒤 필요한 연결만 허용한다.
1. 네트워크를 왜 나누는가?
웹 서버가 공격당했다고 DB와 관리 시스템까지 바로 접근할 수 있어서는 안 된다. Network Segmentation(네트워크 분리)은 이런 피해 확산을 줄이기 위해 서버를 구역별로 나누고, 구역 사이의 통신을 제한하는 설계다.
예를 들어 사용자는 웹 서비스에 접속할 수 있지만 DB에 직접 접속할 필요는 없다. Web 서버도 화면과 요청 전달을 담당할 뿐, App을 건너뛰고 DB에 접근할 필요는 없다.
이 글에서는 Web → App → DB의 3-Tier 구조를 기준으로 설계한다. 설명에 사용하는 포트는 Web 80번, App 5000번, MySQL 3306번이다.
2. Public과 Private는 무엇이 다른가?
Subnet은 VPC 안에서 서버를 배치하는 주소 구역이다. Public·Private 여부는 이름이 아니라 Route Table에 적힌 통신 경로로 판단한다.
구역 | 통신 경로 | 배치할 대상 |
Public · 공개 구역 | 인터넷 연결 장치인 Internet Gateway로 직접 가는 경로가 있음 | 인터넷용 ALB, 필요 시 Public NAT Gateway |
Private · 비공개 구역 | Internet Gateway로 직접 가는 경로가 없음 | Web·App 서버 |
Isolated · 격리 구역 | VPC 밖으로 나가는 경로가 없음 | DB 등 외부 통신이 필요 없는 서버 |
Route Table을 주소별 길 안내표라고 보면 이해하기 쉽다.
- Public의 대표 경로:
0.0.0.0/0 → Internet Gateway
- Private의 선택적 출구:
0.0.0.0/0 → NAT Gateway
0.0.0.0/0은 더 구체적인 경로가 없는 모든 IPv4 목적지를 뜻한다.
Public Subnet에 넣었다고 모든 EC2가 바로 공개되는 것은 아니다. IPv4 직접 통신에는 공인 IP와 허용된 보안 규칙도 필요하다.
또한 구역만 나눠도 서버 사이의 통신이 자동 차단되지는 않는다. VPC 내부 경로가 있으므로 다음 단계의 접근 규칙을 함께 설정해야 한다.
공식 근거: AWS Subnet과 경로
3. 외부 입구와 내부 서버를 분리하기
그림 1 · 서비스 접속 — 왼쪽에서 오른쪽으로
읽는 순서: 사용자 → ALB(입구) → Web(화면) → App(기능) → DB(데이터).
예시: 회원 정보를 조회하면 Web이 요청을 App에 전달하고, App이 DB에서 데이터를 읽는다.
화살표는 요청 방향이다. 응답은 같은 연결로 돌아오며 그림에서는 생략했다. 그림의 차단 정책은 Subnet 배치와 SG 접근 규칙을 함께 적용하는 목표 설계다.
WAF는 ALB 입구에 적용하는 웹 요청 검사 정책이다. 별도의 중간 서버가 아니다. Web을 반드시 Public에 둘 필요는 없으며, 이 설계에서는 ALB 뒤의 Private에 둔다.
인터넷용 ALB는 서로 다른 AZ(서로 분리된 가용영역, Available Zone)의 Public Subnet 두 개에 배치한다. 그림은 논리적인 통신 흐름을 보여주며 서버 수나 이중화까지 나타내지는 않는다.
그림의 허용 경로는 사용자 → ALB 443번, ALB → Web 80번, Web → App 5000번, App → DB 3306번으로 설정한다. 내부 전송 암호화가 필요하면 ALB → Web도 HTTPS로 구성한다.
4. 필요한 연결만 허용하기
Security Group(SG)은 서버에 연결하는 통신 허용 규칙이다. “App은 Web에서 오는 5000번 연결만 받는다”처럼 누가, 어디에, 어떤 포트로 연결할 수 있는지 정한다.
출발지 → 목적지 | 포트 | 정책 | 이유 |
사용자 → ALB | TCP 443 | 허용 | 공개 웹 서비스 접속 |
ALB SG → Web SG | TCP 80 | 허용 | 요청 전달 |
Web SG → App SG | TCP 5000 | 허용 | 서비스 기능 호출 |
App SG → DB SG | TCP 3306 | 허용 | DB 조회 |
Web → DB | TCP 3306 | 차단 | App을 건너뛰는 접근 방지 |
인터넷 → Web·App·DB | 서비스 포트·SSH 22 | 직접 접근 차단 | 공개 입구와 관리 경로 분리 |
SG에는 명시적인 차단 규칙을 넣는 대신 불필요한 허용 규칙을 두지 않는다. 여러 SG가 연결된 서버는 허용 규칙이 합쳐지므로, 다른 SG에 전체 허용이 남아 있지 않은지도 확인한다.
보내는 쪽의 Outbound와 받는 쪽의 Inbound를 함께 맞춘다. ALB가 서버의 정상 여부를 확인하는 Health Check도 허용해야 한다. 확인용 포트가 서비스 포트와 다르면 따로 추가한다.
SG는 허용된 연결의 응답을 기억하므로 응답만을 위한 반대 방향 규칙은 보통 필요하지 않다. 다만 SG로 서버 출처를 제한해도 사용자 로그인과 서비스 권한 검사는 별도로 해야 한다.
공식 근거: SG 규칙, ALB의 접근 규칙
SG·NACL·WAF는 각각 어디를 지키는가?
도구 | 쉽게 말하면 | 확인하는 내용 |
Security Group | 서버별 출입 규칙 | 출발지·목적지·포트; 허용된 연결의 응답을 기억 |
Network ACL(NACL) | Subnet 구역의 경계 규칙 | 출발지·목적지·포트; 허용·거부 가능, 응답도 별도 설정 |
WAF | 웹 요청 검사기 | 주소·Header·Query 등 HTTP 요청 내용 |
처음에는 SG로 계층별 통신을 제한하고, NACL은 추가 경계 통제가 필요한 경우에 사용한다. NACL을 좁힐 때는 응답에 사용하는 임시 포트도 고려해야 한다.
공식 근거: AWS NACL
5. 비공개 서버가 밖으로 나가는 방법
App 서버가 외부 API를 호출하거나 업데이트를 받으려면 외부로 나가는 경로가 필요하다. 이때 선택할 수 있는 것이 NAT Gateway다.
그림 2 · 외부 통신 — 서버가 먼저 나가는 길
기억할 것: ALB는 서비스 입구, NAT는 서버의 인터넷 출구.
예시: App이 외부 API를 호출하면 NAT와 Internet Gateway를 거쳐 나가고, 응답은 같은 연결로 돌아온다. Public NAT Gateway는 Public Subnet에 둔다.
이 설계의 DB는 인터넷 출구에 연결하지 않는다.
NAT는 서버가 시작한 외부 연결과 그 응답을 지원한다. 인터넷 사용자가 Private 서버로 들어오는 공개 입구로 쓰는 것은 아니다. 악성 웹 요청 검사와 목적지 제한을 자동으로 해주는 도구도 아니다.
방향은 서버 기준으로 판단한다. Web → App 요청은 Web에서는 Outbound, App에서는 Inbound다. 인터넷과의 통신만 Inbound·Outbound로 구분하는 것은 아니다.
AWS 서비스에만 접근하면 VPC Endpoint, 즉 인터넷을 거치지 않는 서비스 접속 경로를 비교할 수 있다. 다만 Endpoint가 일반 인터넷 API나 모든 업데이트 저장소를 대신하지는 않는다.
DB에는 기본 인터넷 경로를 두지 않는다. EC2에 직접 DB를 설치한 경우에는 패치용 내부 저장소나 별도 관리 경로를 정해야 한다.
NAT와 일부 Endpoint에는 비용이 발생한다. Lab은 필요한 통신부터 정하고, 비용과 장애 영향을 비교해 출구 방식을 선택한다.
공식 근거: AWS NAT Gateway
6. 관리자 접속은 따로 설계하기
SSH 22번을 인터넷 전체에 열어두면 로그인 공격에 노출된다. AWS에서는 Session Manager(SSM)를 사용해 SSH 포트를 공개하지 않고 EC2를 관리할 수 있다.
관리자가 IAM 권한으로 세션 시작 → EC2의 SSM Agent가 서비스와 연결 → 관리 세션 사용
이때 EC2가 서비스로 Outbound HTTPS 443 연결을 시작한다. 관리자 접속을 위해 EC2의 Inbound 443을 열어야 하는 구조는 아니다.
공식 근거: SSM의 연결 조건
7. Private에 두면 충분히 안전한가?
Private 배치는 인터넷 직접 노출을 줄여준다. 그러나 공격자가 Web을 장악하면 Web에 허용된 App 연결과 IAM 권한은 사용할 수 있다.
따라서 다음 세 가지를 함께 적용해야 한다.
- 연결 제한: 이전 계층에서 필요한 포트로만 접근한다.
- 권한 제한: 서비스의 인증·인가와 AWS Role 권한을 최소화한다.
- 행동 기록: 웹 요청, 서버의 명령 실행, AWS API 호출을 남긴다.
“내부 서버라는 이유만으로 모두 신뢰하지 않는다”는 것이 Zero Trust의 핵심 방향이다. SG 분리는 그 원칙을 적용하는 한 부분이다.
8. 결론
네트워크 분리의 핵심은 공개할 입구를 줄이고, 서버 사이에 필요한 연결만 남기는 것이다.
근두운에서는 직접 공개된 22·5000번 경로를 줄이고, ALB를 통한 서비스 접속과 SSM을 통한 관리 접속을 분리하는 것이 우선이다. 여기에 서버별 권한 제한과 로그 수집을 더해야 침해 후 피해 확산까지 줄일 수 있다.
