Application Gateway를 사용하여 HTTP 헤더 및 URL 다시 쓰기

Application Gateway를 사용하면 선택한 요청 및 응답 내용을 다시 쓸 수 있습니다. 이 기능을 사용하면 URL, 쿼리 문자열 매개 변수를 변환하고 요청 및 응답 헤더를 수정할 수 있습니다. 특정 조건이 충족되는 경우에만 URL 또는 지정된 헤더를 다시 쓸 수 있도록 조건을 추가할 수도 있습니다. 이러한 조건은 요청 및 응답 정보를 기반으로 합니다.

HTTP 헤더 및 URL 다시 쓰기 기능은 Application Gateway v2 SKU에서만 사용할 수 있습니다.

요청 및 응답 헤더

Application Gateway는 요청 및 응답 패킷이 클라이언트와 백 엔드 풀 사이를 이동하는 동안 HTTP 요청 및 응답 헤더를 추가, 제거 또는 업데이트할 수 있습니다. HTTP 헤더를 통해 클라이언트와 서버는 요청 또는 응답과 함께 추가 정보를 전달할 수 있습니다. 헤더를 다시 쓰면 HSTS/X-XSS-Protection과 같은 보안 관련 헤더 필드 추가, 중요한 정보를 노출할 수 있는 응답 헤더 필드 제거, X-Forwarded-For 헤더에서 포트 정보 제거와 같은 중요한 작업을 수행할 수 있습니다.

요청 및 응답에서 모든 헤더를 다시 쓸 수 있습니다( 및 Upgrade 헤더 제외Connection). 애플리케이션 게이트웨이를 사용하여 사용자 지정 헤더를 만들고 이를 통해 라우팅되는 요청 및 응답에 추가할 수도 있습니다. Azure Portal을 사용하여 Application Gateway로 요청 및 응답 헤더를 다시 쓰는 방법을 알아보려면 여기를 참조하세요.

URL 경로 및 쿼리 문자열

Application Gateway의 URL 다시 쓰기 기능을 사용하여 다음을 수행할 수 있습니다.

• 요청 URL의 호스트 이름, 경로 및 쿼리 문자열을 다시 씁니다.

• 리스너에서 모든 요청의 URL을 다시 쓰거나 설정한 조건 중 하나 이상과 일치하는 요청만 다시 쓰도록 선택합니다. 이러한 조건은 요청 속성(요청 헤더 및 서버 변수)을 기반으로 합니다.

• 원래 URL 또는 다시 쓴 URL을 기반으로 요청을 라우팅하도록 선택합니다(백 엔드 풀 선택).

Azure Portal을 사용하여 Application Gateway로 URL을 다시 쓰는 방법을 알아보려면 여기를 참조하십시오.

Application Gateway에서 다시 쓰기 이해

다시 쓰기 집합은 라우팅 규칙, 조건 및 작업의 컬렉션입니다.

• 요청 라우팅 규칙 연결: 다시 쓰기 구성은 해당 라우팅 규칙을 통해 원본 수신기에 연결됩니다. Basic 형식의 라우팅 규칙을 사용하는 경우 다시 쓰기 구성은 해당 수신기와 연결되고 전역 다시 쓰기로 작동합니다. 경로 기반 라우팅 규칙을 사용하는 경우 URL 경로 맵에 따라 다시 쓰기 구성이 정의됩니다. 후자의 경우 사이트의 특정 경로 영역에만 적용됩니다. 여러 라우팅 규칙에 다시 쓰기 집합을 적용할 수 있지만 라우팅 규칙에는 연결된 다시 쓰기가 하나만 있을 수 있습니다.

• 조건 다시 쓰기: 선택적 구성입니다. 정의한 조건에 따라 Application Gateway는 HTTP(S) 요청 및 응답의 콘텐츠를 평가합니다. HTTP(S) 요청 또는 응답이 이 조건과 일치하는 경우 후속 "다시 쓰기 작업"이 발생합니다. 작업에 둘 이상의 조건을 연결할 경우 모든 조건이 충족되는 경우에만 작업이 수행됩니다. 즉, 논리 AND 연산입니다. 조건을 다시 작성하여 HTTP(S) 요청 및 응답의 콘텐츠를 평가할 수 있습니다. 이 선택적 구성을 사용하면 하나 이상의 조건이 충족되는 경우에만 다시 작성을 수행할 수 있습니다. 애플리케이션 게이트웨이는 다음 유형의 변수를 사용하여 요청 및 응답의 콘텐츠를 평가합니다.

  다음 형식을 선택하여 조건을 찾을 수 있습니다.

  • HTTP 헤더(요청 및 응답)
  • 지원되는 서버 변수

  조건을 사용하면 텍스트 또는 Regex 패턴을 통해 해당 값을 일치시켜 지정된 헤더 또는 변수가 존재하는지 여부를 평가할 수 있습니다. 고급 다시 쓰기 구성의 경우 나중에 다시 쓰기 작업에서 사용할 수 있는 헤더 또는 서버 변수 값을 캡처할 수도 있습니다. 패턴 및 캡처에 대해 자세히 알아봅니다.

• 다시 쓰기 작업: 다시 쓰기 작업 집합을 사용하면 헤더(요청 또는 응답) 또는 URL 구성 요소를 다시 쓸 수 있습니다.

  작업에는 다음 값 형식 또는 해당 조합이 있을 수 있습니다.

  • 텍스트.
  • 요청 헤더의 값 - 캡처된 요청 헤더의 값을 사용하려면 구문을 .로 {http_req_headerName}지정합니다.
  • 응답 헤더의 값 - 이전 조건의 캡처된 응답 헤더 값을 사용하려면 구문을 로 {http_resp_headerName}지정합니다. 다시 쓰기 작업 블록은 Set-Cookie 헤더에 대한 "헤더 값 일치자" 필드도 지원합니다. 이 선택적 필드를 사용하면 이름이 같은 여러 Set-Cookie 헤더가 있는 경우 특정 헤더의 값을 캡처할 뿐만 아니라 일치시킬 수 있습니다. 특정 쿠키의 캡처된 값을 조작하려면 다음을 사용할 {capt_header_value_matcher}수 있습니다. 작업 집합에서 캡처에 대해 자세히 알아봅니다.
  • 서버 변수 - 서버 변수를 사용하려면 구문을 .로 {var_serverVariable}지정합니다. 지원되는 서버 변수 목록입니다.

작업을 사용하여 URL을 다시 작성하는 경우 다음 작업이 지원됩니다.

• URL 경로: 경로로 설정할 새 값입니다.
• URL 쿼리 문자열: 쿼리 문자열을 다시 작성해야 하는 새 값입니다.
• 경로 맵 다시 평가: 다시 쓰기 후 URL 경로 맵을 다시 평가해야 하는지 여부를 지정합니다. 선택하지 않은 상태로 유지하면 원래 URL 경로가 URL 경로 맵의 경로 패턴과 일치하는 데 사용됩니다. true로 설정하면 URL 경로 맵이 다시 평가되어 다시 쓴 경로와 일치하는지 확인합니다. 이러한 전환이 가능하도록 설정하면 다시 쓴 후 요청을 다른 백 엔드 풀로 라우팅하는 데 도움이 됩니다.

패턴 일치 및 캡처

패튼 일치 및 캡처는 조건 및 작업에서 지원됩니다(작업에서 특정 헤더에 대해서만 지원됨).

패턴 일치

Application Gateway는 패턴 일치에 정규식을 사용합니다. 패턴 일치 구문을 작성할 때는 RE2(정규식 2) 호환 식을 사용해야 합니다.

조건 및 작업 모두에서 패턴 일치를 사용할 수 있습니다.

• 조건: 헤더 또는 서버 변수의 값과 일치하는 데 사용됩니다. "조건" 아래의 패턴과 일치하려면 "pattern" 속성을 사용합니다.
• 작업: 작업 집합의 패턴 일치는 응답 헤더 "Set-Cookie"에만 사용할 수 있습니다. 작업에서 Set-Cookie의 패턴을 일치하려면 "HeaderValueMatcher" 속성을 사용합니다. 캡처된 경우 해당 값을 {capt_header_value_matcher}으로 사용할 수 있습니다. 여러 Set-Cookie가 있을 수 있으므로 여기에 일치하는 패턴을 사용하면 특정 쿠키를 찾을 수 있습니다. 예: 특정 버전의 사용자 에이전트의 경우 max-age=3600(1시간)으로 "cookie2"에 대한 set-cookie 응답 헤더를 다시 작성하려고 합니다. 이 경우 사용할 수 있습니다.
  • 조건 - 유형: 요청 헤더, 헤더 이름: user-agent, 일치시킬 패턴: *2.0
  • 작업 - 다시 쓰기 유형: 응답 헤더, 작업 유형: Set, Header name: Set-Cookie, Header Value Matcher: cookie2=(.*), Header value: cookie2={capt_header_value_matcher_1}; Max-Age=3600

캡처 구문

패턴을 사용하여 나중에 사용할 하위 문자열을 캡처할 수도 있습니다. regex 정의에서 하위 패턴 주위에 괄호를 배치합니다. 첫 번째 괄호 쌍은 하위 문자열을 1에 저장하고 두 번째 쌍은 2에 저장하는 식입니다. 괄호는 원하는 만큼 사용할 수 있습니다. Perl은 캡처된 문자열을 표현할 수 있도록 번호가 매겨진 변수를 더 많이 정의하고 있습니다. 이 Perl 프로그래밍 지침에서 몇 가지 예를 찾을 수 있습니다.

• (\d)(\d) # 두 숫자를 일치시켜 그룹 1과 2로 캡처합니다.
• (\d+) # 하나 이상의 숫자를 일치시켜 모두 그룹 1로 캡처합니다.
• (\d)+ # 숫자를 한 번 이상 일치시켜 마지막 숫자를 그룹 1로 캡처합니다.

캡처되면 다음 형식을 사용하여 작업 집합 값에서 사용할 수 있습니다.

• 요청 헤더 캡처의 경우 {http_req_headerName_groupNumber}를 사용해야 합니다. 예: {http_req_User-Agent_1} 또는 {http_req_User-Agent_2}
• 응답 헤더 캡처의 경우 {http_resp_headerName_groupNumber}를 사용해야 합니다. 예를 들어 {http_resp_Location_1} 또는 {http_resp_Location_2}입니다. "HeaderValueMatcher" 속성을 통해 캡처된 응답 헤더 Set-Cookie의 경우 {capt_header_value_matcher_groupNumber}을(를) 사용해야 합니다. 예를 들어 {capt_header_value_matcher_1} 또는 {capt_header_value_matcher_2}입니다.
• 서버 변수의 경우 {var_serverVariableName_groupNumber}를 사용해야 합니다. 예: {var_uri_path_1} 또는 {var_uri_path_2}

서버 변수

Application Gateway 서버 변수를 사용하여 서버, 클라이언트와의 연결, 연결에 대한 현재 요청에 관련된 유용한 정보를 저장합니다. 저장되는 정보의 예에는 클라이언트의 IP 주소와 웹 브라우저 유형이 있습니다. 서버 변수는 동적으로(예: 새 페이지가 로드되거나 양식이 게시될 때) 변경됩니다. 이러한 변수를 사용하여 다시 쓰기 조건을 평가하고 헤더를 다시 쓸 수 있습니다. 서버 변수 값을 사용하여 헤더를 다시 쓰려면 {var_serverVariableName} 구문에서 이러한 변수를 지정해야 합니다.

애플리케이션 게이트웨이는 다음 서버 변수를 지원합니다.

상호 인증 서버 변수

Application Gateway는 상호 인증 시나리오에 대해 다음과 같은 서버 변수를 지원합니다. 이러한 서버 변수는 다른 서버 변수와 함께 위와 동일한 방식으로 사용합니다.

헤더 다시 쓰기에 대한 일반적인 시나리오

X-Forwarded-For 헤더에서 포트 정보 제거

Application Gateway는 백 엔드에 요청을 전달하기 전에 모든 요청에 X-Forwarded-For 헤더를 삽입합니다. 이 헤더는 IP 포트를 쉼표로 구분한 목록입니다. 백 엔드 서버에는 IP 주소만 포함된 헤더가 필요한 시나리오가 있을 수 있습니다. 헤더 다시 쓰기를 사용하여 X-Forwarded-For 헤더에서 포트 정보를 제거할 수 있습니다. 이 작업을 수행하는 한 가지 방법은 헤더를 add_x_forwarded_for_proxy 서버 변수로 설정하는 것입니다. 또는 client_ip 변수를 사용할 수도 있습니다.

리디렉션 URL 수정

리디렉션 URL 수정은 특정 상황에서 유용할 수 있습니다. 클라이언트는 원래 “/blog”와 같은 경로로 리디렉션되었지만 이제 콘텐츠 구조의 변경으로 인해 “/updates”로 전송되어야 하는 경우를 예로 들 수 있습니다.

앱 서비스가 리디렉션 응답을 보낼 때는 응답의 위치 헤더에 애플리케이션 게이트웨이에서 수신한 요청의 호스트 이름과 동일한 호스트 이름을 사용합니다. 따라서 클라이언트는 애플리케이션 게이트웨이(contoso.com/path2)를 통과하지 않고 contoso.azurewebsites.net/path2에 직접 요청을 보냅니다. 애플리케이션 게이트웨이를 우회하는 것은 바람직하지 않습니다.

이 문제는 위치 헤더의 호스트 이름을 애플리케이션 게이트웨이의 도메인 이름으로 설정하여 해결할 수 있습니다.

호스트 이름을 바꾸는 단계는 다음과 같습니다.

1. 응답의 위치 헤더에 azurewebsites.net이 포함되어 있는지 평가하는 조건으로 다시 쓰기 규칙을 만듭니다. (https?):\/\/.*azurewebsites\.net(.*)$ 패턴을 입력합니다.

2. 애플리케이션 게이트웨이의 호스트 이름을 포함하도록 위치 헤더를 다시 쓰는 작업을 수행합니다. 이 작업은 {http_resp_Location_1}://contoso.com{http_resp_Location_2}를 헤더 값으로 입력하여 수행합니다. 또는 서버 변수를 host를 사용하여 원래 요청과 일치하도록 호스트 이름을 설정할 수도 있습니다.

   

취약성을 방지하기 위해 보안 HTTP 헤더 구현

애플리케이션 응답에 필요한 헤더를 구현하여 여러 보안 취약점을 해결할 수 있습니다. 보안 헤더에는 X-XSS-Protection, Strict-Transport-Security 및 Content-Security-Policy가 포함됩니다. Application Gateway를 사용하여 모든 응답에 대해 해당 헤더를 설정할 수 있습니다.

원치 않는 헤더 삭제

HTTP 응답에서 중요한 정보를 나타내는 헤더는 제거하는 것이 좋습니다. 예를 들어 백 엔드 서버 이름, 운영 체제 또는 라이브러리 세부 정보와 같은 정보는 제거하는 것이 좋습니다. 애플리케이션 게이트웨이를 사용하여 해당 헤더를 제거할 수 있습니다.

호스트 헤더를 삭제하는 다시 쓰기 규칙을 만들 수 없습니다. 삭제할 작업 유형이 설정되고 헤더가 호스트로 설정된 다시 쓰기 규칙을 만들려고 하면 오류가 발생합니다.

헤더가 있는지 확인

헤더 또는 서버 변수가 있는지 HTTP 요청 또는 응답 헤더를 평가할 수 있습니다. 이 평가는 특정 헤더가 있는 경우에만 헤더 다시 쓰기를 수행하려는 경우 유용합니다.

URL 다시 쓰기에 대한 일반적인 시나리오

매개 변수 기반 경로 선택

요청의 헤더 값, URL의 일부 또는 쿼리 문자열을 기반으로 백 엔드 풀을 선택하는 시나리오를 수행하려면 URL 다시 쓰기 기능과 경로 기반 라우팅의 조합을 사용합니다.

이렇게 하려면 특정 매개 변수(쿼리 문자열, 헤더 등)를 확인하는 조건으로 다시 쓰기 집합을 만들고 URL 경로를 변경하는 작업을 수행합니다(경로 맵 다시 평가가 사용하도록 설정되어 있는지 확인). 그런 다음 다시 쓰기 집합을 경로 기반 규칙에 연결해야 합니다. 경로 기반 규칙에는 다시 쓰기 집합에 지정된 것과 동일한 URL 경로와 해당 백 엔드 풀이 포함되어야 합니다.

따라서 다시 쓰기 집합을 통해 사용자는 특정 매개 변수를 확인하고 이에 새 경로를 할당할 수 있으며, 경로 기반 규칙을 통해 사용자는 백 엔드 풀을 해당 경로에 할당할 수 있습니다. "경로 맵 다시 평가"가 사용하도록 설정되어 있는 경우 트래픽은 다시 쓰기 집합에 지정된 경로를 기준으로 라우팅됩니다.

쿼리 문자열을 사용하는 사용 사례의 경우 포털에서 매개 변수 기반 경로 선택을 사용하여 트래픽 라우팅을 참조하세요.

URL을 기반으로 쿼리 문자열 매개 변수 다시 쓰기

사용자가 볼 수 있는 링크는 간단하고 알기 쉬워야 하지만 백 엔드 서버는 올바른 콘텐츠를 표시하기 위해 쿼리 문자열 매개 변수가 필요한 쇼핑 웹 사이트의 시나리오를 고려해보겠습니다.

이 경우 Application Gateway는 URL에서 매개 변수를 캡처하고 URL에서 쿼리 문자열 키-값 쌍을 추가할 수 있습니다. 예를 들어, 사용자가 https://www.contoso.com/fashion/shirts를 https://www.contoso.com/buy.aspx?category=fashion&product=shirts로 다시 쓰려는 경우, 다음 URL 다시 쓰기 구성을 통해 수행할 수 있습니다.

조건 - 서버 변수 uri_path가 /(.+)/(.+) 패턴과 같은 경우

작업 - URL 경로는 buy.aspx로, 쿼리 문자열은 category={var_uri_path_1}&product={var_uri_path_2}로 설정합니다.

위에서 설명한 시나리오를 수행하는 단계별 가이드는 Azure Portal을 사용하여 Application Gateway로 URL 다시 쓰기를 참조하세요.

다시 쓰기 구성의 일반적인 단점

• 기본 요청 라우팅 규칙에는 ‘경로 맵 다시 평가’를 사용하도록 설정할 수 없습니다. 기본 라우팅 규칙에 대한 무한 평가 루프를 방지하기 위해서 입니다.

• 경로 기반 라우팅 규칙에 대한 무한 평가 루프를 방지하기 위해서는 경로 기반 라우팅 규칙에 대해 ‘경로 맵 다시 평가’를 사용하도록 설정하지 않은 다시 쓰기 규칙이 하나 이상 또는 조건부 다시 쓰기 규칙이 하나 이상 있어야 합니다.

• 클라이언트 입력을 기반으로 루프가 동적으로 생성되는 경우 들어오는 요청은 500 오류 코드로 종료됩니다. 이러한 시나리오에서 Application Gateway는 성능 저하 없이 계속해서 다른 요청을 처리합니다.

Web Application Firewall(WAF_v2 SKU)에서 URL 다시 쓰기 또는 호스트 헤더 다시 쓰기 사용

URL 다시 쓰기 또는 호스트 헤더 다시 쓰기를 구성하는 경우 요청 헤더 또는 URL 매개 변수를 수정한 후(다시 쓴 후) WAF 평가가 수행됩니다. 또한 Application Gateway에서 URL 다시 쓰기 또는 호스트 헤더 다시 쓰기 구성을 제거하면 헤더 다시 쓰기 전(pre-rewrite)에 WAF 평가가 수행됩니다. 이 순서를 통해 백 엔드 풀에서 받은 최종 요청에 WAF 규칙이 적용될 수 있습니다.

예를 들어 헤더 "Accept" : "text/html"에 대해 다음과 같은 헤더 다시 쓰기 규칙이 있다고 가정합니다. 헤더 "Accept"의 값이 "text/html"과 같으면 값을 "image/png"로 다시 씁니다.

여기서 헤더 다시 쓰기만 구성하면 "Accept" : "text/html"에 대해 WAF 평가가 수행됩니다. 하지만 URL 다시 쓰기 또는 호스트 헤더 다시 쓰기를 구성하면, "Accept" : "image/png"에 대해 WAF 평가가 수행됩니다.

URL 다시 쓰기와 URL 리디렉션

URL 다시 쓰기의 경우 요청이 백 엔드로 전송되기 전에 Application Gateway가 URL을 다시 씁니다. 변경 내용이 사용자에게 숨겨져 있기 때문에 브라우저에서 사용자에게 표시되는 내용은 변경되지 않습니다.

URL 리디렉션의 경우 Application Gateway는 새 URL을 사용하여 클라이언트에 리디렉션 응답을 보냅니다. 그러면 클라이언트는 해당 요청을 리디렉션에 제공된 새 URL로 다시 보내야 합니다. 브라우저에서 사용자에게 표시되는 URL이 새 URL로 업데이트됩니다.

제한 사항

• 애플리케이션 게이트웨이가 요청을 리디렉션하거나 사용자 지정 오류 페이지를 표시하도록 구성된 경우에는 다시 쓰기가 지원되지 않습니다.
• 요청 헤더 이름에는 영숫자와 하이픈이 포함될 수 있습니다. 다른 문자를 포함하는 헤더 이름은 요청이 백 엔드 대상으로 전송될 때 삭제됩니다.
• 응답 헤더 이름은 RFC 7230에 정의된 대로 영숫자 문자 및 특정 기호를 포함할 수 있습니다.
• 연결 및 업그레이드 헤더는 다시 쓸 수 없습니다.
• 다시 쓰기는 Application Gateway에서 직접 생성된 4xx 및 5xx 응답에 대해 지원되지 않습니다.

다음 단계

• Azure Portal을 사용하여 Application Gateway로 HTTP 헤더를 다시 쓰는 방법 알아보기
• Azure Portal을 사용하여 Application Gateway로 URL을 다시 쓰는 방법 알아보기