편집

Azure Firewall 및 Application Gateway를 사용하는 웹 애플리케이션에 대한 제로 트러스트 네트워크

Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure 가상 WAN
Azure 웹 애플리케이션 방화벽

이 가이드에서는 검사 및 암호화를 위해 웹앱에 대한 제로 트러스트 보안을 구현하기 위한 전략을 간략하게 설명합니다. 제로 트러스트 패러다임에는 행위자의 ID를 지속적으로 확인하거나 암시적 신뢰 영역의 크기를 최소한으로 줄이는 것과 같은 다른 많은 개념이 포함됩니다. 이 문서에서는 공용 인터넷에서 인바운드 트래픽에 대한 제로 트러스트 아키텍처의 암호화 및 검사 구성 요소를 참조합니다. 인증과 같이 애플리케이션을 안전하게 배포하는 더 많은 측면에 대해서는 다른 제로 트러스트 문서를 읽어보세요. 이 문서의 목적을 위해 네트워크 보안이 제로 트러스트 모델의 계층 중 하나를 구성하는 다층 접근 방식이 가장 적합합니다. 이 계층에서 네트워크 어플라이언스는 패킷을 검사하여 합법적인 트래픽만 애플리케이션에 도달하는지 확인합니다.

일반적으로 다양한 유형의 네트워크 어플라이언스에서 네트워크 패킷의 다양한 측면을 검사합니다.

  • 웹 애플리케이션 방화벽은 웹 애플리케이션 계층에서 공격을 나타내는 패턴을 찾습니다.
  • 차세대 방화벽은 일반적인 위협도 찾을 수 있습니다.

경우에 따라 다양한 유형의 네트워크 보안 어플라이언스를 결합하여 보호를 강화할 수 있습니다. 별도의 가상 네트워크에 대한 방화벽 및 Application Gateway 가이드에서는 다양한 어플라이언스를 정렬하는 데 사용할 수 있는 설계 패턴에 대해 설명합니다. 이 문서는 보안을 최대화하기 위한 일반적인 패턴에 중점을 두며, 이 경우 Azure Application Gateway가 Azure Firewall 프리미엄보다 먼저 작동합니다. 다음 다이어그램에서는 이 패턴을 보여 줍니다.

Azure Firewall Premium 앞의 Application Gateway를 사용하는 웹앱 네트워크의 패킷 흐름을 보여 주는 아키텍처 다이어그램

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

이 아키텍처는 TLS(전송 계층 보안) 프로토콜을 사용하여 모든 단계에서 트래픽을 암호화합니다.

  • 클라이언트에서 부하 분산 장치인 Application Gateway에 패킷을 보냅니다. 선택적 추가 항목인 Azure Web Application Firewall을 사용하여 실행됩니다.

  • Application Gateway에서 패킷의 암호를 해독하고 웹 애플리케이션에 대한 위협을 검색합니다. 위협을 찾지 못하면 제로 트러스트 원칙을 사용하여 패킷을 암호화합니다. 그런 다음, 릴리스합니다.

  • Azure Firewall 프리미엄에서 보안 검사를 실행합니다.

  • 패킷이 테스트를 통과하면 Azure Firewall 프리미엄에서 다음 단계를 수행합니다.

    • 패킷을 암호화합니다.
    • DNS(Domain Name System) 서비스를 사용하여 애플리케이션 VM(가상 머신)을 확인합니다.
    • 패킷을 애플리케이션 VM에 전달합니다.

이 아키텍처의 다양한 검사 엔진은 트래픽 무결성을 보장합니다.

  • Web Application Firewall은 규칙을 사용하여 웹 계층에서 공격을 방지합니다. 공격의 예로 SQL 코드 삽입 및 교차 사이트 스크립팅이 있습니다. 규칙 및 OWASP(Open Web Application Security Project) 핵심 규칙 집합에 대한 자세한 내용은 Web Application Firewall CRS 규칙 그룹 및 규칙을 참조하세요.
  • Azure Firewall 프리미엄은 일반 침입 탐지 및 방지 규칙을 사용합니다. 이러한 규칙은 웹 애플리케이션을 대상으로 하는 악성 파일 및 기타 위협을 식별하는 데 도움이 됩니다.

이 아키텍처는 이 문서에서 설명하는 다양한 유형의 네트워크 설계를 지원합니다.

  • 기존 허브 및 스포크 네트워크
  • Azure Virtual WAN을 플랫폼으로 사용하는 네트워크
  • Azure Route Server를 사용하여 동적 라우팅을 간소화하는 네트워크

Azure Firewall 프리미엄 및 이름 확인

악성 트래픽을 확인하는 경우 Azure Firewall 프리미엄에서 HTTP 호스트 헤더가 패킷 IP 주소 및 TCP 포트와 일치하는지 확인합니다. 예를 들어 Application Gateway에서 웹 패킷을 172.16.1.4 IP 주소 및 443 TCP 포트로 보낸다고 가정합니다. HTTP 호스트 헤더의 값은 해당 IP 주소로 확인되어야 합니다.

HTTP 호스트 헤더는 일반적으로 IP 주소를 포함하지 않습니다. 대신 헤더에는 서버의 디지털 인증서와 일치하는 이름이 포함됩니다. 이 경우 Azure Firewall 프리미엄에서 DNS를 사용하여 호스트 헤더 이름을 IP 주소로 확인합니다. 네트워크 설계는 이후 섹션에서 설명한 대로 가장 효율적으로 작동하는 DNS 솔루션을 결정합니다.

참고

Application Gateway는 HTTP 호스트 헤더의 포트 번호를 지원하지 않습니다. 결과는 다음과 같습니다.

  • Azure Firewall 프리미엄에서 기본 HTTPS TCP 포트가 443이라고 가정합니다.
  • Application Gateway와 웹 서버 간의 연결은 비표준 포트가 아닌 443 TCP 포트만 지원합니다.

디지털 인증서

다음 다이어그램에서는 아키텍처의 TLS 세션 및 인증서에서 사용하는 CN(일반 이름) 및 CA(인증 기관)를 보여 줍니다.

부하 분산 장치가 방화벽 앞에 있을 때 웹앱 네트워크에서 사용하는 일반적인 이름 및 인증 기관을 보여 주는 아키텍처 다이어그램

TLS 연결

이 아키텍처에는 세 가지 고유한 TLS 연결이 포함됩니다. 디지털 인증서는 다음과 같이 각 연결의 유효성을 검사합니다.

클라이언트에서 Application Gateway로

Application Gateway에서 클라이언트에 표시되는 디지털 인증서를 배포합니다. DigiCert 또는 Let's Encrypt와 같은 잘 알려진 CA는 일반적으로 이러한 인증서를 발급합니다.

Application Gateway에서 Azure Firewall 프리미엄으로

TLS 트래픽의 암호를 해독하고 검사하기 위해 Azure Firewall 프리미엄에서 인증서를 동적으로 생성합니다. 또한 Azure Firewall 프리미엄은 웹 서버로 Application Gateway에 제공됩니다. 프라이빗 CA는 Azure Firewall 프리미엄에서 생성하는 인증서에 서명합니다. 자세한 내용은 Azure Firewall 프리미엄 인증서를 참조하세요. Application Gateway에서 해당 인증서의 유효성을 검사해야 합니다. 애플리케이션의 HTTP 설정에서 Azure Firewall 프리미엄이 사용하는 루트 CA를 구성합니다.

Azure Firewall 프리미엄에서 웹 서버로

Azure Firewall 프리미엄은 대상 웹 서버와 TLS 세션을 설정합니다. Azure Firewall 프리미엄에서 잘 알려진 CA가 웹 서버 TLS 패킷에 서명하는지 확인합니다.

구성 요소 역할

Application Gateway와 Azure Firewall 프리미엄은 역할이 다르므로 인증서를 서로 다르게 처리합니다.

  • Application Gateway는 역방향 웹 프록시입니다. HTTP 및 HTTPS 요청을 가로채서 악성 클라이언트로부터 웹 서버를 보호합니다. IP 주소 또는 정규화된 도메인 이름을 사용하여 Application Gateway의 백 엔드 풀에 있는 각 보호된 서버를 선언합니다. 합법적인 클라이언트는 각 애플리케이션에 액세스할 수 있어야 합니다. 따라서 퍼블릭 CA에서 서명한 디지털 인증서를 사용하여 Application Gateway를 구성합니다. 모든 TLS 클라이언트에서 수락할 CA를 사용합니다.
  • Azure Firewall 프리미엄은 정방향 웹 프록시 또는 간단히 웹 프록시입니다. 보호된 클라이언트의 TLS 호출을 가로채서 악성 웹 서버로부터 클라이언트를 보호합니다. 보호된 클라이언트에서 HTTP 요청을 수행하면 정방향 프록시는 디지털 인증서를 생성하고 이를 클라이언트에 제공하여 대상 웹 서버를 가장합니다. Azure Firewall 프리미엄에서 동적으로 생성된 인증서에 서명하는 프라이빗 CA를 사용합니다. 해당 프라이빗 CA를 신뢰하도록 보호된 클라이언트를 구성합니다. 이 아키텍처에서 Azure Firewall 프리미엄은 Application Gateway에서 웹 서버로의 요청을 보호합니다. Application Gateway는 Azure Firewall 프리미엄에서 사용하는 프라이빗 CA를 신뢰합니다.

라우팅 및 트래픽 전달

라우팅은 네트워크 디자인의 토폴로지에 따라 약간 다릅니다. 다음 섹션에서는 허브 및 스포크, Virtual WAN 및 경로 서버 토폴로지 예제의 세부 정보를 자세히 설명합니다. 그러나 모든 토폴로지에 공통적인 몇 가지 측면이 있습니다.

  • Azure 애플리케이션 게이트웨이는 항상 프록시로 동작하며, TLS 검사를 위해 구성된 경우 Azure Firewall Premium도 작동합니다. 클라이언트의 TLS 세션은 Application Gateway에 의해 종료되고 새 TLS 세션은 Azure Firewall을 향해 빌드됩니다. Azure Firewall은 Application Gateway에서 공급된 TLS 세션을 수신 및 종료하고 워크로드에 대한 새 TLS 세션을 빌드합니다. 이 사실은 Azure Firewall Premium의 IDPS 구성에 영향을 줍니다. 아래 섹션에는 이에 대한 자세한 내용이 포함되어 있습니다.
  • 워크로드에 Azure Firewall의 서브넷 IP 주소에서 들어오는 연결이 표시됩니다. 원래 클라이언트 IP 주소는 Application Gateway에 X-Forwarded-For 의해 삽입된 HTTP 헤더에 유지됩니다.
  • Application Gateway에서 워크로드로의 트래픽은 일반적으로 Application Gateway의 서브넷에 구성된 사용자 정의 경로 또는 Azure Virtual WAN 또는 Azure Route Server에서 삽입된 경로를 사용하여 Azure 라우팅 메커니즘을 사용하여 Azure Firewall로 전송됩니다. Application Gateway의 백 엔드 풀에서 Azure Firewall의 개인 IP 주소를 명시적으로 정의할 수 있지만 부하 분산 및 고정과 같은 Azure Firewall의 일부 기능을 제거하므로 기술적으로 권장되지 않습니다.

다음 섹션에서는 Azure Firewall 및 Application Gateway와 함께 사용되는 가장 일반적인 토폴로지 중 일부에 대해 자세히 설명합니다.

허브 및 스포크 토폴로지

일반적으로 허브 및 스포크 설계에서는 공유 네트워크 구성 요소를 허브 가상 네트워크에 배포하고 애플리케이션별 구성 요소를 스포크에 배포합니다. 대부분의 시스템에서 Azure Firewall 프리미엄은 공유 리소스입니다. 그러나 Web Application Firewall은 공유 네트워크 디바이스 또는 애플리케이션별 구성 요소가 될 수 있습니다. 다음과 같은 이유로 일반적으로 Application Gateway를 애플리케이션 구성 요소로 처리하고 스포크 가상 네트워크에 배포하는 것이 가장 좋습니다.

  • Web Application Firewall 경고 문제를 해결하는 것이 어려울 수 있습니다. 일반적으로 해당 경보를 트리거하는 메시지가 합법적인지 여부를 결정하려면 애플리케이션에 대한 심층적인 지식이 필요합니다.
  • Application Gateway를 공유 리소스로 처리하는 경우 Azure Application Gateway 제한을 초과할 수 있습니다.
  • Application Gateway를 허브에 배포하는 경우 역할 기반 액세스 제어 문제에 직면할 수 있습니다. 이 상황은 팀에서 다른 애플리케이션을 관리하지만 동일한 Application Gateway 인스턴스를 사용할 때 발생할 수 있습니다. 그러면 각 팀에서 전체 Application Gateway 구성에 액세스할 수 있습니다.

기존 허브 및 스포크 아키텍처에서 DNS 프라이빗 영역은 DNS를 사용하는 쉬운 방법을 제공합니다.

  • DNS 프라이빗 영역을 구성합니다.
  • 영역을 Azure Firewall 프리미엄이 포함된 가상 네트워크에 연결합니다.
  • Application Gateway에서 트래픽 및 상태 확인에 사용하는 값에 대한 A 레코드가 있는지 확인합니다.

다음 다이어그램에서는 Application Gateway가 스포크 가상 네트워크에 있는 경우의 패킷 흐름을 보여 줍니다. 이 경우 클라이언트는 공용 인터넷에서 연결합니다.

부하 분산 장치 및 방화벽이 있는 허브 및 스포크 네트워크의 패킷 흐름을 보여 주는 아키텍처 다이어그램. 클라이언트는 공용 인터넷에서 연결합니다.

  1. 클라이언트에서 요청을 웹 서버에 제출합니다.
  2. Application Gateway에서 클라이언트 패킷을 가로채서 검사합니다. 패킷이 검사를 통과하면 Application Gateway에서 패킷을 백 엔드 VM에 보냅니다. 패킷이 Azure에 도달하면 Application Gateway 서브넷의 UDR(사용자 정의 경로)에서 패킷을 Azure Firewall 프리미엄에 전달합니다.
  3. Azure Firewall 프리미엄에서 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall 프리미엄에서 패킷을 애플리케이션 VM에 전달합니다.
  4. VM에서 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. VM 서브넷의 UDR에서 패킷을 Azure Firewall 프리미엄으로 리디렉션합니다.
  5. Azure Firewall 프리미엄에서 패킷을 Application Gateway에 전달합니다.
  6. Application Gateway에서 클라이언트에 응답합니다.

트래픽은 공용 인터넷 대신 온-프레미스 네트워크에서 도착할 수도 있습니다. 트래픽은 사이트 간 VPN(가상 사설망) 또는 ExpressRoute를 통해 이동합니다. 이 시나리오에서 트래픽은 먼저 허브의 가상 네트워크 게이트웨이에 도달합니다. 나머지 네트워크 흐름은 이전 사례와 동일합니다.

부하 분산 장치 및 방화벽이 있는 허브 및 스포크 네트워크의 패킷 흐름을 보여 주는 아키텍처 다이어그램. 클라이언트는 온-프레미스 네트워크에서 연결합니다.

  1. 온-프레미스 클라이언트에서 가상 네트워크 게이트웨이에 연결합니다.
  2. 게이트웨이에서 클라이언트 패킷을 Application Gateway에 전달합니다.
  3. Application Gateway에서 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷의 UDR에서 패킷을 Azure Firewall 프리미엄에 전달합니다.
  4. Azure Firewall 프리미엄에서 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall 프리미엄에서 패킷을 애플리케이션 VM에 전달합니다.
  5. VM에서 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. VM 서브넷의 UDR에서 패킷을 Azure Firewall 프리미엄으로 리디렉션합니다.
  6. Azure Firewall 프리미엄에서 패킷을 Application Gateway에 전달합니다.
  7. Application Gateway에서 패킷을 가상 네트워크 게이트웨이에 보냅니다.
  8. 게이트웨이에서 클라이언트에 응답합니다.

Virtual WAN 토폴로지

이 아키텍처에서는 Virtual WAN 네트워킹 서비스를 사용할 수도 있습니다. 이 구성 요소는 많은 이점을 제공합니다. 예를 들어 스포크 가상 네트워크에서 사용자가 유지 관리하는 UDR이 필요하지 않습니다. 대신 가상 허브 경로 테이블에서 정적 경로를 정의할 수 있습니다. 그러면 이러한 경로가 허브에 연결하는 모든 가상 네트워크의 프로그래밍에 포함됩니다.

Virtual WAN을 네트워킹 플랫폼으로 사용하는 경우 두 가지 주요 차이점이 나타납니다.

  • Microsoft에서 가상 허브를 관리하므로 DNS 프라이빗 영역을 가상 허브에 연결할 수 없습니다. 구독 소유자에게는 프라이빗 DNS 영역을 연결할 수 있는 권한이 없습니다. 따라서 DNS 프라이빗 영역을 Azure Firewall 프리미엄이 포함된 보안 허브와 연결할 수 없습니다. Azure Firewall 프리미엄에 대한 DNS 확인을 구현하려면 대신 DNS 서버를 사용합니다.

    • 사용자 지정 DNS 서버를 사용하도록 Azure Firewall DNS 설정을 구성합니다.
    • Virtual WAN에 연결하는 공유 서비스 가상 네트워크에 서버를 배포합니다.
    • DNS 프라이빗 영역을 공유 서비스 가상 네트워크에 연결합니다. 그러면 DNS 서버에서 Application Gateway가 HTTP 호스트 헤더에서 사용하는 이름을 확인할 수 있습니다. 자세한 내용은 Azure Firewall DNS 설정을 참조하세요.

  • 접두사가 가상 네트워크 접두사보다 짧은(덜 구체적인) 경우에만 Virtual WAN을 사용하여 스포크의 경로를 프로그래밍할 수 있습니다. 예를 들어 위의 다이어그램에서 스포크 VNet에는 접두사 172.16.0.0/16이 있습니다. 이 경우 Virtual WAN은 VNet 접두사(172.16.0.0/16) 또는 서브넷(172.16.0.0/24, 172.16.1.0/24) 중 하나와 일치하는 경로를 삽입할 수 없습니다. 즉, Virtual WAN은 동일한 VNet에 있는 두 서브넷 간에 트래픽을 끌어들일 수 없습니다. 이 제한은 Application Gateway 및 대상 웹 서버가 동일한 가상 네트워크에 있을 때 명백해집니다. Virtual WAN은 Azure Firewall 프리미엄으로 진행하도록 Application Gateway와 웹 서버 간의 트래픽을 강제로 적용할 수 없습니다.(해결 방법은 Application Gateway와 웹 서버의 서브넷에서 사용자 정의 경로를 수동으로 구성하는 것입니다.)

다음 다이어그램에서는 Virtual WAN을 사용하는 경우의 패킷 흐름을 보여 줍니다. 이 상황에서 Application Gateway에 대한 액세스는 온-프레미스 네트워크에서 수행됩니다. 사이트 간 VPN 또는 ExpressRoute에서 해당 네트워크를 Virtual WAN에 연결합니다. 인터넷을 통한 액세스도 비슷합니다.

부하 분산 장치, 방화벽 및 Virtual WAN을 포함하는 허브 및 스포크 네트워크의 패킷 흐름을 보여 주는 아키텍처 다이어그램

  1. 온-프레미스 클라이언트에서 VPN에 연결합니다.
  2. VPN에서 클라이언트 패킷을 Application Gateway에 전달합니다.
  3. Application Gateway에서 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷에서 패킷을 Azure Firewall 프리미엄에 전달합니다.
  4. Azure Firewall 프리미엄에서 공유 서비스 가상 네트워크의 DNS 서버로부터 DNS 확인을 요청합니다.
  5. DNS 서버에서 확인 요청에 응답합니다.
  6. Azure Firewall 프리미엄에서 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall 프리미엄에서 패킷을 애플리케이션 VM에 전달합니다.
  7. VM에서 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. Application 서브넷에서 패킷을 Azure Firewall 프리미엄으로 리디렉션합니다.
  8. Azure Firewall 프리미엄에서 패킷을 Application Gateway에 전달합니다.
  9. Application Gateway에서 패킷을 VPN에 보냅니다.
  10. VPN에서 클라이언트에 응답합니다.

이 설계에서는 허브가 스포크 가상 네트워크에 보급하는 라우팅을 수정해야 할 수 있습니다. 특히 Application Gateway v2는 인터넷을 가리키는 0.0.0.0/0 경로만 지원합니다. 인터넷을 가리키지 않는 이 주소를 사용하는 경로는 Microsoft에서 Application Gateway를 관리하는 데 필요한 연결을 끊습니다. 가상 허브에서 0.0.0.0/0 경로를 보급하는 경우 다음 단계 중 하나를 수행하여 해당 경로가 Application Gateway 서브넷에 전파되지 않도록 합니다.

  • 0.0.0.0/0 경로 및 Internet 다음 홉 형식이 포함된 경로 테이블을 만듭니다. 해당 경로를 Application Gateway를 배포하는 서브넷과 연결합니다.
  • Application Gateway를 전용 스포크에 배포하는 경우 가상 네트워크 연결 설정에서 기본 경로 전파를 사용하지 않도록 설정합니다.

경로 서버 토폴로지

Route Server는 자동으로 경로를 스포크에 삽입하는 다른 방법을 제공합니다. 이 기능을 사용하면 라우팅 테이블을 유지 관리하는 데 발생하는 관리 오버헤드를 방지할 수 있습니다. Route Server는 Virtual WAN과 허브 및 스포크 변형을 결합합니다.

  • 고객은 Route Server를 사용하여 허브 가상 네트워크를 관리합니다. 결과적으로 허브 가상 네트워크를 DNS 프라이빗 영역에 연결할 수 있습니다.
  • Route Server에는 IP 주소 접두사와 관련하여 Virtual WAN과 동일한 제한이 있습니다. 접두사가 가상 네트워크 접두사보다 짧은 경우에만 경로를 스포크에 삽입할 수 있습니다. 이 제한으로 인해 Application Gateway와 대상 웹 서버는 서로 다른 가상 네트워크에 있어야 합니다.

다음 다이어그램에서는 Route Server에서 동적 라우팅을 간소화하는 경우의 패킷 흐름을 보여 줍니다. 다음 사항에 유의하세요.

  • 현재 Route Server에는 BGP(Border Gateway Protocol)를 통해 경로를 보내기 위해 해당 경로를 삽입하는 디바이스가 필요합니다. Azure Firewall 프리미엄에서 BGP를 지원하지 않으므로 타사 NVA(네트워크 가상 어플라이언스)를 대신 사용합니다.
  • 허브의 NVA 기능에 따라 구현에 DNS가 필요한지 여부를 결정합니다.

부하 분산 장치, 방화벽 및 Route Server를 포함하는 허브 및 스포크 네트워크의 패킷 흐름을 보여 주는 아키텍처 다이어그램

  1. 온-프레미스 클라이언트에서 가상 네트워크 게이트웨이에 연결합니다.
  2. 게이트웨이에서 클라이언트 패킷을 Application Gateway에 전달합니다.
  3. Application Gateway에서 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷에서 패킷을 백 엔드 컴퓨터에 전달합니다. Route Server에서 삽입한 ApplicationGateway 서브넷의 경로는 트래픽을 NVA에 전달합니다.
  4. NVA에서 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 NVA에서 패킷을 애플리케이션 VM에 전달합니다.
  5. VM에서 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. Route Server에서 VM 서브넷에 삽입한 경로는 패킷을 NVA로 리디렉션합니다.
  6. NVA에서 패킷을 Application Gateway에 전달합니다.
  7. Application Gateway에서 패킷을 가상 네트워크 게이트웨이에 보냅니다.
  8. 게이트웨이에서 클라이언트에 응답합니다.

Virtual WAN과 마찬가지로 Route Server를 사용하는 경우 라우팅을 수정해야 할 수도 있습니다. 0.0.0.0/0 경로를 보급하는 경우 Application Gateway 서브넷에 전파될 수 있습니다. 그러나 Application Gateway는 해당 경로를 지원하지 않습니다. 이 경우 Application Gateway 서브넷에 대한 라우팅 테이블을 구성합니다. 0.0.0.0/0 경로와 Internet 다음 홉 형식을 해당 테이블에 포함합니다.

IDPS 및 개인 IP 주소

Azure Firewall IDPS 규칙에 설명된 대로 Azure Firewall Premium은 패킷의 원본 및 대상 IP 주소에 따라 적용할 IDPS 규칙을 결정합니다. Azure Firewall은 RFC 1918 범위(및) 및 172.16.0.0/12RFC 6598 범위(10.0.0.0/8192.168.0.0/16100.64.0.0/10)의 기본 개인 IP 주소를 내부로 처리합니다. 따라서 이 문서의 다이어그램에서와 같이 Application Gateway가 이러한 범위 중 하나의 서브넷에 배포되는 경우(172.16.0.0/24 위의 예제에서) Azure Firewall Premium은 Application Gateway와 워크로드 간의 트래픽을 내부로 간주하고 내부 트래픽 또는 트래픽에 적용되도록 표시된 IDPS 서명만 사용됩니다. 인바운드 또는 아웃바운드 트래픽에 적용되도록 표시된 IDPS 서명은 Application Gateway와 워크로드 간의 트래픽에 적용되지 않습니다.

Application Gateway와 워크로드 간의 트래픽에 IDPS 인바운드 서명 규칙을 적용하도록 강제하는 가장 쉬운 방법은 프라이빗 범위 외부에 접두사를 가진 서브넷에 Application Gateway를 배치하는 것입니다. 이 서브넷에 공용 IP 주소를 반드시 사용할 필요는 없지만, 대신 Azure Firewall Premium이 IDPS의 내부 주소로 취급하는 IP 주소를 사용자 지정할 수 있습니다. 예를 들어 조직에서 범위를 사용하지 100.64.0.0/10 않는 경우 IDPS에 대한 내부 접두사 목록에서 이 범위를 제거하고(이 작업을 수행하는 방법에 대한 자세한 내용은 Azure Firewall Premium 개인 IPDS 범위 참조) IP 주소로 구성된 서브넷에 100.64.0.0/10Application Gateway를 배포할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

다음 단계