This post is also available in: English (영어) 简体中文 (중국어 간체) 繁體中文 (중국어 번체) 日本語 (일어)
이 포스트는 안전한 액세스의 새로운 표준인 ZTNA 2.0의 5가지 원칙을 자세히 알아보기 위한 5부작 시리즈, "ZTNA 스트레이트 토크"의 1부입니다.
네트워크 및 디지털 트랜잭션의 모든 암시적 신뢰를 없앤다는 제로 트러스트의 개념은 오늘날 기업을 안전하게 보호하기 위한 최고의 접근 방식으로 널리 인정받고 있습니다. 그러나 최근 Nir Zuk가 지적한 바와 같이 기존 제로 트러스트 네트워크 액세스 솔루션은 기업에 리스크를 초래할 수 있는 5가지 불안한 결함을 가지고 있습니다.
1) 최소 권한 원칙을 위반합니다.
2) "허용하고 무시"합니다.
3) 보안 검사를 수행하지 않습니다.
4) 데이터를 보호하지 못합니다.
5) 엔터프라이즈 애플리케이션의 일부만을 보호합니다.
이 중 첫 번째 결함이자 오늘 다룰 주제인, 'ZTNA 1.0은 어떻게 최소 권한 원칙을 위반하는가'에 대해 살펴보겠습니다.
최소 권한의 원칙은 정보 보안 개념으로, 사용자나 기업에 업무를 수행하기 위한 최소한의 액세스 권한만 부여해야 한다는 의미입니다. 이것은 액세스를 최소한으로 제한해야 문제 발생 시 노출도 줄어든다는 생각에서 비롯되었습니다.
최소 권한은 제로 트러스트 태세의 근본이며, ZTNA 1.0 제공업체가 자체 솔루션에 "내장"된 기능이라 주장하기도 합니다. 그러나 ZTNA 1.0 아키텍처 결함은 이 개념을 제공하기 위한 기능에 큰 빈틈을 남깁니다.
ZTNA 1.0의 문제를 논하기 전에 먼저 원격 액세스 VPN에 관해 이야기해보아야 합니다. VPN은 기업 네트워크에 대한 원격 액세스를 제공하기 위해 오랫동안 사용되어 왔습니다. 전체 네트워크에 광범위한 액세스 권한을 부여하는 이 접근 방식은 결코 이상적이라 할 수 없지만 실질적인 대안이 없었을뿐더러 상대적으로 소수의 사용자만이 연결된 후 "신뢰받은" 상태에서 드물게 사용했기 때문에 허용할 수 있다고 판단했습니다. 그러나 하이브리드 업무로의 빠른 전환과 정교한 최신 위협(특히 내부망 이동을 포함한 공격)은 결국 기존 VPN을 무력하게 만들었습니다.
ZTNA는 전체 네트워크가 아닌, 필요한 특정 애플리케이션으로만 사용자의 액세스를 제한하여 VPN의 가장 큰 문제 중 하나를 해결하고자 했습니다. 하지만 공급업체에서 ZTNA 1.0 솔루션을 구현하는 방식은 기본적으로 IP(또는 FQDN) 및 포트 번호와 같은 레이어 3이나 레이어 4 네트워크 구조로 애플리케이션을 반영했습니다. 이러한 제한은 관리자가 액세스 제어 정책을 작성할 때 더욱 폭넓은 범위를 적용하도록 하여 결과적으로 의도한 것보다 훨씬 더 많은 액세스 권한을 부여하게 됩니다.
애플리케이션 구성 요소가 정적 IP 주소 및 포트 번호를 사용하는 레거시 애플리케이션의 경우 IP/포트를 사용하여 애플리케이션을 식별하는 접근 방식이 허용됩니다. 그러나 오늘날 거의 모든 엔터프라이즈에서는 다양한 기능을 제공하는 클라우드 네이티브 애플리케이션을 사용하며, 이들은 각각 개별 URL이나 유사한 고차원 개념을 통해 제공됩니다. 마찬가지로, 비즈니스 애플리케이션은 동적 IP 및 포트, 서버 개시 연결 및 IP와 포트만을 기반으로 한 정적 액세스 제어 정책 생성이 완전히 중단되는 기타 시나리오를 사용합니다.
앞서 설명한 바와 같이, 최소 권한의 원칙은 사용자가 업무를 수행하기 위해 가능한 최소한의 권한만 제공하는 것입니다. SaaS 그리고 동적 IP 및 포트를 사용하는 기타 최신 앱에 대해서도 ZTNA 1.0 솔루션은 액세스 제어(및 애플리케이션)를 위한 광범위한 IP 및 포트 범위의 액세스를 허용하도록 하며 이는 업무에서도 마찬가지입니다. 이것은 네트워크에 공격자나 멀웨어가 익스플로잇할 수 있는 큰 허점을 남기며 최소 권한 원칙을 명백히 위반하는 것입니다.
ZTNA 2.0을 통해 시스템은 앱이 어떤 IP와 포트를 사용하든 상관없이 App-ID를 사용하여 모든 프로토콜과 포트를 통해 앱 내에서 애플리케이션과 특정 기능을 동적으로 식별할 수 있습니다. 이를 통해 관리자는 네트워크 구조를 생각할 필요가 없으며, 세분화된 액세스 제어를 지원하여 결국 진정한 최소 권한 액세스를 구현할 수 있습니다.
ZTNA 1.0 솔루션과 잘 맞지 않는 새로운 유형의 앱은 서버에서 클라이언트로 연결을 설정해야 합니다. 여기에는 업데이트 및 패치 관리 솔루션, 디바이스 관리 앱 및 지원 센터 앱과 같은 미션 크리티컬 애플리케이션이 포함됩니다. 많은 공급업체에서 ZTNA 1.0을 구현한 방식은 사용자가 이러한 연결을 시작한 경우에만 작동하며, 앱 또는 서버 개시 연결은 전혀 허용하지 않습니다. 우리는 고객이 ZTNA 1.0 솔루션을 구현하려고 했지만 이 사용 사례를 해결하기 위해 기존 VPN 솔루션을 유지해야 했던 수많은 사례를 접했습니다!
애플리케이션 액세스 정책을 정의하는 App-ID를 사용하여 양방향 액세스 제어를 허용하는 Prisma Access와 같은 ZTNA 2.0 솔루션은 서버 개시 연결을 사용하는 앱을 포함한 모든 유형의 앱에 대해 최소 권한 액세스를 쉽게 적용할 수 있습니다.
많은 프라이빗 애플리케이션은 대부분의 최신 SaaS 앱에 존재하는 세분화된 내장 액세스 제어 기능이 부족합니다. 사용자가 애플리케이션에 액세스하여 데이터를 볼 수 있지만 데이터를 업로드하거나 다운로드할 수는 없는 것과 같은 간단한 기능은 IP 주소 및 포트 번호만으로 앱을 식별하는 ZTNA 1.0 솔루션에서는 불가능합니다. 하위 앱 수준에서 이와 같은 세분화된 제어 수준을 제공하는 것(즉, 앱에 대한 액세스를 지정하지만 업로드/다운로드는 제한함)은 App-ID 구조를 활용하여 앱 및 하위 앱을 식별하는 ZTNA 2.0 솔루션의 경우에는 그리 어려운 일이 아닙니다.
애플리케이션과 사용자가 어디에나 존재하는 환경에서 최소 권한 원칙을 수용하는 것은 제로 트러스트를 효과적으로 도입하고 기업의 리스크를 줄이는 데 매우 중요합니다. 설명한 바와 같이, ZTNA 2.0은 IP 주소 및 포트 번호 같은 네트워크 구조와 관계없이 모든 유형의 애플리케이션에 대한 정밀한 액세스 제어가 가능합니다. 이것은 안전한 액세스를 위한, 궁극적으로는 레거시, 원격 액세스 VPN으로부터 벗어날 수 있기 위한 중요한 도약입니다.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.