목차/11. 연동 인증 — AD Proxy·SAML·Azure AD

11연동 인증 — AD Proxy·SAML·Azure AD연동 인증 — AD Proxy·SAML·Azure AD

신원을 회사가 이미 쓰고 있는 디렉터리나 클라우드 ID 서비스와 연동 해서 인증·인가에 활용하는 방법을 한자리에 모았습니다. 크게 세 갈래입니다. 첫째는 게이트웨이가 Active Directory에 대한 프록시 역할 을 맡아 관리 서버가 AD에 직접 닿지 못하는 환경에서도 사용자·그룹을 끌어오게 하는 AD Proxy 구성입니다. 둘째는 표준 SAML 프로토콜로 외부 ID 공급자(IdP) 에 인증을 위임하는 SAML Identity Provider 구성입니다. 셋째는 Microsoft 클라우드인 Azure AD 를 인증·인가에 함께 쓰는 구성입니다. 원문이 절차·표·레지스트리 명령·주의사항으로 나열한 내용을 하나도 빠뜨리지 않고, 왜 그렇게 하는지를 함께 풀어 정리합니다.

게이트웨이를 Active Directory 프록시로 (AD Proxy)

Security Management Server가 현재 Active Directory 환경에 직접 연결되어 있지 않은 상황이 있습니다. 이때 Identity Awareness Gateway 를 Active Directory Proxy 로 동작시키면, 게이트웨이가 AD에 닿는 통로가 되어 줍니다. 그러면 Access Role 객체 안에서 Identity Awareness User Picker 로 AD의 사용자·그룹을 골라 넣을 수 있게 됩니다(Access Role 객체를 룰 베이스에서 다루는 방법은 별도 장 참고).

AD Proxy 기능의 제약과 전제 — 반드시 먼저 확인

이 기능은 쓸 수 있는 범위가 분명히 제한되어 있습니다. 구성을 시작하기 전에 다음을 모두 확인하세요.

  • Microsoft Active Directory에서만 동작 합니다. 다른 디렉터리 제품은 지원하지 않습니다.
  • Access Role 객체의 user picker만 지원 합니다. 그 밖의 설정 — Identity Awareness Configuration wizard, Client certificate(클라이언트 인증서), Legacy user picker, Fetch branches(브랜치 가져오기), Fetch fingerprint(지문 가져오기), LDAP tree — 는 지원하지 않 습니다.
  • Security Gateway가 R80.20 이상, Gaia OS 에서 동작할 때만 됩니다.
  • VSX 환경에서는 VSX Gateway/VSX Cluster(즉 VS0의 컨텍스트)와 같은 도메인에 속한 Virtual System만 지원합니다. VS0와 다른 도메인 에 속한 Virtual System은 지원하지 않습니다.
  • 중앙 관리되는 Quantum Spark Appliance(Gaia Embedded OS) 는 모든 모델 에서 지원하지 않습니다.
  • Scalable Platform(41000 / 44000 / 61000 / 64000) 은 지원하지 않습니다.
  • DAIP 게이트웨이 와 외부에서 관리되는(Externally managed) 게이트웨이 도 지원하지 않습니다.
  • Multi-Domain Security Management 환경에서는 Global SmartConsole에서 구성된 Account Unit 에 대해서는 이 기능을 쓸 수 없습니다.

사용할 수 있는 연결 방식(connection type) 은 두 가지입니다.

연결 방식설명
Clear관리 서버와 게이트웨이 사이는 SIC로 암호화 됩니다. 다만 게이트웨이에서 Active Directory 서버로 가는 연결은 암호화되지 않 습니다.
SSLActive Directory 도메인 컨트롤러가 SSL을 허용 해야 합니다.

마지막으로, Account Unit을 구성할 때 쓰는 계정에 필요한 Active Directory 권한 은 용도에 따라 다릅니다.

  • user picker 기능을 쓰려면 그 계정이 LDAP 쿼리를 수행할 권한 을 가져야 합니다.
  • Security Gateway 기능에 필요한 권한은 게이트웨이에서 쓰는 신원 소스(identity source)에 따라 달라 집니다.
  • 도메인 관리자(domain admin) 자격 증명 없이 AD Query로 신원을 얻으려면 sk93938 을 참고하세요.

SmartConsole에서 AD Proxy 게이트웨이 구성하기

전체 절차는 도메인 컨트롤러마다 Host 객체를 만들고, 정책을 설치한 뒤, LDAP Account Unit 객체를 정교하게 구성하는 순서입니다.

1단계 — 도메인 컨트롤러마다 Host 객체 만들기. AD 환경의 Active Directory Domain Controller마다 새 Host 객체를 만듭니다.

  1. 왼쪽 상단에서 Objects > New Host 를 클릭합니다.
  2. 객체 이름과 IP 주소를 설정합니다.
  3. OK 를 클릭합니다.

2단계 — 정책 설치. Identity Awareness Gateway에 Access Control Policy 를 설치합니다.

3단계 — LDAP Account Unit 객체 구성. 이 단계가 핵심입니다. Object Explorer를 열어 새 Account Unit을 만들고 각 탭을 채웁니다.

  1. 왼쪽 상단에서 Objects > Object Explorer 를 클릭하면 Object Explorer 창이 열립니다.
  2. 왼쪽 탐색 트리에서 Servers 를 클릭합니다.
  3. 툴바에서 New > More > User/Identity > LDAP Account Unit 을 클릭하면 LDAP Account Unit Properties 창이 열립니다.
  4. 창의 각 탭에서 속성을 구성합니다.

각 탭에서 무엇을 채우는지 자세히 보겠습니다.

General 탭

  • Name 필드에 객체 이름을 적습니다(예: mycompany.com_LDAP_ACC_UNIT).
  • Profile 필드에서 Microsoft_AD 를 선택합니다.
  • Prefix 필드에 도메인 이름을 적습니다(예: mycompany.com).
  • Account Unit usage 섹션에서 모든 옵션을 선택 합니다.
  • Additional configuration 섹션에서 Enable Unicode support 를 선택합니다.

Servers 탭

  1. Add 를 클릭하면 LDAP Server Properties 창이 열립니다.
  2. General 탭으로 갑니다.
  3. Host 필드에서 1단계에서 이 도메인 컨트롤러용으로 만든 Host 객체를 선택합니다.
  4. Username 필드에 이 도메인 컨트롤러의 사용자 이름을 적습니다(예: John.Smith).
  5. Login DN 필드에 그 사용자의 distinguished name(DN) 을 적습니다(RFC1779 참고).
  6. Password 와 Confirm password 에 암호를 두 번 입력합니다.
  7. OK 를 눌러 LDAP Server Properties 창을 닫습니다.

Objects Management 탭

  • Server to connect 필드에서 1단계에서 만든 Host 객체를 선택합니다.
  • 브랜치(branch)를 수동으로 추가 합니다. > 참고 — 이 기능은 브랜치 자동 가져오기(fetching on branches)를 지원하지 않 습니다. 그래서 손으로 넣어야 합니다.
  • 브랜치 이름은 Login DN에서 DC= 로 시작하는 접미부 입니다. 예를 들어 Login DN이

라면 브랜치 이름은 DC=mycompany,DC=com 입니다. - Management Server needs proxy to reach AD server 를 선택합니다. 이것이 바로 게이트웨이를 프록시로 쓰겠다는 핵심 설정입니다. - Proxy through 필드에서 AD 서버로 가는 경로를 가진 Security Gateway / Security Cluster를 선택합니다. - 그 밖에 필요한 설정을 마저 구성합니다.

(선택) Authentication 탭

  • Use common group path for queries 를 해제 합니다.
  • Allowed authentication schemes 섹션에서 모든 옵션을 선택 합니다.
  • Users' default values 섹션에서:
    • Use user template 을 해제 합니다.
    • Default authentication scheme 을 Check Point Password 로 선택합니다.

마지막으로 OK 를 눌러 새 LDAP Account Unit 객체 구성을 마치고 창을 닫습니다.

(선택) 도메인 컨트롤러와의 LDAP 연결을 암호화하기

게이트웨이에서 도메인 컨트롤러로 가는 LDAP 연결을 SSL로 암호화 하고 싶다면 다음을 따릅니다. 핵심은 AD 서버의 인증서 지문(fingerprint) 을 게이트웨이에서 직접 뽑아 SmartConsole에 등록하는 것입니다.

  1. 앞서 3단계에서 만든 LDAP Account Unit 객체를 엽니다.
  2. Servers 탭으로 갑니다.
  3. LDAP Server 객체를 선택하고 Edit 를 클릭합니다.
  4. Encryption 탭으로 갑니다.
  5. Use Encryption (SSL) 를 선택합니다.
  6. Verify that server has the following Fingerprints 필드에, Identity Awareness Gateway에서 얻은 AD 서버 지문 을 입력합니다(아래 방법으로 얻습니다).
  7. OK 를 눌러 LDAP Account Unit Properties 창까지 모두 닫습니다.

게이트웨이에서 AD 서버 지문 얻기. 다음 순서로 진행합니다.

  1. 내 컴퓨터에서 일반 텍스트 편집기를 엽니다.
  2. 아래의 한 줄짜리 긴 명령을 편집기에 복사해 붙여 넣습니다.
   cpopenssl s_client -connect 192.168.1.2:636 2>&1 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | cpopenssl x509 -noout -md5 -fingerprint
  1. 편집기에서 192.168.1.2 를 내 Active Directory 도메인 컨트롤러의 IP 주소 로 바꿉니다.
  2. Security Gateway 명령줄에 접속합니다.
  3. Expert mode 로 로그인합니다.
  4. VSX Gateway라면, AD 도메인 컨트롤러와 통신 가능한 Virtual System의 컨텍스트로 전환 합니다.
  5. Security Gateway(또는 Virtual System)와 AD 도메인 컨트롤러 사이에 연결이 되는지 확인합니다.
  6. 편집기에서 고친 명령을 게이트웨이 콘솔에 붙여 넣고 Enter 를 누릅니다. 그러면 MD5 Fingerprint 가 표시됩니다. 예:
   MD5 Fingerprint=0B:84:D1:28:A5:19:6A:4D:24:57:72:5A:32:9B:2D:4D
  1. = 기호 뒤에 표시된 지문 번호를 복사합니다.
  2. 복사한 지문을 SmartConsole의 Verify that server has the following Fingerprints 필드에 붙여 넣고 OK 를 누릅니다.

게이트웨이에서 Identity Awareness 블레이드 켜기

Account Unit까지 만들었으면, 게이트웨이에서 Identity Awareness를 활성화합니다.

  1. SmartConsole 왼쪽 Navigation Toolbar에서 Gateways & Servers 를 클릭합니다.
  2. Security Gateway 객체를 편집합니다.
  3. Identity Awareness Software Blade 를 선택합니다.
  4. Identity Awareness Configuration wizard가 열리면 Cancel 을 클릭합니다(이 기능은 wizard를 지원하지 않으므로 마법사를 닫습니다).
  5. Identity Awareness가 선택되어 있는지 확인합니다.
  6. 왼쪽 탐색 트리에서 Identity Awareness 로 갑니다.
  7. Identity Sources 섹션에서 필요한 옵션을 선택·구성합니다.
  8. OK 를 클릭합니다.
  9. Access Control Policy 를 설치합니다.

중첩 그룹(Nested Groups) 쿼리 방식 조정하기

AD 그룹 안에 또 그룹이 들어 있는 중첩 그룹 환경에서는, 게이트웨이가 사용자의 그룹 멤버십을 어떻게 조회할지 방식을 고를 수 있습니다. LDAP 통신에는 3268, 3269, 389, 636 포트 중 하나를 씁니다. Security Gateway에서 다음 CLI 명령으로 상태를 설정합니다.

Per-user nested groups query (사용자 단위 중첩 그룹 쿼리) — 한 번의 LDAP 쿼리 로 해당 사용자의 모든 그룹을 중첩 단계 전부 포함 해 받아 옵니다. 결과에는 LDAP Account Unit에 지정한 브랜치의 그룹이 포함되며, LDAP 서버가 사용자의 그룹을 평평한 목록(flat list) 으로 돌려줍니다.

pdp nested_groups __set_state 3

Multi per-group nested groups query (그룹별 중첩 그룹 쿼리) — 게이트웨이가 사용자 이름과 그룹을 함께 담은 LDAP 쿼리를 보내면, LDAP 서버가 그 사용자가 해당 그룹의 멤버인지 아닌지 만 알려 줍니다.

pdp nested_groups __set_state 4

중첩 그룹의 현재 구성 상태는 다음 명령으로 확인합니다.

pdp nested_groups status

SAML Identity Provider 연동

이 절은 제3자 ID 공급자(3rd party Identity Provider) 를 SAML 프로토콜 로 연동해, Identity Awareness Gateway(Captive Portal)를 Service Provider 로 두고 인증하는 방법을 설명합니다.

용어를 먼저 정리하면, Identity Provider(IdP) 는 신원 정보를 만들고 유지·관리하며 인증 서비스를 제공 하는 시스템 엔티티이고, Service Provider(SP) 는 IdP가 인증한 사용자에게 서비스를 제공 하는 시스템 엔티티입니다. 여기서는 게이트웨이가 SP 역할을 합니다.

SAML 인증 흐름

원문 예시에서는 서비스가 google.com, Service Provider가 Identity Awareness Gateway(Captive Portal), Identity Provider가 Okta입니다. 흐름은 이렇습니다.

  1. 최종 사용자가 클라이언트 브라우저로 서비스를 요청합니다(예: 주소창에 google.com 입력).
  2. Identity Awareness Gateway가 자신의 Captive Portal 을 엽니다.
  3. 게이트웨이가 사용자의 신원을 얻기 위해 브라우저를 제3자 IdP 포털(예: Okta)로 리디렉션 합니다.
  4. IdP 포털이 열리고 사용자가 인증합니다. IdP는 디지털 서명된 SAML assertion 을 만들어 사용자 브라우저로 돌려보냅니다.
  5. 사용자 브라우저가 그 SAML assertion을 게이트웨이로 전달합니다.
  6. 게이트웨이가 SAML assertion을 검증 하고, 통과하면 요청한 서비스를 제공합니다(예: 브라우저에 google.com이 열림).

SAML 구성 절차

1. Identity Awareness 블레이드 구성. 먼저 Identity Awareness Software Blade를 활성화하고("Getting Started with Identity Awareness" 참고), Identity Awareness Captive Portal 을 구성합니다("Configuring Browser-Based Authentication" 참고).

2. External User Profile 객체 구성. External User Profile은 IdP가 인증한 모든 사용자를 대표 하는 객체입니다.

  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 를 설치합니다.

3. Identity Provider 객체 구성. 이 단계가 SAML 연동의 중심입니다.

  1. SmartConsole의 Gateways & Servers 뷰에서 New > More > User/Identity > Identity Provider 를 클릭하면 New Identity Provider 창이 열립니다.
  2. Data required by the SAML Identity Provider 섹션에서 다음을 설정합니다.
    • Gateway 필드 — SAML 인증을 수행할 Security Gateway를 선택합니다.
    • Service 필드 — Identity Awareness 를 선택합니다.
    • 위 두 값을 정하면 SmartConsole이 다음 필드를 자동 생성 합니다.
자동 생성 필드의미
Identifier (Entity ID)Service Provider(여기서는 Security Gateway)를 고유하게 식별 하는 URL
Reply URLSAML assertion이 전송될 URL
  1. IdP 웹사이트에서 SAML 애플리케이션을 구성 합니다.
  • IdP의 안내를 따릅니다.
    • New Identity Provider 창의 Identifier (Entity ID) 와 Reply URL 값을 반드시 제공 해야 합니다. SmartConsole에서 이 값들을 복사해 IdP 웹사이트의 해당 필드에 붙여 넣습니다.
  • IdP가 인증된 사용자 이름을 이메일 형식(alias@domain) 으로 보내도록 구성합니다.
    • (선택) 사용자가 속한 IdP의 그룹을 받고 싶다면, IdP가 그룹 이름을 group_attr 라는 속성의 값 으로 보내도록 구성합니다.
  • 구성 과정의 끝에서 IdP로부터 다음 정보를 반드시 받아 둡니다.
받을 정보의미
Entity ID애플리케이션을 고유하게 식별하는 URL
Login URL애플리케이션에 접근하는 URL
Certificate게이트웨이와 IdP가 주고받는 데이터를 검증하는 인증서
  1. New Identity Provider 창의 Data received from the SAML Identity Provider 섹션에서 다음 중 하나 를 구성합니다.
    • Import the Metadata File 을 선택해 IdP가 준 metadata 파일을 업로드하거나,
    • Insert Manually 를 선택해 Entity ID 와 Login URL 을 수동으로 붙여 넣고 Certificate File 을 업로드합니다.

4. Identity Provider를 인증 방식으로 지정. 만든 IdP 객체를 실제 인증 수단으로 연결합니다.

  1. SmartConsole에서 Gateways & Servers 패널을 클릭합니다.
  2. Security Gateway 객체를 엽니다.
  3. 왼쪽 트리에서 Identity Awareness 를 클릭합니다.
  4. Browser-Based Authentication 옆의 Settings 를 클릭합니다.
  5. Authentication Settings 섹션에서 Edit 를 클릭합니다.
  6. Authentication Method 섹션에서 Identity Provider 를 선택합니다.
  7. 초록색 [+] 버튼을 클릭해 SAML Identity Provider 객체를 선택합니다.
  8. OK 를 클릭합니다.

5. (선택) 그룹 인가(Group Authorization) 구성. 두 부분으로 나뉩니다.

Part A — Identity Tag 구성. SAML 애플리케이션에 정의한 각 그룹마다 SmartConsole에 대응하는 Identity Tag 객체 를 만듭니다. Identity Tag의 값은 제공된 그룹 값 또는 Object ID와 정확히 같아야 합니다.

Part B — 그룹 인가 동작(behavior) 구성.

인가는 두 종류의 그룹을 다룹니다 — IdP가 보내는 Identity Provider groups, 그리고 SmartConsole에 구성된 User Directory에서 받는 Internal groups 입니다. 게이트웨이가 둘을 어떻게 취급할지 네 가지 동작 중에서 고릅니다.

옵션 이름숫자 값게이트웨이의 인가 동작
Only SAML Groups0IdP 그룹만 고려, 내부 그룹은 무시합니다.
Prefer SAML Groups1기본값. IdP 그룹을 우선합니다. IdP에 외부 그룹이 없으면 Ignore SAML Groups 처럼 동작합니다.
Union with SAML Groups2내부 그룹과 IdP 그룹을 모두 고려 합니다.
Ignore SAML Groups3내부 그룹만 고려, IdP 그룹은 무시합니다.

인가 동작 조회. 게이트웨이/각 Cluster Member에서 현재 설정을 두 가지 방법으로 볼 수 있습니다.

  • Expert mode에서 Check Point Registry 값을 직접 확인:
  ckp_regedit -p SOFTWARE/Checkpoint/Ex_Groups "<Realm Name>"
  • Expert mode 또는 Gaia Clish에서:
  pdp idp groups status

인가 동작 설정. 마찬가지로 두 가지 방법이 있습니다.

  • Expert mode에서 Registry 값을 변경:
  ckp_regedit -a SOFTWARE/Checkpoint/Ex_Groups "<Realm Name>" -n {0 | 1 | 2 | 3}
  • Expert mode 또는 Gaia Clish에서:
  pdp idp groups set {only | prefer | union | ignore}

6. Access Control Policy 설치. SmartConsole에서 Install Policy 를 클릭하고, 적용할 정책을 고른 뒤 Access Control 을 선택하고 Install 을 클릭합니다.

Azure AD로 인가하기

Azure Active Directory(Azure AD) 는 Microsoft Azure에서 동작하는 애플리케이션을 위한 클라우드 기반 신원·접근 관리 서비스 입니다. SAML로 사용자 인증을 처리하면서, Azure AD 엔티티(그룹 등)로 회사 자원 접근을 제어 하는 인가에 활용할 수 있습니다.

직접 접근이 안 되면 프록시 서버 를 구성합니다. 대상에 따라 위치가 다릅니다.

  • 관리 서버에 직접 접근이 없을 때 — 브라우저로 Gaia Portal에 로그인하고, 왼쪽 트리에서 System Management > Proxy 로 가서 Use proxy server 를 선택하고 프록시 설정을 입력한 뒤 OK, 그리고 SmartConsole 세션을 Publish 합니다.
  • PDP로 동작하는 게이트웨이에 직접 접근이 없을 때 — SmartConsole에서 Global Properties 를 열고, 왼쪽 트리에서 Proxy 를 클릭한 뒤 Use proxy server 를 선택하고 프록시 설정을 입력하고 OK, 그리고 세션을 Publish 합니다.

Azure AD 구성은 두 부분 으로 나뉩니다 — Part 1은 Microsoft Azure Portal 에서, Part 2는 Check Point SmartConsole 에서 합니다.

Part 1 — Microsoft Azure Portal에서 구성

1. Azure 애플리케이션 구성.

  1. https://portal.azure.com/ 에서 Azure 계정에 로그인하고, 오른쪽 위 사용자 이름을 클릭해 디렉터리가 올바른지 확인합니다. > 참고 — 사용자 한 명과 그룹 하나는 반드시 정의되어 있어야 합니다.
  2. 지정 사용자 그룹을 만듭니다 — 왼쪽 메뉴에서 Azure Active Directory 를 선택하고 Users 를 클릭, Overview 창에서 목록의 사용자를 선택한 뒤 Home 을 클릭합니다.
  3. Enterprise Applications 를 선택합니다.
  4. New Application > Non-gallery application 을 클릭합니다.
  5. Add your own application 창에서 애플리케이션 이름을 입력하고(예: checkpoint) Add 를 클릭합니다.
  6. 애플리케이션 Overview 창에서 애플리케이션을 클릭하고 App registrations 옵션을 선택합니다.
  7. Owned applications > checkpoint 를 클릭합니다.
  8. 다음 두 값을 복사해 저장 합니다.
    • Application (client) ID
    • Directory (tenant) ID
  9. Certificates & Secrets > New client secret 으로 가서 다음을 설정합니다.
    • Description — 자유 텍스트 설명(예: Check Point).
    • Expires — 적절한 만료일.
  10. Add 를 클릭합니다.
  11. client secret 값을 복사해 저장 합니다. > 참고 — 이 값은 다른 작업을 하거나 이 블레이드를 떠나면 다시 볼 수 없 습니다. 즉시 저장하세요.

2. Azure 애플리케이션에 SAML 단일 로그인(SSO) 구성.

  1. Home 을 클릭하고 메뉴에서 Azure Active Directory 를 선택합니다.
  2. Enterprise applications 를 클릭하고 All applications 로 갑니다.
  3. 내 애플리케이션을 선택하면 Overview 창이 열립니다.
  4. Single Sign-On 을 클릭합니다.
  5. SSO 방식으로 SAML 을 선택합니다.
  6. Set up Sign-On with SAML 창에서 User Attributes & Claims 섹션으로 가서 연필 아이콘을 클릭해 claim을 편집합니다.
  7. Required claim 섹션에서 Unique User Identifier (Name ID) 를 클릭합니다.
  8. Manage claim 창에서:
    • Attribute 옵션을 Select 합니다.
    • Source Attribute 드롭다운에서 user.localuserprincipalname 를 선택합니다.
  9. Save 로 claim을 저장하고 창을 닫습니다.
  10. SAML Signing Certificate 페이지로 돌아와 Federation Metadata XML 파일의 Download 를 클릭해 내려받습니다. > 참고 — Azure에는 로그인한 채로 두고 다음 단계에서 다시 돌아옵니다.

3. 애플리케이션 등록(Registering).

  1. App Registrations > New registration 을 클릭합니다.
  2. Owned applications 를 클릭합니다.
  3. 내 애플리케이션을 선택하고 Register 를 클릭합니다.
  4. API permissions > Add a permission 을 클릭하고 다음 권한을 선택합니다.
    • Microsoft Graph
    • Device.Read.All
    • Group.Read.All
    • User.Read.All
  5. Add permissions > Configured permissions > Grant admin consent 로 앱의 API 권한을 승인하고 Yes 를 클릭하면, 애플리케이션이 부여된 권한을 갖게 됩니다.

Part 2 — Check Point SmartConsole에서 구성

1. Azure 객체 구성. 두 가지 방법 중 하나를 씁니다.

방법 ① IDA wizard로 Azure AD 구성

  1. SmartConsole에서 Gateway를 열고 Identity Awareness 를 클릭합니다.
  2. Identity Awareness Configuration wizard에서 Browser-Based Authentication 옵션만 선택합니다.
  3. Next 를 클릭합니다.
  4. Select Active Directory 드롭다운에서 Create new Azure Active Directory 를 선택합니다.
  5. Part 1에서 만든 값을 입력합니다.
    • Name — 애플리케이션 이름.
    • Application ID — Service Principal의 Application ID(UUID 형식 [xxxxxxx-xxxx-xxxx-xxxxxx]).
    • Application Key — Service Principal용으로 만든 Client Secret.
    • Directory ID — Service Principal의 Directory ID(UUID 형식). > 중요 — 같은 Directory ID로 여러 Azure AD 객체를 지정 구성하지 마세요.
  6. Test Connection 을 클릭합니다.
  7. 연결이 활성화되면 Next > Next > Finish 를 클릭합니다. 이제 Users/Identities 메뉴에서 새로 만든 Azure AD를 고를 수 있습니다.
  8. SmartConsole 세션을 Publish 합니다.

방법 ② Objects bar에서 새 서버로 구성

  1. SmartConsole에서 New > More > User/Identity > Azure AD 를 클릭하면 New Azure AD 창이 열립니다.
  2. Service Principal Authentication 섹션에서 Part 1의 값을 입력합니다.
    • Name — 애플리케이션 이름.
    • Application ID — Service Principal의 Application ID(UUID 형식).
    • Application Key — Service Principal용 Client Secret.
    • Directory ID — Service Principal의 Directory ID(UUID 형식).
  3. Test Connection 을 클릭합니다.
  4. SmartConsole 세션을 Publish 합니다.

2. Azure 디렉터리로 Access Role 만들기. 이제 Azure 신원을 룰에 쓸 수 있도록 Access Role을 만듭니다.

  1. 객체 트리에서 New > More > User/Identity > Access Role 을 클릭합니다.
  2. [+] 를 클릭해 새 Access Role을 추가합니다.
  3. New Access Role 창에서 Name 을 입력하고, (선택) Comment 와 Color 를 지정합니다.
  4. Users 창에서 다음 중 하나를 선택합니다.
    • Any user — 모든 사용자.
    • All identified users — 지원되는 인증 방식으로 식별된 모든 사용자(내부 사용자, AD 사용자, LDAP 사용자 포함).
    • Specific users/groups — Azure Active Directory를 선택해 목록에서 사용자나 사용자 그룹을 고릅니다.
  5. OK 를 클릭합니다.
  6. SmartConsole 세션을 Publish 합니다.
  7. 만든 Azure Access Role을 정책의 룰에 추가해 사용합니다.

정리하면, 온프레미스 AD는 AD Query·AD Proxy로, 클라우드 ID는 SAML·Azure AD로 끌어와, 어떤 신원 인프라든 Identity Awareness에 연결해 ID 기반으로 접근을 통제할 수 있습니다. 인증 방식의 세부(Kerberos·2FA·인증서)는 고급 브라우저 인증에서 다룹니다.