AWS(Amazon Web Services) 웹 애플리케이션 워크로드를 Azure 배포 준비

이 문서에서는 Azure 플랫폼에서 웹 애플리케이션의 호스팅, 보호, 크기 조정 및 모니터링을 용이하게 하기 위해 강력하고 프로덕션이 가능한 인프라를 배포하는 방법에 대한 포괄적인 가이드를 제공합니다.

AWS에서 Yelb 배포

AWS의 Yelb 샘플 웹 애플리케이션은 Bash, AWS CLI, eksctl, kubectl 및 Helm을 사용하여 배포 됩니다. 도우미 sample에는 Yelb 애플리케이션의 배포를 자동화하는 데 사용할 수 있는 Bash 스크립트 및 YAML 매니페스트가 AWS EKS(Elastic Kubernetes Service) 포함되어 있습니다. 이 솔루션은 AWS WAF 를 사용하여 EKS(Amazon Elastic Kubernetes Service)에서 실행되는 웹 애플리케이션을 보호하는 웹 애플리케이션 방화벽을 구현하는 방법을 보여 줍니다. Bash 스크립트를 사용하여 EKS 클러스터를 만들고 Yelb 애플리케이션을 배포할 수 있습니다. Yelb 웹 애플리케이션은 ALB(ALB)Load Balancer 을 사용하여 공용 인터넷에 노출되고 AWS WAF 웹 액세스 제어 목록(웹 ACL)를 사용하여 보호됩니다. 자세한 지침은 AWS EKS(Elastic Kubernetes Service)에서 AKS(Azure Kubernetes Service) 웹 애플리케이션을 포팅하는 방법을 참조하세요.

Yelb 서비스 인터페이스의 스크린샷.

Azure 옐브 배포

다음 섹션에서는 Yelb 샘플 웹 애플리케이션을 AKS(Azure Kubernetes Service) 클러스터에 배포하고 NGINX 수신 컨트롤러 같은 수신 컨트롤러를 통해 노출하는 방법을 알아봅니다. 수신 컨트롤러 서비스는 AKS 클러스터가 있는 가상 네트워크 내의 트래픽을 분산하는 내부(또는 프라이빗) 부하 분산 장치를 통해 액세스할 수 있습니다. 하이브리드 시나리오에서는 온-프레미스 네트워크에서 부하 분산 장치 프런트 엔드에 액세스할 수 있습니다. 내부 부하 분산에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 참조하세요.

도우미 sample 애플리케이션 라우팅 추가 기능을 사용하여 관리되는 NGINX 수신 컨트롤러 설치를 지원합니다Helm 차트 사용하여 관리되지 않는 NGINX 수신 컨트롤러>. NGINX 수신 컨트롤러를 사용하는 애플리케이션 라우팅 추가 기능은 다음과 같은 기능을 제공합니다.

다른 구성의 경우

보안을 강화하기 위해 Yelb 애플리케이션은 Azure Application Gateway 리소스로 보호됩니다. 이 리소스는 AKS 클러스터와 동일한 가상 네트워크 내의 전용 서브넷 또는 피어된 가상 네트워크에 배포됩니다. WAF(Azure Web Application Firewall)는 AKS(Azure Kubernetes Service) 호스트되고 Azure Application Gateway 통해 일반 웹 애플리케이션에 대한 액세스를 보호합니다. 악용 및 취약성

사전 요구 사항

Architecture

이 샘플에서는 Bicep 템플릿, Bash 스크립트의 컬렉션을 제공합니다. 및 YAML 매니페스트는 AKS 클러스터를 빌드하고, Yelb 애플리케이션을 배포하고, NGINX 수신 컨트롤러를 사용하여 UI 서비스를 노출하고, Azure Application Gateway 및 AZURE WEB APPLICATION FIREWALL(WAF).

또한 이 샘플에는 별도의 Bicep 매개 변수 파일 2개와 Bash 스크립트 및 YAML 매니페스트 세트 2개가 포함되어 있으며, 각각 두 가지 솔루션 옵션을 배포하기 위한 것입니다. Bicep 대한 자세한 내용은 Bicep?

HTTP를 통한 Application Gateway 및 Yelb 호출에서 TLS 종료

이 솔루션에서 Azure Web Application Firewall(WAF) 악의적인 공격을 차단하여 시스템의 보안을 보장합니다. Azure Application Gateway 클라이언트 애플리케이션에서 들어오는 호출을 수신하고, TLS 종료를 수행하고, AKS 호스팅 yelb-ui 서비스에 요청을 전달합니다. 이 통신은 HTTP 전송 프로토콜을 사용하여 내부 부하 분산 장치 및 NGINX 수신 컨트롤러를 통해 수행됩니다. 다음 다이어그램에서는 아키텍처를 보여 줍니다.

HTTP를 통한 Application Gateway WAFv2 및 NGINX 수신 컨트롤러를 기반으로 하는 솔루션의 다이어그램입니다.

메시지 흐름은 다음과 같습니다.

HTTP를 통한 Application Gateway WAFv2 및 NGINX 수신 컨트롤러를 기반으로 하는 솔루션의 메시지 흐름 다이어그램.

  1. Azure Application Gateway TLS 종료를 처리하고 HTTP를 통해 AKS 호스팅 yelb-ui 서비스에 들어오는 호출을 보냅니다.
  2. Application Gateway 수신기는 Azure Key Vault에서 가져온 SSL 인증서를 사용하여 보안 통신을 보장합니다.
  3. 수신기와 연결된 Azure WAF 정책은 들어오는 요청에 OWASP 규칙 및 사용자 지정 규칙을 적용하여 여러 유형의 악의적인 공격을 효과적으로 방지합니다.
  4. Application Gateway 백 엔드 HTTP 설정은 포트 80을 사용하여 HTTP를 통해 Yelb 애플리케이션을 호출합니다.
  5. Application Gateway 백 엔드 풀 및 상태 프로브는 트래픽 관리를 위해 HTTP 프로토콜을 사용하여 AKS 내부 부하 분산 장치를 통해 NGINX 수신 컨트롤러 를 호출합니다.
  6. NGINX 수신 컨트롤러는 AKS 내부 부하 분산 장치를 사용하여 클러스터 내에서 보안 통신을 보장합니다.
  7. Kubernetes 수신 개체는 NGINX 수신 컨트롤러를 사용하여 내부 부하 분산 장치를 통해 HTTP를 통해 애플리케이션을 노출합니다.
  8. yelb-ui 형식이 있는 ClusterIP 서비스는 클러스터 내에서 또는 NGINX 수신 컨트롤러를 통해 호출을 제한합니다.

Azure Application Gateway 사용하여 엔드투엔드 TLS 구현

TLS 종료

Azure Application Gateway 게이트웨이 수준에서 TLS 종료를 지원합니다. 즉, 백 엔드 서버로 전송되기 전에 게이트웨이에서 트래픽의 암호가 해독됩니다. TLS 종료를 구성하려면 수신기에 TLS/SSL 인증서를 추가해야 합니다. 인증서는 개인 키와 공개 키를 모두 포함하는 PFX(개인 정보 Exchange) 형식이어야 합니다. Azure Key Vault Application Gateway로 인증서를 가져올 수 있습니다. 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

제로 트러스트 보안 모델

제로 트러스트 보안 모델을 채택하는 경우 Azure Application Gateway 같은 서비스 프록시와 백 엔드 서버 간의 암호화되지 않은 통신을 방지해야 합니다. 제로 트러스트 보안 모델을 사용하면 네트워크 내의 리소스에 액세스하려는 사용자 또는 디바이스에 트러스트가 자동으로 부여되지 않습니다. 대신 사용자의 위치 또는 네트워크에 관계없이 각 요청에 대한 ID 및 권한 부여를 지속적으로 확인해야 합니다. 이 시나리오에서 제로 트러스트 보안 모델을 구현하려면 들어오는 요청에 대한 프런트 엔드 역할을 하는 서비스 프록시로 Azure Application Gateway 사용해야 합니다. 그런 다음, 이러한 요청은 암호화된 형식으로 AKS(Azure Kubernetes Service) NGINX 수신 컨트롤러로 이동합니다.

Application Gateway를 사용하여 엔드투엔드 TLS

백 엔드 서버를 사용하여 엔드투엔드 TLS 암호화에 대한 Azure Application Gateway 구성하여 제로 트러스트 방법을 구현할 수 있습니다. 엔드투엔드 TLS 암호화 를 사용하면 쿠키 기반 세션 선호도, URL 기반 라우팅, 사이트 기반 라우팅 및 X-Forwarded-* 헤더를 다시 쓰거나 삽입하는 기능을 포함하여 Application Gateway의 계층 7 부하 분산 기능을 활용하여 중요한 데이터를 백 엔드로 안전하게 전송할 수 있습니다.

Application Gateway가 엔드투엔드 TLS 통신 모드로 구성된 경우 게이트웨이에서 TLS 세션을 종료하고 사용자 트래픽의 암호를 해독합니다. 그런 다음 구성된 규칙을 적용하여 트래픽을 라우팅할 적절한 백 엔드 풀 인스턴스를 선택합니다. 다음으로 Application Gateway는 백 엔드 서버에 대한 새 TLS 연결을 시작하고 백 엔드 서버에 요청을 전송하기 전에 백 엔드 서버의 공개 키 인증서를 사용하여 데이터를 다시 암호화합니다. 웹 서버의 응답은 최종 사용자에게 도달하기 전에 동일한 프로세스를 따릅니다. 엔드투엔드 TLS를 사용하도록 설정하려면 백 엔드 HTTP 설정의 프로토콜 설정을 HTTPS로 설정하고 백 엔드 풀에 적용해야 합니다. 이 방법을 사용하면 백 엔드 서버와의 통신이 보호되고 요구 사항을 준수할 수 있습니다.

자세한 내용은 Application Gateway 엔드투엔드 TLS 암호화 및 Application Gateway 보안 모범 사례를 참조하세요.

이 솔루션에서 Azure Web Application Firewall(WAF) 악의적인 공격을 차단하여 시스템의 보안을 보장합니다. Azure Application Gateway 클라이언트 애플리케이션에서 들어오는 호출을 처리하고, TLS 종료를 수행하고, 내부 부하 분산 장치 및 NGINX 수신 컨트롤러를 통해 HTTPS 전송 프로토콜을 사용하여 기본 AKS 호스팅 yelb-ui 서비스를 호출하여 엔드투엔드 TLS 구현합니다. 다음 다이어그램에서는 아키텍처를 보여 줍니다.

HTTPS를 통한 Application Gateway WAFv2 및 NGINX 수신 컨트롤러를 기반으로 하는 솔루션의 다이어그램.

메시지 흐름은 다음과 같습니다.

  1. Azure Application Gateway TLS 종료를 처리하고 HTTPS를 통해 백 엔드 애플리케이션과 통신합니다.
  2. Application Gateway 수신기는 Azure Key Vault에서 가져온 SSL 인증서를 사용합니다.
  3. 수신기와 연결된 Azure WAF 정책은 들어오는 요청에 대해 OWASP 규칙 및 사용자 지정 규칙을 실행하여 악의적인 공격을 차단합니다.
  4. Application Gateway 백 엔드 HTTP 설정은 포트 443에서 HTTPS를 통해 AKS 호스팅 yelb-ui 서비스를 호출하도록 구성됩니다.
  5. Application Gateway 백 엔드 풀 및 상태 프로브는 HTTPS를 사용하여 AKS 내부 부하 분산 장치를 통해 NGINX 수신 컨트롤러 를 호출합니다.
  6. NGINX 수신 컨트롤러는 AKS 내부 부하 분산 장치를 사용하도록 배포됩니다.
  7. SAKS 클러스터는 Azure Key Vault 공급자 for Secrets Store CSI Driver 추가 기능을 사용하여 CSI 볼륨 통해 Azure Key Vault 비밀, 인증서 및 키를 검색하도록 구성됩니다.
  8. SecretProviderClass는 Key Vault Application Gateway에서 사용하는 인증서를 검색하는 데 사용됩니다.
  9. Kubernetes 수신 개체는 NGINX 수신 컨트롤러를 사용하여 AKS 내부 부하 분산 장치를 통해 HTTPS를 통해 애플리케이션을 노출합니다.
  10. 서비스에는 yelb-uiClusterIP 클러스터 내 또는 NGINX 수신 컨트롤러를 통해 호출을 제한하는 형식이 있습니다.

시스템의 보안 및 안정성을 보장하려면 다음 권장 사항을 고려하세요.

  • 최적의 보안을 보장하기 위해 최신 규칙으로 Azure WAF 정책을 정기적으로 업데이트합니다.
  • 들어오는 요청 및 잠재적인 공격을 추적하고 분석하는 모니터링 및 로깅 메커니즘을 구현합니다.
  • AKS 클러스터, NGINX 수신 컨트롤러 및 Application Gateway의 유지 관리 및 업데이트를 정기적으로 수행하여 보안 취약성을 해결하고 보안 인프라를 유지 관리합니다.
  • 들어오는 요청 및 잠재적인 공격을 추적하고 분석하는 모니터링 및 로깅 메커니즘을 구현합니다.
  • AKS 클러스터, NGINX 수신 컨트롤러 및 Application Gateway의 유지 관리 및 업데이트를 정기적으로 수행하여 보안 취약성을 해결하고 보안 인프라를 유지 관리합니다.

호스트 이름

Application Gateway 수신기 및 Kubernetes 수신 은 동일한 호스트 이름을 사용하도록 구성됩니다. 다음과 같은 이유로 서비스 프록시 및 백 엔드 웹 애플리케이션에 동일한 호스트 이름을 사용하는 것이 중요합니다.

  • 세션 상태 유지: 프록시 및 백 엔드 애플리케이션에 다른 호스트 이름을 사용하면 세션 상태가 손실됩니다. 즉, 사용자 세션이 제대로 유지되지 않아 사용자 환경이 저하되고 데이터가 손실될 수 있습니다.
  • 인증 실패: 호스트 이름이 프록시와 백 엔드 애플리케이션 간에 다른 경우 인증 메커니즘이 실패할 수 있습니다. 이 방법을 사용하면 사용자가 애플리케이션 내에서 보안 리소스에 로그인하거나 액세스할 수 없게 될 수 있습니다.
  • 실수로 URL 노출: 호스트 이름이 유지되지 않으면 백 엔드 URL이 최종 사용자에게 노출될 위험이 있습니다. 이로 인해 잠재적인 보안 취약성과 중요한 정보에 대한 무단 액세스가 발생할 수 있습니다.
  • 쿠키 문제: 쿠키는 사용자 세션을 유지하고 클라이언트와 서버 간에 정보를 전달하는 데 중요한 역할을 합니다. 호스트 이름이 다르면 쿠키가 예상대로 작동하지 않아 인증 실패, 부적절한 세션 처리 및 잘못된 리디렉션과 같은 문제가 발생할 수 있습니다.
  • 엔드투엔드 TLS/SSL 요구 사항: 프록시와 백 엔드 서비스 간의 보안 통신에 엔드투엔드 TLS/SSL이 필요한 경우 원래 호스트 이름에 일치하는 TLS 인증서가 필요합니다. 동일한 호스트 이름을 사용하면 인증서 관리 프로세스가 간소화되고 보안 통신이 원활하게 설정됩니다.

서비스 프록시 및 백 엔드 웹 애플리케이션에 대해 동일한 호스트 이름을 사용하여 이러한 문제를 방지할 수 있습니다. 백 엔드 애플리케이션은 웹 브라우저와 동일한 도메인을 확인하여 세션 상태, 인증 및 URL 처리가 올바르게 작동하는지 확인합니다.

메시지 흐름

다음 다이어그램은 배포 및 런타임 시 메시지 흐름 단계를 보여줍니다.

HTTPS를 통한 Application Gateway WAFv2 및 NGINX 수신 컨트롤러를 기반으로 하는 솔루션의 메시지 흐름 다이어그램.

배포 워크플로

다음 단계에서는 배포 프로세스에 대해 설명합니다. 이 워크플로는 이전 다이어그램의 녹색 숫자에 해당합니다.

  1. 보안 엔지니어는 워크로드에서 사용하는 사용자 지정 도메인에 대한 인증서를 생성하고 Azure 키 자격 증명 모음에 저장합니다. 잘 알려진 CA(인증 기관)에서 유효한 인증서를 얻을 수 있습니다.
  2. 플랫폼 엔지니어는 main.bicepparams Bicep 매개 변수 파일에 필요한 정보를 지정하고 Bicep 템플릿을 배포하여 Azure 리소스를 만듭니다. 필요한 정보에는 다음이 포함됩니다.
    • Azure 리소스에 대한 접두사입니다.
    • 워크로드 호스트 이름 및 Application Gateway 수신기 사용자 지정 도메인에 대한 TLS 인증서를 보유하는 기존 Azure Key Vault 이름 및 리소스 그룹입니다.
  3. AKS 클러스터에 다음 패키지를 설치하도록 배포 스크립트 를 구성할 수 있습니다. 자세한 내용은 Bicep 모듈의 매개 변수 섹션을 확인하세요.
  4. Application Gateway 수신기는 Azure Key Vault TLS 인증서를 검색합니다.
  5. Kubernetes 수신 개체는 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자에서 가져온 인증서를 사용하여 HTTPS를 통해 Yelb UI 서비스를 노출합니다.
  6. Application Gateway 수신기는 Azure Key Vault에서 TLS 인증서를 검색합니다.
  7. Kubernetes 수신 개체는 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자로부터 가져온 인증서를 활용하여 HTTPS를 통해 Yelb UI 서비스를 노출합니다.

런타임 워크플로

  1. 클라이언트 애플리케이션은 호스트 이름을 사용하여 샘플 웹 애플리케이션을 호출합니다. Application Gateway 수신기의 사용자 지정 도메인과 연결된 DNS 영역은 A 레코드를 사용하여 Application Gateway의 프런트 엔드 IP 구성에서 사용하는 Azure 공용 IP의 주소로 DNS 쿼리를 확인합니다.
  2. 요청은 Application Gateway의 프런트 엔드 IP 구성에서 사용하는 Azure 공용 IP로 전송됩니다.
  3. Application Gateway는 다음 작업을 수행합니다.
    1. Application Gateway는 TLS 종료를 처리하고 HTTPS를 통해 백 엔드 애플리케이션과 통신합니다.
    2. Application Gateway 수신기는 Azure Key Vault에서 가져온 SSL 인증서를 사용합니다.
    3. 수신기에 연결된 Azure WAF 정책은 들어오는 요청에 대해 OWASP 규칙 및 사용자 지정 규칙을 실행하고 악의적인 공격을 차단합니다.
    4. Application Gateway 백 엔드 HTTP 설정은 포트 443에서 HTTPS를 통해 샘플 웹 애플리케이션을 호출하도록 구성됩니다.
  4. Application Gateway 백 엔드 풀은 HTTPS를 사용하여 AKS 내부 부하 분산 장치를 통해 NGINX 수신 컨트롤러를 호출합니다.
  5. 요청은 NGINX 수신 컨트롤러의 Pod를 호스트하는 에이전트 노드 중 하나로 전송됩니다.
  6. NGINX 수신 컨트롤러 복제본 중 하나는 요청을 처리하고 서비스의 서비스 엔드포인트 중 하나에 요청을 보냅니다 yelb-ui .
  7. yelb-ui 서비스를 호출합니다yelb-appserver.
  8. 및 yelb-appserver 서비스를 호출 yelb-dbyelb-cache 합니다.
  9. yelb-ui 서비스를 호출합니다yelb-appserver.
  10. 및 yelb-appserver 서비스를 호출 yelb-dbyelb-cache 합니다.

Deployment

기본적으로 Bicep 템플릿은 Azure CNI 오버레이 네트워크 플러그 인과 Cilium 데이터 평면을 사용하여 AKS 클러스터를 설치합니다. 대체 네트워크 플러그 인을 사용할 수 있습니다. 또한 프로젝트는 다음 확장 및 기능을 사용하여 AKS 클러스터를 배포하는 방법을 보여 줍니다.

프로덕션 환경에서는 가동 시간 SLA를 사용하여 프라이빗 AKS 클러스터를 배포하는 것이 좋습니다. 자세한 내용은 공용 DNS 주소가 있는 프라이빗 AKS 클러스터를 참조하세요.

또는 권한 있는 IP 주소 범위를 사용하여 공용 AKS 클러스터를 배포하고 API 서버에 대한 액세스를 보호할 수 있습니다. Bicep 템플릿을 사용하여 Azure 인프라를 배포하는 방법에 대한 자세한 내용과 지침은 companion Azure 코드 샘플 참조하세요.

프로덕션 환경에서는 가동 시간 SLA를 사용하여 프라이빗 AKS 클러스터를 배포하는 것이 좋습니다. 자세한 내용은 공용 DNS 주소가 있는 프라이빗 AKS 클러스터를 참조하세요. 또는 권한 있는 IP 주소 범위를 사용하여 공용 AKS 클러스터를 배포하고 API 서버에 대한 액세스를 보호할 수 있습니다. Bicep 템플릿을 사용하여 Azure 인프라를 배포하는 방법에 대한 자세한 내용과 지침은 companion Azure 코드 샘플 참조하세요.

다음 단계

AWS 웹 애플리케이션 워크로드를 Azure

기여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 원래 그것을 썼다:

대표 저자:

기타 기여자:

  • Last updated on