백 엔드 설정을 사용하면 애플리케이션 게이트웨이 리소스에서 백 엔드 풀의 서버로 설정된 백 엔드 연결에 대한 구성을 관리할 수 있습니다. 백 엔드 설정 구성은 하나 이상의 라우팅 규칙과 연결할 수 있습니다.
Application Gateway의 백 엔드 설정 유형
포털 사용자에게는 "백 엔드 설정" 옵션만 표시되지만 API 사용자는 두 가지 유형의 설정에 액세스할 수 있습니다. 프로토콜에 따라 올바른 구성을 활용해야 합니다.
- 백 엔드 HTTP 설정 - HTTP 및 HTTPS 프로토콜을 지원하는 계층 7 프록시 구성용입니다.
- 백 엔드 설정 - TLS 및 TCP 프로토콜을 지원하는 계층 4 프록시(미리 보기) 구성용입니다.
쿠키 기반 선호도
Azure Application Gateway는 사용자 세션을 유지 관리하기 위해 게이트웨이 관리 쿠키를 사용합니다. 사용자가 Application Gateway에 첫 번째 요청을 보내면 세션 세부 정보가 포함된 해시 값을 사용하여 응답에서 선호도 쿠키를 설정합니다. 이 프로세스를 통해 선호도 쿠키를 전달하는 후속 요청을 동일한 백 엔드 서버로 라우팅하여 고정 상태를 유지할 수 있습니다.
이 기능은 동일한 서버에 사용자 세션을 유지하려는 경우와 사용자 세션의 세션 상태가 서버에 로컬로 저장되는 경우에 유용합니다. 애플리케이션에서 쿠키 기반 선호도를 처리할 수 없는 경우에는 이 기능을 사용할 수 없습니다. 기능을 사용하려면 클라이언트에서 쿠키를 지원하는지 확인합니다.
참고 항목
일부 취약성 검색에서는 Secure 또는 HttpOnly 플래그가 설정되지 않아 Application Gateway 선호도 쿠키가 플래그 지정될 수 있습니다. 이러한 검사는 쿠키의 데이터가 단방향 해시를 사용하여 생성된다는 점을 고려하지 않습니다. 쿠키에는 사용자 정보가 포함되어 있지 않으며 라우팅에만 사용됩니다.
Chromium 브라우저 v80 업데이트는 SameSite 특성이 없는 HTTP 쿠키를 SameSite=Lax로 처리해야 하는 위임을 가져왔습니다. CORS(원본 간 리소스 공유) 요청의 경우 쿠키가 타사 컨텍스트에서 전송되어야 하면 SameSite=None; Secure를 사용해야 하며 HTTPS를 통해서만 전송되어야 합니다. HTTP 전용 시나리오에서는 브라우저가 타사 컨텍스트에서 쿠키를 전송하지 않습니다. Chrome 업데이트의 목표는 보안을 강화하고 CSRF(교차 사이트 요청 위조) 공격을 방지하는 것입니다.
이 변경 내용을 지원하기 위해 2020년 2월 17일부터 Application Gateway(모든 SKU 유형)는 기존 ApplicationGatewayAffinity 쿠키 외에도 ApplicationGatewayAffinityCORS라는 다른 쿠키를 삽입합니다. ApplicationGatewayAffinityCORS 쿠키에는 두 개의 특성이 추가되었으므로(“SameSite=None; Secure”) 원본 간 요청에서도 고정 세션이 유지됩니다.
기본 선호도 쿠키 이름은 ApplicationGatewayAffinity 이며 변경할 수 있습니다. 네트워크 토폴로지에서 여러 애플리케이션 게이트웨이를 한 줄에 배포하는 경우 각 리소스에 대해 고유한 쿠키 이름을 설정해야 합니다. 사용자 지정 선호도 쿠키 이름을 사용하는 경우 추가 쿠키가 접미사로 추가 CORS
됩니다. 예: CustomCookieNameCORS.
참고 항목
SameSite=None 특성이 설정된 경우 쿠키에도 보안 플래그가 포함되어 있어야 하며 HTTPS를 통해 전송되어야 합니다. CORS에서 세션 선호도가 필요한 경우 워크로드를 HTTPS로 마이그레이션해야 합니다. Application Gateway에 대한 TLS 오프로드 및 엔드투엔드 TLS 설명서를 참조하세요. SSL 개요, TLS 종료를 사용하여 애플리케이션 게이트웨이 구성 및 엔드투엔드 TLS 구성을 참조하세요.
연결 드레이닝
연결 드레이닝은 예정된 서비스 업데이트 중에 백 엔드 풀 멤버를 정상적으로 제거하는 데 도움이 됩니다. 백 엔드 풀에서 명시적으로 제거된 백 엔드 인스턴스에 적용됩니다.
백 엔드 설정에서 연결 드레이닝을 사용하도록 설정하여 모든 백 엔드 풀 멤버에 이 설정을 적용할 수 있습니다. 구성된 제한 시간 값까지 기존 연결을 유지하면서 백 엔드 풀의 모든 등록 취소 인스턴스가 새 요청/연결을 수신하지 않도록 합니다. 이 프로세스는 WebSocket 연결에도 마찬가지입니다.
구성 형식 | 값 |
---|---|
백 엔드 설정에서 연결 드레이닝이 사용하도록 설정되지 않은 경우의 기본값 | 30초 |
백 엔드 설정에서 연결 드레이닝이 사용하도록 설정된 경우 사용자 정의 값 | 1~3600초 |
이 프로세스의 유일한 예외는 게이트웨이 관리 세션 선호도로 인해 인스턴스 등록 취소에 대한 요청입니다. 이러한 요청은 등록 취소 인스턴스로 계속 전달됩니다.
참고 항목
연결 드레이닝 시간 제한 후에 구성 업데이트가 진행 중인 연결을 종료하는 제한 사항이 있습니다. 이 제한을 해결하려면 백 엔드 설정의 연결 드레이닝 시간 제한을 최대 예상 클라이언트 다운로드 시간보다 높은 값으로 늘려야 합니다.
프로토콜
Application Gateway는 요청을 백 엔드 서버로 라우팅할 때 HTTP와 HTTPS를 모두 지원합니다. HTTP를 선택하면 백 엔드 서버에 대한 트래픽이 암호화되지 않습니다. 암호화되지 않은 통신이 허용되지 않는 경우 HTTPS를 선택합니다.
이 설정은 수신기의 HTTPS와 결합되어 엔드투엔드 TLS를 지원합니다. 이렇게 하면 암호화된 중요한 데이터를 백 엔드에 안전하게 전송할 수 있습니다. 엔드투엔드 TLS를 사용할 수 있는 백 엔드 풀의 각 백 엔드 서버가 보안 통신을 허용하는 인증서로 구성되어야 합니다.
포트
이 설정은 백 엔드 서버가 애플리케이션 게이트웨이의 트래픽을 수신 대기하는 포트를 지정합니다. 1에서 65535 사이의 포트를 구성할 수 있습니다.
신뢰할 수 있는 루트 인증서
백 엔드 설정에서 HTTPS 프로토콜을 선택할 때 애플리케이션 게이트웨이 리소스는 기본 신뢰할 수 있는 루트 CA 인증서 저장소를 활용하여 백 엔드 서버에서 제공하는 인증서의 체인 및 신뢰성을 확인합니다.
기본적으로 Application Gateway 리소스에는 공용 CA에서 백 엔드 서버 인증서를 발급할 때 원활한 백 엔드 TLS 연결을 허용하는 인기 있는 CA 인증서가 포함됩니다. 그러나 프라이빗 CA 또는 자체 생성된 인증서를 사용하려는 경우 이 백 엔드 설정 구성에서 해당 루트 CA 인증서(.cer)를 제공해야 합니다.
요청 시간 초과
이 설정은 애플리케이션 게이트웨이가 백 엔드 서버에서 응답을 받기 위해 대기하는 시간(초)입니다. 기본값은 20초입니다. 그러나 애플리케이션의 요구에 맞게 이 설정을 조정할 수 있습니다.
백 엔드 경로 재정의
이 설정을 사용하면 요청이 백 엔드로 전달될 때 사용할 선택적 사용자 지정 전달 경로를 구성할 수 있습니다. 백 엔드 경로 재정의 필드의 사용자 지정 경로와 일치하는 들어오는 경로 부분이 전달된 경로에 복사됩니다. 다음 표는 이 기능의 작동 방식을 보여 줍니다.
HTTP 설정이 기본 요청 라우팅 규칙에 연결된 경우
원래 요청 백 엔드 경로 재정의 요청이 백 엔드로 전달됨 /집/ /우선 처리/ /override/home/ /home/secondhome/ /우선 처리/ /override/home/secondhome/ HTTP 설정이 경로 기반 요청 라우팅 규칙에 연결된 경우
원래 요청 경로 규칙 백 엔드 경로 재정의 요청이 백 엔드로 전달됨 /pathrule/home/ /pathrule* /우선 처리/ /override/home/ /pathrule/home/secondhome/ /pathrule* /우선 처리/ /override/home/secondhome/ /집/ /pathrule* /우선 처리/ /override/home/ /home/secondhome/ /pathrule* /우선 처리/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /우선 처리/ /우선 처리/ /pathrule/home/secondhome/ /pathrule/home* /우선 처리/ /override/secondhome/ /경로규칙/ /경로규칙/ /우선 처리/ /우선 처리/
사용자 지정 프로브 사용
이 설정은 HTTP 설정과 사용자 지정 프로브를 연결합니다. 사용자 지정 프로브 1개만 HTTP 설정과 연결할 수 있습니다. 사용자 지정 프로브를 명시적으로 연결하지 않으면 기본 프로브가 백 엔드의 상태를 모니터링하는 데 사용됩니다. 백 엔드의 상태 모니터링을 보다 효율적으로 제어하려면 사용자 지정 프로브를 만드는 것이 좋습니다.
참고 항목
해당 HTTP 설정이 수신기와 명시적으로 연결되지 않은 경우 사용자 지정 프로브는 백 엔드 풀의 상태를 모니터링하지 않습니다.
호스트 이름 구성
Application Gateway는 클라이언트가 Application Gateway에 연결하는 데 사용하는 것과 다른 호스트 이름을 사용하도록 백 엔드에 설정된 연결을 허용합니다. 이 구성은 경우에 따라 유용할 수 있지만 애플리케이션 게이트웨이와 클라이언트가 백 엔드 대상과 비교하여 서로 다르도록 호스트 이름을 재정의할 때 주의해야 합니다.
프로덕션 환경에서는 클라이언트에서 애플리케이션 게이트웨이 연결에 동일한 호스트 이름을 사용하고 애플리케이션 게이트웨이를 백 엔드 대상 연결에 사용하는 것이 가장 좋습니다. 이 방법은 절대 URL, 리디렉션 URL 및 호스트 바인딩된 쿠키와 관련된 잠재적인 문제를 방지합니다.
이를 벗어나는 Application Gateway를 설정하기 전에 아키텍처 센터에서 자세히 설명한 대로 이러한 구성의 의미를 검토합니다. 역방향 프록시와 백 엔드 웹 애플리케이션 간에 원래 HTTP 호스트 이름을 유지합니다.
백 엔드에 연결하기 위해 Application Gateway에서 사용하는 Host
HTTP 헤더에 영향을 미치는 HTTP 설정에는 두 가지 측면이 있습니다.
- "백 엔드 주소에서 호스트 이름 선택"
- "호스트 이름 재정의"
백 엔드 주소에서 호스트 이름 선택
이 기능은 동적으로 요청의 호스트 헤더를 백 엔드 풀의 호스트 이름으로 설정합니다. IP 주소 또는 FQDN이 사용됩니다.
이 기능은 백 엔드의 도메인 이름이 애플리케이션 게이트웨이의 DNS 이름과 다르고 백 엔드가 특정 호스트 헤더를 사용하여 올바른 엔드포인트를 확인하는 경우에 도움이 됩니다.
예를 들어 다중 테넌트 서비스를 백 엔드로 사용합니다. 앱 서비스는 단일 IP 주소가 있는 공유 공간을 사용하는 다중 테넌트 서비스입니다. 따라서 사용자 지정 도메인 설정에서 구성된 호스트 이름을 통해서만 App Service에 액세스할 수 있습니다.
기본적으로 사용자 지정 도메인 이름은 example.azurewebsites.net입니다. App Service에 명시적으로 등록되지 않은 호스트 이름 또는 애플리케이션 게이트웨이의 FQDN을 통해 애플리케이션 게이트웨이를 사용하여 App Service에 액세스하려면 원래 요청의 호스트 이름을 App Service의 호스트 이름을 재정의할 수 있습니다. 이렇게 하려면 백 엔드 주소에서 호스트 이름 선택 설정을 사용하도록 설정합니다.
기존 사용자 지정 DNS 이름이 앱 서비스에 매핑된 사용자 지정 도메인의 경우 백 엔드 주소에서 선택 호스트 이름을 사용하도록 설정하지 않는 것이 좋습니다.
참고 항목
전용 배포인 App Service Environment에는 이 설정이 필요하지 않습니다.
호스트 이름 재정의
이 기능은 애플리케이션 게이트웨이에 들어오는 요청의 ‘호스트’ 헤더를 지정한 호스트 이름으로 바꿉니다.
예를 들어 www.contoso.com
설정에 지정된 경우 요청이 백 엔드 서버로 전달될 때 원래 요청 *https://appgw.eastus.cloudapp.azure.com/path1
이 *https://www.contoso.com/path1
로 변경됩니다.