07Identity Source — RADIUS·API·Remote AccessIdentity Source — RADIUS·API·Remote Access

RADIUS Accounting 은 인증을 RADIUS 서버가 처리하는 환경 에 딱 맞는 신원 소스입니다. RADIUS 회계 클라이언트(RADIUS Accounting Client)가 보내는 회계 요청(Accounting Request)에서 사용자·컴퓨터 신원을 직접 취득 하고, 그 정보를 단서 삼아 LDAP 서버에서 사용자·기기의 그룹 정보를 조회 해 방화벽 규칙의 Access Role 권한을 적용하는 방식입니다.

설정의 큰 그림은 두 가지입니다. 하나는 RADIUS 클라이언트가 게이트웨이로 회계 요청을 보내도록 만드는 것이고, 다른 하나는 게이트웨이에서 그 클라이언트에게 접근 권한과 사전 공유 비밀(shared secret)을 부여 하는 것입니다. 설정은 모두 SmartConsole의 RADIUS Accounting Settings 창에서 합니다 — Check Point Gateway 창 > Identity Awareness 페이지에서 RADIUS Accounting > Settings를 클릭해 엽니다.

Security Gateway에서 RADIUS Accounting 켜기

게이트웨이가 RADIUS Accounting 서버로 동작하려면 먼저 기능을 켜야 합니다.

RADIUS Client Access Permissions — 어느 인터페이스로 받을지

게이트웨이 인터페이스는 RADIUS Accounting 클라이언트의 연결을 받도록 허가 되어 있어야 합니다.

Authorized RADIUS Clients — 허가된 클라이언트와 공유 비밀

게이트웨이는 허가된(authorized) RADIUS Accounting 클라이언트의 회계 요청만 받아들입니다. RADIUS Accounting 클라이언트는 RADIUS 클라이언트 소프트웨어가 설치된 호스트입니다.

공유 비밀은 직접 손으로 입력해도 됩니다. 또한 클라이언트를 추가하거나 제거할 때마다 새 공유 비밀을 다시 만들 필요는 없 습니다.

RADIUS Message Attribute Indices — 어느 속성에서 신원을 읽을지

RADIUS Accounting 메시지에는 연결에 관한 신원·인증·관리 정보가 들어 있고, 이 정보는 패킷의 미리 정의된 속성(attribute) 에 담깁니다. Message Attributes Indices 섹션은 Identity Awareness가 어느 속성에서 신원 정보를 읽을지 알려 주는 곳입니다.

각 값마다 메시지 속성을 하나씩 고릅니다. 대부분의 구성에서는 기본 속성 그대로가 정확 합니다.

메시지 속성을 설정하는 절차는 이렇습니다.

Session Timeout과 LDAP Servers

세션 타임아웃 은 RADIUS Accounting 클라이언트로부터 Accounting Start나 Interim-Update 메시지를 받지 못한 채 사용자 세션이 열려 있을 수 있는 최대 시간 입니다. 분 단위로 값을 입력하거나 선택합니다(기본값 720분).

게이트웨이가 RADIUS Accounting 요청을 받을 때 사용자·기기 정보를 어느 LDAP Account Unit에서 찾을지 도 지정할 수 있습니다(LDAP Account Unit은 SmartConsole에서 구성합니다).

RADIUS Secondary IP와 Dual Stack 지원

RADIUS 서버는 주소마다 따로 메시지를 보내는 대신, 한 메시지에 두 개의 IP 주소 를 실어 보낼 수 있습니다. 이 기능을 켜면 한 RADIUS 메시지에서 두 IP를 뽑아 IP마다 하나씩 별도의 세션 을 만듭니다.

설정은 Expert mode의 CLI로 합니다.

pdp radius ip set <attribute index>

여기서 <attribute index> 는 보조(secondary) IP 주소 값이 들어 있는 RADIUS index 입니다(SmartConsole에서 설정하는 User IP index와 비슷한 개념).

다음은 Cisco-AVPair 를 설정하는 예입니다.

pdp radius ip set 26 -a 1 -c 9

RADIUS Attribute Parsing — 문자열에서 값만 뽑기

이 기능은 RADIUS 메시지 안의 문자열·텍스트 데이터를 파싱 합니다. 파서는 미리 정한 접두사(prefix)와 접미사(suffix) 사이에 있는 문자열 을 찾아냅니다. 예를 들어 메시지가 ###data~~@ 형태라면, prefix를 #, suffix를 @ 로 설정해 data 만 뽑을 수 있습니다.

pdp radius parser set <attribute index> [-p <prefix>] [-s <suffix>]

여기서 <attribute index> 는 파싱이 필요한 값이 들어 있는 RADIUS index 이고, <prefix>·<suffix> 는 파싱 옵션입니다. 메시지가 <text1><prefix><text2><suffix><text3> 형태라면 파서는 <text2> 를 반환 합니다.

예시로, 메시지가 username=test; 이고 prefix가 username=, suffix가 ;(세미콜론)이면 파싱 결과는 test 입니다.

prefix만 또는 suffix만 지정해도 됩니다. 하나만 지정하면 그 하나를 기준으로만 잘라냅니다.

Receiving Groups from RADIUS Messages — 그룹 직접 읽기

이 기능을 쓰면 RADIUS 메시지에서 사용자·컴퓨터 그룹을 직접 읽어 그에 맞게 Access Role을 계산할 수 있습니다.

pdp radius group set -u <attribute index> -d <delimiter>
pdp radius group fetch on

여기서 <attribute index> 는 그룹 값이 들어 있는 RADIUS index 이고, -u 는 사용자 그룹, -m 은 컴퓨터 그룹을 지정합니다. <delimiter> 는 한 메시지 안에 여러 그룹이 있을 때 그룹을 나누는 구분 문자 입니다.

예를 들어 사용자 그룹을 가져오려 하고 메시지가 "group1;group2;group3" 라면, 구분자를 ; 로 설정합니다.

pdp radius groups set -u <attribute index> -d ";"

Identity Awareness API(Identity Web API)는 신원을 가장 유연하게 만들고 다루는 방법 입니다. SSL 위에서 REST 프로토콜 을 쓰며, 요청·응답은 모두 HTTP와 JSON 형식 입니다. 표준 소스로는 잡기 어려운 신원을 외부 시스템과 연동해 직접 주입 할 때 유용합니다.

Identity Web API 설정하기

Client Access Permissions — 어느 인터페이스로 받을지

Web API 클라이언트의 연결을 받을 게이트웨이 인터페이스를 골라야 합니다. 선택지는 게이트웨이에 구성된 토폴로지에 따라 달라지며, Web API 클라이언트는 이 인터페이스에 연결된 네트워크를 거쳐야 게이트웨이에 닿을 수 있습니다.

Authorized Clients와 클라이언트별 비밀

게이트웨이는 허가된 Web API 클라이언트 컴퓨터의 연결만 받아들입니다.

Authentication Settings — 어디서 사용자를 찾을지

Web API Settings 창의 Authentication Settings 섹션에서 Settings 를 클릭하면 LDAP Account Units 창이 열립니다. 여기서 사용자가 인증을 시도할 때 게이트웨이가 어느 디렉터리에서 사용자를 찾을지 정합니다.

기본적으로 모든 User Directories 옵션이 선택되어 있습니다. 사용자가 특정 디렉터리에만 있고 인증 시 게이트웨이 성능을 최대화 하고 싶다면 한두 개만 골라도 됩니다. 다만 같은 사용자 이름이 여러 디렉터리에 있으면 사용자는 domain\username 형태로 로그인해야 합니다.

Identity Web API 명령과 URL 구조

Web API URL은 다음 구조를 가집니다.

https://<IP Address or FQDN of Gateway>/_IA_API/v1.0/<command>

예: https://gw.acme.com/_IA_API/v1.0/add-identity

요청 본문의 JSON은 단순한 평면(flat) 키-값 객체 입니다.

Versioning — 버전 호환성

뒤·앞 버전 호환을 위해 요청 URL에 API 버전을 넣을 수 있습니다.

지원 명령은 셋입니다 — add-identity(IP를 사용자·컴퓨터에 일정 시간 연결), delete-identity(IP/범위/서브넷에 매칭되는 세션 취소), show-identity(IP에 연결된 신원 조회) 입니다.

Add Identity (v1.0)

지정한 IP 주소에 새 Identity Awareness 연결(association)을 생성 합니다.

POST https://<IP Address or FQDN of Gateway>/_IA_API/v1.0/add-identity

응답 필드

Add Identity 주의사항

Add Identity 예제

예제 1 — 사용자 신원 생성을 위한 최소 요청

POST https://gw.acme.com/_IA_API/v1.0/add-identity
{
 "shared-secret":"****",
 "ip-address":"1.2.3.5",
 "user":"mary"
}

응답:

 "ipv4-address":"1.2.3.5",
 "message":"Association sent to PDP."
}

예제 2 — 사용자 정의 그룹, 역할 계산

POST https://gw.acme.com/_IA_API/v1.0/add-identity
{
 "shared-secret":"****",
 "ip-address":"1.1.1.1",
 "user":"john",
 "machine":"",
 "domain":"cme.com",
 "user-groups":["MyUserGroup"],
 "roles":[],"timeout":4,
 "fetch-user-groups":0,
 "calculate-roles":1,
 "identity-source":"ACME API Client"
}

응답:

 "ipv4-address":"1.1.1.1",
 "message":"Association sent to PDP."
}

예제 3 — 사용자 정의 그룹·역할 + 상세 정보

POST https://gw.acme.com/_IA_API/v1.0/add-identity
{
 "shared-secret":"****",
 "user":"John",
 "machine":"Laptop_1234",
 "ip-address":"2.2.2.2",
 "identity-source":"ACME API Client",
 "machine-os":"Windows 10 (Build 1176)",
 "host-type":"Laptop",
 "fetch-user-groups":0,
 "fetch-machine-groups":0,
 "calculate-roles":0,
 "session-timeout":43200,
 "user-groups":["EnterpriseFinanceUsers","ad_user_JohnDoe"],
 "machine-groups":["EnterpriseLaptopMachines"],
 "roles":["FinanceUser","StandardLaptop"]
}

응답:

 "ipv4-address" : "2.2.2.2",
 "message" : "Association sent to PDP."
}

Delete Identity (v1.0)

하나의 IP, IP 범위, 서브넷, 또는 특정 사용자+IP 조합 에 대한 Identity Awareness 연결을 삭제합니다.

POST https://<IP Address or FQDN of Gateway>/_IA_API/v1.0/delete-identity

client-type에 쓸 수 있는 신원 소스 목록

응답 필드

Delete Identity 예제

예제 1 — IP로 삭제:

POST https://gw.acme.com/_IA_API/1.0/delete-identity
{ "shared-secret":"****", "ip-address":"1.1.1.1" }

{ "count":"1", "ipv4-address":"1.1.1.1", "message":"Disassociation sent to PDP." }

예제 2 — IP 범위로 삭제:

POST https://gw.acme.com/_IA_API/v1.0/delete-identity
{
 "shared-secret":"****",
 "revoke-method":"range",
 "ip-address-first":"1.1.1.2",
 "ip-address-last":"1.1.1.3"
}

{ "count":"2", "message":"Total of 2 IPs disassociations will be processed." }

예제 3 — 서브넷으로 삭제:

POST https://gw.acme.com/_IA_API/idasdk/delete-identity
{
 "shared-secret":"****",
 "revoke-method":"mask",
 "subnet":"1.1.1.1",
 "subnet-mask":"255.255.255.0"
}

{ "count":"100", "message":"Total of 100 IPs disassociations will be processed." }

예제 4 — IP+사용자 이름으로 삭제:

POST https://gw.acme.com/_IA_API/idasdk/delete-identity
{
 "shared-secret":"****",
 "ipv4-address":"1.1.1.1",
 "revoke-method":"user-name-and-ip",
 "user":"USER_NAME"
}

{ "count":"2", "ipv4-address":"1.1.1.1", "message":"Disassociation sent to PDP." }

Query Identity (v1.0) — show-identity

주어진 IP의 Identity Awareness 연결을 조회 합니다.

POST https://<IP Address or FQDN of Gateway>/_IA_API/idasdk/show-identity

응답 필드

Query Identity 예제 요청

POST https://gw.acme.com/_IA_API/v1.0/show-identity
{ "shared-secret":"****", "ip-address":"1.1.1.1" }

응답 1 — 사용자 신원만 있을 때

"combined-roles":["All_Identified_Users","User_John"],
"domain":"cme.com",
"ipv4-address":"1.1.1.1",
"machine":"admin-pc@cme.com",
"message":"total 1 user records were found.",
"users":[
 {
  "groups":["All Users","ad_user_John_Smith"],
  "identity-source":"AD Query",
  "roles":["All_identified_Users","User_John"],
  "user":"JohnSmith"
 }
]
}

응답 2 — 사용자와 컴퓨터 신원이 함께 있을 때

"combined-roles":["Admin-PC_cme.com","All_Identified_Users","User_John"],
"domain":"cme.com",
"ipv4-address":"192.168.110.126",
"machine":"admin-pc@ad.ida",
"machine-groups":["ad_machine_ADMINPC","All Machines"],
"machine-identity-source":"Identity Awareness API (ACME API Client)",
"message":"total 1 user records were found.",
"users":[
 {
  "groups":["All Users","ad_user_John_Smith"],
  "identity-source":"Identity Awareness API (ACME API Client)",
  "roles":["Admin-PC_ad.ida","All_Identified_Users","User_John"],
  "user":"John Smith"
 }
]
}

응답 3 — 여러 사용자 신원이 있을 때 (한 IP에 George Black, John Smith 두 사용자가 잡힌 경우로, users 배열에 레코드가 둘 나옵니다.)

응답 4 — 신원을 못 찾았을 때

{ "ipv4-address" : "1.1.1.1", "message" : "total 0 user records were found." }

Bulk Commands (v1.0) — 여러 명령을 한 번에

한 요청으로 여러 명령 을 보낼 수 있습니다. requests 배열을 보내면 각 원소가 한 요청의 파라미터가 되고, 응답으로 돌아오는 responses 배열에는 요청과 같은 순서로 각 명령의 응답이 담깁니다.

예제 1 — 여러 연결 추가

 "shared-secret" : "****",
 "requests":[
  {"user":"linda","machine":"","ip-address":"1.1.18.1"},
  {"user":"james","ip-address":"1.1.18.2", "domain" : "cme.com"},
  {"user":"mary","machine":"","ip-address":"1.1.18.3"}
 ]
}

응답에는 세 건 모두 "Association sent to PDP." 가 차례로 돌아옵니다.

예제 2 — 일부가 잘못된 경우 — 두 번째 요청의 IP가 invalid 이면, 그 항목만 오류로 응답하고 나머지는 정상 처리 됩니다.

 "responses": [
  { "ipv4-address": "1.1.18.1", "message": "Association sent to PDP." },
  { "pre": "GENERIC_ERR_INVALID_PARAMETER", "message": "No valid IP was provided" },
  { "ipv4-address": "1.1.18.3", "message": "Association sent to PDP." }
 ]
}

예제 3 — 여러 신원 조회 — requests 배열에 IP만 넣어 한 번에 여러 IP의 신원을 조회하면, 각 IP의 사용자·그룹·역할·identity source가 responses 배열로 돌아옵니다.

Web API 문제 해결

Web API 문제는 보통 두 가지에서 비롯됩니다 — 잘못된 구성(예: 틀린 URL, 클라이언트 미허가)과 잘못된 명령 구문(예: 누락된 파라미터, 잘못된 값).

표준 요청의 경우: - HTTP 응답 코드 200 — Identity Awareness 서비스가 유효한 API 명령을 받았 다는 뜻 - HTTP 응답 코드 500 — 명령이 잘못되었거나, 내부 오류로 명령을 수행하지 못했다는 뜻

요청이 실패하면 JSON 응답 본문에 code 필드가 들어가고 message 필드에 설명이 담깁니다. message 필드는 절차의 성공 을, code 필드는 절차의 실패 를 알립니다. Bulk 요청은 HTTP 상태가 항상 200 이고, 각 요청마다 세분화된 오류 코드가 주어집니다.

상태와 응답

Remote Access 소스는 Office Mode로 동작하는 Mobile Access·IPsec VPN 클라이언트가 게이트웨이에 접속할 때 신원을 취득 합니다. 이를 쓰려면 같은 게이트웨이에 Identity Awareness와 IPsec VPN 블레이드를 함께 켜야 합니다. 상세는 Mobile Access·Remote Access VPN 관리자 가이드를 참고하세요.

설정은 간단합니다. Identity Awareness 게이트웨이 객체 속성 > Identity Awareness 페이지에서 Remote Access 를 선택하면 켜지고, 해제하면 꺼집니다.

Infinity Identity 는 Check Point 생태계 전반에서 통합된 신원 저장소(unified identity repository) 역할을 합니다. R82에서는 Identity Provider(IdP)를 중앙에서 한 번 구성 하면, Infinity Portal에 정의한 IdP를 Identity Awareness 블레이드가 켜진 여러 Security Gateway에서 재사용 할 수 있습니다.

동작 방식

다음 예는 Azure를 쓰지만, Infinity Portal이 지원하는 어떤 IdP에도 동일하게 적용됩니다.

사전 요구사항

지원 IdP

Microsoft ADFS, Microsoft Entra ID, Okta, RADIUS, OneLogin, Ping Identity, Google Workspace, Duo, 그리고 Generic SAML Server를 지원합니다.

중앙 집중식 Identity Provider 구성하기

시작 전에 SmartConsole, Infinity Portal, 그리고 IdP에 모두 로그인해 둡니다.

Step 1 — Identity Provider 정의

단계별 안내는 SSO Authentication Setup with Identity Provider 문서를 참고합니다.

Step 2 — SmartConsole과 연동

Step 3 — SmartConsole에서 Identity Awareness 구성

이 방식은 Security Management 가이드의 Infinity Portal 연동에서 본 것처럼, 온프레미스 게이트웨이를 클라우드 서비스와 이어 신원 정보를 통합 하는 흐름과 같습니다.

Identity Awareness는 Application & URL Filtering 블레이드와 함께 쓰여 Security Gateway에 사용자 인식, 컴퓨터 인식, 애플리케이션 인식 을 더합니다. 둘은 이렇게 맞물립니다.

시나리오 — Application Control 로그에서 사용자 식별

ACME 조직은 Identity Awareness로 나가는(outbound) 애플리케이션 트래픽을 모니터링 해 직원들이 무엇을 하는지 파악합니다. IT 관리자는 Application Control과 Identity Awareness를 켜고, 로그·이벤트에 신원 정보가 보이도록 합니다.

이후 IT 부서는 Application & URL Filtering Layer에 규칙을 더해 특정 애플리케이션을 차단하거나 다르게 추적할 수 있습니다(R82 Quantum Security Gateway Guide 참고).

필요한 SmartConsole 구성

로그에서의 사용자 식별

애플리케이션 트래픽과 관련된 로그·이벤트에서 식별된 사용자의 데이터를 볼 수 있습니다. 로그 항목은 출발지 IP를 사용자 신원과 매핑 한 결과를 보여 주고, 여기에 Application Control 데이터도 함께 나타납니다.

신원 소스마다 보안·환경 고려사항이 다릅니다. 조직 요구사항에 따라 따로 쓰거나, 서로 보완하도록 조합 할 수 있습니다.

여러 소스를 함께 쓸 때, 신원이 겹치면 소스 간 우선순위 가 적용됩니다.

이렇게 다양한 소스를 환경에 맞게 조합하며, 여러 소스의 신원이 겹칠 때는 PDP의 Identity Conciliation이 최종 조정을 맡습니다.