가상 네트워크에 대한 방화벽 및 Application Gateway

Azure 애플리케이션 워크로드를 보호하려면 애플리케이션 자체에서 인증 및 암호화와 같은 보호 조치를 사용해야 합니다. 애플리케이션을 호스트하는 VNet(가상 네트워크)에 보안 계층을 추가할 수도 있습니다. 이러한 보안 계층은 의도하지 않은 사용률로부터 애플리케이션의 인바운드 흐름을 보호합니다. 또한 인터넷에 대한 아웃바운드 흐름을 애플리케이션에 필요한 엔드포인트로만 제한합니다. 이 문서에서는 Azure DDoS Protection, Azure Firewall 및 Azure Application Gateway와 같은 Azure Virtual Network 보안 서비스에 , 각 서비스를 사용하는 경우 및 둘 모두를 결합하는 네트워크 디자인 옵션에 대해 설명합니다.

• Azure DDoS Protection애플리케이션 디자인 모범 사례와 결합하여 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 더 많은 방어를 제공합니다. 경계 가상 네트워크에서 Azure DDOS Protection 사용하도록 설정해야 합니다.
• Azure Firewall NAT(네트워크 주소 변환)제공하는 관리형 차세대 방화벽입니다. Azure Firewall은 IP(인터넷 프로토콜) 주소 및 전송 제어 프로토콜 및 TCP/UDP(사용자 데이터그램 프로토콜) 포트 또는 애플리케이션 기반 HTTP(S) 또는 SQL 특성에서 패킷 필터링을 기반으로 합니다. 또한 Azure Firewall은 Microsoft 위협 인텔리전스를 적용하여 악의적인 IP 주소를 식별합니다. 자세한 내용은 Azure Firewall 설명서참조하세요.
• Azure Firewall Premium에는 Azure Firewall Standard의 모든 기능과 TLS 검사 및 IDPS(침입 감지 및 보호 시스템)와 같은 기타 기능이 포함됩니다.
• Azure Application Gateway SSL(Secure Socket Layer) 암호화 및 암호 해독을 수행할 수 있는 관리되는 웹 트래픽 부하 분산 장치 및 HTTP(S) 전체 역방향 프록시입니다. Application Gateway는 XForwarded-For HTTP 헤더에서 원래 클라이언트 IP 주소를 유지합니다. 또한 Application Gateway는 웹 애플리케이션 방화벽을 사용하여 웹 트래픽을 검사하고 HTTP 계층에서 공격을 검색합니다. 자세한 내용은 Application Gateway 설명서참조하세요.
• azure WaF(Web Application Firewall) Azure Application Gateway에 대한 선택적 추가 사항입니다. HTTP 요청을 검사하고 SQL 삽입 또는 사이트 간 스크립팅과 같은 웹 계층에서 악의적인 공격을 방지합니다. 자세한 내용은웹 애플리케이션 방화벽 설명서를 참조하세요.

이러한 Azure 서비스는 보완적입니다. 하나 또는 다른 하나는 워크로드에 가장 적합하거나 네트워크 및 애플리케이션 계층 모두에서 최적의 보호를 위해 함께 사용할 수 있습니다. 다음 의사 결정 트리와 이 문서의 예제를 사용하여 애플리케이션의 가상 네트워크에 가장 적합한 보안 옵션을 결정합니다.

Azure Firewall 및 Azure Application Gateway는 다양한 기술을 사용하며 다양한 흐름의 보안화를 지원합니다.

애플리케이션에 필요한 네트워크 흐름에 따라 애플리케이션별로 디자인이 다를 수 있습니다. 다음 다이어그램은 애플리케이션에 권장되는 방법을 선택하는 데 도움이 되는 간소화된 의사 결정 트리를 제공합니다. 결정은 애플리케이션이 HTTP(S)를 통해 게시되는지 또는 다른 프로토콜을 통해 게시되는지에 따라 달라집니다.

가상 네트워크 보안 의사 결정 트리를 보여 주는

이 문서에서는 흐름도에서 널리 권장되는 디자인과 덜 일반적인 시나리오에 적용할 수 있는 다른 디자인에 대해 설명합니다.

• 가상 네트워크에 웹 애플리케이션이 없는 경우 azure Firewall만. 애플리케이션에 대한 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어합니다.
• Application Gateway만, 웹 애플리케이션만 가상 네트워크에 있고 NSG(네트워크 보안 그룹)가 충분한 출력 필터링을 제공할 있습니다. Azure Firewall에서 제공하는 기능은 많은 공격 시나리오(예: 데이터 반출, IDPS 등)를 방지할 수 있습니다. 이러한 이유로 Application Gateway만의 시나리오는 일반적으로 권장되지 않으므로 문서화되지 않으며 위의 흐름 차트에 없습니다.
• 가장 일반적인 디자인 중 하나인 병렬Azure Firewall 및 Application Gateway를 . Azure Application Gateway가 웹 공격으로부터 HTTP(S) 애플리케이션을 보호하고 Azure Firewall이 다른 모든 워크로드를 보호하고 아웃바운드 트래픽을 필터링하려는 경우 이 조합을 사용합니다.
• Azure Firewall앞에 Application Gateway를 Azure Firewall이 모든 트래픽을 검사하고 WAF가 웹 트래픽을 보호하고 애플리케이션이 클라이언트의 원본 IP 주소를 알도록 합니다. Azure Firewall Premium 및 TLS 검사를 통해 이 디자인은 엔드투엔드 SSL 시나리오도 지원합니다.
• Application Gateway앞에서 Azure Firewall을 Azure Firewall이 Application Gateway에 도달하기 전에 트래픽을 검사하고 필터링하도록 할 때 Azure Firewall은 HTTPS 트래픽의 암호를 해독하지 않으므로 Application Gateway에 추가하는 기능이 제한됩니다. 이 시나리오는 위의 흐름도에 설명되어 있지 않습니다.

이 문서의 마지막 부분에서는 이전 기본 디자인의 변형에 대해 설명합니다. 이러한 변형은 다음과 같습니다.

• 온-프레미스 애플리케이션 클라이언트.
• 허브 및 스포크 네트워크는.
• AKS(Azure Kubernetes Service) 구현을 .

API Management 게이트웨이 또는 Azure Front Door같은 다른 역방향 프록시 서비스를 추가할 수 있습니다. 또는 Azure 리소스를타사 네트워크 가상 어플라이언스로 바꿀 수 있습니다.

Azure Firewall만 해당

WAF의 이점을 얻을 수 있는 가상 네트워크에 웹 기반 워크로드가 없는 경우 Azure Firewall만 사용할 수 있습니다. 이 경우 디자인은 간단하지만 패킷 흐름을 검토하면 더 복잡한 디자인을 이해하는 데 도움이 됩니다. 이 디자인에서 모든 인바운드 트래픽은 온-프레미스 또는 다른 Azure VNet의 연결을 위해 UDR(사용자 정의 경로)을 통해 Azure Firewall로 전송됩니다. 아래 다이어그램과 같이 공용 인터넷에서 연결하기 위해 Azure Firewall의 공용 IP 주소로 주소가 지정됩니다. Azure VNet의 아웃바운드 트래픽은 아래 대화 상자와 같이 UDR을 통해 방화벽으로 전송됩니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

Azure Firewall은 인바운드 HTTP(S) 트래픽을 검사하지 않습니다. 그러나 계층 3 & 계층 4 규칙 및 FQDN 기반 애플리케이션 규칙을 적용할 수 있습니다. Azure Firewall은 Azure Firewall 계층 및 TLS 검사를 구성하는지 여부에 따라 아웃바운드 HTTP(S) 트래픽을 검사합니다.

• Azure Firewall Standard는 네트워크 규칙에서 패킷의 계층 3 & 계층 4 특성과 애플리케이션 규칙의 호스트 HTTP 헤더만 검사합니다.
• Azure Firewall Premium은 다른 HTTP 헤더(예: User-Agent)를 검사하고 더 심층적인 패킷 분석을 위해 TLS 검사를 사용하도록 설정하는 등의 기능을 추가합니다. Azure Firewall은 웹 애플리케이션 방화벽과 동일하지 않습니다. Virtual Network에 웹 워크로드가 있는 경우 WAF를 사용하는 것이 좋습니다.

다음 패킷 워크 예제에서는 클라이언트가 공용 인터넷에서 VM 호스팅 애플리케이션에 액세스하는 방법을 보여줍니다. 다이어그램에는 단순성을 위해 하나의 VM만 포함됩니다. 고가용성 및 확장성을 위해 부하 분산 장치 뒤에 여러 애플리케이션 인스턴스가 있습니다. 이 디자인에서 Azure Firewall은 공용 인터넷에서 들어오는 연결과 UDR을 사용하여 애플리케이션 서브넷 VM의 아웃바운드 연결을 모두 검사합니다.

• Azure Firewall 서비스는 프런트 엔드 IP 주소 192.168.100.4 및 범위 192.168.100.0/26의 내부 주소를 사용하여 여러 인스턴스를 커버 아래에 배포합니다. 이러한 개별 인스턴스는 일반적으로 Azure 관리자에게 표시되지 않습니다. 그러나 네트워크 문제를 해결할 때와 같은 경우에 차이점을 알아차리는 것이 유용합니다.
• 트래픽이 인터넷 대신 온-프레미스 VPN(가상 사설망) 또는 Azure ExpressRoute 게이트웨이에서 오는 경우 클라이언트는 VM의 IP 주소에 대한 연결을 시작합니다. 방화벽의 IP 주소에 대한 연결을 시작하지 않으며 방화벽은 기본값당 원본 NAT를 수행하지 않습니다.

건축학

다음 다이어그램에서는 인스턴스 IP 주소가 192.168.100.7가정하는 트래픽 흐름을 보여 줍니다.

Azure Firewall만 표시하는

워크플로

1. 클라이언트는 Azure Firewall의 공용 IP 주소에 대한 연결을 시작합니다.
   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AzFwPIP
2. Azure Firewall 공용 IP에 대한 요청은 방화벽의 백 엔드 인스턴스(이 경우 192.168.100.7)에 배포됩니다. Azure Firewall DNAT(대상 NAT) 규칙 대상 IP 주소를 가상 네트워크 내의 애플리케이션 IP 주소로 변환합니다. Azure Firewall은 DNAT를 수행하는 경우 패킷을 SNAT(원본 NAT)도 . 자세한 내용은알려진 Azure Firewall 문제 참조하세요. VM은 들어오는 패킷에 다음과 같은 IP 주소를 표시합니다.
   • 원본 IP 주소: 192.168.100.7
   • 대상 IP 주소: 192.168.1.4
3. VM은 원본 및 대상 IP 주소를 반전하여 애플리케이션 요청에 응답합니다. 원본 IP가 Azure Firewall의 IP 주소이므로 인바운드 흐름에 UDR(사용자 정의 경로)필요하지 않습니다. 0.0.0.0/0 다이어그램의 UDR은 아웃바운드 연결을 위한 것으로, 공용 인터넷에 대한 패킷이 Azure Firewall을 통과하도록 합니다.
   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.100.7
4. 마지막으로 Azure Firewall은 SNAT 및 DNAT 작업을 실행 취소하고 클라이언트에 응답을 제공합니다.
   • 원본 IP 주소: AzFwPIP
   • 대상 IP 주소: ClientPIP

Application Gateway만

이 디자인은 가상 네트워크에 웹 애플리케이션만 존재하는 상황을 다루며, NSG를 사용하여 아웃바운드 트래픽을 검사하는 것만으로도 인터넷으로의 아웃바운드 흐름을 보호할 수 있습니다.

이전 디자인과 Azure Firewall만의 주요 차이점은 Application Gateway가 NAT를 사용하는 라우팅 디바이스 역할을 하지 않는다는 것입니다. 전체 역방향 애플리케이션 프록시로 동작합니다. 즉, Application Gateway는 클라이언트에서 웹 세션을 중지하고 백 엔드 서버 중 하나를 사용하여 별도의 세션을 설정합니다. 인터넷의 인바운드 HTTP(S) 연결은 Application Gateway의 공용 IP 주소, Azure 또는 온-프레미스에서 게이트웨이의 개인 IP 주소로의 연결로 전송되어야 합니다. Azure VM에서 트래픽을 반환하면 Application Gateway로 다시 라우팅되는 표준 VNet을 따릅니다(자세한 내용은 패킷 연습 참조). Azure VM의 아웃바운드 인터넷 흐름은 인터넷으로 바로 이동합니다.

다음 표에서는 트래픽 흐름을 요약합니다.

건축학

다음 패킷 워크 예제에서는 클라이언트가 공용 인터넷에서 VM 호스팅 애플리케이션에 액세스하는 방법을 보여줍니다.

Application Gateway만 표시하는

워크플로

1. 클라이언트는 Azure Application Gateway의 공용 IP 주소에 대한 연결을 시작합니다.
   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AppGwPIP
2. Application Gateway 공용 IP에 대한 요청은 게이트웨이의 백 엔드 인스턴스(이 경우 192.168.200.7)에 배포됩니다. 요청을 수신하는 Application Gateway 인스턴스는 클라이언트에서 연결을 중지하고 백 엔드 중 하나를 사용하여 새 연결을 설정합니다. 백 엔드는 Application Gateway 인스턴스를 원본 IP 주소로 봅니다. Application Gateway는 원래 클라이언트 IP 주소가 있는 X-Forwarded-For HTTP 헤더를 삽입합니다.
   • 원본 IP 주소: 192.168.200.7(Application Gateway 인스턴스의 개인 IP 주소)
   • 대상 IP 주소: 192.168.1.4
   • XForwarded-For 헤더: ClientPIP
3. VM은 원본 및 대상 IP 주소를 반전하여 애플리케이션 요청에 응답합니다. VM은 Application Gateway에 도달하는 방법을 이미 알고 있으므로 UDR이 필요하지 않습니다.
   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7
4. 마지막으로 Application Gateway 인스턴스는 클라이언트에 응답합니다.
   • 원본 IP 주소: AppGwPIP
   • 대상 IP 주소: ClientPIP

Azure Application Gateway는 원래 클라이언트의 IP 주소를 포함하는 X-Forwarded-For 헤더와 같은 패킷 HTTP 헤더에 메타데이터를 추가합니다. 일부 애플리케이션 서버는 지리적 위치별 콘텐츠를 제공하거나 로깅을 위해 원본 클라이언트 IP 주소가 필요합니다. 자세한 내용은 애플리케이션 게이트웨이가작동하는 방법을 참조하세요.

• IP 주소 192.168.200.7 Azure Application Gateway 서비스가 내부 프라이빗 프런트 엔드 IP 주소 192.168.200.4함께 배포하는 인스턴스 중 하나입니다. 이러한 개별 인스턴스는 일반적으로 Azure 관리자에게 표시되지 않습니다. 그러나 네트워크 문제를 해결할 때와 같은 경우에 차이점을 알아차리는 것이 유용합니다.

• 클라이언트가 VPN 또는 ExpressRoute 게이트웨이를 통해 온-프레미스 네트워크에서 온 경우 흐름은 비슷합니다. 차이점은 클라이언트가 공용 주소 대신 Application Gateway의 개인 IP 주소에 액세스하는 것입니다.

방화벽 및 Application Gateway 병렬

단순성과 유연성으로 인해 Application Gateway 및 Azure Firewall을 병렬로 실행하는 것이 가장 좋은 시나리오인 경우가 많습니다.

가상 네트워크에 웹 워크로드와 웹이 아닌 워크로드가 혼합된 경우 이 디자인을 구현합니다. Azure Application Gateway의 Azure WAF는 웹 워크로드에 대한 인바운드 트래픽을 보호하고 Azure Firewall은 다른 애플리케이션에 대한 인바운드 트래픽을 검사합니다. Azure Firewall은 두 워크로드 유형의 아웃바운드 흐름을 모두 다룹니다.

인터넷의 인바운드 HTTP(S) 연결은 Azure 또는 온-프레미스에서 개인 IP 주소로 Application Gateway, HTTP(S) 연결의 공용 IP 주소로 전송되어야 합니다. 표준 VNet 라우팅은 Application Gateway에서 대상 VM으로 패킷을 보내고 대상 VM에서 Application Gateway로 다시 보냅니다(자세한 내용은 패킷 연습 참조). 인바운드 비 HTTP(S) 연결의 경우 트래픽은 Azure Firewall의 공용 IP 주소(공용 인터넷에서 오는 경우)를 대상으로 하거나 UDR(다른 Azure VNet 또는 온-프레미스 네트워크에서 오는 경우)을 통해 Azure Firewall을 통해 전송됩니다. Azure VM의 모든 아웃바운드 흐름은 UDR을 통해 Azure Firewall로 전달됩니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

이 디자인은 NSG보다 훨씬 더 세분화된 송신 필터링을 제공합니다. 예를 들어 애플리케이션이 특정 Azure Storage 계정에 연결해야 하는 경우 FQDN(정규화된 도메인 이름)기반 필터를 사용할 수 있습니다. FQDN 기반 필터를 사용하면 애플리케이션이 불량 스토리지 계정에 데이터를 보내지 않습니다. 이 시나리오는 NSG를 사용하는 것만으로는 방지할 수 없습니다. 이 디자인은 아웃바운드 트래픽에 FQDN 기반 필터링이 필요한 경우 자주 사용됩니다. 한 가지 예시 상황은 Azure Kubernetes Services 클러스터송신 트래픽을 제한하는 경우입니다.

아키텍처

다음 다이어그램은 외부 클라이언트에서 인바운드 HTTP(S) 연결에 대한 트래픽 흐름을 보여 줍니다.

Application Gateway 및 Azure Firewall을 병렬, 수신 흐름으로 보여 주는

다음 다이어그램은 네트워크 VM에서 인터넷으로의 아웃바운드 연결에 대한 트래픽 흐름을 보여 줍니다. 한 가지 예는 백 엔드 시스템에 연결하거나 운영 체제 업데이트를 가져오는 것입니다.

Application Gateway 및 Azure Firewall을 병렬 송신 흐름으로 보여 주는

각 서비스에 대한 패킷 흐름 단계는 이전 독립 실행형 디자인 옵션과 동일합니다.

방화벽 앞의 Application Gateway

이 디자인은 Azure Firewall 및 Application Gateway사용하는 웹 애플리케이션에 대한 제로 트러스트 네트워크 자세히 설명되어 있습니다. 이 문서에서는 다른 디자인 옵션과의 비교에 중점을 줍니다. 이 토폴로지에서 인바운드 웹 트래픽은 Azure Firewall과 WAF를 모두 통과합니다. WAF는 웹 애플리케이션 계층에서 보호를 제공합니다. Azure Firewall은 중앙 로깅 및 제어 지점 역할을 하며 Application Gateway와 백 엔드 서버 간의 트래픽을 검사합니다. Application Gateway와 Azure Firewall은 병렬로 앉아 있지 않고 서로 1씩 연결됩니다.

Azure Firewall Premium이 디자인은 Azure Firewall이 TLS 검사를 적용하여 Application Gateway와 웹 백 엔드 간의 암호화된 트래픽에서 IDPS를 수행하는 엔드투엔드 시나리오를 지원할 수 있습니다.

이 디자인은 들어오는 클라이언트 원본 IP 주소(예: 지리적 위치별 콘텐츠 제공 또는 로깅)를 알아야 하는 애플리케이션에 적합합니다. Azure Firewall 앞의 Application Gateway는 X 전달 헤더에서 들어오는 패킷의 원본 IP 주소를 캡처하므로 웹 서버는 이 헤더에서 원래 IP 주소를 볼 수 있습니다. 자세한 내용은 애플리케이션 게이트웨이가작동하는 방법을 참조하세요.

인터넷의 인바운드 HTTP(S) 연결은 Application Gateway의 공용 IP 주소, Azure 또는 온-프레미스에서 개인 IP 주소로의 HTTP(S) 연결로 전송되어야 합니다. Application Gateway UDR에서 패킷이 Azure Firewall을 통해 라우팅되는지 확인합니다(자세한 내용은 패킷 연습 참조). 인바운드 비 HTTP(S) 연결의 경우 트래픽은 Azure Firewall의 공용 IP 주소(공용 인터넷에서 오는 경우)를 대상으로 하거나 UDR(다른 Azure VNet 또는 온-프레미스 네트워크에서 오는 경우)을 통해 Azure Firewall을 통해 전송됩니다. Azure VM의 모든 아웃바운드 흐름은 UDR을 통해 Azure Firewall로 전달됩니다.

이 디자인의 중요한 설명은 Azure Firewall Premium이 Application Gateway 서브넷의 원본 IP 주소를 사용하여 트래픽을 볼 수 있다는 것입니다. 이 서브넷이 개인 IP 주소(10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 또는 100.64.0.0/10)로 구성된 경우 Azure Firewall Premium은 Application Gateway의 트래픽을 내부로 처리하고 인바운드 트래픽에 대한 IDPS 규칙을 적용하지 않습니다. Azure Firewall IDPS 규칙Azure Firewall IDPS 규칙 지침 및 IDPS에 대한 개인 IP 접두사에 대한 자세한 정보를 확인할 수 있습니다. 따라서 애플리케이션 게이트웨이 서브넷이 내부 원본으로 간주되지 않도록 Azure Firewall 정책에서 IDPS 프라이빗 접두사를 수정하여 트래픽에 인바운드 및 아웃바운드 IDPS 서명을 적용하는 것이 좋습니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

온-프레미스 또는 인터넷에서 Azure로의 웹 트래픽의 경우 Azure Firewall은 WAF가 이미 허용한 흐름을 검사합니다. Application Gateway가 백 엔드 트래픽(Application Gateway에서 애플리케이션 서버로의 트래픽)을 암호화하는지 여부에 따라 다음과 같은 다양한 잠재적 시나리오가 있습니다.

1. Application Gateway는 제로 트러스트 원칙(엔드투엔드 TLS 암호화)에 따라 트래픽을 암호화하고 Azure Firewall은 암호화된 트래픽을 수신합니다. 그러나 Azure Firewall Standard는 네트워크 규칙의 계층 3 & 계층 4 필터링 또는 TLS SNI(서버 이름 표시) 헤더를 사용하여 애플리케이션 규칙에서 FQDN 필터링과 같은 검사 규칙을 적용할 수 있습니다. Azure Firewall Premium URL 기반 필터링과 같은 TLS 검사를 통해 보다 심층적인 가시성을 제공합니다.
2. Application Gateway가 암호화되지 않은 트래픽을 애플리케이션 서버로 보내는 경우 Azure Firewall은 인바운드 트래픽을 명확한 텍스트로 표시합니다. Azure Firewall에서는 TLS 검사가 필요하지 않습니다.
3. Azure Firewall에서 IDPS를 사용하는 경우 HTTP 호스트 헤더가 대상 IP와 일치하는지 확인합니다. 이를 위해서는 호스트 헤더에 지정된 FQDN에 대한 이름 확인이 필요합니다. 이 이름 확인은 Azure DNS를 사용하여 Azure DNS 프라이빗 영역 및 기본 Azure Firewall DNS 설정을 사용하여 수행할 수 있습니다. Azure Firewall 설정에서 구성해야 하는 사용자 지정 DNS 서버를 사용하여 수행할 수도 있습니다. (자세한 내용은 azure Firewall DNS 설정참조하세요.) Azure Firewall이 배포된 Virtual Network에 대한 관리 액세스 권한이 없는 경우 후자의 방법만 가능합니다. 한 가지 예는 Virtual WAN 보안 허브에 배포된 Azure Firewall을 사용하는 것입니다.

건축학

나머지 흐름(인바운드 비 HTTP(S) 트래픽 및 아웃바운드 트래픽)의 경우 Azure Firewall은 적절한 경우 IDPS 검사 및 TLS 검사를 제공합니다. 또한 DNS를 기반으로 네트워크 규칙에서 FQDN 기반 필터링을 제공합니다.

Azure Firewall 앞에 Application Gateway를 보여 주는

워크플로

공용 인터넷의 네트워크 트래픽은 다음 흐름을 따릅니다.

1. 클라이언트는 Azure Application Gateway의 공용 IP 주소에 대한 연결을 시작합니다.
   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AppGwPIP
2. Application Gateway 공용 IP에 대한 요청은 게이트웨이의 백 엔드 인스턴스(이 경우 192.168.200.7)에 배포됩니다. Application Gateway 인스턴스는 클라이언트에서 연결을 중지하고 백 엔드 중 하나를 사용하여 새 연결을 설정합니다. Application Gateway 서브넷에서 192.168.1.0/24 UDR은 대상 IP를 웹 애플리케이션에 유지하면서 Azure Firewall에 패킷을 전달합니다.
   • 원본 IP 주소: 192.168.200.7(Application Gateway 인스턴스의 개인 IP 주소)
   • 대상 IP 주소: 192.168.1.4
   • XForwarded-For 헤더: ClientPIP
3. 트래픽이 개인 IP 주소로 전달되므로 Azure Firewall은 트래픽을 SNAT하지 않습니다. 규칙이 허용하는 경우 애플리케이션 VM에 트래픽을 전달합니다. 자세한 내용은 Azure Firewall SNAT참조하세요. 그러나 트래픽이 방화벽의 애플리케이션 규칙에 도달하면 Azure Firewall이 연결을 프록시하므로 워크로드에 패킷을 처리한 특정 방화벽 인스턴스의 원본 IP 주소가 표시됩니다.
   • 트래픽이 Azure Firewall 네트워크 규칙에 의해 허용되는 경우 원본 IP 주소: 192.168.200.7(Application Gateway 인스턴스 중 하나의 개인 IP 주소).
   • 트래픽이 Azure Firewall 애플리케이션 규칙에 의해 허용되는 경우 원본 IP 주소: 192.168.100.7(Azure Firewall 인스턴스 중 하나의 개인 IP 주소).
   • 대상 IP 주소: 192.168.1.4
   • XForwarded-For 헤더: ClientPIP
4. VM이 요청에 응답하여 원본 및 대상 IP 주소를 반전합니다. 192.168.200.0/24 UDR은 Application Gateway로 다시 전송된 패킷을 캡처하고 대상 IP를 Application Gateway로 유지하면서 Azure Firewall로 리디렉션합니다.
   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7
5. 여기서도 Azure Firewall은 개인 IP 주소로 이동하고 트래픽을 Application Gateway로 전달하므로 트래픽을 SNAT하지 않습니다.
   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7
6. 마지막으로 Application Gateway 인스턴스는 클라이언트에 응답합니다.
   • 원본 IP 주소: AppGwPIP
   • 대상 IP 주소: ClientPIP

VM에서 공용 인터넷으로의 아웃바운드 흐름은 UDR에서 정의한 대로 Azure Firewall을 통해 0.0.0.0/0.

방화벽 이후의 Application Gateway

이 디자인을 통해 Azure Firewall은 Application Gateway에 도달하기 전에 악성 트래픽을 필터링하고 삭제할 수 있습니다. 예를 들어 위협 인텔리전스 기반 필터링과 같은 기능을 적용할 수 있습니다. 또 다른 이점은 애플리케이션이 프로토콜에 관계없이 인바운드 및 아웃바운드 트래픽 모두에 대해 동일한 공용 IP 주소를 얻는다는 것입니다. 그러나 Azure Firewall은 들어오는 트래픽을 SNAT하므로 애플리케이션은 HTTP 요청의 원래 IP 주소에 대한 가시성을 갖지 않습니다. 관리 관점에서 예를 들어 문제 해결을 위해 Azure Firewall의 SNAT 로그와 상관 관계를 지정하여 특정 연결에 대한 실제 클라이언트 IP를 가져올 수 있습니다.

Azure Firewall은 Application Gateway로 가는 암호화된 트래픽만 표시되므로 이 시나리오에는 제한된 이점이 있습니다. 이 디자인을 선호하는 시나리오가 있을 수 있습니다. 한 가지 경우는 다른 WAF가 네트워크의 앞부분에 있는 경우(예: Azure Front Door포함) X-Forwarded-For HTTP 헤더에서 원래 원본 IP를 캡처할 수 있는 경우입니다. 또는 많은 공용 IP 주소가 필요한 경우 디자인을 사용하는 것이 좋습니다.

공용 인터넷의 HTTP(S) 인바운드 흐름은 Azure Firewall의 공용 IP 주소를 대상으로 해야 하며, Azure Firewall은 패킷을 Application Gateway의 개인 IP 주소로 DNAT(및 SNAT)합니다. 다른 Azure VNet 또는 온-프레미스 네트워크에서 HTTP(S) 트래픽은 Application Gateway의 개인 IP로 전송되고 UDR을 사용하여 Azure Firewall을 통해 전달되어야 합니다. 표준 VNet 라우팅을 사용하면 AZURE VM의 반환 트래픽이 Application Gateway로 돌아가고, DNAT 규칙이 사용된 경우 Application Gateway에서 Azure Firewall로 돌아갑니다. 온-프레미스 또는 Application Gateway 서브넷의 Azure UDR에서 트래픽을 사용해야 합니다(자세한 내용은 패킷 연습 참조). Azure VM에서 인터넷으로의 모든 아웃바운드 트래픽은 UDR을 통해 Azure Firewall을 통해 전송됩니다.

다음 표에서는 이 시나리오의 트래픽 흐름을 요약합니다.

인바운드 HTTP(S) 트래픽의 경우 Azure Firewall은 일반적으로 트래픽의 암호를 해독하지 않습니다. 대신 IP 기반 필터링 또는 HTTP 헤더 사용과 같이 TLS 검사가 필요하지 않은 IDPS 정책을 적용합니다.

건축학

애플리케이션은 웹 트래픽의 원래 원본 IP 주소를 볼 수 없습니다. Azure Firewall은 가상 네트워크에 들어오는 패킷을 SNAT합니다. 이 문제를 방지하려면 방화벽 앞에 Azure Front Door 사용합니다. Azure Front Door는 Azure 가상 네트워크에 들어가기 전에 클라이언트의 IP 주소를 HTTP 헤더로 삽입합니다.

Azure Firewall 이후의 Application Gateway를 보여 주는

워크플로

공용 인터넷의 네트워크 트래픽은 다음 흐름을 따릅니다.

1. 클라이언트는 Azure Firewall의 공용 IP 주소에 대한 연결을 시작합니다.
   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AzFWPIP
2. Azure Firewall 공용 IP에 대한 요청은 방화벽의 백 엔드 인스턴스(이 경우 192.168.100.7)에 배포됩니다. Azure Firewall은 웹 포트(일반적으로 TCP 443)를 Application Gateway 인스턴스의 개인 IP 주소로 DNAT합니다. DNAT를 수행할 때 Azure Firewall도 SNAT를 수행합니다. 자세한 내용은 Azure Firewall 알려진 문제참조하세요.
   • 원본 IP 주소: 192.168.100.7(Azure Firewall 인스턴스의 개인 IP 주소)
   • 대상 IP 주소: 192.168.200.4
3. Application Gateway는 연결을 처리하는 인스턴스와 백 엔드 서버 중 하나 간에 새 세션을 설정합니다. 클라이언트의 원래 IP 주소가 패킷에 없습니다.
   • 원본 IP 주소: 192.168.200.7(Application Gateway 인스턴스의 개인 IP 주소)
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-For 헤더: 192.168.100.7
4. VM은 Application Gateway에 응답하여 원본 및 대상 IP 주소를 반전합니다.
   • 원본 IP 주소: 192.168.1.4
   • 대상 IP 주소: 192.168.200.7
5. Application Gateway는 Azure Firewall 인스턴스의 SNAT 원본 IP 주소에 회신합니다. 연결이 .7같은 특정 Application Gateway 인스턴스에서 오는 경우에도 Azure Firewall은 Application Gateway .4 내부 IP 주소를 원본 IP로 봅니다.
   • 원본 IP 주소: 192.168.200.4
   • 대상 IP 주소: 192.168.100.7
6. 마지막으로 Azure Firewall은 SNAT 및 DNAT를 실행 취소하고 클라이언트에 응답합니다.
   • 원본 IP 주소: AzFwPIP
   • 대상 IP 주소: ClientPIP

Application Gateway에 애플리케이션에 대해 구성된 수신기가 없더라도 Microsoft에서 관리할 수 있도록 공용 IP 주소가 필요합니다.

온-프레미스 클라이언트

앞의 디자인은 모두 공용 인터넷에서 들어오는 애플리케이션 클라이언트를 보여 줍니다. 온-프레미스 네트워크도 애플리케이션에 액세스합니다. 앞의 대부분의 정보 및 트래픽 흐름은 인터넷 클라이언트와 동일하지만 몇 가지 주목할 만한 차이점이 있습니다.

• VPN Gateway 또는 ExpressRoute 게이트웨이는 Azure Firewall 또는 Application Gateway 앞에 있습니다.
• WAF는 Application Gateway의 개인 IP 주소를 사용합니다.
• Azure Firewall은 개인 IP 주소에 대한 DNAT를 지원하지 않습니다. 따라서 UDR을 사용하여 VPN 또는 ExpressRoute 게이트웨이에서 Azure Firewall로 인바운드 트래픽을 보내야 합니다.
• Azure Application Gateway 및 Azure Firewall강제 터널링 대한 주의 사항을 확인해야 합니다. 워크로드에 공용 인터넷에 대한 아웃바운드 연결이 필요하지 않더라도 온-프레미스 네트워크를 가리키는 Application Gateway에 대한 0.0.0.0/0 같은 기본 경로를 삽입하거나 제어 트래픽을 중단합니다. Azure Application Gateway의 경우 기본 경로가 공용 인터넷을 가리킵니다.

건축학

다음 다이어그램에서는 Azure Application Gateway 및 Azure Firewall 병렬 디자인을 보여 줍니다. 애플리케이션 클라이언트는 VPN 또는 ExpressRoute를 통해 Azure에 연결된 온-프레미스 네트워크에서 제공됩니다.

VPN 또는 ExpressRoute 게이트웨이를 사용하는 하이브리드 디자인을 보여 주는

모든 클라이언트가 온-프레미스 또는 Azure에 있더라도 Azure Application Gateway 및 Azure Firewall에는 공용 IP 주소가 있어야 합니다. 공용 IP 주소를 사용하면 Microsoft에서 서비스를 관리할 수 있습니다.

허브 및 스포크 토폴로지

이 문서의 디자인은 여전히 허브 및 스포크 토폴로지에서 적용됩니다. 중앙 허브 가상 네트워크의 공유 리소스는 가상 네트워크 피어링을 통해 별도의 스포크 가상 네트워크의 애플리케이션에 연결됩니다.

건축학

VPN/ER 게이트웨이 및 허브 및 스포크 토폴로지로 하이브리드 디자인을 보여 주는

고려 사항

이 토폴로지의 몇 가지 고려 사항은 다음과 같습니다.

• Azure Firewall은 중앙 허브 가상 네트워크에 배포됩니다. 위의 다이어그램은 허브에 Application Gateway를 배포하는 방법을 보여 줍니다. 하지만 애플리케이션 팀은 Azure Application Gateway 또는 Azure API Management 게이트웨이와 같은 구성 요소를 관리하는 경우가 많습니다. 이 경우 이러한 구성 요소는 스포크 가상 네트워크에 배포됩니다.
• 스포크 네트워크의 UDR에 특히 주의: 스포크에 있는 애플리케이션 서버가 이전 예제의 192.168.100.7 주소와 같이 특정 Azure Firewall 인스턴스에서 트래픽을 수신하는 경우 반환 트래픽을 동일한 인스턴스로 다시 보내야 합니다. 스포크에서 UDR이 허브에 주소가 지정된 트래픽의 다음 홉을 위의 다이어그램에서192.168.100.4 Azure Firewall IP 주소로 설정하는 경우 반환 패킷이 다른 Azure Firewall 인스턴스에서 종료되어 비대칭 라우팅이 발생할 수 있습니다. Azure Firewall을 통해 허브의 공유 서비스로 트래픽을 보낼 스포크 VNet에 UDR이 있는 경우 이러한 UDR에는 Azure Firewall 서브넷의 접두사를 포함하지 않는지 확인합니다.
• 이전 권장 사항은 Application Gateway 서브넷 및 허브 VNet에 배포될 수 있는 다른 네트워크 가상 어플라이언스 또는 역방향 프록시에 동일하게 적용됩니다.
• 다음 홉 유형의 Virtual Network있는 정적 경로를 통해 Application Gateway 또는 Azure Firewall 서브넷에 대한 다음 홉을 설정할 수 없습니다. 이 다음 홉 형식은 VNet 피어링이 아닌 로컬 VNet에서만 유효합니다. 사용자 정의 경로 및 다음 홉 유형에 대한 자세한 내용은 가상 네트워크 트래픽 라우팅참조하세요.

비대칭 라우팅

아래 다이어그램에서는 스포크에서 SNATted 트래픽을 Azure Firewall의 ALB로 다시 보내는 방법을 보여 줍니다. 이 설정으로 인해 비대칭 라우팅이 발생합니다.

허브 및 스포크 토폴로지에서 비대칭 라우팅을 보여 주는

이 문제를 해결하려면 Azure Firewall 서브넷이 없지만 공유 서비스가 있는 서브넷만 사용하여 스포크에서 UDR을 정의합니다. 이 예제에서 스포크에서 올바른 UDR은 192.168.1.0/24만 포함해야 합니다. 빨간색으로 표시된 것처럼 전체 192.168.0.0/16을 포함해서는 안 됩니다.

다른 Azure 제품과의 통합

Azure Firewall 및 Azure Application Gateway를 다른 Azure 제품 및 서비스와 통합할 수 있습니다.

API Management 게이트웨이

API Management 게이트웨이와 같은 역방향 프록시 서비스를 이전 디자인에 통합하여 API 제한 또는 인증 프록시와 같은 기능을 제공합니다. API Management 게이트웨이를 통합해도 디자인이 크게 변경되지는 않습니다. 주요 차이점은 단일 Application Gateway 역방향 프록시 대신 서로 뒤에 연결된 두 개의 역방향 프록시가 있다는 것입니다.

자세한 내용은 가상 네트워크 API Management 및 Application Gateway를 통합하는 디자인 가이드와 마이크로 서비스용 API 게이트웨이애플리케이션 패턴을 참조하세요.

Azure Kubernetes Service

AKS 클러스터에서 실행되는 워크로드의 경우 클러스터와 독립적으로 Azure Application Gateway를 배포할 수 있습니다. 또는 Azure Application Gateway 수신 컨트롤러사용하여 AKS 클러스터와 통합할 수 있습니다. Kubernetes 수준에서 특정 개체(예: 서비스 및 수신)를 구성할 때 Application Gateway는 추가 수동 단계 없이 자동으로 조정됩니다.

Azure Firewall은 AKS 클러스터 보안에서 중요한 역할을 합니다. IP 주소뿐만 아니라 FQDN을 기반으로 AKS 클러스터에서 송신 트래픽을 필터링하는 데 필요한 기능을 제공합니다. 자세한 내용은 AKS 클러스터 노드대한 송신 트래픽 제어를 참조하세요.

Application Gateway와 Azure Firewall을 결합하여 AKS 클러스터를 보호하는 경우 병렬 디자인 옵션을 사용하는 것이 가장 좋습니다. WAF를 사용하는 Application Gateway는 클러스터의 웹 애플리케이션에 대한 인바운드 연결 요청을 처리합니다. Azure Firewall은 명시적으로 허용된 아웃바운드 연결만 허용합니다. 병렬 디자인 옵션의 예는 AKS(Azure Kubernetes Service) 클러스터 기준 아키텍처를 참조하세요.

Azure Front Door

Azure Front Door 기능은 부분적으로 Azure Application Gateway와 겹칩니다. 예를 들어 두 서비스 모두 웹 애플리케이션 방화벽, SSL 오프로드 및 URL 기반 라우팅을 제공합니다. 한 가지 주요 차이점은 Azure Application Gateway가 가상 네트워크 내에 있지만 Azure Front Door는 분산된 글로벌 서비스라는 것입니다.

Application Gateway를 분산형 Azure Front Door로 대체하여 가상 네트워크 디자인을 간소화할 수 있는 경우도 있습니다. 여기에 설명된 대부분의 디자인은 Azure Front Door 앞에 Azure Firewall을 배치하는 옵션을 제외하고 유효합니다.

흥미로운 사용 사례는 가상 네트워크의 Application Gateway 앞에서 Azure Firewall을 사용하는 것입니다. 앞에서 설명한 대로 Application Gateway에서 삽입한 X-Forwarded-For 헤더에는 클라이언트의 IP 주소가 아닌 방화벽 인스턴스의 IP 주소가 포함됩니다. 해결 방법은 트래픽이 가상 네트워크에 들어가 Azure Firewall에 도달하기 전에 방화벽 앞에 Azure Front Door를 사용하여 클라이언트의 IP 주소를 X-Forwarded-For 헤더로 삽입하는 것입니다. 두 번째 옵션은 Azure Front Door PremiumPrivate Link를 사용하여 원본 보안을 것입니다.

두 서비스의 차이점 또는 각 서비스 사용 시기에 대한 자세한 내용은 Azure Front Door대한 질문과 대답을 참조하세요.

기타 네트워크 가상 어플라이언스

Microsoft 제품은 Azure에서 웹 애플리케이션 방화벽 또는 차세대 방화벽 기능을 구현하는 유일한 선택은 아닙니다. 다양한 Microsoft 파트너가 NVA(네트워크 가상 어플라이언스)를 제공합니다. 개념과 디자인은 기본적으로 이 문서와 동일하지만 몇 가지 중요한 고려 사항이 있습니다.

• 차세대 방화벽을 위한 파트너 NVA는 Azure Firewall에서 지원하지 않는 NAT 구성에 대해 더 많은 제어 및 유연성을 제공할 수 있습니다. 예를 들어 온-프레미스의 DNAT 또는 SNAT가 없는 인터넷의 DNAT가 있습니다.
• Azure 관리 NVA(예: Application Gateway 및 Azure Firewall)는 사용자가 여러 어플라이언스에서 확장성 및 복원력을 처리해야 하는 NVA에 비해 복잡성을 줄입니다.
• Azure에서 NVA를 사용하는 경우 활성-활성 사용하고 자동 크기 조정 설정을 사용하므로 이러한 어플라이언스는 가상 네트워크에서 실행되는 애플리케이션의 병목 현상이 아닙니다.

참여자

이 문서는 Microsoft에서 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

주 작성자:

• 호세 모레노 | 수석 고객 엔지니어

다음 단계

구성 요소 기술에 대해 자세히 알아보세요.

• Azure Application Gateway란?
• Azure Firewall이란?
• Azure Front Door란?
• Azure Kubernetes Service
• Azure Virtual Network란?
• Azure Web Application Firewall이란?

관련 리소스

관련 아키텍처 살펴보기:

• 보안 하이브리드 네트워크 구현
• 안전하게 관리되는 웹 애플리케이션
• 방화벽 뒤에서 Microsoft Teams 채널 봇 및 웹앱 보호
• Azure 매우 중요한 IaaS 앱에 대한 보안 고려 사항
• Azure 다중 테넌트 SaaS
• App Services Environment 사용하여 엔터프라이즈 배포
• App Services Environment 사용하여 고가용성 엔터프라이즈 배포
• AKS(Azure Kubernetes Service) 클러스터 대한 기준 아키텍처