065부. 관리자 세션 흐름관리자·사용자 계정 관리

관리자(Administrator) 는 SmartConsole·CLI·관리 API로 Check Point 보안 환경을 관리·유지하는 IT 전문가 입니다. 관리자는 보안 제품을 설치·구성·유지하고, 네트워크 트래픽과 보안 정책을 다루며, 시스템 성능을 모니터링하고 보안 문제를 해결하며, 최신 Hotfix와 업데이트로 환경을 최신 상태로 유지합니다.

사용자(User) 는 Check Point 환경에서 트래픽을 일으키는 대상을 나타내는 객체 입니다. 관리자가 사용자 객체를 만들고, 관리하고, 모니터링합니다. 관리자는 Security Rule Base 로 인증된 사용자의 접근 권한을 제한하거나 허용하며, 특정 사용자에 대한 Access Control 규칙(Remote Access VPN, Identity Awareness 등)을 구성할 수 있습니다. 사용자는 자신이 어떤 그룹에 속하는지 알지 못합니다. 민감한 정보와 자원에 대한 접근을 인가된 사용자에게만 제한 하는 것이 조직의 네트워크와 데이터를 지키는 핵심입니다.

가장 중요한 구분은 누가 인증하느냐 입니다.

---

사용자 계정은 환경에서 트래픽을 만드는 사용자를 나타내는 객체입니다. 모든 사용자는 SmartConsole에서 직접 정의되어 Management Server의 관리 데이터베이스에 저장 됩니다(Active Directory 같은 외부 서버에 정의된 사용자와 대비). 관리자가 정책을 설치하면, Management Server가 해당 사용자 데이터를 관리 대상 Security Gateway로 복사 합니다. 관리자가 데이터베이스를 설치할 때(Menu > Install Database)는 Log Server 같은 다른 관리 대상 서버로도 사용자 데이터가 복사됩니다.

SmartConsole에서 사용자 계정을 만들 때는 다음 인증 방식 중 하나를 고릅니다.

위 Check Point 인증 방식 중 하나로 인증을 구성한 뒤에는, 추가로 인증서 파일(certificate file) 을 만들 수 있습니다. 그러면 사용자는 위 인증 방식이나 인증서 파일 둘 중 하나로 게이트웨이에 인증할 수 있습니다. 인증서 파일은 SmartConsole에서 만들며, 사용자는 두 가지 방법으로 로그인합니다.

기존 사용자 변경하기

사용자 삭제하기

사용자 그룹(User Group) 은 사용자 계정의 모음입니다. 규칙의 Source 또는 Destination 에는 개별 사용자가 아니라 사용자 그룹을 추가 합니다. 사용하지 않는 그룹은 편집·삭제할 수 있습니다.

새 사용자 그룹 만들기

기존 그룹에 사용자·그룹 추가하기

사용자 계정이 곧 만료되면, SmartConsole에서 그 사용자의 속성을 열 때 알림이 표시됩니다.

Check Point Password 는 SmartConsole에 설정하는 정적 암호이고, 게이트웨이 로컬 DB에 저장되며 추가 소프트웨어가 필요 없습니다. 구성 후 인증서 파일 인증도 함께 둘 수 있습니다.

OS Password 는 Security Gateway가 설치된 컴퓨터의 운영체제(또는 Windows 도메인)에 저장된 암호이며 추가 소프트웨어가 필요 없습니다. 절차는 Check Point Password와 거의 같고, 차이는 6단계에서 인증 방식으로 OS Password 를 고르는 것뿐입니다.

RADIUS 는 인증 기능을 액세스 서버에서 분리해 보안성과 확장성을 주는 외부 인증 방식입니다. 게이트웨이는 원격 사용자의 인증 요청을 RADIUS 서버로 전달하고, 사용자 정보를 가진 RADIUS 서버가 인증하며, RADIUS 프로토콜은 UDP 로 통신합니다. RADIUS 그룹을 쓰려면 RADIUS 서버의 사용자 프로파일에 return attribute 를 정의해야 합니다(Gaia는 "Vendor-Specific"(26), RFC 2865).

사용자는 단일 RADIUS 서버나 RADIUS 서버 그룹 으로 인증합니다. 서버 그룹은 동일한 RADIUS 서버들의 High Availability 그룹으로, 우선순위가 가장 높은 서버가 실패하면 다음으로 높은 서버가 이어받 습니다.

1. SmartConsole에서 새 RADIUS Server 객체 구성

2. 새 사용자를 만들고 인증 방식을 RADIUS로 지정

3. (선택) SmartConsole 인증용 RADIUS 서버 그룹 구성

TACACS 는 라우터·네트워크 장비에 중앙 서버로 접근 제어를 제공하는 외부 인증 방식입니다. 게이트웨이가 원격 사용자의 요청을 TACACS 서버로 전달하고, 사용자 정보를 가진 TACACS 서버가 인증합니다. 물리 카드키·토큰 카드, Kerberos 비밀키를 지원하며 모든 인증 요청의 이름·암호·서비스·계정 정보를 암호화합니다. 단일 서버나 TACACS 서버 그룹(HA, 우선순위 기반 이어받기)으로 인증할 수 있습니다.

1. SmartConsole에서 새 TACACS+ 서버 객체 구성

2. 새 사용자를 만들고 인증 방식을 TACACS로 지정

User Name(CN/DN 규칙) → General Properties → Groups → Authentication 에서 TACACS 선택 → Location → Time → Certificates → Encryption → OK 의 순서로, RADIUS 사용자 생성과 동일한 흐름을 따릅니다. (인증 방식을 고르지 않으면 로그인 불가)

3. (선택) TACACS 서버 그룹 구성

SecurID 는 토큰 인증기와 PIN·암호를 함께 요구하는 방식입니다. 토큰은 RSA Authentication Manager(AM) 와 동기화된 일회용 암호를 약 1분마다 생성하고, 게이트웨이가 AM 에이전트 로서 모든 접근 요청을 AM으로 보내 검증받습니다. 별도 파라미터가 없으며, 인증 요청은 SDK 지원 API 또는 REST API로 보냅니다.

1) 인증 요청을 보낼 API 구성

두 가지 API 중 하나를 켤 수 있습니다.

SDK-supported API — UDP 포트 5500 에서 독점 프로토콜을 쓰는 독점 API입니다.

REST API

   vsenv 0
   

   cp -v $CPDIR/conf/RSARestServer.conf{,_BKP}
   

2) 사용자 그룹 구성

3) SecurID 인증 사용자 만들기

구성 절차는 SmartConsole에 정의되는 내부 사용자 와 외부 사용자 가 다릅니다.

내부 사용자(internal users) — Management Server 데이터베이스에 보관됩니다.

외부 사용자(external users) — Legacy SmartDashboard에서 구성하며, Management Server 데이터베이스에 보관되지 않습니다.

4) SecurID 구성 마무리

게이트웨이에 인터페이스가 여러 개면, SecurID 에이전트가 AM의 응답을 복호화할 때 잘못된 인터페이스 IP를 써 인증이 실패 하는 경우가 있습니다. 이를 해결하려면 sdconf.rec 와 같은 디렉터리에 sdopts.rec 텍스트 파일을 만들고 다음 줄을 넣습니다.

CLIENT_IP=<IP Address>

여기서 <IP Address> 는 Authentication Manager에 정의된 게이트웨이의 기본 IP(서버로 라우팅되는 인터페이스의 IP)입니다. 예:

CLIENT_IP=192.168.20.30

Access Role 객체는 다음 기준으로 네트워크 접근을 구성하게 해 줍니다.

Identity Awareness 소프트웨어 블레이드를 켠 뒤에는 Access Role 객체를 만들어 Access Control Policy 규칙의 Source·Destination 열에 쓸 수 있습니다. 자세한 내용은 R82 Identity Awareness Administration Guide를 참고하세요.

Access Role 추가

Identity Awareness 엔진은 LDAP 그룹 멤버십 변경을 자동으로 인식 해 Access Role을 포함한 신원 정보를 갱신합니다.

---

Check Point User Directory 는 사용자별 정보를 저장합니다.

User Directory로 할 수 있는 일:

User Directory를 쓰기 전에 다음을 계획합니다.

User Directory는 Security Management Server와 LDAP 서버를 통합해, Security Gateway가 LDAP 정보를 쓰게 합니다.

SmartConsole에서 Management Server가 Account Unit의 사용자를 관리하도록 켭니다.

User Directory 기본 스키마는 사용자 디렉터리의 데이터 구조를 설명 하며 LDAP 서버용 사용자 정의를 담습니다. 이 스키마에는 IKE 관련 속성, 인증 방식, 원격 사용자 값 같은 Management Server·Security Gateway 고유 데이터가 없 습니다.

모든 사용자가 같은 인증 방식을 쓰고 기본 템플릿대로 정의된다면 기본 스키마를 써도 됩니다. 하지만 사용자 정의가 제각각이면 LDAP 서버에 Check Point 스키마 를 적용하는 편이 낫습니다. Check Point 스키마는 LDAP 구조에 Management Server·Security Gateway 고유 데이터를 더해, 사용자 인증 기능으로 객체 정의를 확장합니다. 예를 들어 fw1Person 객체 클래스는 Person 정의에 필수·선택 속성을 더하고, fw1Template 는 사용자 정보 템플릿을 정의하는 독립 속성입니다.

스키마 검사(Schema Checking)

스키마 검사가 켜지면, User Directory는 모든 Check Point 객체 클래스와 속성이 디렉터리 스키마에 정의되어 있을 것 을 요구합니다. User Directory 작업 전에는 스키마 검사를 꺼야 하며(켜져 있으면 통합 실패), Check Point 객체 클래스·속성을 서버 스키마에 적용한 뒤 다시 켭니다.

OID 고유 속성

fw1 로 시작하는 고유 객체 클래스·속성에는 각각 고유한 OID(Object Identifier) 가 있습니다.

고유 속성의 OID는 모두 1.3.114.7.4.2.0.X 접두사를 공유하며, X 값만 속성마다 다릅니다.

User Directory 스키마 속성

Netscape LDAP 스키마

Netscape 디렉터리 서버에 고유 스키마를 추가하려면 $FWDIR/lib/ldap/schema.ldif 파일을 씁니다.

이 ldif 파일은 새 속성을 스키마에 추가하고, 기존 fw1person·fw1template 정의를 삭제한 뒤 새 정의를 더합니다. 변경하려면 schema.ldif 와 함께 ldapmodify 명령을 실행합니다.

User Directory 프로파일 은 더 정확한 요청을 정의하고 서버와의 통신을 향상하는 구성 가능한 LDAP 정책 입니다. 프로파일이 LDAP 서버별 고유 지식 대부분을 담당하므로, 서로 다른 벤더의 LDAP 서버를 통합할 수 있습니다. 예를 들어 인증된 OPSEC User Directory 서버에는 OPSEC_DS 프로파일을 적용해 OPSEC 고유 속성을 얻습니다.

LDAP 서버는 객체 저장소·스키마·관계가 제각각입니다 — RDN에 cn 을 쓰는 곳도 uid 를 쓰는 곳도 있고, AD는 memberOf 로 그룹 소속을 표현하지만 표준 LDAP은 그룹 객체에 member 를 둡니다. 암호 저장 형식도 다르고, v3로 분류되지만 스키마를 확장하지 못하는 서버도 있으며, AD에는 accountExpires 가 있지만 다른 서버는 Check Point 속성 fw1expirationdate 가 필요합니다.

기본 User Directory 프로파일

프로파일 수정

프로파일에는 세 가지 주요 범주가 있습니다.

같은 항목을 범주별로 다른 값으로 둘 수 있어, 작업 종류에 따라 서버가 다르게 동작합니다.

사용자 정보를 효율적으로 가져오기

User Directory 작업은 사용자·사용자 그룹·사용자 템플릿(그룹 엔트리로 정의되고 사용자가 멤버)에 대해 수행됩니다. 그룹·템플릿과 사용자를 정의하는 모드는 사용자 정보를 가져올 때 성능에 큰 영향 을 줍니다. 세 가지 모드가 있습니다.

가장 효율적인 것은 MemberOf 와 Both 모드 로, 사용자 자신에 그룹 소속 정보가 있어 추가 쿼리가 필요 없습니다.

User-to-Group 멤버십 모드 설정

각 User Directory 서버의 프로파일 객체에서 objects_5_0.C 파일을 통해 멤버십 모드를 설정합니다.

데이터베이스 변환 후 프로파일을 알맞은 멤버십 설정으로 두고 Management Server를 시작한 다음, 모든 게이트웨이에 정책/사용자 데이터베이스를 설치 해 새 구성을 적용합니다.

프로파일 속성

다음은 프로파일에 정의되는 주요 속성, 기본값, 그리고 Microsoft_AD 등에서의 다른 값입니다.

SmartConsole에서 Account Unit의 사용자·그룹은 LDAP 서버와 같은 트리 구조 로 보입니다. User Directory 사용자를 보려면 Users and Administrators 를 열며, LDAP Groups 폴더가 서버의 구조와 계정을 담습니다. User Directory 템플릿을 바꾸면 그 템플릿을 쓰는 사용자에게 즉시 반영 되고, 사용자 정의를 수동으로 바꾸면 그 변경도 서버에 즉시 적용됩니다.

여러 서버에 사용자 분산

조직 사용자는 여러 LDAP 서버에 분산할 수 있으며, 각 LDAP 서버는 별도의 Account Unit 으로 표현됩니다.

LDAP 정보 관리

User Directory는 SmartDashboard로 LDAP 서버에 저장된 사용자·OU 정보를 관리하게 해 줍니다.

User Directory용 LDAP 그룹

User Directory용 LDAP 그룹을 만들면 사용자를 유형별로 분류해 정책 규칙에 쓸 수 있습니다. 사용자를 추가하거나 동적 필터를 만들 수 있습니다.

예: - 매니저 User 객체의 객체 클래스가 myOrgManager 면 필터 objectclass=myOrgManagers 로 Managers 그룹을 정의. - 이메일이 us.org.com 으로 끝나면 필터 mail=*us.org.com 으로 US 그룹을 정의.

User Directory 서버에서 정보 가져오기

게이트웨이가 인증에 사용자 정보가 필요하면 다음 과정을 거칩니다.

User Directory 쿼리 실행

쿼리로 User Directory 사용자·그룹 데이터를 가져옵니다. 성능을 위해 연결이 열려 있을 때 Account Unit을 쿼리하세요(게이트웨이가 일부 연결을 열어 둠).

쿼리 조건:

예를 들어 Attributes=mail, Contains, Value=Andy 로 쿼리하면 서버는 다음 필터로 질의합니다.

(objectclass=organizationalPerson)(objectclass=inetOrgPerson))
(|(cn=Brad)(mail=*Andy*)))

여러 LDAP 서버 질의

Management Server와 Security Gateway는 여러 LDAP 서버를 동시에 다룰 수 있습니다. 사용자가 어디에 정의됐는지 모르면 모든 LDAP 서버를 질의하며, 인증서로 작업할 때는 사용자 DN을 보고 위치를 찾기도 합니다.

Account Unit 은 하나 이상의 LDAP 서버에 있는 사용자 정보 브랜치를 나타내는 객체 로, LDAP 서버와 Management Server·Security Gateway 사이의 인터페이스입니다. Account Unit은 여러 개 둘 수 있고, 사용자를 한 Account Unit의 브랜치들로 나누거나 여러 Account Unit으로 나눌 수 있습니다.

LDAP Account Unit 다루기

LDAP Account Unit Properties 창에서 Account Unit을 새로 만들거나 편집합니다.

각 탭의 설정은 다음과 같습니다.

General 탭 — Management Server가 Account Unit을 어떻게 쓸지 구성합니다.

Servers 탭 — 이 Account Unit이 쓰는 LDAP 서버를 추가·편집·삭제합니다.

서버를 제거하려면 표에서 서버를 선택하고 Remove 를 클릭합니다. 모든 서버가 같은 자격 증명을 쓰면 Update Account Credentials 로 한꺼번에 바꿀 수 있습니다.

Objects Management 탭 — Management Server가 질의할 LDAP 서버와 브랜치를 구성합니다.

Authentication 탭 — Account Unit의 인증 스킴을 구성합니다.

설정을 마치면 OK → Access Control Policy 설치.

LDAP 서버 수정

Account Unit과 High Availability

User Directory 복제로 HA를 구성하면 하나의 Account Unit이 복제된 모든 서버를 대표 합니다. 예를 들어 한 Account Unit에 두 복제 서버를 정의하고, 두 게이트웨이가 같은 Account Unit을 쓸 수 있습니다.

High Availability 우선순위 설정

복제본이 여러 개면 Account Unit에서 각 LDAP 서버의 우선순위를 정합니다. Management Server는 한 복제본하고만 연결 하며, 나머지 복제본은 standby로 동기화돼야 합니다.

인증서로 인증하기

Management Server와 게이트웨이는 인증서로 LDAP 서버와의 통신을 보호할 수 있습니다. 인증서를 구성하지 않으면 인증 없이 통신합니다.

Check Point는 LDAP 등 외부 관리 기술을 자사 솔루션과 통합합니다. 관리자·사용자 수가 많으면 LDAP 같은 외부 데이터베이스를 쓰는 것이 Management Server 성능에 좋 습니다.

도메인을 Check Point 관리 데이터베이스로 관리할지, 외부 LDAP 서버로 구현할지 선택할 수 있습니다.

Microsoft Active Directory

Microsoft Windows 2000 advanced server(이상)에는 정교한 User Directory 서버가 있어 Management Server의 사용자 데이터베이스로 쓸 수 있습니다. 기본적으로 AD 서비스는 꺼져 있으며, 활성화하려면 Start > Run 에서 dcpromo 명령을 실행하거나 System Configuration 창에서 Active Directory 설정 마법사를 실행합니다.

AD 구조 예시는 다음과 같습니다.

DC=qa, DC=checkpoint,DC=com
CN=Configuration,DCROOT
CN=Schema,CN=Configuration,DCROOT
CN=System,DCROOT
CN=Users,DCROOT
CN=Builtin,DCROOT
CN=Computers,DCOOT
OU=Domain Controllers,DCROOT
...

Windows 2000 도구가 만든 사용자·그룹 객체는 대부분 CN=Users, DCROOT 브랜치에, 일부는 CN=Builtin, DCROOT 에 저장되며, 다른 브랜치에도 만들 수 있습니다. CN=Schema, CN=Configuration, DCROOT 브랜치에는 모든 스키마 정의가 있습니다.

Check Point는 기존 AD 객체를 그대로 쓰거나 새 유형을 더할 수 있습니다. 사용자는 기존 User를 "그대로" 쓰거나 fw1person 을 "User"의 보조(auxiliary)로 확장해 완전한 기능을 얻으며, 기존 AD "Group" 유형도 그대로 지원됩니다. fw1template 객체 클래스를 더해 User Directory 템플릿을 만들 수 있고, 이 정보는 schema_microsoft_ad.ldif 파일로 디렉터리에 내려받습니다.

레지스트리 설정 업데이트 — AD 스키마를 수정하려면 HKLM\System\CurrentControlSet\Services\NTDS\Parameters 아래에 0이 아닌 값을 가진 DWORD 키 Schema Update Allowed 를 추가합니다.

제어 위임(Delegating Control) — 기본적으로 Administrator는 User Directory 프로토콜로 스키마를 수정하거나 디렉터리 객체를 관리할 수 없으므로, 특정 사용자·그룹에 디렉터리 제어를 위임해야 합니다.

AD 스키마 확장

SmartConsole로 AD 사용자를 구성하려면 AD 스키마 파일을 수정합니다.

   dn: CN=User,CN-
   Schema,CN=Configuration,DC=sample,DC=checkpoint,DC=com
   changetype: modify
   add: auxiliaryClass
   auxiliaryClass: 1.3.114.7.3.2.0.2
   -
   

   ldifde -i -f c:/schema_microsoft_ad.ldif
   

AD에 새 속성 추가

다음은 AD에 속성 하나를 추가하는 LDIF 예시입니다.

changetype: add
adminDisplayName: fw1auth-method
attributeID: 1.3.114.7.4.2.0.1
attributeSyntax: 2.5.5.4
cn: fw1auth-method
distinguishedName:
CN=fw1auth-method,CN=Schema,CN=Configuration,DCROOT
instanceType: 4
isSingleValued: FALSE
LDAPDisplayName: fw1auth-method
name: fw1auth-method
objectCategory:
CN=Attribute-
Schema,CN=ConfigurationCN=Schema,CN=Configuration,DCROOT
ObjectClass: attributeSchema
oMSyntax: 20
rangeLower: 1
rangeUpper: 256
showInAdvancedViewOnly: TRUE

모든 Check Point 속성을 같은 방식으로 추가할 수 있습니다. 모든 속성의 LDIF 정의는 $FWDIR/lib/ldap 의 schema_microsoft_ad.ldif 에 있습니다. ldapmodify 실행 전에 파일의 모든 DCROOT 를 조직의 도메인 루트로 바꿉니다(예: support.checkpoint.com → dc=support,dc=checkpoint,dc=com).

예시 명령(dc=support,dc=checkpoint,dc=com 도메인의 Administrator 계정 사용):

ldapmodify -c -h support.checkpoint.com -D
cn=administrator,cn=users,dc=support,dc=checkpoint,dc=com" -w
SeCrEt -f $FWDIR/lib/ldap/schema_microsoft_ad.ldif

LDAP Account Unit의 관리자·서비스 계정 암호 갱신

게이트웨이는 SmartConsole LDAP Account Unit에 저장된 LDAP 서버 사용자명·암호로 LDAP 서버에 인증하고, 연결을 맺은 뒤에는 재인증 없이 그 연결을 재사용 합니다. AD의 LDAP 서버 암호를 바꾸면 변경이 적용되도록 다음을 해야 합니다.

---

관리자 계정은 Check Point 관리 데이터베이스나 외부 LDAP 서버 에 저장할 수 있고, Security Management Server가 인증합니다. 관리자로서 객체·사용자 정의 같은 업무를 다른 관리자에게 위임할 수 있으니, 필요한 권한을 가진 관리자 계정 을 만드세요.

대규모 네트워크 보안을 위해 먼저 관리 팀을 꾸리고 업무를 위임하세요. 관리자 계정은 SmartConsole에서, 또는 First Time Configuration Wizard로 만들길 권장합니다. 다음 인증 방식 중 하나를 고릅니다.

Check Point 인증 방식 중 하나를 구성한 뒤 추가로 인증서 파일 인증을 둘 수 있습니다. 관리자는 Certificate File 옵션(암호 필요) 또는 Windows Certificate Store에 가져온 CAPI Certificate 옵션(암호 불필요)으로 SmartConsole에 로그인하며, 자기 계정이 없는 다른 관리자에게 인증서를 줘 로그인하게 할 수도 있습니다.

cpconfig(Check Point Configuration Tool)로 관리자 만들기

cpconfig로 관리자를 만들면:

  cpstop ; cpstart
  

편집

삭제 — 보안을 위해, 인력이 떠나거나 이동하면 관리자 계정을 삭제하는 것이 모범 사례입니다.

관리자 기본 만료 설정 — 여러 계정에 같은 만료 설정을 쓰려면 기본값을 정하고, 만료가 가까우면 알림을 띄울 수 있습니다.

SmartConsole을 안전하게 쓰려면 타임아웃 설정이 기본 요건 입니다. 관리자가 쓰지 않으면 자동 로그아웃됩니다.

인증서로 인증하는 관리자가 일시적으로 업무를 못 보면 그 계정의 인증서를 폐기할 수 있습니다. 계정은 남되 인증서로는 인증할 수 없으며, 추가 인증 방식(암호 등)이 있으면 그 방식으로는 인증 할 수 있습니다.

로그인 시도 제한

Check Point 암호로 로그인하는 관리자에게 다음을 구성할 수 있습니다 — SmartConsole이 계정을 잠그기까지의 로그인 시도 횟수, 잠긴 뒤 자동 해제까지의 분 수.

관리자 계정 잠금 해제

Manage Administrators 권한을 가진 관리자는, 잠긴 관리자가 Check Point 암호로 인증할 경우 그 관리자를 잠금 해제할 수 있습니다.

다중 관리자

두 관리자가 같은 이름으로 관리자 계정을 만들면, 첫 관리자가 세션을 publish한 뒤 두 번째 관리자는 publish할 수 없 습니다. 두 번째 관리자는 이름도 바꿀 수 없으므로, 세션 변경을 discard하고 다시 연결해야 합니다.

절차는 Check Point Password와 거의 같으며, 차이는 인증 방식에서 OS Password 를 고르는 것입니다(이 방식에는 Set New Password 단계가 없음).

SmartConsole 관리자는 단일 RADIUS 서버나 RADIUS 서버 그룹(HA, 우선순위 기반)으로 RADIUS 인증할 수 있습니다. 그룹의 모든 멤버는 같은 프로토콜 을 써야 합니다.

TACACS 서버·TACACS 서버 그룹(HA, 우선순위 기반, 같은 프로토콜)으로 인증할 수 있습니다.

      mkdir -v /var/ace/
      

      chmod -v 777 /var/ace/sdconf.rec
      

SAML 인증은 관리자가 외부 3rd party Identity Provider를 통해 SAML 프로토콜로 SmartConsole에 로그인하게 합니다. IdP가 관리자 정보를 보관하고 인증을 수행합니다. 지원 IdP: Okta·Ping Identity·Azure.

Use Case

Azure 계정을 가진 관리자가 SmartConsole로 일하려는데, Azure용·SmartConsole용으로 이름·암호를 따로 쓰면 서로 다른 암호·만료 정책을 관리해야 하고, 두 암호를 기억해야 하며, 인력이 떠날 때 모든 앱에서 제거 해야 하는 부담이 생깁니다. IdP를 쓰면 관리자는 Azure에 한 번 인증한 뒤 추가 암호 입력 없이 SmartConsole에 연결되고, Management Server에 자기 암호를 노출하지도 않습니다.

SAML 인증 처리 흐름

SAML 인증 로그인 구성

URL 대신 도메인 이름을 쓰려면 (NAT 뒤의 Management Server·Multi-Domain Server, HA 환경에서는 각 Management Server에서): 1. Management Server 명령줄에 접속해 Expert mode 로 로그인합니다. 2. $CPDIR/tmp/.CPprofile.sh 파일을 편집합니다.

         vi $CPDIR/tmp/.CPprofile.sh
         

         SAML_IP_OR_NAME=<Your Domain Name>;export SAML_IP_OR_NAME
         

예:

         SAML_IP_OR_NAME=example.com;export SAML_IP_OR_NAME
         

         # Security Management Server
         cpstop ; cpstart
         # Multi-Domain Server
         mdsstop ; mdsstart
         

관리자 그룹 설정: - Name — 그룹 객체 이름(임의). - Group ID/name — IdP에 정의된 그룹 속성과 정확히 일치 해야 합니다. - Permission — 필요한 권한 프로파일 배정.

SmartConsole 로그인 창으로 로그인 1. SmartConsole을 엽니다. 2. 첫 드롭다운에서 Identity Provider 를 선택합니다. Management Server가 데이터베이스에 관리자가 있는지 확인하고, 있으면 로그인시키며, 없으면 관리자 그룹에 속하는지 확인해 그 그룹의 권한 으로 로그인시킵니다. 3. Management Server의 IP·호스트 이름을 입력합니다. 4. Login with SSO 를 클릭합니다.

SmartConsole 구성 파일로 로그인 — SAML 로그인용 구성 파일로 SmartConsole을 띄우려면 Windows 명령 프롬프트에서:

   SmartConsole.exe -p "Full Path to the Configuration File"
   

예:

   cd /d "C:\Program Files (x86)\CheckPoint\SmartConsole\R82\"
   SmartConsole.exe -p "D:\MySAML_Configuration.xml"
   

필요한 구성 파일(평문 XML):

   <?xml version="1.0" encoding="utf-8"?>
   <RemoteLaunchParemeters
   xmlns:xsi="http:/www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http:/www.w3.org/2001/XMLSchema">
   <ServerIP>IP Address of the Management Server</ServerIP>
   <DomainName>Name of the Domain Management Server</DomainName>
   <ReadOnly>False</ReadOnly>
   <CloudDemoMode>False</CloudDemoMode>
   <IsSamlLogin>1</IsSamlLogin>
   </RemoteLaunchParemeters>
   

IP 172.30.44.55 Management Server 예시:

   <?xml version="1.0" encoding="utf-8"?>
   <RemoteLaunchParemeters
   xmlns:xsi="http:/www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http:/www.w3.org/2001/XMLSchema">
   <ServerIP>172.30.44.55</ServerIP>
   <ReadOnly>False</ReadOnly>
   <CloudDemoMode>False</CloudDemoMode>
   <IsSamlLogin>1</IsSamlLogin>
   </RemoteLaunchParemeters>
   

SAML 구성 후에도 추가로 인증서 파일 인증을 둘 수 있어, IdP나 인증서 파일 중 하나로 로그인할 수 있습니다.

API key 는 클라이언트가 API 호출 시 제공하는 토큰입니다. 사용자명/암호 대신 토큰으로 API 인터페이스에 인증할 수 있습니다.

예제 — API key로 로그인해 게이트웨이 만들기

   mgmt_cli login api-key <api-key> > /<path_to>/<filename>
   

예:

   mgmt_cli login api-key mvYSiHVmlJM+J0tu2FqGag12 > /var/tmp/token.txt
   

   mgmt_cli -s /<path_to>/<filename> add simple-gateway name <gateway name> ip-address <ip address> one-time-password <password> blade <true>
   

예:

   mgmt_cli -s /var/tmp/token.txt add simple-gateway name "gw1" ip-address 192.168.3.181 one-time-password "aaaa" firewall true vpn true
   

자세한 내용은 Check Point Management API Reference를 참고하세요. API 인증 후에도 인증서 파일 인증을 추가로 둘 수 있습니다.

---

권한 프로파일(Permission Profile) 은 Management Server·SmartConsole 관리 권한을 미리 정의한 묶음 으로, 한 프로파일을 여러 관리자에게 배정할 수 있습니다. Manage Administrators 권한을 가진 관리자만 프로파일을 만들고 관리할 수 있습니다. (Multi-Domain 관리자용 프로파일은 R82 Multi-Domain Security Management Administration Guide 참고)

권한 프로파일 변경·생성

Super User 권한 관리자는 프로파일을 편집·생성·삭제할 수 있습니다. 다음은 기본 제공 프로파일로, 변경·삭제할 수 없고 복제(clone)해서 수정 합니다.

관리자의 프로파일 변경

프로파일 변경

새 프로파일 만들기

프로파일 삭제

사용자 정의(Customized) 권한 구성

Gateways·Access Control·Threat Prevention·Others·Monitoring and Logging·Events and Reports·Management 등 자원별로, 이 프로파일의 관리자가 기능을 구성할 수 있는지(Write), 보기만 할 수 있는지(Read) 를 정합니다.

Read·Write 옵션이 있는 기능은 — Read(기능을 갖되 변경 불가), Write(기능을 갖고 변경 가능)입니다.

구성 절차

Access Control Layer 권한 구성

서로 다른 Layer의 소유권을 다른 관리자에게 위임해 Access Control Policy 관리를 단순화할 수 있습니다. Layer에 권한 프로파일을 배정하며, 그 프로파일에는 Edit Layer by the selected profiles in a layer editor 권한이 있어야 합니다.

Layer 권한을 프로파일에 주기

Layer에 프로파일 배정

Access Control·Threat Prevention 권한 구성

프로파일 객체에서 기능과 Read/Write 권한을 선택합니다.

Monitoring·Logging·Events·Reports 권한 구성

프로파일 객체에서 기능과 Read/Write 권한을 선택합니다.

Management Server 접근을 지정한 호스트 목록으로 제한 하려면 Trusted Clients 를 구성합니다. 다음 방식으로 정의할 수 있습니다.

Super User 권한 관리자만 Trusted Client를 추가·편집·삭제할 수 있습니다.

새 Trusted Client 추가

Trusted Client 수정 — Trusted Clients에서 클라이언트를 더블클릭하고 설정을 바꾼 뒤 OK.

Trusted Client 삭제 — Trusted Clients에서 선택하고 Delete → 확인 창에서 Yes.

---

SmartConsole에서 관리자는 세션(Session) 으로 일합니다. 관리자가 SmartConsole에 로그인할 때마다 세션이 생성 되고, 세션 안의 변경은 자동 저장됩니다. 이 변경은 비공개(private) 라 그 관리자만 볼 수 있으며, 충돌을 막기 위해 다른 관리자는 편집 중인 객체·규칙에 잠금 아이콘을 봅니다. 변경 보고서로 세션의 모든 변경을 확인할 수 있습니다.

관리자는 비공개 변경을 publish 하거나 discard 할 수 있습니다. 변경을 정책 설치에 포함하거나 다른 관리자에게 공유하려면 반드시 publish 해야 하며, publish되지 않은 변경은 정책 설치에 포함되지 않습니다. publish 전에 세션에 이름과 간단한 설명을 다는 것이 좋습니다.

SmartConsole의 validations 창은 고유하지 않은 객체 이름, 유효하지 않은 객체 사용 같은 오류를 보여 줍니다. publish 전에 이런 오류를 고치세요.

Session 뷰 는 시스템의 모든 게시되지 않은 세션 을 보여 줍니다 — 현재 관리자, 다른 관리자, 다른 애플리케이션의 세션 모두. 열은 사용자 정의할 수 있고 소유자·이름·설명·연결 모드·비공개 변경 수·잠금 수·애플리케이션 등을 표시합니다. Manage & Settings > Sessions > View Sessions 로 봅니다.

비공개 세션에 할 수 있는 작업은 프로파일의 Manage Sessions 권한에 따라 다릅니다.

특정 세션(현재 또는 다른 세션)의 변경을 보고서로 만들어 추적·모니터링·디버깅할 수 있습니다. 변경 보고서는 정책 규칙과 공통 네트워크 객체의 변경만 담습니다(sk166435 참고).

비활성 세션의 관리자가 객체를 잠가 둔 채 다시 로그인할 수 없으면, 그 세션을 take over할 수 있습니다.

여러 세션으로 일하면, 현재 비공개 세션을 publish하지 않고도 추가 세션을 열 수 있습니다.

Use Case

비공개 세션에서 작업 중에 급한 문제를 해결해 달라는 요청을 받았다고 합시다. 현재 세션을 publish·discard하고 싶지 않다면, 새 비공개 세션을 열어 변경하고 그것만 publish한 뒤 이전 세션으로 돌아옵니다.

여러 세션 켜기

여러 세션을 쓰면 — 같은 계정으로 여러 세션을 열어 관리하고, 활성 세션과 저장된 세션 사이를 전환하고, 다른 세션을 publish·discard·disconnect하고, take over할 수 있습니다.

SmartConsole Session 메뉴

여러 세션을 켜면 Session 메뉴에 새 옵션이 생깁니다.

SmartConsole Session 뷰(여러 세션)

여러 세션을 켜면 추가 작업을 할 수 있습니다.

여러 세션 ↔ 단일 세션 전환

여러 세션에서 단일 세션 허용으로 바꾸면:

이 기능은 관리자가 publish하기 전에 다른 관리자의 세션 변경을 검토·승인 하게 합니다. 누가 승인을 받아야 하고 누가 승인할 수 있는지 정의합니다.

구성

관리자 "A"가 규칙을 수정하고 Submit 하면 SmartConsole이 그 규칙·객체를 잠그고 자물쇠 아이콘 을 표시합니다(객체는 우클릭 View 로 속성만 볼 수 있음).