03Identity Source 종류와 비교Identity Source 종류와 비교

Identity Awareness가 다루는 신원의 종류는 네 가지입니다 — 네트워크(Networks), 사용자·사용자 그룹(Users and user groups), 컴퓨터·컴퓨터 그룹(Computers and computer groups), Remote Access 클라이언트(Remote Access Clients) 입니다. 예를 들어 IT 부서와 영업 부서 역할(Access Role)에게만 FTP로 파일 공유를 허용하는 규칙은 다음과 같은 모습이 됩니다.

Name        Source                Destination  Services  Action
─────────────────────────────────────────────────────────────
IT_dept     IT_dept / Sales_dept  *Any         ftp       accept
& Sales
File Sharing

여기서 규칙의 Source 칸에 들어간 IT_dept·Sales_dept 같은 신원은, 아래에서 설명할 Identity Source들이 게이트웨이에 알려 준 정보로 채워집니다.

게이트웨이는 신원을 두 가지 경로로 받아들입니다.

여기서 한 가지 알아 둘 점은, Identity Client의 버전이 Identity Awareness 게이트웨이의 버전과 다를 수 있다 는 것입니다. 즉 게이트웨이를 업그레이드하지 않아도 최신 클라이언트를 쓸 수 있습니다. 최신 Identity Client는 sk134312 에서 내려받습니다.

본격적으로 들어가기 전에, 게이트웨이가 다루는 신원 소스 전체를 한 줄씩 정리하면 다음과 같습니다.

각 소스의 자세한 동작은 아래에서 하나씩 풀어 봅니다.

Browser-Based Authentication 은 두 가지 취득 방식 중 하나로 신원을 얻고 사용자를 인증합니다 — Captive Portal 과 Transparent Kerberos Authentication 입니다.

Captive Portal

Captive Portal 은 웹 인터페이스로 사용자를 인증합니다. 사용자가 보호된 웹 자원에 접근하려 하면, 웹 브라우저에 뜨는 양식에 인증 정보를 입력하게 합니다. Captive Portal은 다음 조건이 모두 충족될 때 나타납니다.

여기에 더해, Transparent Kerberos Authentication 이 켜져 있지만 인증에 실패한 경우에도 Captive Portal이 나타납니다.

Captive Portal에서 사용자는 다음을 할 수 있습니다.

Captive Portal로 신원을 얻는 흐름은 다음과 같습니다. 등장 요소는 사용자(1)·Identity Awareness 게이트웨이(2)·Captive Portal(3)·Active Directory 도메인 컨트롤러(4)·내부 데이터센터(5) 입니다.

Transparent Kerberos Authentication

Transparent Kerberos Authentication 은 사용자가 따로 입력하지 않아도 웹 브라우저에서 인증 데이터를 받아 사용자를 인증합니다. 인증에 성공하면 사용자는 곧장 목적지로 갑니다. 실패하면 Captive Portal에서 직접 자격 증명을 입력해야 합니다. 흐름은 다음과 같습니다.

자세한 설정은 Identity Source — Browser-Based Authentication을 참고하세요.

AD Query 는 설정이 쉽고 클라이언트가 필요 없는(clientless) 신원 취득 도구입니다. Active Directory 통합에 기반해 동작하며, 사용자에게는 완전히 투명 합니다(사용자는 자신이 식별되고 있다는 것을 의식하지 못합니다). AD Query는 다음 두 조건이 맞을 때 동작합니다.

이 기술의 핵심은 Active Directory의 Security Event Log를 질의해, 거기서 사용자·컴퓨터와 네트워크 주소의 매핑을 뽑아내는 것입니다. 이는 Microsoft 표준 프로토콜인 WMI(Windows Management Instrumentation) 에 기반합니다. 게이트웨이는 AD 도메인 컨트롤러와 직접 통신 하므로 별도의 전용 서버가 필요 없 고, 엔드포인트 클라이언트나 Active Directory 서버에 아무것도 설치하지 않 아도 됩니다.

사용자나 컴퓨터가 네트워크 자원에 연결하면 시스템이 Security Event Log 항목을 생성하고, AD Query가 거기서 신원 정보를 뽑아냅니다. 다만 사용자가 로그아웃할 때는 Security Event Log가 생성되지 않 는데, 이는 Active Directory가 로그아웃 동작을 감지하지 못하기 때문입니다. 이 특성에서 다음 두 가지 한계 가 따라옵니다.

AD Query가 방화벽 Rule Base와 함께 동작하는 흐름은 다음과 같습니다. 등장 요소는 게이트웨이(1)·AD 도메인 컨트롤러(2)·AD 자격 증명으로 로그인하는 엔드포인트 컴퓨터(3)·네트워크 자원(4) 입니다.

자세한 설정은 Identity Source — AD Query를 참고하세요.

Identity Agent 는 사용자 엔드포인트 컴퓨터에 설치하는 전용 클라이언트 에이전트 입니다. 이 에이전트가 신원을 받아 게이트웨이에 보고하며, 관리자가 에이전트를 구성합니다. 경량 에이전트로서 SSO(Single Sign-On)로 사용자를 안전하게 인증 한다는 점이 강점입니다. 사용자 엔드포인트용 Identity Agent의 자세한 내용은 Identity Awareness Clients Administration Guide 를 참고하세요.

Terminal Server용 Identity Agent 는 Terminal Servers·Citrix XenApp·Citrix XenDesktop 서비스를 호스팅하는 Windows 기반 애플리케이션 서버에 설치 하는 에이전트입니다. 이 솔루션은 하나의 IP 주소에서 접속하는 여러 사용자 에게 Identity Awareness 정책을 집행할 수 있게 해 줍니다. Microsoft Terminal Servers·Citrix XenApp·Citrix XenDesktop을 호스팅하는 애플리케이션 서버에서는 여러 사용자가 같은 IP로 보이기 때문에, 그 트래픽을 사용자별로 통제하려면 이 기능이 꼭 필요합니다.

게이트웨이를 RADIUS Accounting(RFC 2866) 으로 동작하도록 구성하면, RADIUS Accounting Client에서 직접 사용자·컴퓨터 신원 을 받아 그 정보로 연결에 접근 권한을 적용할 수 있습니다. 전체 흐름은 이렇습니다.

구성 요소를 정리하면 다음과 같습니다.

자세한 설정은 Identity Source — RADIUS·API·Remote Access를 참고하세요.

Check Point Identity Collector 는 네트워크의 Windows 서버에 설치하는 전용 클라이언트 에이전트 입니다. 신원과 그에 연결된 IP 주소 정보를 모아 게이트웨이로 보내 신원을 집행하게 합니다. Identity Collector는 한 번에 둘 이상의 Identity Source와 연결 할 수 있으며, 이 소스들은 Query Pool 로 묶어 관리합니다. Identity Collector가 연결할 수 있는 Identity Source는 다음 세 가지입니다.

Query Pool 은 여러 Identity Source를 담는 객체입니다. 각 Query Pool은 하나의 게이트웨이에 할당 되고, Identity Collector는 Query Pool 안의 소스들에서 정보를 모아 해당 게이트웨이로 보냅니다.

예를 들어 한 환경에 Asia.com·Euro.com 두 도메인이 있다고 합시다. 관리자는 Asia 게이트웨이가 Asia.com의 도메인 컨트롤러 4대 모두에서 이벤트를 받고, Europe 게이트웨이 1·2가 Euro.com의 도메인 컨트롤러 6대 모두에서 이벤트를 받기를 원합니다. 그러면 관리자는 Query Pool 두 개 를 만듭니다 — 하나는 Asia.com의 모든 도메인 컨트롤러를 담고, 다른 하나는 Euro.com의 모든 도메인 컨트롤러를 담습니다. 그런 다음 Asia 게이트웨이는 Asia Query Pool에서, 두 Europe 게이트웨이는 Europe Query Pool에서 이벤트를 받도록 구성합니다. 자세한 내용은 Identity Awareness Clients Administration Guide 를 참고하세요.

Identity Web API 는 ForeScout CounterACT, Aruba Networks ClearPass 같은 타사(3rd party) 보안·신원 제품과 간단히 연동 할 수 있는 유연한 신원 소스입니다. 환경에 맞춰 신원을 만들고 취소하며, 사용자·IP 주소·컴퓨터에 대해 Identity Awareness 블레이드에 질의할 수 있습니다.

Identity Web API는 HTTPS 위에서 REST 프로토콜 을 씁니다. 게이트웨이는 Web API에서 받은 정보로 사용자·컴퓨터를 인증·인가합니다. 사용자·머신에 대한 연관(association)을 만들면, 게이트웨이가 그들의 그룹 멤버십과 Access Role을 계산하게 하거나, 관리자가 그 정보를 직접 제공할 수도 있습니다. Web API는 다음과 같은 상황에 유용합니다.

동작 방식은 이렇습니다. Identity Web API는 HTTPS로 JSON 요청 을 받으며, 각 JSON 요청에는 하나의 명령 또는 여러 명령의 묶음(bulk)이 들어갑니다. 각 API 명령에는 SmartConsole에서 미리 구성한 사전 공유 비밀(shared secret)이 포함 되어야 합니다. 지원하는 명령은 다음과 같습니다.

자세한 설정은 Identity Source — RADIUS·API·Remote Access를 참고하세요.

Office Mode로 동작하도록 구성된 Mobile Access 클라이언트와 IPsec VPN 클라이언트 는 게이트웨이에 접속할 때 신원을 취득합니다. 이 기능이 동작하려면 같은 게이트웨이에서 Identity Awareness 블레이드와 IPsec VPN 블레이드를 모두 켜야 합니다. 자세한 내용은 사용 중인 버전의 Mobile Access Administration Guide 와 Remote Access VPN Administration Guide 를 참고하세요.

핵심은 환경과 목적에 맞춰 하나 이상의 소스를 골라 조합 하는 것입니다. 아래 표는 각 소스의 권장 사용처(Recommended Usage) 와 환경 고려 사항(Environment Considerations) 을 정리한 것입니다.

여러 소스를 함께 쓰면 같은 사용자의 신원이 여러 경로로 겹쳐 들어올 수 있습니다. 이때 어느 신원을 우선할지는 PDP의 Identity Conciliation이 조정합니다.