Azure 네트워크 보안의 가장 기초이자 가장 많이 틀리는 영역이 바로 NSG(Network Security Group) 설계입니다. “일단 열어두자”로 시작한 NSG는 금세 수십 개의 규칙이 뒤엉켜 관리 불가 상태가 됩니다. 이번 글에서는 실전에서 검증된 NSG 설계 원칙과 자주 하는 실수를 정리합니다.
NSG 기본 동작 원리
NSG는 상태 저장(stateful) 방화벽입니다. 즉, inbound로 허용된 트래픽에 대한 return 트래픽은 자동으로 허용됩니다. 이 특성을 이해하지 못하면 불필요한 outbound 규칙을 추가하게 됩니다.
평가 순서
- 우선순위(Priority) 100부터 4,096까지, 낮은 숫자가 먼저 평가
- 첫 번째 매칭되는 규칙이 적용됨 (Allow 또는 Deny)
- 일치하는 규칙이 없으면 Default Deny 적용
기본 규칙(Default Rules)
- Inbound: VirtualNetwork 내부 허용, AzureLoadBalancer 허용, 인터넷 Deny
- Outbound: VirtualNetwork 내부 허용, 인터넷 허용, 기타 Deny
기본 규칙은 수정할 수 없지만, 우선순위 65,000 이하의 사용자 규칙으로 덮어쓸 수 있습니다.
NSG 설계 원칙
1. Subnet 단위가 기본, NIC는 예외
NSG는 Subnet 또는 NIC(Network Interface)에 적용 가능합니다. 원칙은 Subnet 단위로 적용하는 것입니다. NIC 단위는 관리가 분산되어 전체 가시성이 떨어집니다.
예외 상황: 동일 Subnet 내 일부 VM만 다른 정책이 필요한 경우. 이때도 Application Security Group(ASG)로 해결 가능한지 먼저 검토하세요.
2. Application Security Group(ASG) 적극 활용
ASG는 VM을 논리적으로 그룹화하는 기능입니다. IP 주소 대신 ASG 이름으로 규칙을 작성할 수 있어 관리가 훨씬 쉬워집니다.
기존 방식:
- Source: 10.0.1.10, 10.0.1.11, 10.0.1.12
- Destination: 10.0.2.10, 10.0.2.11
ASG 방식:
- Source: asg-webservers
- Destination: asg-dbservers
서버가 추가·삭제될 때 ASG 멤버십만 변경하면 되므로 규칙을 수정할 필요가 없습니다.
3. Service Tag 활용
특정 Azure 서비스의 IP 대역은 Microsoft가 관리합니다. 직접 IP 대역을 입력하지 말고 Service Tag를 사용하세요.
자주 쓰는 Service Tag:
AzureLoadBalancer: Azure LB 헬스체크용Storage,Storage.KoreaCentral: Storage 서비스Sql,AzureCosmosDB: 데이터베이스 서비스AzureMonitor: Log Analytics, Application InsightsAzureFrontDoor.Backend: Front Door에서 오는 트래픽
4. 최소 권한 원칙
규칙은 가장 구체적으로 작성합니다. Any:Any:Allow는 NSG가 존재하지 않는 것과 같습니다.
나쁜 예:
- Source: Any / Port: Any / Action: Allow
좋은 예:
- Source: asg-webservers / Destination: asg-dbservers / Port: 1433 / Action: Allow
실전에서 자주 하는 실수
실수 1: Subnet과 NIC에 NSG 동시 적용
Subnet NSG와 NIC NSG가 모두 적용된 경우, 두 NSG를 모두 통과해야 트래픽이 허용됩니다. 문제는 진단이 어려워진다는 점입니다. 트래픽이 차단될 때 어느 NSG가 차단했는지 파악에 많은 시간이 소요됩니다.
원칙은 둘 중 하나만 쓰는 것입니다.
실수 2: 너무 넓은 CIDR 허용
“10.0.0.0/8″로 사내 전체를 허용하는 규칙은 간편하지만, 침해 시 피해 범위가 걷잡을 수 없이 커집니다. 가능하면 /24 또는 /26 수준으로 좁혀 작성하세요.
실수 3: Outbound 규칙 무시
Inbound에만 집중하고 Outbound를 Any:Allow로 두는 경우가 많습니다. 하지만 보안 사고가 발생하면 공격자는 Outbound를 통해 데이터를 탈취합니다. Outbound도 필요한 목적지만 허용하는 것이 정석입니다.
실수 4: 규칙 번호 간격 없이 연속 배치
우선순위를 100, 101, 102… 처럼 연속 배치하면 중간에 규칙을 삽입할 때 모두 재번호해야 합니다. 100, 200, 300 단위로 간격을 두고 배치하세요.
실수 5: AzureLoadBalancer 태그 차단
Internal Load Balancer 뒤에 VM을 배치할 때 AzureLoadBalancer 태그에서 오는 헬스체크를 차단하면 백엔드가 Unhealthy 상태가 됩니다. 기본 규칙은 유지하거나 명시적으로 Allow 규칙을 추가하세요.
실전 NSG 설계 예시: 3-Tier 웹 애플리케이션
NSG-Web (Web Tier Subnet)
- Inbound 100: Internet → :443 (Allow) — 공개 HTTPS
- Inbound 110: AzureLoadBalancer → :443 (Allow) — 헬스체크
- Inbound 4096: Any → Any (Deny) — 명시적 Deny
- Outbound 100: asg-web → asg-app:8080 (Allow)
NSG-App (App Tier Subnet)
- Inbound 100: asg-web → asg-app:8080 (Allow)
- Inbound 4096: Any → Any (Deny)
- Outbound 100: asg-app → asg-db:1433 (Allow)
NSG-DB (DB Tier Subnet)
- Inbound 100: asg-app → asg-db:1433 (Allow)
- Inbound 110: Bastion Subnet → :1433 (Allow) — 관리용
- Inbound 4096: Any → Any (Deny)
NSG Flow Logs 활용
NSG가 실제로 어떤 트래픽을 허용·차단하는지 추적하려면 NSG Flow Logs를 활성화하세요. Storage Account로 저장되고, Traffic Analytics와 연동하면 시각화도 가능합니다.
활용 시나리오:
- 보안 사고 후 포렌식
- 불필요한 규칙 식별 (전혀 매칭되지 않는 규칙)
- 비정상 트래픽 패턴 탐지
- 컴플라이언스 감사 증빙
NSG 관리 자동화
규모가 커지면 수동 관리는 불가능합니다. 다음 도구들을 활용하세요.
- Bicep/Terraform: NSG 규칙을 코드로 관리
- Azure Policy: 금지 규칙 자동 차단 (예: RDP 포트 인터넷 노출 금지)
- Azure Firewall Manager: 여러 NSG·Firewall 통합 관리
- Microsoft Defender for Cloud: 보안 추천 자동 제공
NSG 한계와 대안
NSG는 기본적인 L3/L4 필터링만 가능합니다. 다음 기능이 필요하면 추가 솔루션을 고려하세요.
- L7 검사 (HTTP 패턴, SQL Injection): Azure Firewall Premium, WAF
- FQDN 기반 필터링: Azure Firewall
- IDS/IPS: Azure Firewall Premium 또는 3rd party NVA
마무리
NSG는 단순해 보이지만 설계를 잘못하면 운영 중 가장 큰 골칫거리가 됩니다. Subnet 단위 적용, ASG 활용, 최소 권한 원칙 세 가지만 지켜도 대부분의 문제를 예방할 수 있습니다. 규칙이 많아지기 전에 체계적으로 설계하세요.