목차/12. 고급 환경 설정

12고급 환경 설정고급 환경 설정

기본 구성을 넘어, 여러 도메인이 얽힌 Active Directory 환경, 비영어 사용자 이름, 중첩 그룹, 배포 형태별 구성, 테스트 환경 검증, 신뢰받는 서버 인증서, 그리고 2단계 인증(Two-Factor Authentication) 까지 — Identity Awareness를 실제 운영 환경에 맞춰 다듬는 고급 손질을 빠짐없이 정리합니다. 원문이 절차·표·파라미터로 나열한 내용을 그대로 담되, 왜 그렇게 하는지를 함께 풀어 둡니다.

Domain Forest(서브도메인)를 위한 Identity Awareness 구성

여러 도메인이 모인 Domain Forest 환경(서브도메인이 있는 환경)에서는, 포레스트 안의 도메인(서브도메인)마다 별도의 LDAP Account Unit 을 따로 만들어야 합니다. 서로 다른 두 서브도메인의 도메인 컨트롤러를 같은 LDAP Account Unit에 함께 넣을 수는 없 습니다.

이때 Identity Awareness Configuration Wizard(구성 마법사) 를 쓰면, 지정한 하나의 서브도메인 에 대해서는 LDAP Account Unit을 자동으로 만들어 주고, 이후 손쉽게 설정을 더 붙일 수 있습니다. 하지만 Identity Awareness가 연동해야 하는 나머지 도메인은 모두 수동으로 만들어야 합니다. 수동 생성 경로는 다음과 같습니다.

포레스트의 각 도메인용 LDAP Account Unit 만들기

포레스트의 도메인마다 LDAP Account Unit을 만들 때는 다음을 지킵니다.

1. 사용자 이름은 반드시 다음 둘 중 하나여야 합니다.

  • 서브도메인의 Domain Admins 그룹에 속한 Domain administrator(도메인 관리자) 계정 — 이때 사용자 이름은 subdomain\user 형식으로 입력합니다.
  • 도메인의 Enterprise Admins 그룹에 속한 Enterprise administrator(엔터프라이즈 관리자) 계정 — 이때 사용자 이름은 domain\user 형식으로 입력합니다.

예를 들어 도메인이 ACME.COM, 서브도메인이 SUB.ACME.COM, 관리자가 John_Doe라면:

  • 관리자가 Domain administrator 이면 Username은:
  • 관리자가 Enterprise administrator 이면 Username은:

2. LDAP Server Properties 탭 > Add > Login DN 에서 login DN을 추가합니다.

3. Objects Management 탭 > Branches in use 에서 base DN을 다음과 같이 고칩니다.

변경 전: DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX
변경 후: DC=SUB_DOMAIN_NAME,DC=DOMAIN_NAME,DC=DOMAIN_SUFFIX

예를 들어 DC=ACME,DC=local 을 DC=SUB,DC=ACME,DC=local 로 바꿉니다.

PEP Identity Conciliation — Custom Configuration

여러 PDP가 같은 사용자에 대한 신원 세션을 PEP에 보낼 수 있는데, PEP는 어느 세션을 쓸지 골라야 합니다. 이를 PEP Identity Conciliation(신원 조정) 이라 합니다. 신원 출처(identity source)마다 기본 신뢰 점수(Confidence score)가 정해져 있는데, 예를 들면 다음과 같습니다.

  • Identity Web API — 15
  • Identity Collector — 10

Custom configuration(사용자 지정 구성) 에서는 PEP가 두 세션을 Confidence(신뢰도) 하나만 보는 것이 아니라, 여러 요소를 합산한 전역 점수(global score) 로 비교합니다. 고려되는 요소는 다음과 같습니다.

요소(Factor)설명
PDP Preference신원 세션을 보내온 PDP 게이트웨이를 가리킵니다. 우선순위가 더 높은 PDP에서 온 세션이 이 요소로 점수 를 얻습니다. 기본값은 "선호하는 PDP 없음" 입니다.
Time to Live세션 만료까지 남은 시간이 더 많은 세션 에 PDP가 더 높은 우선순위를 줍니다.
Full Session한 세션은 사용자 신원과 컴퓨터 신원을 모두 가지고 다른 세션은 한 종류만 가질 때, 둘 다 가진 세션이 이 요소로 점수를 얻습니다.
Connect TimeConnect 타임스탬프가 더 최신 인 세션이 더 높은 점수를 얻습니다. 이 요소는 default·basic 구성에는 없고, custom 구성에만 존재합니다.

비영어 언어 지원 (Non-English Language Support)

Identity Awareness 게이트웨이에서 영어가 아닌 사용자 이름(한글·일본어 등)을 지원 하려면, SmartConsole의 LDAP Account Unit 객체에서 파라미터 하나를 설정해야 합니다.

비영어 언어 지원을 구성하는 절차는 다음과 같습니다.

  1. SmartConsole에서 Open Object Explorer 를 엽니다(단축키 Ctrl+E).
  2. Categories 트리에서 Servers > LDAP Account Unit 을 선택하고, 해당 LDAP Account Unit을 고릅니다.
  3. LDAP Account Unit의 General 탭에서 Enable Unicode support(유니코드 지원) 가 선택되어 있는지 확인 합니다. 기본값으로 선택되어 있습니다.
  4. OK 를 클릭합니다.

중첩 그룹 (Nested Groups)

Identity Awareness 게이트웨이는 LDAP의 중첩 그룹(nested group) 을 지원합니다. 한 그룹이 다른 그룹 안에 중첩되어 있으면, 중첩된 그룹의 사용자들은 부모 그룹의 일원으로도 식별 됩니다.

예를 들어 Group_B가 Group_A의 멤버라면, 게이트웨이는 Group_B의 멤버들을 Group_A의 일부로도 식별합니다.

중첩 그룹에 쓸 수 있는 쿼리 방식은 두 가지이며, 게이트웨이에서 CLI 명령으로 전환합니다.

쿼리 방식설명게이트웨이 CLI 명령
Recursive nested groups query(재귀적 중첩 그룹 쿼리)게이트웨이가 사용자 이름으로 LDAP 서버에 쿼리를 보내면, 결과에 사용자가 속한 모든 그룹이 담깁니다. 다만 어떤 그룹이 다른 그룹에 중첩되어 있는지 알려면, 중첩 단계마다 새 쿼리를 다시 보내야 합니다. 기본으로 활성 되어 있으며 기본 중첩 깊이(nesting depth)는 20 입니다. 자세한 내용은 sk66561 참고.pdp nested_groups __set_state 1
Per-user nested groups query(사용자별 중첩 그룹 쿼리)단 한 번의 LDAP 쿼리 로, 해당 사용자의 모든 그룹을 모든 중첩 단계까지 한꺼번에 받습니다. 결과에는 포레스트의 모든 브랜치에 걸친 그룹이 포함됩니다. LDAP 서버가 사용자의 그룹을 평면 목록(flat list) 으로 보내 줍니다. 게이트웨이는 이 쿼리를 Global Catalog 포트 3268/3269 로 보냅니다. 자세한 내용은 sk134292 참고.pdp nested_groups __set_state 2

고급 구성 — IP Routing Mode와 Transparent Mode

Identity Awareness 게이트웨이를 구성하는 추가적인 방식이 두 가지 더 있습니다.

  • IP routing mode (IP 라우팅 모드)
  • Transparent mode (= Bridge Mode, 브리지 모드)
모드설명
IP routing mode일반적이고 표준적인 구성 방식입니다. 게이트웨이를 네트워크 경계(perimeter)에 둘 때 씁니다. 이 경우 게이트웨이는 IP 라우터처럼 동작 해 내부 인터페이스와 외부 인터페이스 사이의 트래픽을 양방향으로 검사하고 전달합니다. 두 인터페이스는 서로 다른 네트워크 서브넷·범위 에 위치시킵니다.
Transparent mode (Bridge Mode)게이트웨이를 IP 라우터가 아니라 Layer 2 장비 로 설치하는 방식입니다. 장점은 네트워크 인프라를 바꿀 필요가 없다 는 점으로, 게이트웨이를 같은 서브넷 안에 인라인(inline) 으로 배치할 수 있습니다. 주로 네트워크 분리(segregation)나 데이터 센터 보호 를 위해 게이트웨이를 둘 때 적합합니다.

테스트 환경 구성 (Configuring a Test Environment)

권장하는 주요 구성 요소는 다음과 같습니다.

  1. User host — Windows 사용자 호스트
  2. Check Point Security Gateway — R75.20 이상
  3. Microsoft Windows server — Active Directory, DNS, 그리고 IIS(웹 리소스)가 함께 도는 서버

배치는 보호 대상 리소스(IIS 웹 서버가 도는 Windows 서버) 앞에 게이트웨이를 두는 형태입니다. 사용자 호스트 컴퓨터는 게이트웨이를 거쳐서 보호 대상 리소스에 접근하게 됩니다.

Identity Agent 테스트 (Testing Identity Agents)

Identity Agent를 켜고 구성한 뒤, Captive Portal을 통한 Identity Agent 자가 프로비저닝(self-provisioning) 까지 시험하는 절차입니다.

  1. 브라우저를 열고 웹 리소스에 접속합니다. 리소스가 여러분을 Captive Portal로 리다이렉트 합니다.
  2. 사용자 자격 증명(credential)을 입력합니다.
  3. Captive Portal이 안내하는 대로 클라이언트를 설치 합니다.
  4. 인증 창에서 클라이언트를 통해 사용자 자격 증명을 입력합니다.
  5. 연결 상태를 점검합니다.

배포 시나리오 — Perimeter Identity Awareness Gateway

게이트웨이는 여러 형태로 구성할 수 있는데, 대표적인 것이 경계(perimeter)에 두는 게이트웨이 입니다.

보안 과제(Security Challenge) — 경계의 게이트웨이는 기업 네트워크를 드나드는 모든 트래픽의 주 관문 입니다. 내부 사용자는 매일 인터넷 리소스와 애플리케이션에 접근하는데, 모든 인터넷 애플리케이션·웹사이트가 안전한 것은 아니고 일부는 회사 정책상 제한 대상입니다. 그렇다고 내부 접근을 전부 막으면 업무상 접근이 꼭 필요한 직원들의 생산성이 떨어 집니다. Application Control 블레이드로 허용 애플리케이션 접근을 통제할 수 있지만, 사용자·컴퓨터 신원에 기반한 더 세밀한 Access Control Policy 가 필요합니다.

이때 Access Role 을 써서 Application Control과 결합한 Identity Awareness 정책을 구성하면, 지정한 사용자 그룹에게만 인터넷의 특정 애플리케이션 접근을 허용 할 수 있습니다. 그러려면 경계 게이트웨이에서 Identity Awareness를 켭니다.

구성 시나리오(Configuration Scenario)

  1. 경계 게이트웨이를 Routing Mode 로 구성합니다. ISP(인터넷)로 향하는 외부 인터페이스와 내부 기업 LAN을 향하는 내부 인터페이스를 지정해 만듭니다.
    • (선택) DMZ 서버를 보호하는 별도의 내부 인터페이스를 추가로 만들 수도 있습니다.
  2. 게이트웨이와 네트워크 사이에 NAT나 Proxy 서버가 없는지 확인 합니다.

서버 인증서 (Server Certificates)

안전한 SSL 연결을 위해, 게이트웨이는 엔드포인트 컴퓨터에 Server Certificate(서버 인증서) 를 제시해 신뢰 관계(trust)를 맺 어야 합니다.

Check Point 게이트웨이는 기본적으로 Security Management Server의 Internal Certificate Authority(ICA)가 만든 인증서 를 서버 인증서로 씁니다. 그런데 브라우저는 이 인증서를 신뢰하지 않 기 때문에, 엔드포인트가 기본 인증서로 게이트웨이에 접속하면 브라우저에 인증서 경고 가 뜹니다. 이 경고를 없애려면 관리자가 신뢰받는 인증 기관(CA)이 서명한 서버 인증서 를 설치해야 합니다.

신뢰받는 서버 인증서 발급·설치하기

경고 없이 엔드포인트에 받아들여지려면, 게이트웨이는 Entrust·VeriSign·Thawte 같은 알려진 CA가 서명한 서버 인증서 를 가져야 합니다. 이 인증서는 게이트웨이에 직접 발급되거나, 신뢰 루트 CA까지 이어지는 인증 경로(certification path)를 가진 체인 인증서(chained certificate) 일 수 있습니다.

알려진 CA가 서명한 인증서를 받는 과정은 아래 세 단계입니다.

1단계 — CSR(Certificate Signing Request) 생성

먼저 CSR(인증서 서명 요청) 을 만듭니다. 게이트웨이가 클라이언트에 대해 서버로 동작하므로, 이 CSR은 서버 인증서용입니다.

  1. 게이트웨이 명령줄에서 Expert mode 로 로그인합니다.
  2. 다음을 실행합니다.
   cpopenssl req -new -out <CSR file> -keyout <private key file> -config $CPDIR/conf/openssl.cnf

이 명령은 개인 키를 생성하며 다음과 같은 출력이 나옵니다.

   Generating a 2048 bit RSA private key
   .+++
   ...+++
   writing new private key to 'server1.key'
   Enter PEM pass phrase:
  1. 암호를 입력하고 확인합니다. 그다음 데이터를 채웁니다.
    • Common Name 필드는 필수 이며, FQDN(Fully Qualified Domain Name) 을 넣어야 합니다. 이것은 사용자가 접속하는 사이트입니다. 예: portal.example.com.
    • 나머지 필드는 모두 선택 사항입니다.
  2. CSR 파일을 신뢰받는 CA에 보냅니다. 반드시 PEM 형식의 Signed Certificate(서명된 인증서) 를 요청하고, .key 개인 키 파일은 잘 보관 합니다.

2단계 — P12 파일 생성

CA로부터 게이트웨이용 Signed Certificate를 받은 뒤, 서명된 인증서와 개인 키를 함께 담은 P12 파일 을 만듭니다.

  1. CA로부터 게이트웨이용 Signed Certificate를 받습니다. 서명된 인증서가 P12나 P7B 형식이면, CRT 확장자의 PEM(Base64 인코딩) 형식 파일로 변환 합니다.
  2. CRT 파일이 신뢰 루트 CA까지 이어지는 전체 인증서 체인(full certificate chain) 을 담고 있는지 확인합니다. 보통 서명 CA에서 인증서 체인을 받는데, 때로는 여러 파일로 쪼개져 옵니다. 서명된 인증서와 신뢰 체인이 별도 파일이면, 텍스트 편집기로 하나의 파일로 합치되, 서버 인증서가 CRT 파일의 맨 위에 오도록 합니다.
  3. 게이트웨이 명령줄에서 Expert mode 로 로그인합니다.
  4. 생성해 둔 .key 파일과 .crt 파일로 인증서를 설치합니다.
   cpopenssl pkcs12 -export -out <output file> -in <signed cert chain file> -inkey <private key file>

예시:

   cpopenssl pkcs12 -export -out server1.p12 -in server1.crt -inkey server1.key

프롬프트가 뜨면 인증서 암호를 입력합니다.

3단계 — Signed Certificate 설치

  1. SmartConsole에 로그인합니다.
  2. 왼쪽 Navigation Toolbar에서 Gateways & Servers 를 클릭합니다.
  3. Identity Awareness 게이트웨이 객체를 엽니다.
  4. 탐색 트리에서 해당하는 Software Blade 페이지를 클릭합니다.
    • Mobile Access > Portal Settings
    • Platform Portal
    • Data Loss Prevention
    • Identity Awareness > Captive Portal > Settings > Access Settings

Certificate 영역에서 Import 또는 Replace 를 클릭합니다. 5. 게이트웨이에 Access Control Policy를 설치합니다.

2단계 인증 (Two-Factor Authentication)

Check Point Captive Portal 은 웹 인터페이스로 사용자를 손쉽게 인증합니다. 사용자가 보호 대상 리소스에 접근하려 하면, 브라우저에서 자격 증명을 입력하라는 프롬프트가 뜹니다.

Captive Portal Two Factor Authentication(2단계 인증) 은 여기에 RADIUS 프로토콜을 통한 추가 챌린지-응답(challenge-response) 인증 을 더합니다. 구성하려면 아래 다섯 가지 절차를 모두 따라야 합니다.

1. SmartConsole에서 RADIUS 서버 객체 구성

  1. 왼쪽 위에서 Objects > Object Explorer 를 클릭합니다.
  2. 왼쪽 탐색 트리에서 Servers 를 클릭합니다.
  3. 툴바에서 New > More > User/Identity > RADIUS 를 클릭합니다.
  4. RADIUS 서버 이름을 입력합니다.
  5. Host 필드에 RADIUS 서버 IP 주소가 담긴 호스트 객체를 추가합니다. 아직 호스트가 정의되지 않았으면 별 모양 아이콘 > Host 를 눌러 호스트의 Name 과 IP Address 를 입력합니다.
  6. Version 필드에서 알맞은 RADIUS 버전을 고릅니다.
  7. Protocol 필드에서 알맞은 인증 프로토콜을 고릅니다.
  8. OK 를 클릭하고 Object Explorer 창을 닫습니다.
  9. Access Control Policy를 설치합니다.

2. SmartConsole에서 Captive Portal 구성

  1. 왼쪽 Navigation Toolbar에서 Gateways & Servers 를 클릭합니다.
  2. Security Gateway 객체를 더블 클릭합니다.
  3. General Properties 창에서 Identity Awareness Software Blade를 선택합니다. Identity Awareness Configuration Wizard 가 열립니다.
  4. Methods For Acquiring Identity 화면에서 Browser-Based Authentication 을 선택하고 Next 를 클릭합니다.
  5. Integration With Active Directory 화면에서 I do not wish to configure an Active Directory at this time 를 선택하고 Next 를 클릭합니다.
  6. Browser-Based Authentication Settings 화면에서 접근성(accessibility) 설정을 구성하고 Next 를 클릭합니다.
  7. Finish 를 눌러 마법사를 닫습니다.
  8. 왼쪽 탐색 트리에서 Identity Awareness 를 클릭합니다.
  9. Browser-Based Authentication 체크박스 옆의 Settings 를 클릭합니다.
  10. Authentication Settings 영역에서 Edit 를 클릭합니다.
  11. Authentication Method 영역에서 RADIUS 를 선택하고, 앞서 만든 RADIUS 서버 객체를 고릅니다.
  12. User Directories 영역에서, 사용자 그룹을 LDAP 서버에서 직접 가져온다면 LDAP users 옵션을 선택하고, 아니면 이 옵션을 해제합니다.
  13. OK 를 눌러 게이트웨이 객체 속성을 닫습니다.
  14. Access Control Policy를 설치합니다.

3. Legacy SmartDashboard에서 generic 사용자 프로필 구성

  1. SmartConsole에서 Manage & Settings > Blades 를 클릭합니다.
  2. Mobile Access 영역에서 Configure in SmartDashboard 를 클릭합니다. Legacy SmartDashboard 가 열립니다.
  3. 왼쪽 아래 창에서 Users 를 클릭합니다.
  4. 왼쪽 아래 창의 마지막 폴더 아래 빈 공간을 오른쪽 클릭하고 New > External User Profile > Match all users 를 선택합니다.
  5. External User Profile 속성을 구성합니다.
    • General Properties 페이지 — External User Profile name 필드는 기본 이름 generic* 그대로 두고, Expiration Date 필드에 알맞은 날짜를 설정합니다.
    • Authentication 페이지 — Authentication Scheme 드롭다운에서 알맞은 옵션을 선택·구성합니다.
    • Location, Time, Encryption 페이지 — 필요한 다른 설정을 구성합니다.
    • OK 를 클릭합니다.
  6. 상단 툴바에서 Update(또는 Ctrl+S)를 클릭합니다.
  7. SmartDashboard를 닫습니다.
  8. SmartConsole에서 Access Control Policy를 설치합니다.

4. LDAP 사용자·그룹 기반 Access Role 구성

  1. LDAP 서버용 LDAP Account Unit 객체가 있는지 확인합니다.
    • SmartConsole 왼쪽 위에서 Objects > Object Explorer 로 가서 왼쪽 트리의 Servers 를 클릭합니다.
    • 없으면 툴바에서 New > More > User/Identity > LDAP Account Unit 을 눌러 객체를 구성합니다.
  2. LDAP 사용자·LDAP 그룹에 기반한 Access Role을 구성합니다.
  3. Access Control Policy를 설치합니다.

5. RADIUS 그룹 기반 Access Role 구성

a. Global Properties 구성

  1. SmartConsole에서 Menu > Global properties 로 갑니다.
  2. 왼쪽 트리에서 Advanced > Configure 를 클릭합니다. Advanced Configuration 창이 열립니다.
  3. 왼쪽 트리에서 SecuRemote/SecureClient 를 클릭합니다.
  4. add_radius_groups 를 선택합니다.
  5. OK 를 눌러 Advanced Configuration 창을, 다시 OK 를 눌러 Global Properties 창을 닫습니다.

b. 내부 사용자 그룹 구성

  1. 왼쪽 위에서 Objects > Object Explorer 를 클릭합니다.
  2. 왼쪽 트리에서 Users 를 클릭합니다.
  3. 툴바에서 New > User > User Group 을 클릭합니다.
  4. RADIUS 서버의 각 RADIUS 그룹 <grp> 마다, RAD_<grp> 이름의 내부 사용자 그룹 을 만듭니다(대소문자 구분). 예를 들어 RADIUS 그룹 MyGroup 에는 내부 사용자 그룹 RAD_MyGroup 을 만듭니다.
  5. Object Explorer 창을 닫습니다.

c. 앞 단계에서 만든 내부 사용자 그룹으로 Access Role을 구성합니다.

d. Access Control Policy를 설치합니다.

Command Line Reference

전체 명령은 R82 CLI Reference Guide 를 참고하세요. 아래는 자주 쓰는 일부 명령에서 등장하는 용어입니다.

용어설명
PDPIdentity Awareness Policy Decision Point. 신원을 수집·공유 하는 책임을 진 게이트웨이입니다.
PEPIdentity Awareness Policy Enforcement Point. 네트워크 접근 제한을 시행 하는 게이트웨이로, PDP에서 받은 신원 데이터를 바탕으로 결정합니다.
ADLOGActive Directory에서 사용자·컴퓨터 같은 엔티티의 신원을 획득 하는 모듈입니다. AD Query를 켠 게이트웨이(정책을 시행하고 신원을 로깅), 그리고 Log Server(신원을 로깅)에서 동작합니다. adlog 는 ADLOG 기능을 제어·모니터링하는 명령줄 프로세스로, 사용자 상태 제어와 문제 해결·모니터링에 쓰입니다.

PEP와 PDP 프로세스는 시스템의 핵심 구성 요소로, 이들을 통해 관리자가 사용자 접근과 네트워크 보호를 통제합니다.