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

아티클
03/11/2024

Azure App Service의 세 가지 변형에는 Azure Application Gateway와의 통합에 대해 약간 다른 구성이 필요합니다. 변형에는 일반 App Service(다중 테넌트라고도 함), ILB(내부 부하 분산 장치) App Service Environment 및 외부 App Service Environment가 포함됩니다.

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

App Service와의 통합(다중 테넌트)

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

Diagram that shows the internet flowing to an application gateway in an Azure virtual network and then flowing through a firewall icon to instances of apps in App Service.

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

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

Azure Portal을 사용하여 서비스 설정

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

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

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

Screenshot shows the text of Error 403 - Forbidden.

Azure Resource Manager 템플릿을 사용하여 서비스 설정

Azure Resource Manager 배포 템플릿은 전체 시나리오를 만듭니다. 이 시나리오는 서비스 엔드포인트로 잠긴 App Service 인스턴스와 Application Gateway에서만 트래픽을 수신하기 위한 액세스 제한으로 구성됩니다. 템플릿에는 리소스 이름에 추가된 많은 스마트 기본값과 고유한 접미사가 포함되어 있어 단순하게 유지됩니다. 이를 재정의하려면 리포지토리를 복제하거나 템플릿을 다운로드하여 편집해야 합니다.

템플릿을 적용하려면 템플릿 설명에 있는 Azure에 배포 단추를 사용합니다. 또는 적절한 PowerShell 또는 Azure CLI 코드를 사용할 수 있습니다.

Azure CLI를 사용하여 서비스 설정

Azure CLI 샘플은 서비스 엔드포인트로 잠겨 있고 Application Gateway에서만 트래픽을 수신하도록 액세스를 제한하는 App Service 인스턴스를 만듭니다. 기존 애플리케이션 게이트웨이에서 기존 App Service 인스턴스에 대한 트래픽만 격리해야 하는 경우 다음 명령을 사용합니다.

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

기본 구성에서 이 명령은 서브넷의 서비스 엔드포인트 구성 설정과 App Service의 액세스 제한을 보장합니다.

프라이빗 엔드포인트 사용 시 고려 사항

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

Diagram that shows traffic flowing to an application gateway in an Azure virtual network and then flowing through a private endpoint to instances of apps in App Service.

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

ILB App Service Environment에 대한 고려 사항

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

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

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

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

외부 App Service Environment에는 다중 테넌트 App Service와 같은 공용 연결 부하 분산 장치가 있습니다. App Service Environment에서는 서비스 엔드포인트가 작동하지 않습니다. 그렇기 때문에 애플리케이션 게이트웨이의 공용 IP 주소를 사용하여 IP 기반 액세스 제한을 사용해야 합니다. Azure Portal을 사용하여 외부 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"
        }
    }
    ...
}

ARR 선호도

다중 인스턴스 배포에서 ARR 선호도는 클라이언트 요청이 세션 수명 동안 동일한 인스턴스로 라우팅되도록 보장합니다. ARR 선호도는 호스트 이름 재정의와 함께 작동하지 않습니다. 세션 선호도가 작동하려면 App Service와 Application Gateway에서 동일한 사용자 지정 도메인과 인증서를 구성하고 호스트 이름을 재정의하지 않아야 합니다.

다음 단계

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

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

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

다음을 통해 공유