오늘날의 ZTNA는 다양한 애플리케이션에 충분하지 않습니다.

인증 및 권한 부여는 다양한 색상으로 제공됩니다.

SASE의 제로 트러스트 네트워크 액세스(ZTNA) 구성 요소는 엔터프라이즈 비공개 애플리케이션에 대한 안전한 인바운드 액세스를 제공하도록 설계되었습니다. 제로 트러스트 아키텍처(ZTA)의 ID 기반 액세스 제어의 핵심 원칙에 따라 ZTNA는 사용자를 인증하고 엔터프라이즈 애플리케이션에 대한 모든 인바운드 세션에서 사용자 유형, 그룹 및 역할에 따라 액세스 제어를 적용하는 데 중요한 역할을 합니다. ZTNA 보안은 다음과 같은 시나리오에서 상당한 이점을 제공합니다:

• 레거시 애플리케이션: 기본 제공 보안 조치가 없는 레거시 애플리케이션은 보안 문제로 인해 WFA(어디서나 작업 가능) 사용자에게 노출되지 않는 경우가 많습니다. 이러한 레거시 애플리케이션의 프론트엔드에 ZTNA를 활용하면 인증서 관리, OIDC와 같은 프로토콜을 사용한 인증, 상황 인식 액세스 제어에 기반한 권한 부여를 통해 HTTPS 종료를 제공할 수 있습니다. 이를 통해 WFA 사용자는 인터넷을 통해 레거시 애플리케이션에 안전하게 액세스할 수 있습니다.
• 손상된 애플리케이션: 보안을 염두에 두고 개발되었음에도 불구하고 일부 애플리케이션은 오랜 기간 동안 업데이트되지 않았을 수 있습니다. 이러한 애플리케이션은 새 인증서 업로드 또는 자동 갱신을 지원하지 않거나 오래되어 적절한 인증서 관리가 부족할 수 있습니다. ZTNA는 이러한 손상된 애플리케이션의 보안을 대체하여 보안 한계를 극복하면서 안전한 액세스를 보장합니다.
• 새로운 애플리케이션 아키텍처: 최신 엔터프라이즈 애플리케이션은 보안 고려 사항을 ZTNA 및 서비스 메시 기술과 같은 외부 엔터티로 전환하여 설계되는 경우가 많습니다. 이 접근 방식은 보안이 프런트엔드 엔터티로 오프로드되므로 애플리케이션 개발자가 HTTPS, 인증 및 권한 부여를 처리해야 하는 부담을 덜어줍니다. 보안 관리를 중앙 집중화하면 일관된 보안 정책 적용, 애플리케이션 개발 생산성 향상, 유지 관리 간소화 등의 이점을 얻을 수 있습니다. 또한 보안 업데이트가 외부에서 처리되므로 보안 문제를 해결하기 위한 패치 릴리스 빈도를 크게 줄일 수 있습니다.

오늘날 많은 ZTNA 솔루션은 단순한 엔터프라이즈 애플리케이션의 프런트엔드에는 적합하지만, SaaS 애플리케이션과 같은 멀티테넌트 애플리케이션에 대한 인증 및 권한 부여는 제공하지 못합니다. SaaS 애플리케이션에서 ZTNA의 역할: 서비스형 소프트웨어(SaaS) 애플리케이션의 맥락에서 ZTNA는 인증 및 권한 부여 메커니즘을 강화하고 개선하는 데 중요한 역할을 할 것으로 생각합니다. SaaS 애플리케이션에는 멀티테넌시, DoS/DDoS 공격에 대한 복원력, 인증 우회 및 권한 상승 공격에 대한 강력한 보호 등 특정 요구 사항이 있습니다. 이 문서에서는 SaaS 애플리케이션의 인증 및 권한 부여 프로세스의 부하를 덜어주거나 개선하는 데 도움이 되는 차세대 ZTNA의 기능에 대해 자세히 설명합니다. 이 문서에서는 WAAP(웹 애플리케이션 및 API 보호), HTTPS 종료, 다양한 애플리케이션 인스턴스로 들어오는 세션의 트래픽 관리, SSH/RDP/VNC 서비스의 웹화, 포트 스캐너에서 애플리케이션을 보이지 않게 하는 등 ZTNA의 다른 기능에 대해서는 다루지 않는다는 점에 유의하세요. 주로 ZTNA의 인증 및 권한 부여 측면에 중점을 두고 있습니다. SaaS의 맥락에서 CASB(클라우드 액세스 보안 브로커)와 ZTNA의 역할이 혼동될 수 있다는 점에 유의하세요. SASE의 CASB 구성 요소는 기업이 사용하는 SaaS 서비스에 대한 연결을 보호하는 데 중점을 두며, 기업은 SaaS 및 CASB 서비스의 소비자입니다. 반면, SaaS의 맥락에서 ZTNA는 SaaS 애플리케이션 자체를 보호하도록 설계되어 SaaS 회사가 ZTNA 서비스의 소비자가 됩니다. 이러한 차별화는 SASE 솔루션에서 CASB와 ZTNA의 뚜렷한 역할과 책임을 이해하는 데 필수적입니다. ID 브로커에 대한 이전 글에서 브로커를 SASE 솔루션에 통합하면 얻을 수 있는 다양한 이점에 대해 살펴보았습니다. 논의된 장점은 주로 설계의 모듈성과 단순성, 궁극적으로 SASE 솔루션의 복원력 향상에 관한 것이었습니다. 이 문서에서는 복잡한 애플리케이션을 지원하는 데 있어 ID 브로커의 중추적인 역할, 특히 SaaS 애플리케이션에 중점을 두고 살펴봅니다.

멀티테넌트 애플리케이션의 어려움은 무엇인가요?

SASE의 ZTNA는 정책 기반 인증에 대한 강력한 지원을 제공하는 데 탁월합니다. SASE 내의 권한 부여 엔진은 여러 정책 테이블을 관리할 수 있는 기능을 제공하며, 각 테이블에는 여러 정책이 포함되어 있습니다. 각 정책은 여러 규칙으로 구성되며 일치 성공 시 취해야 할 조치를 지정합니다. 규칙 자체는 다양한 매칭 속성을 포함하며, 소스 및 대상 속성으로 분류할 수 있습니다. 대상 속성은 주로 URI 및 해당 리소스와 상호 작용하는 데 사용되는 메서드(예: GET, PUT, POST, DELETE)와 같이 액세스하는 애플리케이션의 리소스와 관련이 있습니다. 반면에 소스 속성은 일반적으로 리소스에 액세스하는 주체와 연관됩니다. 이러한 속성에는 이름, 그룹, 역할, 사용자 자격 증명을 검증한 인증 서비스 및 기타 사용자 클레임과 같은 사용자 관련 속성이 포함됩니다. 여기에는 주체가 사용하는 디바이스의 보안 상태와 사용자가 리소스에 액세스하는 디바이스의 위치를 캡처하는 디바이스 컨텍스트 속성도 포함됩니다. 그러나 많은 ZTNA 솔루션은 포괄적인 인증 시나리오를 처리하는 데 있어 부족하며, 종종 비(非)SaaS 애플리케이션으로 기능을 제한하는 경우가 많습니다. SASE/SSE 솔루션에 ID 브로커를 포함시킨 것은 모든 유형의 애플리케이션에서 포괄적인 인증을 달성하기 위한 진일보한 단계입니다. SaaS 공급업체가 애플리케이션 내에서 인증 및 권한 부여를 처리할 수 있는 역량을 보유하고 있다고 주장할 수도 있지만, 환경은 크게 변화했습니다. 오늘날의 애자일 환경에서 SaaS 제공업체는 보안 책임을 SASE와 같은 외부 기관에 오프로드하는 것의 이점을 점점 더 많이 인식하고 있습니다. 이를 통해 생산성이 향상되고 전반적인 보안 태세에 대한 자신감이 높아지는 이점을 누릴 수 있습니다. 또한 이러한 접근 방식을 통해 신규 SaaS 제공업체는 인증 및 권한 부여를 외부 기관에 맡기고 핵심 비즈니스 로직에 집중할 수 있으므로 시장에 더 신속하게 진입할 수 있습니다. SASE 솔루션은 이러한 새로운 SaaS 제공업체를 지원하는 데 중추적인 역할을 할 수 있습니다. 저희는 SASE 솔루션이 SaaS 애플리케이션과 같은 복잡한 애플리케이션을 대신하여 인증 및 권한 부여 보안을 제공해야 하는 이 과제를 해결할 준비가 되어 있어야 하고, 또 그렇게 될 것이라고 믿습니다. 다음 시나리오에서는 SaaS 애플리케이션의 한 가지 대표적인 예를 제시하고, ID 브로커를 통합하여 SASE가 애플리케이션의 인증 및 권한 위임에 어떻게 도움이 될 수 있는지 살펴봅니다. 여러 API 리소스로 구성된 이 예제 SaaS 애플리케이션(app.example.com에서 호스팅됨) 시나리오를 살펴보세요:

이 시나리오에서는 SaaS 공급업체의 IDP가 example-idp라고 가정해 보겠습니다. 두 개의 테넌트가 있습니다: XYZ와 ABC이며, 각각의 IDP 서비스는 XYZ-idp와 ABC-idp입니다. 또한 각 테넌트에는 각각 자체 IDP 서비스를 제공하는 두 개의 파트너가 있습니다. XYZ-P1-idp 및 XYZ-P2-idp는 XYZ 파트너의 IDP 서비스입니다. ABC-P1-idp 및 ABC-P2-idp는 ABC 파트너의 IDP 서비스입니다. 또한 XYZ 테넌트는 공용 API 공간에 액세스하기 위해 Google 및 Facebook을 통한 인증이 필요한 반면, ABC 테넌트는 LinkedIn 및 GitHub를 통한 인증을 선호합니다. 위의 시나리오를 해결하려면 ZTNA에서 다음과 같은 권한 부여 정책이 필요합니다:

1. 도메인 = app.example.com; 사용자 역할 = app-admin; authservice = example-idp; uri = /service-admin-api/* ALLOW: example-idp 서비스에 성공적으로 로그인하고 도메인이 app.example.com인 애플리케이션의 admin-api 아래에 있는 모든 리소스에 대한 app-admin 역할을 가진 모든 사용자의 액세스를 허용합니다.
2. 도메인 = app.example.com; 사용자 그룹 = admin-group; 인증 서비스 = XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* ALLOW: 모든 리소스에 대한 관리자 그룹 역할을 가진 XYZ-idp 서비스에 성공적으로 로그인한 모든 사용자에 대한 액세스를 허용합니다(XYZ/tenant-admin-api 아래).
3. 도메인 = app.example.com; 사용자-역할 = admin-역할; 인증 서비스 = ABC-idp; uri = /tenants/ABC/tenant-admin-api/* ALLOW: ABC-idp 서비스로 인증된 관리자 역할이 있는 모든 사용자가 ABC/tenant-admin-api 리소스에 액세스할 수 있도록 허용합니다.
4. 도메인 = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: XYZ-idp 서비스로 성공적으로 인증된 모든 사용자에 대해 규칙에 지정된 리소스에 대한 액세스를 허용합니다.
5. 도메인 = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ABC-idp 서비스로 성공적으로 인증된 모든 사용자에 대해 규칙에 지정된 리소스에 대한 액세스를 허용합니다.
6. 도메인 = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: XYZ-P1-idp 서비스로 인증된 사용자에게 XYZ 협업 공간에 대한 액세스를 허용합니다.
7. 도메인 = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* ALLOW: XYZ-P2-idp 서비스로 인증된 사용자에게 XYZ 협업 공간에 대한 액세스를 허용합니다.
8. 도메인 = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ABC-P1-idp 서비스로 인증된 사용자에게 ABC 협업 공간에 대한 액세스를 허용합니다.
9. 도메인 = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* ALLOW: ABC-P2-idp 서비스로 인증된 사용자에게 ABC 협업 공간에 대한 액세스를 허용합니다.
10. 도메인 = app.example.com; authservice = google.com; uri = /tenants/XYZ/public-api/* ALLOW: google.com으로 인증된 모든 사용자에게 XYZ 공개 API 공간에 대한 액세스를 허용합니다.
11. 도메인 = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* ALLOW: facebook.com으로 인증된 모든 사용자에게 XYZ 공개 API 공간에 대한 액세스를 허용합니다.
12. 도메인 = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* ALLOW: linkedin.com으로 인증된 모든 사용자에게 ABC 공개 API 공간에 대한 액세스를 허용합니다.
13. 도메인 = app.example.com; authservice = github.com; uri = /tenants/ABC/public-api/* ALLOW: github.com으로 인증된 모든 사용자에게 XYZ 퍼블릭 API 공간에 대한 액세스를 허용합니다.
14. 도메인 = app.example.com; 거부: 위의 규칙이 일치하지 않는 경우 애플리케이션에 대한 액세스를 거부합니다.

SASE 솔루션은 속성 기반 액세스 제어에 탁월합니다. 즉, 인증 기능을 잘 처리한다는 의미입니다. 하지만 인증에 있어서는 그다지 포괄적이지 않습니다. 위의 정책에서는 사용자가 인증하기로 선택한 IDP(ID 공급자) 서비스에 따라 서로 다른 수준의 액세스 권한이 부여됩니다. 또한 일부 사용자는 잠재적인 데이터 유출 실수를 피하기 위해 의도적으로 특정 IDP 서비스로 인증하여 최소한의 권한으로 리소스에 액세스하려고 할 수도 있습니다.

ID 브로커의 역할

이러한 시나리오를 해결하려면 ID 브로커의 통합 기능이 필요합니다. ID 브로커는 SASE/SSE 프록시 구성 요소에 대한 OIDC(OpenID Connect) 공급자 역할을 하는 동시에 업스트림 ID 서비스(인증 서비스)에 대한 OIDC/SAML/LDAP 클라이언트 역할을 합니다. 오픈 소스 IAM 시스템인 Keycloak은 많은 사람들에게 인기 있는 선택입니다. ID 브로커의 역할을 수행하도록 구성할 수 있으며 일반적으로 SASE 서비스 제공업체 및 서비스 메시 제품 공급업체에서 사용합니다. 따라서 여기에서는 키클로크 용어를 사용합니다. Keycloak은 멀티테넌트 SaaS 애플리케이션을 비롯한 다양한 유형의 애플리케이션에 대한 인증을 유연하게 처리할 수 있습니다. 멀티테넌트 SaaS 애플리케이션에 대한 인증은 다음과 같은 방식으로 ‘ID 브로커’를 사용하여 수행할 수 있습니다: 인증 흐름이 수정된 각 SaaS 애플리케이션에 대해 하나의 클라이언트가 있는 하나의 영역: URL 경로 또는 HTTP 요청 헤더에서 애플리케이션 테넌트를 식별할 수 없는 경우, SASE 프록시 구성 요소는 ID 브로커와 통신할 OIDC 클라이언트를 하나만 가질 수 있습니다. 사용자 인증 중에 ID 브로커는 사용자를 인증할 IDP 서비스를 알아야 합니다. Keycloak은 브라우저 흐름과 같은 표준 인증 흐름을 제공하며 사용자 지정 흐름을 생성하고 Keycloak 클라이언트와 연결할 수 있습니다. SASE는 사용자에게 테넌트 정보를 제공하라는 메시지가 표시되는 인증 플로우를 생성하여 이 기능을 활용합니다. 이 정보를 기반으로 인증 흐름은 사용자가 선택할 수 있는 사용 가능한 ID 공급자를 표시할 수 있습니다. 이 정보를 통해 브로커는 사용자를 적절한 ID 서비스로 리디렉션할 수 있습니다. 각 SaaS 애플리케이션에 대해 여러 클라이언트가 있는 하나의 영역: URL 또는 HTTP 요청 헤더에서 애플리케이션 테넌트를 식별할 수 있는 경우, 각 애플리케이션 테넌트에 대해 하나의 클라이언트를 사용하도록 SASE 프록시 구성 요소를 구성할 수 있습니다. 이 경우, 다양한 ID 공급자 집합을 사용하는 표준 브라우저 플로우를 사용하여 Keycloak의 해당 클라이언트 엔티티와 연결할 수 있습니다. 이 방법의 장점은 사용자에게 테넌트 이름을 입력하라는 메시지가 표시되지 않으므로 사용자 환경이 개선된다는 것입니다. 요약하면, 이러한 전략은 멀티테넌트 SaaS 애플리케이션에 대한 인증을 효과적으로 처리할 수 있도록 SASE 솔루션의 역량을 강화하여 ID 브로커로서 Keycloak의 기능을 활용합니다.

정책 기반 OIDC 클라이언트 선택

키클로크 브로커는 여러 영역과 각 영역 내 여러 클라이언트를 지원합니다. 표준 인증 플로우, 사용자 지정 인증 플로우 생성, 이러한 플로우를 클라이언트와 연결할 수 있습니다. 키클로크 브로커 기능을 사용하면 사용자 측 인증 메커니즘과 백엔드(업스트림) 인증 서비스 간의 인증 세션을 중개할 수도 있습니다. 키클로크가 사용자에게 애플리케이션 테넌트를 식별하고 인증을 위한 ID 서비스를 선택하라는 메시지를 표시하는 방법에 대해서는 이전에 설명한 바 있습니다. 이러한 기능은 멀티테넌트 애플리케이션을 비롯한 다양한 고객 애플리케이션을 위한 OIDC 클라이언트(OIDC 릴레이라고도 함) 역할을 하는 SASE 프록시에서도 활용해야 합니다. SASE 프록시는 여러 OIDC 클라이언트를 지원해야 합니다. 한 가지 접근 방식은 각 고객에 대해 일련의 OIDC 클라이언트를 보유하여 고객별 인증 관련 구성이 다른 고객과 격리되도록 하는 것입니다. 일반적으로 각 SASE 고객의 OIDC 세트는 Keycloak의 영역과 연결됩니다. SASE 프록시 고객이 각각 고유한 도메인 이름을 가진 여러 애플리케이션을 보유하고 있는 시나리오에서는 여러 애플리케이션 관리자 간에 격리 기능을 제공해야 합니다. 이러한 경우 각 애플리케이션에 하나의 클라이언트를 할당하여 OIDC 클라이언트의 하위 집합을 구성해야 합니다. 많은 애플리케이션의 경우 단일 테넌트 애플리케이션이거나 앞서 설명한 것처럼 트래픽에서 테넌트를 식별할 수 없는 경우 단일 OIDC 클라이언트로 충분합니다. 그러나 테넌트를 식별할 수 있는 경우 각 애플리케이션 테넌트에 대해 하나의 OIDC 클라이언트를 구성할 수 있습니다. 여러 개의 OIDC 클라이언트가 필요하기 때문에 SASE 프록시는 적절한 OIDC 클라이언트를 선택할 수 있는 메커니즘을 제공해야 합니다. 바로 이 지점에서 정책 기반 OIDC 선택이 중요해집니다. 여러 정책이 포함된 정책 테이블이 사용되며, 각 정책은 해당 OIDC 클라이언트 레코드를 가리킵니다. 트래픽 흐름 중에 SASE 프록시는 OIDC 인증이 필요한지 여부를 확인한 다음 고객, 애플리케이션 도메인 이름, 애플리케이션 테넌트를 표의 정책과 일치시킵니다. 일치하는 항목이 발견되면 해당 OIDC 클라이언트 레코드가 브로커와 통신하는 데 사용됩니다. 일부 구현에서는 정책 매칭 프로세스를 신속하게 처리하기 위해 각 고객 전용 테이블이 하나씩 있는 여러 개의 정책 테이블을 사용할 수 있습니다.

멀티테넌트 애플리케이션에 적응하는 NextGen ZTNA

SASE(보안 접속 서비스 엣지) 솔루션 내의 ZTNA(제로 트러스트 네트워크 접속)는 애플리케이션 보안에 중요한 역할을 합니다. 애플리케이션에서 인증 및 권한 부여 작업을 오프로드할 수 있으므로 개발자는 핵심 비즈니스 로직에 집중할 수 있습니다. 이 접근 방식은 생산성을 향상하고 전반적인 보안을 강화합니다. 모든 개발자가 보안에 대한 전문 지식을 갖춘 것은 아니기 때문에 인증 우회 및 권한 상승 취약점은 애플리케이션에서 흔히 발생합니다. 보안을 오프로드하면 이러한 취약점을 제거하여 애플리케이션 복원력을 강화할 수 있습니다. SASE와 같이 보안을 중앙 집중화하면 모든 애플리케이션에 대해 단일 인터페이스만 관리하면 되므로 보안 관리자의 업무가 간소화됩니다. 보안과 유연성을 모두 달성하기 위해 SASE 솔루션의 차세대 ZTNA는 다양한 애플리케이션 유형을 처리해야 합니다. 기존의 많은 ZTNA 솔루션은 멀티테넌트 애플리케이션을 효과적으로 지원하는 데 어려움을 겪는 경우가 많습니다. 향후 개선 사항에는 다양한 애플리케이션 시나리오를 충족하기 위해 ID 브로커 기능과 정책 기반 OIDC(OpenID Connect) 클라이언트 선택 기능이 통합될 예정입니다.

• CTO 인사이트 블로그

  아리아카 CTO 인사이트 블로그 시리즈는 네트워크, 보안 및 SASE 주제에 대한 사고 리더십을 제공합니다.
  아리아카 제품 사양은 아리아카 데이터시트를 참조하세요.