Application Gateway HTTP 설정 구성
애플리케이션 게이트웨이는 여기에서 지정한 구성을 사용하여 트래픽을 백 엔드 서버로 라우팅합니다. HTTP 설정을 만든 후에는 하나 이상의 요청 라우팅 규칙과 연결해야 합니다.
쿠키 기반 선호도
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 특성을 설정한 경우 쿠키에 Secure 플래그도 포함되어야 하며 HTTPS를 통해 전송되어야 합니다. CORS에서 세션 선호도가 필요한 경우 워크로드를 HTTPS로 마이그레이션해야 합니다. 개요, Azure Portal을 사용하여 TLS 종료로 애플리케이션 게이트웨이 구성, 포털에서 Application Gateway를 사용하여 엔드투엔드 TLS 구성에서 Application Gateway에 대한 TLS 오프로드 및 엔드투엔드 TLS 설명서를 참조하세요.
연결 드레이닝
연결 드레이닝은 예정된 서비스 업데이트 중에 백 엔드 풀 멤버를 정상적으로 제거하는 데 도움이 됩니다. 백 엔드 풀에서 명시적으로 제거되거나
- 스케일 인 작업 중에 제거되거나
- 상태 프로브에서 비정상으로 보고된
- 백 엔드 인스턴스에 적용됩니다.
백 엔드 설정에서 연결 드레이닝을 사용하도록 설정하여 모든 백 엔드 풀 멤버에 이 설정을 적용할 수 있습니다. 구성된 제한 시간 값까지 기존 연결을 유지하면서 백 엔드 풀의 모든 등록 취소 인스턴스가 새 요청/연결을 수신하지 않도록 합니다. 이는 WebSocket 연결에서도 마찬가지입니다.
| 구성 형식 | 값 |
|---|---|
| 백 엔드 설정에서 연결 드레이닝이 사용하도록 설정되지 않은 경우 기본값 | 30초 |
| 백 엔드 설정에서 연결 드레이닝이 사용하도록 설정된 경우 사용자 정의 값 | 1~3600초 |
단, 게이트웨이 관리형 세션 선호도로 인해 등록 취소 인스턴스에 바인딩된 요청은 예외이며 계속해서 등록 취소 인스턴스에 전달됩니다.
프로토콜
Application Gateway는 요청을 백 엔드 서버로 라우팅할 때 HTTP와 HTTPS를 모두 지원합니다. HTTP를 선택하면 백 엔드 서버에 대한 트래픽이 암호화되지 않습니다. 암호화되지 않은 통신이 허용되지 않는 경우 HTTPS를 선택합니다.
이 설정은 수신기의 HTTPS와 결합되어 엔드투엔드 TLS를 지원합니다. 이렇게 하면 암호화된 중요한 데이터를 백 엔드에 안전하게 전송할 수 있습니다. 엔드투엔드 TLS를 사용할 수 있는 백 엔드 풀의 각 백 엔드 서버가 보안 통신을 허용하는 인증서로 구성되어야 합니다.
포트
이 설정은 백 엔드 서버가 애플리케이션 게이트웨이의 트래픽을 수신 대기하는 포트를 지정합니다. 1에서 65535 사이의 포트를 구성할 수 있습니다.
신뢰할 수 있는 루트 인증서
HTTPS를 백 엔드 프로토콜로 선택하는 경우 Application Gateway에는 엔드투엔드 SSL에 대한 백 엔드 풀을 신뢰하기 위해 신뢰할 수 있는 루트 인증서가 필요합니다. 기본적으로 잘 알려진 CA 인증서 사용 옵션은 아니요로 설정되어 있습니다. 자체 서명된 인증서 또는 내부 인증 기관에서 서명한 인증서를 사용하려는 경우 백 엔드 풀에서 사용할 일치하는 공용 인증서를 Application Gateway에 제공해야 합니다. 이 인증서는 .CER 형식으로 Application Gateway에 직접 업로드해야 합니다.
신뢰할 수 있는 공용 인증 기관에서 서명한 백 엔드 풀의 인증서를 사용하려는 경우 잘 알려진 CA 인증서 사용 옵션을 예로 설정하고 공용 인증서 업로드를 건너뛸 수 있습니다.
요청 시간 초과
이 설정은 애플리케이션 게이트웨이가 백 엔드 서버에서 응답을 받기 위해 대기하는 시간(초)입니다.
백 엔드 경로 재정의
이 설정을 사용하면 요청이 백 엔드로 전달될 때 사용할 선택적 사용자 지정 전달 경로를 구성할 수 있습니다. 백 엔드 경로 재정의 필드의 사용자 지정 경로와 일치하는 들어오는 경로 부분이 전달된 경로에 복사됩니다. 다음 표는 이 기능의 작동 방식을 보여 줍니다.
HTTP 설정이 기본 요청 라우팅 규칙에 연결된 경우
원본 요청 백 엔드 경로 재정의 백 엔드에 전달되는 요청 /home/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ HTTP 설정이 경로 기반 요청 라우팅 규칙에 연결된 경우
원본 요청 경로 규칙 백 엔드 경로 재정의 백 엔드에 전달되는 요청 /pathrule/home/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /home/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/home/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /pathrule/ /pathrule/ /override/ /override/
사용자 지정 프로브 사용
이 설정은 HTTP 설정과 사용자 지정 프로브를 연결합니다. 사용자 지정 프로브 1개만 HTTP 설정과 연결할 수 있습니다. 사용자 지정 프로브를 명시적으로 연결하지 않으면 기본 프로브가 백 엔드의 상태를 모니터링하는 데 사용됩니다. 백 엔드의 상태 모니터링을 보다 효율적으로 제어하려면 사용자 지정 프로브를 만드는 것이 좋습니다.
참고 항목
해당 HTTP 설정이 수신기와 명시적으로 연결되지 않은 경우 사용자 지정 프로브는 백 엔드 풀의 상태를 모니터링하지 않습니다.
호스트 이름 구성
Application Gateway는 클라이언트가 Application Gateway에 연결하는 데 사용하는 것과 다른 호스트 이름을 사용하도록 백 엔드에 설정된 연결을 허용합니다. 이 구성은 경우에 따라 유용할 수 있지만 클라이언트와 애플리케이션 게이트웨이 및 백 엔드 대상에 대한 애플리케이션 게이트웨이 간에 서로 다른 호스트 이름을 재정의하는 것은 주의해서 수행해야 합니다.
프로덕션에서는 애플리케이션 게이트웨이가 백 엔드 대상에 사용하는 것과 동일한 호스트 이름으로 클라이언트가 애플리케이션 게이트웨이를 향해 사용하는 호스트 이름을 유지하는 것이 좋습니다. 이렇게 하면 절대 URL, 리디렉션 URL 및 호스트 바인딩 쿠키와 관련된 잠재적인 문제를 피할 수 있습니다.
이와 다른 Application Gateway를 설정하기 전에 아키텍처 센터에서 자세히 설명한 대로 이러한 구성의 영향을 검토하세요. 역방향 프록시와 해당 백 엔드 웹 애플리케이션 간에 원래 HTTP 호스트 이름 유지
백 엔드에 연결하기 위해 Application Gateway에서 사용하는 Host HTTP 헤더에 영향을 미치는 HTTP 설정에는 두 가지 측면이 있습니다.
- "백 엔드 주소에서 호스트 이름 선택"
- "호스트 이름 재정의"
백 엔드 주소에서 호스트 이름 선택
이 기능은 동적으로 요청의 호스트 헤더를 백 엔드 풀의 호스트 이름으로 설정합니다. IP 주소 또는 FQDN이 사용됩니다.
이 기능은 백 엔드의 도메인 이름이 애플리케이션 게이트웨이의 DNS 이름과 다르고 백 엔드가 특정 호스트 헤더를 사용하여 올바른 엔드포인트를 확인하는 경우에 도움이 됩니다.
예를 들어 다중 테넌트 서비스가 백 엔드로 사용되는 경우입니다. App Service는 단일 IP 주소로 공유 공간을 사용하는 다중 테넌트 서비스입니다. 따라서 사용자 지정 도메인 설정에서 구성된 호스트 이름을 통해서만 App Service에 액세스할 수 있습니다.
기본적으로 사용자 지정 도메인 이름은 example.azurewebsites.net입니다. App Service에 명시적으로 등록되지 않은 호스트 이름 또는 애플리케이션 게이트웨이의 FQDN을 통해 애플리케이션 게이트웨이를 사용하여 App Service에 액세스하려면 원래 요청의 호스트 이름을 App Service의 호스트 이름을 재정의할 수 있습니다. 이렇게 하려면 백 엔드 주소에서 호스트 이름 선택 설정을 사용하도록 설정합니다.
기존 사용자 지정 DNS 이름이 App Service에 매핑된 사용자 지정 도메인의 경우 권장되는 구성은 백 엔드 주소에서 호스트 이름 선택을 사용하도록 설정하지 않는 것이 좋습니다.
참고 항목
전용 배포인 App Service Environment에서는 이 설정이 필요 없습니다.
호스트 이름 재정의
이 기능은 애플리케이션 게이트웨이에 들어오는 요청의 ‘호스트’ 헤더를 지정한 호스트 이름으로 바꿉니다.
예를 들어 호스트 이름 설정에 www.contoso.com이 지정된 경우 요청이 백 엔드 서버에 전달될 때 원래 요청 *https://appgw.eastus.cloudapp.azure.com/path1이 *https://www.contoso.com/path1로 변경됩니다.