Azure 기반 네트워크 통신 분할에 제로 트러스트 원칙 적용

아티클
05/31/2024

이 문서에서는 Azure 환경에서 네트워크를 분할하기 위한 제로 트러스트 원칙을 적용하기 위한 지침을 제공합니다. 다음은 제로 트러스트 원칙입니다.

제로 트러스트 원칙	정의
명시적으로 확인	항상 사용 가능한 모든 데이터 포인트를 기반으로 인증하고 권한을 부여합니다.
최소 권한 액세스 사용	JIT/JEA(Just-In-Time and Just-Enough-Access), 위험 기반 적응 정책 및 데이터 보호를 사용하여 사용자 액세스를 제한합니다.
위반 가정	미치는 영향 및 세그먼트 액세스를 최소화합니다. 엔드투엔드 암호화를 확인하고, 분석을 사용하여 가시성을 확보하고, 위협 탐지를 추진하고, 방어를 향상시킵니다. Azure 인프라의 다양한 수준에서 네트워크 구분을 수행하여 사이버 공격 폭발 반경 및 세그먼트 액세스를 최소화할 수 있습니다.

이 문서는 Azure 네트워킹에 제로 트러스트 원칙을 적용하는 방법을 보여 주는 일련의 문서의 일부입니다.

조직이 중소기업에서 대기업으로 성장함에 따라 단일 Azure 구독에서 여러 구독으로 이동하여 각 부서에 대한 리소스를 분리해야 하는 경우가 많습니다. 네트워크 분할을 신중하게 계획하여 환경 간의 논리적 경계와 격리를 만드는 것이 중요합니다.

일반적으로 조직의 별도 부서를 반영하는 각 환경에는 특정 워크로드에 대한 자체 액세스 권한 및 정책이 있어야 합니다. 예를 들어 내부 소프트웨어 개발자 구독의 사용자는 연결 구독에서 네트워크 리소스를 관리하고 배포하는 데 액세스할 수 없어야 합니다. 그러나 이러한 환경은 여전히 DNS, 하이브리드 연결과 같은 기본 서비스에 필요한 기능을 달성하고 다른 Azure VNet(가상 네트워크)에서 다른 리소스에 연결할 수 있도록 네트워크 연결이 필요합니다.

Azure 인프라의 세분화는 격리뿐만 아니라 공격자가 환경 간에 이동하고 추가 피해를 입히지 않도록 하는 보안 경계를 만들 수 있습니다(위반 가정 제로 트러스트 원칙).

참조 아키텍처

Azure에서 다양한 수준의 분할을 사용하여 무단 액세스 또는 악의적인 공격으로부터 리소스를 보호할 수 있습니다. 이러한 분할 수준은 구독 수준에서 시작하여 가상 머신에서 실행되는 애플리케이션으로 이동합니다. 분할은 각각 고유한 규칙과 정책을 사용하여 한 환경을 다른 환경과 분리하는 경계를 만듭니다. 위반이 발생할 수 있다는 가정 하에 네트워크를 분할하여 확산을 방지해야 합니다.

Azure 네트워킹은 다음과 같은 수준의 분할을 사용합니다.

Abunələr

Azure 구독은 Azure에서 리소스를 프로비저닝하는 데 사용되는 논리적 컨테이너입니다. Microsoft Entra ID 테넌트의 Azure 계정에 연결되며 구독에 할당된 Azure 리소스에 대한 단일 청구 단위로 사용됩니다. Azure 구독은 구독에 포함된 리소스에 액세스하기 위한 논리적 경계이기도 합니다. 다른 구독의 리소스 간에 액세스하려면 명시적 권한이 필요합니다.
VNet

Azure VNet은 기본적으로 내의 모든 가상 머신이 서로 통신할 수 있도록 하는 격리된 프라이빗 네트워크입니다. 기본적으로 VNet은 피어링, VPN 연결 또는 ExpressRoute를 통해 VNet 간에 연결을 만들지 않는 한 다른 VNet과 통신할 수 없습니다. 개별 VNet은 서로 다른 애플리케이션, 워크로드, 부서 또는 조직을 나누는 트러스트 경계로 사용할 수 있습니다.

AVNM(Azure Virtual Network Manager )은 단일 관리 팀이 VNet을 관리하고 전역적으로 여러 구독에서 보안 규칙을 적용할 수 있도록 하는 네트워크 관리 서비스입니다. AVNM을 사용하여 네트워크 그룹을 정의하여 서로 통신할 수 있는 VNet을 결정할 수 있습니다. AVNM을 사용하여 네트워크 구성 변경 내용을 모니터링할 수도 있습니다.
VNet 내의 워크로드

가상 머신 또는 Azure Databricks 및 App Service와 같은 VNet 통합을 지원하는 PaaS 서비스와 같은 VNet 내 워크로드의 경우 통신은 기본적으로 동일한 VNet 내에 포함되어 있고 네트워크 보안 그룹을 사용하여 추가로 보호되어야 하므로 허용됩니다. VNet 내의 분할을 위한 도구 및 서비스에는 다음이 포함됩니다.
- Azure Firewall
  
  Azure Firewall 은 클라우드 리소스, 온-프레미스 및 인터넷 간의 트래픽을 필터링하기 위해 VNet에 배포된 서비스입니다. Azure Firewall을 사용하면 네트워크 및 애플리케이션 계층에서 트래픽을 허용하거나 거부하는 규칙 및 정책을 정의할 수 있습니다. 또한 IDPS(침입 탐지 및 방지 시스템), TLS(전송 계층 보안) 검사 및 위협 인텔리전스 기반 필터링과 같은 Azure Firewall에서 제공하는 고급 위협 방지 기능을 활용할 수 있습니다.
- 네트워크 보안 그룹
  
  네트워크 보안 그룹은 VNet 내의 가상 머신과 같은 Azure 리소스 간의 네트워크 트래픽을 필터링하는 액세스 제어 메커니즘입니다. 네트워크 보안 그룹에는 VNet의 서브넷 또는 가상 머신 수준에서 트래픽을 허용하거나 거부하는 보안 규칙이 포함되어 있습니다. 네트워크 보안 그룹의 일반적인 사용은 서로 다른 서브넷에 있는 가상 머신 집합을 분할하는 것입니다.
- 애플리케이션 보안 그룹
  
  애플리케이션 보안 그룹은 해당 역할 및 기능에 따라 가상 머신의 네트워크 인터페이스를 그룹화할 수 있는 네트워크 보안 그룹의 확장입니다. 그런 다음 가상 머신의 IP 주소를 정의하지 않고도 대규모로 네트워크 보안 그룹의 애플리케이션 보안 그룹을 사용할 수 있습니다.
- Azure Front Door
  
  Azure Front Door 는 전 세계 사용자와 애플리케이션의 정적 및 동적 웹 콘텐츠 간에 빠르고 안정적이며 안전한 액세스를 제공하는 Microsoft의 최신 클라우드 CDN(Content Delivery Network)입니다.

다음 다이어그램은 구분 수준에 대한 참조 아키텍처를 보여줍니다.

다이어그램에서 단색 빨간색 선은 다음 사이의 구분 수준을 나타냅니다.

Azure 구독
구독의 VNet
VNet의 서브넷
인터넷 및 VNet

또한 다이어그램은 AZURE 구독에 걸쳐 있는 AVNM에서 관리하는 VNet 집합을 보여 줍니다.

이 문서의 내용

제로 트러스트 원칙은 Azure 클라우드 내의 참조 아키텍처에 적용됩니다. 다음 표에서는 위반 가정 제로 트러스트 원칙을 준수하기 위해 이 아키텍처 전체에서 네트워크를 분할하기 위한 권장 사항을 설명합니다.

단계	작업
1	개별 VNet 내의 세그먼트입니다.
2	피어링을 사용하여 여러 VNet을 연결합니다.
3	허브 및 스포크 구성에서 여러 VNet을 연결합니다.

1단계: 개별 VNet 내의 세그먼트

Azure 구독의 단일 VNet 내에서 서브넷을 사용하여 리소스를 분리하고 구분합니다. 예를 들어 VNet 내에는 데이터베이스 서버용 서브넷, 웹 애플리케이션용 서브넷, 웹 애플리케이션 방화벽이 있는 Azure Firewall 또는 Azure 애플리케이션 Gateway 용 전용 서브넷이 있을 수 있습니다. 기본적으로 서브넷 간의 모든 통신은 VNet 내에서 사용하도록 설정됩니다.

서브넷 간에 격리를 만들려면 네트워크 보안 그룹 또는 애플리케이션 보안 그룹을 적용하여 IP 주소, 포트 또는 프로토콜에 따라 특정 네트워크 트래픽을 허용하거나 거부할 수 있습니다. 그러나 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 디자인하고 유지 관리하면 관리 오버헤드가 발생할 수도 있습니다.

이 그림에서는 각 계층에 대해 별도의 서브넷이 있는 3계층 애플리케이션의 일반적이고 권장되는 구성과 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 사용하여 각 서브넷 간에 구분된 경계를 만드는 방법을 보여 줍니다.

Azure Firewall 또는 타사 NVA(네트워크 가상 어플라이언스)를 가리키는 UDR(사용자 정의 경로)을 사용하여 서브넷 간 트래픽을 라우팅하여 리소스를 세분화할 수도 있습니다. Azure Firewall 및 NVA에는 계층 3에서 계층 7 컨트롤로 트래픽을 허용하거나 거부하는 기능도 있습니다. 이러한 서비스의 대부분은 고급 필터링 기능을 제공합니다.

자세한 내용은 패턴 1: 단일 가상 네트워크의 지침을 참조하세요.

2단계: 피어링을 사용하여 여러 VNet 연결

기본적으로 단일 Azure 구독 또는 여러 구독에서 VNet 간에 허용되는 통신은 없습니다. 서로 다른 엔터티에 속하는 여러 VNet에는 자체 액세스 제어가 있습니다. Azure Firewall 또는 타사 NVA가 모든 트래픽을 검사하는 VNet 피어링을 사용하여 서로 또는 중앙 집중식 허브 VNet에 연결할 수 있습니다.

이 그림에서는 두 VNet 간의 VNet 피어링 연결과 연결의 각 끝에서 Azure Firewall을 사용하는 방법을 보여 줍니다.

허브 VNet에는 일반적으로 방화벽, ID 공급자 및 하이브리드 연결 구성 요소와 같은 공유 구성 요소가 포함됩니다. 마이크로 분할을 위해 특정 접두사 UDR을 추가하는 것은 VNet 내 트래픽이 요구 사항인 경우에만 필요하기 때문에 UDR 관리는 더 간단해집니다. 그러나 VNet에는 자체 경계가 있으므로 보안 컨트롤이 이미 있습니다.

자세한 내용은 다음 지침을 참조하세요.

3단계: 허브 및 스포크 구성에서 여러 VNet 연결

허브 및 스포크 구성의 여러 VNet의 경우 이러한 경계에 대한 네트워크 트래픽을 분할하는 방법을 고려해야 합니다.

인터넷 경계
온-프레미스 네트워크 경계
글로벌 Azure 서비스에 대한 경계

인터넷 경계

인터넷 트래픽 보안은 네트워크 보안의 기본 우선 순위이며, 여기에는 Azure 워크로드에서 인터넷(신뢰할 수 있는)으로 전달되는 인터넷(신뢰할 수 없음)의 수신 트래픽 관리와 송신 트래픽이 포함됩니다.

인터넷의 수신 트래픽에는 단일 진입점이 있는 것이 좋습니다. Microsoft는 수신 트래픽이 Azure Firewall, Azure Front Door 또는 Azure 애플리케이션 Gateway와 같은 Azure PaaS 리소스를 통과하도록 권장합니다. 이러한 PaaS 리소스는 공용 IP 주소가 있는 가상 머신보다 더 많은 기능을 제공합니다.

Azure Firewall

이 그림에서는 자체 서브넷의 Azure Firewall이 인터넷과 Azure VNet의 3계층 워크로드 간의 트래픽에 대한 중앙 진입점 및 구분 경계 역할을 하는 방법을 보여 줍니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 Azure Firewall을 참조하세요.

Azure Front Door

Azure Front Door는 인터넷과 Azure에서 호스트되는 서비스 사이의 경계 역할을 할 수 있습니다. Azure Front Door는 VNet 액세스를 위한 ILB(내부 부하 분산), 정적 웹 사이트 및 Blob Storage에 대한 스토리지 계정 및 Azure 앱 서비스와 같은 리소스에 대한 Private Link 연결을 지원합니다. Azure Front Door는 일반적으로 대규모 배포를 위해 수행됩니다.

Azure Front Door는 부하 분산 서비스 이상입니다. Azure Front Door 인프라에는 DDoS 보호가 기본 제공되어 있습니다. 캐싱을 사용하도록 설정하면 백 엔드 서버에 지속적으로 액세스하는 대신 POP(현재 상태 지점) 위치에서 콘텐츠를 검색할 수 있습니다. 캐시가 만료되면 Azure Front Door는 요청된 리소스를 검색하고 캐시를 업데이트합니다. Azure Front Door는 최종 사용자가 서버에 액세스하는 대신 분할 TCP를 두 개의 별도 연결에 사용합니다. 이렇게 하면 최종 사용자 환경이 향상될 뿐만 아니라 악의적인 행위자가 리소스에 직접 액세스하지 못하게 됩니다.

이 그림에서는 Azure Front Door가 스토리지 계정에 있을 수 있는 인터넷 사용자와 Azure 리소스 간에 분할을 제공하는 방법을 보여 줍니다.

자세한 내용은 Azure Well-Architected Framework의 Azure Front Door를 참조하세요.

Azure Application Gateway

인터넷 진입점은 수신 지점의 조합일 수도 있습니다. 예를 들어 HTTP/HTTPS 트래픽은 웹 애플리케이션 방화벽 또는 Azure Front Door로 보호되는 Application Gateway를 통해 수신할 수 있습니다. RDP/SSH와 같은 비 HTTP/HTTPS 트래픽은 Azure Firewall 또는 NVA를 통해 수신할 수 있습니다. 이러한 두 요소를 함께 사용하여 심층 검사를 수행하고 UDR을 사용하여 트래픽 흐름을 제어할 수 있습니다.

이 그림에서는 인터넷 수신 트래픽 및 HTTP/HTTPS 트래픽에 대한 웹 애플리케이션 방화벽 및 다른 모든 트래픽에 대한 Azure Firewall과 함께 Application Gateway를 사용하는 방법을 보여 줍니다.

일반적으로 권장되는 두 가지 시나리오는 다음과 같습니다.

Application Gateway와 병렬로 Azure Firewall 또는 NVA를 배치합니다.
대상에 도달하기 전에 추가 트래픽 검사를 위해 Application Gateway 후에 Azure Firewall 또는 NVA를 배치합니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 Azure 애플리케이션 Gateway를 참조하세요.

다음은 인터넷 트래픽 흐름에 대한 추가적인 일반적인 패턴입니다.

여러 인터페이스를 사용하는 수신 트래픽

한 가지 방법은 NVA를 사용할 때 가상 머신에서 여러 네트워크 인터페이스를 사용하는 것입니다. 즉, 신뢰할 수 없는 트래픽(외부 연결)에 대한 인터페이스와 신뢰할 수 있는 트래픽(내부 연결)에 대한 인터페이스가 있습니다. 트래픽 흐름 측면에서 UDR을 사용하여 온-프레미스에서 NVA로 수신 트래픽을 라우팅해야 합니다. NVA에서 수신한 인터넷의 수신 트래픽은 게스트 OS 어플라이언스와 UDR의 정적 경로를 조합하여 적절한 VNet 또는 서브넷의 대상 워크로드로 라우팅되어야 합니다.

송신 트래픽 및 UDR

인터넷용 VNet을 출발하는 트래픽의 경우 선택한 NVA를 다음 홉으로 사용하여 경로 테이블을 사용하여 UDR을 적용할 수 있습니다. 복잡성을 줄이기 위해 Azure Virtual WAN 허브 내에 Azure Firewall 또는 NVA를 배포하고 라우팅 의도를 사용하여 인터넷 보안을 설정할 수 있습니다. 이렇게 하면 비 Azure VIP(가상 IP 주소)로 향하는 남북 트래픽(네트워크 범위에서 들어오고 나가는) 및 동서 트래픽(네트워크 범위 내의 디바이스 간)이 모두 검사됩니다.

송신 트래픽 및 기본 경로

일부 메서드에는 다른 메서드를 사용하여 기본 경로(0.0.0.0/0)를 관리하는 작업이 포함됩니다. 일반적으로 Azure에서 발생하는 송신 트래픽은 Azure 인프라에서 처리할 수 있는 처리량으로 인해 종료 지점 및 검사를 Azure Firewall 또는 NVA로 활용하는 것이 좋습니다. 대부분의 경우 훨씬 더 크고 복원력이 있을 수 있습니다. 이 경우 워크로드 서브넷의 UDR에서 기본 경로를 구성하면 해당 종료 지점으로 트래픽이 강제로 발생할 수 있습니다. 또한 송신 트래픽을 온-프레미스에서 Azure로 종료 지점으로 라우팅하는 것이 좋습니다. 이 경우 NVA와 함께 Azure Route Server를 활용하여 BGP(Border Gateway Protocol)를 활용하는 온-프레미스에 기본 경로를 보급합니다.

BGP를 통해 기본 경로를 보급하여 모든 송신 트래픽을 온-프레미스로 다시 라우팅해야 하는 특별한 경우가 있습니다. 이렇게 하면 검사를 위해 온-프레미스 네트워크를 통해 VNet을 나가는 트래픽을 방화벽으로 터널화합니다. 이 마지막 방법은 대기 시간이 늘어나고 Azure에서 제공하는 보안 제어가 부족하기 때문에 가장 바람직하지 않습니다. 이 관행은 온-프레미스 환경 내에서 트래픽 검사에 대한 특정 요구 사항이 있는 정부 및 은행 부문에 의해 널리 채택됩니다.

규모 측면에서:

단일 VNet의 경우 계층 4 의미 체계를 엄격하게 준수하는 네트워크 보안 그룹을 사용하거나 계층 4 및 계층 7 의미 체계를 모두 준수하는 Azure Firewall을 사용할 수 있습니다.
여러 VNet의 경우 연결할 수 있는 경우 단일 Azure Firewall을 계속 사용하거나 각 가상 네트워크에 Azure Firewall을 배포하고 UDR을 사용하여 트래픽을 직접 배포할 수 있습니다.

대기업 분산 네트워크의 경우 허브 및 스포크 모델을 계속 사용하고 UDR을 사용하여 트래픽을 직접 처리할 수 있습니다. 그러나 이로 인해 관리 오버헤드 및 VNet 피어링 제한이 발생할 수 있습니다. 사용 편의성을 위해 가상 허브에 Azure Firewall을 배포하고 인터넷 보안에 대한 라우팅 의도를 활성화하면 Azure Virtual WAN에서 이를 달성할 수 있습니다. 이렇게 하면 모든 스포크 및 분기 네트워크에 기본 경로를 삽입하고 검사를 위해 인터넷 바인딩된 트래픽을 Azure Firewall로 보냅니다. RFC 1918 주소 블록으로 향하는 프라이빗 트래픽은 Azure Virtual WAN 허브 내에서 지정된 다음 홉으로 Azure Firewall 또는 NVA로 전송됩니다.

온-프레미스 네트워크 경계

Azure에서 온-프레미스 네트워크와의 연결을 설정하는 주요 방법은 IPsec(인터넷 프로토콜) 터널, ExpressRoute 터널 또는 SD-WAN(소프트웨어 정의 WAN) 터널입니다. 일반적으로 더 적은 대역폭이 필요한 더 작은 워크로드에 Azure S2S(사이트 대 사이트) VPN 연결을 사용합니다. 전용 서비스 경로 및 더 높은 처리량 요구 사항이 필요한 워크로드의 경우 ExpressRoute를 권장합니다.

이 그림에서는 Azure 환경과 온-프레미스 네트워크 간의 다양한 유형의 연결 방법을 보여 줍니다.

Azure VPN 연결은 여러 터널을 지원할 수 있지만 ExpressRoute는 연결 파트너를 통해 더 높은 대역폭 및 프라이빗 연결이 필요한 대규모 엔터프라이즈 네트워크에 대해 구성되는 경우가 많습니다. ExpressRoute의 경우 동일한 VNet을 여러 회로에 연결할 수 있지만 세분화를 위해 VNet이 서로 연결되지 않아 통신할 수 있기 때문에 이상적이지 않은 경우가 많습니다.

분할 방법 중 하나는 스포크 VNet에서 원격 게이트웨이를 사용하지 않도록 선택하거나 경로 테이블을 사용하는 경우 BGP 경로 전파를 사용하지 않도록 설정하는 것입니다. NVA 및 방화벽을 사용하여 ExpressRoute에 연결된 허브를 분할할 수 있습니다. 허브에 피어링된 스포크의 경우 VNet 피어링 속성에서 원격 게이트웨이를 사용하지 않도록 선택할 수 있습니다. 이렇게 하면 스포크는 온-프레미스 경로가 아닌 직접 연결된 허브에 대해서만 알아봅니다.

온-프레미스 간 트래픽을 분할하는 또 다른 새로운 접근 방식은 SD-WAN 기술을 사용하는 것입니다. Azure에서 타사 NVA를 사용하여 NVA 어플라이언스 내의 다른 분기에서 들어오는 SD-WAN 터널을 기반으로 분할을 만들어 분기 위치를 Azure SD-WAN으로 확장할 수 있습니다. Azure Route Server를 사용하여 SD-WAN 터널의 주소 접두사를 허브 및 스포크 토폴로지용 Azure 플랫폼에 삽입할 수 있습니다.

가상 WAN 토폴로지의 경우 가상 허브 내에서 타사 SD-WAN NVA를 직접 통합할 수 있습니다. BGP 엔드포인트를 사용하여 SD-WAN 솔루션을 사용하도록 허용하여 가상 허브 통합 NVA에서 터널을 만들 수도 있습니다.

두 모델 모두 ExpressRoute를 사용하여 프라이빗 피어링 또는 Microsoft 피어링을 사용하여 기본 프라이빗 또는 퍼블릭 연결을 분할할 수 있습니다. 보안을 위해 ExpressRoute를 통해 기본 경로를 보급하는 것이 일반적입니다. 이렇게 하면 검사를 위해 VNet을 떠나는 모든 트래픽이 온-프레미스 네트워크로 터널됩니다. 마찬가지로 VPN 및 ExpressRoute를 통해 들어오는 트래픽은 추가 검사를 위해 NVA로 전송될 수 있습니다. 이는 Azure를 떠나는 트래픽에도 적용됩니다. 이러한 메서드는 환경이 더 작은 경우(예: 하나 또는 두 개의 지역) 간단합니다.

대규모 분산 네트워크의 경우 라우팅 의도를 사용하여 프라이빗 트래픽 검사를 활성화하여 Azure Virtual WAN을 사용할 수도 있습니다. 검사를 위해 NVA의 개인 IP 주소로 향하는 모든 트래픽을 전달합니다. 위의 방법과 마찬가지로 환경이 여러 지역에 걸쳐 있을 때 관리하기가 훨씬 쉽습니다.

Azure Virtual WAN의 다른 방법은 격리 경계에 사용자 지정 경로 테이블을 사용하는 것입니다. 사용자 지정 경로를 만들고 해당 경로 테이블에 원하는 VNet만 연결하고 전파할 수 있습니다. 그러나 이 기능은 현재 라우팅 의도와 결합할 수 없습니다. 분기를 격리하려면 해당 레이블에 분기를 연결할 레이블을 할당할 수 있습니다. 허브별로 기본 레이블로 전파를 사용하지 않도록 설정할 수도 있습니다. 현재 Azure의 개별 분기는 단일 허브에서 별도로 격리할 수 없습니다. 예를 들어 ExpressRoute에서 SD-WAN을 격리할 수 없습니다. 그러나 전체 허브에서 기본 레이블로 전파를 사용하지 않도록 설정할 수 있습니다.

글로벌 Azure 서비스에 대한 경계

Azure에서 대부분의 서비스는 기본적으로 Azure 전역 WAN을 통해 액세스할 수 있습니다. 이는 Azure PaaS 서비스에 대한 공용 액세스에도 적용됩니다. 예를 들어 Azure Storage에는 VNet에 대한 액세스를 제한하고 공용 액세스를 차단할 수 있는 기본 제공 방화벽이 있습니다. 그러나 더 세분화된 제어가 필요한 경우가 많습니다. 일반적인 기본 설정은 제공된 기본 공용 IP 주소를 사용하는 대신 Azure VIP에 비공개로 연결하는 것입니다.

PaaS 리소스에 대한 액세스를 제한하는 가장 일반적인 방법은 Azure Private Link를 사용하는 것입니다. 프라이빗 엔드포인트를 만들면 VNet에 삽입됩니다. Azure는 이 개인 IP 주소를 사용하여 해당 PaaS 리소스로 터널을 연결합니다. Azure는 Azure 프라이빗 DNS 영역을 사용하여 프라이빗 엔드포인트에 DNS A 레코드를 매핑하고 CNAME 레코드를 프라이빗 링크 PaaS 리소스에 매핑합니다.

서비스 엔드포인트는 PaaS VIP에 연결하기 위한 대체 방법을 제공합니다. 서비스 태그를 선택하여 해당 태그 내의 모든 PaaS 리소스에 대한 연결을 허용하고 PaaS 리소스에 대한 프라이빗 연결을 제공할 수 있습니다.

또 다른 일반적인 방법은 ExpressRoute용 Microsoft 피어링을 사용하는 것입니다. 온-프레미스에서 PaaS VIP에 연결하려는 경우 Microsoft 피어링을 설정할 수 있습니다. VIP를 사용할 BGP 커뮤니티를 선택할 수 있으며 Microsoft 피어링 경로를 통해 보급됩니다.