깡민쓰~IT Story

Azure Firewall을 사용하여 Spoke 간 통신하기

1. 테스트 아키텍처

2. Hub 대역 구성 

2.1 리소스 그룹 생성

2.2 가상 네트워크 생성

2.3 Azure Firewall 배포 

2.4 방화벽 규칙 생성

2.5 가상 머신 생성

2.6 Private DNS Zone 생성 

2.7 가상 네크워크 링크 생성 

3. Spoke 1 대역 구성 

3.1 리소스 그룹 생성

3.2 가상 네트워크 생성

3.3 Hub - Spoke 1 간 VNet Peering 

3.4 경로 테이블 생성

3.5 경로 테이블 구성 

3.6 가상 머신 생성  

3.7 가상 네크워크 링크 생성 

4. Spoke 2 대역 구성 

4.1 리소스 그룹 생성

4.2 가상 네트워크 생성

4.3 Hub - Spoke 2 간 VNet Peering 

4.4 경로 테이블 생성

4.5 경로 테이블 구성 

4.6 Azure Database for MySQL Flexible Server 생성

 4.7 가상 네크워크 링크 생성

 5. 통신 테스트 

5.1 Network Watcher를 통한 Next Hop 확인 

5.2 Azure Firewall 진단 설정을 통한 방화벽 규칙 적용 확인

5.3 Spoke 1 대역 VM → Spoke 2 대역 MySQL Server 접근 테스트

1. 테스트 아키텍처

 
Spoke 1 대역의 VM에서 Azure Firewall을 거쳐 Spoke 2 대역의 MySQL Flexible Server에 접근할 수 있도록 Azure 환경을 구성하는 것이 이번 주제의 목표입니다.
 
2. Hub 대역 구성 
2.1 리소스 그룹 생성

리소스 그룹 : rg-hub-test # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역 [리소스 그룹]을 생성합니다. 

 
2.2 가상 네트워크 생성

리소스 그룹 : rg-hub-test 가상 네트워크 이름 : vnet-hub-test # hub용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

주소 공간 : 10.10.0.0/24 # 가상 네트워크 대역 입력서브넷 : AzureFirewallSubnet, snet-vm 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역의 [가상 네트워크]를 생성합니다.

 
2.3 Azure Firewall 배포 
1. [가상 머신]과 Azure Database for MySQL - Flexible Server이 3306 포트를 통해 통신할 수 있도록 규칙 추가 필요2. 방화벽 규칙은 Firewall Manager을 통해 관리됨 

[기본 사항] 탭




리소스 그룹 : rg-hub-test이름 : fw-test방화벽 SKU : 표준Firewall policy : fw-policy-test # [Add new] 버튼을 클릭하여 새로운 policy 생성가상 네트워크 선택 # 기존 항목 사용가상 네트워크 : vnet-hub-test # AzureFirewallSubnet이 있는 Hub 네트워크 선택공용 IP 주소 : pip-fw-test # [새로 추가] 버튼을 클릭하여 새로운 공용 IP 생성
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역에 [방화벽]을 생성합니다.

 
2.4 방화벽 규칙 생성

[방화벽] > [개요] 




[설정] > [네트워크 규칙] > [+ 규칙 컬렉션 추가]

1. [규칙]의 상위 개념인 [규칙 컬렉션]을 먼저 생성하여야 합니다.([규칙 컬렉션]을 생성하지 않은 상태로 [+ Add rule]을 클릭하여 [규칙]을 생성할 수 없습니다.)2. 가장 상위 개념인 [규칙 컬렉션 그룹]의 경우, 기본값을 사용하거나 [설정] > [규칙 컬렉션] 탭에서 [+ Add] > [Rule collection group]을 클릭하여 신규로 생성할 수 있습니다.cf) 기본값은 다음과 같이 3개가 존재합니다.(DefaultDnatRuleCollectionGroup, DefaultNetworkRuleCollectionGroup, DefaultApplicationRuleCollectionGroup)3. [규칙 컬렉션 그룹], [규칙 컬렉션]은 모두 우선 순위를 가지며 [규칙]은 상위 개념들의 우선 순위를 따라갑니다.



[규칙 컬렉션] 및 [규칙]을 추가합니다.



이름 : rule-collection-nw # 규칙 컬렉션 이름 입력규칙 컬렉션 형식 : 네트워크 우선 순위 : 100 # 같은 [규칙 컬렉션] 내에서의 우선 순위를 의미함규칙 추가1. spoke1 대역에서 spoke 2 대역의 MySQL Flexible Server에 접근하기 위한 3306 포트 open(원본 : Spoke 1 대역, 대상 : Spoke 2 대역)2. spoke2 대역에서 spoke 1 대역으로 응답 보낼 수 있도록 하기 위한 3306 포트 open(원본 : Spoke 2 대역, 대상 : Spoke 1 대역)
 

[추가]를 클릭하여 [규칙 컬렉션] 및 [규칙]을 생성합니다.

 
2.5 가상 머신 생성
Spoke 1 대역에 배포될 가상 머신에 접근하거나 Azure Portal에 로그인하여 Private하게 구성된 리소스들을 조회하기 위한 VM을 생성합니다.

[기본 사항] 탭




리소스 그룹 : rg-hub-test # Hub 대역 리소스 그룹 선택가상 머신 이름 : vm-bastion-test   이미지 : Windows 11 Pro, version 22H2 - X64 Gen2 크기 : Standard_D4s_v5 - 4 vcpu, 16 GiB 메모리관리자 계정- 사용자 이름 : azureuser # 원하는 이름 사용- 암호인바운드 포트 선택 : RDP (3389)라이선싱 : 체크 박스 클릭
 

[네트워킹] 탭



가상 네트워크 : vnet-hub-test 선택서브넷 : snet-vm 선택공용 IP : pip-vm-bastion # [새로 만들기] 클릭하여 원하는 이름 입력
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역의 bastion용 [가상 머신]을 생성합니다.

 
2.6 Private DNS Zone 생성 
Spoke 2 대역에 배포될 Azure Database for MySQL Flexible Server (VNet Integration)를 Private DNS Zone과 통합하기 위하여 Hub 대역에 Private DNS Zone(private.mysql.database.azure.com)을 생성합니다. 

[기본 사항] 탭



리소스 그룹 : rg-hub-test 선택이름 : private.mysql.database.azure.com 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Hub 대역에 [Private DNS Zone]을 생성합니다.

 
2.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-hub # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-hub-test # Hub 대역의 가상 네트워크 선택
 
3. Spoke 1 대역 구성 
3.1 리소스 그룹 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-01 # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[태그] 탭




[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [리소스 그룹]을 생성합니다.

 
3.2 가상 네트워크 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-01가상 네트워크 이름 : vnet-spoke-01 # spoke 1용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

[IP 주소] 탭



주소 공간 : 10.20.0.0/26 # 가상 네트워크 대역 입력서브넷 : snet-vm 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [가상 네트워크]를 생성합니다.

 
3.3 Hub - Spoke 1 간 VNet Peering 

vnet-spoke-01 > [설정] > [피어링] > [+ 추가]




Hub - Spoke 1 간 VNet Peering을 구성합니다.  




[추가] 버튼을 클릭하여 VNet Peering을 생성합니다. 



 
3.4 경로 테이블 생성
Spoke 1 VNet에서 Hub의 Azure Firewall을 통해 Spoke 2 VNet 내 Azure Database for MySQL - Flexible Server에 접근할 수 있도록 사용자 지정 경로를 생성 및 구성합니다. 

[기본] 탭



리소스 그룹 : rg-spoke-test-01 이름 : rt-spoke-01게이트웨이 경로 전파 : No # VPN 게이트웨이를 통해 온-프레미스 네트워크에 연결된 가상 네트워크의 서브넷에 경로 테이블을 연결하고 온-프레미스 경로를 서브넷의 네트워크 인터페이스에 전파하지 않으려는 경우 No 옵션 선택 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [경로 테이블]을 생성합니다. 

 
3.5 경로 테이블 구성 

경로 구성

rt-spoke-01 > [설정] > [경로] > [+ 추가]





경로 이름 : To-Spoke2 # Spoke 2 대역으로 가기 위해 사용자 지정 경로(UDR) 생성대상 IP 주소/CIDR 범위 : 10.30.0.0/24 # Spoke 2 대역 IP 주소 입력다음 홉 형식 : 가상 어플라이언스 # 방화벽을 거쳐서 Spoke 2 대역으로 이동다음 홉 주소 : # Azure Firewall의 Private IP 주소 입력
 

[추가] 버튼을 클릭하여 사용자 지정 경로를 생성합니다. 
서브넷 연결

rt-spoke-01 > [설정] > [서브넷] > [+ 연결]





가상 네트워크 : vnet-spoke-01 # spoke 1 대역의 VNet 선택서브넷 : snet-vm # 경로 테이블과 연결할 subnet 선택
 
3.6 가상 머신 생성  
Spoke 2 대역에 배포될 Azure Database for MySQL Flexible Server에 접근하기 위한 client VM을 생성합니다. 

[기본 사항] 탭




리소스 그룹 : rg-spoke-test-01 # Spoke 1 대역 리소스 그룹 선택가상 머신 이름 : vm-client-test   이미지 : Ubuntu Server 20.04 LTS - x64 Gen2크기 : Standard_D4s_v5 - 4 vcpu, 16 GiB 메모리관리자 계정- 인증 형식 : 암호- 사용자 이름 : azureuser # 원하는 이름 사용- 암호인바운드 포트 선택 : SSH (22)
 

[네트워킹] 탭



가상 네트워크 : vnet-spoke-01 선택서브넷 : snet-vm 선택공용 IP : 없음 # Hub 대역에 배포한 [가상 머신]을 통해 접속할 것이므로 공용 IP 불필요 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 1 대역의 [가상 머신]을 생성합니다. 

 
3.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-spoke-01 # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-spoke-01 # Spoke 1 대역의 가상 네트워크 선택
 
4. Spoke 2 대역 구성 
4.1 리소스 그룹 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-02 # 원하는 리소스 그룹 이름 입력영역 : (Asia Pachific) Korea Central 
 

[태그] 탭




[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [리소스 그룹]을 생성합니다. 

 
4.2 가상 네트워크 생성

[기본] 탭



리소스 그룹 : rg-spoke-test-02가상 네트워크 이름 : vnet-spoke-02 # spoke 2용 가상 네트워크 이름 입력영역 : (Asia Pachific) Korea Central 
 

[IP 주소] 탭



주소 공간 : 10.30.0.0/24 # 가상 네트워크 대역 입력서브넷 : snet-mysql-delegated 추가 # [+ 서브넷 추가] 버튼을 클릭하여 주소 범위와 크기 입력 프라이빗 서브넷 사용 : 체크 X # 위임된 서브넷의 경우 DefaultOutboundConnectivity를 false로 설정해서는 안 됨 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [가상 네트워크]를 생성합니다.

 
4.3 Hub - Spoke 2 간 VNet Peering 

vnet-spoke-02 > [설정] > [피어링] > [+ 추가]




Hub - Spoke 2 간 VNet Peering을 구성합니다.  




[추가] 버튼을 클릭하여 VNet Peering을 생성합니다. 



 
4.4 경로 테이블 생성
Spoke 1 대역의 가상 머신이 Azure Database for MySQL - Flexible Server에 접근할 때와 동일한 루트로 통신할 수 있도록 사용자 지정 경로를 구성합니다. 

[기본] 탭



리소스 그룹 : rg-spoke-test-02 이름 : rt-spoke-02게이트웨이 경로 전파 : No # VPN 게이트웨이를 통해 온-프레미스 네트워크에 연결된 가상 네트워크의 서브넷에 경로 테이블을 연결하고 온-프레미스 경로를 서브넷의 네트워크 인터페이스에 전파하지 않으려는 경우 No 옵션 선택 
 

[검토 + 만들기] 탭에서 [만들기]를 클릭하여 Spoke 2 대역의 [경로 테이블]을 생성합니다. 

 
4.5 경로 테이블 구성 

경로 구성

rt-spoke-02 > [설정] > [경로] > [+ 추가]





경로 이름 : To-Spoke1 # Spoke 1 대역으로 가기 위해 사용자 지정 경로(UDR) 생성대상 IP 주소/CIDR 범위 : 10.20.0.0/26 # Spoke 1 대역 IP 주소 입력다음 홉 형식 : 가상 어플라이언스 # 방화벽을 거쳐서 Spoke 1 대역으로 이동다음 홉 주소 : # Azure Firewall의 Private IP 주소 입력
 

[추가] 버튼을 클릭하여 사용자 지정 경로를 생성합니다. 
서브넷 연결

rt-spoke-02 > [설정] > [서브넷] > [+ 연결]





가상 네트워크 : vnet-spoke-02 # spoke 2 대역의 VNet 선택서브넷 : snet-mysql-delegated # 경로 테이블과 연결할 subnet 선택
 
4.6 Azure Database for MySQL Flexible Server 생성 
VNet Integration?- 가상 네트워크 인프라를 통해서만 서버에 대해 액세스할 수 있도록 합니다. - Azure Database for MySQL - Flexible Server 전용으로 위임된 서브넷이 필요합니다. - 단일 VNet 또는 여러 VNet에 포함될 수 있습니다. 

[기본] 탭




리소스 그룹 : rg-spoke-test-02 # spoke 2 대역의 리소스 그룹 선택서버 이름 : db-mysql-flexible-test MySQL 버전 : 8.0 # 기본값 유지인증 방법 : MySQL 인증만- 관리자 사용자 이름 : sqladmin # 원하는 사용자 이름 입력- 암호
 

[네트워킹] 탭




네트워크 연결 - 연결 방법 : 프라이빗 액세스(VNet 통합)가상 네트워크 : vnet-spoke-02 # Azure Database for MySQL Flexible Server가 생성될 VNet 선택서브넷 : # 위임될 subnet 선택프라이빗 DNS 통합- 구독 : # Hub 대역이 있는 구독 선택- 프라이빗 DNS 영역 : # 기 생성한 프라이빗 DNS 영역 선택
 
4.7 가상 네크워크 링크 생성 

[설정] > [가상 네트워크 링크] > [+ 추가]



링크 이름 : vnet-link-spoke-02 # 원하는 가상 네트워크 링크 이름 입력가상 네트워크 : vnet-spoke-02 # Spoke 1 대역의 가상 네트워크 선택
 
5. 통신 테스트 
5.1 Network Watcher를 통한 Next Hop 확인 

[Network Watcher] > [네트워크 진단 도구] > [다음 홉] 



리소스 그룹 : rg-spoke-test-01 # Client용 가상 머신이 있는 Spoke 1 대역의 리소스 그룹 선택가상 머신 : vm-client-test 선택대상 IP 주소 : 10.30.0.4 # Azure Database for MySQL Flexible Server의 IP 주소 입력
 

[다음 홉] 버튼을 클릭하여 조회 시 [다음 홉 형식]은 VirtualAppliance, IP 주소는 방화벽의 Private IP 주소가 출력되는 것을 확인할 수 있습니다. 

 
5.2 Azure Firewall 진단 설정을 통한 방화벽 규칙 적용 확인

[방화벽] > [모니터링] > [진단 설정] > [+ 진단 설정 추가]




[진단 설정] 구성



진단 설정 이름 : Diagnostics-Setting-FW # 원하는 진단 설정 이름 입력범주 : Azure Firewall Network Rule # 현재 방화벽에 Network 규칙만 있으므로 관련된 범주만 선택대상 세부 정보- 스토리지 계정에 보관 # 방화벽 규칙에 의해 트래픽이 허용/거부되는지 확인을 위해 스토리지 계정에 로그 적재스토리지 계정 : # 없는 경우 먼저 생성 필요
 

[스토리지 계정] > [데이터 스토리지] > [컨테이너] > [insights-logs-azurefirewall] 컨테이너 클릭




조회하고자 하는 로그 파일을 다운로드합니다.



경로 : resourceId=/SUBSCRIPTIONS/{구독 id}/RESOURCEGROUPS/{Resource Group 명}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{Firewall 명}/년/월/일/시/분/PT1H.json
 

로그 세부 내용 확인



Action : 해당 트래픽의 허용 여부 Policy : 어떤 방화벽 정책을 사용하는지 RuleCollectionGroup : 트래픽을 허용/거부하는 [규칙]이 어떤 [규칙 컬렉션 그룹]에 속해 있는지RuleCollection : 트래픽을 허용/거부하는 [규칙]이 어떤 [규칙 컬렉션]에 속해 있는지Rule : 어떤 [규칙]에 의해 트래픽이 허용/거부되는지 
※ 방화벽 테스트를 위해 Spoke 2 대역에 [가상 머신]을 추가로 생성하였습니다. 
 
5.3 Spoke 1 대역 VM → Spoke 2 대역 MySQL Server 접근 테스트

Hub 대역의 Bastion용 [가상 머신]에 접속합니다. 




Spoke 1 대역의 Client용 [가상 머신]에 접속합니다. 




Spoke 2 대역의 MySQL Flexible Server 접근을 위한 MySQL Client를 설치합니다. (명령어 하기 박스 참고)

1. sudo apt-get update2. sudo apt-get install mysql-client (Y 입력)3. mysql -V # 입력 시 mysql Ver 8.0.35-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu)) 출력 

Azure Database for MySQL Flexible Server 접근 

[Azure Database for MySQL Flexible Server] > [설정] > [연결] > [브라우저에서 또는 로컬에서 연결] 클릭 후 명령어를 복사합니다. 






Spoke 1 대역의 [가상 머신]에서 해당 명령어를 입력하여 정상 접근을 확인합니다. 



 

RG
● Region

vNet
●  RG
●  Region
●  IP address prefixes
●  subnet

Subnet
●  IP address prefixes
●  NAT gateway

NIC
●  RG
●  vNet
●  Subnet
●  NSG

프라이빗 엔드포인트는 가상 네트워크의 개인 IP 주소를 사용하는 네트워크 인터페이스입니다. 프라이빗 엔드포인트는 Azure Private Link에서 제공하는 서비스에 비공개로 안전하게 연결합니다. 프라이빗 엔드포인트를 사용하도록 설정하면 서비스를 가상 네트워크로 가져올 수 있습니다.

서비스는 다음과 같은 Azure 서비스일 수 있습니다.

• Azure Storage
• Azure Cosmos DB
• Azure SQL Database
• Private Link 서비스를 사용하는 자체 서비스입니다.

프라이빗 엔드포인트는 다음 속성을 지정합니다.

프라이빗 엔드포인트를 만들 때 다음을 고려합니다.

• 프라이빗 엔드포인트를 사용하면 동일한 고객 간에 연결이 가능합니다.
  • 가상 네트워크
  • 지역적으로 피어링된 가상 네트워크
  • 전역적으로 피어링된 가상 네트워크
  • VPN 또는 Express Route를 사용하는 온-프레미스 환경
  • Private Link에서 제공하는 서비스
• 네트워크 연결은 프라이빗 엔드포인트에 연결하는 클라이언트에서만 시작할 수 있습니다. 서비스 공급자는 서비스 고객에 대한 연결을 만들기 위한 라우팅 구성이 없습니다. 연결은 단일 방향으로만 설정할 수 있습니다.
• 프라이빗 엔드포인트의 수명 주기에 대해 읽기 전용 네트워크 인터페이스가 자동으로 만들어집니다. 이 인터페이스에는 프라이빗 링크 리소스에 매핑되는 서브넷의 동적 개인 IP 주소가 할당됩니다. 프라이빗 IP 주소의 값은 프라이빗 엔드포인트의 전체 수명 주기 동안 변경되지 않고 유지됩니다.
• 프라이빗 엔드포인트는 가상 네트워크와 동일한 지역 및 구독에 배포되어야 합니다.
• 프라이빗 링크 리소스는 가상 네트워크 및 프라이빗 엔드포인트의 지역이 아닌 다른 지역에 배포할 수 있습니다.
• 동일한 프라이빗 링크 리소스를 사용하여 여러 프라이빗 엔드포인트를 만들 수 있습니다. 일반적인 DNS 서버 구성을 사용하는 단일 네트워크의 경우 지정된 프라이빗 링크 리소스에 단일 프라이빗 엔드포인트를 사용하는 것이 좋습니다. DNS 확인 시 중복 항목 또는 충돌을 방지하려면 이 방법을 사용합니다.
• 동일한 가상 네트워크 내에서 동일하거나 다른 서브넷에 여러 프라이빗 엔드포인트를 만들 수 있습니다. 하나의 구독에서 만들 수 있는 프라이빗 엔드포인트 수는 제한됩니다. 자세한 내용은 Azure 제한을 참조하세요.
• 프라이빗 링크 리소스를 포함하는 구독은 Micosoft 네트워크 리소스 공급자에 등록해야 합니다. 프라이빗 엔드포인트를 포함하는 구독은 Micosoft 네트워크 리소스 공급자에도 등록해야 합니다. 자세한 내용은 Azure Resource Providers를 참조하세요.

프라이빗 링크 리소스는 지정된 프라이빗 엔드포인트의 대상입니다. 다음 표에는 프라이빗 엔드포인트를 지원하는 사용 가능한 리소스를 나와 있습니다.

프라이빗 엔드포인트를 사용하는 경우 트래픽은 프라이빗 링크 리소스로 보호됩니다. 플랫폼은 네트워크 연결의 유효성을 검사하여 지정된 프라이빗 링크 리소스에 도달하는 연결만 허용합니다. 동일한 Azure 서비스 내에서 더 많은 하위 리소스에 액세스하려면 해당 대상이 있는 더 많은 프라이빗 엔드포인트가 필요합니다. 예를 들어 Azure Storage 경우 파일 및 blob 하위 리소스에 액세스하려면 별도의 프라이빗 엔드포인트가 필요합니다.

프라이빗 엔드포인트는 Azure 서비스에 비공개로 액세스할 수 있는 IP 주소를 제공하지만 공용 네트워크 액세스를 반드시 제한하지는 않습니다. 그러나 다른 모든 Azure 서비스에는 추가 액세스 제어가 필요합니다. 이러한 컨트롤은 리소스에 추가 네트워크 보안 계층을 제공하여 프라이빗 링크 리소스와 연결된 Azure 서비스에 대한 액세스를 방지하는 데 도움이 되는 보호를 제공합니다.

프라이빗 엔드포인트는 네트워크 정책을 지원합니다. 네트워크 정책을 사용하면 NSG(네트워크 보안 그룹), UDR(사용자 정의 경로) 및 ASG(애플리케이션 보안 그룹)를 지원할 수 있습니다. 프라이빗 엔드포인트에 대한 네트워크 정책을 사용하도록 설정하는 방법에 대한 자세한 내용은 프라이빗 엔드포인트에 대한 네트워크 정책 관리를 참조하세요. 프라이빗 엔드포인트에서 ASG를 사용하려면 프라이빗 엔드포인트를 사용하여 ASG(애플리케이션 보안 그룹) 구성을 참조하세요.

다음 연결 승인 방법을 사용하여 프라이빗 링크 리소스에 연결할 수 있습니다.

• 자동 승인: 사용자가 특정 프라이빗 링크 리소스를 소유하거나 권한이 있는 경우 이 방법을 사용합니다. 필요한 권한은 다음 형식의 프라이빗 링크 리소스 종류를 기준으로 합니다.
• Microsoft.<Provider>/<resource_type>/privateEndpointConnectionsApproval/action
• 수동 요청: 필요한 사용 권한이 없고 액세스를 요청하려는 경우 이 방법을 사용합니다. 승인 워크플로가 시작됩니다. 프라이빗 엔드포인트와 이후의 프라이빗 엔드포인트 연결은 보류 중 상태로 만들어집니다. Private Link 리소스 소유자가 연결을 승인해야 합니다. 승인된 후 다음 승인 워크플로 다이어그램에 표시된 것처럼 프라이빗 엔드포인트가 트래픽을 정상적으로 보낼 수 있습니다.

프라이빗 엔드포인트 연결을 통해 프라이빗 링크 리소스 소유자는 다음을 수행할 수 있습니다.

• 모든 프라이빗 엔드포인트 연결 세부 정보를 검토합니다.
• 프라이빗 엔드포인트 연결을 승인합니다. 해당 프라이빗 엔드포인트는 트래픽을 프라이빗 링크 리소스로 보낼 수 있도록 사용하도록 설정됩니다.
• 프라이빗 엔드포인트 연결을 거부합니다. 해당 프라이빗 엔드포인트는 상태를 반영하도록 업데이트됩니다.
• 모든 상태의 프라이빗 엔드포인트 연결을 삭제합니다. 해당 프라이빗 엔드포인트는 작업을 반영하기 위해 연결이 끊긴 상태로 업데이트됩니다. 프라이빗 엔드포인트 소유자는 이 시점에서만 리소스를 삭제할 수 있습니다.

별칭은 서비스 소유자가 표준 부하 분산 장치 뒤에 프라이빗 링크 서비스를 만들 때 생성되는 고유한 모니커입니다. 서비스 소유자는 이 별칭을 서비스 소비자와 오프라인으로 공유할 수 있습니다.

소비자는 리소스 URI 또는 별칭을 사용하여 프라이빗 링크 서비스에 대한 연결을 요청할 수 있습니다. 별칭을 사용하여 연결하려면 수동 연결 승인 방법을 사용하여 프라이빗 엔드포인트를 만듭니다. 수동 연결 승인 방법을 사용하려면 프라이빗 엔드포인트 만들기 흐름에서 수동 요청 매개 변수를 True로 설정합니다. 자세한 내용은 New-AzPrivateEndpoint 및 az network private-endpoint create를 참조하세요.

프라이빗 링크 리소스에 연결하는 데 사용하는 DNS 설정이 중요합니다. 기존 Azure 서비스에는 공용 엔드포인트를 통해 연결할 때 사용할 DNS 구성이 이미 있을 수 있습니다. 프라이빗 엔드포인트를 통해 동일한 서비스에 연결하려면 프라이빗 DNS 영역을 통해 구성되는 별도의 DNS 설정이 필요합니다. 연결에 FQDN(정규화된 도메인 이름)을 사용하는 경우 DNS 설정이 올바른지 확인합니다. 프라이빗 엔드포인트의 개인 IP 주소를 확인하려면 DNS 구성을 변경합니다.

프라이빗 엔드포인트와 연결된 네트워크 인터페이스에는 DNS를 구성하는 데 필요한 정보가 포함되어 있습니다. 이 정보에는 프라이빗 링크 리소스에 대한 FQDN 및 개인 IP 주소가 포함됩니다.

프라이빗 엔드포인트에 대한 DNS 구성 권장 사항에 대한 자세한 내용은 프라이빗 엔드포인트 DNS 구성을 참조하세요.

다음 정보에는 프라이빗 엔드포인트 사용에 대한 알려진 제한 사항이 나와 있습니다.

• 프라이빗 엔드포인트에서 거부된 아웃바운드 트래픽은 서비스 공급자가 트래픽을 생성할 수 없기 때문에 유효한 시나리오가 아닙니다.
• 다음 서비스는 프라이빗 엔드포인트를 사용하고 NSG 보안 필터를 추가할 때 모든 대상 포트를 열어야 할 수 있습니다.
  • Azure Cosmos DB - 자세한 내용은 서비스 포트 범위를 참조하세요.

• 프라이빗 엔드포인트 및 Private Link에 대한 자세한 내용은 Azure Private Link란?을 참조하세요.
• 웹앱에 대한 프라이빗 엔드포인트 만들기를 시작하려면 빠른 시작: Azure Portal을 사용하여 프라이빗 엔드포인트 만들기를 참조하세요.

다음은 Azure에 Palo Alto의 VM-Series Virtual Appliance를 배포하면서 얻은 몇 가지 반작용을 요약한 것입니다. 이것은 가이드라기보다는 내가 취한 단계를 반영한 것이지만 아래 정보를 적절하다고 생각되는 대로 사용할 수 있습니다. 개략적으로 Azure에 디바이스를 배포한 다음, Azure의 VNet(Virtual Network)에서 트래픽을 적절하게 라우팅할 수 있도록 Palo Alto의 내부 "내장"을 구성해야 합니다. 설명된 단계는 Palo Alto VM-Series 어플라이언스의 8.0 및 8.1 버전 모두에 적용되어야 합니다.

또한 이 자습서에서는 스케일 아웃 아키텍처를 배포하려고 한다고 가정합니다. 이렇게 하면 단일 인스턴스가 푸시하려는 대역폭의 양에 압도되지 않도록 할 수 있습니다. 단일 인스턴스를 찾고 있는 경우에도 계속 따라갈 수 있습니다.

Azure에서 어플라이언스 배포Deploy the appliance in Azure

Virtual Palo Altos를 배포할 때 설명서에서는 Azure Marketplace(https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=Overview 에서 찾을 수 있음)를 통해 만드는 것을 권장합니다. 개인적으로, 나는 명명 규칙에 대한 많은 통제력이 없고, 규모를 위해 둘 이상의 어플라이언스를 배포 할 수 없으며, 가용성 집합을 지정할 수 없으며, 관리 디스크를 활용할 수 없기 때문에 이러한 방식으로 어플라이언스를 배포하는 것을 좋아하지 않습니다. 또한 31자보다 큰 암호를 지정하면 Palo Alto 디바이스가 Azure에 배포되지 않는다는 정말 이상한 오류를 발견했습니다. 이 경우 관리 디스크, 가용성 집합, 일관된 명명법, 적절한 VM 크기 조정을 활용하고 가장 중요한 것은 크기 조정을 위해 배포하려는 가상 인스턴스의 수를 정의할 수 있는 사용자 지정 ARM 템플릿을 작성했습니다.

참고: 이 문서에서는 Panorama를 사용하는 개념을 다루지 않지만, "단일 창"에서 각 스케일 아웃 인스턴스를 중앙에서 관리합니다. 아래에서는 노드를 수동으로 설정하여 작동시키는 방법에 대해 설명합니다. ARM 템플릿 배포 시 노드를 부트스트랩하기 위해 배포 후 Panorama에 조인하는 기본 구성 파일을 생성할 수 있습니다. 부트 스트랩 파일은이 템플릿에 통합 한 것이 아니지만 템플릿을 쉽게 수정할 수 있습니다.

위에서 언급했듯이 이 기사에서는 Palo Alto가 공유 디자인 모델로 간주하는 것을 다룹니다. 다음은 시각적으로 표시되는 것의 예입니다(이 문서 하단의 메모 섹션에 나열된 Palo Alto의 참조 아키텍처 문서에서 발췌).

Palo Alto의 Reference Architecture에 따른 공유 설계 모델

Microsoft에는 가상 어플라이언스 배포를 설명하는 참조 아키텍처 문서도 있으며, 이 문서는 다음에서 찾을 수 있습니다 https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha

아래는 내가 사용하는 ARM 템플릿에 대한 링크입니다.

PaloAlto-HA.json

이 템플릿의 배포는 Azure Portal(portal.azure.com)로 이동하고, 리소스 만들기를 선택하고, Azure Marketplace에서 템플릿 배포를 입력하고, 만들기를 클릭하고, 편집기에서 고유한 템플릿 빌드를 선택하고, 코드를 편집기에 붙여넣어 수행할 수 있습니다.

또는 여기에서 이 버튼을 클릭할 수 있습니다.

다음은 템플릿에서 매개 변수가 의미하는 바에 대한 몇 가지 참고 사항입니다.

VM 크기: Palo Alto에 따라 권장되는 VM 크기는 DS3, DS4 또는 DS5여야 합니다. 이에 대한 설명서는 여기에서 찾을 수 있습니다.

PASku: 여기에서 Bring-Your-Own-License 또는 종량제 사용을 선택할 수 있습니다. 계획은 여기에 요약되어 있습니다 : https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=PlansAndPrice

PAVersion: 배포할 PanOS의 버전입니다.

PACount: 부하 분산 장치 뒤에 배포하고 배치하려는 가상 인스턴스의 수를 정의합니다.

VNetName: 만든 가상 네트워크의 이름입니다.

VNetRG: 가상 네트워크가 있는 리소스 그룹의 이름입니다. 이는 Palos를 배치하는 리소스 그룹과 동일할 수 있지만, 다른 리소스 그룹의 VNet을 참조하는 오류를 방지하기 위해 구성 가능한 필수 옵션입니다.

envPrefix: 생성되는 모든 리소스(로드 밸런서, 가상 머신, 공용 IP, NIC 등)는 이 명명 명명법을 사용합니다.

manPrivateIPPrefix, trustPrivateIPPrefix, untrustPrivateIPPrefix: 해당 서브넷 주소 범위입니다. 이는 범위의 처음 3옥텟 뒤에 마침표가 와야 합니다. 예: 10.5.6. 가 유효한 값입니다.

manPrivateIPFirst, trustPrivateIPFirst, untrustPrivateIPFirst: 지정된 서브넷에서 사용 가능한 첫 번째 IP 주소입니다. 예를 들어 서브넷이 10.4.255.0/24인 경우 첫 번째 사용 가능한 주소로 4를 지정해야 합니다.

사용자 이름: PanOS 웹 포털에 ssh 및 로그인하는 데 사용해야 하는 권한 있는 계정의 이름입니다.

* 암호: PanOS 웹 포털에 ssh 및 로그인하는 데 사용되는 권한 있는 계정의 암호입니다. Pan OS 제한으로 인해 31자 이하여야 합니다.

어플라이언스 구성

가상 어플라이언스가 배포되면 Trust/Untrust 인터페이스에서 연결을 활성화하도록 Palo Alto 디바이스 자체를 구성해야 합니다.

VM-Series 방화벽에서 라이센스를 활성화합니다.

BYOL 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. VM-Series 방화벽
   (인증 코드 포함)을 등록합니다.
3. 방화벽 웹 인터페이스에서 Device(디바이스) 탭 -> Licenses(라이선스)
   를 선택하고 Activate feature using authentication code(인증 코드를 사용하여 기능 활성화)를 선택합니다.
4. 지원
   포털에 등록한 용량 인증 코드를 입력합니다. 방화벽이 업데이트 서버(updates.paloaltonetworks.com)에 연결되고 라이센스가 다운로드
   되고 자동으로 재부팅됩니다. 그래도 문제가 해결되지 않으면 아래에서 장치의 인터페이스 구성을 계속하십시오.
5. 재부팅 후 웹 인터페이스에 다시 로그인하고 대시보드에서 다음을 확인합니다.
   1. 유효한 일련 번호가 Serial#에 표시됩니다.
      알 수 없음이라는 용어가 표시되면 장치에 라이선스가 부여되지 않았음을 의미합니다. 방화벽에서 트래픽 로그를 보려면
      유효한 용량 라이선스를 설치해야 합니다.
   2. VM 모드가 Microsoft Azure로 표시됩니다.

PAYG(Pay as you go) 버전을 사용하는 경우 다음 단계를 수행합니다

1. 지원 계정을 만듭니다.
2. AWS 및 Azure에서 VM 시리즈 방화벽
   의 사용량 기반 모델을 등록합니다(인증 코드 없음).

Untrust/Trust 인터페이스 구성

신뢰할 수 없는 인터페이스 구성

1. Network-> Interfaces ->Ethernet->를 선택하고 ethernet1/1에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 인터페이스를 Untrust-VR 라우터에 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Untrust(신뢰할 수 없음)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. 참고: 가상 머신에 공용 IP 주소를 사용하지 마십시오. Azure는 트래픽을 개인 주소로 자동으로 DNAT하므로 UnTrust 인터페이스에 개인 IP 주소를 사용해야 합니다.
3. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
   1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
4. 확인을 클릭합니다.

참고: 신뢰할 수 없는 인터페이스의 경우 템플릿이 배포하지 않으므로 Azure 환경 내에서 신뢰할 수 없는 서브넷 또는 개별 방화벽 인터페이스에 연결된 NSG가 있는지 확인합니다(추가할 수 있지만 이미 NSG가 있는 경우 덮어쓰지 않으려고 합니다). Azure Load Balancer의 설명서에 따라 인터넷에서 들어오는 트래픽을 허용하려면 NIC 또는 서브넷에 연결된 NSG가 필요합니다.

트러스트 인터페이스 구성

1. Network-> Interfaces ->Ethernet->을 선택하고 ethernet1/2에 대한 링크를 선택한 후 다음과 같이 구성합니다.
   1. 인터페이스 유형: Layer3(기본값).
   2. Config 탭에서 Trust-VR 라우터에 인터페이스를 할당합니다.
   3. Config(구성) 탭에서 Security Zone(보안 영역) 드롭다운을 확장하고 New Zone(새 영역)을 선택합니다. Trust(신뢰)라는 새 영역을 정의하고 OK(확인)를 클릭합니다.
2. 인터페이스에 하나의 IP 주소만 할당하려는 경우 IPv4 탭에서 DHCP Client(DHCP 클라이언트)를 선택합니다. 둘 이상의 IP 주소를 할당하려는 경우 고정을 선택하고 Azure Portal의 인터페이스에 할당된 기본 및 보조 IP 주소를 수동으로 입력합니다. 인터페이스의 개인 IP 주소는 Virtual Machines -> YOURPALOMACHINE -> Networking으로 이동하고 각 탭에 지정된 개인 IP 주소를 사용하여 찾을 수 있습니다.
   1. Automatically create default route to default gateway provided by server 확인란의 선택을 취소합니다.
      1. 참고: 이 옵션을 사용하지 않도록 설정하면 이 인터페이스에서 처리되는 트래픽이 VNet의 기본 게이트웨이로 직접 흐르지 않습니다.
3. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다. 인터페이스의 링크 상태가 작동 중인지 확인합니다(Palo Alto 사용자 인터페이스에서 인터페이스가 녹색으로 바뀌어야 함).

Static Routes(정적 경로 정의)

Palo Alto는 트래픽을 인터넷으로 라우팅하는 방법과 서브넷으로 트래픽을 라우팅하는 방법을 이해해야 합니다. 이 섹션에서 볼 수 있듯이 각 Azure Load Balancer에서 제출된 상태 프로브의 처리를 처리하는 데 도움이 되는 두 개의 별도 가상 라우터가 필요합니다.

새 Virtual Router 및 Static Route to the Internet(인터넷에 대한 고정 경로)을 생성합니다.

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Untrust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 인터넷 트래픽을 송신하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Untrust 인터페이스가 배포된 서브넷의 기본 게이트웨이 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰할 수 없는 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. 정적 경로를 생성하여 인터넷에서 신뢰할 수 있는 VR로 트래픽 이동
   1. 이름: 내부 경로
   2. 대상: vnet 주소 공간
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 트러스트-VR
7. 확인을 클릭합니다.

Azure 서브넷에 대한 새 가상 라우터 및 고정 경로 만들기Create a new Virtual Router and Static Route to your Azure Subnets

1. Network(네트워크) - > Virtual Router(가상 라우터)를 선택합니다.
2. 하단에서 추가를 클릭합니다.
3. 이름을 Trust-VR로 설정합니다.
4. 고정 경로 선택 -> IPv4 -> 추가
5. 신뢰할 수 있는 인터페이스에서 Azure로 트래픽을 보내는 고정 경로 만들기Create a Static Route to send traffic to Azure from your trusted interface
   1. 이름: AzureVNet
   2. 대상: vnet 주소 공간
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 트러스트 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
6. Trust에서 수신된 인터넷 트래픽을 Untrust Virtual Router로 이동하기 위한 고정 경로 생성
   1. 이름: 인터넷
   2. 대상: 0.0.0.0/0
   3. 인터페이스: 없음
   4. 다음 홉: 다음 VR
      1. 언트러스트 VR
7. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Azure Load Balancer에 대한 상태 프로브 구성Configure Health Probes for Azure Load Balancer

스케일 아웃 시나리오를 배포하는 경우 Azure Load Balancer의 IP 주소인 168.63.129.16에서 TCP 프로브를 승인해야 합니다. Azure 상태 프로브는 특정 IP 주소(168.63.129.16)에서 제공됩니다. 이 경우 로드 밸런서에 대한 응답을 다시 허용하기 위해 정적 경로가 필요합니다. 이 문서에서는 Azure Load Balancer가 Palo Alto 인스턴스가 정상인지 확인하기 위해 연결할 수 있도록 Trust 인터페이스에서 SSH를 엄격하게 구성합니다.

인터페이스에 대한 Palo Alto SSH 서비스 구성

먼저 인터페이스 관리 프로필을 생성해야 합니다

1. 네트워크 -> 네트워크 프로파일 -> Interface Mgmt를 선택합니다.
2. 버튼 왼쪽에서 추가를 클릭합니다.
3. 다음 구성을 사용합니다
   1. 이름: SSH-MP
   2. 관리 서비스: SSH
   3. 허용된 IP 주소: 168.63.129.16/32
4. 확인을 클릭합니다.

다음으로 Trust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/2에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

다음으로 Untrust 인터페이스에 프로필을 할당해야 합니다

1. 네트워크 선택 -> 인터페이스 ->ethernet1/1에 대한 링크 선택
2. 고급 탭을 선택합니다.
3. 관리 프로필을 SSH-MP로 설정합니다.
4. 확인을 클릭합니다.

신뢰할 수 없는 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 정적 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the Untrust Interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Untrust 인터페이스에서 빠져나가도록 지시해야 합니다.

1. 네트워크 -> 가상 라우터 -> Untrust-VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/1
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

트러스트 인터페이스에서 Azure Load Balancer 상태 프로브에 대한 고정 경로 만들기Create a static route for the Azure Load Balancer Health Probes on the trust interface

다음으로, 0.0.0.0/0 규칙으로 인해 상태 프로브가 Trust 인터페이스에서 벗어나도록 지시해야 합니다.

1. Network(네트워크) -> Virtual Router(가상 라우터) - Trust(신뢰)> VR을 선택합니다.
2. 고정 경로 선택 -> IPv4 -> 추가
3. 다음 구성을 사용합니다
   1. 이름: AzureLBHealthProbe
   2. 대상: 168.63.129.16/32
   3. 인터페이스: 이더넷 1/2
   4. 다음 홉: IP 주소
   5. IP 주소: Trust 인터페이스가 배포된 서브넷의 기본 게이트웨이의 IP 주소를 사용합니다.
      1. 참고: 이를 찾으려면 Azure Portal(portal.azure.com)로 이동하여 모든 서비스 -> 가상 네트워크 -> 가상 네트워크 -> 서브넷을 선택하고 신뢰 인터페이스가 있는 서브넷의 첫 번째 IP 주소를 사용합니다. 예를 들어 서브넷의 주소 범위가 10.5.15.0/24인 경우 10.5.15.1을 IP 주소로 사용합니다. 서브넷이 10.5.15.128/25 인 경우 129 10.5.15.129를 IP 주소로 사용합니다.
4. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

인터넷으로 향하는 내부 트래픽에 대한 NAT 규칙 만들기

Untrust 인터페이스의 주소를 통해 인터넷으로 향하는 모든 이그레스 트래픽을 NAT해야 하므로 인터넷의 반환 트래픽은 디바이스의 Untrust 인터페이스를 통해 다시 들어옵니다.

1. Policies(정책) - > NAT로 이동합니다.
2. Add(추가)를 클릭합니다.
3. 일반 탭에서 다음 구성을 사용합니다
   1. 이름: UntrustToInternet
   2. 설명: 인터넷으로 향하는 모든 신뢰할 수 있는 트래픽을 신뢰할 수 없는 인터페이스로 NAT하는 규칙
4. Original Packet(원본 패킷) 탭에서 다음 구성을 사용합니다
   1. Source Zone(소스 영역): Add(추가)를 클릭하고 Trust(신뢰)를 선택합니다.
   2. 대상 영역: 신뢰할 수 없음
   3. 대상 인터페이스: 이더넷 1/1
   4. 서비스: 모두 확인
   5. Source Address(소스 주소): Add(추가)를 클릭하고 Trust zone의 Internal Address(내부 주소) 공간을 사용합니다.
   6. 대상 주소: 모두 선택
5. Translated Packet(변환된 패킷) 탭에서 다음 구성을 사용합니다
   1. 변환 유형: 동적 IP 및 포트
   2. 주소 유형: 인터페이스 주소
   3. 인터페이스: 이더넷 1/1
   4. IP 주소: 없음
   5. 대상 주소 변환 변환 유형: 없음
6. 확인을 클릭합니다.

오른쪽 상단에서 커밋을 클릭합니다.

Palo Alto 어플라이언스 업데이트

기본적으로 Palo Alto는 8.0.X 시리즈에 8.0.0을 배포하고 8.1.X 시리즈에 8.1.0을 배포합니다. 이 경우 Palo Alto는 지원 사례를 지원하기 전에 어플라이언스를 해당 시리즈의 최신 버전으로 업그레이드할 것을 강력히 권장합니다.

이렇게 하려면 Device -> Dynamic Updates로 이동하여 왼쪽 하단의 Check Now를 클릭하고 사용 가능한 업데이트 목록에서 최신 빌드를 다운로드>.

참고: 업데이트 프로세스를 수행하려면 장치를 재부팅해야 하며 20분 정도 걸릴 수 있습니다.

요약

이 시점에서 작동하는 스케일 아웃 Palo Alto 배포가 있어야 합니다. 모든 것이 순조롭게 진행되었다면 관리 인터페이스에서 공용 IP를 제거하거나 최소한 원래 있는 단일 공용 IP 주소로 범위를 지정하는 것이 좋습니다. 여기로 이동하여 공용 IP 주소를 찾을 수 있습니다 https://jackstromberg.com/whats-my-ip-address/

참조

Azure에 VM-Series 배포에 대한 Palo Alto의 공식 문서 (이것을 찾는 데 시간이 오래 걸렸으며 정적 경로 설정 또는 어플라이언스 업데이트는 다루지 않음) : https://docs.paloaltonetworks.com/vm-series/8-1/vm-series-deployment/set-up-the-vm-series-firewall-on-azure/deploy-the-vm-series-firewall-on-azure-solution-template.html

Azure VM 크기 조정에 대한 Palo Alto의 공식 설명서: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD7CAK

Azure의 VM-Series 아키텍처에 대한 설명서(PDF 복사본을 얻으려면 페이지 맨 위에 있는 작은 다운로드 단추를 클릭): https://www.paloaltonetworks.com/resources/guides/azure-architecture-guide

팔로알토 네트웍스 Visio & OmniGraffle 스텐실: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmAJCA0

Palo Alto에서 스케일 아웃 VM 시리즈 배포의 아키텍처를 간략하게 설명하는 깔끔한 비디오: https://www.paloaltonetworks.com/resources/videos/vm-series-in-azure

Palo Alto 배포의 예정된 VMSS 버전: PaloAltoNetworks/azure-autoscaling: VMSS를 사용하는 Azure 자동 크기 조정 솔루션(github.com)

Azure 프라이빗 DNS는 가상 네트워크에 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다. 프라이빗 DNS 영역을 사용하면 배포 중에 Azure에서 제공한 이름 대신 고유한 사용자 지정 도메인 이름을 사용할 수 있습니다. 사용자 지정 도메인 이름을 사용하면 조직의 요구 사항에 가장 적합하도록 가상 네트워크 아키텍처를 조정할 수 있습니다. 가상 네트워크와 연결된 가상 네트워크 내에서 VM(가상 머신)에 대한 이름을 확인할 수 있게 해줍니다. 또한 분할-수평 보기를 사용해 영역을 구성할 수도 있습니다. 그러면 프라이빗 DNS 영역과 공용 DNS 영역이 이름을 공유할 수 있습니다.

가상 네트워크에서 프라이빗 DNS 영역의 레코드를 확인하려면 가상 네트워크를 해당 영역과 연결해야 합니다. 연결된 가상 네트워크는 전체 액세스 권한을 가지며 프라이빗 영역에 게시된 모든 DNS 레코드를 확인할 수 있습니다. 가상 네트워크 링크에 대한 자동 등록을 사용하도록 설정할 수도 있습니다. 가상 네트워크 연결에 대한 자동 등록을 사용하도록 설정하면 해당 가상 네트워크의 가상 머신에 대한 DNS 레코드가 프라이빗 영역에 등록됩니다. 자동 등록을 사용할 수 있게 되면 Azure DNS는 가상 머신이 생성되거나, 해당 IP 주소를 변경하거나, 삭제될 때마다 영역 레코드를 업데이트합니다.

프라이빗 DNS 영역을 만들 때 Azure는 영역 데이터를 전역 리소스로 저장합니다. 즉 프라이빗 영역은 단일 VNet 또는 지역에 종속되지 않습니다. 동일한 프라이빗 영역을 다른 지역의 여러 VNet에 연결할 수 있습니다. 하나의 VNet에서 서비스가 중단된 경우 프라이빗 영역을 계속 사용할 수 있습니다. 자세한 내용은 Azure 프라이빗 DNS 영역 복원력을 참조하세요.

Azure 프라이빗 DNS는 다음과 같은 이점을 누릴 수 있습니다.

• 사용자 지정 DNS 솔루션이 필요 없음. 이전에는 많은 고객이 가상 네트워크에서 DNS 영역을 관리하기 위해 사용자 지정 DNS 솔루션을 만들었습니다. 이제 기본 Azure 인프라를 사용하여 DNS 영역을 관리할 수 있으므로 사용자 지정 DNS 솔루션을 만들고 관리해야 하는 부담이 사라졌습니다.
• 모든 공용 DNS 레코드 형식을 사용합니다. Azure DNS는 A, AAAA, CNAME, MX, PTR, SOA, SRV 및 TXT 레코드를 지원합니다.
• 자동 호스트 레코드 관리. Azure는 사용자 지정 DNS 레코드를 호스팅할 뿐 아니라 VM의 호스트 이름 레코드를 지정된 가상 네트워크에 자동으로 보존합니다. 이 시나리오에서는 사용자 지정 DNS 솔루션을 만들거나 애플리케이션을 수정할 필요 없이 사용하는 도메인 이름을 최적화할 수 있습니다.
• 가상 네트워크 간의 호스트 이름 확인. Azure에서 제공하는 호스트 이름과는 달리, 프라이빗 DNS 영역은 가상 네트워크 간에 공유할 수 있습니다. 이 기능은 가상 네트워크 피어링 같은 교차 네트워크 및 서비스 검색 시나리오를 단순화합니다.
• 친숙한 도구 및 사용자 환경. 이 서비스는 학습 곡선을 단축할 수 있도록 잘 설정된 Azure DNS 도구(Azure Portal, Azure PowerShell, Azure CLI, Azure Resource Manager 템플릿, REST API)를 사용합니다.
• 수평 분할 DNS 지원. Azure DNS를 사용하면 이름이 같고 가상 네트워크 내 그리고 공용 인터넷의 다른 답변을 확인하는 영역을 만들 수 있습니다. 분할 수평 DNS에 대한 일반적인 시나리오는 가상 네트워크 내에서 사용할 수 있는 전용 서비스 버전을 제공하는 것입니다.
• 모든 Azure 지역에서 사용 가능. Azure DNS 프라이빗 영역 기능은 Azure 퍼블릭 클라우드의 모든 Azure 지역에서 사용할 수 있습니다.

Azure 프라이빗 DNS는 다음과 같은 기능을 제공합니다.

• 자동 등록이 사용 설정된 프라이빗 영역에 연결된 가상 네트워크에서 가상 머신 자동 등록. 가상 머신이 개인 IP 주소를 가리키는 A 레코드로 프라이빗 영역에 등록됩니다. 자동 등록이 사용 설정된 가상 네트워크 연결에서 가상 머신이 삭제되면 Azure DNS는 연결된 프라이빗 영역에서 해당 DNS 레코드도 자동으로 제거합니다.
• 프라이빗 영역에 연결된 가상 네트워크 전체에서 정방향 DNS 확인이 지원됩니다. 가상 네트워크 간 DNS 확인의 경우 가상 네트워크가 서로 연결되는 명시적 종속성은 없습니다. 그러나 다른 시나리오(예: HTTP 트래픽)를 위해 가상 네트워크를 피어링할 수도 있습니다.
• DNS 역방향 조회는 가상 네트워크 범위 내에서 지원됩니다. 프라이빗 영역에 연결된 개인 IP에 대한 역방향 DNS 조회에서는 호스트/레코드 이름과 영역 이름이 접미사로 포함된 FQDN이 반환됩니다.

Azure 프라이빗 DNS의 제한 사항은 다음과 같습니다.

• VM DNS 레코드의 자동 등록이 활성화된 경우 특정 가상 네트워크를 하나의 프라이빗 영역에만 연결할 수 있습니다. 그러나 단일 DNS 영역에 여러 가상 네트워크를 연결할 수 있습니다.
• 역방향 DNS는 연결된 가상 네트워크의 개인 IP 공간에 대해서만 작동합니다.
• 연결된 가상 네트워크의 개인 IP 주소에 대한 역방향 DNS는 가상 머신의 기본 접미사로 internal.cloudapp.net을 반환합니다. 자동 등록이 사용하도록 설정된 프라이빗 영역에 연결된 가상 네트워크의 경우 개인 IP 주소에 대한 역방향 DNS는 두 개의 FQDN을 반환합니다. 하나는 기본적으로 접미사가 internal.cloudapp.net이고 다른 하나는 프라이빗 영역 접미사가 있습니다.
• 조건부 전달은 Azure DNS Private Resolver를 사용하여 지원됩니다. Azure와 온-프레미스 네트워크 간에 확인을 사용하려면 VM 및 역할 인스턴스에 대한 이름 확인을 참조하세요.

가격 책정 정보는 Azure DNS 가격 책정을 참조하세요.

• Azure PowerShell 또는 Azure CLI를 사용하여 Azure DNS에서 프라이빗 영역을 만드는 방법을 알아봅니다.
• Azure DNS에서 프라이빗 영역으로 실현할 수 있는 몇 가지 일반 프라이빗 영역 시나리오에 대해 읽어보세요.
• Azure DNS의 프라이빗 영역에 대한 일반적인 질문과 답변은 프라이빗 DNS FAQ를 참조하세요.
• DNS 영역 및 레코드 개요를 참조하여 DNS 영역 및 레코드에 대해 알아봅니다.
• Azure의 몇 가지 다른 주요 네트워킹 기능을 알아봅니다.
• 학습 모듈: Azure DNS 소개

Azure DNS Private Resolver는 VM 기반 DNS 서버를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 새로운 서비스입니다.

Azure DNS Private Resolver에는 Azure Virtual Network가 필요합니다. 가상 네트워크 내에서 Azure DNS Private Resolver를 만들면 DNS 쿼리의 대상으로 사용할 수 있는 하나 이상의 인바운드 엔드포인트가 설정됩니다. 확인자의 아웃바운드 엔드포인트는 구성하는 DNS 전달 규칙 집합을 기반으로 하여 DNS 쿼리를 처리합니다. 규칙 집합에 연결된 네트워크에서 시작된 DNS 쿼리는 다른 DNS 서버에 보낼 수 있습니다.

Azure DNS Private Resolver를 사용하기 위해 VM(가상 머신)의 DNS 클라이언트 설정을 변경할 필요가 없습니다.

Azure DNS Private Resolver를 사용할 때의 DNS 쿼리 프로세스는 다음과 같이 요약됩니다.

1. 가상 네트워크의 클라이언트에서 DNS 쿼리를 실행합니다.
2. 이 가상 네트워크에 대한 DNS 서버가 사용자 지정되면 쿼리를 지정된 IP 주소로 전달합니다.
3. 기본(Azure 제공) DNS 서버가 가상 네트워크에 구성되어 있고 동일한 가상 네트워크에 연결된 프라이빗 DNS 영역이 있는 경우 이러한 영역을 참조합니다.
4. 쿼리가 가상 네트워크에 연결된 프라이빗 DNS 영역과 일치하지 않는 경우 DNS 전달 규칙 집합에 대한 가상 네트워크 링크를 참조합니다.
5. 규칙 집합 링크가 없는 경우 Azure DNS를 사용하여 쿼리를 확인합니다.
6. 규칙 집합 링크가 있는 경우 DNS 전달 규칙을 평가합니다.
7. 접미사가 일치하는 경우 쿼리를 지정된 주소로 전달합니다.
8. 여러 항목이 일치하는 경우 가장 긴 접미사를 사용합니다.
9. 일치하는 항목이 없는 경우 DNS 전달을 수행하지 않고 Azure DNS를 사용하여 쿼리를 확인합니다.

Azure DNS Private Resolver 아키텍처는 다음 그림에 요약되어 있습니다. Azure 가상 네트워크와 온-프레미스 네트워크 간의 DNS 확인에는 Azure ExpressRoute 또는 VPN이 필요합니다.

그림 1: Azure DNS Private Resolver 아키텍처

프라이빗 DNS 확인자를 만드는 방법에 대한 자세한 내용은 다음을 참조하세요.

• 빠른 시작: Azure Portal을 사용하여 Azure DNS Private Resolver 만들기
• 빠른 시작: Azure PowerShell을 사용하여 Azure DNS Private Resolver 만들기

Azure DNS Private Resolver에서 제공하는 이점은 다음과 같습니다.

• 완전 관리형: 기본 제공 고가용성, 영역 중복성
• 비용 절감: 운영 비용을 절감하고, 기존 IaaS 솔루션 가격의 일부로 실행합니다.
• 프라이빗 DNS 영역에 대한 프라이빗 액세스: 온-프레미스에서 조건부로 전달합니다.
• 확장성: 엔드포인트별 고성능
• DevOps 친숙한 기능: Terraform, ARM 또는 Bicep을 사용하여 파이프라인을 빌드합니다.

지역별 Azure 제품 - Azure DNS를 참조하세요.

Azure DNS Private Resolver는 확인자를 배포한 지역에서 고객 데이터를 이동하거나 저장하지 않습니다.

이 문서에서는 해결 프로그램 엔드포인트 및 규칙 집합에 대한 요약을 제공합니다. 엔드포인트 및 규칙 집합에 대한 자세한 내용은 Azure DNS Private Resolver 엔드포인트 및 규칙 집합을 참조하세요.

인바운드 엔드포인트를 사용하면 프라이빗 가상 네트워크 주소 공간의 일부인 IP 주소를 통해 온-프레미스 또는 다른 프라이빗 위치에서 이름을 확인할 수 있습니다. 온-프레미스에서 Azure 프라이빗 DNS 영역을 확인하려면 인바운드 엔드포인트의 IP 주소를 온-프레미스 DNS 조건부 전달자에 입력합니다. 온-프레미스 DNS 조건부 전달자는 가상 네트워크에 대한 네트워크 연결이 있어야 합니다.

인바운드 엔드포인트에는 프로비저닝된 VNet의 서브넷이 필요합니다. 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다. 인바운드 엔드포인트에서 받은 DNS 쿼리는 Azure로 들어갑니다. 자동 등록 또는 Private Link 사용 서비스를 사용하는 VM을 포함하여 프라이빗 DNS 영역이 있는 시나리오에서 이름을 확인할 수 있습니다.

아웃바운드 엔드포인트를 사용하면 이름 확인을 조건부로 Azure에서 온-프레미스, 다른 클라우드 공급자 또는 외부 DNS 서버로 전달할 수 있습니다. 이 엔드포인트에는 해당 서브넷에서 실행되는 다른 서비스가 없고 Microsoft.Network/dnsResolvers에만 위임할 수 있는 프로비전된 VNet의 전용 서브넷이 필요합니다. 아웃바운드 엔드포인트에 보낸 DNS 쿼리는 Azure에서 나갑니다.

가상 네트워크 링크는 DNS 전달 규칙 집합을 사용하여 아웃바운드 엔드포인트에 연결된 가상 네트워크에 대한 이름 확인을 사용하도록 설정합니다. 1:1 관계입니다.

DNS 전달 규칙 집합은 하나 이상의 아웃바운드 엔드포인트에 적용하거나 하나 이상의 가상 네트워크에 연결할 수 있는 DNS 전달 규칙(최대 1000개) 그룹입니다. 1:N 관계입니다. 규칙 집합은 특정 아웃바운드 엔드포인트와 연결됩니다. 자세한 내용은 DNS 전달 규칙 집합을 참조하세요.

DNS 전달 규칙에는 조건부 전달에 사용할 하나 이상의 대상 DNS 서버가 포함되며 다음으로 표시됩니다.

• 도메인 이름
• 대상 IP 주소
• 대상 포트 및 프로토콜(UDP 또는 TCP)

현재 Azure DNS Private Resolver에 적용되는 제한은 다음과 같습니다.

DNS 프라이빗 확인자1

1 포털이 업데이트될 때까지 Azure Portal에서 다른 한도가 적용될 수 있습니다. PowerShell을 사용하여 가장 최근 한도까지 요소를 프로비전합니다.

가상 네트워크와 관련된 제한 사항은 다음과 같습니다.

• 암호화가 사용하도록 설정된 VNet은 Azure DNS Private Resolver를 지원하지 않습니다.
• DNS 확인자는 DNS 확인자와 동일한 지역의 가상 네트워크만 참조할 수 있습니다.
• 가상 네트워크는 여러 DNS 확인자 간에 공유할 수 없습니다. 단일 가상 네트워크는 단일 DNS 확인자에서만 참조할 수 있습니다.

DNS 확인자에 사용되는 서브넷에 대한 제한 사항은 다음과 같습니다.

• 서브넷은 최소 /28 주소 공간 또는 최대 /24 주소 공간이어야 합니다. /28 서브넷은 현재 엔드포인트 한도를 수용하기에 충분합니다. /27에서 /24까지의 서브넷 크기는 이러한 한도가 변경되는 경우 유연성을 제공할 수 있습니다.
• 서브넷은 여러 DNS 확인자 엔드포인트 간에 공유할 수 없습니다. 단일 서브넷은 단일 DNS 확인자 엔드포인트에서만 사용할 수 있습니다.
• DNS 확인자 인바운드 엔드포인트에 대한 모든 IP 구성은 동일한 서브넷을 참조해야 합니다. 단일 DNS 확인자 인바운드 엔드포인트에 대한 IP 구성은 여러 서브넷을 포함할 수 없습니다.
• DNS 확인자 인바운드 엔드포인트에 사용되는 서브넷은 부모 DNS 확인자에서 참조하는 가상 네트워크 내에 있어야 합니다.
• 서브넷은 Microsoft.Network/dnsResolvers에만 위임할 수 있으며 다른 서비스에는 사용할 수 없습니다.

아웃바운드 엔드포인트에 대한 제한 사항은 다음과 같습니다.

• DNS 전달 규칙 집합과 그 아래의 가상 네트워크 링크가 삭제되지 않으면 아웃바운드 엔드포인트를 삭제할 수 없습니다.

• 규칙 집합은 최대 1000개의 규칙을 가질 수 있습니다.
• 규칙 집합의 교차 테넌트 연결은 지원되지 않습니다.

• IPv6 사용 서브넷은 지원되지 않습니다.
• DNS Private Resolver는 Azure ExpressRoute FastPath를 지원하지 않습니다.
• DNS Private Resolver는 Azure Lighthouse와 호환되지 않습니다.
  • Azure Lighthouse가 사용 중인지 확인하려면 Azure Portal에서 서비스 공급자를 검색하고 서비스 공급자 제품을 선택합니다.

• Azure PowerShell 또는 Azure Portal을 사용하여 Azure DNS Private Resolver를 만드는 방법을 알아봅니다.
• Azure DNS Private Resolver를 사용하여 Azure 및 온-프레미스 도메인을 확인하는 방법을 이해합니다.
• Azure DNS Private Resolver 엔드포인트 및 규칙 집합에 대해 알아봅니다.
• 프라이빗 해결 프로그램을 사용하여 DNS 장애 조치(failover) 설정 방법 알아보기
• 프라이빗 해결 프로그램을 사용하여 하이브리드 DNS를 구성하는 방법을 알아봅니다.
• Azure의 몇 가지 다른 주요 네트워킹 기능을 알아봅니다.
• 학습 모듈: Azure DNS 소개

애플리케이션 보안 그룹을 사용하면 네트워크 보안을 애플리케이션 구조의 자연 확장으로 구성하여 가상 머신을 그룹화하고 해당 그룹에 따라 네트워크 보안 정책을 정의할 수 있습니다. 명시적 IP 주소를 수동으로 유지 관리하지 않고 대규모 보안 정책을 재사용할 수 있습니다. 플랫폼은 명시적 IP 주소 및 여러 규칙 집합의 복잡성을 처리하여 비즈니스 논리에 집중할 수 있도록 합니다. 애플리케이션 보안 그룹에 대해 보다 정확하게 이해하려면 다음 예제를 잘 살펴보세요.

이전 그림에서 NIC1 및 NIC2는 AsgWeb 애플리케이션 보안 그룹의 멤버입니다. NIC3는 AsgLogic 애플리케이션 보안 그룹의 멤버입니다. NIC4는 AsgDb 애플리케이션 보안 그룹의 멤버입니다. 이 예시에서는 각 네트워크 인터페이스(NIC)가 단 하나의 애플리케이션 보안 그룹의 멤버이지만, 네트워크 인터페이스는 Azure 제한 내에서 여러 애플리케이션 보안 그룹의 멤버가 될 수 있습니다. 어떤 네트워크 인터페이스에도 네트워크 보안 그룹이 연결되지 않았습니다. NSG1은 두 서브넷에 연결되었으며 다음 규칙을 포함하고 있습니다.

이 규칙은 인터넷에서 웹 서버로 가는 트래픽을 허용하기 위해 필요합니다. 인터넷의 인바운드 트래픽을 DenyAllInbound 기본 보안 규칙에서 거부하기 때문에 AsgLogic 또는 AsgDb 애플리케이션 보안 그룹에 대한 규칙을 추가하지 않아도 됩니다.

AllowVNetInBound 기본 보안 규칙은 동일한 가상 네트워크의 리소스 간 통신을 모두 허용하므로, 모든 리소스에서 들어오는 트래픽을 거부하려면 이 규칙이 필요합니다.

이 규칙은 AsgLogic 애플리케이션 보안 그룹에서 AsgDb 애플리케이션 보안 그룹으로 가는 트래픽을 허용합니다. 이 규칙의 우선 순위는 Deny-Database-All 규칙의 우선 순위보다 높습니다. 결과적으로 이 규칙이 Deny-Database-All 규칙보다 먼저 처리되므로 AsgLogic 애플리케이션 보안 그룹의 트래픽은 허용되는 반면, 그 외의 트래픽은 모두 차단됩니다.

애플리케이션 보안 그룹의 구성원인 네트워크 인터페이스는 원본 또는 대상으로 지정하는 규칙을 적용합니다. 이 규칙은 다른 네트워크 인터페이스에 영향을 주지 않습니다. 네트워크 인터페이스가 애플리케이션 보안 그룹의 멤버가 아닌 경우에는 네트워크 보안 그룹이 서브넷과 연결되어도 규칙이 네트워크 인터페이스에 적용되지 않습니다.

Application Security Group에는 다음과 같은 제약 사항이 있습니다.

• 한 구독에 허용되는 애플리케이션 보안 그룹의 개수 제한 및 애플리케이션 보안 그룹과 관련된 기타 제한이 있습니다. 자세한 내용은 Azure 제한을 참조하세요.
• 애플리케이션 보안 그룹에 할당된 모든 네트워크 인터페이스는 애플리케이션 보안 그룹에 할당된 첫 번째 네트워크 인터페이스가 있는 가상 네트워크와 동일한 가상 네트워크에 있어야 합니다. 예를 들어 AsgWeb라는 애플리케이션 보안 그룹에 할당된 첫 번째 네트워크 인터페이스가 VNet1이라는 가상 네트워크에 있는 경우 ASGWeb에 할당되는 모든 후속 네트워크 인터페이스는 VNet1에 있어야 합니다. 서로 다른 가상 네트워크의 네트워크 인터페이스를 동일한 애플리케이션 보안 그룹에 추가할 수 없습니다.
• 애플리케이션 보안 그룹을 보안 규칙의 원본 및 대상으로 지정하는 경우, 두 애플리케이션 보안 그룹의 네트워크 인터페이스는 동일한 가상 네트워크에 있어야 합니다.
  • 예를 들어 AsgLogic에 VNet1의 네트워크 인터페이스가 있었고 AsgDb에 VNet2의 네트워크 인터페이스가 있었던 경우입니다. 이 경우 AsgLogic을 원본으로, AsgDb를 규칙의 대상으로 할당하는 것은 불가능합니다. 원본 및 대상 애플리케이션 보안 그룹에 대한 모든 네트워크 인터페이스는 동일한 가상 네트워크에 있어야 합니다.

• 네트워크 보안 그룹 만들기에 대해 알아보세요.

Azure Private Link를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure PaaS Services(예: Azure Storage 및 SQL Database)와 Azure 호스팅 고객 소유/파트너 서비스에 액세스할 수 있습니다.

가상 네트워크와 서비스 사이의 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다. 서비스를 공용 인터넷에 더 이상 노출할 필요가 없습니다. 가상 네트워크에 자체 프라이빗 링크 서비스를 만들어서 고객에게 제공할 수도 있습니다. Azure Private Link를 사용한 설치 및 소비는 Azure PaaS, 고객 소유 및 공유 파트너 서비스에서 일관적입니다.

Azure Private Link는 다음과 같은 이점이 있습니다.

• Azure 플랫폼의 프라이빗 액세스 서비스: 프라이빗 엔드포인트를 사용하여 가상 네트워크를 Azure에서 애플리케이션 구성 요소로 사용할 수 있는 모든 서비스에 연결합니다. 서비스 공급자는 자체 가상 네트워크에서 서비스를 렌더링할 수 있으며, 소비자는 로컬 가상 네트워크에서 이러한 서비스에 액세스할 수 있습니다. Private Link 플랫폼은 Azure 백본 네트워크를 통해 소비자와 서비스 간의 연결을 처리합니다.
• 온-프레미스 및 피어링된 네트워크: 프라이빗 엔드포인트를 사용하여 온-프레미스에서 ExpressRoute 개인 피어링, VPN 터널 및 피어링된 가상 네트워크를 통해 Azure에서 실행되는 서비스에 액세스할 수 있습니다. 서비스에 연결하기 위해 ExpressRoute Microsoft 피어링을 구성하거나 인터넷을 트래버스할 필요가 없습니다. Private Link는 워크로드를 Azure로 안전하게 마이그레이션하는 방법을 제공합니다.
• 데이터 유출 방지: 프라이빗 엔드포인트는 전체 서비스가 아닌 PaaS 리소스의 인스턴스에 매핑됩니다. 소비자는 특정 리소스에만 연결할 수 있습니다. 서비스의 다른 리소스에 대한 액세스는 차단됩니다. 이 메커니즘은 데이터 유출 위험을 방지합니다.
• Global Reach: 다른 지역에서 실행되는 서비스에 비공개로 연결합니다. 소비자의 가상 네트워크는 A 지역에 있으며, B 지역의 Private Link 뒤에 있는 서비스에 연결할 수 있습니다.
• 사용자 고유의 서비스로 확장: 동일한 환경과 기능을 사용하여 자체 서비스를 Azure의 소비자에게 비공개로 렌더링할 수 있습니다. 서비스를 표준 Azure Load Balancer 뒤에 배치하여 Private Link에 사용할 수 있습니다. 그러면 소비자는 자체 가상 네트워크에서 프라이빗 엔드포인트를 사용하여 서비스에 직접 연결할 수 있습니다. 승인 호출 흐름을 사용하여 연결 요청을 관리할 수 있습니다. Azure Private Link는 다른 Microsoft Entra 테넌트에 속하는 소비자 및 서비스에 대해 작동합니다.

Private Link를 지원하는 Azure 서비스에 대한 자세한 내용은 Azure Private Link 가용성을 참조하세요.

최신 알림은 Azure Private Link 업데이트 페이지를 확인하세요.

Azure Private Link는 Azure Monitor와 통합되었습니다. 이 조합을 통해 다음을 수행할 수 있습니다.

• 스토리지 계정에 로그를 보관합니다.
• 이벤트를 Event Hubs로 스트리밍합니다.
• Azure Monitor 로깅이 가능합니다.

Azure Monitor에서 다음 정보에 액세스할 수 있습니다.

• 프라이빗 엔드포인트:
  • 프라이빗 엔드포인트에서 처리한 데이터(수신/송신)
• Private Link 서비스:
  • Private Link 서비스에서 처리한 데이터(수신/송신)
  • NAT 포트 가용성

가격 책정에 대한 자세한 내용은 Azure Private Link 가격 책정을 참조하세요.

FAQ는 Azure Private Link FAQ를 참조하세요.

제한은 Azure Private Link 제한을 참조하세요.

SLA는 Azure Private Link에 대한 SLA를 참조하세요.

Azure 네트워크 보안 그룹을 사용하여 Azure 가상 네트워크의 Azure 리소스 간의 네트워크 트래픽을 필터링할 수 있습니다. 네트워크 보안 그룹에는 여러 종류의 Azure 리소스에서 오는 인바운드 트래픽 또는 이러한 리소스로 나가는 아웃바운드 네트워크 트래픽을 허용하거나 거부하는 보안 규칙이 포함됩니다. 규칙마다 원본 및 대상, 포트, 프로토콜을 지정할 수 있습니다.

이 문서에서는 네트워크 보안 그룹 규칙의 속성, 적용되는 기본 보안 규칙 및 강화된 보안 규칙을 만들기 위해 수정할 수 있는 규칙 속성을 설명합니다.

네트워크 보안 그룹은 Azure 구독 제한 내에서 필요한 개수 만큼 규칙을 포함합니다. 각 규칙은 다음 속성을 지정합니다.

보안 규칙은 5-튜플(원본, 원본 포트, 대상, 대상 포트, 프로토콜) 정보를 기반으로 평가 및 적용됩니다. 우선 순위와 방향이 같은 두 개의 보안 규칙을 만들 수 없습니다. 기존 연결에 대한 흐름 레코드가 만들어집니다. 통신은 흐름 레코드의 연결 상태에 따라 허용 또는 거부됩니다. 흐름 레코드는 네트워크 보안 그룹의 상태 저장을 허용합니다. 예를 들어 포트 80을 통해 모든 주소에 대한 아웃바운드 보안 규칙을 지정하는 경우 아웃바운드 트래픽에 대한 응답에 인바운드 보안 규칙을 지정하지 않아도 됩니다. 통신이 외부에서 시작된 경우 인바운드 보안 규칙을 지정하기만 하면 됩니다. 반대의 경우도 마찬가지입니다. 포트를 통해 인바운드 트래픽이 허용되는 경우 포트를 통해 트래픽에 응답하도록 아웃바운드 보안 규칙을 지정하지 않아도 됩니다.

연결을 허용한 보안 규칙을 제거해도 기존 연결이 중단되지 않을 수 있습니다. 네트워크 보안 그룹 규칙을 수정하면 새 연결에만 영향을 줍니다. 네트워크 보안 그룹에서 새 규칙을 만들거나 기존 규칙을 업데이트하는 경우 새 연결에만 적용됩니다. 기존 연결은 새 규칙으로 재평가되지 않습니다.

한 네트워크 보안 그룹에 만들 수 있는 보안 규칙 수에는 제한이 있습니다. 자세한 내용은 Azure 제한을 참조하세요.

Azure는 사용자가 만드는 각 네트워크 보안 그룹에 다음과 같은 기본 규칙을 만듭니다.

원본 및 대상 열에서 VirtualNetwork, AzureLoadBalancer 및 인터넷은 IP 주소가 아닌 서비스 태그입니다. 프로토콜 열에서 모두는 TCP, UDP 및 ICMP를 포함합니다. 규칙을 만들 때 TCP, UDP, ICMP 또는 모두를 지정할 수 있습니다. 소스 및 대상 열에서 0.0.0.0/0은 모든 주소를 나타냅니다. Azure Portal, Azure CLI 또는 PowerShell과 같은 클라이언트는 이 식에 * 또는 모두를 사용할 수 있습니다.

기본 규칙을 제거할 수 없지만 더 높은 우선 순위의 규칙을 만들어서 재정의할 수 있습니다.

보강된 보안 규칙은 가상 네트워크에 대한 보안 정의를 간소화하여 더 적은 규칙으로 크고 복잡한 네트워크 보안 정책을 정의할 수 있도록 합니다. 여러 포트, 여러 명시적 IP 주소 및 범위를 이해하기 쉬운 단일 보안 규칙으로 결합할 수 있습니다. 규칙의 원본, 대상 및 포트 필드에서 보강된 규칙을 사용합니다. 보안 규칙 정의를 간단히 유지 관리하려면 보강된 보안 규칙을 서비스 태그 또는 애플리케이션 보안 그룹과 결합합니다. 한 규칙에서 지정할 수 있는 주소, 범위 및 포트 수가 제한됩니다. 자세한 내용은 Azure 제한을 참조하세요.

서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. 네트워크 보안 규칙에 대한 빈번한 업데이트의 복잡성을 최소화하는 데 도움이 됩니다.

자세한 내용은 Azure 서비스 태그를 참조하세요. Storage 서비스 태그를 사용하여 네트워크 액세스를 제한하는 방법에 대한 예제는 PaaS 리소스에 대한 네트워크 액세스 제한을 참조하세요.

애플리케이션 보안 그룹을 사용하면 네트워크 보안을 애플리케이션 구조의 자연 확장으로 구성하여 가상 머신을 그룹화하고 해당 그룹에 따라 네트워크 보안 정책을 정의할 수 있습니다. 명시적 IP 주소를 수동으로 유지 관리하지 않고 대규모 보안 정책을 재사용할 수 있습니다. 자세한 내용은 애플리케이션 보안 그룹을 참조하세요.

• 호스트 노드의 가상 IP: DHCP, DNS, IMDS, 상태 모니터링과 같은 기본 인프라 서비스는 가상화된 호스트 IP 주소 168.63.129.16 및 169.254.169.254를 통해 제공됩니다. 이러한 IP 주소는 Microsoft에 속하며, 이 용도로 모든 지역에서 유일하게 사용되는 가상화된 IP 주소입니다. 기본적으로 이러한 서비스는 각 서비스에 특정한 서비스 태그로 대상이 지정되지 않는 한 구성된 네트워크 보안 그룹의 적용을 받지 않습니다. 이 기본 인프라 통신을 재정의하기 위해 네트워크 보안 그룹 규칙에서 AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM과 같은 서비스 태그를 사용하여 트래픽을 거부하는 보안 규칙을 만들 수 있습니다. 네트워크 트래픽 필터링을 진단하고 네트워크 라우팅을 진단하는 방법을 알아봅니다.
• 라이선싱(키 관리 서비스): 가상 머신에서 실행되는 Windows 이미지는 사용이 허가되어 있어야 합니다. 사용 허가를 위해 라이선스 요청이 이러한 쿼리를 처리하는 키 관리 서비스 호스트 서버로 전송됩니다. 요청은 1688 포트를 통해 아웃바운드로 수행됩니다. 기본 경로 0.0.0.0/0 구성을 사용한 배포에 대해 이 플랫폼 규칙은 사용하지 않도록 설정됩니다.
• 부하가 분산된 풀의 가상 머신: 적용되는 원본 포트와 주소 범위는 부하 분산 장치가 아닌 원래 컴퓨터에서 가져옵니다. 대상 포트와 주소 범위는 부하 분산 장치가 아닌 대상 컴퓨터에서 가져옵니다.
• Azure 서비스 인스턴스: HDInsight, 애플리케이션 서비스 환경 및 Virtual Machine Scale Sets와 같은 몇 가지 Azure 서비스의 인스턴스는 가상 네트워크 서브넷에 배포됩니다. 가상 네트워크에 배포할 수 있는 서비스의 전체 목록은 Azure 서비스에 대한 가상 네트워크를 참조하세요. 서브넷에 네트워크 보안 그룹을 적용하기 전에 각 서비스의 포트 요구 사항을 숙지합니다. 서비스에 필요한 포트를 거부하면 서비스가 제대로 작동하지 않습니다.
• 아웃바운드 전자 메일 보내기: 인증된 SMTP 릴레이 서비스(일반적으로 587 TCP 포트를 통해 연결되지만 종종 다른 방법도 사용)를 활용하여 Azure Virtual Machines에서 전자 메일을 보내는 것이 좋습니다. SMTP 릴레이 서비스는 타사 전자 메일 공급자에서 메시지를 거부할 가능성을 최소화하기 위해 보낸 사람 신뢰도를 특수화합니다. 이러한 SMTP 릴레이 서비스는 Exchange Online Protection 및 SendGrid를 포함하지만 여기에 제한되지 않습니다. SMTP 릴레이 서비스는 구독 유형에 관계 없이 Azure에서 제한되지 않고 사용할 수 있습니다.
  • 기업계약: 표준 기업계약 구독에 배포된 VM의 경우 TCP 포트 25의 아웃바운드 SMTP 연결이 차단되지 않습니다. 그러나 외부 도메인은 VM에서 들어오는 이메일을 수락한다는 보장이 없습니다. 외부 도메인에서 이메일을 거부하거나 필터링하는 경우 외부 도메인의 이메일 서비스 공급자에게 문의하여 문제를 해결해야 합니다. 이러한 문제는 Azure 지원에서 다루지 않습니다.이 차단에서 구독을 제외하고 VM이 중지되었다가 다시 시작되면 해당 구독의 모든 VM은 제외됩니다. 예외는 요청된 구독에만 적용되고 인터넷으로 직접 라우팅되는 VM 트래픽에만 적용됩니다.
  • Enterprise 개발/테스트 구독의 경우 기본적으로 포트 25가 차단됩니다. 이 차단을 제거하는 것이 가능합니다. 차단을 제거하도록 요청하려면 Azure Portal의 Azure Virtual Network 리소스에 대한 진단 및 해결 설정 페이지의 이메일을 보낼 수 없음(SMTP-포트 25) 섹션으로 이동하여 진단을 실행합니다. 그러면 정규화된 엔터프라이즈 개발/테스트 구독이 자동으로 제외됩니다.
  • 종량제: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
  • MSDN, Azure Pass, Azure in Open, Education 및 평가판: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
  • 클라우드 서비스 공급자: 모든 리소스에서 아웃바운드 포트 25 통신이 차단되었습니다. 요청이 승인되지 않았기 때문에 제한 제거를 요청할 수 없습니다. 가상 머신에서 이메일을 보내야 하는 경우 SMTP 릴레이 서비스를 사용해야 합니다.
• 2017년 11월 15일까지 Azure 구독을 만든 경우 SMTP 릴레이 서비스를 사용할 수 있을 뿐만 아니라 TCP 포트 25를 통해 직접 전자 메일을 보낼 수 있습니다. 2017년 11월 15일 이후에 구독을 만든 경우 포트 25를 통해 직접 전자 메일을 보낼 수 없습니다. 포트 25를 통한 아웃바운드 통신 동작은 다음과 같이 구독 형식에 따라 다릅니다.

• 가상 네트워크에 배포하고 네트워크 보안 그룹이 연결된 Azure 리소스에 대한 자세한 내용은 Azure 서비스용 가상 네트워크 통합을 참조하세요
• 네트워크 보안 그룹을 사용하여 트래픽을 평가하는 방법에 대한 자세한 내용은 네트워크 보안 그룹의 작동 방법을 참조하세요.
• 네트워크 보안 그룹을 만들어 본 경험이 전혀 없는 경우 빠른 자습서를 완료하여 직접 경험해 볼 수 있습니다.
• 네트워크 보안 그룹에 익숙하고 네트워크 보안 그룹을 관리해야 하는 경우 네트워크 보안 그룹 관리를 참조하세요.
• 통신에 문제가 있고 네트워크 보안 그룹 문제를 해결해야 하는 경우 가상 머신 네트워크 트래픽 필터 문제 진단을 참조하세요.
• 네트워크 보안 그룹 흐름 로그를 사용하여 연결된 네트워크 보안 그룹이 있는 리소스와 주고 받는 네트워크 트래픽을 분석하는 방법을 알아보세요.

서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. Microsoft는 서비스 태그에 포함되는 주소 접두사를 관리하고 주소가 변경되면 서비스 태그를 자동으로 업데이트하여 네트워크 보안 규칙을 자주 업데이트할 때 발생하는 복잡성을 최소화합니다.

서비스 태그를 사용하여 네트워크 보안 그룹, Azure Firewall 및 사용자 정의 경로에서 네트워크 액세스 제어를 정의할 수 있습니다. 보안 규칙 및 경로를 만들 때 특정 IP 주소 대신 서비스 태그를 사용합니다. 서비스 태그 이름(예: ApiManagement)을 보안 규칙의 적절한 원본 또는 대상 필드에 지정하면 해당 서비스에 대한 트래픽을 허용하거나 거부할 수 있습니다. 경로의 주소 접두사에 서비스 태그 이름을 지정하면 서비스 태그로 캡슐화된 접두사에 대한 트래픽을 원하는 다음 홉 유형으로 라우팅할 수 있습니다.

퍼블릭 엔드포인트가 있는 Azure 서비스에 액세스하면서, 서비스 태그를 사용하여 네트워크 격리를 수행하고 일반 인터넷에서 Azure 리소스를 보호할 수 있습니다. 인바운드/아웃바운드 네트워크 보안 그룹 규칙을 만들어 인터넷에서 들어오고 나가는 트래픽을 거부하고 AzureCloud 또는 특정 Azure 서비스의 다른 사용 가능한 서비스 태그에서 들어오고 나가는 트래픽을 허용합니다.

다음 표에는 네트워크 보안 그룹 규칙에서 사용할 수 있는 모든 서비스 태그가 나와 있습니다.

열은 태그가 다음에 해당하는지 여부를 나타냅니다.

• 인바운드 또는 아웃바운드 트래픽을 포함하는 규칙에 적합합니다.
• 지역 범위를 지원합니다.
• Azure Firewall 규칙에서 인바운드 또는 아웃바운드 트래픽에 대해서만 대상 규칙으로 사용할 수 있습니다.

기본적으로 서비스 태그는 전체 클라우드의 범위를 반영합니다. 일부 서비스 태그는 해당 IP 범위를 지정된 지역으로 제한하여 보다 자세히 제어할 수 있습니다. 예를 들어, 서비스 태그 Storage는 전체 클라우드의 Azure Storage를 나타내지만 Storage.WestUS는 범위를 WestUS 지역의 스토리지 IP 주소 범위로 좁힙니다. 다음 표에서는 각 서비스 태그가 이러한 지역 범위를 지원하는지 여부를 나타내며 각 태그에 대해 나열된 방향이 권장 사항입니다. 예를 들어 AzureCloud 태그를 사용하여 인바운드 트래픽을 허용할 수 있습니다. 대부분의 시나리오에서는 다른 Azure 고객이 사용하는 IP가 서비스 태그의 일부로 포함되어 있으므로 모든 Azure IP의 트래픽을 허용하지 않는 것이 좋습니다.

클래식 배포 모델(Azure Resource Manager 이전)에서는 이전 표에 나열된 태그 중 일부만 지원합니다. 클래식 배포 모델의 태그는 다음 표와 같이 철자가 다릅니다.

다음은 현재 UDR(사용자 정의 경로)에 사용하기 위해 지원되지 않는 태그 목록입니다.

• AzurePlatformDNS
• AzurePlatformIMDS
• AzurePlatformLKM
• VirtualNetwork
• AzureLoadBalancer
• 인터넷

온-프레미스 방화벽 구성의 일부로 포함할 현재 서비스 태그 및 범위 정보를 얻을 수 있습니다. 이 정보는 각 서비스 태그에 해당하는 IP 범위의 현재 지정 시간 목록입니다. 다음 섹션에 설명된 대로 프로그래밍 방식으로 또는 JSON 파일 다운로드를 통해 이 정보를 가져올 수 있습니다.

IP 주소 범위 세부 정보와 함께 서비스 태그의 현재 목록을 프로그래밍 방식으로 검색할 수 있습니다.

• REST (영문)
• Azure PowerShell
• Azure CLI

예를 들어 스토리지 서비스 태그에 대한 모든 접두사를 검색하려면 다음 PowerShell cmdlet을 사용합니다.

$serviceTags = Get-AzNetworkServiceTag -Location eastus2
$storage = $serviceTags.Values | Where-Object { $_.Name -eq "Storage" }
$storage.Properties.AddressPrefixes

현재 서비스 태그 목록이 포함된 JSON 파일을 IP 주소 범위 정보와 함께 다운로드할 수 있습니다. 이러한 목록은 매주 업데이트되고 게시됩니다. 각 클라우드의 위치는 다음과 같습니다.

• Azure 공용
• Azure 미국 정부
• 21Vianet에서 운영하는 Microsoft Azure
• Azure 독일

해당 파일의 IP 주소 범위는 CIDR 표기법으로 되어 있습니다.

다음 AzureCloud 태그에는 일반 스키마에 따라 서식이 지정된 지역 이름이 없습니다.

• AzureCloud.centralfrance(FranceCentral)
• AzureCloud.southfrance(FranceSouth)
• AzureCloud.germanywc(GermanyWestCentral)
• AzureCloud.germanyn(GermanyNorth)
• AzureCloud.norwaye(NorwayEast)
• AzureCloud.norwayw(NorwayWest)
• AzureCloud.switzerlandn(SwitzerlandNorth)
• AzureCloud.switzerlandw(SwitzerlandWest)
• AzureCloud.usstagee(EastUSSTG)
• AzureCloud.usstagec(SouthCentralUSSTG)
• AzureCloud.brazilse(BrazilSoutheast)

• 네트워크 보안 그룹 만들기에 대해 알아보세요.