신원 인식 SASE 실현

왜 SASE에서 신원 인식을 해야 하나요?

이전 블로그 ‘ SASE 해독하기 ‘에서는 SASE의 다양한 보안 구성 요소에서 ID 인식에 대해 이야기했습니다. 이 게시물에서는 신원 인식 SASE를 구현하는 다양한 방법에 대해 설명합니다. 기존 경계 중심 보안의 액세스 제어는 IP 주소와 서비스를 사용하여 정의됩니다. 클라이언트는 액세스 정책에서 IP 주소로 표시되며, 서비스는 도메인 이름 및 IP 주소와 함께 HTTP의 경우 포트 80, HTTPS의 경우 포트 443과 같은 TCP/UDP 포트로 정의됩니다. PC/노트북/모바일을 통해 서비스에 접속하는 인간 사용자, 클라이언트 애플리케이션, IoT 디바이스 등 다양한 유형의 클라이언트가 존재하기 때문에, 각 세그먼트가 다양한 유형의 클라이언트를 대표하는 세분화 접근 방식이 고안되었습니다. 각 세그먼트에는 고유한 서브넷 또는 IP 주소 범위가 지정됩니다. 이를 통해 다양한 유형의 클라이언트에 대한 액세스 제어를 정의할 수 있습니다. 다양한 클라이언트에 대한 액세스 제어를 정의하는 데 있어 몇 가지 문제를 해결했지만, 세그먼트 관리라는 또 다른 복잡한 문제가 발생했습니다. 빠르게 많은 조직에서 세그먼트가 폭발적으로 증가하기 시작했습니다. 조직은 차별화된 QoS, WAN 링크 선택, 다양한 유형의 보안 액세스 제어를 정의하기 위해 다양한 세그먼트를 만들어야 할 필요성을 인식하기 시작했습니다. 세분화의 또 다른 큰 과제는 “어디서나 작업하기“와 관련된 것입니다. 즉, 사용자 IP 주소는 사용자의 작업 위치에 따라 계속 변경됩니다. 이 경우 세그먼트와 사용자를 연결하는 것이 큰 과제가 됩니다. 지정된 사무실, 재택근무, 커피숍, 다른 사무실 또는 파트너 사무실에서 근무하는 사용자는 근무 장소에 관계없이 동일한 대우를 받습니다. 신원 인식 SASE는 고객을 차별화하기 위해 세그먼트를 생성할 필요가 없으므로 세그먼트 관리가 더 간편해집니다(적어도 사람 사용자에 대해서는). 하지만 IoT 디바이스와 같은 클라이언트에 대한 세그먼트를 완전히 제거할 수는 없습니다. ‘디지털 포렌식’에도 신원 인식 SASE가 필요합니다. 데이터 유출이 발생하면 공격자가 사용한 접근 방식과 악용된 취약점을 파악하고 전반적인 영향을 파악하기 위해 공격 중에 어떤 일이 일어났는지 파악하는 것이 중요합니다. “2022 Verizon 데이터 유출 보고서“에 따르면 데이터 유출의 82%가 인적 요소와 관련된 것으로 나타났습니다. 따라서 각 연결/세션의 신원은 최초 감염을 일으킨 사용자의 액세스 패턴, 방문한 사이트, 사용한 디바이스 및 애플리케이션을 파악하는 데 매우 중요합니다. 그러면 궁극적으로 유출을 초래하는 측면 공격을 찾아내는 데 도움이 될 수 있습니다. 요약하면, SASE의 신원 인식은 도움이 됩니다:

• 다양한 사용자를 위해 방화벽, SWG, CASB, ZTNA 전반에 걸쳐 차별화된 접속 정책 정의
• 다양한 사용자를 위한 QoS, 라우팅 전반에 걸쳐 차별화된 네트워크 정책 정의
• 디지털 포렌식
• 사용자 행동 분석

SASE 정책의 신원 확인

SASE 구성 요소는 다양한 서비스/사이트에 대한 액세스를 다양한 세부 단위로 제어합니다. SASE의 방화벽은 L3/L4 계층에서 액세스를 제어합니다. SWG는 URL 수준에서 액세스를 제어합니다. ZTNA와 CASB는 API 수준에서 액세스를 제어합니다. DLP가 포함된 SWG, ZTNA 및 CASB는 데이터 수준에서 액세스를 제어할 수 있습니다. 이러한 모든 제어는 위에서 설명한 이유와 NIST에서 지정한 제로 트러스트 가이드라인을 충족하기 위해 사용자가 선택자 중 한 명인 경우 필요합니다. 모든 액세스 제어 정책에는 일련의 규칙이 포함되어 있으며, 대부분 정렬된 규칙입니다. 이러한 규칙은 모든 트래픽 세션에 대해 확인됩니다. 규칙이 일치하면 일치하는 규칙에 지정된 작업이 수행됩니다. 일반적인 조치에는 트래픽 허용, 트래픽 거부 또는 트래픽 모니터링 및 로깅이 포함됩니다. 모든 규칙의 매칭은 속성 집합과 함께 이루어집니다. 각 규칙은 이러한 속성의 값으로 지정됩니다. 이러한 속성에는 일반적으로 5-튜플(소스 IP, 대상 IP, 프로토콜, 소스 포트 및 대상 포트), 영역 및 위치가 포함됩니다. 새 트래픽 세션이 발생하면 패킷과 컨텍스트(영역, 위치)에서 값을 추출하여 규칙 속성의 값과 일치시킵니다. 일치하면 규칙이 일치하는 것으로 간주합니다. ID 인식 SASE를 사용하면 규칙 일치 속성에 사용자 속성이 포함됩니다. 사용자 속성은 개별 사용자 이름, 사용자 그룹, 사용자 역할, 클라이언트 인증서 주체 이름 또는 인증서 주체 대체 이름 집합일 수 있습니다. 정책 매칭에는 ID 기반 SASE에 대한 사용자 컨텍스트와의 매칭이 포함되어야 합니다. 새 트래픽 세션에 대한 일반적인 정책 매칭은 다음과 같습니다:

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

사용자 식별 및 인증

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

• SASE는 사용자를 어떻게 인증하나요?
• SASE는 트래픽을 수신할 때 사용자를 어떻게 식별하나요?

그 전에 SASE 솔루션이 처리해야 할 몇 가지 고려 사항을 살펴봅시다. SASE는 다음 유형의 클라이언트를 고려해야 합니다:

• 브라우저를 사용하여 서비스에 액세스하는 인간 사용자
• 브라우저 이외의 애플리케이션을 사용하여 서비스에 액세스하는 사람 사용자
• 사람의 개입 없이 작동하여 서비스에 액세스할 수 있는 비브라우저 애플리케이션
• CA 인증서 고정을 사용하는 비브라우저 애플리케이션
• 서비스에 액세스하는 IoT 디바이스

이는 SASE 솔루션이 트래픽 세션을 시작하는 사용자가 항상 인간이라고 가정할 수 없다는 것을 의미합니다. 트래픽 세션을 시작하는 프로그래밍 엔티티와 디바이스가 있을 수 있습니다. SASE는 두 종류의 클라이언트에 모두 서비스를 제공해야 하므로 SASE 솔루션은 여러 인증 방법을 지원합니다. SASE는 다음과 같은 사용자 경험 문제를 고려해야 합니다:

• 사용자 자격 증명을 입력하기 위한 팝업 화면이 표시되지 않거나 적은 사용자 환경
• 특정 액세스가 거부된 이유를 사용자에게 알려주는 사용자 환경
• 자신의 디바이스를 사용하여 서비스에 액세스하는 사용자
• 고용주 관리 장치를 사용하여 서비스에 액세스하는 사용자
• 재택근무든 사무실 근무든 사용자에게 일관된 환경 제공

위와 같은 요구 사항 및 시사점을 바탕으로 SASE 솔루션은 다양한 인증 모드를 구현합니다. SASE 솔루션에서 지원하는 대부분의 인증 모드가 여기에 나열되어 있습니다.

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

클라이언트가 위의 방법을 통해 SASE에 인증하면 SASE는 사용자가 시작한 트래픽 세션을 올바른 사용자와 연결할 수 있는 방법을 갖게 됩니다. 두 가지 식별 매핑 방식이 사용됩니다. 맞습니다:

• 토큰 매핑: SASE 솔루션은 HTTP/HTTPS 트래픽 세션의 요청 헤더에 있는 인증/아이덴티티/발신자 토큰을 통해 사용자를 식별합니다. 클라이언트에게는 인증의 일부로 토큰이 제공되며 트래픽 세션에서 클라이언트가 동일한 토큰을 제시합니다.
• 대표 IP 매핑: 이 접근 방식에서는 IP 주소가 사용자를 대표합니다. SASE 솔루션은 트래픽 세션의 소스 IP 주소를 사용하여 사용자를 식별합니다. 사용자가 처음 SASE를 통해 성공적으로 인증하면 SASE는 해당 사용자의 사용자 IP 주소를 기록합니다. 이후 이 IP 주소에서 발생하는 모든 트래픽 세션이 사용자와 연결됩니다.

토큰은 HTTP/HTTPS 트래픽 세션에만 유효합니다. 토큰은 쿠키를 통해 직접 또는 간접적으로 모든 HTTP 세션에 존재하기 때문에 ‘대표 IP’보다 더 안전한 것으로 간주됩니다. 비 HTTP/HTTPS 트래픽 세션의 경우, SASE 솔루션에서는 ‘대표 IP’ 매핑을 사용합니다. ‘대표 IP’ 매핑 방식은 머신의 모든 애플리케이션에서 IP 주소를 사용하기 때문에 몇 가지 문제가 있습니다. 즉, 브라우저 사용자가 SASE 솔루션에 인증되더라도 브라우저뿐만 아니라 시스템에서 실행 중인 다른 모든 클라이언트 애플리케이션도 동일한 액세스 권한을 갖게 됩니다. 다중 사용자 시스템의 경우, 한 명의 사용자가 SASE 솔루션으로 인증에 성공하더라도 해당 시스템의 모든 사용자가 액세스 권한을 갖게 됩니다. SASE 시스템 인증에 사용되는 시스템이 NAT 장치 뒤에 있는 경우 더욱 위험합니다. 해당 NAT IP 주소 뒤에 있는 모든 사용자가 액세스 권한을 얻게 됩니다. 따라서 ‘대표 IP’ 기능은 필요한 경우에만 사용하고 이 매핑을 비 HTTP/HTTPS 세션으로만 제한하는 것이 특히 중요합니다. 토큰(프록시 권한 부여 헤더 또는 권한 부여 헤더 또는 쿠키를 통해)은 각 HTTP 요청의 일부이므로, SASE 솔루션으로 인증된 클라이언트 애플리케이션만 토큰을 보낼 수 있습니다. 액세스가 필요한 다른 웹 기반 클라이언트 애플리케이션은 액세스 권한을 얻기 위해 SASE 솔루션에 자신을 인증해야 합니다. 보안상의 이점 때문에 모든 HTTP/HTTPS 세션에 토큰 매핑 방식을 사용하는 것을 적극 권장합니다.

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

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

ZTNA

이전 블로그에서 설명한 것처럼 ZTNA는 악성 및 감염된 클라이언트로부터 엔터프라이즈 애플리케이션을 보호하기 위한 것입니다. 프런트엔드 애플리케이션 서비스인 ZTNA는 다음과 같은 기능을 제공합니다.

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

애플리케이션 서비스의 보안 책임이 점점 더 커짐에 따라 ZTNA의 필요성이 점점 더 커지고 있습니다. 그 결과 엔터프라이즈 애플리케이션 개발의 생산성 향상, 여러 애플리케이션 서비스에서 일관된 보안 구성, 공격 표면 감소 등의 이점을 얻을 수 있습니다. ZTNA는 주로 웹 기반 애플리케이션을 보호하는 데 사용됩니다. 애플리케이션 개발자들은 웹 프로토콜로 새로운 애플리케이션을 개발할 뿐만 아니라 기존 애플리케이션도 웹 프로토콜에서 일어나는 혁신을 활용하기 위해 웹화되고 있습니다. SSH와 같은 전통적인 관리 프로토콜도 Apache Guacamole과 같은 프로젝트를 사용하여 웹화되고 있습니다. 하지만 웹이 아닌 애플리케이션은 항상 존재합니다. SASE의 일부인 방화벽은 엔터프라이즈 인스턴스화된 비웹 서비스에 대한 액세스 제어 및 위협 보호 보안을 제공합니다. 자세한 내용은 방화벽 섹션을 참조하세요. ZTNA는 트래픽에 어떻게 액세스하나요? ZTNA는 DNS 방식과 투명 프록시 방식의 두 가지 방법으로 트래픽에 액세스합니다. 엔터프라이즈 애플리케이션의 관리자는 애플리케이션의 ZTNA를 가리키도록 권한 있는 도메인 서버를 구성합니다. 즉, 관리자는 애플리케이션의 FQDN에 대한 DNS 쿼리에 ZTNA IP 주소로 응답하도록 DNS 서버를 구성합니다. 투명 프록시 방식에서는 ZTNA가 트래픽 라인에 있거나 트래픽 라인에 있는 엔티티가 트래픽을 가로채서 ZTNA로 트래픽을 전송할 것으로 예상됩니다. 애플리케이션 관리자는 애플리케이션 서비스를 대신하여 TLS/SSL 인증서/개인 키 쌍으로 ZTNA를 구성할 수도 있습니다. ZTNA는 사용자를 인증하고 트래픽 세션을 사용자에게 매핑하는 방법은 무엇인가요? ZTNA는 역방향 프록시 인증, 클라이언트 인증서, API 키 인증 모드를 지원하여 다양한 유형의 클라이언트(사람 사용자 및 프로그래밍 엔터티)를 인증할 수 있습니다. 다음과 같이 작동합니다:

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

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

SWG 및 CASB

SWG 구성 요소는 멀웨어, 피싱 및 안전하지 않은 사이트 방문으로부터 사용자를 보호합니다. 또한 클라이언트 애플리케이션이 감염 시 C&C 봇넷 사이트에 접속하지 못하도록 보호합니다. 또한 SWG는 조직 내 사용자의 역할과 사용자가 속한 그룹에 따라 다양한 사이트에 대한 액세스 권한을 차별적으로 제공할 수 있는 방법을 제공합니다. 또한 SWG는 다양한 분석 및 디지털 포렌식에 도움이 될 수 있는 사용자 정보와 함께 트래픽 세션 메타데이터를 기록합니다. CASB 구성 요소는 다양한 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 포털로 리디렉션하는 등 일반 HTTP 인증 체계로 이루어져야 하며, 이 포털은 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 및 ID

이 게시물에서는 ‘통합 SASE’를 통해 기업이 얻을 수 있는 다양한 이점에 대해 설명했습니다. SASE가 다양한 개별 구성 요소로 구축된 경우 사용자 인증이 여러 번 발생할 수 있으며, 이는 좋은 사용자 경험이 아닙니다. ‘통합 SASE’를 사용하면 사용자는 전체 SASE에 대해 한 번만 인증하면 됩니다. 이것이 ‘통합 SASE’의 추가적인 이점 중 하나입니다. 통합 SASE 오퍼링은 공통 통합 가시성 플랫폼에 일관되고 포괄적인 방식으로 관련 로그 메시지에 사용자 정보를 추가합니다. SDWAN 및 보안 서비스 전반에서 사용자 행동을 모니터링하여 다양한 분석 및 이상 징후 탐지에 도움을 줍니다.

요약

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

• CTO 인사이트 블로그

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