NGINX Plus로 Microsoft Azure App Service의 애플리케이션 보호

Cedric Derue

클라우드 컴퓨팅, 특히 서비스형 플랫폼(PaaS)과 서비스형 컨테이너(CaaS)의 부상으로 기업이 비즈니스 애플리케이션을 배포하고 운영하는 방식이 변화하고 있습니다. 클라우드 애플리케이션을 설계할 때 가장 중요한 과제 중 하나는 보안을 저해하지 않으면서 비용과 시간이 많이 드는 운영 작업을 줄여 주는 완전 관리형 클라우드 서비스를 선택하는 것입니다.

이 블로그 게시물에서는 Microsoft Azure App Service에서 애플리케이션을 호스팅하고 NGINX Plus로 보호하여 인터넷을 통한 공격을 방지하는 방법을 설명합니다.

Microsoft Azure App Service 간략히 살펴보기

Microsoft Azure App Service는 그림 1과 같이 조직이 기본 인프라를 관리하지 않고도 Microsoft Azure에 웹, API 및 모바일 앱을 배포할 수 있도록 지원하는 엔터프라이즈급 완전 관리형 플랫폼입니다. Azure App Service는 다음과 같은 주요 기능을 제공합니다:

• Web Apps를 사용하면 다양한 언어와 프레임워크(ASP.NET, Node.js, Java, PHP, Python)로 웹 앱을 배포하고 실행할 수 있습니다. 또한 포괄적인 애플리케이션 관리 기능(모니터링, 스테이징 환경에서 프로덕션 환경으로의 전환, 배포된 애플리케이션 삭제 등)을 갖춘 IIS(Internet Information Services)를 사용하여 확장 가능하고 안정적인 웹 애플리케이션을 관리할 수 있습니다. 컨테이너를 사용하여 Linux에서 웹 애플리케이션을 실행할 수 있는 Docker 런타임도 제공합니다.
• API Apps는 CORS(교차 출처 리소스 공유)를 지원하는 REST API 배포 도구를 제공합니다. 코드를 변경하지 않고도 Azure Active Directory, 소셜 네트워크 SSO(Single Sign-On) 또는 OAuth를 사용하여 Azure API Apps를 손쉽게 보호할 수 있습니다.
• Mobile Apps는 인증, 푸시 알림, 사용자 관리, 클라우드 스토리지 등의 필수 기능을 지원하는 모바일 백엔드 서비스를 빠르게 배포할 수 있도록 해줍니다.

Microsoft는 Azure App Service를 통해 클라우드에서 웹 애플리케이션을 실행할 수 있는 풍부한 기능과 빠른 방법을 제공합니다. 개발자는 ASP.NET, Java, Node.js, PHP, Python을 사용하여 로컬에서 애플리케이션을 개발한 후 Microsoft Visual Studio 또는 Azure CLI를 통해 Azure App Service에 손쉽게 배포할 수 있습니다. 또한 DevOps 팀은 Azure App Service의 지속적 배포 기능을 활용하여 여러 환경에 애플리케이션 릴리스를 빠르고 안정적으로 배포할 수 있습니다.

Azure App Service의 애플리케이션은 Azure에 배포된 다른 리소스에 액세스하거나 VPN을 통해 온-프레미스 기업 리소스에 연결할 수 있습니다.

Azure App Service Environment 이해하기

기본적으로 Azure App Service로 만든 애플리케이션은 인터넷에 직접 노출되며 azurewebsites.net의 하위 도메인이 할당됩니다. 보안을 강화하려면 SSL 종료나 OAuth2 또는 OpenID Connect(OIDC)와 같은 인증 및 권한 부여 프로토콜을 사용하여 앱을 보호할 수 있습니다. 하지만 세분화된 아웃바운드 및 인바운드 보안 규칙으로 네트워크를 사용자 지정하거나, 인터넷에서 유입되는 악의적인 공격이나 익스플로잇을 방지하기 위해 웹 애플리케이션 방화벽(WAF)과 같은 미들웨어를 적용할 수는 없습니다.

Azure App Service에서 민감한 애플리케이션을 실행하며 이를 보호하려는 경우 Azure App Service Environment(ASE)를 사용할 수 있습니다. ASE는 가상 네트워크에 배포되며 단일 고객의 애플리케이션 전용으로 제공되는 격리된 환경입니다. 따라서 애플리케이션의 인바운드 및 아웃바운드 네트워크 트래픽을 더욱 세밀하게 제어할 수 있습니다.

ASE를 사용하면 그림 2와 같이 웹, API, 모바일 또는 함수 앱을 더욱 안전한 환경에 대규모로 배포할 수 있습니다.

새 ASE v2 만들기

ASE에는 ASE v1과 ASE v2, 두 가지 버전이 있습니다. 이 게시물에서는 ASE v2를 다룹니다.

Azure Portal을 사용하여 새 ASE v2를 수동으로 만들거나 Azure Resource Manager를 사용하여 자동으로 만들 수 있습니다.

새 ASE를 만들 때는 다음 두 가지 배포 유형 중 하나를 선택해야 합니다:

• An 외부 ASE는 ASE에서 호스팅되는 애플리케이션을 공용 IP 주소를 통해 노출합니다.
• An ILB ASE는 ASE에서 호스팅되는 애플리케이션을 Azure Virtual Network 내부에서만 액세스할 수 있는 프라이빗 IP 주소를 통해 노출합니다. 내부 엔드포인트는 Azure에서 내부 부하 분산 장치(ILB)라고 부르는 것입니다.

다음 예제에서는 인터넷에서의 액세스를 차단하기 위해 ILB ASE를 선택합니다. 따라서 ASE에 배포된 애플리케이션은 동일한 네트워크에서 실행되는 VM(가상 머신)에서만 액세스할 수 있습니다. 다음 두 명령은 Azure Resource Manager와 Azure CLI를 사용하여 새 ILB ASE v2를 프로비저닝합니다.

$ azure config mode arm$ azure group deployment create my-resource-group my-deployment-name --template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

공개적으로 액세스 가능한 ASE에서 앱에 대한 액세스 보호

반면 앱을 인터넷에서 액세스할 수 있도록 하려면 애플리케이션에 저장된 민감한 정보를 탈취하려는 악의적인 공격자로부터 앱을 보호해야 합니다.

ASE에서 계층 7의 애플리케이션을 보호하는 방법은 크게 두 가지입니다:

• Azure Application Gateway
• NGINX Plus with the NGINX ModSecurity WAF 모듈이 포함된 NGINX Plus

(WAF 기능을 갖춘 사용자 지정 애플리케이션 전송 컨트롤러[ADC]로 대체할 수 있지만, 여기서는 해당 사용 사례를 다루지 않습니다.)

솔루션 선택은 보안 제약 조건에 따라 달라집니다. Azure Application Gateway는 보안 정책 적용을 위한 턴키 솔루션을 제공하며, 기본 인프라를 직접 유지 관리할 필요가 없습니다. 반면 VM에 NGINX Plus를 배포하면 보안 규칙을 세밀하게 조정할 수 있도록 더 뛰어난 제어 기능과 유연성을 갖춘 강력한 스택을 사용할 수 있습니다.

ASE 내에서 생성된 애플리케이션의 부하를 분산하고 보안을 유지하기 위해 Azure Application Gateway와 NGINX Plus 중 하나를 선택하려면 각 솔루션이 제공하는 기능을 충분히 이해해야 합니다. Azure Application Gateway는 단순한 사용 사례에는 적합하지만, 복잡한 사용 사례에서는 NGINX Plus가 기본으로 제공하는 여러 기능을 지원하지 않습니다.

다음 표에서는 Azure Application Gateway와 NGINX Plus의 부하 분산 및 보안 기능 지원 여부를 비교합니다. NGINX Plus 기능에 대한 자세한 내용은 표 아래에서 확인할 수 있습니다.

기능 Azure Application Gateway NGINX Plus완화 기능 애플리케이션 계층(계층 7) 애플리케이션 계층(계층 7)HTTP 인식 ✅ ✅HTTP/2 인식 ❌ ✅WebSocket 인식 ❌ ✅SSL 오프로딩 ✅ ✅라우팅 기능 요청 URL 또는 쿠키 기반 세션 선호도에 따른 단순 결정 고급 라우팅 기능IP 주소 기반 액세스 제어 목록 ❌(Azure의 웹앱 수준에서 정의해야 함) ✅엔드포인트 모든 Azure 내부 IP 주소, 공용 인터넷 IP 주소, Azure VM 또는 Azure Cloud Service 모든 Azure 내부 IP 주소, 공용 인터넷 IP 주소, Azure VM 또는 Azure Cloud ServiceAzure Vnet 지원 인터넷 연결 및 내부(Vnet) 애플리케이션 모두 인터넷 연결 및 내부(Vnet) 애플리케이션 모두WAF ✅ ✅대규모 트래픽 공격 부분 지원 부분 지원프로토콜 공격 부분 지원 부분 지원애플리케이션 계층 공격 ✅ ✅HTTP 기본 인증 ❌ ✅JWT 인증 ❌ ✅OpenID Connect SSO ❌ ✅

보시다시피 NGINX Plus와 Azure Application Gateway는 모두 레이어 7 부하 분산 기능과 WAF를 갖춘 ADC로 작동하여 일반적인 웹 취약점과 익스플로잇으로부터 강력한 보호를 제공합니다.

NGINX Plus는 Azure Application Gateway에는 없는 몇 가지 추가 기능을 제공합니다:

• URL 재작성 및 리디렉션 – NGINX Plus를 사용하면 요청을 백엔드 서버로 전달하기 전에 요청의 URL을 재작성할 수 있습니다. 즉, 클라이언트에 공개된 URL을 수정하지 않고도 파일 위치나 요청 경로를 변경할 수 있습니다. 요청을 리디렉션할 수도 있습니다. 예를 들어 모든 HTTP 요청을 HTTPS 서버로 리디렉션할 수 있습니다.
• 연결 및 속도 제한 – NGINX Plus 인스턴스에서 송수신되는 트래픽을 제어하기 위한 여러 제한을 구성할 수 있습니다. 여기에는 인바운드 연결 수, 인바운드 요청 속도, 백엔드 노드에 대한 연결 수, NGINX Plus에서 클라이언트로의 데이터 전송 속도에 대한 제한이 포함됩니다.
• HTTP/2 및 WebSocket 지원 – NGINX Plus는 애플리케이션 계층(계층 7)에서 HTTP/2 및 WebSocket을 지원합니다. Azure Application Gateway는 이를 지원하지 않으며, 대신 Azure Load Balancer가 TCP 및 UDP가 작동하는 네트워크 계층(계층 4)에서 이를 지원합니다.

보안을 더욱 강화하려면 Azure DDoS Protection을 배포하여 계층 3 및 4의 위협을 완화하고 Azure Application Gateway 또는 NGINX Plus에서 제공하는 계층 7 위협 완화 기능을 보완할 수 있습니다.

NGINX Plus와 Azure App Service를 사용하여 애플리케이션 보호

그림 3은 NGINX Plus와 Azure App Service를 결합하여 프로덕션 환경에서 비즈니스 애플리케이션을 안전하게 실행하는 방법을 보여줍니다. 이 배포 전략에서는 NGINX Plus의 부하 분산 및 WAF 기능을 활용합니다.

이 배포는 다음 구성 요소를 결합합니다:

• Azure Virtual Network(VNet) – 조직 전용 Azure 클라우드 가상 네트워크를 나타냅니다. Azure 리소스가 가상 네트워크 내에서 서로 안전하게 통신할 수 있도록 논리적 격리를 제공합니다. 여기서는 두 개의 서브넷을 정의했습니다. Internal은 인터넷에 직접 노출되지 않는 웹 애플리케이션용이고, Waf는 NGINX Plus 및 이를 지원하는 기반 인프라용입니다.
• Azure App Service Environment – 이 샘플 배포에서는 두 개의 샘플 웹 애플리케이션인 Web App 1과 Web App 2를 사용하여 NGINX Plus로 서로 다른 웹 앱을 보호하고 부하를 분산하는 방법을 보여 줍니다. NGINX Plus에서는 서로 다른 upstream 블록을 구성하여 요청을 여러 웹 애플리케이션에 분산하고, location 블록을 사용하여 URI를 기반으로 콘텐츠를 라우팅합니다. 다음은 이 목표를 달성하기 위한 최소한의 NGINX Plus 구성을 보여 줍니다(여기서는 모든 요청이 동일한 업스트림 그룹으로 전달됨).

upstream backend {    server IP-address-of-your-ASE-ILB;
}

server {
    location / {
        proxy_set_header Host $host;
        proxy_pass http://backend;
    }
}

• NGINX Plus – 여러 웹 애플리케이션에 걸쳐 HTTP(S) 연결의 부하를 분산합니다. VM에 NGINX Plus를 배포하면 다른 Azure 서비스보다 인프라를 더 세밀하게 제어할 수 있습니다. 예를 들어 VM을 사용하면 격리된 가상 네트워크 내에서 실행할 운영 체제(Linux 또는 Windows)를 선택할 수 있습니다. 실제로 Azure VM은 모든 Linux 배포판에서 사용할 수 있습니다. 단, 당연한 이유로 Amazon Linux는 제외됩니다.
• Azure VM 확장 집합 – VM 확장 집합은 동일한 VM 집합을 배포하고 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스입니다. VM의 크기를 구성하고 VM을 적절한 VNet에 할당할 수 있습니다. 확장 집합 내에서 실행되는 모든 VM은 VM 인스턴스 간 TCP 연결을 제공하는 Azure Load Balancer를 통해 부하가 분산됩니다. 여기서 확장 집합의 각 VM은 Azure Marketplace에서 제공되는 NGINX Plus 이미지를 기반으로 합니다. 확장 집합은 진정한 자동 크기 조정을 제공하도록 설계되었습니다.

Azure는 애플리케이션의 Azure 리소스를 논리적으로 손쉽게 그룹화할 수 있도록 리소스 그룹도 지원합니다. 리소스 그룹을 사용해도 인프라 설계와 토폴로지에는 영향을 미치지 않으므로 여기에서는 표시하지 않습니다.

Azure VM Scale Sets를 활용한 NGINX Plus 고가용성 및 자동 확장

Azure VM 확장 집합을 사용하면 확장을 지원하는 물리적 하드웨어를 직접 구매하고 유지 관리할 필요 없이 가상화의 이점을 누리면서 언제든지 규모를 확장하거나 축소할 수 있습니다. 하지만 구성, 패치 적용, 보안 업데이트, VM에서 실행되는 소프트웨어 설치 등의 작업을 수행하여 VM을 유지 관리하는 것은 여전히 사용자의 책임입니다.

그림 4에 표시된 아키텍처에서는 Azure VM 확장 집합 내에 NGINX Plus 인스턴스를 액티브-액티브 방식으로 배포하여 고가용성을 구현합니다. 액티브-액티브 구성에서는 모든 NGINX Plus VM이 Azure Load Balancer를 통해 라우팅되는 수신 요청을 처리할 수 있으므로 비용 효율적으로 용량을 확보할 수 있습니다.

Azure VM 확장 집합을 사용하면 평균 CPU 사용량을 기준으로 NGINX Plus 인스턴스의 자동 크기 조정을 손쉽게 설정할 수도 있습니다. 이 경우 NGINX Plus 구성 파일이 동기화되도록 주의해야 합니다. 이를 위해 NGINX Plus 관리 가이드에 설명된 NGINX Plus 구성 공유 기능을 사용할 수 있습니다.

요약

클라우드 애플리케이션에 Azure App Service를 사용하고 웹 앱, API 및 모바일 백엔드의 프런트엔드에 NGINX Plus를 배치하면 전 세계 규모로 이러한 애플리케이션의 부하를 분산하고 보안을 강화할 수 있습니다. NGINX Plus를 Azure App Service와 함께 사용하면 웹상의 취약점 악용 및 공격으로부터 높은 수준의 보호 기능을 제공하는 완전한 부하 분산 인프라를 구축할 수 있습니다. 이를 통해 중요한 애플리케이션을 프로덕션 환경에서 안전하게 실행할 수 있는 견고한 설계를 보장합니다.

리소스

Web Apps 개요 (Microsoft)
App Service Environment 소개 (Microsoft)
Azure Portal을 사용하여 웹 애플리케이션 방화벽이 포함된 애플리케이션 게이트웨이 만들기 (Microsoft)
NGINX Open Source와 NGINX Plus의 기능 비교 (NGINX)
HTTP 부하 분산 (NGINX)

게스트 공동 저자인 Cedric Derue는 Altran의 솔루션 아키텍트이자 Microsoft MVP입니다. 게스트 공동 저자인 Vincent Thavonekham은 VISEO의 Microsoft 지역 디렉터이자 Azure MVP입니다.

작성자 소개

Cedric Derue

Cedric Derue의 다른 블로그 게시물