블로그 | NGINX

NGINX Plus를 사용하여 Microsoft Azure App Service에서 애플리케이션 보안

NGINX-F5-수평-검정-유형-RGB의 일부
세드릭 데루 썸네일
세드릭 데루
2018년 10월 3일 게시

클라우드 컴퓨팅의 등장, 특히 PaaS(Platform as a Service)와 CaaS(Container as a Service) 서비스의 등장은 기업이 비즈니스 애플리케이션을 배포하고 운영하는 방식을 변화시키고 있습니다. 클라우드 애플리케이션을 설계할 때 가장 중요한 과제 중 하나는 보안을 손상시키지 않으면서 비용과 시간이 많이 소요되는 운영 작업을 줄여주는 완전 관리형 클라우드 서비스를 선택하는 것입니다.

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

Microsoft Azure App Service에 대한 간략한 개요

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

  • 웹 앱을 사용하면 다양한 언어와 프레임워크(ASP.NET, Node.js, Java, PHP, Python)로 웹 앱을 배포하고 실행할 수 있습니다. 또한 포괄적인 애플리케이션 관리 기능(모니터링, 스테이징에서 프로덕션으로의 전환, 배포된 애플리케이션 삭제 등)을 갖춘 인터넷 정보 서비스(IIS)를 사용하여 확장 가능하고 안정적인 웹 애플리케이션을 관리합니다. 또한 컨테이너를 사용하여 Linux에서 웹 애플리케이션을 실행하기 위한 Docker 런타임을 제공합니다.
  • API 앱은 CORS(Cross‑Origin Resource Sharing)를 지원하는 REST API를 배포하기 위한 도구를 제공합니다. Azure API 앱은 코드 변경 없이 Azure Active Directory, 소셜 네트워크 Single Sign‑On(SSO) 또는 OAuth를 통해 쉽게 보안할 수 있습니다.
  • 모바일 앱은 인증, 푸시 알림, 사용자 관리, 클라우드 스토리지 등과 같은 필수 기능을 지원하는 모바일 백엔드 서비스를 빠르게 배포하는 방법을 제공합니다.
그림 1: 애저 앱 서비스

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 환경 이해

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

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

그림 2에서 볼 수 있듯이 ASE를 사용하면 훨씬 더 안전한 환경에서 웹, API, 모바일 또는 기능 앱을 매우 큰 규모로 배포할 수 있습니다.

그림 2: Azure ASE에 대한 트래픽을 필터링하는 NGINX ModSecurity WAF

새로운 ASE v2 생성

ASE에는 두 가지 버전이 있습니다. ASE v1과 ASE v2. 이 게시물에서는 ASE v2에 대해 설명합니다.

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

새 ASE를 만들 때는 두 가지 배포 유형 중에서 선택해야 합니다.

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

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

$ azure config mode arm $ azure group 배포 생성 내 리소스 그룹 내 배포 이름 --템플릿 URI https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

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

반면, 앱을 인터넷에서 접속할 수 있게 하려면, 앱에 저장된 중요 정보를 훔치려는 악의적인 공격자로부터 앱을 보호해야 합니다.

ASE에서 7계층에서 애플리케이션을 보호하려면 두 가지 주요 선택 사항이 있습니다.

(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 애플리케이션 게이트웨이 NGINX 플러스
완화 능력 응용 프로그램 계층(Layer 7) 응용 프로그램 계층(Layer 7)
HTTP 인식
HTTP/2 인식
WebSocket 인식
SSL 오프로딩
라우팅 기능 요청 URL 또는 쿠키 기반 세션 친화성에 따른 간단한 결정 고급 라우팅 기능
IP 주소 기반 액세스 제어 목록 ❌ (Azure의 웹앱 수준에서 정의되어야 함)
엔드포인트 모든 Azure 내부 IP 주소, 공용 인터넷 IP 주소, Azure VM 또는 Azure Cloud Service 모든 Azure 내부 IP 주소, 공용 인터넷 IP 주소, Azure VM 또는 Azure Cloud Service
Azure Vnet 지원 인터넷 연결 및 내부(Vnet) 애플리케이션 모두 인터넷 연결 및 내부(Vnet) 애플리케이션 모두
와프
체적 공격 부분적 부분적
프로토콜 공격 부분적 부분적
애플리케이션 계층 공격
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/2WebSocket을 지원합니다. Azure Application Gateway는 그렇지 않습니다. 대신 Azure Load Balancer는 TCP와 UDP가 작동하는 네트워크 계층(4계층)에서 이를 지원합니다.

추가 보안을 위해 Azure DDoS Protection을 배포하여 3계층과 4계층 의 위협을 완화할 수 있으며, Azure Application Gateway 또는 NGINX Plus에서 제공하는 7계층 위협 완화 기능을 보완할 수 있습니다.

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

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

그림 3: NGINX Plus는 Azure ASE의 애플리케이션에 대한 트래픽 부하를 분산합니다.

배포에는 다음 구성 요소가 결합됩니다.

  • Azure Virtual Network(VNet) – 귀하의 조직에 전용된 Azure 클라우드의 가상 네트워크를 나타냅니다. Azure 리소스가 가상 네트워크에서 서로 안전하게 통신할 수 있도록 하는 논리적 격리를 제공합니다. 여기서는 두 개의 서브넷을 정의했습니다. 내부 인터넷에 직접 노출되지 않는 웹 애플리케이션의 경우 와프 NGINX Plus와 이를 기반으로 하는 인프라에 대해 알아보세요.
  • Azure App Service 환경 – 이 샘플 배포는 두 개의 샘플 웹 애플리케이션( 웹 앱 1웹 앱 2 )을 활용하여 NGINX Plus를 사용하여 다양한 웹 앱을 보호하고 부하를 분산하는 방법을 보여줍니다. NGINX Plus에서는 별도의 업스트림 블록을 구성하여 다양한 웹 애플리케이션에 대한 요청을 분산시키고, 위치 블록을 사용하여 URI를 기반으로 콘텐츠 라우팅을 수행합니다. 다음은 이 목표를 충족하는 최소 NGINX Plus 구성을 보여줍니다(여기서는 모든 요청이 동일한 업스트림 그룹으로 이동함):

    업스트림 백엔드 { 서버 IP 주소-ASE-ILB ; } 서버 { 위치 / { proxy_set_header 호스트 $host; proxy_pass http://backend; } }
    
  • NGINX Plus – 여러 웹 애플리케이션에서 HTTP(S) 연결의 부하를 분산합니다. VM에 NGINX Plus를 배포하면 다른 Azure 서비스보다 인프라를 더 효과적으로 제어할 수 있습니다. 예를 들어, VM을 사용하면 격리된 가상 네트워크 내부에서 실행되는 운영 체제(Linux 또는 Windows)를 선택할 수 있습니다. 실제로 Azure VM은 NGINX Plus가 지원하는 모든 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에 표시된 아키텍처에서 NGINX Plus 인스턴스는 Azure VM 확장 집합 내에서 활성-활성 고가용성을 위해 배포됩니다. 액티브-액티브 설정은 모든 NGINX Plus VM이 Azure Load Balancer에서 라우팅된 수신 요청을 처리할 수 있으므로 비용 효율적인 용량을 제공하므로 매우 유용합니다.

그림 4: Azure Load Balancer를 사용하여 NGINX Plus로 트래픽 부하 분산하는 Azure VM 확장 세트

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

요약

클라우드 애플리케이션에 Azure App Service를 사용하고 웹 앱, API, 모바일 백엔드 앞에 NGINX Plus를 사용하면 글로벌 규모로 이러한 애플리케이션의 부하를 분산하고 보안을 유지할 수 있습니다. Azure App Service와 함께 NGINX Plus를 사용하면 웹에서의 악용 및 공격으로부터 높은 수준의 보호 기능을 갖춘 완벽한 부하 분산 인프라를 구축할 수 있습니다. 이를 통해 안전한 방식으로 프로덕션 환경에서 중요한 애플리케이션을 실행할 수 있는 견고한 설계가 보장됩니다.

 

리소스

웹 앱 개요 (Microsoft)
App Service 환경 소개 (Microsoft)
Azure Portal(Microsoft)을 사용하여 웹 애플리케이션 방화벽이 있는 애플리케이션 게이트웨이 만들기
NGINX Open Source와 NGINX Plus(NGINX)의 기능을 비교해보세요
HTTP 부하 분산 (NGINX)

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


"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."