신원 인식 실현 SASE

신원 인식이 필요한 이유 SASE?

의 이전 블로그 해독 SASE 의 다양한 보안 구성 요소에서 신원 인식에 대해 이야기했습니다. SASE. 이 게시물은 신원 인식을 실현하기 위한 다양한 방법을 설명합니다. SASE.

기존 경계 중심 보안의 액세스 제어는 IP 주소 및 서비스를 사용하여 정의됩니다. 클라이언트는 액세스 정책에서 IP 주소로 표시되며 서비스는 도메인 이름 및 IP 주소와 함께 정의됩니다. TCP/UDP 포트(예: HTTP용 포트 80, HTTPS용 443 등) 클라이언트 유형이 다양하므로 PC/노트북/모바일, 클라이언트 애플리케이션, IoT 장치 및 다양한 인간 사용자 범주를 통해 서비스에 액세스하는 인간 사용자, 다양한 유형의 클라이언트를 나타내는 각 세그먼트가 발명되었습니다. 각 세그먼트에는 자체 서브넷 또는 IP 주소 범위가 지정됩니다. 이를 통해 서로 다른 유형의 클라이언트에 대한 액세스 제어를 정의할 수 있습니다.

다양한 클라이언트에 대한 액세스 제어를 정의하는 데 있어 몇 가지 문제를 해결했지만 다음과 같은 또 다른 복잡성을 도입했습니다. 세그먼트 관리. 빠르게 많은 조직에서 세그먼트가 폭발적으로 증가하기 시작했습니다. 조직은 차별화를 정의하기 위해 다양한 세그먼트를 생성해야 할 필요성을 인식하기 시작했습니다. QoS, WAN 링크 선택 및 다양한 유형의 보안 액세스 제어.

세분화의 또 다른 큰 과제는 "어디서나 일할 수있다..” 즉, 사용자 IP 주소는 사용자가 작업하는 위치에 따라 계속 변경됩니다. 이 경우 세그먼트와의 사용자 연결이 빠르게 큰 문제가 됩니다. 지정된 사무실, 집, 커피숍, 다른 사무실 또는 파트너 사무실에서 근무하는 사용자는 사용자가 근무하는 장소에 관계없이 동일한 방식으로 취급됩니다.

신원 인식 SASE 최소한 인간 사용자를 위해 클라이언트를 차별화하기 위해 세그먼트를 생성할 필요가 없으므로 세그먼트 관리가 더 간단해집니다. 그러나 IoT 장치와 같은 클라이언트에 대한 세그먼트를 완전히 제거할 수는 없습니다.

신원 인식 SASE '디지털 포렌식'에도 필요합니다. 데이터 침해가 발생하면 공격자가 사용한 접근 방식, 악용된 약점을 이해하고 전반적인 영향을 식별하기 위해 공격 중에 발생한 일을 아는 것이 중요합니다. "에 따르면2022 Verizon 데이터 위반 보고서”, 데이터 유출의 82%는 인적 요소와 관련이 있습니다. 따라서 각 연결/세션의 ID는 액세스 패턴, 방문한 사이트, 첫 번째 감염을 초래한 사용자가 사용하는 장치 및 애플리케이션을 이해하는 데 매우 중요합니다. 그런 다음 궁극적으로 위반을 초래하는 측면 공격을 찾는 데 추가로 도움이 될 수 있습니다.

요약하면 신원인식은 SASE 다음에 도움이 됩니다.

• 방화벽, SWG, CASB 다양한 사용자를 위한 ZTNA
• 차별화된 네트워크 정책 정의 QoS, 다양한 사용자를 위한 라우팅
• 디지털 법의학
• 사용자 행동 분석

신원 확인 SASE 정책

SASE 구성 요소들 다양한 세분성으로 다양한 서비스/사이트에 대한 액세스를 제어합니다. 방화벽 SASE L3/L4 계층에서 액세스를 제어합니다. SWG는 다음 수준에서 액세스를 제어합니다. URL에스. ZTNA 및 CASB API 수준에서 액세스를 제어합니다. SWG, ZTNA 및 CASB DLP를 사용하면 데이터 수준에서 액세스를 제어할 수 있습니다. 위에서 설명한 이유와 NIST에서 지정한 제로 트러스트 지침을 충족하려면 이러한 모든 컨트롤이 선택자 중 하나인 사용자와 함께 필요합니다.

모든 액세스 제어 정책에는 대부분 순서가 지정된 규칙인 일련의 규칙이 포함되어 있습니다. 이러한 규칙은 모든 트래픽 세션에 대해 확인됩니다. 규칙이 일치하면 일치하는 규칙에 지정된 작업이 수행됩니다. 일반적인 작업에는 트래픽 허용, 트래픽 거부 또는 트래픽 모니터링 및 로깅이 포함됩니다. 모든 규칙의 일치는 속성 집합을 사용합니다. 각 규칙은 이러한 속성 값으로 지정됩니다. 이러한 속성에는 전통적으로 5튜플(소스 IP, 대상 IP, 프로토콜, 소스 포트 및 대상 포트), 영역 및 위치가 포함됩니다. 새 트래픽 세션에서 패킷 및 컨텍스트(영역, 위치)에서 값이 추출되고 규칙 속성의 값과 일치합니다. 일치하면 규칙이 일치한다고 합니다.

신원 인식으로 SASE, 규칙 일치 속성에는 사용자 속성이 포함됩니다. 사용자 속성은 개별 사용자 이름, 사용자 그룹, 사용자 역할, 클라이언트 인증서 주체 이름 또는 인증서 주체 대체 이름의 집합일 수 있습니다. 정책 매칭에는 신원 기반을 위한 사용자 컨텍스트와의 매칭이 포함되어야 합니다. SASE.

새 트래픽 세션에 대한 일반적인 정책 일치는 다음과 같습니다.

• 패킷에서 5개의 튜플(소스 IP 주소, 대상 IP 주소, IP 프로토콜, 소스 포트 및 대상 포트)을 추출합니다.
• 트래픽 세션이 시작된 소스 영역 및 위치를 가져옵니다.
• 트래픽 세션을 시작한 사용자 정보(이름, 사용자 그룹 및 사용자 역할)를 가져옵니다.
• 트래픽 세션이 시작된 시스템의 장치 상태를 가져옵니다.
• 위에서 추출한 정보를 규칙 일치 속성 값과 일치시켜 정책의 위에서 아래로 규칙을 살펴봅니다. 일치하는 항목이 있으면 해당 규칙에 지정된 조치를 취하십시오. 그렇지 않은 경우 다음 규칙으로 이동합니다.
• 일치하는 규칙이 없으면 해당 정책 테이블 수준에 대해 구성된 조치를 취하십시오.

사용자 식별 및 인증

트래픽 세션에 대한 정책 확인 전에 사용자를 식별해야 하므로 다음과 같은 몇 가지 질문이 발생합니다.

• 어떻게 SASE 사용자를 인증합니까?
• 어떻게 SASE 트래픽을 수신할 때 사용자를 식별합니까?

거기에 가기 전에 몇 가지 고려 사항을 살펴 보겠습니다. SASE 솔루션 돌볼 것. SASE 다음 유형의 클라이언트를 고려해야 합니다.

• 브라우저를 사용하여 서비스에 액세스하는 인간 사용자
• 브라우저가 아닌 애플리케이션을 사용하여 서비스에 액세스하는 인간 사용자
• 서비스에 액세스하기 위해 사람의 개입 없이 작동하는 비브라우저 애플리케이션
• CA 인증서 고정 기능이 있는 비브라우저 애플리케이션
• 서비스에 액세스하는 IoT 장치

그 의미는 SASE 솔루션은 트래픽 세션을 시작하는 인간 사용자가 항상 있다고 가정할 수 없습니다. 트래픽 세션을 시작하는 프로그래밍 방식의 엔터티 및 장치가 있을 수 있습니다. SASE 두 종류의 고객 모두에게 서비스를 제공할 것으로 예상되므로 SASE 솔루션은 여러 인증 방법을 지원합니다.

SASE 다음과 같은 사용자 경험 문제를 고려해야 합니다.

• 인간 사용자에게 사용자 자격 증명을 얻기 위한 팝업 화면이 없거나 적게 표시되는 사용자 경험
• 인간 사용자에게 특정 액세스가 거부된 이유를 알려주는 사용자 경험
• 서비스에 액세스하기 위해 자신의 장치를 사용하는 사용자
• Employer 관리 장치를 사용하여 서비스에 액세스하는 사용자
• 집에서 일하든 사무실에서 일하든 상관없이 사용자를 위한 균일한 경험

위의 요구 사항 및 의미와 함께 SASE 솔루션은 다양한 인증 모드를 구현합니다. 에서 지원하는 대부분의 인증 모드 SASE 솔루션은 여기에 나열되어 있습니다.

• 역방향 프록시 인증
• 정방향 프록시 인증
• 포털 기반 인증
• 터널 인증
• 클라이언트 인증서 인증
• API 키 기반 인증

클라이언트가 인증하면 SASE 위를 통해, SASE 사용자가 시작한 트래픽 세션을 올바른 사용자와 연결하는 방법이 있어야 합니다. 두 가지 식별 매핑 방식이 사용됩니다. 그들은:

• 토큰 매핑: SASE 솔루션은 HTTP/HTTPS 트래픽 세션의 요청 헤더에 있는 인증/ID/Bearer 토큰에서 사용자를 식별합니다. 클라이언트에는 인증의 일부로 토큰이 제공되며 트래픽 세션에서 클라이언트가 동일한 토큰을 제공합니다.
• 대표 IP 매핑: 이 접근 방식에서 IP 주소는 사용자를 나타냅니다. SASE 솔루션은 트래픽 세션의 소스 IP 주소를 사용하여 사용자를 식별합니다. 사용자가 처음으로 인증할 때 SASE 성공적으로, SASE 해당 사용자의 사용자 IP 주소를 기록합니다. 나중에 이 IP 주소에서 오는 모든 트래픽 세션이 사용자와 연결됩니다.

토큰은 HTTP/HTTPS 트래픽 세션에만 유효합니다. 토큰은 모든 HTTP 세션에 직접 또는 쿠키를 통해 간접적으로 존재하므로 '대표 IP'보다 더 안전한 것으로 간주됩니다. 비HTTP/HTTPS 트래픽 세션의 경우 '대표 IP' 매핑이 다음에서 사용됩니다. SASE 솔루션. '대표 IP' 매핑 방법에는 IP 주소가 시스템의 모든 응용 프로그램에서 사용되므로 몇 가지 문제가 있습니다. 즉, 브라우저 사용자가 SASE 솔루션을 사용하면 브라우저뿐만 아니라 컴퓨터에서 실행되는 다른 모든 클라이언트 응용 프로그램도 동일한 액세스 권한을 갖게 됩니다. 다중 사용자 시스템의 경우 한 사용자가 성공적으로 인증하더라도 해당 시스템의 모든 사용자가 액세스할 수 있습니다. SASE 해결책. 더 위험한 것은 인증에 사용되는 시스템이 SASE 시스템이 NAT 장치 뒤에 있습니다. 해당 NAT IP 주소 뒤에 있는 모든 사용자가 액세스할 수 있습니다. 따라서 '대표 IP' 기능은 필요한 경우에만 사용하고 이 매핑을 HTTP/HTTPS가 아닌 세션에만 제한하는 것이 특히 중요합니다.

토큰(프록시 인증 헤더 또는 인증 헤더를 통해 또는 쿠키를 통해)은 각 HTTP 요청의 일부이므로 SASE 솔루션은 토큰을 보낼 수 있습니다. 액세스가 필요한 다른 웹 기반 클라이언트 애플리케이션은 SASE 액세스할 수 있는 솔루션입니다. 보안상의 이점으로 인해 모든 HTTP/HTTPS 세션에 대해 토큰 매핑 방식을 사용하는 것이 좋습니다.

다양한 사용자 인증 및 식별 SASE 구성 요소들

많은 SASE 웹 기반 애플리케이션/서비스에 보안을 제공하는 구성 요소는 HTTP 요청 헤더, 클라이언트 인증서 또는 API 키의 토큰을 통해 트래픽 세션에 사용자를 식별하고 연결하는 경향이 있습니다.

다음 섹션에서는 관련성이 높은 최상의 인증 모드를 다양한 인증 모드에 매핑합니다. SASE 구성 요소.

ZTNA

ZTNA는 이 문서에서 논의된 바와 같이 이전 블로그, Ent를 보호하기 위한 것입니다.erp말리에서 신청 증가cio우리와 감염된 클라이언트. ZTNA는 프론트엔드 응용 서비스로 다음과 같은 기능을 제공합니다.

• TLS/SSL 비 TLS/에 대한 보안SSL 애플리케이션 및 강력한 암호화 알고리즘을 지원하지 않는 애플리케이션용
• RBAC를 지원하지 않는 애플리케이션 및 두 번째 수준의 RBAC가 필요한 애플리케이션에 대한 RBAC/최소 권한 액세스 지원
• MFA 수준이 한 단계 더 높은 권한 액세스 관리
• 여러 애플리케이션 인스턴스에서 트래픽의 로드 밸런싱
• 애플리케이션에 대한 WAF 및 API 수준 위협 보호 보안

ZTNA는 애플리케이션 서비스에서 보안 책임을 제거함에 따라 점점 더 필요성이 높아지고 있습니다. 결과적인 이점에는 Ent의 생산성 증가가 포함됩니다.erp응용 프로그램 개발 증가, 여러 응용 프로그램 서비스에 걸친 균일한 보안 구성 및 적은 공격 표면.

ZTNA는 주로 웹 기반 애플리케이션 보안을 위한 것입니다. 애플리케이션 개발자는 웹 프로토콜을 사용하여 새로운 애플리케이션을 생성할 뿐만 아니라 기존 애플리케이션도 웹 프로토콜에서 발생하는 혁신을 활용하기 위해 웹화되고 있습니다. SSH와 같은 전통적인 관리 프로토콜도 다음과 같은 프로젝트를 사용하여 웹화되고 있습니다. 아파치 과카 몰리. 즉, 웹이 아닌 응용 프로그램은 항상 있을 것입니다. 방화벽의 일부 SASE Ent에 대한 액세스 제어 및 위협 보호 보안 제공erp웹이 아닌 서비스를 인스턴스화하십시오. 자세한 내용은 방화벽 섹션을 참조하십시오.

ZTNA는 트래픽에 어떻게 액세스합니까?

ZTNA는 두 가지 방법으로 트래픽에 액세스합니다. DNS 방법 및 투명 프록시 방법.

Ent의 관리자erp상승 응용 프로그램은 응용 프로그램에 대한 ZTNA를 가리키도록 신뢰할 수 있는 도메인 서버를 구성합니다. 즉, 관리자가 구성 DNS ZTNA IP 주소로 응답하는 서버 DNS 애플리케이션의 FQ에 대한 쿼리DNs. 투명 프록시 방식에서는 ZTNA가 트래픽 라인에 있거나 트래픽 라인에 있는 엔터티가 트래픽을 가로채 ZTNA로 트래픽을 보낼 것으로 예상됩니다. 애플리케이션 관리자는 또한 TLS/로 ZTNA를 구성합니다.SSL 애플리케이션 서비스를 대신하는 인증서/개인 키 쌍.

ZTNA는 어떻게 사용자를 인증하고 트래픽 세션을 사용자에게 매핑합니까?

ZTNA는 리버스 프록시 인증, 클라이언트 인증서 및 API 키 인증 모드를 지원하여 다양한 유형의 클라이언트(인간 사용자 및 프로그래밍 엔티티)를 인증합니다. 다음과 같이 작동합니다.

• ZTNA는 TLS/SSL 연결
• 클라이언트 인증서가 협상되면 클라이언트 인증서의 유효성을 검사합니다. 유효하면 인증서 주체 이름과 SAN(주체 대체 이름)을 추출합니다. 클라이언트 사용자의 ID입니다. 사용자 그룹 또는 역할이 프로비저닝되면 프로비저닝된 데이터베이스에서 그룹 및 역할 정보를 추출합니다.
• 클라이언트가 API 키를 제시하면 사용자 ID를 추출하기 위해 내부 데이터베이스(프로비저닝됨)를 참조합니다. 사용자 그룹 또는 역할이 프로비저닝되면 프로비저닝된 데이터베이스에서 그룹 및 역할 정보를 추출합니다.
• HTTP 요청에 연결된 인증/ID 토큰이 있는 경우 사용자가 이전에 인증되었음을 의미합니다. 또한 사용자 컨텍스트(사용자 이름, 사용자 그룹 및 사용자 역할이 있는 경우)가 ZTNA에 알려져 있음을 의미합니다.
• 토큰이 유효하지 않거나 토큰이 없으면 사용자에게 OIDC를 통해 식별 및 인증을 요청합니다. ZTNA의 OIDC 브로커는 사용자가 Ent로 인증할 수 있도록 다양한 인증 프로토콜을 사용할 수 있습니다.erp상승 인증 서비스. 특권 계정의 경우 ZTNA는 자체 MFA를 수행하여 사용자가 실제 사용자인지 확인합니다.
• 사용자가 성공적으로 인증되면 ZTNA의 OIDC 구성 요소가 ID 토큰을 설정합니다. 또한 사용자 정보(사용자 이름, 사용자 그룹(있는 경우) 및 사용자 역할(있는 경우))를 기록합니다.
• 그런 다음 ZTNA는 애플리케이션 서비스 인스턴스 중 하나에 대한 연결을 설정합니다.
• HTTP 트랜잭션당 사용자 기반 액세스 제어 결정을 수행합니다.
• ZTNA가 고급 위협 보호용으로 구성된 경우 트래픽에서 익스플로잇, 맬웨어 및 민감한 데이터 유출도 검사합니다.

ID 토큰이 만료될 때까지 자격 증명을 한 번만 제공하라는 화면이 사용자에게 표시됩니다. 클라이언트의 동일 출처 정책으로 인해 클라이언트는 항상 응용 프로그램 서비스에 대한 HTTP 트랜잭션에서 올바른 ID 토큰을 제시합니다. ID 토큰이 유효하면 ZTNA는 해당 정보를 사용하여 세션을 올바른 사용자에게 매핑합니다.

SWG 및 CASB

SWG 구성 요소는 맬웨어, 피싱 및 안전하지 않은 사이트를 방문하는 사용자를 보호합니다. 또한 감염 시 클라이언트 애플리케이션이 C&C 봇넷 사이트에 접속하지 못하도록 보호합니다. 또한 SWG는 조직 내 사용자의 역할과 사용자가 속한 그룹에 따라 다양한 사이트에 대한 차별화된 액세스를 제공하는 방법을 제공합니다. SWG는 또한 다양한 분석 및 디지털 포렌식에 도움이 될 수 있는 사용자 정보와 함께 트래픽 세션 메타데이터를 기록합니다. CASB 구성 요소는 Ent를 보호합니다.erp에 의해 유지되는 상승 데이터 SaaS 다양한 서비스에 대한 API 수준 액세스 제어를 사용하여 올바른 사용자만 데이터에 액세스하고 수정하도록 보장함으로써 공급자 SaaS 분야의 다양한 어플리케이션에서 사용됩니다. CASB는 SWG와 마찬가지로 다양한 분석 및 디지털 포렌식을 위해 사용자 정보와 함께 API 메타데이터도 기록합니다.

SWG와 CASB 구성 요소는 사용자에서 인터넷 사이트로 이동하는 HTTP/HTTPS 트래픽을 검사해야 합니다. SWG 및 CASB 클라이언트 연결 종료, 수행 SSL 허용되는 경우 가로채기, 더 심층적인 콘텐츠 검사를 수행하여 맬웨어를 감지 및 방지하고 민감한 데이터 유출을 중지합니다.

SWG는 어떻게 CASB 트래픽에 액세스할 수 있습니까?

SWG & CASB 프록시는 프록시/PAC 방법과 투명 방법의 두 가지 방법을 통해 트래픽을 확보합니다.

프록시/PAC 방법에서 클라이언트 시스템/응용 프로그램은 프록시 설정으로 수동으로 구성되거나 클라이언트 응용 프로그램이 프록시 자동 검색을 통해 자동 구성됩니다. 클라이언트 애플리케이션이 프록시를 알게 되면 클라이언트 애플리케이션은 HTTP CONNECT 방법을 사용하여 일반적으로 HTTP 및 HTTPS 트랜잭션인 데이터 세션을 터널링합니다. HTTP CONNECT URI는 내부 HTTP 및 HTTPS 트랜잭션의 대상을 나타냅니다. 프록시는 이것을 사용합니다. URL 대상 사이트에 연결합니다. 프록시는 데이터가 클라이언트와 서버에서 또는 그 반대로 전달되도록 허용하기 전에 모든 액세스 제어 및 위협 보호 서비스를 수행합니다.

투명 프록시 방식에서는 클라이언트가 프록시에 대해 알지 못합니다. 트래픽을 확보하기 위해 프록시가 트래픽 라인에 있을 것으로 예상됩니다.

SWG/CASB 프록시는 사용자를 인증하고 트래픽 세션을 사용자에게 매핑합니까?

프록시/PAC 방법을 사용하여 SWG/CASB 그러면 프록시는 HTTP CONNECT 트랜잭션의 일부로 사용자를 인증할 기회를 얻습니다. 이를 "정방향 프록시 인증"이라고 합니다. HTTP CONNECT 기반 정방향 프록시 인증에 대해 설명합니다. 여기에서 지금 확인해 보세요. 아주 잘. 이 링크는 NTLM 인증을 설명하지만 비슷한 흐름이 Kerberos 인증에도 동일하게 적용될 수 있습니다. HTTP CONNECT는 모든 HTTP/HTTPS 트래픽 세션에 선행하므로 사용자는 각 세션에서 프록시에 알려집니다. 이 방법의 한 가지 좋은 점은 브라우저 응용 프로그램 외에도 대부분의 기본 클라이언트 응용 프로그램이 프록시 설정을 준수하고 프록시로 인증할 수 있으므로 대부분의 인터넷 액세스 사용 사례를 다룰 수 있다는 것입니다.

투명 프록시 방식에서는 HTTP CONNECT 트랜잭션이 없습니다. 따라서 순방향 프록시 인증은 불가능합니다. 모든 사용자 인증은 HTTP 요청을 SASE OIDC 및 SAML 방법을 사용하여 사용자를 인증합니다. 이러한 종류의 인증을 "포털 기반 인증"이라고 합니다. 사용자가 성공적으로 로그인하면 포털에서 쿠키를 설정할 수 있지만 브라우저의 동일 출처 정책으로 인해 사용자가 인터넷 사이트를 탐색할 때 프록시에 쿠키가 표시되지 않습니다. 이 문제로 인해 사용자가 성공적으로 로그인하면 포털은 사용자 인증 세션의 사용자 이름과 소스 IP 주소 간에 매핑을 생성하고 프록시에 이 매핑을 알립니다. 나중에 프록시는 이 매핑을 사용하여 트래픽 세션을 사용자에게 매핑합니다. 사용 가능한 매핑이 없는 경우 프록시는 로그인을 위해 트래픽 세션을 포털로 리디렉션합니다. 이 '매핑'을 "대표 IP 매핑"이라고 합니다. 앞에서 설명한 것처럼 이 매핑 방법은 의도하지 않은 당사자에게 액세스를 허용할 수 있으므로 주의해서 사용해야 합니다.

투명한 프록시 방법은 들어오는 HTTP 트랜잭션의 리디렉션에 따라 달라집니다. 이는 다음을 통해 명확한 트래픽을 확보해야 함을 의미합니다. SSL 차단. 경우가 있습니다. SSL/TLS 가로채기가 허용되지 않거나 불가능합니다. 이러한 경우 리디렉션이 불가능하므로 사용자가 다음에 대해 인증을 받아야 합니다. SASE 포털의 사전 인증 또는 '터널 인증'과 같은 다른 메커니즘을 통해.

방화벽 및 L3/L4 기반 기능

방화벽 및 관련 NAT, 라우팅, QoS 함수는 L3/L4 계층 수준의 패킷에서 작동합니다. 이러한 기능은 트래픽 라인에 있는 시스템에 있어야 합니다. 더 자주, SASE 이러한 기능을 가진 시스템은 사이트 및 원격 사용자로부터 오는 트래픽에 대한 게이트웨이입니다.

방화벽은 액세스 제어, 역방향 프록시 및 순방향 프록시와 관련하여 HTTP 및 HTTPS 이외의 모든 종류의 프로토콜을 다루기 때문에 주문형 포털 인증 메커니즘이 불가능합니다. 사용자를 인증하는 데 주로 사용되는 두 가지 모드인 명시적 포털 인증과 터널 인증이 있습니다.

명시적 포털 인증 모드에서 사용자는 SASE 브라우저에서 SASE 문. 그만큼 SASE 포털은 OIDC와 함께 사용자를 인증합니다. 이 경우에도, SASE '대표 IP' 매핑 방식을 사용합니다. 그만큼 SASE 포털은 성공적인 사용자 인증 시 IP 주소 대 사용자 매핑을 방화벽으로 보냅니다. 방화벽 및 L3/L4 기능은 이러한 매핑 레코드를 사용하여 트래픽 세션을 사용자와 연결합니다.

터널 인증 모드에는 클라이언트 장치에 설치된 특수 소프트웨어가 필요합니다. 클라이언트는 터널 세션을 만듭니다. SASE 능동적으로. 해당 터널의 일부는 SASE. IPSec 기반 터널이 사용되는 경우 터널 인증은 SASE/IKEv2 구성 요소. SASE/IKEv2 구성 요소는 사용자(이니시에이터 ID) 및 가상 IP 주소 매핑을 SASE 보안 및 네트워킹 서비스. 방화벽 및 L3/L4 기능은 '대표 IP' 매핑 방식을 사용하여 트래픽 세션을 사용자에게 매핑합니다.

이 두 가지 인증 모드가 여기에 명시적으로 언급되어 있지만 사용자가 '역방향 프록시', '정방향 프록시' 모드에서 프록시에 인증할 때 사용자 매핑에 대한 IP 주소도 프록시에서 올 수 있습니다.

여기서 주목해야 할 점은 사용자별 규칙이 유효하려면 사용자 인증이 발생할 것으로 예상된다는 것입니다. 사용자가 인증되지 않은 경우 정책 일치 로직은 사용자를 알 수 없다고 가정합니다. 이로 인해 방화벽 및 L3/L4 수준의 사용자 기반 정책은 기회주의적인 것으로 간주됩니다. 사용자가 사전에 로그인하도록 장려/상기시키기 위해, SASE 솔루션은 브라우저 알림을 생성하여 사용자에게 SASE 문.

통합 인증 SASE 및 신원

통합 인증 SASE 논의되었다 여기에서 지금 확인해 보세요., 그리고 그 게시물은 다양한 이점을 제공했습니다 Enterp"통일 SASE” 제물.

경우 SASE 다양한 개별 구성 요소로 구축되므로 사용자 인증이 여러 번 발생할 수 있으며 이는 좋은 사용자 경험이 아닙니다. '통합 SASE,' 사용자는 전체 기간 동안 한 번만 인증을 받아야 합니다. SASE. 이는 'Unified SASE. '

통합 인증 SASE 오퍼링은 공통 관찰 가능성 플랫폼에 대해 일관되고 포괄적인 방식으로 관련 로그 메시지에 사용자 정보를 추가합니다. SD 전반에 걸쳐 사용자 행동을 모니터링하여 다양한 분석 및 이상 탐지에 도움을 줍니다.WAN 및 보안 서비스.

요약

마이크로 세분화 접근 방식이 필요하지만 다양한 사용자를 분류하기 위해 마이크로 세분화를 확장하는 것은 확장 가능한 솔루션이 아닙니다. SASE 솔루션은 점점 더 ID 기반 정책 정의 및 시행을 지원하고 있습니다. SASE 솔루션은 사용자를 인증한 다음 트래픽 세션을 사용자에게 매핑하여 이를 수행합니다. SASE 솔루션은 사용자가 인증할 수 있는 다양한 방법을 제공합니다. SASE. 이 게시물에서는 몇 가지 방법을 설명했습니다. Aryaka 정체성 인식의 여정을 시작했습니다 SASE'.  Aryaka SWG 솔루션은 사용자별 정책 시행을 지원합니다. 자세히 알아보기 Aryaka SWG 솔루션은 다음과 같습니다. https://www.aryaka.com/secure-web-gateway/

• CTO 인사이트 블로그

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