목차/04. Identity Awareness 구성

04Identity Awareness 구성Identity Awareness 구성

신원 소스를 고르기 전에, Identity Awareness를 켜고 Access Role을 만들어 규칙에 쓰는 기본 골격을 잡아야 합니다. 이 장은 그 구성 흐름을 처음부터 끝까지, 즉 Identity Awareness가 동작하는 환경, 통신에 쓰는 기본 포트, 게이트웨이에서 블레이드를 켜는 마법사, Access Role 객체를 만드는 단계, LDAP 사용자에게 SID를 붙이는 법, Identity Tag로 외부 식별자를 매칭에 끌어오는 법, 만든 Access Role을 방화벽 Rule Base에서 실제로 쓰는 법, 그리고 HTTP 프록시 뒤에 숨은 사용자를 식별하는 법 까지 빠짐없이 풀어 정리합니다.

Identity Awareness 환경

Identity Awareness는 여러 신원 소스(Identity Source)와 함께 동작하도록 만들어졌습니다. 각 소스마다 권장 사용 환경(Recommended Usage) 과 함께 고려할 점(Environment Considerations) 이 다르므로, 환경에 맞춰 골라야 합니다.

AD Query

AD Query 는 Microsoft Active Directory 도메인과 함께 쓰는 대표적인 소스입니다.

권장 사용 환경 — Microsoft Active Directory Domain Controller 가 있는 대규모 환경에서 동작합니다. Windows 애플리케이션이며, 전제 조건(prerequisites)을 갖춰야 합니다. Cisco Identity Services Engine(ISE) 와도 연동되고, 로컬에서 관리(locally managed)되며, NetIQ eDirectory 서버와도 동작합니다.
고려할 점 — 도메인 컨트롤러의 보안 이벤트 로그를 읽어야 하므로 Event Log Readers 권한이 있는 자격 증명 을 요구합니다.

Identity Web API

Identity Web API 는 서드파티 보안·신원 제품과 간단히 통합 할 수 있는 유연한 신원 소스입니다.

권장 사용 환경 — ForeScout CounterACT, Aruba Networks ClearPass 같은 서드파티 보안 제품과 연동합니다. Check Point가 정식으로 지원하지 않는 인증 시스템과도 Identity Awareness를 연결할 수 있고, 사용자의 IP 주소를 빠르게 확인하는 등 시스템 관리 작업에도 씁니다.
고려할 점 — 접근성(accessibility)과 허용된 API 클라이언트 목록을 제대로 구성 해야 하며, 각 API 클라이언트마다 별도의 shared secret(공유 비밀) 을 만들어야 합니다.

Remote Access

Remote Access 는 IPsec VPN Office Mode 로 접속하는 사용자가 자연스럽게(seamlessly) 인증 되도록 해 줍니다. VPN을 통해 조직에 들어오는 사용자에게 신원 기반 보안 정책을 식별·적용할 때 씁니다. 어떤 소스를 고를지는 신원 소스 선택을 참고하세요.

게이트웨이는 어디에 두나

Identity Awareness Software Blade 는 보통 경계(perimeter) Security Gateway 에 켜고, 흔히 Application Control Software Blade 와 함께 씁니다.

내부 데이터 센터를 보호하려면, 내부 서버(데이터 센터 등) 앞에 놓인 내부(internal) Security Gateway 에도 Identity Awareness를 켤 수 있습니다. 이는 경계 게이트웨이에 더해 추가로 할 수도 있지만, 경계 게이트웨이가 반드시 필요한 것은 아닙니다 — 내부 게이트웨이만으로도 됩니다.

기본 포트 (Default Ports)

Identity Awareness 게이트웨이는 두 가지 방식으로 구성할 수 있습니다.

Bridge Mode — Security Gateway가 현재 서브넷을 그대로 쓰며, 호스트의 IP 주소를 바꾸지 않 습니다.
Route Mode — Security Gateway가 라우터처럼 동작 하며, 서로 다른 서브넷을 각 네트워크 인터페이스에 연결합니다.

이중화(redundancy)를 위해 Identity Awareness 게이트웨이를 High Availability 또는 Load Sharing 모드의 클러스터로 구성할 수 있습니다.

또한 여러 Identity Awareness 게이트웨이가 신원 정보를 공유 하도록 구성할 수 있습니다. 흔한 시나리오는 다음과 같습니다.

경계 Security Gateway와 데이터 센터 Security Gateway에 각각 Identity Awareness를 켜는 경우
둘 이상의 데이터 센터 Security Gateway에 켜는 경우
지사(branch office) 게이트웨이와 중앙(central) 게이트웨이에 각각 켜는 경우

한 대 이상의 게이트웨이가 신원을 취득해 다른 Identity Awareness 게이트웨이들과 공유할 수 있고, 더 나아가 서로 다른 Multi-Domain Server에서 관리되는 게이트웨이끼리도 신원을 공유 할 수 있습니다(Identity Sharing).

기능별 기본 포트 표

다음은 Identity Awareness 기능들이 쓰는 기본 포트입니다. 방화벽이나 중간 장비가 이 포트를 막으면 신원 취득·공유가 안 되므로 미리 확인해 두는 것이 좋습니다.

기능 (Feature)	포트 (Port)
LDAP	389
LDAP over SSL (LDAPS)	636
AD Query	135
Global Catalog	3268
Global Catalog over SSL	3269
Identity Awareness Gateway → AD	135, 389
AD → Identity Awareness Gateway	135
Enforcement Gateway	389
Identity Sharing Gateway → Enforcement Gateway	15105, 28581
Browser-Based Authentication	443
Identity Agents → Enforcement Gateway	443
RADIUS Accounting	1813

게이트웨이에서 Identity Awareness 켜기

Security Gateway에서 Identity Awareness Software Blade 를 켜면 Identity Awareness Configuration 마법사 가 열립니다. 이 마법사로는 AD Query, Browser-Based Authentication, Terminal Servers 를 신원 취득 방법으로 쓰는 한 대의 게이트웨이 를 구성할 수 있습니다. 다만 여러 대의 게이트웨이를 한꺼번에 구성하거나, Identity Agent·Remote Access 취득 방식을 구성하는 것은 마법사로 할 수 없 습니다(이들은 다른 신원 취득 방법입니다).

마법사를 끝내고 Access Control 정책을 설치하면, 시스템이 Identity Awareness를 모니터링할 준비를 마칩니다. 사용자·컴퓨터 신원 로그는 SmartConsole의 Logs & Events > Logs 탭에서 볼 수 있고, Columns Profile 을 Access Control 로 두면 이 이벤트가 보입니다.

게이트웨이에서 Identity Awareness를 켜려면 신원 소스를 고르고 Active Directory 도메인을 구성 해야 합니다.

신원 소스 고르기

SmartConsole 에 로그인합니다.
왼쪽 탐색 툴바에서 Gateways & Servers 를 클릭합니다.
Security Gateway 또는 Security Cluster 객체를 더블 클릭합니다.
Network Security 탭에서 Identity Awareness 를 선택합니다.
Identity Awareness Configuration 마법사 가 열립니다.
Methods For Acquiring Identity 페이지에서 해당하는 신원 소스를 고릅니다.
- AD Query
- Browser-Based Authentication
- Terminal Servers

Next 를 클릭하면 Integration With Active Directory 페이지가 열립니다. 여기서 Active Directory 도메인을 고르거나 새로 구성합니다.

Active Directory 도메인 구성

SmartConsole 컴퓨터가 도메인에 속해 있으면, 마법사가 도메인의 모든 도메인 컨트롤러를 가져와 자동으로 구성 합니다.

반대로 새 도메인을 만드는데 SmartConsole 컴퓨터가 그 도메인에 속해 있지 않으면, 시스템이 만드는 LDAP Account Unit 에는 직접 설정한 도메인 컨트롤러 하나만 들어갑니다. AD Query가 다른 도메인 컨트롤러에서도 데이터를 가져와야 한다면, 마법사를 끝낸 뒤 LDAP Servers 목록에 나중에 직접 추가해야 합니다.

LDAP Account Unit 객체를 보거나 편집하려면 Object Explorer(CTRL+E)를 열고 Categories 트리에서 Servers > LDAP Account units 를 선택합니다. LDAP Account Unit의 이름 규칙은 다음과 같습니다.

   <domain name>__AD

예를 들어 CORP.ACME.COM__AD 처럼 됩니다.

Select an Active Directory 목록에서 다음 중 하나를 합니다.
- 구성된 LDAP Account Unit 이 보이는 목록에서 구성할 Active Directory를 고릅니다.
- 새 도메인을 만듭니다. Active Directory를 아직 설정하지 않았다면 도메인 이름, 사용자 이름, 암호, 도메인 컨트롤러 자격 증명을 입력해야 합니다.

SmartConsole 클라이언트 컴퓨터가 AD 도메인에 속해 있으면, SmartConsole이 그 도메인을 자동으로 제안 합니다. 이 도메인을 고르면 조직 Active Directory의 모든 도메인 컨트롤러를 담은 LDAP Account Unit 이 만들어집니다.

Active Directory 자격 증명을 입력하고 Connect 를 눌러 자격 증명을 확인합니다.

(선택) Browser-Based Authentication이나 Terminal Servers를 골랐거나 Active Directory를 구성하지 않으려면, I do not wish to configure Active Directory at this time 를 선택하고 Next 를 누릅니다.

Next 를 클릭합니다. Methods For Acquiring Identity 페이지에서 Browser-Based Authentication을 골랐다면 Browser-Based Authentication Settings 페이지가 열립니다.

Browser-Based Authentication Settings 페이지에서 식별되지 않은 사용자가 향하게 될 포털의 URL 을 고릅니다.

이 목록에는 Security Gateway에 구성된 모든 IP 주소가 보이며, 기본으로 선택되는 것은 게이트웨이의 main IP 주소입니다. 같은 IP 주소를 경로(path)만 달리해 다른 포털에도 쓸 수 있습니다. 예를 들면 다음과 같습니다. - Identity Awareness Browser-Based Authentication — 192.0.2.2/connect - DLP Portal — 192.0.2.2/DLP - Mobile Access Portal — 192.0.2.2/sslvpn

기본적으로 포털 접근은 내부 인터페이스를 통해서만 가능합니다. 이를 바꾸려면 Edit 를 클릭합니다.

Next 를 클릭하면 취득 방법 요약이 담긴 Identity Awareness is Now Active 페이지가 열립니다. Terminal Servers를 골랐다면 이 페이지에 에이전트 다운로드 링크 가 포함됩니다(Identity Awareness Clients Administration Guide 참고).

Finish 를 클릭합니다.
(선택) Security Gateway 또는 Security Cluster 객체에서 Identity Awareness 페이지로 가 해당하는 설정을 구성합니다.
OK 를 클릭합니다.
Access Control Policy 를 설치합니다.

Access Role 만들기

Identity Awareness를 켰다면, 이제 Access Role(액세스 롤) 객체를 만듭니다. Access Role은 규칙의 출발지(Source)와/또는 목적지(Destination) 파라미터로 쓰며, 다음 객체들을 하나 이상 담을 수 있습니다.

Networks(네트워크)
Users and user groups(사용자/사용자 그룹)
Computers and computer groups(컴퓨터/컴퓨터 그룹)
Remote Access clients(원격 접속 클라이언트)

Access Role 객체를 만드는 절차는 다음과 같습니다.

SmartConsole에서 Object Explorer(CTRL+E)를 엽니다.
New > Users > Access Role 을 클릭하면 New Access Role 창이 열립니다.
Name 을 입력하고, Comment(선택)를 적습니다.
Networks 페이지에서 다음 중 하나를 고릅니다.
- Any network — 모든 네트워크.
- Specific networks — 더하기 [+] 기호를 누르고 네트워크를 고른 뒤 그 옆의 [+] 기호를 누르거나, 알고 있는 네트워크를 검색합니다.
Users 페이지에서 다음 중 하나를 고릅니다.
- Any user — 모든 사용자.
- All identified users — 지원되는 인증 방법으로 식별된 사용자 를 포함합니다.
- Specific users/groups — [+] 기호를 눌러 사용자를 고른 뒤 그 옆의 [+] 기호를 누르거나, 알고 있는 사용자·사용자 그룹을 검색합니다.
Machines 페이지에서 다음 중 하나를 고릅니다.
- Any machine — 모든 컴퓨터.
- All identified machines — 지원되는 인증 방법으로 식별된 컴퓨터 를 포함합니다.
- Specific machines/groups — [+] 기호를 눌러 장치를 고른 뒤 그 옆의 [+] 기호를 누르거나, 알고 있는 장치·장치 그룹을 검색합니다.

Full Identity Agents 를 쓰는 컴퓨터에 대해서는 (선택) Enforce IP Spoofing protection 을 켤 수 있습니다. 7. Remote Access Clients 페이지에서 다음 중 하나를 고릅니다. - Any Client — 모든 클라이언트. - Specific Client — 현재 허용된 클라이언트를 고르거나, 새 허용 클라이언트를 만듭니다.

예를 들어 IT 부서와 영업 부서 롤이 FTP로 파일을 공유하도록 허용 하는 규칙은, Source 에 IT_dept·Sales_dept 롤을 두고 Service 에 ftp, Action 에 accept를 두면 됩니다.

LDAP 사용자에 SID(Security Identifier) 구성

LDAP 사용자에 대한 Access Role 매칭에서는 보통 LDAP 사용자 계정의 DN(Distinguished Name) 을 지정합니다. 형식은 CN=UserName, OU=Group, DC=Domain, DC=com 처럼 됩니다.

R81부터 SID(Security Identifier) 지원 기능이 추가되었습니다. SID 는 LDAP이 보관하는 각 객체의 고유 식별자 입니다. SID 지원을 켜면, 그룹 이름·사용자 이름·도메인 이름이 바뀌어도 사용자의 SID는 그대로 이므로, Check Point Security Gateway가 그 SID로 Access Role을 계속 매칭해 정책이 이름 변경에 영향받지 않고 그대로 적용 됩니다.

Check Point Security Gateway에서 SID 지원을 켜는 절차는 다음과 같습니다.

cpstop 명령을 실행합니다.

   # cpstop

$CPDIR/tmp/.CPprofile.sh 파일을 편집합니다.
다음 줄을 추가합니다.

   export LDAP_SID=1

파일을 저장합니다.
Security Gateway를 재부팅합니다.
다음 명령을 실행합니다.

   # pdp nested status

Access Role 매칭에 Identity Tag 쓰기

Identity Tag 는 외부 식별자(external identifier)를 Access Role 매칭에 끌어오는 기능입니다. 예를 들어 Cisco Security Group Tag 나, 어떤 신원 소스든 제공하는 그 밖의 그룹을 매칭에 쓸 수 있습니다. 이 외부 식별자들은 특정 사용자·컴퓨터·그룹에 붙이는 태그처럼 동작합니다.

Identity Tag를 Access Role 매칭에 쓰는 절차는 다음과 같습니다.

1. 새 Identity Tag 만들기

a. SmartConsole에서 Objects 창 > New > More > User/Identity > Identity Tag 를 클릭합니다.

b. 객체의 이름을 입력합니다.

c. External Identifier 필드에 다음 중 하나를 입력합니다. - Cisco ISE 서버에 정의되었거나 Identity Collector 로 취득한 Cisco Security Group Name - 서드파티 제품에 정의되고 Check Point Identity Web API 로 취득한 커스텀 태그(custom tag)

d. OK 를 클릭합니다.

2. Identity Tag를 Access Role에 포함하기

a. SmartConsole에서 Objects 창 > New > More > User/Identity > New Access Role 을 클릭합니다.

b. Users 탭 또는 Machines 탭에서 Specific users/groups 를 고릅니다.

c. [+] 아이콘을 클릭합니다.

d. 왼쪽 위 모서리의 도메인 이름 버튼 을 클릭하고 Identity Tags 를 고릅니다.

e. 1단계에서 만든 Identity Tag를 고릅니다.

f. OK 를 클릭합니다.

3. 규칙에 추가하고 설치하기

이 Access Role을 Access Control Policy 규칙의 Source 또는 Destination 열에 추가합니다.
Access Control Policy 를 설치합니다.

방화벽 Rule Base에서 쓰기

Security Gateway는 패킷을 검사하고 규칙을 순서대로(sequential) 적용합니다. 연결의 패킷을 받으면 Rule Base의 첫 번째 규칙부터 대조하고, 맞지 않으면 두 번째 규칙으로 넘어가며 일치하는 규칙을 찾을 때까지 계속합니다. 명시적(explicit)·암시적(implied) 규칙 어디에도 맞지 않으면 패킷을 드롭 합니다.

Rule Base에서 Access Role 객체 다루기

Access Role을 쓰는 규칙에서는, 출발지 신원을 모르고(unknown) 트래픽이 HTTP 라면 Action 필드를 Captive Portal 로 리다이렉트하도록 구성합니다. 그러면 이 규칙이 사용자를 Captive Portal로 보냅니다.

반대로 출발지 신원을 이미 안다(known) 면, 규칙의 Action(Allow, Drop, Reject)이 즉시 적용 되고 사용자는 Captive Portal로 보내지지 않습니다. 시스템이 Captive Portal에서 자격 증명을 받고 나면, 다음 연결부터는 그 규칙을 검사할 수 있습니다.

Access Role 객체가 들어간 규칙에서 매칭은 이렇게 동작합니다.

IP 주소의 신원 데이터를 알 때
- Access Role과 맞으면 규칙이 적용되어 Action에 따라 허용·차단됩니다.
- 맞지 않으면 다음 규칙을 검사하러 넘어갑니다.
IP 주소의 신원 데이터를 모르고, 다음 조건이 모두 맞을 때
- Source 필드의 Access Role을 제외한 나머지 규칙 필드가 모두 일치 하고,
- 연결이 HTTP 이며,
- Action이 Captive Portal로 리다이렉트 하도록 설정된 경우.

세 조건이 모두 맞으면, 트래픽이 Captive Portal로 리다이렉트되어 자격 증명을 받고 매칭 여부를 확정합니다. 조건이 다 맞지 않으면 매칭되지 않고 다음 규칙을 검사합니다.

HTTP 트래픽을 Captive Portal로 리다이렉트하기

Source 열에 Access Role을 쓰는 Access Control Policy 규칙에서, Action 셀을 오른쪽 클릭하고 More 를 클릭합니다. Action Settings 창이 열립니다.
Action 필드에서 Accept, Ask, Inform 중 하나를 고릅니다.
맨 아래에서 Enable Identity Captive Portal 을 선택합니다.
OK 를 클릭합니다.
Action 셀에 Captive Portal로의 리다이렉트가 일어남이 표시됩니다.

   Accept (display Captive Portal)
   Ask (display Captive Portal)
   Inform (display Captive Portal)

Access Control Policy 를 설치합니다.

매칭 예시 Rule Base

다음은 매칭이 어떻게 동작하는지 보여 주는 방화벽 Rule Base 예시입니다.

No.	Source	Destination	Service	Action
1	Finance Dept (Access Role)	Finance Web Server	Any	Accept (display Captive Portal)
2	Admin IP Address	Any	Any	Accept
3	Any	Any	Any	Drop

예시 1 — 식별되지 않은 Finance 사용자가 HTTP로 Finance Web Server에 접근하려 하면 Captive Portal로 리다이렉트됩니다. 사용자가 자격 증명을 입력하면 Identity Awareness 게이트웨이가 Finance Web Server 접근을 허용합니다. 이 허용은 사용자를 Finance Access Role에 속한 것으로 식별 하는 규칙 1번 에 따른 것입니다.

예시 2 — 식별되지 않은 관리자가 HTTP로 Finance Web Server에 접근하려 하면, 규칙 2번 이 있음에도 일단 Captive Portal로 리다이렉트 됩니다. 관리자가 식별된 뒤에야 규칙 2번이 매칭됩니다. 관리자가 Captive Portal 리다이렉트 없이 곧장 접근하게 하려면, 규칙 1번과 2번의 순서를 바꾸거나 Access Role에 네트워크 제한(network restriction)을 추가 하면 됩니다.

HTTP 프록시 서버 뒤의 사용자 식별

조직이 사용자와 Identity Awareness 게이트웨이 사이에 HTTP 프록시 서버 를 두면, 게이트웨이는 프록시 뒤 사용자들의 신원을 볼 수 없 습니다(출발지 IP가 프록시로 보이기 때문). 그 결과 사용자 신원 기반 정책 규칙을 적용할 수 없게 됩니다.

게이트웨이가 프록시 뒤 사용자를 식별하게 하려면, 프록시 서버가 붙여 주는 X-Forward-For HTTP 헤더 를 활용합니다. 이를 위해 세 가지를 해야 합니다.

Identity Awareness 게이트웨이에서 XFF 헤더 구성
Access Control Policy Layer에서 XFF 헤더 구성
Access Control Policy Layer에서 Access Role 사용, 또는 Track 열에서 고급 옵션(Log, Detailed Log, Extended Log) 중 하나 사용

Identity Awareness 게이트웨이에서 XFF 헤더 구성

SmartConsole 에 로그인합니다.
탐색 툴바에서 Gateways & Servers 를 클릭합니다.
Identity Awareness 게이트웨이 객체를 엽니다.
General Properties 페이지 > Network Security 탭에서 Identity Awareness 가 켜져 있는지 확인합니다.
왼쪽 탐색 트리에서 Identity Awareness 옆의 [+] 를 눌러 펼치고 Proxy 페이지로 갑니다.
Detect users located behind http proxy configured with X-Forwarded-For 를 선택합니다.
- (선택) Hide X-Forwarded-For in outgoing traffic — 이 옵션을 켜면 인터넷으로 나가는 요청에 내부 IP 주소가 보이지 않 습니다.
- (선택) Trust X-Forwarded-For from known proxies only — 켠 뒤 드롭다운에서 해당 Group 객체를 고릅니다(이 Group 객체는 미리 구성해 두어야 합니다). 그러면 게이트웨이가 신뢰하는 서버에서 온 XFF 헤더만 읽습니다.

Access Control Policy Layer에서 XFF 헤더 구성

SmartConsole 에 로그인합니다.
탐색 툴바에서 Security Policies 를 클릭합니다.
Access Control 섹션에서 Policy 를 오른쪽 클릭하고 Edit Policy 를 고릅니다.
Access Control 섹션에서
- 이미 Policy Layer 가 구성돼 있으면, Policy Layer 섹션에서 클릭한 뒤 Edit Layer 를 고릅니다.
- 아직 Policy Layer가 없으면 다음과 같이 합니다.
  1. [+] 기호 > New Layer 를 클릭합니다.
  2. 레이어를 구성합니다.
  3. OK 로 Layer Editor 창을 닫습니다.
  4. OK 로 Policy 창을 닫습니다.
  5. Access Control 섹션에서 Policy 를 오른쪽 클릭하고 Edit Policy 를 고릅니다.
  6. Policy Layer 섹션에서 클릭한 뒤 Edit Layer 를 고릅니다.
Layer Editor 창에서 Advanced 페이지로 갑니다.
Proxy Configuration 섹션에서 Detect users located behind http proxy configured with X-Forwarded-For 를 선택합니다.
OK 로 Layer Editor 창을 닫습니다.
OK 로 Policy 창을 닫습니다.
Access Control Policy 를 설치합니다.

Access Control Policy Layer에서 Access Role 구성

위의 방화벽 Rule Base에서 쓰기를 참고하세요.

Track 열에서 고급 옵션 쓰기

Track 열을 오른쪽 클릭하고 More 를 클릭하면 Track Settings 창이 열립니다.