편집

다음을 통해 공유

안전한 관리형 웹 애플리케이션

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Azure 웹 애플리케이션 방화벽

이 문서에서는 App Service Environment를 사용하여 보안 애플리케이션을 배포하는 방법의 개요를 제공합니다. 인터넷에서의 애플리케이션 액세스를 제한하는 데는 Azure Application Gateway 서비스 및 Azure Web Application Firewall이 사용됩니다. 또한 이 문서에서는 Azure DevOps를 사용하여 App Service Environment의 CI/CD(연속 통합 및 지속적인 배포)에 대한 지침을 제공합니다.

이 시나리오는 일반적으로 고객이 애플리케이션 수준 보안 외에 플랫폼 수준 보안을 인식하는 금융 및 보험과 같은 업계에 배포됩니다. 이러한 개념을 설명하기 위해 사용자가 경비 보고서를 제출할 수 있는 애플리케이션을 사용합니다.

잠재적인 사용 사례

이 시나리오에 적합한 사용 사례는 다음과 같습니다.

  • 추가 보안이 필요한 Azure 웹앱 빌드
  • 공유 테넌트 App Service 요금제가 아닌 전용 테넌시 제공
  • 내부적으로 부하가 분산된(ILB) Application Service Environment와 함께 Azure DevOps를 사용합니다.

아키텍처

보안 ILB App Service Environment 배포에 대한 샘플 시나리오 아키텍처를 특징으로 하는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

데이터 흐름

  1. HTTP/HTTPS 요청은 먼저 애플리케이션 게이트웨이에 도달합니다.
  2. 필요에 따라(다이어그램에 표시되지 않음) Web App에 대해 Microsoft Entra 인증을 사용하도록 설정할 수 있습니다. 트래픽이 애플리케이션 게이트웨이에 처음 도달하면 사용자에게 애플리케이션 인증을 위한 자격 증명을 제공하라는 메시지가 표시됩니다.
  3. 사용자 요청은 환경의 ILB(내부 부하 분산 장치)를 통해 전달되며, 그러면 트래픽이 Expenses Web App으로 라우팅됩니다.
  4. 그런 다음, 사용자는 경비 보고서를 만들기 위해 진행합니다.
  5. 경비 보고서를 만드는 과정의 일환으로 배포된 API 앱이 호출되어 사용자의 관리자 이름과 메일을 검색합니다.
  6. 만들어진 경비 보고서는 Azure SQL Database에 저장됩니다.
  7. 지속적인 배포를 용이하게 하기 위해 코드가 Azure DevOps 인스턴스에 체크 인됩니다.
  8. 빌드 VM에는 Azure DevOps 에이전트가 설치되어 있으므로 빌드 VM이 App Service Environment에 배포할 웹앱의 비트를 풀(pull)할 수 있습니다(빌드 VM은 같은 가상 네트워크 내의 서브넷에 배포되므로).

구성 요소

  • App Service Environment는 대규모 애플리케이션을 안전하게 실행하기 위해 완전히 격리된 전용 환경을 제공합니다. 또한 App Service Environment와 이 환경에서 실행되는 워크로드는 가상 네트워크 뒤에 있으므로 추가 보안 및 격리 레이어도 제공합니다. 대규모 및 격리에 대한 요구 사항으로 인해 ILB App Service Environment가 선택되었습니다.
  • 이 워크로드는 격리된 App Service 가격 책정 계층을 사용하므로 애플리케이션은 더 빠른 프로세서, SSD(반도체 드라이브) 스토리지를 사용하여 Azure 데이터 센터의 프라이빗 전용 환경에서 실행되고 표준과 비교했을 때 메모리 대 코어 비율이 두 배가 됩니다.
  • Azure App Service Web App 및 API 앱은 웹 애플리케이션과 RESTful API를 호스트합니다. 이 앱과 API는 격리된 서비스 플랜에서 호스트되며, 자동 스케일링, 사용자 지정 도메인 등을 전용 계층에서 제공합니다.
  • Azure Application Gateway는 웹 애플리케이션에 대한 트래픽을 관리하는 계층 7에서 작동하는 웹 트래픽 부하 분산 장치입니다. SSL 오프로딩을 제공하여 웹앱을 호스트하는 웹 서버가 트래픽 암호를 다시 해독하는 추가 오버헤드를 제거합니다.
  • Web Application Firewall는 Application Gateway의 기능입니다. 응용 프로그램 게이트웨이에서 웹 응용 프로그램 방화벽을 사용하도록 설정하면 보안이 더욱 강화됩니다. 웹 애플리케이션 방화벽은 OWASP(Open Worldwide Application Security Project) 규칙을 사용하여 교차 사이트 스크립팅, 세션 하이재킹 및 SQL 삽입과 같은 공격으로부터 웹 애플리케이션을 보호합니다.
  • Azure SQL Database는 이 애플리케이션의 데이터 대부분이 관계형 데이터이고 일부 데이터는 문서와 Blob으로 되어 있어 선택되었습니다.
  • Azure 네트워킹은 Azure의 다양한 네트워킹 기능을 제공하며, 네트워크는 Azure의 다른 가상 네트워크와 피어링될 수 있습니다. ExpressRoute 또는 사이트 간을 통해 온-프레미스 데이터 센터와 연결을 설정할 수 있습니다. 이 경우 가상 네트워크에서 서비스 엔드포인트가 사용하도록 설정되어 데이터가 Azure 가상 네트워크와 SQL Database 인스턴스 간에만 흐르도록 합니다.
  • Azure DevOps는 Agile 개발을 지원하는 기능을 사용하여 스프린트 중에 팀이 협업하는 데 도움을 주고 빌드 및 릴리스 파이프라인을 생성하는 데 사용됩니다.
  • 설치된 에이전트가 각 빌드를 풀하고 웹앱을 환경에 배포할 수 있도록 Azure 빌드 VM이 생성되었습니다.

대안

App Service Environment는 Windows에서 일반 웹앱을 실행하거나, 이 예제에서처럼 환경 내에 배포된 웹앱은 각각 Linux 컨테이너로 실행됩니다. 이러한 단일 인스턴스 컨테이너화된 애플리케이션을 호스트하도록 App Service Environment가 선택되었습니다. 사용 가능한 대안이 있습니다. 솔루션을 디자인할 때 아래 고려 사항을 검토하세요.

  • Azure Service Fabric: 사용자 환경이 주로 Windows 기반이고 워크로드가 주로 .NET Framework 기반이며 아직 .NET Core로 아키텍처 변경을 고려하고 있지 않은 경우 Service Fabric을 사용하여 Windows Server 컨테이너를 지원하고 배포합니다. 또한 Service Fabric은 C# 또는 Java 프로그래밍 API를 지원하고 네이티브 마이크로 서비스 개발의 경우 Windows 또는 Linux에서 클러스터를 프로비저닝할 수 있습니다.
  • AKS(Azure Kubernetes Service)는 오픈 소스 프로젝트이며 일반적으로 마이크로 서비스 기반 아키텍처를 사용하는 복잡한 다중 컨테이너 애플리케이션을 호스트하는 데 더 적합한 오케스트레이션 플랫폼입니다. AKS는 Kubernetes 클러스터 프로비저닝 및 구성의 복잡성을 추상화하는 관리형 Azure 서비스입니다. 그러나 Kubernetes 플랫폼을 지원하고 유지 관리하는 데는 상당한 관련 지식이 필요하므로 소수의 단일 인스턴스 컨테이너화된 웹 애플리케이션을 호스트하는 것은 가장 적합한 옵션이 아닐 수 있습니다.

데이터 계층에 대한 다른 옵션은 다음과 같습니다.

  • Azure Cosmos DB: 대부분의 데이터가 비관계형 형식인 경우 Azure Cosmos DB가 좋은 대안이 됩니다. 이 서비스는 MongoDB, Cassandra, Graph 데이터 또는 간단한 Table Storage와 같은 다른 데이터 모델을 실행하는 플랫폼을 제공합니다.

고려 사항

ILB App Service Environment에서 인증서를 처리할 경우 특정 고려 사항이 있습니다. 인증서가 최종적으로 저장될 서버에서 생성된 인증서 서명 요청을 요구하지 않고 신뢰할 수 있는 루트에 연결된 인증서를 생성한다는 점입니다. 예를 들어 IIS(인터넷 정보 서비스)를 사용하는 경우 첫 번째 단계는 IIS 서버에서 인증서 서명 요청(CSR)을 생성한 후 SSL 인증서 발급 기관으로 보내는 것입니다.

App Service Environment의 ILB(내부 부하 분산 장치)에서 CSR을 발급할 수 없습니다. 이 제한을 처리하는 방법은 와일드카드 프로시저를 사용하는 것입니다.

와일드카드 프로시저에서는 CSR 대신 DNS 이름 소유권 증명을 사용할 수 있습니다. DNS 네임스페이스를 소유하는 경우 특수 DNS TXT 레코드에 넣을 수 있으며 와일드카드 프로시저는 레코드가 거기에 있는지 확인하고, 있는 경우 사용자에게 올바른 레코드가 있으므로 사용자가 DNS 서버를 소유하고 있음을 알 수 있습니다. 해당 정보에 따라 신뢰할 수 있는 루트에 등록된 인증서가 발급됩니다. 그러면 사용자가 해당 인증서를 ILB에 업로드할 수 있습니다. ILB에 신뢰할 수 있는 루트 SSL 인증서가 있으므로 웹앱의 개별 인증서 저장소를 사용하여 아무 작업도 수행할 필요가 없습니다.

ILB App Service Environment에서 실행되는 서비스 간에 보안 호출을 수행하려는 경우 자체 서명되거나 내부적으로 발급된 SSL 인증서가 작동하도록 합니다. ILB App Service Environment가 내부적으로 발급된 SSL 인증서에서 작동하도록 하는 방법과 신뢰할 수 있는 루트 저장소에 내부 CA를 로드하는 방법에 대해 고려할 또 다른 솔루션이 있습니다.

App Service Environment를 프로비저닝하는 동안 App Service Environment의 도메인 이름을 선택할 때 다음과 같은 제한 사항을 고려합니다. 도메인 이름은 다음일 수 없습니다.

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

또한 앱에 사용되는 사용자 지정 도메인 이름과 ILB App Service Environment에서 사용되는 도메인 이름은 겹칠 수 없습니다. contoso.com이라는 도메인 이름의 ILB App Service Environment의 경우 앱에 다음과 비슷한 사용자 지정 도메인 이름을 사용할 수 없습니다.

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

사용자 지정 도메인 이름과 충돌하지 않는 ILB App Service Environment의 도메인을 선택합니다. 이 예제에서는 .contoso.com으로 끝나는 사용자 지정 도메인 이름과 충돌하지 않는 contoso-internal.com과 같은 이름을 환경의 도메인에 사용할 수 있습니다.

고려해야 할 또 다른 사항은 DNS입니다. App Service Environment 내의 애플리케이션이 서로 통신할 수 있도록 하려면(예: 웹 애플리케이션이 API와 통신하는 경우) 환경이 있는 가상 네트워크에 대해 DNS를 구성해야 합니다. 사용자 고유의 DNS를 지정하거나 Azure DNS 프라이빗 영역을 사용할 수 있습니다.

가용성

확장성

보안

복원력

시나리오 배포

이 시나리오를 배포하려면 이 단계별 자습서에 따라 각 구성 요소를 수동으로 배포하는 방법을 시연합니다. 자습서를 따르는 경우 v2 대신 App Service Environment v3를 선택합니다. 이 자습서에서는 간단한 Contoso 경비 보고 애플리케이션을 실행하는 .NET 샘플 애플리케이션도 제공합니다.

가격 책정

이 시나리오를 실행하는 데 드는 비용을 살펴보세요. 모든 서비스는 비용 계산기에 미리 구성되어 있습니다. 특정 사용 사례에 대한 가격 변동을 확인하려면 필요한 트래픽에 맞게 변수를 적절하게 변경합니다.

가져오는 데 필요한 트래픽 양을 기준으로 다음 세 가지 샘플 비용 프로필을 제공했습니다.

  • 소형: 이 가격 책정 예제는 매월 수천 명의 사용자에게 서비스를 제공하는 최소 프로덕션 수준 인스턴스에 필요한 구성 요소를 나타냅니다. 앱에서 자동 크기 조정을 사용하는 데 충분한 표준 웹앱의 단일 인스턴스를 사용합니다. 다른 각 구성 요소는 비용을 최소화하지만, SLA(서비스 수준 약정)를 지원하고 프로덕션 수준 워크로드를 처리할 수 있을 만큼 충분한 용량을 보장하는 기본 계층으로 스케일링됩니다.
  • 중형: 이 가격 책정 예제는 보통 크기의 배포에 필요한 구성 요소를 나타냅니다. 여기서는 한 달 동안 사용자가 약 10만 명이라고 예상합니다. 보통의 표준 계층이 있는 단일 App Service 인스턴스에서 필요한 트래픽이 처리됩니다. 또한 인지 및 검색 서비스의 중간 계층이 계산기에 추가됩니다.
  • 대형: 이 가격 책정 예제는 매월 테라바이트 단위의 데이터를 이동하는 수백만 명의 사용자가 주문하는 수준의 대규모 애플리케이션을 나타냅니다. 이 고성능 사용 수준에서는 여러 지역에 배포되어 Traffic Manager에서 제어되는 프리미엄 계층 웹앱이 필요합니다. 데이터는 스토리지, 데이터베이스, CDN 등으로 구성되며 이러한 구성 요소는 테라바이트 단위의 데이터를 처리하도록 구성됩니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

  • Faisal Mustafa | 선임 고객 엔지니어

다음 단계