단일 지역 시나리오 - Azure Virtual WAN의 Private Link 및 DNS

이 문서에서는 프라이빗 엔드포인트를 통해 PaaS 리소스를 단일 지역의 특정 워크로드에 노출하는 방법을 보여 줍니다. 이 시나리오에서 네트워크 토폴로지는 허브-스포크이며 허브는 Azure Virtual WAN 허브입니다.

시나리오

그림 1: Private Link 및 Azure DNS를 사용하는 Virtual WAN에 대한 단일 지역 시나리오 - 과제

이 아키텍처의 Visio 파일을 다운로드합니다. 이 섹션에서는 시나리오를 정의하고 이 시나리오에 대한 챌린지를 다시 정의합니다(챌린지는 개요 페이지의 비작업 예제와 동일). 초기 시나리오 아키텍처는 개요 가이드에 정의된 시작 네트워크 토폴로지에서 빌드됩니다. 다음은 추가 및 변경 내용입니다.

• 하나의 가상 허브를 가진 지역은 하나뿐입니다.
• 공용 네트워크 액세스가 사용하지 않도록 설정된 지역에 Azure Storage 계정이 있습니다. 이 시나리오에서는 하나의 워크로드만 스토리지 계정에 액세스한다고 가정합니다.
• 처음에는 가상 허브에 연결된 단일 가상 네트워크가 있습니다.
• 가상 네트워크에는 VM(가상 머신) 클라이언트를 포함하는 워크로드 서브넷이 있습니다.
• 가상 네트워크에는 스토리지 계정에 대한 프라이빗 엔드포인트가 포함된 프라이빗 엔드포인트 서브넷이 포함되어 있습니다.

성공적인 결과

Azure Virtual Machine 클라이언트는 동일한 가상 네트워크에 있는 스토리지 계정의 프라이빗 엔드포인트를 통해 Azure Storage 계정에 연결할 수 있으며 스토리지 계정에 대한 다른 모든 액세스는 차단됩니다.

장애

스토리지 계정의 FQDN(정규화된 do기본 이름)을 프라이빗 엔드포인트의 개인 IP 주소로 다시 확인할 수 있는 DNS 흐름의 DNS 레코드가 필요합니다. 개요에 설명된 것처럼 시나리오의 과제는 두 가지입니다.

1. 가상 허브에 필요한 스토리지 계정 DNS 레코드와 기본 프라이빗 DNS 영역을 연결할 수 없습니다.
2. 프라이빗 DNS 영역을 워크로드 네트워크에 연결할 수 있으므로 작동한다고 생각할 수 있습니다. 아쉽게도 기준 아키텍처는 연결된 각 가상 네트워크에 Azure Firewall DNS 프록시를 사용하도록 DNS 서버가 구성되어 있다고 규정하고 있습니다.

프라이빗 DNS 영역을 가상 허브에 연결할 수 없고 가상 네트워크가 Azure Firewall DNS 프록시를 사용하도록 구성되었으므로 Azure DNS 서버에는 스토리지 계정의 FQDN(FQDN)을 프라이빗 엔드포인트의 개인 IP 주소로 확인하는 메커니즘이 없습니다. 그 결과 클라이언트가 잘못된 DNS 응답을 받습니다.

DNS 및 HTTP 흐름

이 워크로드에 대한 DNS 및 결과 HTTP 요청 흐름을 검토해 보겠습니다. 검토는 앞에서 설명한 장애를 시각화하는 데 도움이 됩니다.

그림 2: Private Link 및 Azure DNS를 사용하는 Virtual WAN에 대한 단일 지역 시나리오 - 과제

이 아키텍처의 Visio 파일을 다운로드합니다.

DNS 흐름

1. 클라이언트의 DNS 쿼리 stgworkload00.blob.core.windows.net 는 피어된 지역 허브의 Azure Firewall인 구성된 DNS 서버로 전송됩니다.
2. Azure Firewall은 Azure DNS에 요청을 프록시합니다. 프라이빗 DNS 영역을 가상 허브에 연결할 수 없으므로 Azure DNS는 프라이빗 엔드포인트 개인 IP 주소로 FQDN을 확인하는 방법을 모릅니다. FQDN을 스토리지 계정의 공용 IP 주소로 확인하는 방법을 알고 있으므로 스토리지 계정의 공용 IP 주소를 반환합니다.

HTTP 흐름

1. DNS 결과, 스토리지 계정의 공용 IP 주소를 사용하여 클라이언트는 HTTP 요청을 실행합니다 stgworkload00.blob.core.windows.net.
2. 요청은 스토리지 계정의 공용 IP 주소로 전송됩니다. 이 요청은 여러 가지 이유로 실패합니다.
   • 워크로드 서브넷의 NSG는 이 인터넷 바인딩된 트래픽을 허용하지 않을 수 있습니다.
   • 인터넷 바인딩된 송신 트래픽을 필터링하는 Azure Firewall에는 이 흐름을 지원하는 애플리케이션 규칙이 없을 수 있습니다.
   • NSG와 Azure Firewall 모두 이 요청 흐름에 대한 허용량을 가지고 있더라도 스토리지 계정은 모든 공용 네트워크 액세스를 차단하도록 구성됩니다. 이 시도는 궁극적으로 프라이빗 엔드포인트를 통해서만 스토리지 계정에 대한 액세스를 허용하려는 목표를 위반합니다.

솔루션 - DNS에 대한 가상 허브 확장 설정

이 문제에 대한 해결 방법은 엔터프라이즈 네트워크 팀이 DNS에 대한 가상 허브 확장을 구현하는 것입니다. DNS 가상 허브 확장에 대한 단일 책임은 이 시작 Virtual WAN 허브 토폴로지 내에서 아키텍처에서 프라이빗 DNS 영역을 사용해야 하는 워크로드 팀을 사용하도록 설정하는 것입니다.

DNS 확장은 해당 지역 가상 허브에 피어되는 가상 네트워크 스포크로 구현됩니다. 프라이빗 DNS 영역을 이 가상 네트워크에 연결할 수 있습니다. 또한 가상 네트워크에는 Azure Firewall과 같은 이 가상 네트워크 외부의 서비스가 연결된 모든 프라이빗 DNS 영역에서 값을 쿼리하고 받을 수 있도록 하는 Azure DNS Private Resolver가 포함되어 있습니다. 다음은 몇 가지 필수 구성 변경 내용과 함께 DNS에 대한 일반적인 가상 허브 확장의 구성 요소입니다.

• 지역의 가상 허브와 피어되는 새 스포크 가상 네트워크입니다. 이 스포크는 다른 스포크처럼 구성됩니다. 즉, 기본 DNS 서버 및 라우팅 규칙은 지역 허브에서 Azure Firewall을 강제로 사용합니다.
• DNS Private Resolver 리소스는 스포크 가상 네트워크의 인바운드 엔드포인트와 함께 배포됩니다.
• 명명된 privatelink.blob.core.windows.net 프라이빗 DNS 영역 리소스가 만들어집니다.
  • 이 영역에는 A 스토리지 계정 FQDN 이름에서 스토리지 계정에 대한 프라이빗 엔드포인트의 개인 IP 주소로 매핑되는 레코드가 포함되어 있습니다.
  • 프라이빗 DNS 영역은 스포크 가상 네트워크에 연결됩니다.
  • RBAC(역할 기반 액세스 제어)가 허용하는 경우 자동 등록 또는 서비스 관리 항목을 사용하여 이러한 DNS 레코드를 기본 수 있습니다. 그렇지 않은 경우 수동으로 기본 수 있습니다.
• 지역 허브에서 Azure Firewall의 DNS 서버가 DNS 프라이빗 확인자의 인바운드 엔드포인트를 가리키도록 변경됩니다.

다음 다이어그램에서는 DNS 및 HTTP 흐름과 함께 아키텍처를 보여 줍니다.

그림 3: Private Link 및 DNS를 사용하는 Virtual WAN에 대한 단일 지역 시나리오에 대한 작업 솔루션

이 아키텍처의 Visio 파일을 다운로드합니다.

DNS에 대한 가상 허브 확장을 설정하기 위한 DNS 흐름

1. 클라이언트의 DNS 쿼리 stgworkload00.blob.core.windows.net 는 구성된 DNS 서버로 전송됩니다. 이 경우 피어된 지역 허브의 Azure Firewall인 10.100.0.132입니다.

   그림 4: 워크로드 가상 네트워크에 대한 DNS 서버 구성

2. 이 경우 Azure Firewall은 DNS Private Resolver의 인바운드 엔드포인트의 개인 IP 주소인 허브 확장 -10.200.1.4에서 지역 Azure DNS Private Resolver에 요청을 프록시합니다.

   

   DNS 프록시를 사용하도록 설정하고 DNS 서버를 사용자 지정으로 설정하는 Azure Firewall 정책의 스크린샷. 진입점은 DNS Private Resolver 입력 엔드포인트의 개인 IP 주소를 가리킵니다.

   그림 5: Azure Firewall 정책의 DNS 구성

3. DNS Private Resolver는 Azure DNS에 요청을 프록시합니다. 프라이빗 DNS 영역은 인바운드 엔드포인트가 포함된 가상 네트워크에 연결되므로 Azure DNS는 연결된 프라이빗 DNS 영역의 레코드를 사용할 수 있습니다.

   그림 6: 영역 가상 네트워크 링크 프라이빗 DNS

4. Azure DNS는 연결된 프라이빗 DNS 영역을 참조하고 스토리지 계정에 대한 프라이빗 엔드포인트의 stgworkload00.blob.core.windows.net IP 주소인 10.1.2.4의 FQDN을 확인합니다. 이 응답은 Azure Firewall DNS에 제공된 다음, 스토리지 계정의 개인 IP 주소를 클라이언트에 반환합니다.

   그림 7: 스토리지 계정 프라이빗 엔드포인트에 대한 A 레코드가 있는 프라이빗 DNS 영역

HTTP 흐름

1. DNS 결과, 스토리지 계정의 개인 IP 주소를 사용하여 클라이언트는 HTTP 요청을 실행합니다 stgworkload00.blob.core.windows.net.
2. 요청은 스토리지 계정의 개인 IP 주소(10.1.2.4)로 전송됩니다. 이 요청은 클라이언트 서브넷 또는 프라이빗 엔드포인트 서브넷의 로컬 네트워크 보안 그룹에 대해 충돌하는 제한이 없다고 가정하여 성공적으로 라우팅됩니다. Azure Firewall이 프라이빗 트래픽을 보호하더라도 프라이빗 엔드포인트가 클라이언트와 동일한 가상 네트워크에 있기 때문에 요청이 Azure Firewall을 통해 라우팅되지 않는다는 것을 이해하는 것이 중요합니다. 즉, 이 시나리오에 대해 Azure Firewall 허용량을 만들 필요가 없습니다.
3. 스토리지 계정에 대한 프라이빗 연결은 Private Link 서비스를 통해 설정됩니다. 스토리지 계정은 프라이빗 네트워크 액세스만 허용하고 HTTP 요청을 수락합니다.

DNS 고려 사항에 대한 가상 허브 확장

엔터프라이즈에 대한 확장을 구현할 때 다음 지침을 고려합니다.

• DNS 확장을 배포하는 작업은 워크로드 팀의 작업이 아닙니다. 이 작업은 엔터프라이즈 네트워킹 함수이며 해당 개인을 통해 결정된 구현 결정이어야 합니다.
• 프라이빗 엔드포인트 DNS 레코드를 구성하려는 PaaS 서비스를 추가하기 전에 DNS 확장 및 프라이빗 DNS 영역이 있어야 합니다.
• 가상 허브 확장은 지역별 리소스이며, 지역 간 트래픽을 방지하고, 프라이빗 엔드포인트 DNS 확인이 필요한 지역 허브당 허브 확장을 설정합니다.

스포크 가상 네트워크

• 단일 책임 원칙에 따라 DNS 확장에 대한 가상 네트워크에는 DNS 확인에 필요한 리소스만 포함되어야 하며 다른 리소스와 공유해서는 안 됩니다.
• DNS 확장에 대한 가상 네트워크는 스포크 네트워크 추가에서 동일한 구성 지침을 따라야 합니다.

Azure DNS Private Resolver

• 각 지역에는 하나의 DNS 프라이빗 확인자를 사용하여 하나의 가상 허브 DNS 확장이 있어야 합니다.

• DNS Private Resolver에는 인바운드 엔드포인트만 필요하고 이 시나리오에는 아웃바운드 엔드포인트가 필요하지 않습니다. 인바운드 엔드포인트의 개인 IP는 Azure Firewall 정책에서 사용자 지정 DNS 서비스에 대해 설정됩니다(그림 5 참조).

• 복원력이 향상되고 부하 처리가 증가하려면 지역당 여러 DNS Private Resolver 인스턴스를 배포할 수 있으며, Azure DNS 프록시는 프록시 확인을 위해 여러 IP 주소로 구성됩니다.

  그림 8: DNS 프라이빗 확인자의 인바운드 엔드포인트

• DNS Private Resolver에 대한 가상 네트워크 제한을 따릅니다.

• DNS Private Resolver의 인바운드 엔드포인트에 대한 서브넷의 네트워크 보안 그룹은 지역 허브에서 포트 53으로의 UDP 트래픽만 허용해야 합니다. 다른 모든 인바운드 및 아웃바운드 트래픽을 차단해야 합니다.

프라이빗 DNS 영역

Azure DNS 프라이빗 확인자는 Azure DNS를 통해 DNS를 확인하므로 Azure DNS는 인바운드 서브넷의 가상 네트워크에 연결된 모든 프라이빗 DNS 영역을 선택할 수 있습니다.

• 프라이빗 DNS 영역을 DNS 가상 네트워크의 가상 허브 확장에 연결합니다.
• 프라이빗 엔드포인트에 대한 프라이빗 DNS 영역 관리에 대한 지침을 따릅니다.
• PaaS 리소스 소유자가 자체 항목을 관리하도록 예상하는 경우 그에 따라 RBAC를 구성하거나 Private Link 및 DNS 통합과 같은 솔루션을 대규모로 구현합니다.

시나리오 고려 사항

잘 관리되는 가상 허브 DNS 확장을 사용하여 워크로드로 돌아가서 이 시나리오 내에서 성공적인 결과 목표를 달성하는 데 도움이 되는 몇 가지 추가 사항을 해결해 보겠습니다.

스토리지 계정

• 공용 네트워크 액세스 설정: 프라이빗 엔드포인트를 통해서만 스토리지 계정에 액세스할 수 있도록 네트워크 연결에서 사용하지 않도록 설정합니다.
• 워크로드의 가상 네트워크에서 전용 프라이빗 엔드포인트 서브넷에 프라이빗 엔드포인트를 추가합니다.
• 워크로드 Log Analytics 작업 영역에 Azure Diagnostics를 보냅니다. 액세스 로그를 사용하여 구성 문제를 해결할 수 있습니다.

프라이빗 엔드포인트 보안

이 솔루션의 요구 사항은 이 스토리지 계정의 노출을 제한하는 것입니다. PaaS 리소스에 대한 공용 인터넷 액세스를 제거하면 프라이빗 네트워킹 보안을 해결해야 합니다.

Azure Firewall이 Virtual WAN 허브-스포크 토폴로지에서 프라이빗 트래픽을 보호하는 경우 Azure Firewall은 기본적으로 스포크 간 연결을 거부합니다. 이 기본 설정은 다른 스포크 네트워크의 워크로드가 워크로드 가상 네트워크의 프라이빗 엔드포인트(및 기타 리소스)에 액세스하지 못하도록 합니다. 가상 네트워크 내의 트래픽은 Azure Firewall을 통해 라우팅되지 않습니다. 가상 네트워크 내에서 액세스를 제어하고 보다 세부적인 보호를 추가하려면 다음 NSG(네트워크 보안 그룹) 권장 사항을 고려합니다.

• ASG(애플리케이션 보안 그룹)를 만들어 인바운드 또는 아웃바운드 액세스 요구 사항이 비슷한 리소스를 그룹화합니다. 이 시나리오에서는 스토리지에 액세스해야 하는 클라이언트 VM에 ASG를 사용하고, 하나는 액세스되는 스토리지 계정에 사용합니다. 프라이빗 엔드포인트를 사용하여 ASG(애플리케이션 보안 그룹) 구성을 참조하세요.
• 워크로드 VM을 포함하는 서브넷에 NSG가 있는지 확인합니다.
• 프라이빗 엔드포인트를 포함하는 서브넷에 NSG가 있는지 확인합니다.

워크로드 VM을 포함하는 서브넷에 대한 NSG 규칙

워크로드에 필요한 다른 네트워크 규칙 외에도 다음 규칙을 구성합니다.

• 아웃바운드 규칙:
  • 컴퓨팅 ASG가 스토리지 계정 ASG에 액세스하도록 허용합니다.
  • 포트 53에서 UDP에 대한 지역 허브 Azure Firewall의 개인 IP에 컴퓨팅 ASG를 허용합니다.

*그림 9: 워크로드 서브넷에 대한 NSG 규칙

프라이빗 엔드포인트를 포함하는 서브넷에 대한 NSG 규칙

사용하는 가상 네트워크 내의 작은 전용 서브넷에 프라이빗 엔드포인트를 노출하는 것이 가장 좋은 사례로 간주됩니다. 한 가지 이유는 추가 트래픽 제어 및 보안을 위해 프라이빗 엔드포인트에 대해 사용자 정의 경로 및 네트워크 보안 그룹 네트워크 정책을 적용할 수 있기 때문입니다.

이 시나리오에서는 매우 제한적인 네트워크 보안 그룹을 적용할 수 있습니다.

• 인바운드 규칙:
  • 컴퓨팅 ASG가 스토리지 계정 ASG에 액세스하도록 허용
  • 다른 모든 트래픽 거부
• 아웃바운드 규칙:
  • 모든 트래픽 거부

*그림 10: 프라이빗 엔드포인트 서브넷에 대한 NSG 규칙

작동 중인 프라이빗 엔드포인트 보안

다음 이미지는 설명된 고려 사항을 따라 심층 방어 보안을 제공하는 방법을 보여 줍니다. 다이어그램은 두 번째 VM이 있는 두 번째 스포크 가상 네트워크를 보여줍니다. 해당 워크로드는 프라이빗 엔드포인트에 액세스할 수 없습니다.

그림 11: Private Link 및 DNS를 사용하는 Virtual WAN에 대한 단일 지역 시나리오에 대한 작업 솔루션

이 아키텍처의 Visio 파일을 다운로드합니다.

DNS 흐름

DNS 흐름은 솔루션 흐름과 정확히 동일합니다.

강조해야 할 중요한 점은 FQDN이 공용 IP 주소가 아닌 개인 IP 주소로 확인된다는 것입니다. 이 해결 방법은 모든 스포크에서 항상 이 서비스의 개인 IP 주소를 수신한다는 것을 의미합니다. 또 다른 시나리오에서는 이 방법을 사용하여 여러 사용 중인 워크로드에서 PaaS 서비스를 공유하는 방법을 설명합니다. 이 단일 워크로드 시나리오의 경우 이는 문제가 되지 않습니다.

HTTP 흐름

1. DNS 결과, 스토리지 계정의 개인 IP 주소를 사용하여 클라이언트는 HTTP 요청을 실행합니다 stgworkload00.blob.core.windows.net.
2. 요청은 스토리지 계정의 개인 IP 주소로 전송됩니다. 이 요청은 다음과 같은 여러 가지 이유로 적절하게 실패합니다.
   • Azure Firewall은 프라이빗 트래픽을 보호하도록 구성되므로 요청을 처리합니다. Azure Firewall에 흐름을 허용하는 네트워크 또는 애플리케이션 규칙이 없는 한 Azure Firewall은 요청을 차단합니다.
   • 프라이빗 트래픽을 보호하기 위해 허브에서 Azure Firewall을 사용할 필요가 없습니다. 예를 들어 네트워크에서 프라이빗 지역 간 트래픽을 지원하는 경우 프라이빗 엔드포인트 서브넷의 NSG는 워크로드를 호스트하는 가상 네트워크 내의 컴퓨팅 ASG 원본 이외의 모든 트래픽을 차단하도록 구성됩니다.

요약

이 문서에서는 VM 클라이언트가 스토리지 계정의 프라이빗 엔드포인트를 통해 Azure Storage 계정에 연결하는 시나리오를 소개합니다. 엔드포인트는 클라이언트와 동일한 가상 네트워크에 있습니다. 스토리지 계정에 대한 다른 모든 액세스가 차단됩니다. 이 시나리오에서는 스토리지 계정의 FQDN(정규화된 do기본 이름)을 프라이빗 엔드포인트의 개인 IP 주소로 다시 확인할 수 있는 DNS 흐름의 DNS 레코드가 필요합니다.

이 시나리오의 시작 네트워크 토폴로지 에서는 다음 두 가지 문제가 발생합니다.

• 스토리지 계정에 필요한 DNS 레코드와 프라이빗 DNS 영역을 가상 허브에 연결할 수 없습니다.
• 프라이빗 DNS 영역을 워크로드 서브넷에 연결하는 것은 작동하지 않습니다. 시작 네트워크 토폴로지에서는 기본 DNS 서버 및 라우팅 규칙이 지역 허브에서 Azure Firewall을 강제로 사용해야 합니다.

제안된 솔루션은 엔터프라이즈 네트워크 팀이 DNS에 대한 가상 허브 확장을 구현하는 것입니다. 이 확장을 통해 엔터프라이즈 네트워크 팀은 공유 DNS 서비스를 필요한 워크로드 스포크에 노출할 수 있습니다.

관련 참고 자료

• 프라이빗 엔드포인트란?
• Azure 프라이빗 엔드포인트 DNS 구성
• Private Link와 DNS의 대규모 통합
• 허브 및 스포크 네트워크의 Azure Private Link
• 온-프레미스 및 Azure 리소스에 대한 DNS
• 단일 지역 데이터 랜딩 존 연결
• Azure Private Link를 사용하여 네트워크를 Azure Monitor에 연결
• Azure DNS Private Resolver
• 온-프레미스 네트워크에서 다중 테넌트 웹앱에 대한 보안 액세스 향상
• 고가용성 영역 중복 웹 애플리케이션 기준
• 자습서: 온-프레미스 워크로드에 대한 Azure Private Resolver를 사용하여 프라이빗 엔드포인트 DNS 인프라 만들기