오늘날의 ZTNA는 다양한 응용 분야에 충분하지 않습니다.

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

제로 트러스트 네트워크 액세스(ZTNA) 구성 요소는 SASE 엔터티에 대한 안전한 인바운드 액세스를 제공하도록 설계되었습니다.erp상승 개인 응용 프로그램. 제로 트러스트 아키텍처(ZTA)의 신원 기반 액세스 제어의 핵심 원칙에 따라 ZTNA는 Ent에 대한 모든 인바운드 세션에서 사용자를 인증하고 사용자 유형, 그룹 및 역할을 기반으로 액세스 제어를 시행하는 데 중요한 역할을 합니다.erp상승 응용 프로그램.

ZTNA 보안은 다음 시나리오에서 상당한 이점을 제공합니다.

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

오늘날 많은 ZTNA 솔루션은 프론트 엔드 단순 Ent에 능숙합니다.erp응용 프로그램이 증가하지만 다음과 같은 다중 테넌트 응용 프로그램에 대한 인증 및 권한 부여를 제공하지 못합니다. SaaS 분야의 다양한 어플리케이션에서 사용됩니다.

ZTNA의 역할 SaaS 애플리케이션: SaaS(Software-as-a-Service) 맥락에서(SaaS) 애플리케이션에서 ZTNA는 인증 및 권한 부여 메커니즘을 강화하고 향상시키는 데 중요한 역할을 할 것이라고 생각합니다. SaaS 애플리케이션에는 다중 테넌시, DoS/DDoS 공격에 대한 복원력, 인증 우회 및 권한 에스컬레이션 공격에 대한 강력한 보호 등 특정 요구 사항이 있습니다. 이 기사에서는 인증 및 권한 부여 프로세스를 오프로드하거나 향상시키는 데 도움이 되는 차세대 ZTNA의 기능에 대해 자세히 설명합니다. SaaS 응용 프로그램. 이 기사에서는 WAAP(웹 응용 프로그램 및 API 보호), HTTPS 종료, 다양한 응용 프로그램 인스턴스로 들어오는 세션의 트래픽 관리, SSH/RDP/VNC 서비스 및 포트 스캐너에서 응용 프로그램을 보이지 않게 합니다. 주요 초점은 ZTNA의 인증 및 권한 부여 측면에 있습니다.

의 역할 간에 혼동이 있을 수 있다는 점에 유의하는 것이 중요합니다. CASB (Cloud 액세스 보안 브로커) 및 ZTNA의 맥락에서 SaaS. 그만큼 CASB 의 구성 요소 SASE 에 대한 연결을 확보하는 데 중점을 둡니다. SaaS ent가 사용하는 서비스erp상승, 여기서 엔트erp상승은 소비자 SaaS 및 CASB 서비스. 반면에 ZTNA는 SaaS, 보호하도록 설계되었습니다. SaaS 응용 프로그램 자체, 만들기 SaaS ZTNA 서비스의 기업 소비자. 이러한 구분은 서로 다른 역할과 책임을 이해하는 데 필수적입니다. CASB 그리고 ZTNA는 SASE 솔루션을 제공합니다.

대한 이전 기사에서 신원 브로커, 우리는 중개인을 SASE 솔루션. 논의된 장점은 주로 설계의 모듈성과 단순성을 중심으로 이루어졌으며 궁극적으로 SASE 솔루션. 이 기사에서는 복잡한 애플리케이션을 지원하는 데 있어 ID 브로커의 중추적인 역할에 대해 자세히 설명합니다. SaaS 분야의 다양한 어플리케이션에서 사용됩니다.

다중 테넌트 애플리케이션의 문제점은 무엇입니까?

ZTNA의 SASE 정책 기반 인증에 대한 강력한 지원을 제공하는 데 탁월합니다. 내의 권한 부여 엔진 SASE 각 테이블에 여러 정책이 포함된 여러 정책 테이블을 관리하는 기능을 제공합니다. 각 정책은 여러 규칙으로 구성되며 성공적인 일치 시 수행할 작업을 지정합니다. 규칙 자체는 원본 및 대상 속성으로 분류할 수 있는 다양한 일치 속성을 포함합니다.

대상 속성은 URI 및 이러한 리소스와 상호 작용하는 데 사용되는 메서드(예: GET, PUT, POST, DELETE)와 같이 액세스되는 애플리케이션의 리소스와 주로 관련됩니다. 반면 소스 속성은 일반적으로 리소스에 액세스하는 주체와 연결됩니다. 이러한 특성에는 이름, 그룹, 역할, 사용자 자격 증명을 확인한 인증 서비스 및 기타 사용자 클레임과 같은 사용자 관련 특성이 포함됩니다. 또한 주체가 사용하는 장치의 보안 상태와 사용자가 리소스에 액세스하는 장치의 위치를 ​​캡처하는 장치 컨텍스트 속성도 포함됩니다.

그러나 많은 ZTNA 솔루션은 포괄적인 인증 시나리오를 처리하는 데 부족하여 종종 그 기능을 비인증으로 제한합니다.SaaS 응용 프로그램. Identity Broker의 포함 SASE/SSE 솔루션은 모든 유형의 애플리케이션에서 포괄적인 인증을 달성하기 위한 진보적인 단계입니다. 라고 주장할 수 있지만 SaaS 공급업체는 애플리케이션 내에서 인증 및 권한 부여를 처리할 수 있는 기능을 보유하고 있으며 환경이 크게 발전했습니다.

오늘날의 민첩한 환경에서 SaaS 제공업체는 다음과 같은 외부 엔터티에 보안 책임을 전가하는 이점을 점차 인식 SASE. 그렇게 함으로써 생산성을 높이고 전반적인 보안 태세에 대한 자신감을 높일 수 있습니다. 또한 이 접근 방식은 새로운 SaaS 공급자는 인증 및 권한 부여를 외부 엔터티로 오프로드하고 주로 핵심 비즈니스 논리에 집중할 수 있으므로 시장에 더 신속하게 진입할 수 있습니다. SASE 솔루션은 이러한 새로운 지원에 중추적인 역할을 할 수 있습니다. SaaS 제공.

우리의 믿음은 SASE 솔루션은 SaaS 응용 프로그램. 다음 시나리오는 하나의 대표적인 예를 제공합니다. SaaS 적용 및 방법 탐색 SASE, ID 브로커를 통합하여 애플리케이션에서 인증 및 권한 위임을 도울 수 있습니다.

이 예를 고려하십시오 SaaS 여러 API 리소스로 구성된 애플리케이션(app.example.com에서 호스팅) 시나리오:

이 시나리오에서는 IDP가 SaaS 공급자는 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; 사용자 역할=앱 관리자; authservice=예제-idp; uri = /service-admin-api/* 허용: example-idp 서비스에 성공적으로 로그인하고 도메인 앱이 있는 애플리케이션의 admin-api 아래에 있는 모든 리소스에 대한 app-admin 역할을 소유한 모든 사용자에게 액세스를 허용합니다. .example.com.
2. 도메인 = app.example.com; 사용자 그룹=관리자 그룹; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-admin-api/* 허용: XYZ/tenant-admin-api 아래의 모든 리소스에 대한 admin-group 역할을 소유한 XYZ-idp 서비스에 성공적으로 로그인한 모든 사용자에게 액세스를 허용합니다. .
3. 도메인 = app.example.com; 사용자 역할=관리자 역할; authservice=ABC-idp; uri = /tenants/ABC/tenant-admin-api/* 허용: ABC-idp 서비스로 인증되고 ABC/tenant-admin-api 리소스에 액세스하는 admin-role이 있는 모든 사용자의 액세스를 허용합니다.
4. 도메인 = app.example.com; authservice=XYZ-idp; uri = /tenants/XYZ/tenant-user-api/*, /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* 허용: 다음을 수행하는 모든 사용자에 대해 규칙에 지정된 리소스에 대한 액세스를 허용합니다. XYZ-idp 서비스로 성공적으로 인증되었습니다.
5. 도메인 = app.example.com; authservice=ABC-idp; uri = /tenants/ABC/tenant-user-api/*, /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* 허용: 다음을 수행하는 모든 사용자에 대해 규칙에 지정된 리소스에 대한 액세스를 허용합니다. ABC-idp 서비스로 성공적으로 인증되었습니다.
6. 도메인 = app.example.com; authservice=XYZ-P1-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* 허용: XYZ-P1-idp 서비스로 인증된 사용자의 XYZ 협업 공간에 대한 액세스를 허용합니다.
7. 도메인 = app.example.com; authservice=XYZ-P2-idp; uri = /tenants/XYZ/collaboration-api/*, /tenants/XYZ/public-api/* 허용: XYZ-P2-idp 서비스로 인증된 사용자의 XYZ 협업 공간에 대한 액세스를 허용합니다.
8. 도메인 = app.example.com; authservice=ABC-P1-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* 허용: ABC-P1-idp 서비스로 인증된 사용자의 ABC 협업 공간에 대한 액세스를 허용합니다.
9. 도메인 = app.example.com; authservice=ABC-P2-idp; uri = /tenants/ABC/collaboration-api/*, /tenants/ABC/public-api/* 허용: ABC-P2-idp 서비스로 인증된 사용자의 ABC 협업 공간에 대한 액세스를 허용합니다.
10. 도메인 = app.example.com; authservice=google.com; uri = /tenants/XYZ/public-api/* 허용: google.com으로 인증된 모든 사용자의 XYZ public-api 공간에 대한 액세스를 허용합니다.
11. 도메인 = app.example.com; authservice=facebook.com; uri = /tenants/XYZ/public-api/* 허용: facebook.com으로 인증된 모든 사용자의 XYZ public-api 공간에 대한 액세스 허용
12. 도메인 = app.example.com; authservice=linkedin.com; uri = /tenants/ABC/public-api/* 허용: linkedin.com으로 인증된 모든 사용자의 ABC public-api 공간에 대한 액세스 허용
13. 도메인 = app.example.com; authservice=github.com; uri = /tenants/ABC/public-api/* 허용: github.com으로 인증된 모든 사용자의 XYZ public-api 공간에 대한 액세스 허용
14. 도메인 = app.example.com; 거부: 위의 규칙 중 어느 것도 일치하지 않는 경우 애플리케이션에 대한 액세스를 거부합니다.

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

ID 브로커의 역할

이러한 시나리오를 해결하려면 ID 브로커의 통합 기능이 필요합니다. ID 브로커는 OIDC(OpenID Connect) 공급자 역할을 합니다. SASE/SSE 프록시 구성 요소는 업스트림 ID 서비스(인증 서비스)에 대해 OIDC/SAML/LDAP 클라이언트 역할을 합니다.

오픈 소스 IAM 시스템인 Keycloak은 많은 사람들에게 인기 있는 선택입니다. ID 브로커의 역할을 수행하도록 구성할 수 있으며 일반적으로 다음에서 사용합니다. SASE 서비스 제공업체 및 서비스 메시 제품 공급업체. 따라서 여기서는 Keycloak 용어를 사용합니다. Keycloak은 다중 테넌트를 포함하여 다양한 유형의 애플리케이션에 대한 인증을 처리할 수 있는 유연성을 제공합니다. SaaS 분야의 다양한 어플리케이션에서 사용됩니다.

다중 테넌트에 대한 인증 SaaS 애플리케이션은 다음과 같은 방식으로 'ID 브로커'를 사용하여 달성할 수 있습니다.

각각에 대해 하나의 클라이언트가 있는 하나의 영역 SaaS 인증 흐름이 수정된 애플리케이션:

애플리케이션 테넌트를 애플리케이션 테넌트에서 식별할 수 없는 경우 URL 경로 또는 HTTP 요청 헤더, SASE 프록시 구성 요소는 ID 브로커와 통신하기 위해 하나의 OIDC 클라이언트만 가질 수 있습니다. 사용자 인증 중에 자격 증명 브로커는 사용자를 인증할 IDP 서비스를 알아야 합니다. Keycloak은 브라우저 흐름과 같은 표준 인증 흐름을 제공하고 맞춤형 흐름을 생성하고 Keycloak 클라이언트와 연결할 수 있습니다. SASE 사용자에게 테넌트 정보를 제공하라는 메시지가 표시되는 인증 흐름을 생성하여 이 기능을 활용합니다. 이 정보를 기반으로 인증 흐름은 사용자가 선택할 수 있는 사용 가능한 ID 공급자를 제시할 수 있습니다. 이 정보를 사용하여 브로커는 사용자를 적절한 ID 서비스로 리디렉션할 수 있습니다.

각각에 대해 여러 클라이언트가 있는 하나의 영역 SaaS 응용 프로그램 :

애플리케이션 테넌트가 URL 또는 HTTP 요청 헤더, SASE 각 애플리케이션 테넌트에 대해 하나의 클라이언트를 사용하도록 프록시 구성 요소를 구성할 수 있습니다. 이 경우 다양한 ID 공급자 세트가 있는 표준 브라우저 흐름을 사용하고 Keycloak의 해당 클라이언트 엔터티와 연결할 수 있습니다. 이것의 장점은 사용자에게 테넌트 이름을 제공하라는 메시지가 표시되지 않아 더 나은 사용자 경험을 제공한다는 것입니다.

요약하면 이러한 전략은 SASE 다중 테넌트에 대한 인증을 효과적으로 처리하는 솔루션 SaaS ID 브로커로서 Keycloak의 기능을 활용하는 애플리케이션.

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

Keycloak 브로커는 각 영역 내에서 여러 영역과 여러 클라이언트를 지원합니다. 표준 인증 흐름, 사용자 지정 인증 흐름 생성 및 이러한 흐름과 클라이언트의 연결을 활성화합니다. Keycloak 브로커 기능은 또한 사용자 측 인증 메커니즘과 백엔드(업스트림) 인증 서비스 간의 인증 세션 중개를 허용합니다. 이전에 Keycloak이 사용자에게 애플리케이션 테넌트를 식별하고 인증을 위해 ID 서비스를 선택하라는 메시지를 표시하는 방법에 대해 논의했습니다.

이러한 기능은 SASE 다중 테넌트 애플리케이션을 포함한 다양한 고객 애플리케이션에 대한 OIDC 클라이언트(OIDC 릴레이라고도 함) 역할을 하는 프록시.

XNUMXD덴탈의 SASE 프록시는 여러 OIDC 클라이언트를 지원해야 합니다. 한 가지 접근 방식은 각 고객에 대한 OIDC 클라이언트 세트를 보유하여 고객별 인증 관련 구성이 다른 구성과 격리되도록 하는 것입니다. 일반적으로 각 SASE 고객의 OIDC 세트는 Keycloak의 영역과 연결됩니다.

고객이 SASE 프록시에는 각각 자체 도메인 이름이 있는 여러 응용 프로그램이 있으므로 여러 응용 프로그램 관리자 간에 격리를 제공해야 합니다. 이러한 경우 각 애플리케이션에 하나의 클라이언트가 할당되어 OIDC 클라이언트의 하위 집합을 구성해야 합니다.

많은 애플리케이션의 경우 단일 테넌트 애플리케이션이거나 앞에서 설명한 것처럼 트래픽에서 테넌트를 식별할 수 없는 경우 단일 OIDC 클라이언트로 충분합니다. 그러나 테넌트를 식별할 수 있는 경우 각 애플리케이션 테넌트에 대해 하나의 OIDC 클라이언트를 구성할 수 있습니다.

여러 OIDC 클라이언트에 대한 요구 사항으로 인해 SASE 프록시는 적절한 OIDC 클라이언트를 선택하기 위한 메커니즘을 제공해야 합니다. 여기에서 정책 기반 OIDC 선택이 중요해집니다.

여러 정책이 포함된 정책 테이블이 활용되며 각 정책은 해당 OIDC 클라이언트 레코드를 가리킵니다. 교통 흐름 중에는 SASE 프록시는 OIDC 인증이 필요한지 확인한 다음 테이블의 정책에 대해 고객, 애플리케이션 도메인 이름 및 애플리케이션 테넌트를 일치시킵니다. 일치 항목이 발견되면 해당 OIDC 클라이언트 레코드를 사용하여 브로커와 통신합니다. 일부 구현에는 정책 일치 프로세스를 촉진하기 위해 각 고객 전용 테이블이 있는 여러 정책 테이블이 있을 수 있습니다.

NextGen ZTNA는 다중 테넌트 애플리케이션에 적응할 것입니다.

ZTNA(Zero Trust Network Access) 내 SASE (Secure Access Service Edge) 솔루션은 애플리케이션 보안에 중요한 역할을 합니다. 애플리케이션에서 인증 및 권한 부여 작업을 오프로드할 수 있으므로 개발자는 핵심 비즈니스 논리에 집중할 수 있습니다. 이 접근 방식은 생산성을 향상시키고 전반적인 보안을 강화합니다.

모든 개발자가 보안에 대한 전문 지식을 가지고 있는 것은 아니기 때문에 인증 우회 및 권한 에스컬레이션 취약성은 애플리케이션에서 일반적입니다. 오프로드 보안은 이러한 취약성을 제거하여 더 강력한 애플리케이션 복원력을 보장할 수 있습니다.

다음과 같은 일상적인 보안 중앙 집중화 SASE, 모든 애플리케이션에 대해 단일 인터페이스만 관리하면 되는 보안 관리자의 작업을 단순화합니다.

보안과 유연성을 모두 달성하기 위해 차세대 ZTNA는 SASE 솔루션은 다양한 애플리케이션 유형을 처리해야 합니다. 기존의 많은 ZTNA 솔루션은 다중 테넌트 애플리케이션을 효과적으로 지원하는 데 어려움을 겪는 경우가 많습니다. 향후 개선 사항은 ID 브로커 기능과 정책 기반 OIDC(OpenID Connect) 클라이언트 선택을 통합하여 광범위한 애플리케이션 시나리오를 수용할 것으로 예상됩니다.

• CTO 인사이트 블로그

  XNUMXD덴탈의 Aryaka CTO Insights 블로그 시리즈는 네트워크, 보안 및 보안에 대한 사고 리더십을 제공합니다. SASE 주제. 을 위한 Aryaka 제품 사양 참조 Aryaka 데이터시트.