[특집 시리즈] Zero to Hero with App Service, 7부: 멀티 티어 웹 애플리케이션

Azure App Service는 멀티 테넌트 서비스와 앱 서비스 환경의 두 가지 배포 유형으로 제공된다. 멀티 테넌트 서비스에는 같은 인프라에 수천 명의 고객이 존재한다. 앱은 항상 보호되지만 네트워크, 주소 공간 및 기타 구성요소가 공유된다. 앱 서비스 환경에서는 Azure 가상 네트워크에서 실행되는 앱 서비스의 단일 테넌트 버전이 있다. 다음 두 글에서는 멀티 테넌트 앱 서비스에서 네트워크 보안을 구성하는 방법에 초점을 맞추고 있다.

 

 

 

멀티 티어 웹 애플리케이션

먼저 짚어보고 시작해야 할 분명한 질문은 멀티 티어 웹 애플리케이션이란 무엇인가? 멀티 티어 웹 애플리케이션은 그 뒤로 하나 이상의 API 애플리케이션을 호출하는 프런트 엔드가 있는 애플리케이션이다. 그 자체로는 복잡한 개념은 아니지만 사용자가 API 애플리케이션을 보호하여 인터넷에 액세스 할 수 없도록 하려는 경우 아키텍처가 더욱 복잡해진다.

프론트 엔드 애플리케이션에서만 접근할 수 있도록 API 애플리케이션을 보호하는 여러 가지 방법이 있다. 모두 API 애플리케이션의 인바운드 트래픽 보안을 포함한다. 이 목적으로 사용할 수 있는 여러 기능이 있다.

• 서비스 엔드포인트는 리스닝하는 서비스를 보호한다. 서비스 엔드포인트를 사용하는 경우 원본 주소는 Azure Virtual Network 서브넷에 있어야 한다.
• 프라이빗 엔드포인트는 데이터 유출을 방지하고 리스닝하는 서비스를 보호한다. 프라이빗 엔드포인트를 사용하면 프라이빗 엔드포인트 주소에 대한 네트워크 액세스 권한이 있는 모든 곳에서 웹 앱에 연결할 수 있다. 
• 액세스 제한은 주소 블록 집합에 대한 인바운드 트래픽을 잠글 수 있다.

각각의 특징들은 특정한 상황을 만족시키며 트레이드 오프가 있다. 액세스 제한은 NAT 장치와 같은 공용 주소 액세스 포인트 또는 전용 공용 주소를 가진 가상 네트워크 장치를 가지고 있는 경우 유용하다. 서비스 엔드포인트를 사용하는 경우, 구독에 새로운 리소스를 추가하지 않고 하나의 서브넷을 사용할 수 있다. 프라이빗 엔드포인트를 사용하면 새로운 최상위 리소스를 추가하고, VNet에 Azure DNS 프라이빗 영역을 추가하고 두 개의 서브넷이 필요하다. 이제 이 옵션들을 더 자세히 설명해보자.

 

 

 

서비스 엔드포인트

API 애플리케이션을 보호하기 위해 서비스 엔드포인트를 사용하여 멀티 티어 애플리케이션을 구성하려면 프런트 엔드 앱과 함께 VNet 통합을 사용하고 API 앱과 함께 서비스 엔드포인트를 사용해야 한다. 프런트 엔드 애플리케이션에서 사용하는 통합 서브넷에 서비스 엔드포인트를 설정한다. 이 솔루션은 설치가 빠르고 쉽다.

 

프런트 엔드 앱이 여러 개 있는 경우, 프런트 엔드 앱이 모두 동일한 앱 서비스 플랜에 있는 경우 구성이 동일하다. VNet 통합을 사용하면 동일한 앱 서비스 플랜의 앱이 동일한 통합 서브넷을 사용할 수 있다. 별도의 앱 서비스 플랜에 프런트 엔드 애플리케이션이 추가되어 있는 경우 여러 통합 서브넷을 사용해야 한다. 이 경우, 서비스 엔드포인트는 각 통합 서브넷에 대해 구성되어야 한다. VNet 통합을 사용하면 서브넷으로 구성된 앱 서비스 플랜을 둘 이상 가질 수 없다.

 

별도의 App Service 플랜에서 여러 API 앱과 여러 프런트 엔드 앱이 있는 경우 각 프런트 엔드 앱에서 VNet 통합을 구성한 다음 통합 서브넷에 대해 각 API 앱에서 서비스 엔드 포인트를 구성해야 한다.

 

프런트 엔드 애플리케이션을 추가할 때 각 종속 API 애플리케이션으로 서비스 엔드포인트를 구성해야 한다. 이는 서비스 엔드포인트가 규모가 작다는 것을 의미하다. 여러 API 애플리케이션을 사용하여 많은 또는 점점 더 많은 수의 프론트 엔드 애플리케이션을 보유하고 있는 경우 신속하게 통제할 수 없다. 구성을 관리하는 것은 프런트 엔드 수가 증가함에 따라 혼란스러울 수 있다.

 

 

 

프라이빗 엔드포인트

프라이빗 엔드포인트를 사용하면 구성이 더 쉽기도 하고 더 어려워도 진다. 앱용 VNet에 프라이빗 엔드포인트를 배치하면 API 앱에 대한 인바운드 트래픽을 관리하는 작업이 완료된다는 점에서 더 쉽다. 서비스 엔드포인트와 달리, 새로운 프런트 엔드 소비자를 추가할 때 API 앱에 추가 구성이 없다. 프라이빗 엔드포인트를 설정하는 것은 최상위 수준의 새로운 리소스와 Azure DNS 프아이빗 영역을 생성하기 때문에 더 어렵다.

하나 이상의 프런트 엔드 앱이 있는 경우 구성은 동일하다. API 앱에 프라이빗 엔드포인트가 있는 것과 동일한 VNet으로 VNet 통합을 설정한다. 또한 API 애플리케이션에 프라이빗 엔드포인트가 구성되어 있다.

 

둘 이상의 프런트 엔드 앱이 있는 경우 유일한 차이점은 이 두 번째 프런트 엔드 앱을 사용하여 구성하려면 VNet 통합이 필요하다는 것이다. 이 추가 프런트 엔드 애플리케이션이 다른 앱 서비스 플랜에 있는 경우 별도의 서브넷을 사용한다. 다른 앱 서비스 플랜에서 VNet 통합을 사용할 때마다 통합을 위해 다른 서브넷이 필요하다.

 

여러 API 애플리케이션이 있는 경우 여러 프라이빗 엔드포인트가 필요하다. 이러한 프라이빗 엔드포인트는 동일한 서브넷에 있을 수도 있고 아닐 수도 있다. 이 점에서 프라이빗 엔드포인트는 VNet 통합보다 더 유연하다.

API 애플리케이션이 프라이빗 엔드포인트로 노출되면 해당 VNet과 통합되는 모든 프런트 엔드 앱에 연결할 수 있어야 한다.

 

소규모에서는 프라이빗 엔드포인트가 더 많은 오버헤드를 발생시킨다. 서비스 엔드포인트보다 관리 및 유지 관리가 더 많이 필요하다. 반면에, 프라이빗 엔드포인트는 데이터 유출 우려에 대한 해결책이 된다. 또한 더 많은 프론트 엔드 애플리케이션을 추가하기 쉽기 때문에 규모면에서도 더 좋다.

 

 

 

액세스 통합

액세스 제한을 통해 IP 주소 블록 집합에 대한 인바운드 트래픽을 보호 할 수 있다. 이는 일련의 송신 장치에 대한 트래픽을 잠그려는 경우에 유용하다. Azure Front Door와 같은 다른 에지 보호 서비스와 함께 사용할 수도 있다. 멀티 티어 애플리케이션에서 직접 사용하는 것과 관련하여 API 애플리케이션을 프런트 엔드 애플리케이션에서 사용하는 송신 주소로 보호 할 수 있다. 이 접근 방식의 문제는 아웃바운드 주소가 동일한 확장 단위의 다른 모든 고객과 공유된다는 것이다. 보안 검토 관점에서 보면 서비스 엔드포인트나 프라이빗 엔드포인트 기반 솔루션만큼 안전하지 않다. 따라서 가능하고 주목할 가치가 있지만 액세스 제한을 사용하여 멀티 티어 웹 애플리케이션을 만드는 것은 권장되지 않는다.