역방향 프록시를 통해 Azure Spring 앱 노출

Azure Spring Apps에서 앱 또는 마이크로 서비스를 호스트하는 경우 항상 인터넷에 직접 게시하지 않으려는 것은 아닙니다. 대신 역방향 프록시를 통해 노출할 수 있습니다. 이 방법을 사용하면 앱 앞에 서비스를 배치할 수 있습니다. 이 서비스는 WAF(웹 애플리케이션 방화벽) 기능과 같은 교차 절단 기능을 정의하여 앱, 부하 분산, 라우팅, 요청 필터링 및 속도 제한을 보호할 수 있습니다.

azure Spring Apps 앞에 Azure 애플리케이션 Gateway 또는 Azure Front Door와 같은 일반적인 역방향 프록시 서비스를 배포하는 경우 역방향 프록시를 통해서만 앱에 연결할 수 있는지 확인해야 합니다. 이 보호 기능은 악의적인 사용자가 WAF를 우회하거나 제한 제한을 우회하지 못하도록 방지하는 데 도움이 됩니다.

애플리케이션 설계 모범 사례와 결합된 Azure DDoS Protection은 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 방어력을 높입니다. 경계 가상 네트워크에서 Azure DDOS Protection을 사용하도록 설정해야 합니다.

이 문서에서는 Azure Spring Apps에서 호스트되는 애플리케이션이 역방향 프록시 서비스를 통해서만 액세스할 수 있도록 액세스 제한을 적용하는 방법을 설명합니다. 이러한 제한을 적용하는 권장 방법은 Azure Spring Apps 인스턴스를 배포하는 방법과 사용하는 역방향 프록시에 따라 달라집니다. 가상 네트워크 내부 또는 외부에 배포하는지 여부에 따라 고려해야 할 점이 다릅니다. 이 문서에서는 네 가지 시나리오에 대한 정보를 제공합니다.

• 가상 네트워크 내에 Azure Spring Apps를 배포하고 네트워크 내에서 비공개로 앱에 액세스합니다.

  • 앱이 실행되는 가상 네트워크를 제어할 수 있습니다. NSG(네트워크 보안 그룹)와 같은 네이티브 Azure 네트워킹 기능을 사용하여 역방향 프록시만 허용하도록 액세스를 잠급니다.

  • Azure 애플리케이션 Gateway를 사용하여 앱을 인터넷에 공개적으로 공개한 다음 적절한 액세스 제한을 적용하여 잠글 수 있습니다. 이 방법은 이 문서의 뒷부분에 있는 시나리오 1 에서 설명합니다.

  • 프라이빗 가상 네트워크의 Azure Spring Apps 인스턴스에 연결할 수 없으므로 Azure Front Door를 직접 사용할 수 없습니다. Azure Front Door는 공용 IP 주소 또는 프라이빗 엔드포인트를 사용하는 서비스를 통해서만 백 엔드에 연결할 수 있습니다. Azure Spring Apps의 다중 지역 배포가 있고 전역 부하 분산이 필요한 경우 Application Gateway를 통해 Azure Spring Apps 인스턴스를 계속 노출할 수 있습니다. 이 시나리오를 수행하려면 Application Gateway 앞에 Azure Front Door를 배치합니다. 이 방법은 이 문서의 뒷부분에 있는 시나리오 2 에 설명되어 있습니다.

• 가상 네트워크 외부에 Azure Spring Apps를 배포하고 엔드포인트를 할당하는 경우 앱을 인터넷에 직접 게시합니다.

  • 네트워크를 제어하지 않으며 NSG를 사용하여 액세스를 제한할 수 없습니다. 역방향 프록시만 앱에 액세스하도록 허용하려면 Azure Spring Apps 자체 내에서 접근 방식이 필요합니다.

  • 앱은 공개적으로 연결할 수 있으므로 Application Gateway 또는 Azure Front Door를 역방향 프록시로 사용할 수 있습니다. Application Gateway 접근 방식은 이 문서의 뒷부분에 있는 시나리오 3 에 설명되어 있습니다. Azure Front Door 접근 방식은 이 문서의 뒷부분에 있는 시나리오 4 에 설명되어 있습니다.

  • 필요에 따라 두 방법의 조합을 사용할 수 있습니다. Application Gateway와 Azure Front Door를 모두 사용하는 경우 시나리오 2에서 사용되는 두 역방향 프록시 간에 동일한 액세스 제한을 사용합니다.

시나리오 비교

다음 표에서는 Azure Spring Apps에 대한 4가지 역방향 프록시 구성 시나리오를 간략하게 비교합니다. 각 시나리오에 대한 자세한 내용은 이 문서의 해당 섹션을 참조하세요.

가상 네트워크 내 배포

Azure Spring Apps가 가상 네트워크에 배포되면 다음 두 개의 서브넷을 사용합니다.

• 관련 네트워크 리소스를 포함하는 서비스 런타임 서브넷
• 코드를 호스트하는 앱 서브넷

서비스 런타임 서브넷에는 앱에 연결하기 위한 부하 분산 장치가 포함되어 있으므로 역방향 프록시의 트래픽만 허용하도록 이 서비스 런타임 서브넷에서 NSG를 정의할 수 있습니다. 다른 모든 트래픽을 차단하면 가상 네트워크의 아무도 역방향 프록시를 거치지 않고 앱에 액세스할 수 없습니다.

역방향 프록시를 통해 노출하려는 각 앱에는 할당된 엔드포인트가 있어야 역방향 프록시가 가상 네트워크의 앱에 연결할 수 있습니다. 또한 각 앱에 대해 역방향 프록시에서 HTTP Host 헤더를 재정의하지 않고 원래 호스트 이름을 그대로 유지하기 위해 사용하는 사용자 지정 do기본 매핑해야 합니다. 이 메서드는 제대로 작동하지 않는 쿠키 또는 리디렉션 URL과 같은 문제를 방지합니다. 자세한 내용은 호스트 이름 유지를 참조하세요.

시나리오 1: Application Gateway를 역방향 프록시로 사용

시나리오 1에서는 Application Gateway를 사용하여 앱을 인터넷에 공개적으로 공개한 다음 적절한 액세스 제한을 적용하여 잠그는 방법을 설명합니다.

다음 다이어그램은 시나리오 1의 아키텍처를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

Application Gateway가 Azure Spring Apps 인스턴스 앞에 있는 경우 Spring Cloud Gateway 앱의 할당된 엔드포인트를 백 엔드 풀로 사용합니다. 예제 엔드포인트는 myspringcloudservice-myapp.private.azuremicroservices.io입니다. 엔드포인트는 서비스 런타임 서브넷의 개인 IP 주소로 확인됩니다. 따라서 액세스를 제한하기 위해 다음 인바운드 보안 규칙을 사용하여 서비스 런타임 서브넷에 NSG를 배치할 수 있습니다(거부 규칙에 가장 낮은 우선 순위를 부여).

시나리오 1 구성은 서비스 런타임 서브넷이 다음 원본의 트래픽만 허용하도록 합니다.

• 전용 Application Gateway 서브넷
• 앱 서브넷(두 Azure Spring Apps 서브넷 간의 양방향 통신이 필요합니다.)
• Azure 부하 분산 장치(일반적인 Azure 플랫폼 요구 사항)

다른 모든 트래픽이 차단됩니다.

시나리오 2: Azure Front Door와 Application Gateway를 모두 역방향 프록시로 사용

앞에서 설명한 것처럼 Azure Front Door는 프라이빗 가상 네트워크에 연결할 수 없으므로 Azure Spring Apps 바로 앞에 배치할 수 없습니다. (Azure Front Door 표준 또는 프리미엄은 가상 네트워크의 프라이빗 엔드포인트에 연결할 수 있지만 Azure Spring Apps는 현재 프라이빗 엔드포인트 지원을 제공하지 않습니다.) 다른 Azure 지역의 여러 Azure Spring Apps 인스턴스에서 전역 부하 분산을 요구하는 등 Azure Front Door를 계속 사용하려는 경우에도 Application Gateway를 통해 앱을 노출할 수 있습니다. 이 시나리오를 수행하려면 Application Gateway 앞에 Azure Front Door를 배치합니다.

다음 다이어그램은 시나리오 2의 아키텍처를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 2 구성은 시나리오 1과 동일한 방식으로 Application Gateway와 Azure Spring Apps 간의 액세스 제한을 구현합니다. 적절한 규칙을 사용하여 서비스 런타임 서브넷에 NSG를 배치합니다.

시나리오 2에서는 Application Gateway가 Azure Front Door 인스턴스에서 들어오는 트래픽만 허용하도록 해야 합니다. Azure Front Door 설명서에서는 Azure Front Door 트래픽만 허용하도록 백 엔드에 대한 액세스를 잠그는 방법을 설명합니다. 백 엔드가 Application Gateway인 경우 다음과 같이 이 제한을 구현할 수 있습니다.

• Application Gateway 서브넷에서 서비스 태그가 있는 AzureFrontDoor.Backend 트래픽만 허용하는 NSG를 만듭니다(Azure Front Door 외에는 Application Gateway에 연결할 수 없음). Application Gateway에 대한 NSG 제한에 설명된 대로 다른 필수 서비스 태그도 포함해야 합니다.
• Application Gateway에서 사용자 지정 WAF 규칙을 만들어 HTTP 헤더가 X-Azure-FDID 특정 Azure Front Door 인스턴스 ID로 설정되어 있는지 확인합니다. 이 방법을 사용하면 동일한 IP 범위를 사용하는 다른 조직의 Azure Front Door 인스턴스가 Application Gateway 인스턴스에 연결할 수 없습니다.

가상 네트워크 외부 배포

가상 네트워크 외부에 Azure Spring Apps를 배포하는 경우 네트워크를 제어하지 않으므로 네이티브 Azure 네트워킹 기능을 사용할 수 없습니다. 대신 역방향 프록시의 트래픽만 허용하도록 앱 자체에 필요한 액세스 제한을 적용해야 합니다. 앱이 많은 경우 이 접근 방식은 복잡성을 더할 수 있으며 모든 앱을 적절하게 구성할 수 없는 위험이 있습니다.

Spring Cloud Gateway를 사용하여 앱 노출 및 보안 지원

개별 애플리케이션의 개발자로부터 액세스 제어 책임을 제거하려면 Spring Cloud Gateway를 사용하여 교차 절단 제한을 적용할 수 있습니다. Spring Cloud Gateway는 다른 앱과 마찬가지로 Azure Spring Apps에 배포할 수 있는 일반적으로 사용되는 Spring 프로젝트입니다. Spring Cloud Gateway를 사용하면 Azure Spring Apps 인스턴스 내에서 고유한 애플리케이션을 비공개로 유지하고 공유 Spring Cloud Gateway 앱을 통해서만 액세스할 수 있는지 확인할 수 있습니다. 그런 다음, Spring Cloud Gateway의 기본 제공 기능인 경로 조건자를 사용하여 필요한 액세스 제한으로 이 앱을 구성합니다. 경로 조건자는 들어오는 HTTP 요청의 다른 특성을 사용하여 백 엔드 애플리케이션으로 요청을 라우팅할지 아니면 거부할지를 결정할 수 있습니다. 조건자는 클라이언트 IP 주소, 요청 메서드 또는 경로, HTTP 헤더 등과 같은 특성을 사용할 수 있습니다.

이 패턴은 일반적으로 사용됩니다. 이 문서의 목적을 위해 Spring Cloud Gateway를 통해 애플리케이션을 노출한다고 가정합니다. 역방향 프록시의 요청만 허용되도록 경로 조건자를 사용하여 필요한 액세스 제한을 설정하는 것이 좋습니다. Spring Cloud Gateway를 사용하지 않더라도 동일한 일반 원칙이 적용됩니다. 그러나 이 문서의 뒷부분에서 설명한 것과 동일한 X-Forwarded-For HTTP 헤더를 기반으로 앱에 고유한 요청 필터링 기능을 빌드해야 합니다.

Spring Cloud Gateway의 작동 방식을 설명하는 것은 이 문서의 범위를 벗어납니다. 코드 또는 구성을 통해 사용자 지정할 수 있는 매우 유연한 서비스입니다. 이 문서에서는 작업을 간단하게 유지하기 위해 코드 변경이 필요하지 않은 순수한 구성 기반 접근 방식만 설명합니다. 배포된 Spring Cloud Gateway 앱에 기존 application.properties 또는 application.yml 파일을 포함하여 이 방법을 구현할 수 있습니다. 구성 파일을 Git 리포지토리로 외부화하는 Azure Spring Apps의 Config Server를 사용하여 이 방법을 구현할 수도 있습니다. 다음 예제에서는 YAML 구문을 사용하여 접근 방식을 구현 application.yml 하지만 동등한 application.properties 구문도 작동합니다.

애플리케이션에 요청 라우팅

기본적으로 Azure Spring Apps의 앱에 할당된 엔드포인트 또는 이를 위해 구성된 사용자 지정 도메인이 없는 경우 외부에서 연결할 수 없습니다. 앱 이 Spring Cloud Service Registry에 등록되면 Spring Cloud Gateway는 라우팅 규칙을 사용하여 트래픽을 올바른 대상 앱으로 전달할 수 있도록 앱을 검색할 수 있습니다.

따라서 Azure Spring Apps에서 엔드포인트를 할당해야 하는 유일한 앱은 Spring Cloud Gateway 앱입니다. 이 엔드포인트를 사용하면 외부에서 연결할 수 있습니다. 다른 앱에 엔드포인트를 할당해서는 안 됩니다. 그렇지 않으면 Spring Cloud Gateway를 통해서가 아니라 직접 앱에 연결할 수 있으며, 이를 통해 역방향 프록시를 우회할 수 있습니다.

Spring Cloud Gateway를 통해 등록된 모든 앱을 쉽게 노출하는 방법은 다음과 같이 DiscoveryClient 경로 정의 로케이터를 사용하는 것입니다.

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

또는 앱별 경로를 정의하여 Spring Cloud Gateway를 통해 특정 앱을 선택적으로 노출할 수 있습니다.

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

검색 로케이터 접근 방식과 명시적 경로 정의를 모두 사용하면 경로 조건자를 사용하여 잘못된 요청을 거부할 수 있습니다. 이 경우 이 기능을 사용하여 Azure Spring Apps 앞에 있는 예상 역방향 프록시에서 제공되지 않는 요청을 차단합니다.

X-Forwarded-For HTTP 헤더를 사용하여 액세스 제한

Azure Spring Apps에 앱을 배포하는 경우 HTTP 클라이언트 또는 역방향 프록시는 앱에 직접 연결되지 않습니다. 네트워크 트래픽은 먼저 내부 수신 컨트롤러를 통과합니다.

추가 서비스로 인해 직접 네트워크 클라이언트의 IP 주소는 항상 내부 Azure Spring Apps 구성 요소입니다. IP 주소는 앱을 호출하려는 역방향 프록시와 같은 논리 클라이언트가 되지 않습니다. 액세스 제한에는 클라이언트 IP 주소를 사용할 수 없습니다. 또한 기본적으로 클라이언트 IP 주소를 사용하므로 요청 필터링에 RemoteAddr Spring Cloud Gateway의 기본 제공 경로 조건 자를 사용할 수 없습니다.

다행히 Azure Spring Apps는 항상 앱에 대한 요청에 있는 X-Forwarded-For HTTP 헤더에 논리 클라이언트의 IP 주소를 추가합니다. 헤더의 X-Forwarded-For 마지막(가장 오른쪽) 값에는 항상 논리 클라이언트의 IP 주소가 포함됩니다.

헤더를 기반으로 X-Forwarded-For 요청을 필터링하려면 기본 제공 XForwarded Remote Addr 경로 조건자를 사용할 수 있습니다. 이 조건자를 사용하면 가장 적합한 값으로 허용되는 역방향 프록시의 IP 주소 또는 IP 범위 목록을 구성할 수 있습니다.

올바른 호스트 이름 및 요청 URL을 표시하도록 앱 구성

Spring Cloud Gateway를 사용하는 경우 고려해야 할 중요한 요소가 있습니다. Spring Cloud Gateway는 아웃바운드 요청의 HTTP Host 헤더를 앱 인스턴스의 내부 IP 주소(예: .)로 Host: 10.2.1.15:1025설정합니다. 애플리케이션 코드에서 보는 요청의 호스트 이름은 브라우저에서 보낸 요청의 원래 호스트 이름(예: contoso.com)이 아닙니다. 경우에 따라 이 결과로 인해 쿠키 손상 또는 리디렉션 URL이 제대로 작동하지 않는 등의 문제가 발생할 수 있습니다. 이러한 유형의 문제 및 이러한 문제를 방지하기 위해 Application Gateway 또는 Azure Front Door와 같은 역방향 프록시 서비스를 구성하는 방법에 대한 자세한 내용은 호스트 이름 유지를 참조하세요.

Spring Cloud Gateway는 헤더에 원래 호스트 이름을 Forwarded 제공합니다. 또한 다른 헤더(예: X-Forwarded-Port<a0/>X-Forwarded-Prefix)를 설정하므로 애플리케이션에서 이를 사용하여 원래 요청 URL을 다시 구성할 수 있습니다. Spring Framework 애플리케이션에서는 애플리케이션 속성에서 설정을 설정 server.forward-headers-strategy 하여 이 구성을 FRAMEWORK 자동으로 수행할 수 있습니다. (이 값을 NATIVE으로 설정하지 마세요. 그렇지 않으면 필요한 X-Forwarded-Prefix 헤더를 고려하지 않는 다른 헤더가 사용됩니다.) 자세한 내용은 프런트 엔드 프록시 서버 뒤에서 실행을 참조 하세요. 이 구성 을 사용하면 HttpServletRequest.getRequestURL 메서드는 이러한 모든 헤더를 고려하여 브라우저에서 보낸 정확한 요청 URL을 반환합니다.

시나리오 3: Spring Cloud Gateway에서 Application Gateway 사용

시나리오 3에서는 Spring Cloud Gateway 엔드포인트를 통해 공개적으로 연결할 수 있는 앱에 대한 역방향 프록시로 Application Gateway를 사용하는 방법을 설명합니다.

다음 다이어그램은 시나리오 3의 아키텍처를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

Application Gateway가 Azure Spring Apps 인스턴스 앞에 있는 경우 Spring Cloud Gateway 앱의 할당된 엔드포인트를 백 엔드 풀로 사용합니다. 예제 엔드포인트는 myspringcloudservice-mygateway.azuremicroservices.io입니다. Azure Spring Apps는 가상 네트워크 외부에 배포되므로 이 URL은 공용 IP 주소로 확인됩니다. 백 엔드 풀이 퍼블릭 엔드포인트인 경우 Application Gateway는 프런트 엔드 공용 IP 주소를 사용하여 백 엔드 서비스에 연결합니다.

Application Gateway 인스턴스의 요청만 Spring Cloud Gateway에 도달하도록 허용하려면 경로 조건자를 XForwarded Remote Addr 구성할 수 있습니다. 다음 예제와 같이 Application Gateway의 전용 공용 IP 주소에서만 요청을 허용하도록 조건자를 구성합니다.

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

시나리오 4: Spring Cloud Gateway에서 Azure Front Door 사용

시나리오 4에서는 Spring Cloud Gateway 엔드포인트를 통해 공개적으로 연결할 수 있는 앱의 역방향 프록시로 Azure Front Door를 사용하는 방법을 설명합니다.

다음 다이어그램은 시나리오 4의 아키텍처를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

시나리오 3과 마찬가지로 이 구성은 Spring Cloud Gateway 앱의 공용 URL을 Azure Front Door의 백 엔드 풀 또는 원본으로 사용합니다. 예제 엔드포인트는 https://myspringcloudservice-mygateway.azuremicroservices.io입니다.

Azure Front Door는 에지 위치가 많은 글로벌 서비스이므로 많은 IP 주소를 사용하여 백 엔드 풀과 통신합니다. Azure Front Door 설명서에서는 Azure Front Door 트래픽만 허용하도록 백 엔드에 대한 액세스를 잠그는 방법을 설명합니다. 그러나 이 시나리오에서는 앱이 배포되는 Azure 네트워크를 제어하지 않습니다. 아쉽게도 서비스 태그를 AzureFrontDoor.Backend 사용하여 최신 상태로 보장되는 아웃바운드 Azure Front Door IP 주소의 전체 목록을 가져올 수는 없습니다. 대신 Azure IP 범위 및 서비스 태그를 다운로드하고, 섹션을 AzureFrontDoor.Backend 찾고, 배열의 addressPrefixes 모든 IP 범위를 경로 조건자 구성으로 XForwarded Remote Addr 복사해야 합니다.

Azure Front Door IP 범위는 다른 조직과 공유되므로 고유한 Front Door IDHTTP 헤더를 기반으로 특정 Azure Front Door 인스턴스에 X-Azure-FDID 대한 액세스만 잠가야 합니다. 지정된 HTTP 헤더에 특정 값이 Header 없는 한 요청을 거부하는 경로 조건자를 사용하여 액세스를 제한할 수 있습니다.

이 시나리오에서는 Spring Cloud Gateway 경로 조건자 구성이 다음 예제와 같이 표시될 수 있습니다.

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "e483e3cc-e7f3-4e0a-9eca-5f2a62bde229"

참가자

Microsoft는 이 콘텐츠를 기본. 다음 기여자 원본 콘텐츠를 개발했습니다.

보안 주체 작성자:

• Jelle Druyts | 수석 고객 엔지니어

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

• Azure Spring Apps 참조 아키텍처
• Azure Virtual Networks에서 Azure Spring Apps를 실행하기 위한 고객의 책임

관련 참고 자료

• 호스트 이름 유지
• 부하 분산 옵션
• 마이크로 서비스 아키텍처 스타일