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

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

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

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

Context

HTTP 요청의 호스트

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

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

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

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

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

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

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

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

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

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

또한 들어오는 호스트 이름은 애플리케이션 코드 외부의 구성 요소 또는 모든 권한이 없는 애플리케이션 서버의 미들웨어에서 사용될 수 있는데 여기서는 사용자가 완전히 제어할 수 없습니다. 다음은 몇 가지 예입니다.

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

호스트 이름을 재정의하고 싶어질 수 있는 이유

App Service(또는 Spring Cloud와 같은 다른 서비스)에서 기본 도메인이 contoso.azurewebsites.net인 웹 애플리케이션을 만드는 경우를 가정해 봅시다. (또는 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.com이 아닌 contoso.azurewebsites.net에 대해 의도된 것처럼 보입니다.

이 시점에 App Service는 호스트 이름을 인식하며 사용자 지정 도메인 이름을 구성할 필요 없이 요청을 수락합니다. 실제로 백 엔드 풀의 호스트를 사용하여 Application Gateway는 호스트 헤더를 쉽게 재정의할 수 만듭니다. Azure Front Door는 심지어 그렇게 하는 것이 기본값입니다.

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

잠재적 문제

잘못된 절대 URL

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

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

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

잘못된 리디렉션 URL

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

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을 따릅니다.

손상된 쿠키

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

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

일반적인 Azure 서비스에 대한 구현 참고 자료

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

백 엔드 구성

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

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

마찬가지로 Spring Apps를 사용하는 경우 앱에 사용자 지정 도메인을 사용하여 azuremicroservices.io 호스트 이름을 사용하지 않도록 할 수 있습니다. 엔드투엔드 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 주소로 확인되어야 하기 때문입니다. (수평 분할 DNS와 같은 고급 DNS 확인 기술을 사용하지 하는 경우는 예외).

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

Application Gateway

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

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

Azure Front Door

Azure Front Door를 사용하는 경우 백 엔드 풀 정의에서 백 엔드 호스트 헤더를 비워 두어 호스트 이름을 재정의하지 않도록 할 수 있습니다. 백 엔드 풀의 Resource Manager 정의에서 이 구성은 backendHostHeader를 null로 설정하는 것에 해당합니다.

Azure Front Door 표준 또는 프리미엄을 사용하는 경우 원본 정의에 원본 호스트 헤더를 비워 두어 호스트 이름을 유지할 수 있습니다. origin의 Resource Manager 정의에서 이 구성은 originHostHeader를 null로 설정하는 것에 해당합니다.

API Management

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

다음과 같이 inboundHTTP 헤더 설정 정책을 추가하여 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 환경을 사용하는 엔터프라이즈 배포