애플리케이션 게이트웨이 통합

이 문서에서는 프라이빗 엔드포인트를 사용하여 트래픽을 보호하여 App Service에서 Application Gateway를 구성하는 방법을 안내합니다. 또한 이 문서에서는 서비스 엔드포인트를 사용하고 내부 및 외부 App Service Environment와 통합하는 방법에 대한 고려 사항에 대해서도 설명합니다. 마지막으로 이 문서에서는 SCM(소스 제어 관리자) 사이트에 대한 액세스 제한을 설정하는 방법을 설명합니다.

App Service와 통합

프라이빗 엔드포인트를 사용하여 Application Gateway와 App Service 앱 간의 트래픽을 보호할 수 있습니다. Application Gateway가 DNS를 사용하여 App Service 앱의 개인 IP 주소를 확인할 수 있는지 확인해야 합니다. 또는 백 엔드 풀에서 개인 IP 주소를 사용하고 HTTP 설정에서 호스트 이름을 재정의할 수 있습니다.

Application Gateway는 DNS 조회 결과를 캐시합니다. FQDN(정규화된 도메인 이름)을 사용하고 DNS 조회를 사용하여 개인 IP 주소를 가져오는 경우 백 엔드 풀을 구성한 후 DNS 업데이트 또는 Azure 프라이빗 DNS 영역에 대한 링크가 발생하면 애플리케이션 게이트웨이를 다시 시작해야 할 수 있습니다.

애플리케이션 게이트웨이를 다시 시작하려면 Azure CLI를 사용하여 중지하고 시작합니다.

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

프라이빗 엔드포인트를 사용하여 App Service 앱을 구성하는 방법에 대해 자세히 알아봅니다.

서비스 엔드포인트 사용에 대한 고려 사항

프라이빗 엔드포인트 대신 서비스 엔드포인트를 사용하여 Application Gateway에서 트래픽을 보호할 수 있습니다. 서비스 엔드포인트를 사용하면 Azure 가상 네트워크 내 특정 서브넷의 트래픽만 허용하고 다른 모든 트래픽은 차단할 수 있습니다. 다음 시나리오에서는 이 기능을 사용하여 App Service 인스턴스가 특정 애플리케이션 게이트웨이에서만 트래픽을 수신할 수 있도록 합니다.

이 구성에는 App Service 앱 인스턴스 및 애플리케이션 게이트웨이를 만드는 것 외에 두 가지 부분이 있습니다. 첫 번째 부분은 애플리케이션 게이트웨이가 배포된 Virtual Network의 서브넷에서 서비스 엔드포인트를 사용하도록 설정하는 것입니다. 서비스 엔드포인트는 서브넷에서 App Service로 나가는 모든 네트워크 트래픽에 특정 서브넷 ID로 태그가 지정되도록 합니다.

두 번째 부분은 이 특정 서브넷 ID로 태그가 지정된 트래픽만 허용되도록 특정 웹 앱의 액세스 제한을 설정하는 것입니다. 기본 설정에 따라 다양한 도구를 사용하여 액세스 제한을 구성할 수 있습니다.

Azure Portal을 사용하면 네 단계에 따라 App Service 및 Application Gateway 설정을 만들고 구성할 수 있습니다. 기존 리소스가 있는 경우에는 첫 번째 단계를 건너뛰어도 됩니다.

1. App Service 설명서의 빠른 시작 중 하나를 사용하여 App Service 인스턴스를 만듭니다. 한 가지 예는 .NET Core 빠른 시작입니다.
2. 포털 빠른 시작을 사용하여 애플리케이션 게이트웨이를 만들되 백 엔드 대상 추가에 대한 섹션은 건너뜁니다.
3. App Service를 Application Gateway의 백 엔드로 구성하되 액세스 제한에 대한 섹션은 건너뜁니다.
4. 서비스 엔드포인트를 사용하여 액세스 제한을 만듭니다.

이제 Application Gateway를 통해 App Service에 액세스할 수 있습니다. App Service에 직접 액세스하려고 하면 웹앱이 액세스를 차단하고 있다는 403 HTTP 오류가 표시됩니다.

내부 App Service Environment에 대한 고려 사항

내부 App Service Environment는 인터넷에 노출되지 않습니다. 인스턴스와 애플리케이션 게이트웨이 간의 트래픽은 이미 가상 네트워크로 격리되어 있습니다. Azure Portal을 사용하여 내부 App Service Environment를 구성하고 애플리케이션 게이트웨이와 통합하려면 방법 가이드를 참조하세요.

Application Gateway 서브넷의 트래픽만 App Service Environment에 도달하도록 하려는 경우 App Service Environment의 모든 웹앱에 영향을 미치는 NSG(네트워크 보안 그룹)를 구성할 수 있습니다. NSG의 경우 서브넷 IP 범위를 지정할 수 있으며 선택적으로 포트(80/443)를 지정할 수 있습니다.

개별 웹앱에 대한 트래픽을 격리하려면 서비스 엔드포인트가 App Service Environment에서 작동하지 않기 때문에 IP 기반 액세스 제한을 사용해야 합니다. IP 주소는 애플리케이션 게이트웨이의 개인 IP여야 합니다.

외부 App Service Environment에 대한 고려 사항

외부 App Service Environment에는 다중 테넌트 App Service 앱과 같은 공용 부하 분산 장치가 있습니다. App Service Environment에서는 서비스 엔드포인트가 작동하지 않습니다. App Service Environment를 사용하면 애플리케이션 게이트웨이의 공용 IP 주소를 사용하여 IP 기반 액세스 제한을 사용할 수 있습니다. Azure Portal을 사용하여 외부 App Service Environment를 만들려면 이 빠른 시작을 따라야 합니다.

외부 App Service Environment에서 호스트되는 앱에 프라이빗 엔드포인트를 추가할 수도 있습니다.

Kudu/SCM 사이트에 대한 고려 사항

Kudu라고도 알려진 SCM 사이트는 모든 웹앱에 존재하는 관리 사이트입니다. SCM 사이트에는 역방향으로 프록시를 사용할 수 없습니다. 또한 개별 IP 주소나 특정 서브넷으로 잠그고 싶을 수도 있습니다.

기본 사이트와 동일한 액세스 제한을 사용하려는 경우 다음 명령을 사용하여 설정을 상속할 수 있습니다.

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

SCM 사이트에 대한 개별 액세스 제한을 추가하려면 --scm-site 플래그를 사용할 수 있습니다.

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

기본 도메인 사용 시 고려 사항

호스트 이름을 재정의하고 App Service의 기본 도메인(일반적으로 azurewebsites.net)을 사용하도록 Application Gateway를 구성하는 것이 통합을 구성하는 가장 쉬운 방법입니다. App Service에서 사용자 지정 도메인 및 인증서를 구성할 필요가 없습니다.

이 문서에서는 원래 호스트 이름을 재정의하기 위한 일반적인 고려 사항에 대해 설명합니다. App Service에는 이 구성에 주의해야 하는 두 가지 시나리오가 있습니다.

인증

App Service(Easy Auth라고도 함)에서 인증 기능을 사용하면 일반적으로 앱이 로그인 페이지로 리디렉션됩니다. App Service는 요청의 원래 호스트 이름을 모르기 때문에 리디렉션은 기본 도메인 이름에서 수행되며 일반적으로 오류가 발생합니다.

기본 리디렉션을 해결하려면 전달된 헤더를 검사하고 리디렉션 도메인을 원래 도메인에 맞게 조정하도록 인증을 구성하면 됩니다. Application Gateway는 X-Original-Host라는 헤더를 사용합니다. 파일 기반 구성을 사용하여 인증을 구성하면 원래 호스트 이름에 맞게 App Service를 구성할 수 있습니다. 구성 파일에 다음 구성을 추가합니다.

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

세션 선호도

다중 인스턴스 배포 에서 세션 선호도 는 클라이언트 요청이 세션 수명 동안 동일한 인스턴스로 라우팅되도록 합니다. 역방향 프록시에서 들어오는 헤더에 쿠키 도메인을 적용하도록 세션 선호도를 구성할 수 있습니다. 세션 선호도 프록시를 true로 구성하면 세션 선호도가 쿠키 도메인을 X-Original-Host 찾거나 X-Forwarded-Host 이 헤더에 있는 도메인에 맞게 조정합니다. 세션 선호도 프록시를 사용하도록 설정할 때 권장되는 사례로 트래픽이 역방향 프록시에서 들어오도록 사이트에서 액세스 제한을 구성해야 합니다.

다음 명령을 사용하여 구성할 clientAffinityProxyEnabled 수도 있습니다.

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

다음 단계

App Service Environment에 대한 자세한 내용은 App Service Environment 설명서를 참조하세요.

웹앱을 더욱 안전하게 보호하려면 Azure Web Application Firewall 설명서에서 Application Gateway의 Azure Web Application Firewall에 대한 정보를 찾아보세요.

Azure Front Door 또는 Application Gateway를 사용하여 App Service에 사용자 지정 도메인이 포함된 안전하고 복원력 있는 사이트를 배포하려면 이 자습서를 참조하세요.