Azure VNet·Subnet·NSG 기초: 주소 계획부터 트래픽 규칙 검증까지

Azure Portal에서 Virtual Network를 만드는 일은 매우 단순해 보인다. 주소 범위를 고르고, Subnet을 만들고, Network Security Group을 연결한 뒤 규칙 몇 개를 추가하면 된다. 하지만 어려운 일은 Create 버튼을 누르는 것이 아니다. 배포 전과 배포 후에 다음 질문에 답할 수 있어야 한다.

어떤 구성요소가 연결을 시작할 수 있는가?
실제로 필요한 목적지와 포트는 무엇인가?
패킷은 어떤 경로로 이동하는가?
어떤 규칙이 허용하거나 차단하는가?
필요한 경로와 금지된 경로를 모두 어떻게 증명할 것인가?

입문자는 VNet을 사설 방, Subnet을 벽, NSG를 작은 Firewall 장비처럼 생각하기 쉽다. 이 비유는 불완전하다. 같은 VNet 안의 리소스는 Azure System Route를 통해 기본적으로 통신할 수 있다. 두 리소스를 서로 다른 Subnet에 배치하면 주소가 정리되고 정책을 연결할 지점이 생기지만 두 리소스 사이의 트래픽이 자동 차단되지는 않는다. NSG는 Layer 3·Layer 4 흐름을 필터링하지만 Route를 만들거나 Source Network Address Translation(SNAT)을 수행하거나, 이름을 해석하거나, 사용자를 인증하거나, 애플리케이션이 실제로 수신 중임을 증명하지 않는다.

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 나눈 학습 계획의 다섯 번째 상세 노트다. Module 1 복습 글은 전체 보안 통제 지도를 제공한다. 바로 앞의 Public IP 없는 VM 설계 글에서는 관리, 애플리케이션 인바운드, 인터넷 아웃바운드, Azure 서비스 접속 경로를 분리했다. 이번에는 그 경로를 실제로 통제하는 VNet, Subnet, NSG의 기초를 설명한다.

이 글은 강의 녹취록, 평가 답안, 운영 환경 배포 기록 또는 애플리케이션별 위협 모델을 대신하는 문서가 아닌 독립 학습 노트다. 제품 동작과 제약은 2026년 8월 11일 Microsoft 공식 문서를 기준으로 검토했다.

이 글에서 다루지 않는 범위

이번 글은 단순화한 웹·앱·데이터베이스 3계층 워크로드로 IPv4 주소 계획과 NSG 판정 방식을 학습한다. Portal, CLI, PowerShell, Bicep 또는 Terraform 배포 절차는 제공하지 않는다. 전체 IPv6 설계, Hub-and-Spoke Transit, User-Defined Route 구현, VPN과 ExpressRoute 구성, Azure Firewall Policy, WAF 튜닝, Private Link DNS, 운영체제 보안 강화는 별도 주제다. 예시 Port는 학습용 통신 계약이며 운영 환경에 바로 적용할 규칙 모음이 아니다.

1. 이 글이 도와줄 의사결정

이번 글의 실질적인 질문은 다음과 같다.

입문자는 하나의 Azure VNet을 어떻게 Subnet으로 나누고, 애플리케이션의 필수 연결을 최소 권한 NSG 규칙으로 바꾸며, 허용·차단 트래픽이 의도대로 동작함을 어떻게 증명해야 할까?

이 글을 읽은 뒤에는 다음 작업을 할 수 있어야 한다.

/16, /24, /29 CIDR 표기를 추측하지 않고 읽는다.
Azure 예약 주소를 제외한 실제 사용 가능 IPv4 주소 수를 계산한다.
앞으로 연결할 네트워크와 겹치지 않는 주소 범위를 고른다.
역할, 신뢰 수준, 확장 방식과 수명 주기에 따라 VNet을 Subnet으로 나눈다.
Subnet이 자동 보안 장벽이 아닌 이유를 설명한다.
NSG 규칙의 모든 항목을 왼쪽부터 차례로 읽는다.
방향과 우선순위에 따라 어느 규칙이 적용되는지 예측한다.
상태 저장 반환 트래픽과 기존 연결의 동작을 설명한다.
Subnet NSG와 NIC NSG의 평가 관계를 이해한다.
의도를 숨기지 않고 Service Tag와 Application Security Group(ASG)을 사용한다.
3계층 통신 흐름표를 작은 학습용 규칙 모음으로 바꾼다.
구성, 규칙 모의 판정, 실제 연결과 흐름 증적을 구분해 검증한다.

결과물은 “NSG가 있다”는 문장이 아니다. 다음을 묶은 작은 증적 패키지다.

주소 계획
+ Subnet 할당표
+ 필수 통신 흐름 목록
+ 버전이 관리되는 NSG 규칙
+ 실제 적용 규칙과 경로 내보내기
+ 허용·차단 테스트 결과
+ 로그 저장 위치와 담당자
+ 재검토일과 롤백 방법

2. VNet, Subnet, Route, NSG를 하나의 모델로 이해하기

도시 비유를 조심스럽게 사용해 보자.

Azure 개념	도시 비유	기술적 역할
VNet 주소 공간	도시 전체 경계와 주소 계획	어떤 사설 IP 범위가 가상 네트워크에 속하는지 정의
Subnet	도시 안의 구역	더 작은 CIDR 범위를 할당하고 리소스 배치·정책 적용 범위 제공
Network Interface(NIC)	건물의 네트워크 출입구	VM을 하나의 Subnet에 연결하고 Private IP 구성 수신
Route	도로 표지판과 다음 교차로	목적지 Prefix에 대한 다음 홉 선택
NSG	교통 검문소	출발지, 목적지, Port, Protocol, 방향으로 L3/L4 흐름 허용·차단
DNS	주소 안내 책자	이름을 주소로 해석
게스트 방화벽과 Listener	건물의 마지막 문과 서비스 창구	운영체제와 애플리케이션이 연결을 받을지 결정

이 비유를 실제 물리 네트워크까지 확장하면 오히려 틀리기 쉽다. Azure Network는 물리 Ethernet Segment가 아니라 Software-defined Layer 3 Network다. Subnet 경계에 보이지 않는 Firewall이 자동 생성되지 않는다. Azure는 주소 일부를 예약하고 플랫폼 서비스를 제공하는 방식도 가정용 네트워크와 다르다.

다음 모델을 기억한다.

주소 공간은 IP가 어디에 속하는지 정한다.
Route는 다음 홉을 고른다.
NSG는 흐름의 통과 여부를 판단한다.
이 셋 중 어느 것도 애플리케이션이 실제로 수신 중임을 보장하지 않는다.

3. CIDR를 고르기 전에 연결 대상 조사하기

익숙하다는 이유로 10.0.0.0/16부터 선택하지 않는다. 먼저 VNet의 예상 수명 동안 연결해야 할 수 있는 모든 네트워크를 조사한다. 아래 표는 중복 확인을 마친 학습 예제다. 실제 기록에는 조직이 사용하는 정확한 Prefix와 모든 중복 검사를 통과했다는 증적을 넣어야 한다.

현재 또는 미래 연결 네트워크	현재 CIDR	연결 방식	담당자	중복 확인 여부
사내 데이터센터	`10.0.0.0/16`	ExpressRoute	네트워크 팀	완료
지사	`172.16.0.0/16`	Site-to-Site VPN	네트워크 팀	완료
기존 Azure 운영 환경	`10.20.0.0/16`	VNet Peering	플랫폼 팀	완료
재해 복구 지역	`10.50.0.0/16` 예약	Global VNet Peering	플랫폼 팀	완료
AWS 또는 Google Cloud	`10.60.0.0/16` 예약	향후 Interconnect	클라우드 플랫폼 팀	완료
외부 업체 네트워크	`192.168.50.0/24`	VPN	서비스 담당자	완료

RFC 1918에는 익숙한 세 가지 Private IPv4 범위가 있다. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이다. Azure는 문서화된 시나리오에서 RFC 6598의 100.64.0.0/10 같은 공유 주소 공간도 Private으로 취급할 수 있다. “Private”이라는 말은 “전 세계에서 고유하다”는 뜻이 아니다. 수많은 조직이 같은 범위를 사용한다.

서로 격리된 두 VNet이 같은 CIDR를 사용하는 것은 기술적으로 가능하다. 문제는 나중에 연결할 때 나타난다. 일반 VNet Peering에는 겹치지 않는 주소 공간이 필요하며, Hybrid 또는 Cross-cloud 경로가 겹치면 어느 목적지로 보낼지 모호해진다. 운영 중인 시스템의 주소를 다시 정하는 일은 배포 전에 중복 없는 Block을 예약하는 것보다 훨씬 어렵다.

주소 의사결정 기록에는 조사일과 승인자를 남긴다.

선택 Block: 10.40.0.0/16
환경: 학습 예제 / 운영 환경에서는 별도 확인
확인 대상: Azure, On-premises, DR, 다른 Cloud, 외부 업체
성장 기간: 24~36개월
담당자: 플랫폼 네트워크
재검토 조건: 새 Peering, VPN, Region, Cloud, 인수합병 또는 주소 확장

4. CIDR를 겁내지 않고 읽는 법

CIDR 표기는 기준 주소와 Prefix 길이를 합친다. IPv4는 32bit이며 Prefix는 앞에서부터 몇 bit가 네트워크를 나타내는지 말한다. 나머지 bit가 그 안의 주소를 나타낸다.

전체 주소 수 = 2 ^ (32 - Prefix 길이)

CIDR	Host bit	전체 IPv4 주소	Azure 예약 주소 5개를 제외한 사용 가능 주소	학습 포인트
`/16`	16	65,536	일반적으로 하나의 거대한 Workload Subnet으로 쓰지 않음	나누어 쓸 VNet 상위 Block 예시
`/24`	8	256	251	이해하기 쉬운 일반 Workload Subnet 예시
`/26`	6	64	59	일부 전용 플랫폼 Subnet의 최소 크기
`/27`	5	32	27	확장 여유가 제한적인 작은 Subnet
`/29`	3	8	3	지원되는 최소 IPv4 Subnet, 운영 확장에는 대개 불리함

Prefix 숫자가 작을수록 주소 Block은 더 크다. /16은 /24보다 훨씬 크다. Prefix는 곧 리소스 용량 목표가 아니다. 서비스마다 최소 크기가 있을 수 있고 확장·업그레이드 중 여러 주소를 사용할 수 있다.

학습 VNet을 나눠 보자.

VNet: 10.40.0.0/16

가능한 /24 하위 범위:
10.40.0.0/24
10.40.1.0/24
...
10.40.255.0/24

가능한 256개 하위 범위를 모두 즉시 만들어야 한다는 뜻은 아니다. 상위 Block 안에서 중복 없이 체계적으로 할당할 공간이 있다는 뜻이다.

5. 겹치지 않는 주소 계획 만들기

그림만 그리지 말고 표로 관리한다.

할당 대상	CIDR	목적	상태	확장 참고사항
VNet	`10.40.0.0/16`	전체 Workload Network	할당	연결 네트워크와 중복 금지
`snet-edge`	`10.40.0.0/24`	승인된 애플리케이션 Frontend	할당	플랫폼별 크기 재확인 필요
`snet-web`	`10.40.10.0/24`	Web Tier Backend	할당	Scale-out·Upgrade 여유
`snet-app`	`10.40.20.0/24`	Application Tier Service	할당	Scale-out·Blue/Green 여유
`snet-data`	`10.40.30.0/24`	Database Tier Host	할당	Private Endpoint 별도 평가
`snet-management`	`10.40.40.0/24`	승인된 관리 구성요소	예약	실제 관리 설계는 범위 밖
향후 플랫폼·Workload	나머지 중복 없는 범위	성장, DR 또는 전용 서비스	예약 Pool	IP 관리 절차로만 할당

예시 사이의 빈 범위는 의도적이다. 관련 Subnet을 추가할 여유가 생기고 Diagram과 Route Summary를 읽기 쉬워진다. 운영 환경에서는 서로 다른 크기와 중앙 IP Address Management(IPAM) 시스템을 사용할 수 있다. 대규모 환경은 Azure Virtual Network Manager의 IPAM 기능을 검토할 수 있으며, 작은 팀은 담당자와 검토 절차가 있는 통제된 대장으로 시작할 수 있다.

조직의 실제 자산 목록을 확인하지 않고 10.40.0.0/16을 그대로 운영 환경에 복사하지 않는다. 이 범위는 문서 예시이지 어디서나 안전한 주소가 아니다.

6. Azure 예약 주소와 확장 여유 계산하기

Azure는 모든 IPv4 Subnet에서 다섯 주소를 예약한다.

주소 위치	`10.40.10.0/24` 예시	Azure 용도
첫 번째	`10.40.10.0`	Network Identifier
두 번째	`10.40.10.1`	Default Gateway
세 번째	`10.40.10.2`	Azure DNS Mapping
네 번째	`10.40.10.3`	Azure DNS Mapping
마지막	`10.40.10.255`	예약 Broadcast 주소

따라서 /24는 전체 256개 중 Azure 리소스가 251개를 사용할 수 있으며 254개가 아니다. /29는 전체 8개 중 3개만 사용할 수 있다. Azure는 Layer 3 Overlay이므로 마지막 주소가 예약되어 있다고 전통적인 Broadcast나 Multicast 동작이 제공되는 것도 아니다.

Subnet 크기를 정할 때 다음 항목도 포함한다.

현재 VM과 NIC 수
Scale-out, Rolling Upgrade, Blue/Green 배포 또는 Failover 중 임시 주소
Subnet 주소를 소비하는 Private Endpoint와 Platform Instance
서비스별 전용 Subnet 크기
Monitoring, Recovery와 Management 구성요소
향후 2~3년 성장량
주소 재설정 없이 확장할 수 있는 연속된 여유 공간

“VM이 6대이므로 오늘은 /28이면 된다”는 설계가 아니다. 다음 배포에서 Surge Instance나 병렬 교체가 필요하거나 서비스 최소 크기가 더 클 수 있다. 계산식과 성장 가정을 함께 기록한다.

7. 역할·신뢰 수준·확장·수명 주기로 Subnet 나누기

Subnet 분리는 의미 있는 차이를 표현해야 한다. 다음은 리소스를 분리할 합리적인 근거다.

애플리케이션 역할: Edge, Web, Application, Data, Management와 Private Endpoint는 필수 흐름이 다르다.
신뢰 수준: 인터넷을 마주하는 Frontend와 Database가 하나의 구분 없는 정책을 물려받아서는 안 된다.
확장 방식: Stateless Web Tier와 고정 Management 구성요소는 확장 방식이 다르다.
수명 주기: 플랫폼 팀이 관리하는 공유 서비스와 앱 팀이 관리하는 Instance는 변경 일정이 다를 수 있다.
Routing 요구: 특정 Subnet은 Egress를 Firewall로 보내는 Route Table이 필요할 수 있다.
서비스 요구: Azure Firewall, Bastion, VPN Gateway, Route Server, DNS Private Resolver에는 문서화된 Subnet 이름 또는 크기 요구사항이 있다.
Delegation 요구: 일부 Azure Service는 위임된 Subnet이 필요하며 공유할 수 있는 리소스를 제한한다.

두 극단을 모두 피한다.

모든 것을 하나의 Subnet에 배치
→ 처음에는 단순하지만 정책 경계와 변경 담당이 불분명해짐

VM 하나마다 Subnet 생성
→ 객체가 지나치게 늘고 예약 주소가 낭비되며 정책과 운영이 파편화됨

같은 신뢰 경계, 필수 흐름, Route 동작, 확장 방식과 담당자를 공유하는 구성요소를 묶는 것이 좋은 출발점이다. 예외는 TemporaryAllowAll2 같은 규칙 이름에서 뒤늦게 발견되지 않도록 명시적으로 기록한다.

8. 플랫폼 서비스와 미래 Subnet을 위한 공간 남기기

일부 Azure Service는 전용 Subnet을 요구하거나 충분한 용량을 강하게 권장한다. 현재 예시는 다음과 같다.

서비스	현재 설계 기준	입문자가 기억할 점
Azure Firewall	전용 `AzureFirewallSubnet`, 최소 `/26`	중앙 검사를 계획하기 전에 VNet을 가득 채우지 않음
Azure Bastion	전용 `AzureBastionSubnet`, 현재 전용 배포 최소 `/26`	Bastion 선택 시 올바른 이름과 용량 예약
VPN Gateway	`GatewaySubnet`, `/27` 이상 권장	Hybrid 연결도 계획된 주소 공간을 사용함
Azure DNS Private Resolver	Inbound·Outbound Endpoint 전용 Subnet, 각각 최소 `/28`	DNS 설계에 Subnet 두 개가 추가될 수 있음
Application Gateway v2	전용 Subnet, 확장 목적으로 `/24`를 흔히 권장	Frontend 용량은 현재 Instance 수만으로 정하지 않음
Private Endpoint	Subnet의 Private IP 소비, 항상 전용 Subnet이 필요한 것은 아님	Endpoint 수와 담당 체계를 함께 결정

이 값들은 바뀔 수 있고 SKU나 시나리오에 따른 별도 요구사항도 있다. 이 표는 계획을 시작하기 위한 질문 목록으로 사용하고 배포 전 최신 제품 문서를 다시 확인한다.

핵심은 “모든 Subnet을 /24로 만든다”가 아니다. “쉬운 범위부터 할당하기 전에 플랫폼 요구사항을 조사한다”는 것이다.

9. Subnet은 자동 보안 장벽이 아니다

Azure는 같은 VNet 안의 리소스가 기본적으로 서로 도달할 수 있도록 System Route를 만든다. Subnet은 주소를 나누고 NSG와 Route Table을 연결할 범위를 제공하지만 snet-web과 snet-data를 만드는 것만으로 Web-to-Database 트래픽이 차단되지는 않는다.

NSG가 존재하면 Priority 65000의 기본 인바운드 규칙 AllowVNetInBound가 있다. VirtualNetwork Service Tag는 “현재 Subnet”보다 넓다. Topology와 Route에 따라 VNet 주소 공간뿐 아니라 Peered VNet이나 On-premises 같은 연결 범위도 포함할 수 있다. 이 기본 규칙을 최소 권한 분리로 생각하면 위험하다.

Subnet만 분리한 상태

Web 10.40.10.4 ───────────────► Database 10.40.30.4:1433
                  System Route
                  아직 의도한 차단 규칙 없음

Segmentation에는 두 가지가 모두 필요하다.

역할을 이해할 수 있는 주소·배치 경계
필요한 출발지, 목적지, Protocol과 Port를 허용하고 불필요한 인접 경로를 차단하는 적용 규칙

모든 아키텍처에서 모든 Subnet 쌍에 Custom Deny가 반드시 필요하다는 뜻은 아니다. Subnet 이름만 보고 의도가 적용됐다고 가정하지 말고 실제 규칙과 결과를 검증해야 한다는 뜻이다.

10. 웹·앱·DB 3계층 참조 구조 그리기

이후 단원에서는 하나의 단순화한 Topology를 계속 사용한다.

인터넷 사용자
    │
    ▼ HTTPS 443
승인된 Reverse Proxy Frontend
학습 가정: Application Gateway v2
snet-edge 10.40.0.0/24
    │
    ▼ HTTPS 443
Web Tier
snet-web 10.40.10.0/24
    │
    ▼ TCP 8443
Application Tier
snet-app 10.40.20.0/24
    │
    ▼ TCP 1433
Database Tier
snet-data 10.40.30.0/24

의도한 애플리케이션 흐름은 순차적이다.

Edge → Web → App → Data

다음 지름길은 실패해야 한다.

Internet ─X→ Web / App / Data 직접 연결
Edge     ─X→ App / Data 직접 연결
Web      ─X→ Data 직접 연결
App      ─X→ 승인되지 않은 Port로 Data 연결

이 학습 구조는 Application Gateway v2가 snet-edge에서 Reverse Proxy로 동작하고 Web Backend에 새 연결을 만든다고 가정한다. 다른 Frontend 제품은 Backend에 다른 Source를 전달할 수 있다. 예를 들어 Azure Load Balancer는 원래 Client Source IP를 보존하며, Load-balancing Rule이 적용 대상 NSG의 허용 규칙을 대신하지 않는다. 뒤의 NSG 예시를 복사하기 전에 선택한 제품이 Backend에 어떤 Source로 연결하는지 다시 확인한다.

Port 443, 8443, 1433은 학습용 예시다. 실제 애플리케이션 통신 계약에는 Listener, 암호화, 인증, Health Probe, 출발지, 목적지와 가용성 요구사항을 기록해야 한다. SQL Server에서 흔히 사용하는 Port라고 해서 모든 Data Tier에서 TCP 1433을 열어야 하는 것은 아니다.

11. 규칙보다 먼저 통신 흐름표 작성하기

규칙은 구현 수단이다. 먼저 흐름과 이유를 기록한다.

ID	목적	출발지	목적지	Protocol / 목적지 Port	예상 결과	담당자	실패 영향
F01	Frontend 전달	`snet-edge`	Web Tier	TCP 443	허용	Edge 팀	사용자 요청 실패
F02	Application 호출	Web Tier	App Tier	TCP 8443	허용	App 팀	Web 요청 실패
F03	Database 호출	App Tier	Data Tier	TCP 1433	허용	Data 팀	Transaction 실패
F04	Database 직접 지름길	Web Tier	Data Tier	TCP 1433	차단	보안 담당자	Lateral Movement 제한
F05	잘못된 App Port	Web Tier	App Tier	TCP 22	차단	보안 담당자	의도하지 않은 관리 경로 방지
F06	잘못된 Database Port	App Tier	Data Tier	TCP 3306	차단	보안 담당자	실제 통신 계약 적용
F07	Public 직접 접속	Internet	App·Data Tier	Any	차단	플랫폼 팀	직접 노출 방지

이 표는 의도적으로 배포에 필요한 모든 항목을 포함하지 않았다. 실제 설계에는 다음 요구사항을 추가한다.

DNS 이름 해석
운영체제 Update와 Package Repository
ID와 시간 동기화
Monitoring과 Log Export
Backup과 Recovery
Load Balancer 또는 Application Health Probe
Vulnerability Management
승인된 사설 경로를 통한 관리
애플리케이션 아웃바운드 종속성

각 종속성에는 결정 담당자가 있어야 한다. “Agent에 여러 기능이 필요하므로 모든 아웃바운드 허용”은 통신 흐름 목록이 아니다.

12. 패킷 하나를 출발지부터 애플리케이션까지 따라가기

Web Tier가 TCP 8443으로 app.internal.example을 호출한다고 가정한다. 문서화된 Outbound·Inbound 평가 순서에 따라 각 종속성을 확인해 보자.

1. DNS
   app.internal.example → 10.40.20.4

2. 출발지 필터링
   Web NIC/Subnet에 적용되는 Outbound NSG가 새 흐름 평가

3. Route 선택
   10.40.20.4에 대한 Web NIC Effective Route → Virtual network Next Hop

4. 목적지 필터링
   App Subnet/NIC에 적용되는 Inbound NSG가 새 흐름 평가

5. 게스트 운영체제
   OS Firewall이 TCP 8443 허용

6. Listener
   애플리케이션이 예상 Interface와 TCP 8443에서 수신

7. TLS와 ID
   인증서, 클라이언트 신원(호출 주체의 ID), 애플리케이션 권한 확인 성공

8. 애플리케이션 상태
   Process가 요청과 종속성을 정상 처리

NSG의 Allow는 해당 범위에서 네트워크 필터 판정이 허용됐다는 뜻일 뿐이다. DNS가 의도한 주소를 반환했는지, Route와 Return Path가 유효한지, Guest Firewall이 허용하는지, Service가 수신 중인지, 인증이 성공하는지를 증명하지 않는다.

반대도 중요하다. 올바른 Route가 NSG Deny를 무시할 수 없다. 장애 분석에서는 NSG를 계속 바꾸기 전에 어느 계층에서 실패했는지 찾아야 한다.

13. NSG가 하는 일과 하지 않는 일

Azure Network Security Group은 분산형 Stateful Layer 3·Layer 4 트래픽 필터다. Inbound와 Outbound 규칙을 가지며 지원되는 Subnet과 VM Network Interface에 연결할 수 있다.

NSG는 다음을 판단할 수 있다.

새 인바운드 또는 아웃바운드 흐름 허용·차단
Source, Source Port, Destination, Destination Port, Protocol 기준 판정
Subnet 또는 NIC 적용 범위
지원되는 IP/CIDR, Service Tag 또는 Application Security Group 사용

NSG는 다음을 수행하지 않는다.

Route 생성 또는 Network Virtual Appliance 선택
SNAT 또는 안정적인 Outbound Public IP 제공
Public·Private Endpoint 생성
DNS 이름 해석 또는 임의 FQDN 기준 필터링
HTTP Path, SQL Injection, Malware 또는 TLS 내용 검사
사용자나 Workload Identity 인증
운영체제 Patch 또는 보안 강화
목적지 애플리케이션의 실제 수신 상태 증명
Architecture가 Inspection, Egress 통제 또는 여러 네트워크의 중앙 운영을 요구할 때 중앙 Firewall Policy 대체

따라서 “NSG는 저렴한 Azure Firewall”이라는 비교는 적절하지 않다. 둘 다 일부 Packet Attribute를 필터링할 수 있지만 Enforcement, Inspection, Routing, Logging과 운영 모델이 다르다. 뒤의 Module 1 상세 글에서 Azure Firewall을 따로 다룬다.

14. NSG 규칙 한 줄을 왼쪽부터 읽는 법

모든 규칙은 하나의 문장으로 읽을 수 있어야 한다.

항목	예시	답해야 할 질문
Name	`Allow-Web-To-App-8443`	이 규칙은 왜 존재하는가?
Priority	`100`	인접 규칙과 비교해 언제 평가되는가?
Direction	Inbound	보호 대상에 들어오는가, 나가는가?
Source	`asg-web`	누가 연결을 시작하는가?
Source port	`*`	어떤 Client-side Port에서 시작할 수 있는가?
Destination	`asg-app`	어떤 역할이 연결을 받는가?
Destination port	`8443`	어떤 Service Port가 필요한가?
Protocol	TCP	어떤 Layer 4 Protocol을 허용하는가?
Action	Allow	일치하는 흐름을 허용하는가, 차단하는가?

소리 내어 문장으로 바꿔 본다.

인바운드 트래픽에서 Web Tier NIC가 임의의 Client Source Port로 시작해 App Tier NIC의 Destination Port 8443으로 연결하는 TCP 흐름을 더 큰 Priority 숫자를 가진 후순위 규칙보다 먼저 허용한다.

Source Port를 보통 `*`로 두는 이유

Client는 Server의 Destination Port 8443에 연결할 때 51542 같은 임시 Source Port를 흔히 선택한다. Source와 Destination을 모두 8443으로 제한하면 Client가 만들지 않는 연결을 기술할 수 있다.

Web Client 10.40.10.4:51542 → App Server 10.40.20.4:8443
                    Source Port                         Destination Port

목적지 Service Port와 출발지 주소 또는 역할을 제한한다. Protocol 계약이 실제로 요구할 때만 Source Port를 제한한다.

Public IP를 통해 들어오는 Inbound Traffic은 Azure가 Public Destination을 Private 주소로 변환한 뒤 NSG가 평가한다. Outbound에서는 Public 변환 전에 Private Source를 평가한다. Workload Endpoint는 Public IP가 아니라 VM Private IP, Subnet CIDR 또는 ASG로 표현한다.

15. 숫자가 작을수록 먼저 평가되고 첫 일치에서 끝난다

사용자 NSG 규칙 Priority는 100부터 4096까지다. 숫자가 작을수록 먼저 평가된다. 하나의 NSG 안에서 트래픽이 규칙과 일치하면 그 NSG의 평가는 끝난다.

다음 규칙을 보자.

Priority	규칙	Web → App TCP 8443 결과
100	Web에서 App TCP 8443 허용	일치 후 허용, 평가 종료
200	Web에서 App TCP 8443 차단	해당 흐름에서는 평가되지 않음
4000	나머지 `VirtualNetwork` Inbound 차단	해당 흐름에서는 평가되지 않음

앞의 두 Action을 반대로 하면 결과도 바뀐다.

Priority	규칙	결과
100	Web에서 App TCP 8443 차단	즉시 일치하고 차단
200	Web에서 App TCP 8443 허용	평가되지 않음

Priority 100이 Priority 200보다 “더 안전한 규칙”이라는 뜻은 아니다. 더 먼저 평가될 뿐이며 결과는 일치 조건과 Action이 결정한다.

100, 200, 300, 4000처럼 의도적인 간격을 남기면 전체 번호를 다시 정하지 않고 규칙을 추가할 수 있다. Name이나 Portal 표시 순서에 의존하지 말고 숫자 Priority와 Direction을 확인한다.

하나의 NSG에서 같은 Direction의 사용자 규칙 두 개가 같은 Priority를 사용할 수 없다. Infrastructure as Code와 Review Check로 충돌과 광범위한 Shadow Rule을 찾아야 한다.

16. Segmentation을 믿기 전에 여섯 가지 기본 규칙 읽기

Azure는 사용자가 만든 각 NSG 안에 여섯 가지 기본 규칙을 생성한다. 모든 VNet에 보이지 않는 NSG가 자동 연결되는 것은 아니다.

기본 Inbound 규칙

Priority	Name	Source	Destination	Protocol / Port	Action
65000	`AllowVNetInBound`	`VirtualNetwork`	`VirtualNetwork`	Any	Allow
65001	`AllowAzureLoadBalancerInBound`	`AzureLoadBalancer`	Any	Any	Allow
65500	`DenyAllInbound`	Any	Any	Any	Deny

기본 Outbound 규칙

Priority	Name	Source	Destination	Protocol / Port	Action
65000	`AllowVnetOutBound`	`VirtualNetwork`	`VirtualNetwork`	Any	Allow
65001	`AllowInternetOutBound`	Any	`Internet`	Any	Allow
65500	`DenyAllOutBound`	Any	Any	Any	Deny

기본 규칙을 삭제할 수는 없지만 Priority 100~4096의 사용자 규칙이 먼저 평가되므로 실제 결과를 바꿀 수 있다.

세 가지를 정확히 구분한다.

AllowVNetInBound는 최소 권한이 아니다. VirtualNetwork Tag에는 Local Subnet 밖의 Peered·Connected Range가 포함될 수 있다.
AllowInternetOutBound는 인터넷 연결을 만들지 않는다. 유효한 Route와 명시적 또는 과거 방식의 Outbound 경로가 있을 때 필터가 허용한다는 뜻이다. 2026년 3월 31일 이후 공개된 API 버전으로 새 VNet을 만들면 그 VNet에 함께 생성되는 Subnet은 defaultOutboundAccess=false가 기본이다. 기존 VNet은 자동 변경되지 않으며 오래된 API 버전은 이전의 암시적 동작을 유지할 수 있다. 실제 Subnet과 Egress 설계를 확인한다.
AzureLoadBalancer는 플랫폼 Health Probe를 나타낸다. Load Balancer를 통과하는 모든 사용자 트래픽을 의미하지 않으며 Backend Data Traffic은 해당 서비스에서 문서화한 원래 Source Context를 유지한다.

별도의 기본 동작도 있다. Standard Public IP Frontend는 NSG가 명시적으로 허용할 때까지 Inbound가 닫힌 Secure-by-default 방식이다. Frontend가 Standard Load Balancer에 속한다면 Load-balancing Rule과 적용 대상 NSG의 허용이 모두 필요하다. 이를 NSG 안에만 존재하는 여섯 Default Rule과 혼동하지 않는다.

17. 상태 저장 반환 트래픽 이해하기

NSG는 Flow 상태를 유지한다. 새 App-to-Database TCP 1433 연결이 허용되면 그 Established Flow의 응답 Packet을 위해 반대 방향 Database → App Allow Rule을 똑같이 만들 필요가 없다.

새 Flow 시작
App 10.40.20.4:52341 → Data 10.40.30.4:1433
NSG 규칙 평가 후 허용

Stateful 응답
Data 10.40.30.4:1433 → App 10.40.20.4:52341
Established Flow의 Return Traffic 허용

이 동작이 Database Tier에서 App Tier로 완전히 별개의 새 연결을 시작하도록 허용하는 것은 아니다. 반대편이 시작한 새 Flow는 해당 Direction의 규칙으로 다시 평가된다.

규칙 변경도 새 연결에 적용된다. SSH Allow Rule을 제거해도 이미 열려 있던 SSH Flow는 즉시 종료되지 않을 수 있다. Session이 닫히거나 상태가 만료될 때까지 유지될 수 있다. 기존 연결을 재사용하는 테스트는 새 Deny가 동작하지 않는 것처럼 보이게 한다.

규칙 변경 후에는 다음 순서로 확인한다.

변경 시각과 Rule Version을 보관한다.
기존 Test Session을 닫거나 새 연결과 명확히 구분한다.
실제로 새로운 연결을 시작한다.
필요한 Allow와 금지된 Deny를 모두 테스트한다.
일치한 규칙과 로그를 확인한다.

Stateful은 “자동으로 안전하다”는 뜻이 아니다. 허용된 통신의 Return Packet 상태를 추적한다는 뜻이다.

18. Subnet NSG와 NIC NSG 평가

NSG는 Subnet, 지원되는 VM NIC 또는 두 범위 모두에 연결할 수 있다.

Inbound Traffic의 문서상 처리 순서는 다음과 같다.

Source → Subnet NSG → NIC NSG → Guest OS / Application

Outbound Traffic은 반대 순서다.

Guest OS / Application → NIC NSG → Subnet NSG → Next Hop

두 수준이 모두 적용되면 적용되는 모든 NSG가 새 Flow를 허용해야 한다. Subnet Allow가 NIC Deny를 무시할 수 없고 NIC Allow도 Subnet Deny를 무시할 수 없다. 먼저 차단한 수준에서 Packet이 멈춘다.

같은 Subnet의 VM 사이 통신에도 이 원칙이 적용된다. Intra-subnet Traffic이 NSG 평가를 우회하는 것은 아니다.

하나의 수준으로 요구사항을 표현할 수 있다면 Microsoft도 Subnet과 NIC에 동시에 NSG를 적용하지 않도록 권장한다. 두 수준은 충돌 지점을 늘리고 장애 분석을 어렵게 한다. 입문자에게 유용한 시작 모델은 다음과 같다.

Tier 전체에 공통인 정책 → Subnet NSG
특정 NIC 예외 → 문서화된 요구와 담당자가 있을 때만 사용

과거 Flow Log Record가 보이는 순서만으로 처리 순서를 추정하지 않는다. 합산된 Effective Rule과 두 Configuration Scope를 모두 확인한다.

19. 의도를 숨기지 않고 Service Tag, ASG와 고급 규칙 사용하기

Service Tag는 관리되는 IP Prefix 집합이다

Storage, AzureLoadBalancer, VirtualNetwork 같은 Service Tag는 Microsoft가 관리하는 IP Prefix 그룹이다. Microsoft가 주소 변경을 반영하므로 팀이 계속 바뀌는 목록을 직접 입력하지 않아도 된다.

Service Tag는 다음을 의미하지 않는다.

Microsoft Entra Identity
Tenant 또는 Subscription 경계
특정 Service Resource Instance 하나
트래픽 암호화나 인증의 증거
목적지 Service Firewall, Identity와 Authorization의 대체

서비스가 지원하고 요구사항이 특정 Region에 한정되면 Regional Tag를 사용한다. 현재 범위를 이해하지 않은 광범위한 AzureCloud 또는 VirtualNetwork 권한은 피한다. Service Tag는 IP 유지 관리를 단순화할 뿐 광범위한 요구사항을 안전하게 만들지는 않는다.

Application Security Group은 NIC 역할을 표현한다

ASG는 VM NIC를 asg-web, asg-app, asg-data 같은 Workload Role로 묶는다. NSG Rule은 다음처럼 표현할 수 있다.

asg-web → asg-app TCP 8443 허용
asg-app → asg-data TCP 1433 허용

NIC Membership이 바뀌면 규칙이 Private IP 변경과 Scale Operation을 따라갈 수 있다. ASG는 사람 사용자, 모든 유형의 Azure Resource 또는 여러 VNet의 NIC를 임의로 묶는 기능이 아니다. ASG Member와 ASG-to-ASG Rule은 Same-VNet 제약을 지켜야 한다.

Augmented Rule은 규칙 수를 줄인다

Augmented NSG Rule은 여러 명시적 IP, CIDR Range와 Port Range를 하나의 규칙에 묶을 수 있다. 항목이 같은 목적, 담당자, Action과 Lifecycle을 가질 때 사용한다. 규칙 수를 줄이려고 서로 관계없는 예외를 읽기 힘든 한 줄로 합치지 않는다. 여러 Service Tag를 한 Field에 임의로 섞을 수 있다고 가정해서도 안 된다.

중앙 Admin Rule이 Local NSG보다 먼저 평가될 수 있다

Azure Virtual Network Manager로 관리되는 기업 환경에서는 Security Admin Rule이 Local NSG보다 먼저 적용될 수 있다. Admin Deny는 트래픽을 중단하고 Always Allow는 NSG 평가를 우회할 수 있으며 Allow는 NSG 평가가 이어지게 한다. Local NSG가 올바른데 결과가 다르면 중앙 Admin Rule도 증적 검토에 포함한다.

Azure Platform Endpoint는 조심해서 통제한다

Azure는 168.63.129.16과 169.254.169.254 같은 Host Virtual Address를 서로 다른 플랫폼 기능에 사용한다. 전자는 Azure-provided DNS, Health Probe, DHCP와 VM Platform Communication에 참여하며, 후자는 Route되지 않는 Instance Metadata Service Endpoint다. 인터넷 위협 목록에 있다는 식의 이유로 Azure Platform Dependency를 이해하지 않고 Raw IP Deny를 추가하지 않는다. AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM Tag를 차단하면 각각 Azure 제공 DNS, IMDS/Managed Identity, Windows Licensing 종속성이 중단될 수 있다. 168.63.129.16의 TCP 80과 32526을 사용하는 VM Agent WireServer 트래픽은 NSG 적용 대상이 아니므로 Guest Firewall에서 계속 허용해야 한다.

20. 3계층 의도를 학습용 규칙으로 옮기기

다음 Inbound Rule은 정책을 이해하기 위한 예시다. 앞서 정의한 CIDR와 Subnet-level NSG를 사용하며 Management와 Platform Dependency는 별도 흐름으로 문서화한다고 가정한다.

NSG	Priority	Source	Source Port	Destination	Destination Port	Protocol	Action
`nsg-web`	100	`10.40.0.0/24`	`*`	`10.40.10.0/24`	443	TCP	Allow
`nsg-web`	4000	`VirtualNetwork`	`*`	`10.40.10.0/24`	`*`	Any	Deny
`nsg-app`	100	`10.40.10.0/24`	`*`	`10.40.20.0/24`	8443	TCP	Allow
`nsg-app`	4000	`VirtualNetwork`	`*`	`10.40.20.0/24`	`*`	Any	Deny
`nsg-data`	100	`10.40.20.0/24`	`*`	`10.40.30.0/24`	1433	TCP	Allow
`nsg-data`	4000	`VirtualNetwork`	`*`	`10.40.30.0/24`	`*`	Any	Deny

필수 Allow가 나머지 Connected-network Deny보다 먼저 온다. VirtualNetwork 밖의 Source가 다른 사용자 Allow와 일치하지 않으면 최종적으로 Priority 65500의 DenyAllInbound에 도달한다.

ASG 방식은 고정 Workload CIDR를 역할로 바꿀 수 있다.

asg-web → asg-app TCP 8443 Allow
asg-app → asg-data TCP 1433 Allow

CIDR 표는 학습하기 쉽고 ASG 방식은 확장되는 VM 역할을 더 잘 표현할 수 있다. 지원 리소스와 담당 체계에 따라 선택한다.

이 표는 운영 배포 Template이 아니다. 실제 설계에서는 Priority 4000 Deny 앞에 승인된 관리, Health Probe, Monitoring, Backup, Identity와 기타 문서화된 Inbound Dependency Rule을 최소 범위로 추가해야 한다. Outbound Rule과 명시적 Egress Policy도 별도 Flow Inventory가 필요하다. 종속성 테스트 없이 광범위한 Deny를 추가하면 장애가 생기고, AllowVNetInBound를 이해하지 않고 Deny를 빼면 의도하지 않은 Lateral Path가 남을 수 있다.

21. NSG처럼 패킷 판정해 보기

학습용 규칙으로 First-match 평가를 연습한다.

사례 A: Edge → Web TCP 443

Source 10.40.0.4, Destination 10.40.10.4, TCP 443
→ nsg-web Priority 100 일치
→ Allow, nsg-web 평가 종료

사례 B: Edge → Web TCP 80

Priority 100은 Destination Port가 일치하지 않음
→ Priority 4000의 나머지 VirtualNetwork Inbound와 일치
→ Deny

사례 C: Web → App TCP 8443

Source 10.40.10.4, Destination 10.40.20.4, TCP 8443
→ nsg-app Priority 100 일치
→ Allow

사례 D: Web → Data TCP 1433

Source가 허용된 App Subnet이 아니라 Web
→ nsg-data Priority 100 불일치
→ Priority 4000 VirtualNetwork Deny 일치
→ Deny

가장 중요한 Shortcut Test다. 적용되는 사용자 Deny가 없다면 Same-VNet Flow가 기본 AllowVNetInBound까지 도달할 수 있다.

사례 E: App → Data TCP 1433

nsg-data Priority 100 일치
→ Allow

사례 F: App → Data TCP 3306

Priority 100은 Destination Port가 일치하지 않음
→ Priority 4000 일치
→ Deny

사례 G: 허용된 App Request에 대한 Data 응답

Response는 Established App → Data TCP 1433 Flow에 속함
→ Stateful Return Traffic 허용
→ 반대 방향의 새 Flow Rule은 필요하지 않음

사례 H: Allow Rule을 방금 제거한 경우

기존 연결은 계속될 수 있음
새 연결은 변경된 규칙으로 평가
→ 기존 Session을 닫거나 구분한 뒤 다시 Test

모든 사례에서 NIC NSG 또는 중앙 Admin Rule이 적용되는지도 물어야 한다. 눈에 가장 가까운 Subnet NSG 하나만 평가해서는 충분하지 않다.

22. 허용 경로와 차단 경로를 모두 증명하기

증적을 네 계층으로 나눈다.

1계층: 구성 증적

VNet Address Space와 Subnet Allocation을 Export한다.
실제 NSG-to-Subnet, NSG-to-NIC Association을 확인한다.
관련 VM NIC마다 Effective Security Rules를 확인한다. Subnet, NIC와 적용되는 Central Admin Rule이 합산되어 보인다.
Effective Routes와 Network Watcher Next Hop으로 선택된 경로를 확인한다.

2계층: 규칙 모의 판정

Network Watcher IP Flow Verify는 TCP 또는 UDP Direction, Local·Remote Address와 Port를 적용되는 NSG·Admin Rule에 대입해 평가한다. Allow/Deny와 일치한 Rule을 반환한다. ICMP 또는 IP Flow Verify가 지원하지 않는 Scale Set 같은 시나리오는 NSG Diagnostics를 사용한다.

Allowed 결과는 End-to-end Application Test가 아니다. Route, Guest Firewall, Listener, TLS, ID 또는 Application Health를 증명하지 않는다.

3계층: 실제 허용·차단 연결

테스트	예상 결과	증적
Edge → Web TCP 443	성공	Application Request와 일치 경로 증적
Edge → Web TCP 80	실패	새 연결 결과와 일치한 Deny Rule
Web → App TCP 8443	성공	`curl`, `Test-NetConnection` 또는 승인 Client Test
Web → App TCP 22	실패	새 연결 결과와 Rule 판정
Web → Data TCP 1433	실패	Shortcut 차단 증적
App → Data TCP 1433	성공	Application/Database Handshake 증적
App → Data TCP 3306	실패	Wrong-port 차단 증적
Internet → App/Data	실패	노출 자산 목록, Public Edge 확인, 연결 결과

실제 Source NIC에서 테스트한다. Azure 밖의 Laptop Test는 Web-to-App Segmentation을 증명하지 못한다. 규칙 변경 후에는 새 연결을 사용한다.

4계층: 운영 증적

신규 설계에서는 Workload가 지원된다면 Virtual Network Flow Logs를 사용한다. Five-tuple, Direction, State, Rule, Byte와 Packet 같은 Layer 4 Flow Metadata를 Azure Storage에 기록한다. Packet Payload를 수집하지 않으며 모든 Azure Service를 지원하는 것도 아니다.

NSG Flow Log는 2025년 6월 30일 이후 새로 만들 수 없으며 2027년 9월 30일 종료될 예정이다. Storage에 이미 저장된 Record는 Storage Retention을 따르지만 2026년 신규 모니터링 설계는 Virtual Network Flow Log를 사용해야 한다. 두 유형이 같은 Workload를 수집할 때 Duplicate Log와 추가 비용이 생기지 않도록 Microsoft가 안내하는 Migration 순서를 따른다.

23. Portal 기억이 아니라 정책으로 변경 운영하기

모든 규칙에는 다음 항목이 있어야 한다.

업무 또는 기술적 목적
출발지와 목적지 담당자
Protocol과 Port 통신 계약
Rule Priority 근거
생성일과 재검토일
Ticket 또는 의사결정 참조
허용·차단 Test
Monitoring Destination
임시 예외의 만료일
Rollback 절차

가능하다면 Infrastructure as Code와 Policy Check를 사용한다. Portal Screenshot은 Reviewer에게 도움이 될 수 있지만 현재 Association, Effective Rule 또는 Drift 이후의 동작을 증명하지 못한다.

주소와 Subnet 체크리스트

CIDR를 Azure, On-premises, DR, 다른 Cloud와 외부 업체 Network와 비교했다.
모든 Subnet이 VNet Address Space 안에 있고 다른 Subnet과 겹치지 않는다.
Azure가 예약하는 IPv4 주소 5개를 용량 계산에 포함했다.
Scale-out, Upgrade, Failover, Private Endpoint와 Platform Service의 여유가 있다.
Subnet이 임의의 이름이 아니라 역할, 신뢰, Routing, 확장, Lifecycle 또는 서비스 요구를 나타낸다.
필요한 전용 Subnet 이름과 최신 최소 크기를 다시 확인했다.
미할당 범위와 담당자를 기록했다.

NSG 체크리스트

검증과 운영 체크리스트

24. 스스로 확인할 질문과 1분 기억 카드

질문

/24에서 사용할 수 있는 Azure IPv4 주소가 254개가 아니라 251개인 이유는 무엇인가?
VNet CIDR를 고르기 전에 현재와 미래 연결 Network를 조사해야 하는 이유는 무엇인가?
Web과 Data를 서로 다른 Subnet으로 나누어도 Web-to-Data가 자동 차단되지 않는 이유는 무엇인가?
Address Plan, Route, NSG, Application Listener는 각각 어떤 질문에 답하는가?
NSG Flow를 판정하는 Five-tuple은 무엇인가?
동일 Flow에 Priority 100 Deny와 200 Allow가 모두 일치하면 무엇이 적용되는가?
Client-to-server Rule의 NSG Source Port를 보통 *로 두는 이유는 무엇인가?
Stateful NSG에서 허용된 응답을 위해 Mirror Rule이 필요하지 않은 이유는 무엇인가?
SSH Allow Rule을 삭제해도 기존 Session이 계속될 수 있는 이유는 무엇인가?
Inbound와 Outbound에서 Subnet·NIC NSG 평가 순서는 어떻게 다른가?
Service Tag와 ASG는 어떻게 다른가?
VirtualNetwork가 현재 VNet Subnet보다 넓을 수 있는 이유는 무엇인가?
IP Flow Verify가 Allowed인데 Application이 실패하면 무엇을 더 확인해야 하는가?
Allow Test와 Deny Test가 모두 필요한 이유는 무엇인가?
2026년 신규 설계는 어떤 Flow Log를 사용해야 하는가?

기억 카드

공간 계획 → 역할 분리 → 모든 Flow에 이름 부여
→ 필요한 경로만 허용 → 허용과 차단을 모두 증명

Address Plan = 주소가 존재할 수 있는 위치
Subnet = 배치와 정책 적용 범위, 자동 보안 장벽이 아님
Route = Packet의 다음 Hop
NSG = L3/L4 Flow 통과 여부

낮은 숫자가 먼저 평가된다.
첫 일치에서 평가가 끝난다.
Return Traffic은 Stateful이다.
Rule 변경 후 새로 연결해 테스트한다.

NSG Allowed ≠ Application 정상
Subnet 분리 ≠ Traffic 차단

마지막으로 기억할 문장은 다음과 같다.

안전한 VNet 설계는 중복 없는 주소에서 시작해 이름 붙인 애플리케이션 흐름을 좁은 규칙으로 바꾸고, 연결 가능한 것과 연결할 수 없는 것을 모두 증명한다.

다음 Module 1 상세 노트에서는 Azure Firewall Basic, Standard, Premium을 비교하고, 이후 글에서 Routing, DNS, Rule, Logging과 검증을 더 깊게 다룰 예정이다. 완성된 영문·국문 글 한 쌍이 준비되기 전까지 계획 상태로 유지하며 빈 경로를 연결하지 않는다.