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

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

• 애플리케이션 설계 모범 사례와 결합된 Azure DDoS Protection은 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 방어력을 높입니다. 경계 가상 네트워크에서 Azure DDOS Protection을 사용하도록 설정해야 합니다.
• Azure Firewall은 NAT(네트워크 주소 변환)를 제공하는 관리되는 차세대 방화벽입니다. Azure Firewall의 패킷 필터링은 IP(인터넷 프로토콜) 주소 및 전송 제어 프로토콜 및 TCP/UDP(Transmission Control Protocol 및 User Datagram Protocol) 포트, 또는 애플리케이션 기반 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는 X-Forwarded-For HTTP 헤더에서 원래 클라이언트 IP 주소를 유지합니다. 또한 Application Gateway는 웹 애플리케이션 방화벽을 사용하여 웹 트래픽을 검사하고 HTTP 계층에서 공격을 검색합니다. 자세한 내용은 Application Gateway 설명서를 참조하세요.
• Azure WAF(웹 애플리케이션 방화벽)는 Azure Application Gateway에 선택적으로 추가된 것입니다. HTTP 요청을 검사하고 SQL 삽입 또는 사이트 간 스크립팅과 같은 웹 계층에서 악의적인 공격을 방지합니다. 자세한 내용은 웹 애플리케이션 방화벽 설명서를 참조하세요.

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

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

애플리케이션 흐름	Azure Firewall을 통해 필터링할 수 있음	Application Gateway에서 WAF로 필터링할 수 있음
온-프레미스/인터넷에서 Azure로의 HTTP(S) 트래픽(인바운드)	예	예
Azure에서 온-프레미스/인터넷으로의 HTTP(S) 트래픽(아웃바운드)	예	예
비 HTTP(S) 트래픽, 인바운드/아웃바운드	예	예

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

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

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

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

흐름	Application Gateway/WAF를 통과	Azure Firewall을 통과
인터넷/온-프레미스에서 Azure로의 HTTP(S) 트래픽	해당 없음	예(아래 참조)
Azure에서 인터넷/온-프레미스로의 HTTP(S) 트래픽	해당 없음	예
인터넷/온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	해당 없음	예
Azure에서 인터넷/온-프레미스로의 비 HTTP(S) 트래픽	해당 없음	예

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

• Azure Firewall Standard는 네트워크 규칙에서 패킷의 계층 3 및 계층 4 특성과 애플리케이션 규칙의 호스트 HTTP 헤더만 검사합니다.
• Azure Firewall Premium은 다른 HTTP 헤더(예: 사용자 에이전트)를 검사하고 더 심층적인 패킷 분석을 위해 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임을 가정하는 트래픽 흐름을 보여 줍니다.

워크플로

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(Source 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의 아웃바운드 인터넷 흐름은 인터넷으로 바로 이동합니다.

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

흐름	Application Gateway/WAF를 통과	Azure Firewall을 통과
인터넷/온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	해당 없음
Azure에서 인터넷/온-프레미스로의 HTTP(S) 트래픽	예	해당 없음
인터넷/온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	예	해당 없음
Azure에서 인터넷/온-프레미스로의 비 HTTP(S) 트래픽	예	해당 없음

아키텍처

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

워크플로

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

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

흐름	Application Gateway/WAF를 통과	Azure Firewall을 통과
인터넷/온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	예
Azure에서 인터넷/온-프레미스로의 HTTP(S) 트래픽	예	예
인터넷/온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	예	예
Azure에서 인터넷/온-프레미스로의 비 HTTP(S) 트래픽	예	예

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

아키텍처

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

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

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

방화벽 전에 Application Gateway 사용

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

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

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

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

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

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

흐름	Application Gateway/WAF를 통과	Azure Firewall을 통과
인터넷/온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	예
Azure에서 인터넷/온-프레미스로의 HTTP(S) 트래픽	예	예
인터넷/온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	예	예
Azure에서 인터넷/온-프레미스로의 비 HTTP(S) 트래픽	예	예

온-프레미스 또는 인터넷에서 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를 사용하도록 설정하면 Azure Firewall은 HTTP 호스트 헤더가 대상 IP와 일치하는지 확인합니다. 이를 위해 호스트 헤더에 지정된 FQDN에 대한 이름 확인이 필요합니다. 이 이름 확인은 Azure DNS를 사용하여 Azure DNS Private Zones 및 기본 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 기반 필터링을 제공합니다.

워크플로

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

1. 클라이언트는 Azure 애플리케이션 게이트웨이의 공용 IP 주소에 대한 연결을 시작합니다.
   • 원본 IP 주소: ClientPIP
   • 대상 IP 주소: AppGwPIP
2. Application Gateway 공용 IP에 대한 요청은 게이트웨이의 백 엔드 인스턴스(이 경우 192.168.200.7)에 배포됩니다. Application Gateway 인스턴스는 클라이언트에서의 연결을 중지하고 백 엔드 중 하나를 사용하여 새 연결을 설정합니다. Application Gateway 서브넷의 UDR 192.168.1.0/24 은 대상 IP를 웹 애플리케이션에 유지하면서 Azure Firewall에 패킷을 전달합니다.
   • 원본 IP 주소: 192.168.200.7(Application Gateway 인스턴스의 개인 IP 주소)
   • 대상 IP 주소: 192.168.1.4
   • X-Forwarded-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
   • X-Forwarded-For 헤더: ClientPIP
4. VM은 요청에 응답하여 원본 및 대상 IP 주소를 반전합니다. 192.168.200.0/24(으)로의 UDR은 Application Gateway로 다시 전송된 패킷을 캡처하고 패킷을 Azure Firewall로 리디렉션하면서 대상 IP가 Application Gateway를 향하도록 유지합니다.
   • 원본 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에서 공용 인터넷으로의 아웃바운드 흐름은 0.0.0.0/0(으)로의 UDR에서 정의된 대로 Azure Firewall을 통해 이동합니다.

방화벽 후에 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을 통해 전송됩니다.

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

흐름	Application Gateway/WAF를 통과	Azure Firewall을 통과
인터넷/온-프레미스에서 Azure로의 HTTP(S) 트래픽	예	예(아래 참조)
Azure에서 인터넷/온-프레미스로의 HTTP(S) 트래픽	예	예
인터넷/온-프레미스에서 Azure로의 비 HTTP(S) 트래픽	예	예
Azure에서 인터넷/온-프레미스로의 비 HTTP(S) 트래픽	예	예

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

아키텍처

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

워크플로

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

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에 연결된 온-프레미스 네트워크로부터 옵니다.

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

허브 및 스포크 토폴로지

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

아키텍처

고려 사항

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

• Azure Firewall은 중앙 허브 가상 네트워크에 배포됩니다. 위의 다이어그램은 허브에 Application Gateway를 배포하는 방법을 보여 줍니다. 애플리케이션 팀이 종종 Azure Application Gateway 또는 Azure API Management 게이트웨이와 같은 구성 요소를 관리하기는 합니다. 이 경우 이러한 구성 요소는 스포크 가상 네트워크에 배포됩니다.
• 스포크 네트워크의 UDR에 특히 주의합니다. 스포크에 있는 애플리케이션 서버가 이전 예제의 192.168.100.7 주소와 같이 특정 Azure Firewall 인스턴스에서 트래픽을 수신하는 경우 반환 트래픽을 동일한 인스턴스로 다시 보내야 합니다. 스포크의 UDR이 허브에 주소가 지정된 트래픽의 다음 홉을 Azure Firewall IP 주소(위의 다이어그램에서 192.168.100.4)로 설정하는 경우 반환 패킷이 다른 Azure Firewall 인스턴스로 가게 되어 비대칭 라우팅이 발생할 수 있습니다. 스포크 VNet에 Azure Firewall을 통해 허브의 공유 서비스로 트래픽을 보낼 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 Premium에서 Private 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에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Jose Moreno | 수석 고객 엔지니어

다음 단계

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

• Azure Application Gateway란?
• Azure Firewall이란?
• Azure Front Door란?
• Azure Kubernetes Service
• Azure Virtual Network란?
• Azure 웹 애플리케이션 방화벽이란?

관련 참고 자료

관련 아키텍처 살펴보기:

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