다음을 통해 공유

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

이 문서에서는 웹앱에 대한 제로 트러스트 보안을 구현하여 검사 및 엔드 투 엔드 암호화를 사용하도록 설정하는 방법을 설명합니다. 제로 트러스트 모델에는 연속 ID 확인 및 암시적 신뢰 영역의 크기 최소화와 같은 다른 많은 개념이 포함되어 있습니다.

이 문서에서는 공용 인터넷의 인바운드 트래픽에 대한 제로 트러스트 아키텍처의 암호화 및 검사 구성 요소에 중점을 둡니다. 인증 및 권한 부여와 같은 애플리케이션을 안전하게 배포하는 다른 측면에 대한 자세한 내용은 제로 트러스트 설명서를 참조하세요. 이 문서의 예제에서는 다층 접근 방식을 사용합니다. 다중 계층 접근 방식에서 네트워크 보안은 제로 트러스트 모델의 계층 중 하나를 구성합니다. 이 계층에서 네트워크 어플라이언스는 패킷을 검사하여 합법적인 트래픽만 애플리케이션에 도달하는지 확인합니다.

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

  • 웹 애플리케이션 방화벽은 웹 애플리케이션 계층에서 공격을 나타내는 패턴을 찾습니다.

  • 차세대 방화벽은 일반적인 위협을 찾을 수도 있습니다.

이 아키텍처는 Azure Application Gateway가 Azure Firewall Premium에 도달하기 전에 트래픽을 검사하고 처리하는 보안을 극대화하기 위한 일반적인 패턴에 중점을 둡니다. 일부 시나리오에서는 다양한 유형의 네트워크 보안 어플라이언스를 결합하여 보호를 강화할 수 있습니다. 자세한 내용은 가상 네트워크에 대한 Azure Firewall 및 Application Gateway를 참조하세요.

건축학

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

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

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

  1. 클라이언트는 부하 분산 장치인 Application Gateway에 패킷을 보냅니다. Azure 웹 애플리케이션 방화벽의 선택적 추가와 함께 실행됩니다.

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

  3. Azure Firewall Premium은 다음 보안 검사를 실행합니다.

  4. 패킷이 테스트를 통과하는 경우 Azure Firewall Premium은 다음 단계를 수행합니다.

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

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

  • Azure Web Application Firewall은 규칙을 사용하여 웹 계층에서 공격을 방지합니다. 공격의 예로는 SQL 코드 삽입 및 사이트 간 스크립팅이 있습니다. 규칙 및 OWASP(Open Worldwide Application Security Project) CRS(핵심 규칙 집합)에 대한 자세한 내용은 웹 애플리케이션 방화벽 CRS 규칙 그룹 및 규칙을 참조하세요.

  • Azure Firewall Premium은 일반 침입 감지 및 방지 규칙을 사용합니다. 이러한 규칙은 웹 애플리케이션을 대상으로 하는 악성 파일 및 기타 위협을 식별하는 데 도움이 됩니다.

이 아키텍처는 이 문서에서 설명하는 다음과 같은 유형의 네트워크 디자인을 지원합니다.

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

Azure Firewall 프리미엄 및 이름 확인

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

HTTP 호스트 헤더는 일반적으로 IP 주소를 포함하지 않습니다. 대신 헤더에는 서버의 디지털 인증서와 일치하는 이름이 포함됩니다. 이 경우 Azure Firewall Premium은 DNS를 사용하여 호스트 헤더 이름을 IP 주소로 확인합니다. 네트워크 디자인은 가장 적합한 DNS 솔루션을 결정합니다.

비고

Application Gateway는 HTTP 호스트 헤더의 포트 번호를 지원하지 않습니다. 결과적으로 다음을 수행합니다.

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

디지털 인증서

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

부하 분산 장치가 방화벽 앞에 있을 때 웹앱 네트워크에서 사용하는 CN 및 CA를 보여 주는 다이어그램

Azure Firewall은 자체 인증서를 동적으로 생성합니다. 이 기능은 Application Gateway 뒤에 배치되는 주된 이유 중 하나입니다. 그렇지 않으면 애플리케이션 클라이언트는 보안 위험으로 플래그가 지정된 자체 생성 인증서에 직면합니다.

TLS 연결

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

클라이언트에서 Application Gateway로

Application Gateway에서 클라이언트에서 볼 수 있는 디지털 인증서를 배포합니다. DigiCert 또는 Let's Encrypt와 같은 잘 알려진 CA는 일반적으로 이러한 인증서를 발급합니다. 이 메커니즘은 Azure Firewall이 자체 서명된 또는 내부 공개 키 인프라 CA에서 디지털 인증서를 동적으로 생성하는 방법과 근본적으로 다릅니다.

Application Gateway에서 Azure Firewall Premium으로

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

Azure Firewall Premium에서 웹 서버로

Azure Firewall Premium은 대상 웹 서버를 사용하여 TLS 세션을 설정합니다. Azure Firewall Premium은 잘 알려진 CA가 웹 서버 TLS 패킷에 서명하는지 확인합니다.

구성 요소 역할

Application Gateway 및 Azure Firewall Premium은 역할이 다르기 때문에 인증서를 서로 다르게 처리합니다.

  • Application Gateway는 역방향 웹 프록시. HTTP 및 HTTPS 요청을 가로채 악성 클라이언트로부터 웹 서버를 보호합니다. IP 주소 또는 정규화된 도메인 이름을 사용하여 Application Gateway의 백 엔드 풀에 있는 보호된 각 서버를 선언합니다. 합법적인 클라이언트는 각 애플리케이션에 액세스할 수 있어야 합니다. 따라서 공용 CA가 서명하는 디지털 인증서를 사용하여 Application Gateway를 구성합니다. 모든 TLS 클라이언트가 허용하는 CA를 사용합니다.

  • Azure Firewall Premium은 전달 웹 프록시 또는 간단히 웹 프록시입니다. 보호된 클라이언트에서 TLS 호출을 가로채 악성 웹 서버로부터 클라이언트를 보호합니다. 보호된 클라이언트가 HTTP 요청을 만들 때 전달 웹 프록시는 디지털 인증서를 생성하고 클라이언트에 제공하여 대상 웹 서버를 가장합니다. Azure Firewall Premium은 동적으로 생성된 인증서에 서명하는 프라이빗 CA를 사용합니다. 보호된 클라이언트가 해당 프라이빗 CA를 신뢰하도록 구성합니다. 이 아키텍처에서 Azure Firewall Premium은 Application Gateway에서 웹 서버로 요청을 보호합니다. Application Gateway는 Azure Firewall Premium에서 사용하는 프라이빗 CA를 신뢰합니다.

라우팅 및 트래픽 전달

라우팅은 네트워크 디자인의 토폴로지에 따라 약간 다릅니다. 다음 섹션에서는 허브 및 스포크, Virtual WAN 및 Route Server 토폴로지의 예를 설명합니다. 모든 토폴로지의 공통점은 다음과 같습니다.

  • Application Gateway는 항상 프록시 역할을 합니다. Azure Firewall Premium은 TLS 검사를 위해 구성된 경우 프록시 역할을 합니다. Application Gateway는 클라이언트에서 TLS 세션을 종료하고 새 TLS 세션은 Azure Firewall을 향해 빌드됩니다. Azure Firewall은 Application Gateway에서 공급된 TLS 세션을 수신 및 종료하고 워크로드에 대한 새 TLS 세션을 빌드합니다. 이 프로세스는 Azure Firewall Premium의 IDPS 구성에 영향을 줍니다. 자세한 내용은 IDPS 및 개인 IP 주소를 참조하세요.

  • 워크로드에는 Azure Firewall 서브넷 IP 주소에서 오는 연결이 표시됩니다. 원래 클라이언트 IP 주소는 Application Gateway가 삽입하는 X-Forwarded-For HTTP 헤더에 유지됩니다. Azure Firewall은 헤더에 원본 클라이언트 IP 주소 X-Forwarded-For 삽입도 지원합니다. 이 시나리오에서 원본 클라이언트 IP 주소는 애플리케이션 게이트웨이의 IP 주소입니다.

  • Application Gateway에서 워크로드로의 트래픽은 일반적으로 Azure 라우팅 메커니즘을 사용하여 Azure Firewall로 전송됩니다. 이러한 메커니즘에는 Application Gateway 서브넷에 구성된 UDR(사용자 정의 경로) 또는 Virtual WAN 또는 Route Server가 삽입하는 경로가 포함됩니다. Application Gateway 백 엔드 풀에서 Azure Firewall 개인 IP 주소를 명시적으로 정의할 수 있지만 부하 분산 및 세션 고정과 같은 Application Gateway의 네이티브 기능 중 일부를 제거하므로 그렇게 하지 않는 것이 좋습니다.

다음 섹션에서는 Azure Firewall 및 Application Gateway에서 사용할 수 있는 가장 일반적인 토폴로지 중 일부에 대해 설명합니다.

허브 및 스포크 토폴로지

허브 및 스포크 디자인은 일반적으로 허브 가상 네트워크에 공유 네트워크 구성 요소를 배포하고 스포크에서 애플리케이션 관련 구성 요소를 배포합니다. 대부분의 시스템에서 Azure Firewall Premium은 공유 리소스입니다. Azure 웹 애플리케이션 방화벽은 공유 네트워크 디바이스 또는 애플리케이션별 구성 요소일 수 있습니다. Application Gateway를 애플리케이션 구성 요소로 처리하고 다음과 같은 이유로 스포크 가상 네트워크에 배포하는 것이 가장 좋습니다.

  • Azure Web Application Firewall 경고 문제를 해결하기 어려울 수 있습니다. 일반적으로 이러한 경보를 트리거하는 메시지가 합법적인지 여부를 결정하려면 애플리케이션에 대한 심층적인 지식이 필요합니다.

  • Application Gateway를 공유 리소스로 처리하는 경우 Application Gateway 제한을 초과할 수 있습니다.

  • 허브에 Application Gateway를 배포하는 경우 역할 기반 액세스 제어 문제가 발생할 수 있습니다. 이 상황은 팀이 다른 애플리케이션을 관리하지만 Application Gateway의 동일한 인스턴스를 사용하는 경우에 발생할 수 있습니다. 그러면 각 팀이 전체 Application Gateway 구성에 액세스할 수 있습니다.

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

  1. DNS 프라이빗 영역을 구성합니다.
  2. Azure Firewall Premium이 포함된 가상 네트워크에 영역을 연결합니다.
  3. Application Gateway가 트래픽 및 상태 검사에 사용하는 값에 대한 주소 레코드가 있는지 확인합니다.

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

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

  1. 클라이언트가 웹 서버에 요청을 제출합니다.

  2. Application Gateway는 클라이언트 패킷을 가로채 검사합니다. 패킷이 검사를 통과하면 Application Gateway는 백 엔드 VM에 패킷을 보냅니다. 패킷이 Azure에 도달하면 Application Gateway 서브넷의 UDR이 이를 Azure Firewall Premium으로 전달합니다.

  3. Azure Firewall Premium은 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall Premium은 패킷을 애플리케이션 VM에 전달합니다.

  4. VM이 응답하고 대상 IP 주소를 애플리케이션 게이트웨이로 설정합니다. VM 서브넷의 UDR은 패킷을 Azure Firewall Premium으로 리디렉션합니다.

  5. Azure Firewall Premium은 패킷을 Application Gateway로 전달합니다.

  6. Application Gateway가 클라이언트에 응답합니다.

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

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

  1. 온-프레미스 클라이언트는 가상 네트워크 게이트웨이에 연결합니다.

  2. 가상 네트워크 게이트웨이는 클라이언트 패킷을 Application Gateway로 전달합니다.

  3. Application Gateway는 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷의 UDR이 패킷을 Azure Firewall Premium에 전달합니다.

  4. Azure Firewall Premium은 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall Premium은 패킷을 애플리케이션 VM에 전달합니다.

  5. VM이 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. VM 서브넷의 UDR은 패킷을 Azure Firewall Premium으로 리디렉션합니다.

  6. Azure Firewall Premium은 패킷을 Application Gateway로 전달합니다.

  7. Application Gateway는 가상 네트워크 게이트웨이에 패킷을 보냅니다.

  8. 가상 네트워크 게이트웨이가 클라이언트에 응답합니다.

Virtual WAN 토폴로지

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

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

  • Microsoft에서 가상 허브를 관리하므로 DNS 프라이빗 영역을 가상 허브에 연결할 수 없습니다. 구독 소유자는 프라이빗 DNS 영역을 연결할 수 있는 권한이 없습니다. 따라서 AZURE Firewall Premium을 포함하는 보안 허브와 DNS 프라이빗 영역을 연결할 수 없습니다.

    Azure Firewall Premium에 대한 DNS 확인을 구현하려면 DNS 서버를 대신 사용합니다.

    • 사용자 지정 DNS 서버를 사용하도록 Azure Firewall DNS 설정을 구성합니다.

    • 가상 WAN에 연결하는 공유 서비스 가상 네트워크에 서버를 배포합니다.

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

  • 가상 네트워크 접두사보다 접두사를 더 짧게(덜 구체적인) 경우에만 Virtual WAN을 사용하여 스포크에서 경로를 프로그래밍할 수 있습니다. 예를 들어 이전 다이어그램에서 스포크 가상 네트워크에는 접두사 172.16.0.0/16가 있습니다. 이 경우 Virtual WAN은 가상 네트워크 접두사() 또는 서브넷172.16.0.0/16(172.16.0.0/24, 172.16.1.0/24)과 일치하는 경로를 삽입할 수 없습니다. 즉, Virtual WAN은 동일한 가상 네트워크에 있는 두 서브넷 간에 트래픽을 보낼 수 없습니다.

    Application Gateway와 대상 웹 서버가 동일한 가상 네트워크에 있는 경우 이 제한이 명백해집니다. Virtual WAN은 Application Gateway와 웹 서버 간의 트래픽이 Azure Firewall Premium을 통과하도록 강제할 수 없습니다. 한 가지 해결 방법은 Application Gateway 및 웹 서버 서브넷에서 UDR을 수동으로 구성하는 것입니다.

다음 다이어그램은 Virtual WAN을 사용하는 아키텍처의 패킷 흐름을 보여줍니다. 이 시나리오에서 Application Gateway에 대한 액세스는 온-프레미스 네트워크에서 제공됩니다. 사이트간 VPN 또는 ExpressRoute 인스턴스는 해당 네트워크를 Virtual WAN에 연결합니다. 인터넷 기반 액세스는 비슷한 경로를 따릅니다.

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

  1. 온-프레미스 클라이언트는 VPN 게이트웨이에 연결합니다.

  2. VPN 게이트웨이는 클라이언트 패킷을 Application Gateway로 전달합니다.

  3. Application Gateway는 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷은 패킷을 Azure Firewall Premium에 전달합니다.

  4. Azure Firewall Premium은 공유 서비스 가상 네트워크의 DNS 서버에서 DNS 확인을 요청합니다.

  5. DNS 서버가 확인 요청에 응답합니다.

  6. Azure Firewall Premium은 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 Azure Firewall Premium은 패킷을 애플리케이션 VM에 전달합니다.

  7. VM이 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. 애플리케이션 서브넷은 패킷을 Azure Firewall Premium으로 리디렉션합니다.

  8. Azure Firewall Premium은 패킷을 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는 Virtual WAN과 허브 및 스포크 변형을 결합합니다.

  • 경로 서버를 사용하여 허브 가상 네트워크를 관리할 수 있습니다. 따라서 허브 가상 네트워크를 DNS 프라이빗 영역에 연결할 수 있습니다.

  • 경로 서버에는 Virtual WAN이 IP 주소 접두사에 대해 가지고 있는 것과 동일한 제한 사항이 있습니다. 접두사(덜 구체적인)가 가상 네트워크 접두사보다 짧은 경우에만 스포크에 경로를 삽입할 수 있습니다. 이러한 제한으로 인해 Application Gateway와 대상 웹 서버는 서로 다른 가상 네트워크에 있어야 합니다.

다음 다이어그램은 Route Server가 동적 라우팅을 간소화할 때의 패킷 흐름을 보여줍니다. 다음 사항을 고려합니다.

  • 경로 서버에는 현재 경로를 삽입하는 디바이스가 BGP(Border Gateway Protocol)를 통해 전송되어야 합니다. Azure Firewall Premium은 BGP를 지원하지 않으므로 Microsoft가 아닌 NVA(네트워크 가상 어플라이언스)를 대신 사용합니다.

  • 허브에서 NVA의 기능은 구현에 DNS가 필요한지 여부를 결정합니다.

부하 분산 장치, 방화벽 및 경로 서버를 포함하는 허브 및 스포크 네트워크의 패킷 흐름을 보여 주는 다이어그램.

  1. 온-프레미스 클라이언트는 가상 네트워크 게이트웨이에 연결합니다.

  2. 가상 네트워크 게이트웨이는 클라이언트 패킷을 Application Gateway로 전달합니다.

  3. Application Gateway는 패킷을 검사합니다. 검사를 통과하면 Application Gateway 서브넷은 패킷을 백 엔드 머신으로 전달합니다. 경로 서버는 트래픽을 NVA로 전달하는 Application Gateway 서브넷에 경로를 삽입합니다.

  4. NVA 서브넷은 공유 서비스 가상 네트워크의 DNS 서버에서 DNS 확인을 요청합니다.

  5. DNS 서버가 확인 요청에 응답합니다.

  6. NVA는 패킷에 대한 보안 검사를 실행합니다. 테스트를 통과하면 NVA는 패킷을 애플리케이션 VM에 전달합니다.

  7. 애플리케이션 VM이 응답하고 대상 IP 주소를 Application Gateway로 설정합니다. 경로 서버는 패킷을 NVA로 리디렉션하는 경로를 VM 서브넷에 삽입합니다.

  8. NVA는 패킷을 Application Gateway로 전달합니다.

  9. Application Gateway는 가상 네트워크 게이트웨이에 패킷을 보냅니다.

  10. 가상 네트워크 게이트웨이가 클라이언트에 응답합니다.

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

IDPS 및 개인 IP 주소

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

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

기여자

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

대표 저자:

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계

  • Last updated on