역방향 프록시와 백 엔드 웹 애플리케이션 간에 원래 HTTP 호스트 이름 유지

Azure API Management

Azure App Service

Azure Application Gateway

Azure Front Door

Azure Spring Apps

웹 애플리케이션 앞에서 역방향 프록시를 사용하는 경우 원래 HTTP 호스트 이름을 유지하는 것이 좋습니다. 역방향 프록시에서 백 엔드 애플리케이션 서버에 제공된 것과 다른 호스트 이름을 사용하면 제대로 작동하지 않는 쿠키 또는 리디렉션 URL이 발생할 수 있습니다. 예를 들어 세션 상태가 손실되거나 인증이 실패하거나 백 엔드 URL이 실수로 최종 사용자에게 노출될 수 있습니다. 애플리케이션 서버가 웹 브라우저와 동일한 도메인을 볼 수 있도록 초기 요청의 호스트 이름을 유지하여 이러한 문제를 방지할 수 있습니다.

이 지침은 특히 Azure App Service 및 azure Spring AppsPaaS(Platform as a Service) 제품에서 호스트되는 애플리케이션에 적용됩니다. 이 문서에서는 일반적으로 사용되는 역방향 프록시 서비스인 Azure Application Gateway, Azure Front Door및 Azure API Management대한 특정 구현 지침 제공합니다.

메모

웹 API는 일반적으로 호스트 이름 불일치로 인한 문제에 덜 민감합니다. 예를 들어 프런트 엔드백 엔드라고 하는 패턴에서 쿠키를 사용하여 단일 페이지 앱과 백 엔드 API간의 통신을 보호할 않는 한 쿠키에 의존하지 않습니다. Web API는 OData(Open Data Protocol) HATEOAS같은 특정 API 스타일을 제외하고 절대 URL을 자신에게 반환하지 않는 경우가 많습니다. API 구현이 쿠키에 의존하거나 절대 URL을 생성하는 경우 이 문서에 제공된 지침이 적용됩니다.

엔드투엔드 TLS/SSL(역방향 프록시와 백 엔드 서비스 간의 연결이 HTTPS를 사용함)이 필요한 경우 백 엔드 서비스에는 원래 호스트 이름에 대해 일치하는 TLS 인증서도 필요합니다. 이 요구 사항은 인증서를 배포하고 갱신할 때 운영 복잡성을 더하지만, 많은 PaaS 서비스는 완전히 관리되는 무료 TLS 인증서를 제공합니다.

문맥

HTTP 요청의 호스트

대부분의 경우 애플리케이션 서버 또는 요청 파이프라인의 일부 구성 요소에 액세스하기 위해 브라우저에서 사용한 인터넷 도메인 이름이 필요합니다. 요청의 호스트. IP 주소일 수 있지만 일반적으로 contoso.com 같은 이름입니다(브라우저가 DNS를 사용하여 IP 주소로 확인됨). 호스트 값은 일반적으로 요청 URI호스트 구성 요소에서 결정됩니다. 이 구성 요소는 브라우저가 HTTP 헤더애플리케이션에 보냅니다.

중요하다

보안 메커니즘에서 호스트의 값을 사용하지 마세요. 이 값은 브라우저 또는 일부 다른 사용자 에이전트에서 제공되며 최종 사용자가 쉽게 조작할 수 있습니다.

일부 시나리오에서는 특히 요청 체인에 HTTP 역방향 프록시가 있는 경우 원래 호스트 헤더가 애플리케이션 서버에 도달하기 전에 변경될 수 있습니다. 역방향 프록시는 클라이언트 네트워크 세션을 닫고 백 엔드에 대한 새 연결을 설정합니다. 이 새 세션에서는 클라이언트 세션의 원래 호스트 이름을 전달하거나 새 호스트를 설정할 수 있습니다. 후자의 경우 프록시는 Forwarded 또는 X-Forwarded-Host같은 다른 HTTP 헤더에서 원래 호스트 값을 보내는 경우가 많습니다. 이 값을 사용하면 애플리케이션이 원래 호스트 이름을 확인할 수 있지만 이러한 헤더를 읽기 위해 코딩된 경우에만 확인할 수 있습니다.

웹 플랫폼이 호스트 이름을 사용하는 이유

다중 테넌트 PaaS 서비스는 들어오는 요청을 적절한 테넌트의 백 엔드 서버로 라우팅하기 위해 등록되고 유효성이 검사된 호스트 이름이 필요한 경우가 많습니다. 이는 일반적으로 모든 테넌트에 대해 들어오는 요청을 수락하는 부하 분산 장치의 공유 풀이 있기 때문입니다. 테넌트는 일반적으로 들어오는 호스트 이름을 사용하여 고객 테넌트에 대한 올바른 백 엔드를 조회합니다.

쉽게 시작할 수 있도록 이러한 플랫폼은 일반적으로 배포된 인스턴스로 트래픽을 라우팅하도록 미리 구성된 기본 도메인을 제공합니다. App Service의 경우 이 기본 도메인은 azurewebsites.net. 만드는 각 웹앱은 자체 하위 도메인(예: contoso.azurewebsites.net)을 가져옵니다. 마찬가지로 기본 도메인은 Azure Spring Apps 및 API Management용 azuremicroservices.ioazure-api.net.

프로덕션 배포의 경우 이러한 기본 도메인을 사용하지 않습니다. 대신 조직 또는 애플리케이션의 브랜드에 맞게 고유한 도메인을 제공합니다. 예를 들어 contoso.com App Service의 contoso.azurewebsites.net 웹앱에 대한 백그라운드에서 확인할 수 있지만 이 도메인은 웹 사이트를 방문하는 최종 사용자에게 표시되지 않아야 합니다. 그러나 이 사용자 지정 contoso.com 호스트 이름은 PaaS 서비스에 등록해야 하므로 플랫폼은 요청에 응답해야 하는 백 엔드 서버를 식별할 수 있습니다.

App Service의 호스트 기반 라우팅을 보여 주는

애플리케이션에서 호스트 이름을 사용하는 이유

애플리케이션 서버에 호스트 이름이 필요한 두 가지 일반적인 이유는 절대 URL을 생성하고 특정 도메인에 대한 쿠키를 발급하기 위해서입니다. 예를 들어 애플리케이션 코드에서 다음을 수행해야 하는 경우

• HTTP 응답에서 상대 URL이 아닌 절대값을 반환합니다(일반적으로 웹 사이트는 가능한 경우 상대 링크를 렌더링하는 경향이 있지만).
• 웹 사이트 링크를 사용자에게 전자 메일로 보낼 때처럼 상대 URL을 사용할 수 없는 HTTP 응답 외부에서 사용할 URL을 생성합니다.
• 외부 서비스에 대한 절대 리디렉션 URL을 생성합니다. 예를 들어 Microsoft Entra ID와 같은 인증 서비스에 인증에 성공한 후 사용자를 반환해야 하는 위치를 나타냅니다.
• 쿠키의 Domain 특성정의된 대로 특정 호스트로 제한된 HTTP 쿠키를 발급합니다.

애플리케이션의 구성에 예상된 호스트 이름을 추가하고 요청에 들어오는 호스트 이름 대신 정적으로 정의된 값을 사용하여 이러한 모든 요구 사항을 충족할 수 있습니다. 그러나 이 방법은 애플리케이션 개발 및 배포를 복잡하게 만듭니다. 또한 애플리케이션의 단일 설치는 여러 호스트를 제공할 수 있습니다. 예를 들어 고유한 호스트 이름(예: tenant1.contoso.com 및 tenant2.contoso.com)이 있는 여러 애플리케이션 테넌트에 단일 웹앱을 사용할 수 있습니다.

또한 들어오는 호스트 이름은 애플리케이션 코드 외부 또는 모든 권한이 없는 애플리케이션 서버의 미들웨어에서 구성 요소에서 사용됩니다. 다음은 몇 가지 예입니다.

• App Service에서 웹앱에 HTTPS 적용할 수 있습니다. 이렇게 하면 안전하지 않은 모든 HTTP 요청이 HTTPS로 리디렉션됩니다. 이 경우 들어오는 호스트 이름은 HTTP 리디렉션의 Location 헤더에 대한 절대 URL을 생성하는 데 사용됩니다.
• Azure Spring Apps는 비슷한 기능을 사용하여 HTTPS적용합니다. 또한 들어오는 호스트를 사용하여 HTTPS URL을 생성합니다.
• App Service에는 고정 세션을 사용하도록 설정하는 ARR 선호도 설정 있으므로 동일한 브라우저 인스턴스의 요청은 항상 동일한 백 엔드 서버에서 제공됩니다. 이 작업은 HTTP 응답에 쿠키를 추가하는 App Service 프런트 엔드에서 수행됩니다. 쿠키의 Domain 들어오는 호스트로 설정됩니다.
• App Service는 사용자가 API에 로그인하고 데이터에 쉽게 액세스할 수 있도록 인증 및 권한 부여 기능을 제공합니다.
  • 들어오는 호스트 이름은 인증에 성공한 후 ID 공급자가 사용자를 반환해야 하는 리디렉션 URL을 생성하는 데 사용됩니다.
  • 기본적으로 이 기능을 사용하도록 설정하면 HTTP-HTTPS 리디렉션켜집니다. 다시, 들어오는 호스트 이름은 리디렉션 위치를 생성하는 데 사용됩니다.

호스트 이름을 재정의하려는 이유가 무엇인가요?

기본 도메인이 contoso.azurewebsites.netApp Service에서 웹 애플리케이션을 만든 경우를 가정해 보겠습니다. (또는 Azure Spring Apps와 같은 다른 서비스에서) App Service에서 사용자 지정 도메인을 구성하지 않았습니다. Application Gateway(또는 유사한 서비스)와 같은 역방향 프록시를 이 애플리케이션 앞에 배치하려면 contoso.com 대한 DNS 레코드를 설정하여 Application Gateway의 IP 주소로 확인합니다. 따라서 브라우저에서 contoso.com 대한 요청을 수신하고 해당 요청을 contoso.azurewebsites.net 확인되는 IP 주소로 전달하도록 구성됩니다. 이는 요청된 호스트에 대한 최종 백 엔드 서비스입니다. 그러나 이 경우 App Service는 contoso.com 사용자 지정 도메인을 인식하지 못하고 이 호스트 이름에 대해 들어오는 모든 요청을 거부합니다. 요청을 라우팅할 위치를 확인할 수 없습니다.

이 구성 작업을 수행하는 쉬운 방법은 Application Gateway에서 HTTP 요청의 Host 헤더를 재정의하거나 다시 작성하고 contoso.azurewebsites.net값으로 설정하는 것입니다. 이렇게 하면 Application Gateway에서 나가는 요청은 원래 요청이 실제로 contoso.azurewebsites.net대신 contoso.com 의도된 것처럼 보입니다.

호스트 이름이 재정의된 구성을 보여 주는

이 시점에서 App Service는 호스트 이름을 인식하고 사용자 지정 도메인 이름을 구성할 필요 없이 요청을 수락합니다. 실제로 Application Gateway를 사용하면 호스트 헤더 백 엔드 풀의 호스트로 쉽게 재정의할 수 있습니다. Azure Front Door는 기본적으로.

그러나 이 솔루션의 문제는 앱에 원래 호스트 이름이 표시되지 않을 때 다양한 문제가 발생할 수 있다는 것입니다.

잠재적인 문제

잘못된 절대 URL

원래 호스트 이름이 유지되지 않고 애플리케이션 서버가 들어오는 호스트 이름을 사용하여 절대 URL을 생성하는 경우 백 엔드 도메인이 최종 사용자에게 공개될 수 있습니다. 이러한 절대 URL은 애플리케이션 코드 또는 앞에서 설명한 대로 App Service 및 Azure Spring Apps에서 HTTP-HTTPS 리디렉션에 대한 지원과 같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

잘못된 절대 URL의 문제를 보여 주는

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에서 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름(예: https://contoso.azurewebsites.net/)을 기반으로 하는 절대 URL을 생성합니다.
4. 브라우저는 이 URL을 따릅니다. 이 URL은 contoso.com역방향 프록시로 돌아가지 않고 백 엔드 서비스로 직접 이동합니다.

역방향 프록시가 웹 애플리케이션 방화벽 역할을 하는 일반적인 경우 보안 위험이 발생할 수도 있습니다. 사용자는 백 엔드 애플리케이션으로 바로 이동하고 역방향 프록시를 우회하는 URL을 받습니다.

중요하다

이러한 보안 위험 때문에 백 엔드 웹 애플리케이션이 역방향 프록시의 네트워크 트래픽만 직접 수락하도록 해야 합니다(예: App Service액세스 제한 사용). 이렇게 하면 잘못된 절대 URL이 생성되더라도 적어도 작동하지 않으며 악의적인 사용자가 방화벽을 우회하는 데 사용할 수 없습니다.

잘못된 리디렉션 URL

이전 시나리오의 일반적이고 구체적인 사례는 절대 리디렉션 URL이 생성될 때 발생합니다. 이러한 URL은 OpenID Connect, OAuth(Open Authorization) 2.0 또는 SAML(Security Assertion Markup Language) 2.0과 같은 브라우저 기반 ID 프로토콜을 사용하는 경우 Microsoft Entra ID와 같은 ID 서비스에 필요합니다. 이러한 리디렉션 URL은 애플리케이션 서버 또는 미들웨어 자체에서 생성되거나 앞에서 설명한 대로 앱 서비스 인증 및 권한 부여 기능같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

잘못된 리디렉션 URL의 문제를 보여 주는

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름(예: https://contoso.azurewebsites.net/)을 기반으로 하는 절대 리디렉션 URL을 생성합니다.
4. 브라우저가 ID 공급자로 이동하여 사용자를 인증합니다. 요청에는 인증에 성공한 후 사용자를 반환할 위치를 나타내는 생성된 리디렉션 URL이 포함됩니다.
5. ID 공급자는 일반적으로 리디렉션 URL을 미리 등록해야 하므로 이 시점에서 제공된 리디렉션 URL이 등록되지 않았기 때문에 ID 공급자가 요청을 거부해야 합니다. (사용할 수 없습니다.) 그러나 어떤 이유로 리디렉션 URL이 등록된 경우 ID 공급자는 브라우저를 인증 요청에 지정된 리디렉션 URL로 리디렉션합니다. 이 경우 URL은 https://contoso.azurewebsites.net/.
6. 브라우저는 역방향 프록시로 돌아가지 않고 백 엔드 서비스로 직접 가는 이 URL을 따릅니다.

끊어진 쿠키

호스트 이름이 일치하지 않는 경우 애플리케이션 서버에서 쿠키를 발급하고 들어오는 호스트 이름을 사용하여 쿠키 특성을 생성하는 경우에도 문제가 발생할 수 있습니다. 도메인 특성은 쿠키가 해당 특정 도메인에만 사용되도록 합니다. 이러한 쿠키는 애플리케이션 코드 또는 앞에서 설명한 대로 앱 서비스 ARR 선호도 설정같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에서 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름을 기반으로 도메인을 사용하는 쿠키를 생성합니다. 브라우저는 사용자가 실제로 사용하는 contoso.com 도메인이 아닌 이 특정 도메인에 대한 쿠키를 저장합니다.
4. 쿠키의 contoso.com 도메인이 요청의 도메인과 일치하지 않으므로 브라우저는 contoso.azurewebsites.net 대한 후속 요청에 쿠키를 포함하지 않습니다. 애플리케이션은 이전에 발급한 쿠키를 받지 않습니다. 결과적으로 사용자는 쿠키에 있어야 하는 상태가 손실되거나 ARR 선호도와 같은 기능이 작동하지 않을 수 있습니다. 아쉽게도 이러한 문제 중 어느 것도 오류를 생성하지 않거나 최종 사용자에게 직접 표시됩니다. 따라서 문제를 해결하기가 어렵습니다.

일반적인 Azure 서비스에 대한 구현 지침

여기서 설명하는 잠재적인 문제를 방지하려면 역방향 프록시와 백 엔드 애플리케이션 서버 간의 호출에서 원래 호스트 이름을 유지하는 것이 좋습니다.

호스트 이름이 유지되는 구성을 보여 주는

백 엔드 구성

많은 웹 호스팅 플랫폼에서 허용되는 들어오는 호스트 이름을 명시적으로 구성해야 합니다. 다음 섹션에서는 가장 일반적인 Azure 서비스에 대해 이 구성을 구현하는 방법을 설명합니다. 다른 플랫폼은 일반적으로 사용자 지정 도메인을 구성하기 위한 유사한 방법을 제공합니다.

App Service웹 애플리케이션을 호스트하는 경우 사용자 지정 도메인 이름을 웹앱 연결하고 백 엔드에 기본 azurewebsites.net 호스트 이름을 사용하지 않도록 할 수 있습니다. 웹앱에 사용자 지정 도메인을 연결할 때 DNS 확인을 변경할 필요가 없습니다. 일반 또는 레코드에 영향을 주지 않고도 레코드 사용하여 도메인을 확인할 있습니다. (이러한 레코드는 여전히 역방향 프록시의 IP 주소로 확인됩니다.) 엔드투엔드 TLS/SSL이 필요한 경우 Key Vault 기존 인증서를 가져오거나 사용자 지정 도메인에 App Service Certificate 사용할 있습니다. (이 경우 도메인의 DNS 레코드가 역방향 프록시가 아닌 App Service로 직접 확인되어야 하므로 무료 App Service 관리 인증서 사용할 수 없습니다.)

마찬가지로 Spring Apps사용하는 경우 앱 사용자 지정 도메인을 사용하여 호스트 이름을 사용하지 않도록 수 있습니다. 엔드투엔드 TLS/SSL이 필요한 경우 기존 또는 자체 서명된 인증서를 가져올 수 있습니다.

API Management 앞에 역방향 프록시가 있는 경우(그 자체가 역방향 프록시로도 작동함) API Management 인스턴스 사용자 지정 도메인을 구성하여 azure-api.net 호스트 이름을 사용하지 않도록 할 수 있습니다. 엔드투엔드 TLS/SSL이 필요한 경우 기존 또는 무료 관리 인증서를 가져올 수 있습니다. 그러나 앞에서 설명한 것처럼 API는 호스트 이름 불일치로 인한 문제에 덜 민감하므로 이 구성은 중요하지 않을 수 있습니다.

Kubernetes 또는 가상 머신에서 직접처럼다른 플랫폼에서 애플리케이션을 호스트하는 경우 들어오는 호스트 이름에 따라 기본 제공 기능이 없습니다. 애플리케이션 서버 자체에서 호스트 이름을 사용하는 방법에 대한 책임이 있습니다. 호스트 이름을 유지하는 권장 사항은 일반적으로 애플리케이션에서 역방향 프록시를 인식하고 forwarded 또는 X-Forwarded-Host 헤더를 존중하지 않는 한 애플리케이션에 의존하는 모든 구성 요소에 계속 적용됩니다.

역방향 프록시 구성

역방향 프록시 내에서 백 엔드를 정의할 때 백 엔드 서비스의 기본 도메인(예: https://contoso.azurewebsites.net/)을 계속 사용할 수 있습니다. 이 URL은 역방향 프록시에서 백 엔드 서비스에 대한 올바른 IP 주소를 확인하는 데 사용됩니다. 플랫폼의 기본 도메인을 사용하는 경우 IP 주소가 항상 올바른지 확인합니다. 일반적으로 contoso.com같은 공용 도메인은 역방향 프록시 자체의 IP 주소로 확인되어야 하므로 사용할 수 없습니다. (Split-horizon DNS같은 고급 DNS 확인 기술을 사용하지 않는 한).

중요하다

역방향 프록시와 최종 백 엔드 사이에 Azure Firewall Premium 같은 차세대 방화벽이 있는 경우 분할 수평 DNS를 사용해야 할 수 있습니다. 이 유형의 방화벽은 HTTP Host 헤더가 대상 IP 주소로 확인되는지 여부를 명시적으로 확인할 수 있습니다. 이러한 경우 브라우저에서 사용하는 원래 호스트 이름은 공용 인터넷에서 액세스할 때 역방향 프록시의 IP 주소로 확인되어야 합니다. 그러나 방화벽의 관점에서 해당 호스트 이름은 최종 백 엔드 서비스의 IP 주소로 확인되어야 합니다. 자세한 내용은 Azure Firewall 및 Application Gateway사용하는 웹 애플리케이션에 대한 제로 트러스트 네트워크 참조하세요.

대부분의 역방향 프록시를 사용하면 백 엔드 서비스에 전달되는 호스트 이름을 구성할 수 있습니다. 다음 정보는 가장 일반적인 Azure 서비스에 들어오는 요청의 원래 호스트 이름이 사용되는지 확인하는 방법을 설명합니다.

메모

모든 경우에 들어오는 요청에서 호스트 이름을 사용하는 대신 명시적으로 정의된 사용자 지정 도메인으로 호스트 이름을 재정의하도록 선택할 수도 있습니다. 애플리케이션에서 단일 도메인만 사용하는 경우 해당 방법이 제대로 작동할 수 있습니다. 동일한 애플리케이션 배포가 여러 도메인(예: 다중 테넌트 시나리오)의 요청을 수락하는 경우 단일 도메인을 정적으로 정의할 수 없습니다. 들어오는 요청에서 호스트 이름을 가져와야 합니다(추가 HTTP 헤더를 고려하도록 애플리케이션이 명시적으로 코딩되지 않은 경우). 따라서 일반적인 권장 사항은 호스트 이름을 전혀 재정의해서는 안 된다는 것입니다. 들어오는 호스트 이름을 수정되지 않은 상태로 백 엔드에 전달합니다.

역방향 프록시에서 호스트 이름을 유지하거나 재정의하든 관계없이 백 엔드 서버가 사용자 형식으로 요청을 수락하도록 구성되어 있는지 확인합니다.

애플리케이션 게이트웨이

Application Gateway 역방향 프록시로 사용하는 경우 백 엔드 HTTP 설정에서 새 호스트 이름 재정의를 사용하지 않도록 설정하여 원래 호스트 이름이 유지되도록 할 수 있습니다. 이렇게 하면 백 엔드 주소 호스트 이름 선택과 특정 도메인 이름재정의를 모두 사용하지 않도록 설정합니다. (이러한 설정은 모두 호스트 이름을 재정의합니다.) Application Gateway대한 Azure Resource Manager 속성에서 이 구성은 속성을 설정하고 .

상태 프로브는 들어오는 요청의 컨텍스트 외부에서 전송되므로 올바른 호스트 이름을 동적으로 확인할 수 없습니다. 대신 사용자 지정 상태 프로브를 만들고, 백 엔드 HTTP 설정호스트 이름 선택을 사용하지 않도록 설정하고, 호스트 이름명시적으로 지정해야 합니다. 이 호스트 이름의 경우 일관성을 위해 적절한 사용자 지정 도메인도 사용해야 합니다. (그러나 상태 프로브가 잘못된 쿠키를 무시하거나 응답에서 URL을 리디렉션하기 때문에 여기서 호스팅 플랫폼의 기본 도메인을 사용할 수 있습니다.)

Azure Front Door (Azure의 웹 트래픽 관리 서비스)

Azure Front Door사용하는 경우 원본 호스트 헤더를 원본 정의에 비워 두어 호스트 이름을 유지할 수. 원본Resource Manager 정의에서 이 구성은 설정하는 데 해당합니다.

API 관리

기본적으로 API Management API 웹 서비스 URL의 호스트 구성 요소(APIResource Manager 정의의 값에 해당)를 사용하여 백 엔드로 전송되는 호스트 이름을 재정의합니다.

다음과 같이 헤더 정책을 추가하여 API Management에서 들어오는 요청의 호스트 이름을 대신 사용하도록 강제할 수 있습니다.

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

그러나 앞에서 설명한 것처럼 API는 호스트 이름 불일치로 인한 문제에 덜 민감하므로 이 구성은 중요하지 않을 수 있습니다.

다음 단계

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

관련 리소스

• Azure Firewall 및 Application Gateway 사용하여 웹 애플리케이션에 대한 제로 트러스트 네트워크
• Application Gateway 및 API Management 사용하여 API 보호
• App Services Environment 사용하여 엔터프라이즈 배포

웹 애플리케이션 앞에서 역방향 프록시를 사용하는 경우 원래 HTTP 호스트 이름을 유지하는 것이 좋습니다. 역방향 프록시에서 백 엔드 애플리케이션 서버에 제공된 것과 다른 호스트 이름을 사용하면 제대로 작동하지 않는 쿠키 또는 리디렉션 URL이 발생할 수 있습니다. 예를 들어 세션 상태가 손실되거나 인증이 실패하거나 백 엔드 URL이 실수로 최종 사용자에게 노출될 수 있습니다. 애플리케이션 서버가 웹 브라우저와 동일한 도메인을 볼 수 있도록 초기 요청의 호스트 이름을 유지하여 이러한 문제를 방지할 수 있습니다.

이 지침은 특히 Azure App Service 및 azure Spring AppsPaaS(Platform as a Service) 제품에서 호스트되는 애플리케이션에 적용됩니다. 이 문서에서는 일반적으로 사용되는 역방향 프록시 서비스인 Azure Application Gateway, Azure Front Door및 Azure API Management대한 특정 구현 지침 제공합니다.

메모

웹 API는 일반적으로 호스트 이름 불일치로 인한 문제에 덜 민감합니다. 예를 들어 프런트 엔드백 엔드라고 하는 패턴에서 쿠키를 사용하여 단일 페이지 앱과 백 엔드 API간의 통신을 보호할 않는 한 쿠키에 의존하지 않습니다. Web API는 OData(Open Data Protocol) HATEOAS같은 특정 API 스타일을 제외하고 절대 URL을 자신에게 반환하지 않는 경우가 많습니다. API 구현이 쿠키에 의존하거나 절대 URL을 생성하는 경우 이 문서에 제공된 지침이 적용됩니다.

엔드투엔드 TLS/SSL(역방향 프록시와 백 엔드 서비스 간의 연결이 HTTPS를 사용함)이 필요한 경우 백 엔드 서비스에는 원래 호스트 이름에 대해 일치하는 TLS 인증서도 필요합니다. 이 요구 사항은 인증서를 배포하고 갱신할 때 운영 복잡성을 더하지만, 많은 PaaS 서비스는 완전히 관리되는 무료 TLS 인증서를 제공합니다.

문맥

HTTP 요청의 호스트

대부분의 경우 애플리케이션 서버 또는 요청 파이프라인의 일부 구성 요소에 액세스하기 위해 브라우저에서 사용한 인터넷 도메인 이름이 필요합니다. 요청의 호스트. IP 주소일 수 있지만 일반적으로 contoso.com 같은 이름입니다(브라우저가 DNS를 사용하여 IP 주소로 확인됨). 호스트 값은 일반적으로 요청 URI호스트 구성 요소에서 결정됩니다. 이 구성 요소는 브라우저가 HTTP 헤더애플리케이션에 보냅니다.

중요하다

보안 메커니즘에서 호스트의 값을 사용하지 마세요. 이 값은 브라우저 또는 일부 다른 사용자 에이전트에서 제공되며 최종 사용자가 쉽게 조작할 수 있습니다.

일부 시나리오에서는 특히 요청 체인에 HTTP 역방향 프록시가 있는 경우 원래 호스트 헤더가 애플리케이션 서버에 도달하기 전에 변경될 수 있습니다. 역방향 프록시는 클라이언트 네트워크 세션을 닫고 백 엔드에 대한 새 연결을 설정합니다. 이 새 세션에서는 클라이언트 세션의 원래 호스트 이름을 전달하거나 새 호스트를 설정할 수 있습니다. 후자의 경우 프록시는 Forwarded 또는 X-Forwarded-Host같은 다른 HTTP 헤더에서 원래 호스트 값을 보내는 경우가 많습니다. 이 값을 사용하면 애플리케이션이 원래 호스트 이름을 확인할 수 있지만 이러한 헤더를 읽기 위해 코딩된 경우에만 확인할 수 있습니다.

웹 플랫폼이 호스트 이름을 사용하는 이유

다중 테넌트 PaaS 서비스는 들어오는 요청을 적절한 테넌트의 백 엔드 서버로 라우팅하기 위해 등록되고 유효성이 검사된 호스트 이름이 필요한 경우가 많습니다. 이는 일반적으로 모든 테넌트에 대해 들어오는 요청을 수락하는 부하 분산 장치의 공유 풀이 있기 때문입니다. 테넌트는 일반적으로 들어오는 호스트 이름을 사용하여 고객 테넌트에 대한 올바른 백 엔드를 조회합니다.

쉽게 시작할 수 있도록 이러한 플랫폼은 일반적으로 배포된 인스턴스로 트래픽을 라우팅하도록 미리 구성된 기본 도메인을 제공합니다. App Service의 경우 이 기본 도메인은 azurewebsites.net. 만드는 각 웹앱은 자체 하위 도메인(예: contoso.azurewebsites.net)을 가져옵니다. 마찬가지로 기본 도메인은 Azure Spring Apps 및 API Management용 azuremicroservices.ioazure-api.net.

프로덕션 배포의 경우 이러한 기본 도메인을 사용하지 않습니다. 대신 조직 또는 애플리케이션의 브랜드에 맞게 고유한 도메인을 제공합니다. 예를 들어 contoso.com App Service의 contoso.azurewebsites.net 웹앱에 대한 백그라운드에서 확인할 수 있지만 이 도메인은 웹 사이트를 방문하는 최종 사용자에게 표시되지 않아야 합니다. 그러나 이 사용자 지정 contoso.com 호스트 이름은 PaaS 서비스에 등록해야 하므로 플랫폼은 요청에 응답해야 하는 백 엔드 서버를 식별할 수 있습니다.

App Service의 호스트 기반 라우팅을 보여 주는

애플리케이션에서 호스트 이름을 사용하는 이유

애플리케이션 서버에 호스트 이름이 필요한 두 가지 일반적인 이유는 절대 URL을 생성하고 특정 도메인에 대한 쿠키를 발급하기 위해서입니다. 예를 들어 애플리케이션 코드에서 다음을 수행해야 하는 경우

• HTTP 응답에서 상대 URL이 아닌 절대값을 반환합니다(일반적으로 웹 사이트는 가능한 경우 상대 링크를 렌더링하는 경향이 있지만).
• 웹 사이트 링크를 사용자에게 전자 메일로 보낼 때처럼 상대 URL을 사용할 수 없는 HTTP 응답 외부에서 사용할 URL을 생성합니다.
• 외부 서비스에 대한 절대 리디렉션 URL을 생성합니다. 예를 들어 Microsoft Entra ID와 같은 인증 서비스에 인증에 성공한 후 사용자를 반환해야 하는 위치를 나타냅니다.
• 쿠키의 Domain 특성정의된 대로 특정 호스트로 제한된 HTTP 쿠키를 발급합니다.

애플리케이션의 구성에 예상된 호스트 이름을 추가하고 요청에 들어오는 호스트 이름 대신 정적으로 정의된 값을 사용하여 이러한 모든 요구 사항을 충족할 수 있습니다. 그러나 이 방법은 애플리케이션 개발 및 배포를 복잡하게 만듭니다. 또한 애플리케이션의 단일 설치는 여러 호스트를 제공할 수 있습니다. 예를 들어 고유한 호스트 이름(예: tenant1.contoso.com 및 tenant2.contoso.com)이 있는 여러 애플리케이션 테넌트에 단일 웹앱을 사용할 수 있습니다.

또한 들어오는 호스트 이름은 애플리케이션 코드 외부 또는 모든 권한이 없는 애플리케이션 서버의 미들웨어에서 구성 요소에서 사용됩니다. 다음은 몇 가지 예입니다.

• App Service에서 웹앱에 HTTPS 적용할 수 있습니다. 이렇게 하면 안전하지 않은 모든 HTTP 요청이 HTTPS로 리디렉션됩니다. 이 경우 들어오는 호스트 이름은 HTTP 리디렉션의 Location 헤더에 대한 절대 URL을 생성하는 데 사용됩니다.
• Azure Spring Apps는 비슷한 기능을 사용하여 HTTPS적용합니다. 또한 들어오는 호스트를 사용하여 HTTPS URL을 생성합니다.
• App Service에는 고정 세션을 사용하도록 설정하는 ARR 선호도 설정 있으므로 동일한 브라우저 인스턴스의 요청은 항상 동일한 백 엔드 서버에서 제공됩니다. 이 작업은 HTTP 응답에 쿠키를 추가하는 App Service 프런트 엔드에서 수행됩니다. 쿠키의 Domain 들어오는 호스트로 설정됩니다.
• App Service는 사용자가 API에 로그인하고 데이터에 쉽게 액세스할 수 있도록 인증 및 권한 부여 기능을 제공합니다.
  • 들어오는 호스트 이름은 인증에 성공한 후 ID 공급자가 사용자를 반환해야 하는 리디렉션 URL을 생성하는 데 사용됩니다.
  • 기본적으로 이 기능을 사용하도록 설정하면 HTTP-HTTPS 리디렉션켜집니다. 다시, 들어오는 호스트 이름은 리디렉션 위치를 생성하는 데 사용됩니다.

호스트 이름을 재정의하려는 이유가 무엇인가요?

기본 도메인이 contoso.azurewebsites.netApp Service에서 웹 애플리케이션을 만든 경우를 가정해 보겠습니다. (또는 Azure Spring Apps와 같은 다른 서비스에서) App Service에서 사용자 지정 도메인을 구성하지 않았습니다. Application Gateway(또는 유사한 서비스)와 같은 역방향 프록시를 이 애플리케이션 앞에 배치하려면 contoso.com 대한 DNS 레코드를 설정하여 Application Gateway의 IP 주소로 확인합니다. 따라서 브라우저에서 contoso.com 대한 요청을 수신하고 해당 요청을 contoso.azurewebsites.net 확인되는 IP 주소로 전달하도록 구성됩니다. 이는 요청된 호스트에 대한 최종 백 엔드 서비스입니다. 그러나 이 경우 App Service는 contoso.com 사용자 지정 도메인을 인식하지 못하고 이 호스트 이름에 대해 들어오는 모든 요청을 거부합니다. 요청을 라우팅할 위치를 확인할 수 없습니다.

이 구성 작업을 수행하는 쉬운 방법은 Application Gateway에서 HTTP 요청의 Host 헤더를 재정의하거나 다시 작성하고 contoso.azurewebsites.net값으로 설정하는 것입니다. 이렇게 하면 Application Gateway에서 나가는 요청은 원래 요청이 실제로 contoso.azurewebsites.net대신 contoso.com 의도된 것처럼 보입니다.

호스트 이름이 재정의된 구성을 보여 주는

이 시점에서 App Service는 호스트 이름을 인식하고 사용자 지정 도메인 이름을 구성할 필요 없이 요청을 수락합니다. 실제로 Application Gateway를 사용하면 호스트 헤더 백 엔드 풀의 호스트로 쉽게 재정의할 수 있습니다. Azure Front Door는 기본적으로.

그러나 이 솔루션의 문제는 앱에 원래 호스트 이름이 표시되지 않을 때 다양한 문제가 발생할 수 있다는 것입니다.

잠재적인 문제

잘못된 절대 URL

원래 호스트 이름이 유지되지 않고 애플리케이션 서버가 들어오는 호스트 이름을 사용하여 절대 URL을 생성하는 경우 백 엔드 도메인이 최종 사용자에게 공개될 수 있습니다. 이러한 절대 URL은 애플리케이션 코드 또는 앞에서 설명한 대로 App Service 및 Azure Spring Apps에서 HTTP-HTTPS 리디렉션에 대한 지원과 같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

잘못된 절대 URL의 문제를 보여 주는

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에서 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름(예: https://contoso.azurewebsites.net/)을 기반으로 하는 절대 URL을 생성합니다.
4. 브라우저는 이 URL을 따릅니다. 이 URL은 contoso.com역방향 프록시로 돌아가지 않고 백 엔드 서비스로 직접 이동합니다.

역방향 프록시가 웹 애플리케이션 방화벽 역할을 하는 일반적인 경우 보안 위험이 발생할 수도 있습니다. 사용자는 백 엔드 애플리케이션으로 바로 이동하고 역방향 프록시를 우회하는 URL을 받습니다.

중요하다

이러한 보안 위험 때문에 백 엔드 웹 애플리케이션이 역방향 프록시의 네트워크 트래픽만 직접 수락하도록 해야 합니다(예: App Service액세스 제한 사용). 이렇게 하면 잘못된 절대 URL이 생성되더라도 적어도 작동하지 않으며 악의적인 사용자가 방화벽을 우회하는 데 사용할 수 없습니다.

잘못된 리디렉션 URL

이전 시나리오의 일반적이고 구체적인 사례는 절대 리디렉션 URL이 생성될 때 발생합니다. 이러한 URL은 OpenID Connect, OAuth(Open Authorization) 2.0 또는 SAML(Security Assertion Markup Language) 2.0과 같은 브라우저 기반 ID 프로토콜을 사용하는 경우 Microsoft Entra ID와 같은 ID 서비스에 필요합니다. 이러한 리디렉션 URL은 애플리케이션 서버 또는 미들웨어 자체에서 생성되거나 앞에서 설명한 대로 앱 서비스 인증 및 권한 부여 기능같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

잘못된 리디렉션 URL의 문제를 보여 주는

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름(예: https://contoso.azurewebsites.net/)을 기반으로 하는 절대 리디렉션 URL을 생성합니다.
4. 브라우저가 ID 공급자로 이동하여 사용자를 인증합니다. 요청에는 인증에 성공한 후 사용자를 반환할 위치를 나타내는 생성된 리디렉션 URL이 포함됩니다.
5. ID 공급자는 일반적으로 리디렉션 URL을 미리 등록해야 하므로 이 시점에서 제공된 리디렉션 URL이 등록되지 않았기 때문에 ID 공급자가 요청을 거부해야 합니다. (사용할 수 없습니다.) 그러나 어떤 이유로 리디렉션 URL이 등록된 경우 ID 공급자는 브라우저를 인증 요청에 지정된 리디렉션 URL로 리디렉션합니다. 이 경우 URL은 https://contoso.azurewebsites.net/.
6. 브라우저는 역방향 프록시로 돌아가지 않고 백 엔드 서비스로 직접 가는 이 URL을 따릅니다.

끊어진 쿠키

호스트 이름이 일치하지 않는 경우 애플리케이션 서버에서 쿠키를 발급하고 들어오는 호스트 이름을 사용하여 쿠키 특성을 생성하는 경우에도 문제가 발생할 수 있습니다. 도메인 특성은 쿠키가 해당 특정 도메인에만 사용되도록 합니다. 이러한 쿠키는 애플리케이션 코드 또는 앞에서 설명한 대로 앱 서비스 ARR 선호도 설정같은 플랫폼 기능에 의해 생성될 수 있습니다. 이 다이어그램은 다음과 같은 문제를 보여 줍니다.

1. 브라우저는 역방향 프록시에 contoso.com 요청을 보냅니다.
2. 역방향 프록시는 백 엔드 웹 애플리케이션(또는 다른 서비스의 유사한 기본 도메인)에 대한 요청에서 contoso.azurewebsites.net 호스트 이름을 다시 작성합니다.
3. 애플리케이션은 들어오는 contoso.azurewebsites.net 호스트 이름을 기반으로 도메인을 사용하는 쿠키를 생성합니다. 브라우저는 사용자가 실제로 사용하는 contoso.com 도메인이 아닌 이 특정 도메인에 대한 쿠키를 저장합니다.
4. 쿠키의 contoso.com 도메인이 요청의 도메인과 일치하지 않으므로 브라우저는 contoso.azurewebsites.net 대한 후속 요청에 쿠키를 포함하지 않습니다. 애플리케이션은 이전에 발급한 쿠키를 받지 않습니다. 결과적으로 사용자는 쿠키에 있어야 하는 상태가 손실되거나 ARR 선호도와 같은 기능이 작동하지 않을 수 있습니다. 아쉽게도 이러한 문제 중 어느 것도 오류를 생성하지 않거나 최종 사용자에게 직접 표시됩니다. 따라서 문제를 해결하기가 어렵습니다.

일반적인 Azure 서비스에 대한 구현 지침

여기서 설명하는 잠재적인 문제를 방지하려면 역방향 프록시와 백 엔드 애플리케이션 서버 간의 호출에서 원래 호스트 이름을 유지하는 것이 좋습니다.

호스트 이름이 유지되는 구성을 보여 주는

백 엔드 구성

많은 웹 호스팅 플랫폼에서 허용되는 들어오는 호스트 이름을 명시적으로 구성해야 합니다. 다음 섹션에서는 가장 일반적인 Azure 서비스에 대해 이 구성을 구현하는 방법을 설명합니다. 다른 플랫폼은 일반적으로 사용자 지정 도메인을 구성하기 위한 유사한 방법을 제공합니다.

App Service웹 애플리케이션을 호스트하는 경우 사용자 지정 도메인 이름을 웹앱 연결하고 백 엔드에 기본 azurewebsites.net 호스트 이름을 사용하지 않도록 할 수 있습니다. 웹앱에 사용자 지정 도메인을 연결할 때 DNS 확인을 변경할 필요가 없습니다. 일반 또는 레코드에 영향을 주지 않고도 레코드 사용하여 도메인을 확인할 있습니다. (이러한 레코드는 여전히 역방향 프록시의 IP 주소로 확인됩니다.) 엔드투엔드 TLS/SSL이 필요한 경우 Key Vault 기존 인증서를 가져오거나 사용자 지정 도메인에 App Service Certificate 사용할 있습니다. (이 경우 도메인의 DNS 레코드가 역방향 프록시가 아닌 App Service로 직접 확인되어야 하므로 무료 App Service 관리 인증서 사용할 수 없습니다.)

마찬가지로 Spring Apps사용하는 경우 앱 사용자 지정 도메인을 사용하여 호스트 이름을 사용하지 않도록 수 있습니다. 엔드투엔드 TLS/SSL이 필요한 경우 기존 또는 자체 서명된 인증서를 가져올 수 있습니다.

API Management 앞에 역방향 프록시가 있는 경우(그 자체가 역방향 프록시로도 작동함) API Management 인스턴스 사용자 지정 도메인을 구성하여 azure-api.net 호스트 이름을 사용하지 않도록 할 수 있습니다. 엔드투엔드 TLS/SSL이 필요한 경우 기존 또는 무료 관리 인증서를 가져올 수 있습니다. 그러나 앞에서 설명한 것처럼 API는 호스트 이름 불일치로 인한 문제에 덜 민감하므로 이 구성은 중요하지 않을 수 있습니다.

Kubernetes 또는 가상 머신에서 직접처럼다른 플랫폼에서 애플리케이션을 호스트하는 경우 들어오는 호스트 이름에 따라 기본 제공 기능이 없습니다. 애플리케이션 서버 자체에서 호스트 이름을 사용하는 방법에 대한 책임이 있습니다. 호스트 이름을 유지하는 권장 사항은 일반적으로 애플리케이션에서 역방향 프록시를 인식하고 forwarded 또는 X-Forwarded-Host 헤더를 존중하지 않는 한 애플리케이션에 의존하는 모든 구성 요소에 계속 적용됩니다.

역방향 프록시 구성

역방향 프록시 내에서 백 엔드를 정의할 때 백 엔드 서비스의 기본 도메인(예: https://contoso.azurewebsites.net/)을 계속 사용할 수 있습니다. 이 URL은 역방향 프록시에서 백 엔드 서비스에 대한 올바른 IP 주소를 확인하는 데 사용됩니다. 플랫폼의 기본 도메인을 사용하는 경우 IP 주소가 항상 올바른지 확인합니다. 일반적으로 contoso.com같은 공용 도메인은 역방향 프록시 자체의 IP 주소로 확인되어야 하므로 사용할 수 없습니다. (Split-horizon DNS같은 고급 DNS 확인 기술을 사용하지 않는 한).

중요하다

역방향 프록시와 최종 백 엔드 사이에 Azure Firewall Premium 같은 차세대 방화벽이 있는 경우 분할 수평 DNS를 사용해야 할 수 있습니다. 이 유형의 방화벽은 HTTP Host 헤더가 대상 IP 주소로 확인되는지 여부를 명시적으로 확인할 수 있습니다. 이러한 경우 브라우저에서 사용하는 원래 호스트 이름은 공용 인터넷에서 액세스할 때 역방향 프록시의 IP 주소로 확인되어야 합니다. 그러나 방화벽의 관점에서 해당 호스트 이름은 최종 백 엔드 서비스의 IP 주소로 확인되어야 합니다. 자세한 내용은 Azure Firewall 및 Application Gateway사용하는 웹 애플리케이션에 대한 제로 트러스트 네트워크 참조하세요.

대부분의 역방향 프록시를 사용하면 백 엔드 서비스에 전달되는 호스트 이름을 구성할 수 있습니다. 다음 정보는 가장 일반적인 Azure 서비스에 들어오는 요청의 원래 호스트 이름이 사용되는지 확인하는 방법을 설명합니다.

메모

모든 경우에 들어오는 요청에서 호스트 이름을 사용하는 대신 명시적으로 정의된 사용자 지정 도메인으로 호스트 이름을 재정의하도록 선택할 수도 있습니다. 애플리케이션에서 단일 도메인만 사용하는 경우 해당 방법이 제대로 작동할 수 있습니다. 동일한 애플리케이션 배포가 여러 도메인(예: 다중 테넌트 시나리오)의 요청을 수락하는 경우 단일 도메인을 정적으로 정의할 수 없습니다. 들어오는 요청에서 호스트 이름을 가져와야 합니다(추가 HTTP 헤더를 고려하도록 애플리케이션이 명시적으로 코딩되지 않은 경우). 따라서 일반적인 권장 사항은 호스트 이름을 전혀 재정의해서는 안 된다는 것입니다. 들어오는 호스트 이름을 수정되지 않은 상태로 백 엔드에 전달합니다.

역방향 프록시에서 호스트 이름을 유지하거나 재정의하든 관계없이 백 엔드 서버가 사용자 형식으로 요청을 수락하도록 구성되어 있는지 확인합니다.

애플리케이션 게이트웨이

Application Gateway 역방향 프록시로 사용하는 경우 백 엔드 HTTP 설정에서 새 호스트 이름 재정의를 사용하지 않도록 설정하여 원래 호스트 이름이 유지되도록 할 수 있습니다. 이렇게 하면 백 엔드 주소 호스트 이름 선택과 특정 도메인 이름재정의를 모두 사용하지 않도록 설정합니다. (이러한 설정은 모두 호스트 이름을 재정의합니다.) Application Gateway대한 Azure Resource Manager 속성에서 이 구성은 속성을 설정하고 .

상태 프로브는 들어오는 요청의 컨텍스트 외부에서 전송되므로 올바른 호스트 이름을 동적으로 확인할 수 없습니다. 대신 사용자 지정 상태 프로브를 만들고, 백 엔드 HTTP 설정호스트 이름 선택을 사용하지 않도록 설정하고, 호스트 이름명시적으로 지정해야 합니다. 이 호스트 이름의 경우 일관성을 위해 적절한 사용자 지정 도메인도 사용해야 합니다. (그러나 상태 프로브가 잘못된 쿠키를 무시하거나 응답에서 URL을 리디렉션하기 때문에 여기서 호스팅 플랫폼의 기본 도메인을 사용할 수 있습니다.)

Azure Front Door (Azure의 웹 트래픽 관리 서비스)

Azure Front Door사용하는 경우 원본 호스트 헤더를 원본 정의에 비워 두어 호스트 이름을 유지할 수. 원본Resource Manager 정의에서 이 구성은 설정하는 데 해당합니다.

API 관리

기본적으로 API Management API 웹 서비스 URL의 호스트 구성 요소(APIResource Manager 정의의 값에 해당)를 사용하여 백 엔드로 전송되는 호스트 이름을 재정의합니다.

다음과 같이 헤더 정책을 추가하여 API Management에서 들어오는 요청의 호스트 이름을 대신 사용하도록 강제할 수 있습니다.

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

그러나 앞에서 설명한 것처럼 API는 호스트 이름 불일치로 인한 문제에 덜 민감하므로 이 구성은 중요하지 않을 수 있습니다.

다음 단계

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

관련 리소스

• Azure Firewall 및 Application Gateway 사용하여 웹 애플리케이션에 대한 제로 트러스트 네트워크
• Application Gateway 및 API Management 사용하여 API 보호
• App Services Environment 사용하여 엔터프라이즈 배포