클라우드 컴퓨팅의 등장, 특히 PaaS(Platform as a Service)와 CaaS(Container as a Service) 서비스의 등장은 기업이 비즈니스 애플리케이션을 배포하고 운영하는 방식을 변화시키고 있습니다. 클라우드 애플리케이션을 설계할 때 가장 중요한 과제 중 하나는 보안을 손상시키지 않으면서 비용과 시간이 많이 소요되는 운영 작업을 줄여주는 완전 관리형 클라우드 서비스를 선택하는 것입니다.
이 블로그 게시물에서는 Microsoft Azure App Service 에서 애플리케이션을 호스팅하고 NGINX Plus 로 보안을 유지하여 인터넷 공격을 차단하는 방법을 보여줍니다.
Microsoft Azure App Service는 조직이 그림 1에서 볼 수 있듯이 기본 인프라를 관리하지 않고도 Microsoft Azure에서 웹, API 및 모바일 앱을 배포할 수 있는 엔터프라이즈급 완전 관리형 플랫폼입니다. Azure App Service는 다음과 같은 주요 기능을 제공합니다.
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로 만든 애플리케이션은 인터넷에 직접 노출되고 azurewebsites.net 의 하위 도메인에 할당됩니다. 보안을 강화하려면 SSL 종료나 OAuth2 또는 OpenID Connect(OIDC)와 같은 인증 및 권한 부여 프로토콜을 사용하여 앱을 보호할 수 있습니다. 그러나 세분화된 아웃바운드 및 인바운드 보안 규칙으로 네트워크를 사용자 지정하거나 웹 애플리케이션 방화벽(WAF)과 같은 미들웨어를 적용하여 인터넷에서 발생하는 악의적인 공격이나 악용을 방지하는 것은 불가능합니다.
Azure App Service에서 중요한 애플리케이션을 실행하고 이를 보호하려면 Azure App Service Environment(ASE)를 사용할 수 있습니다. ASE는 가상 네트워크에 배포되고 단일 고객의 애플리케이션에 전담되는 격리된 환경입니다. 따라서 인바운드 및 아웃바운드 애플리케이션 네트워크 트래픽을 더욱 효과적으로 제어할 수 있습니다.
그림 2에서 볼 수 있듯이 ASE를 사용하면 훨씬 더 안전한 환경에서 웹, API, 모바일 또는 기능 앱을 매우 큰 규모로 배포할 수 있습니다.
ASE에는 두 가지 버전이 있습니다. ASE v1과 ASE v2. 이 게시물에서는 ASE v2에 대해 설명합니다.
Azure Portal을 사용하여 새 ASE v2를 수동으로 만들거나 Azure Resource Manager를 사용하여 자동으로 만들 수 있습니다.
새 ASE를 만들 때는 두 가지 배포 유형 중에서 선택해야 합니다.
다음 예에서는 인터넷 접근을 차단하기 위해 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에서 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에서 누락된 여러 추가 기능을 제공합니다.
추가 보안을 위해 Azure DDoS Protection을 배포하여 3계층과 4계층 의 위협을 완화할 수 있으며, Azure Application Gateway 또는 NGINX Plus에서 제공하는 7계층 위협 완화 기능을 보완할 수 있습니다.
그림 3은 NGINX Plus와 Azure App Service를 결합하여 프로덕션에서 비즈니스 애플리케이션을 실행하기 위한 안전한 환경을 제공하는 방법을 보여줍니다. 이 배포 전략은 부하 분산 및 WAF 기능을 위해 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; } }
Azure는 또한 논리적인 방식으로 애플리케이션의 Azure 리소스를 그룹화하는 쉬운 방법으로 리소스 그룹을 지원합니다. 리소스 그룹을 사용해도 인프라 설계와 토폴로지에 영향을 미치지 않으므로, 여기서는 표시하지 않습니다.
Azure VM 확장 집합을 사용하면 확장을 지원하는 실제 하드웨어를 구매하고 유지 관리하지 않고도 언제든지 확장할 수 있는 가상화 기능을 사용할 수 있습니다. 그러나 구성, 패치, 보안 업데이트, VM에서 실행되는 소프트웨어 설치 등의 작업을 수행하여 VM을 유지 관리하는 일은 여전히 사용자의 책임입니다.
그림 4에 표시된 아키텍처에서 NGINX Plus 인스턴스는 Azure VM 확장 집합 내에서 활성-활성 고가용성을 위해 배포됩니다. 액티브-액티브 설정은 모든 NGINX Plus VM이 Azure Load Balancer에서 라우팅된 수신 요청을 처리할 수 있으므로 비용 효율적인 용량을 제공하므로 매우 유용합니다.
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 콘텐츠로 리디렉션됩니다."