Public IP 없이 Azure VM을 안전하게 설계하기: 관리·인바운드·아웃바운드 경로 분리

Azure Virtual Machine에서 Public IP 주소를 제거하는 것은 직접 도달 가능한 공격 표면을 줄이는 가장 분명한 방법 중 하나다. 인터넷에서 VM으로 바로 들어오는 가장 단순한 경로가 사라지고, 광범위한 스캔의 효율이 낮아지며, 관리자는 통제된 접속 경로를 사용하게 된다. 매우 중요한 설계 결정이지만 이것만으로 보안 아키텍처가 완성되지는 않는다.

사설 VM에도 서로 목적이 다른 네 가지 연결이 필요할 수 있다.

관리자가 게스트 운영체제에 접속해야 한다.
사용자가 VM에서 실행되는 애플리케이션에 접속해야 할 수 있다.
VM이 업데이트, 패키지 저장소, 외부 API 또는 정품 인증을 위해 외부로 통신해야 할 수 있다.
VM이 Storage나 Key Vault 같은 Azure 서비스에 사설로 접속해야 할 수 있다.

이 흐름들을 모두 “네트워크 접속”이라는 하나의 모호한 요구사항으로 취급하면 필요 이상으로 공개하거나 필수 운영 경로를 끊기 쉽다. 더 안전한 방법은 각 경로를 따로 설계하고, 권한을 부여하고, 라우팅하고, 관찰하고, 테스트하는 것이다.

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 나눈 학습 계획의 네 번째 상세 노트다. Module 1 복습 글은 전체 보안 지도를 제공하고, 바로 앞의 DDoS 보호 계층 선택 글은 Public 엔드포인트를 보호하는 방법을 다뤘다. 이번에는 그보다 앞선 아키텍처 질문을 다룬다. VM 자체가 정말 Public 엔드포인트여야 하는가?

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

이 글에서 다루지 않는 범위

이번 글은 아키텍처와 검증 방법을 설명하며 화면을 따라 하는 배포 절차는 제공하지 않는다. Bastion, VPN, ExpressRoute, Azure Firewall, Private Endpoint의 전체 배포 명령, WAF 규칙 튜닝, 운영체제 보안 강화 기준, Infrastructure as Code 모듈 또는 워크로드별 비용 계산은 범위 밖이다. 이런 결정에는 실제 지역, 네트워크 구성, ID 모델, 가용성 목표와 변경 절차가 필요하다.

1. 목표 상태를 정확하게 표현하기

불충분한 목표는 다음과 같다.

VM에 Public IP가 없다.

운영 가능한 목표는 다음과 같다.

VM NIC에는 Public IP가 없다.
게스트 관리는 승인된 ID 기반 경로를 사용한다.
필요한 경우 애플리케이션 인바운드는 승인된 Frontend만 사용한다.
인터넷 아웃바운드는 명시적이고 관찰 가능한 외부 통신(Egress) 경로를 사용한다.
지원되는 Azure 서비스는 필요성을 검토한 뒤 Private Endpoint로 연결한다.
허용·차단 경로마다 담당자, 증적, 테스트가 있다.

이 차이가 중요한 이유는 “VM에 Public IP가 없다”가 곧 “워크로드가 사설이다”를 뜻하지 않기 때문이다. Public Application Gateway, Load Balancer, Reverse Proxy 또는 Azure Firewall DNAT(Destination Network Address Translation) 규칙은 여전히 인터넷 트래픽을 VM의 Private IP로 전달할 수 있다. Public 웹사이트라면 오히려 이것이 올바른 아키텍처일 수 있다. 공개 경계(Edge)는 인터넷에 노출되지만 백엔드 VM은 사설 주소만 사용하는 구조다. 보안 검토에서는 전체 워크로드가 인터넷에서 사라졌다고 말하지 말고 실제 공개 경계가 무엇인지 밝혀야 한다.

이번 글의 핵심 문장은 다음과 같다.

Public IP가 없는 VM은 공격 표면이 더 작은 VM이지, 보안 설계가 완성된 VM은 아니다.

2. 제품을 선택하기 전에 기본 용어 익히기

네트워크 인터페이스(Network Interface, NIC)와 IP 구성

Azure VM은 Network Interface(NIC)를 통해 Virtual Network에 연결된다. NIC의 IP Configuration에는 Private IP가 있으며 선택적으로 Public IP 리소스를 참조할 수 있다. 이 Public IP 연결을 제거하면 인터넷에서 NIC를 직접 주소로 지정할 수 없게 된다. Private IP, NIC 또는 VM이 사용할 수 있는 모든 경로가 사라지는 것은 아니다.

가상 네트워크(VNet)와 서브넷

Virtual Network(VNet)는 사설 주소 공간이다. Subnet은 그 안에서 NIC나 플랫폼 리소스를 배치하는 주소 범위다. Subnet은 유용한 정책 경계이기도 하다. Route Table, Network Security Group(NSG), NAT Gateway와 일부 서비스 위임은 Subnet 범위로 동작한다.

경로(Route)

Route는 **패킷을 다음에 어디로 보낼 것인가?**에 답한다. Azure는 System Route, User-Defined Route(UDR), 연결된 네트워크에서 전파된 Route를 조합한다. Route는 사람의 ID를 확인하거나 게스트 OS에 로그인시키거나 애플리케이션의 안전성을 판단하지 않는다.

Network Security Group

NSG는 **이 네트워크 흐름을 허용할 것인가, 차단할 것인가?**에 답한다. 우선순위에 따라 평가되는 Stateful 인바운드·아웃바운드 규칙으로 구성된다. NSG는 도달 경로를 만들거나 Private 주소를 Public 주소로 변환하거나 DNS 이름을 해석하지 않는다.

DNS

DNS는 **이 이름을 어떤 주소로 해석할 것인가?**에 답한다. Private Endpoint에서는 올바른 Private DNS 해석이 애플리케이션으로 하여금 사설 주소를 선택하게 하는 핵심 요소인 경우가 많다. 그러나 DNS가 연결 자체를 승인하지는 않는다. Route, 네트워크 통제, 서비스 정책, ID와 애플리케이션 권한도 모두 통과해야 한다.

다음 세 문장을 기억하면 많은 장애 분석 오류를 줄일 수 있다.

DNS는 주소를 선택한다.
Route는 Next Hop을 선택한다.
NSG는 흐름을 허용하거나 차단한다.

3. Control Plane과 네 가지 데이터 경로 분리하기

Azure 리소스 관리와 게스트 운영체제 접속은 서로 같은 경로가 아니다. 사용자가 Azure Resource Manager를 통해 VM을 시작하거나 중지할 수 있어도 Windows나 Linux에는 로그인하지 못할 수 있다. 반대로 외부에 노출된 프로토콜을 통해 Local OS 계정으로 로그인할 수 있는 사람이 Azure 구독 권한은 전혀 없을 수도 있다.

설계 검토에서는 다음 지도를 사용한다.

Azure 리소스 관리
관리자 → Microsoft Entra ID / Azure RBAC → Azure Resource Manager → VM 리소스

게스트 관리
관리자 → Bastion 또는 사설 연결 네트워크 → VM Private IP → RDP / SSH

애플리케이션 인바운드
인터넷 사용자 → 승인된 Public Edge / WAF → VM Private IP → 애플리케이션 포트

인터넷 아웃바운드
VM Private IP → NAT Gateway 또는 Azure Firewall → 인터넷 종속성

Azure 서비스 접속
VM Private IP → Private Endpoint + Private DNS → 지원되는 Azure 서비스

각 화살표에 다섯 가지 질문을 적용한다.

목적: 어떤 업무 또는 운영 작업 때문에 이 흐름이 필요한가?
ID: 누가 또는 어떤 워크로드가 연결을 시작할 수 있는가?
네트워크 경로: 어떤 출발지, 목적지, 포트, 경로와 통제 지점을 지나는가?
증적: 어떤 로그, 실제 적용 구성, 테스트가 설계대로 동작함을 증명하는가?
장애 동작: 경로가 차단되거나 중단되거나 잘못 구성되면 무엇이 실패하는가?

4. NIC를 변경하기 전에 통신 흐름 목록 작성하기

Public IP를 제거한 뒤 장애 신고를 통해 종속성을 발견해서는 안 된다. 먼저 작은 흐름 자산 목록을 만든다.

흐름	출발지	목적지	포트·프로토콜	승인 경로	담당자	실패 영향
Windows 관리	지정된 운영 그룹	사설 VM	TCP 3389	Azure Bastion	플랫폼 팀	사고 대응 지연
Linux 관리	지정된 운영 그룹	사설 VM	TCP 22	VPN과 허브 방화벽	플랫폼 팀	사고 대응 지연
공개 웹 요청	인터넷 사용자	웹 애플리케이션	HTTPS 443	WAF 프런트엔드에서 사설 백엔드로	앱 팀	고객 서비스 중단
OS 업데이트	사설 VM	구성된 Windows Update, WSUS 또는 Linux 저장소	저장소별로 다르며 일반적으로 TCP 80/443	승인된 방화벽 또는 사설 저장소 경로	플랫폼 팀	보안 패치 지연
패키지 다운로드	사설 VM	승인된 저장소	HTTPS 443	NAT Gateway 또는 방화벽	앱 팀	배포 실패
비밀 조회	워크로드 ID	Key Vault	HTTPS 443	Private Endpoint	보안 팀	애플리케이션 시작 실패
모니터링	에이전트 또는 게스트 OS	모니터링 엔드포인트	HTTPS 443	명시적 외부 통신 경로	관측성 팀	관측 데이터 누락

“인터넷 연결 필요”는 사용할 수 있는 행이 아니다. 실제 종속성, 방향, 담당자, 실패 결과를 기록한다. 목적지 목록을 고정할 수 없다면 승인된 FQDN을 사용하는 Azure Firewall Application Rule 같은 방식으로 어떻게 통제할지, 변경 사항은 누가 검토할지 기록한다.

5. VM Public IP를 제거하면 달라지는 것

VM NIC에서 Public IP를 제거하면 다음과 같은 실질적인 이점이 생긴다.

해당 NIC에 직접 매핑된 Public 주소가 사라진다.
인터넷 Scanner가 그 NIC Public 주소로 RDP, SSH 또는 애플리케이션 연결을 직접 시작할 수 없다.
운영자는 Bastion, VPN, ExpressRoute 또는 다른 통제 네트워크 같은 별도 경로를 사용해야 한다.
Public 진입점이 필요하다면 그 역할에 맞게 설계된 Edge에 집중할 수 있다.

하지만 다음 작업이 자동으로 이루어지는 것은 아니다.

VM으로 전달하는 애플리케이션 Frontend 제거
인터넷 아웃바운드 차단
안전한 관리 접속 경로 생성
너무 넓은 NSG 규칙 수정
게스트 OS 패치, 강화 또는 모니터링
ID 및 최소 권한 통제 대체
Azure 서비스 트래픽의 사설화
DNS와 Route가 의도한 경로를 따르는지 증명

구성 변경과 적용 완료도 구분해야 한다. 명시적 아웃바운드 방식을 추가하더라도 Subnet이 Nonprivate 상태이면 이미 할당된 Default Outbound IP가 자동 제거되지는 않는다. 완전히 제거하려면 Subnet에 defaultOutboundAccess=false를 설정하고 해당 VM을 중지한 뒤 할당 해제해야 한다. 속성 하나를 바꾸는 즉시 과거 동작이 모두 사라진다고 가정하지 말고 실제 관찰 상태를 검증한다.

6. 현재 Azure 아웃바운드 동작: 오래된 한 문장으로 외우지 않기

과거에는 명시적인 아웃바운드 방식을 구성하지 않은 VM도 Microsoft 소유 Public 주소를 통해 Default Outbound Access를 받을 수 있었다. 이 방식은 암시적이고 주소가 바뀔 수 있으며, 안정된 주소나 명시적인 통제가 필요한 운영 환경에는 적합하지 않다.

2026년 3월 31일 이후 릴리스된 API Version으로 새 VNet의 일부인 Subnet을 만들면 Azure는 defaultOutboundAccess=false를 기본 설정한다. 현재 이 동작을 구현한 Version은 Microsoft.Network/virtualNetworks@2025-07-01이다. 기존 VNet은 자동 전환되지 않으며, 오래된 API Version은 속성을 null로 남겨 Default Outbound Access를 암시적으로 허용할 수 있다. 따라서 다음 두 문장은 모두 안전하지 않다.

“새 Azure VM에는 항상 아웃바운드 인터넷이 자동 제공된다.”
“2025년 9월 이후 모든 새 Azure VM에서 아웃바운드 인터넷이 사라졌다.”

실제 Subnet의 defaultOutboundAccess 상태, Effective Route, NIC 구성과 명시적 아웃바운드 리소스를 확인해야 한다. Private Subnet은 VM에 Default Outbound Access를 부여하지 않는다는 뜻이다. NAT Gateway, Azure Firewall, 다른 Network Virtual Appliance 또는 지원되는 명시적 Egress 방식을 추가할 수 없다는 뜻은 아니다.

과거 동작을 모두 외우는 것보다 설계 원칙 하나가 더 중요하다.

운영 환경의 아웃바운드 연결은 명시적이고 의도적이며 관찰 가능해야 한다.

유효한 Egress 경로가 없다면 Windows 정품 인증과 업데이트, Linux 패키지 저장소, 모니터링 Agent, 인증서 확인, 외부 API 또는 자체 배포 절차가 실패할 수 있다. “Private”가 “다음 패치 작업 때 종속성을 발견한다”는 뜻이 되어서는 안 된다.

7. 애플리케이션 인바운드 경로 따로 선택하기

먼저 워크로드가 인터넷 사용자에게 서비스를 제공하는지 묻는다.

Public 애플리케이션이 없는 경우

관리 서버, Batch Worker, Internal API 또는 Domain Service라면 Public 애플리케이션 인바운드가 필요하지 않을 수 있다. VM을 Private Subnet에 두고 승인된 VNet, Peered VNet, VPN 또는 ExpressRoute 출발지에만 서비스를 공개한다. 실제 출발지와 포트를 NSG와 Firewall Policy로 제한한다.

Public 웹 애플리케이션인 경우

Public 웹사이트에는 여전히 Public Edge가 필요하다. Public 주소는 WAF를 적용한 Application Gateway 또는 요구사항에 맞는 다른 Load Balancing·보호 서비스에 두고, 필요한 Backend 포트만 VM의 Private IP로 전달한다.

인터넷
  ↓ HTTPS 443
TLS/WAF 정책이 적용된 Public Edge
  ↓ 승인된 Backend 흐름만
Private VM 애플리케이션 포트

Backend NSG는 Internet → Any가 아니라 필요한 Frontend 출발지와 포트만 허용해야 한다. 관리 접속이 애플리케이션 경로를 재사용해서도 안 된다. DDoS Protection, WAF Policy, 인증서, Health Probe, 지원되는 경우의 Backend 인증, 애플리케이션 로그는 각각 별도 검토 항목이다.

직원이나 파트너에게만 제공하는 Private 애플리케이션인 경우

요구사항에 따라 사설 연결, ID 기반 애플리케이션 접속 방식 또는 승인된 Private Ingress 서비스를 사용한다. 원격 사용자 한 명이 접속해야 한다는 이유로 VM Public IP를 추가하지 않는다. 사용자 접속 문제를 상시 노출 네트워크 Endpoint 문제로 바꾸는 셈이 된다.

8. 게스트 관리 경로 선택하기

일반적인 선택지는 서로 다른 연결 문제를 해결한다.

선택지	운영자가 VM에 도달하는 방법	적합한 경우	반드시 알아야 할 경계
Azure Bastion	브라우저 또는 네이티브 클라이언트에서 관리형 Bastion을 거쳐 VM Private IP로 연결	VM Public IP 없이 Azure 내부 VM 관리	대상 NSG와 게스트 OS 인증은 여전히 필요
Point-to-Site VPN	운영자 장치가 승인된 사설 네트워크 경로에 참여	개별 관리자와 원격 직원	장치, ID, 경로, DNS, VPN 운영 필요
Site-to-Site VPN	온프레미스 네트워크와 Azure 연결	기존 통제가 있는 사무실·데이터센터	이중화, 라우팅, 출발지 범위 필요
ExpressRoute	조직 네트워크와 Azure를 사설 회선으로 연결	기업 사설 연결과 예측 가능한 네트워크 통합	그 자체로 인터넷 암호화를 뜻하지 않으며 이중화 설계 필요
Jump Host	강화된 중간 서버를 먼저 거쳐 연결	레거시 또는 특수 운영 절차	패치, 강화, 자격 증명, 가용성, 로그를 직접 책임짐
Run Command / Serial Console	Azure 제어·플랫폼 경로로 명령을 실행하거나 긴급 콘솔 접속	진단과 긴급 복구(Break-glass)	일상적인 대화형 관리 경로의 대체품이 아님

주 경로 하나와 테스트를 마친 복구 경로 하나를 선택한다. 담당자가 없는 여러 가능성을 나열하는 것은 복원력이 아니다.

9. Azure Bastion이 하는 일과 하지 않는 일

Azure Bastion은 VM의 Private IP로 RDP와 SSH 연결을 제공하는 관리형 플랫폼 서비스다. 사용자는 일반적으로 443번 포트의 TLS를 통해 Bastion에 연결하고, Bastion이 대상 VM으로 연결한다. 포털 기반 접속에서는 대상 VM에 Public IP, Bastion 에이전트 또는 별도 클라이언트가 필요하지 않다.

그렇다고 대상 VM에서 RDP나 SSH를 허용하지 않아도 된다는 뜻은 아니다. 대상 NSG는 올바른 Bastion 출발지, 일반적으로 전용 AzureBastionSubnet에서 오는 관리 포트를 허용하고 승인되지 않은 출발지는 차단해야 한다. 게스트 OS 방화벽과 RDP/SSH 서비스도 연결을 허용해야 한다.

전용 Basic, Standard, Premium Bastion 배포는 /26 이상의 AzureBastionSubnet을 사용한다. 일반 배포는 대상 VM에 Public IP가 없어도 Bastion 자체에는 Standard Public IP가 있다. Bastion 자체에도 Public IP가 없어야 하는 조직을 위해 Premium은 Private-only 배포를 지원하지만 생성 시 선택해야 하며 운영자가 VPN이나 ExpressRoute 같은 기존 사설 경로를 통해 접속해야 한다. 종단 간 사설 연결에는 네이티브 클라이언트를 사용한다. 일반 Bastion 배포를 Private-only로 그 자리에서 단순 전환할 수는 없다.

Bastion은 관리 전송 경로다. 다음 기능은 대신하지 않는다.

Azure 리소스 권한 부여
Windows 또는 Linux 안에서의 사용자 인증
VM의 인터넷 아웃바운드 경로
게스트 패치와 보안 강화
애플리케이션 Load Balancer 또는 WAF
지나치게 넓은 대상 NSG의 정당화

마지막으로 Bastion 비용은 RDP 또는 SSH 탭을 열어 둔 시간에만 발생하는 것이 아니라 배포가 존재하는 동안 발생한다. 서비스 계층, 확장 규모, Private-only 요구, 네이티브 클라이언트 요구, 로그와 운영 비용까지 설계에 포함한다.

10. Azure 권한과 Guest 로그인을 두 개의 잠금으로 보기

관리자는 일반적으로 두 개의 권한 경계를 통과해야 한다.

잠금 1: 이 ID가 Azure VM 리소스를 운영할 수 있는가?
잠금 2: 이 ID가 게스트 운영체제에 로그인할 수 있는가?

Owner나 Contributor 같은 Azure RBAC Role은 리소스에 대한 관리 작업을 승인한다. 해당 사용자를 모든 VM의 Windows 또는 Linux 관리자 계정으로 자동 등록하지 않는다. Azure VM의 Microsoft Entra 로그인은 필요한 Guest Extension 및 구성과 함께 Virtual Machine Administrator Login 또는 Virtual Machine User Login 같은 전용 Role을 사용한다. Local 또는 Domain Account는 별도의 수명 주기와 정책을 가진다.

명명된 개인 ID, Multi-Factor Authentication, 지원되는 범위의 Conditional Access, 최소 권한 Azure Role, 필요한 경우 분리된 관리자 계정과 Privileged Identity Management를 통한 시간 제한 승격을 우선한다. 공유 Local Administrator Credential은 피한다. Azure 권한 증적과 Guest 권한 증적을 모두 기록한다.

11. Bastion과 Just-in-Time Access를 서로 다른 질문으로 보기

Azure Bastion은 다음 질문에 답한다.

관리자는 어떤 통제된 전송 경로로 Private VM에 도달할 것인가?

Microsoft Defender for Cloud의 Just-in-Time(JIT) VM Access는 다음 질문에 답한다.

어떤 출발지, 포트, 제한 시간에 한해 관리 규칙을 열 것인가?

JIT는 Defender for Servers Plan 2에서 사용할 수 있다. NSG 규칙 또는 지원되는 동일 VNet Azure Firewall Classic Rule 구성을 일시적으로 변경해 요청된 관리 연결을 허용한다. Azure Firewall Manager 또는 Azure Firewall Policy로 관리되는 Azure Firewall은 JIT 통합을 지원하지 않는다. JIT는 누락된 Route를 만들거나 VPN을 생성하거나 Bastion을 배포하거나 Guest 내부 사용자를 인증하지 않는다.

통제된 경로와 시간 제한 대상 접속이 모두 필요한 운영 모델이라면 Bastion과 JIT를 함께 사용할 수 있다. JIT를 사용할 때 출발지 Any 같은 편리한 기본값을 검토 없이 받아들이지 않는다. 출발지, 포트, 지속 시간, 승인자, 경보와 예외 동작을 제한한다.

12. 명시적 아웃바운드 선택하기: NAT Gateway 또는 Azure Firewall

많은 Private VM에도 아웃바운드 연결은 필요하다. 흔히 사용하는 두 Azure Service는 역할이 다르다.

NAT Gateway: 예측 가능한 Subnet Egress

NAT Gateway는 Subnet에서 시작한 아웃바운드 흐름에 Source Network Address Translation(SNAT)을 제공한다. VM NIC에 Public IP를 연결하지 않아도 하나 이상의 명시적 고정 Public IP 또는 Public IP Prefix를 통해 인터넷 연결을 시작할 수 있다. VM이 시작한 흐름의 반환 트래픽은 허용되지만 NAT Gateway를 통한 비요청 인바운드 연결은 허용되지 않는다.

주요 요구사항이 다음과 같다면 NAT Gateway를 검토한다.

명시적이고 예측 가능한 아웃바운드 Public 주소
하나 이상의 Subnet을 위한 확장 가능한 아웃바운드 SNAT
외부 파트너가 고정 출발지 IP를 Allowlist에 등록해야 하는 경우
이 지점에서 중앙 FQDN 기반 목적지 정책이 필요하지 않은 경우

NAT Gateway는 Firewall이 아니다. 목적지를 검사하거나 FQDN Application Rule을 적용하거나 Endpoint·Application Security를 대체하지 않는다. 직접 인터넷 Egress에는 일반적으로 User-Defined Route가 필요하지 않다.

Azure Firewall: 중앙 정책과 검사

Azure Firewall은 관리형 Stateful Network Firewall이다. 선택한 SKU와 설계에 따라 Network Rule, Application Rule, Threat Intelligence Control, TLS Inspection 기능과 중앙 로그를 제공할 수 있다. 어떤 Public 주소가 Translation을 수행하는가보다 Workload가 어디로 연결할 수 있는가를 통제해야 할 때 사용한다.

Firewall 리소스를 배포하는 것만으로 트래픽이 자동 검사되지는 않는다. 일반적으로 0.0.0.0/0 User-Defined Route 같은 Workload Subnet Route가 의도한 흐름의 Next Hop을 Firewall로 지정해야 한다. Policy, DNS 동작, Diagnostic, 가용성, 처리 용량과 담당자도 구성해야 한다.

우연히 조합하지 않기

Virtual Appliance나 Firewall로 향하는 Default Route는 Subnet의 직접 인터넷 경로보다 우선하므로 NAT Gateway가 연결되어 있다는 이유만으로 트래픽이 그쪽을 선택하지 않는다. Microsoft가 문서화한 결합 설계에서는 Workload Subnet Route가 트래픽을 Azure Firewall로 보내고, NAT Gateway는 Firewall Egress를 위해 AzureFirewallSubnet에 연결한다. Workload Subnet에만 NAT Gateway를 연결해도 0.0.0.0/0 → VirtualAppliance Route 뒤에 자동 배치되는 것은 아니다. 두 서비스를 함께 사용한다면 토폴로지와 지원되는 통합 방식을 의도적으로 설계해야 한다. 필요한 통제 결과에서 시작한다.

요구사항	시작 선택지
단순한 직접 Egress에서 안정적이고 확장 가능한 아웃바운드 IP	NAT Gateway
중앙 목적지 허용·차단 정책과 검사	Azure Firewall
인터넷 종속성 없음	인터넷 Egress 없음, 필요한 사설 종속성을 모두 증명
Hybrid 중앙 보안 Appliance	이중화와 증적을 갖춘 승인 Route로 해당 Appliance 사용

13. 지원되는 Azure 서비스 종속성에 Private Endpoint 사용하기

Azure Private Link는 사설 연결 기술이다. Private Endpoint는 지원 서비스에 연결하기 위해 소비자 VNet에 생성하는 네트워크 인터페이스와 사설 IP다. VM은 Storage Account나 Key Vault 같은 특정 Azure 서비스 인스턴스에 Public Endpoint가 아닌 사설 주소로 접근할 수 있다. 서비스를 제공하는 쪽의 Private Link Service 설계는 이 글의 범위 밖이다.

세 가지 조건이 함께 맞아야 한다.

올바른 Private Endpoint와 Service Subresource가 존재한다.
VM의 DNS 환경에서 서비스 이름이 Private Endpoint의 Private IP로 해석된다.
Route, 적용되는 NSG, Service 구성과 ID가 연결을 허용한다.

Private DNS는 나중에 처리해도 되는 선택 사항이 아니다. VM에서 myvault.vault.azure.net 또는 Storage FQDN을 조회했을 때 계속 Public 주소가 반환되면 Private Endpoint 리소스가 있어도 애플리케이션은 잘못된 경로를 선택할 수 있다. 적합한 Private DNS Zone을 VNet에 연결하거나 조직 DNS Forwarder와 올바르게 통합한 뒤 Workload에서 실제 이름을 조회한다.

Private Endpoint를 만든다고 해당 서비스의 Public Network Access가 항상 자동 비활성화되는 것은 아니다. 서비스별 동작에 맞춰 대상 서비스의 Public Access 또는 Firewall 설정을 별도로 구성한다. 일부 서비스는 별도 Subresource를 제공한다. 예를 들어 Storage의 Blob과 File에는 각각 Endpoint와 DNS Record가 필요할 수 있다.

Private Endpoint는 다음을 의미하지 않는다.

관리자가 VM으로 RDP 또는 SSH하는 경로
모든 인터넷 사이트에 대한 사설 접속
Workload Identity와 서비스 권한의 대체
Public Endpoint가 비활성화되었다는 증거

14. NSG, Route, DNS가 설계를 표현하게 만들기

네 가지 경로를 선택했다면 실제 구성이 그 그림을 사실로 만들어야 한다.

NSG 원칙

실제 Bastion Subnet, VPN 주소 범위 또는 승인된 관리 Segment만 관리 접속을 허용한다.
애플리케이션은 의도한 Frontend 또는 Private Client 범위에서 필요한 Port로 들어오는 흐름만 허용한다.
아웃바운드 규칙도 검토한다. 인바운드만 확인하면 Data Exfiltration과 의도하지 않은 종속성을 놓친다.
요구사항을 정확히 나타낼 때 Service Tag 또는 Application Security Group을 사용하되 범위를 이해한다.
규칙의 이유와 담당자가 초기 배포 이후에도 남도록 명확한 Priority와 Description을 사용한다.
Subnet NSG 파일 하나만 읽지 말고 NIC의 Effective Security Rule을 확인한다.

Routing 원칙

Workload NIC에서 Effective Route를 확인한다.
Effective 0.0.0.0/0 Next Hop이 Internet, VirtualAppliance, VirtualNetworkGateway, None 중 무엇인지 확인한다. NAT Gateway 연결은 별도로 확인한다. NAT Gateway는 선택된 Next Hop이 Internet인 트래픽에 SNAT를 수행하며 Route Next Hop으로 표시되지는 않는다.
Hybrid 연결의 Return Route를 확인한다. Forward Path를 허용해도 Return Path가 없거나 비대칭이면 실패한다.
Peering이 Transitive하다고 가정하지 않는다. Hub-and-Spoke Routing은 명시적인 설계가 필요하다.

DNS 원칙

관리자 노트북이 아니라 VM 자체에서 이름 해석을 테스트한다.
Azure-provided DNS, Custom DNS Server, Private DNS Resolver 또는 On-Premises Forwarder 중 무엇이 응답하는지 기록한다.
반환된 주소와 의도한 DNS Zone Link 또는 Forwarding Rule을 함께 검증한다.
Private Endpoint FQDN이 Public 주소로 해석되면 단순 애플리케이션 오류가 아니라 설계 신호로 취급한다.

15. 세 가지 참조 시나리오

시나리오 A: 소규모 내부 운영 VM

운영자 → Azure Bastion → VM Private IP
VM → NAT Gateway → 필요한 외부 업데이트 엔드포인트
VM → Private Endpoint → Key Vault
Public 애플리케이션 인바운드 없음

VM NIC에는 Public IP가 없다. 대상 NSG는 AzureBastionSubnet에서 오는 SSH 또는 RDP만 허용한다. NAT Gateway는 명시적 아웃바운드 출발지 주소를 제공하지만 업데이트 목적지를 승인하지는 않는다. 목적지 정책이 필요하다면 다른 통제 지점에서 적용해야 한다. 엔드포인트 보안과 업데이트 정책도 여전히 필요하다. Key Vault에는 검증된 Private DNS와 함께 Private Endpoint를 사용한다. 별도의 긴급 복구(Break-glass) 방법과 담당자를 기록한다.

단순한 구조지만 Bastion이 있다는 이유만으로 “Zero Trust”라고 부를 수는 없다. 누가 시스템을 관리할 수 있는지는 ID 강도, Endpoint 상태, Guest 권한, Session 증적과 최소 권한이 결정한다.

시나리오 B: Private VM에서 실행되는 Public 웹 애플리케이션

고객 → Public Application Gateway + WAF → Private VM Backend
운영자 → Bastion 또는 VPN → Private VM 관리 Port
VM → Azure Firewall → 승인된 종속성
VM → Private Endpoint → Database 또는 Secret Service

워크로드는 Application Gateway에서 계속 인터넷에 노출된다. 따라서 Public IP, DDoS 대응, WAF, TLS, Health Probe와 애플리케이션 처리 용량을 검토해야 한다. Backend NSG는 Frontend 흐름만 허용한다. 관리는 별도 경로를 사용한다. Azure Firewall이 아웃바운드 목적지 정책을 적용하고, 필요한 경우 Private Endpoint로 Public 서비스 종속성을 줄인다.

정확한 표현은 “Backend VM에 Public IP가 없다”이지 “애플리케이션이 Private다”가 아니다.

시나리오 C: 기업 Hub-and-Spoke

관리자 네트워크 → VPN/ExpressRoute → Hub 보안 통제 → Spoke VM
Spoke VM → Hub Azure Firewall → 승인된 인터넷 목적지
Spoke VM → Private Endpoint / 사설 연결 서비스
Public 애플리케이션 → 통제된 Edge → Private Spoke Backend

정책과 증적을 중앙화할 수 있지만 Routing은 더 복잡하다. Peering 설정, Gateway Transit, Route Propagation, Default Route, Firewall Policy, DNS Forwarding, Return Path와 플랫폼·애플리케이션 팀 사이의 담당 범위를 확인한다. 명확한 Service Level Objective 없이 중앙화하면 Hub 자체가 공유 장애 경계가 될 수 있다.

16. 반복 가능한 9단계 구현 절차

1단계: 워크로드 분류

데이터 민감도, 업무 영향, 가용성 목표, 사용자 범위와 애플리케이션이 외부 공개형인지 사설형인지 또는 혼합형인지 기록한다.

2단계: 모든 흐름 자산 목록 작성

관리, 애플리케이션 인바운드, 아웃바운드 종속성, Azure 서비스 종속성, 모니터링, 백업, 시간 동기화, ID, 정품 인증과 복구 경로를 나열하고 담당자를 지정한다.

3단계: 필요한 경우 공개 경계 선택

인터넷 노출을 어디에 둘지 결정한다. 불필요한 직접 Public IP를 제거한다. VM Public IP를 관리되지 않는 Jump Host로 옮기고 위험을 해결했다고 말하지 않는다.

4단계: 주 관리 경로와 복구 경로 선택

Bastion, VPN, ExpressRoute 또는 다른 통제 경로를 선택한다. 게스트 ID, 최소 권한, Conditional Access, 사용하는 경우 JIT, 로그와 긴급 복구 담당자를 정의한다.

5단계: 명시적 아웃바운드 동작 선택

NAT Gateway, Azure Firewall, 통제된 Virtual Appliance 또는 인터넷 외부 통신 없음 중 하나를 선택한다. 목적지 요구사항과 실패 동작을 기록한다.

6단계: 지원되는 서비스 종속성 사설화

서비스와 하위 리소스(Subresource)마다 Private Endpoint를 평가한다. DNS와 Public Network Access를 별도로 구성한다. 담당자나 테스트가 없는 엔드포인트를 만들지 않는다.

7단계: NSG, 경로, DNS와 정책을 코드화

가능하다면 Infrastructure as Code와 정책 통제를 사용한다. 예외에는 종료 시점과 검토 절차를 둔다. 의도한 템플릿뿐 아니라 실제 적용 구성도 보관한다.

8단계: 허용·차단 경로 테스트

현실적인 출발지에서 반드시 동작해야 하는 경로와 반드시 실패해야 하는 경로를 증명한다. RDP 세션 한 번 성공했다고 테스트를 끝내지 않는다.

9단계: 운영과 재평가

구성 변경, 흐름, 게스트 상태, 애플리케이션 상태와 종속성 실패를 모니터링한다. 워크로드, 공개 경계, 네트워크, ID 모델 또는 Microsoft 서비스 동작이 바뀌면 다시 검토한다.

17. 허용·차단 테스트로 설계 증명하기

다음과 같은 표를 배포 증적으로 사용한다.

테스트	예상 결과	유용한 증적
인터넷에서 과거 VM Public 주소로 연결	실패, Public NIC 매핑이 존재하지 않음	NIC/IP 자산 목록과 연결 결과
권한 있는 ID로 승인 관리 경로를 거쳐 RDP/SSH	성공	Bastion/VPN Log, Guest 인증 Log, Session Record
승인되지 않은 인터넷 출발지에서 RDP/SSH	실패	NSG 흐름 증적 또는 Connection Troubleshoot 결과
승인된 WAF Frontend를 통한 Public HTTPS	Public Workload라면 성공	Frontend Access/WAF Log와 애플리케이션 상태
인터넷에서 Backend 애플리케이션으로 직접 연결	실패	NSG/Effective Rule과 연결 결과
승인된 아웃바운드 종속성	선택한 다음 홉을 통해 성공	실제 적용 경로, 방화벽/NAT 증적, 애플리케이션 테스트
승인되지 않은 아웃바운드 목적지	정책상 차단 대상이면 실패	방화벽 규칙과 로그, 애플리케이션 결과
VM에서 Azure Service FQDN 조회	의도한 Private IP 반환	DNS 조회 결과와 Private Endpoint Record
유효한 워크로드 ID로 Azure 서비스 접속	성공	서비스 감사 로그와 ID 로그인 증적
동일 서비스를 Public Network로 접속	Public Access를 껐다면 실패	Service Firewall/Public Access 구성과 테스트

Azure Network Watcher Connection Troubleshoot는 도달성과 Next Hop 문제를 찾는 데 도움이 되고, IP Flow Verify는 특정 흐름을 NSG 규칙이 허용하는지 평가할 수 있다. 신규 Flow Logging 설계에는 Virtual Network Flow Log를 사용한다. Microsoft는 2025년 6월 30일 이후 신규 NSG Flow Log 생성을 중단했고 기존 NSG Flow Log는 2027년 9월 30일 종료할 예정이므로 퇴역 예정 기능을 새로운 증적 전략의 기반으로 삼지 않는다.

18. 모니터링과 증적 담당자 지정하기

아무도 모니터링하지 않는 안전한 구성도는 조용히 변질된다. 다음 데이터의 담당자와 보존 기간을 정한다.

NIC, Public IP, NSG, Route, Bastion, Firewall과 Private Endpoint를 변경하는 Azure Activity Log
금지된 VM Public IP 또는 필수 통제를 검사하는 Azure Policy 준수 상태
해당되는 Azure Firewall, Bastion, VPN, WAF와 Load Balancer Diagnostic
Virtual Network Flow Log와 Network Watcher 테스트
Windows/Linux Guest 인증 및 보안 Log
애플리케이션, 종속성과 Health Telemetry
서비스를 사용할 경우 Defender for Cloud Recommendation과 JIT Event
Private 이름 해석이 중요한 경우 DNS Query 또는 Resolver 증적

경보에는 실제 수신자와 대응 절차가 필요하다. 예를 들어 운영 VM NIC에 새 Public IP가 연결되는 경우, Port 22 또는 3389를 0.0.0.0/0에 여는 NSG 규칙이 추가되는 경우, Default Route가 Firewall을 우회하는 경우, Private Endpoint DNS Record가 삭제되는 경우, 반복적인 Guest 로그인 실패가 발생하는 경우다.

19. Break-glass와 패치도 Private 설계에 포함하기

Private 관리 경로도 실패할 수 있다. Bastion, VPN, Hub Firewall, Custom DNS, ID Service 또는 VM Guest 자체가 중단될 수 있다. 사고가 나기 전에 통제된 복구 방식을 정한다.

Azure Run Command는 VM Agent를 통해 Script를 실행하므로 진단과 복구에 유용하다. 하지만 Agent 또는 그 종속성이 비정상이면 실패할 수 있으며 일상적인 Interactive 관리 Channel은 아니다. Action Run Command가 결과를 반환하려면 Azure Public IP로 향하는 Outbound TCP 443 연결도 필요하다. Inbound Port가 필요 없다는 이유만으로 완전히 격리된 Subnet에서도 항상 동작한다고 가정해서는 안 된다. Azure Serial Console은 지원되는 복구 상황에서 네트워크와 독립된 Console을 제공하지만 매우 높은 권한을 가지므로 제한된 Role과 모니터링을 갖춘 Break-glass 접속으로 취급해야 한다.

Azure Update Manager는 업데이트 평가와 설치를 조정하지만 모든 운영체제 Package를 직접 제공하는 저장소는 아니다. VM에는 여전히 Windows Update, WSUS, Linux Repository 또는 조직이 승인한 Content Source로 연결되는 유효한 경로가 필요하다. 아웃바운드를 제거하거나 제한하기 전에 이 종속성을 검증한다.

복구 기록에는 다음 항목을 포함한다.

실행 조건과 Incident 담당자
누가 방법 사용을 승인할 수 있는지
필요한 Azure 및 Guest Role
Credential 또는 ID 복구 절차
Log와 사후 검토 요구사항
사용 후 정상 통제를 복원하는 방법

20. 흔한 오해 바로잡기

오해	더 정확한 설명
“Public IP가 없으면 인터넷에서 VM에 도달할 수 없다.”	NIC Public IP로 직접 주소 지정할 수 없지만 Public Frontend나 DNAT 경로가 Private 주소로 전달할 수 있다.
“Public IP가 없으면 아웃바운드 인터넷도 없다.”	아웃바운드는 별개다. 오래된/Nonprivate Subnet에는 암시적 동작이 있거나 명시적 NAT/Firewall 경로가 구성될 수 있다.
“Bastion은 RDP와 SSH를 없앤다.”	Bastion은 RDP/SSH를 Private VM으로 전달한다. 대상 NSG, Guest Firewall, Service와 인증이 여전히 필요하다.
“Owner라면 모든 VM에 로그인할 수 있다.”	Azure 리소스 Role과 Guest 로그인 권한은 서로 다른 경계다.
“JIT가 Private 연결을 만든다.”	JIT는 지원되는 Access Rule을 일시 변경할 뿐 Route, VPN 또는 Guest 인증을 만들지 않는다.
“NAT Gateway가 위험한 목적지를 필터링한다.”	NAT Gateway는 아웃바운드 Translation과 Return Flow를 처리하며 Firewall 검사나 목적지 정책을 제공하지 않는다.
“Azure Firewall을 배포하면 모든 Subnet이 보호된다.”	Route가 의도한 트래픽을 Firewall로 보내야 하며 Policy도 허용·차단을 정의해야 한다.
“Private Endpoint를 만들면 Public Access도 자동 차단된다.”	Private Endpoint는 사설 Service 경로를 만들며 Public Access는 별도의 Service 설정이다.
“NSG가 허용하면 애플리케이션은 반드시 동작한다.”	DNS, Route, Return Path, Guest Firewall, Listener, ID, TLS와 애플리케이션 상태가 여전히 차단할 수 있다.
“Private이므로 모니터링은 필요 없다.”	사설 경로도 악용되거나 잘못 구성될 수 있다. 구성, 흐름, ID, Guest와 애플리케이션 증적이 필요하다.

21. 아키텍처 검토 체크리스트

노출 범위

모든 VM NIC Public IP의 목록과 필요 근거가 있다.
Public 애플리케이션 Edge를 Backend VM과 구분해 명명했다.
인터넷에서 직접 들어오는 RDP와 SSH가 없다.
Public DNAT와 Load Balancing Rule도 노출 검토에 포함했다.
실제 Public Edge에서 DDoS와 WAF 요구사항을 평가했다.

관리와 ID

주 관리 경로 하나와 복구 경로 하나를 문서화하고 테스트했다.
Azure 리소스 권한과 Guest 로그인 권한을 별도로 검토했다.
대상 NSG가 실제 관리 출발지와 필요 Port만 허용한다.
JIT 사용 시 출발지, 지속 시간, Port와 Defender for Servers Plan 2 종속성을 기록했다.
공유 Credential과 영구적인 광범위 관리자 권한을 피했거나 정식 예외 처리했다.

아웃바운드와 Service 접속

Subnet의 실제 Default Outbound 상태를 확인했다.
모든 필수 인터넷 종속성에 담당자와 명시적 Egress 경로가 있다.
익숙한 제품이 아니라 통제 요구사항으로 NAT Gateway와 Azure Firewall을 선택했다.
VM에서 Private Endpoint Subresource와 Private DNS 결과를 검증했다.
필요 시 Public Service Access를 별도로 비활성화하거나 제한했다.
Update, Activation, Monitoring, Backup과 ID 종속성을 테스트했다.

증적과 운영

Effective Route와 Effective Security Rule이 의도한 그림과 일치한다.
Positive·Negative 연결 테스트 결과를 보관한다.
Activity, Flow, ID, Guest, Firewall과 애플리케이션 Log에 담당자와 보존 기간이 있다.
새 Public IP 연결과 위험하게 넓은 관리 규칙에 대한 경보가 있다.
Break-glass 접속을 제한·모니터링하고 사용 후 검토한다.
측정 가능한 재검토일 또는 재검토 조건이 있다.

22. 스스로 확인할 질문

VM NIC에서 Public IP를 제거하면 어떤 직접 경로가 사라지는가?
그 뒤에도 애플리케이션이 인터넷에 노출될 수 있는 이유는 무엇인가?
Azure Resource Manager 접속과 Windows/Linux Guest 접속은 어떻게 다른가?
DNS, Route, NSG는 각각 어떤 서로 다른 질문에 답하는가?
Azure Bastion이 VM의 아웃바운드 경로가 아닌 이유는 무엇인가?
Private-only Bastion을 사용할 때 관리자에게 추가로 필요한 것은 무엇인가?
JIT는 Bastion과 어떻게 다른가?
어떤 경우에 Azure Firewall보다 NAT Gateway가 더 적합한 시작점인가?
Azure Firewall 배포만으로 VM이 그 경로를 사용한다고 증명할 수 없는 이유는 무엇인가?
Private Endpoint 도입 시 어떤 두 설정을 별도로 고려해야 하는가?
Azure Update Manager를 구성해도 패치가 실패할 수 있는 이유는 무엇인가?
Backend가 직접 노출되지 않았음을 증명하는 Negative Test는 무엇인가?

답변이 단순히 “Private이기 때문”이라면 흐름 지도로 돌아가 ID, 주소, Route, 통제와 증적을 구체적으로 말해 본다.

23. 한 페이지 기억 카드

1. VM NIC Public IP 제거
   → 해당 NIC의 직접 Public 주소 지정을 없앤다.
   → Public Frontend나 아웃바운드를 자동 제거하지는 않는다.

2. 네 경로 분리
   → Guest 관리
   → 애플리케이션 인바운드
   → 인터넷 아웃바운드
   → Azure Service 사설 접속

3. 역할에 맞는 통제 선택
   Bastion / VPN / ExpressRoute → 관리 경로
   WAF / Load Balancer / 승인 Edge → 애플리케이션 인바운드
   NAT Gateway → 예측 가능한 아웃바운드 Translation
   Azure Firewall → 중앙 목적지 정책과 검사
   Private Endpoint + Private DNS → 지원 Service의 사설 경로
   NSG → 네트워크 흐름 허용 또는 차단
   Route → Next Hop 선택
   ID + Guest 권한 → 누가 작업하거나 로그인할지 결정

4. 양방향 증명
   필요한 흐름은 성공한다.
   금지한 흐름은 실패한다.
   Log와 Effective Configuration이 그 이유를 설명한다.

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

사설 Azure VM은 하나의 Public IP가 없다는 사실이 아니라 서로 다른 경로를 분리하는 방식으로 설계한다.

다음 Module 1 상세 노트에서는 이번 설계의 기초 구성요소인 VNet과 NSG를 클라우드 입문자 관점에서 다룰 예정이다. 완성된 영문·국문 글 한 쌍이 준비되기 전까지는 계획 상태로 유지하며 빈 경로를 연결하지 않는다.