13관리 서버 운영관리 서버 운영

SmartConsole에는 환경 전체에 적용되는 여러 설정이 모여 있습니다. 데이터베이스 리비전, 환경의 IP 주소 버전, 로그인 창 꾸미기, UserCenter 동기화, 검사 설정(Inspection Settings), 그리고 자동화를 위한 SmartTasks가 여기에 속합니다.

Database Revisions — 데이터베이스 리비전

Security Management 아키텍처에는 Revision(리비전) 이 내장되어 있습니다. publish(게시)할 때마다 직전 리비전과의 변경분만 담은 새 리비전이 생성 됩니다. 이 구조 덕분에 다음 세 가지 이점을 얻습니다.

다만 리비전 기능을 쓰기 전에 알아야 할 한계가 있습니다.

다음 경우에는 리비전 자체가 지원되지 않습니다.

또한 이전 리비전으로 되돌리면 Native Cloud와의 Site to Site VPN 터널 구성은 저장되지 않 습니다(자세한 내용은 R82 Site to Site VPN Administration Guide의 Seamless Site to Site VPN Tunnel with Native Cloud 장 참고).

저장된 데이터베이스 버전 보기와 다루기

저장된 리비전은 SmartConsole의 Manage & Settings > Sessions > Revisions 에서 봅니다. 여기서 할 수 있는 작업은 다음과 같습니다.

환경의 IP 주소 버전 설정

많은 객체와 규칙이 IP 주소를 사용합니다. 환경이 쓰는 버전을 지정해 두면 관련 옵션만 보여서 작업이 깔끔해집니다.

창 기본값 복원 (Restoring Window Default)

SmartConsole의 일부 창은 관리자에게 "이 창을 다시 보지 않음(do not show)" 옵션을 줍니다. 이 선택을 취소하고 모든 창을 다시 보이도록 되돌릴 수 있습니다. 이 옵션은 관리자가 어떤 창에서 "do not show"를 선택한 적이 있을 때만 나타납니다.

로그인 창 꾸미기 (Configuring the Login Window)

관리자는 매일 SmartConsole을 씁니다. 로그인 창을 조직의 문화에 맞게 꾸밀 수 있습니다.

   This system is for authorized use only
   

UserCenter와 동기화 (Synchronization with UserCenter)

환경에 관한 정보(Security Gateway 이름, 버전, 활성 블레이드 등)를 User Center 에 추가할 수 있습니다. Check Point는 이 추가 정보를 더 나은 재고 관리, 선제적 지원, 더 효율적인 티켓 처리 에 활용합니다(자세한 내용은 sk94064 참고).

검사 설정 (Inspection Settings)

Security Gateway의 검사(inspection) 동작을 다음 세 가지 관점에서 설정할 수 있습니다.

Security Management Server에는 두 개의 사전 구성된 검사 프로파일이 함께 제공됩니다 — Default Inspection 과 Recommended Inspection. Security Gateway를 구성하면 기본으로 Default Inspection 프로파일이 활성화됩니다. 여기에 Recommended Inspection 프로파일을 할당하거나, 사용자 정의 프로파일을 만들어 할당할 수도 있습니다. 검사 설정을 실제로 적용하려면 Access Control Policy를 설치 해야 합니다.

검사 설정 구성하기

SmartConsole에서 Manage & Settings > Blades 뷰로 가서 General 섹션의 Inspection Settings 를 클릭하면 Inspection Settings 창이 열립니다. 여기서 할 수 있는 일은 다음과 같습니다.

설정 편집 — Inspection Settings > General 뷰에서 설정을 선택하고 Edit 를 누른 뒤, 프로파일을 골라 다시 Edit 를 누르면 설정 창이 열립니다. 여기서 Main Action 을 고릅니다.

이어서 Logging Settings 를 구성합니다. Drop 규칙에서 차단된 패킷을 나중에 살펴보려면 Capture Packets 를 선택합니다. OK → Close 로 마칩니다. SYN 공격에 대한 고급 구성은 sk120476 을 참고하세요.

특정 프로파일의 설정만 보기 — Inspection Settings > General 뷰에서 View > Show Profiles 를 누르고, Specific Inspection settings profiles 를 선택한 뒤 프로파일을 고르면 선택한 프로파일의 설정만 보입니다.

사용자 정의 프로파일 편집 — Inspection Settings > Profiles 뷰에서 프로파일을 선택하고 Delete(삭제) 또는 Edit(이름·색상·태그 변경)를 누릅니다. 속성을 바꿨으면 OK 로 저장합니다.

새 프로파일 추가 — Profiles 뷰에서 New 를 누르고 New Profile 창에서 속성을 편집한 뒤 OK 를 누릅니다.

Security Gateway에 프로파일 할당 — Inspection Settings > Gateways 뷰에서 Security Gateway를 선택하고 Edit 를 누른 뒤, 검사 설정 프로파일을 골라 OK 를 누릅니다.

검사 설정 예외 구성 — Inspection Settings > Exceptions 뷰에서 New 로 새 예외를 추가하거나 기존 예외를 선택해 Edit 로 수정하면 Exception Rule 창이 열립니다. 예외 설정은 다음과 같습니다.

변경을 적용하려면 Access Control Policy를 설치 해야 합니다.

SmartTasks — 관리 작업 자동화

Management SmartTasks 는 시스템의 여러 트리거(trigger)에 따라 자동 동작을 수행하게 해 줍니다. SmartTask는 트리거(trigger)와 동작(action)의 조합 입니다.

사용 가능한 트리거 (Available Triggers)

  blade:"CloudGuard IaaS" AND severity:Critical
  

Management Server는 이런 이벤트를 다음 JSON 형식으로 만듭니다.

  {
      "severity": "<VALUE1>",
      "log-description": "<VALUE2>",
      "product": "CloudGuard IaaS",
      "gateway-name": "<VALUE3>",
      "datacenter-name": [
      "<VALUE4>",
      "<VALUE5>",
      "...",
      "<VALUEx>"
      ],
  "version": "1.0"
  }
  

Run Script 동작에 쓸 수 있는 예시 스크립트는 다음과 같습니다.

  #!/bin/sh
  input=$(echo $1 | base64 --decode)
  severity=$(echo $input | jq '.severity')
  message=$(echo $input | jq '."log-description"')
  gw_name=$(echo $input | jq '."gateway-name"')
  dc_name=$(echo $input | jq '."datacenter-name"')

  echo -e "Subject: CloudGuard Controller event\r\n\r\nSeverity: $severity\r\nMessage: $message\r\nData Center: $dc_name\r\nGateway: $gw_name" | sendmail --domain=acme.com -f no-reply@acme.com -v admin@acme.com --host=smtp.acme.com > /dev/null
  echo "Email sent"
  

사용 가능한 동작 (Available Actions)

"Before" 계열 트리거로 실행되는 SmartTask에서는, 리포지토리 스크립트가 "result"(필수)와 "message"(선택) 필드를 가진 JSON 객체를 출력하고 종료 코드 0으로 끝냄으로써 작업을 중단할지 계속할지 신호 를 줄 수 있습니다. "result" 값이 "failure" 이면 작업이 중단됩니다. 그 밖의 트리거에서는 종료 코드 0이 성공, 그 외 코드는 실패로 처리됩니다.

"Before" 계열 트리거에서는 스크립트가 "result"·"message" 필드를 가진 JSON 객체와 200 OK 상태로 응답해 작업 중단/계속을 신호할 수 있습니다. "result" 가 "failure" 이면 작업이 중단됩니다. 그 밖의 트리거에서는 200 OK 가 성공, 그 외 코드는 실패로 처리됩니다. - Send Mail — 설정한 이메일을 보냅니다.

SmartTask 속성 구성하기

SmartTask 고급 속성 (Advanced Properties)

고급 옵션은 General 탭에서 고른 동작에 따라 달라집니다.

Send Web Request

Run script

Send Email — 다음 이메일 항목을 입력합니다 — To, Cc, Sender, Subject, Attachment, Body text.

To, Cc, Sender 의 사전 정의 옵션은 SmartConsole에 이메일 주소가 정의된 관리자에게만 쓸 수 있습니다. Identity Provider로 접속한 관리자에게는 쓸 수 없습니다. 이메일이 정의되지 않은 관리자라면, 해당 이메일 주소를 직접 입력하거나, 이메일 프로그램에서 관리자들의 메일링 리스트를 만들어 해당 필드에 쓰세요. 예를 들어 After Session Approve SmartTask에서 검토자가 제출자의 변경을 검토·승인하는 경우, To 에는 사전 정의된 "Submitter email" 대신 모든 제출자의 메일링 리스트를, Cc 에는 "All reviewers" 대신 모든 검토자의 메일링 리스트를, Sender 에는 "Reviewer email" 대신 SmartTask@mycompany.com 같은 더미 이메일을 넣습니다.

예제 — 게시 전 세션 이름 접두사 검증

사용 사례 — 회사 정책상, 데이터베이스에 변경을 저장하기 전에 publish 작업의 세션 이름 앞에 서비스 요청 번호를 접두사로 붙여야 한다고 합시다. 그래야 보안 정책을 왜 바꿨는지 관리자들이 알 수 있습니다.

1단계 — 스크립트를 Scripts Repository에 추가. Gateways & Servers > Scripts > Scripts Repository > New 를 클릭하고 스크립트에 이름을 준 뒤, Content 입력란에 아래 코드를 붙이고 OK 로 저장합니다.

#!/bin/bash
JQ=${CPDIR}/jq/jq
data=`echo $1 | base64 --decode -i`
# Extracting the required session name prefix for the session name based on the input JSON
sessionNamePrefix=`echo $data | $JQ -r  .\"custom-data\".\"session-name-prefix\"`
# If there's no input session name prefix, publish is allowed
if [[ $sessionNamePrefix = "null" ]] || [[ -z "$sessionNamePrefix" ]]; then
printf '{"result":"success"}\n'
exit 0
fi
# Extracting the actual session name
sessionName=`echo $data | $JQ -r .session.\"session-name\"`
# Abort the publish if the session doesn't contain a name at all
if [[ $sessionName = "null" ]]; then
    m1="Corporate Policy requires you to use a service request number for the session's name prefix."
    m2="For example: ${sessionNamePrefix}######"
    m3="Session name is missing. Please change your session's name to meet the requirements and try to publish again."
printf '{"result":"failure","message":"%s %s %s"}\n' "$m1" "$m2" "$m3"
exit 0
fi
# Abort the publish if the session name doesn't match the expected prefix
if [[ ! $sessionName == $sessionNamePrefix* ]]; then
    m1="Corporate Policy requires you to use a ticket number as the session's name."
    m2="For example: ${sessionNamePrefix}###### "
    m2=${m2//\"/\\\"}
    m3="Please change your session's name to meet the requirements and publish again."
printf '{"result":"failure","message":"%s %s %s"}\n' "$m1" "$m2" "$m3"
exit 0
else

2단계 — 세션 검증 스크립트를 실행할 SmartTask 생성. Manage & Settings > Tasks > SmartTasks > New 로 가서 SmartTask에 이름(예: Validate Session Name Before Publish)을 줍니다. Trigger and Action 섹션에서 드롭다운으로 Before Publish 와 Run Script 를 고르고, Select script from repository 에서 1단계에서 저장한 스크립트를 고릅니다. Custom Data 필드에 다음 문자열을 입력합니다.

{"session-name-prefix": "CR"}

3~5단계 — SmartConsole 세션을 게시하고, 네트워크 객체를 하나 추가한 뒤, 요구된 접두사를 붙여 변경을 게시합니다.

Management High Availability(HA) 는 관리 서버의 이중화(redundancy)와 데이터베이스 백업 입니다. 동기화된 서버들은 같은 정책·규칙·사용자 정의·네트워크 객체·시스템 구성 설정 을 갖습니다.

Management HA는 내장 리비전 기술을 사용해 마지막 동기화 이후의 변경분만 동기화 합니다. 덕분에 다음을 얻습니다.

처음 설치한 관리 서버가 Primary 입니다. Primary Security Management Server가 장애가 나거나 유지보수로 오프라인이 되면, 관리자가 changeover(전환) 를 시작해 Secondary 서버가 역할을 넘겨받게 할 수 있습니다.

고가용성 환경의 구성

Management HA 환경에는 다음이 포함됩니다.

완전한 이중화를 위해, Active 관리 서버는 일정 간격으로 Secondary 서버(들)와 데이터베이스를 동기화합니다.

Active 대 Standby

표준 HA 구성에서는 한 번에 하나의 Active 서버 만 있습니다. 관리자는 Active 서버로 HA 구성을 관리합니다. Active 서버는 일정 간격으로 Standby 서버(들)를 자동 동기화합니다. Standby 서버는 읽기 전용(Read Only) 모드로만 열 수 있습니다. Active 서버가 장애가 나면 changeover를 시작해 Standby를 Active로 만들 수 있습니다. Active 서버와 통신이 끊기면 Active 서버가 둘 이상 생길 수 있는데, 이를 Collision Mode(충돌 모드) 라고 합니다.

Primary 서버 대 Secondary 서버

관리 서버를 설치한 순서가 Primary인지 Secondary인지를 정합니다. 처음 설치한 서버가 Primary active 서버 가 됩니다. 이후 설치하는 Security Management Server는 Secondary로 정의하며, Secondary 서버는 기본적으로 Standby 입니다.

SmartConsole에서 Secondary 서버 구성하기

Primary Security Management Server에 연결된 SmartConsole에서 Secondary 서버용 Check Point Host 객체를 만듭니다. SmartConsole 세션을 게시하면 Primary와 Secondary 사이의 동기화가 시작됩니다.

Active와 Standby 동기화

Active 서버는 일정 간격으로, 그리고 세션을 게시할 때 Standby 서버(들)와 동기화합니다. 게시되지 않은 세션은 동기화되지 않 습니다.

고가용성 모니터링

High Availability Status 창은 HA 구성의 각 Security Management Server 상태를 보여 줍니다. SmartConsole을 열어 Primary 또는 Secondary 서버에 연결한 뒤, Menu > High Availability 를 클릭하면 창이 열립니다. 이 창은 관리 서버와 그 피어(들)에 대해 다음을 보여 줍니다.

동기화 상태와 동작 모니터링

상태 메시지는 시스템 전체에 적용되는 일반(general) 메시지 이거나, 특정 Active/Standby 서버에만 적용되는 메시지일 수 있습니다. 일반 메시지는 노란색 개요 배너(overview banner)에 나타납니다.

특정 Active 관리 서버에 연결됐을 때:

특정 Standby 관리 서버에 연결됐을 때:

서버를 Active 또는 Standby로 바꾸기

Active 서버는 일정 간격으로, 그리고 세션을 게시할 때 Standby와 동기화합니다(게시되지 않은 세션 제외). Primary(active)와 Secondary(standby) 사이의 changeover는 자동이 아니라 관리자가 수동으로 해야 합니다. 관리 서버가 Standby가 되면 읽기 전용(Read Only) 이 되고, 새 Active 서버로부터 모든 변경을 받습니다.

changeover를 시작하면, Standby가 Active가 된 뒤 모든 공개 데이터(public data)가 새 Active에서 새 Standby로 동기화 됩니다. 즉 새 Active의 데이터가 새 Standby의 데이터를 덮어씁니다. 게시되지 않은 변경은 동기화되지 않습니다.

Active와 Standby 맞바꾸기

Collision Mode(충돌 모드)에서 작업하기

서버를 둘 이상 Active로 만들 수 있습니다. Primary에 연결이 안 될 때 이렇게 해야 할 수 있습니다. Standby를 Active로 바꾸면, 현재 Active 서버에게 Standby가 되라고 알리지 않은 채 그 서버가 Active가 됩니다 — 이것이 collision mode입니다. 나중에 둘 중 하나를 Standby로 바꾸면 표준 구성으로 돌아갑니다.

Collision mode에서는 두 Active 서버가 네트워크로 연결돼 있어도 동기화하지 않 습니다. 둘 중 하나를 Standby로 바꾸면 동기화가 시작되어, 남은 Active의 데이터가 Standby 서버의 데이터를 덮어씁 니다.

고가용성 문제 해결

동기화가 실패하면 High Availability Status 창에 다음 오류 메시지가 나타납니다.

관리자 잠금 해제 (Unlocking the Administrator)

HA 환경에서 관리자가 Standby 관리 서버에서 잠기면(locked), 그 관리자는 Active 관리 서버에서는 잠긴 것으로 보이지 않 습니다. 따라서 Active 관리 서버에서는 그 관리자를 잠금 해제할 수 없습니다. 잠금을 풀려면, Standby 관리 서버에서 API 명령 unlock-administrator를 실행하세요(Check Point Management API Reference 참고). 관리자 계정 관련 내용은 관리자·사용자 계정도 참고하세요.

Endpoint Security가 있는 환경

Endpoint Security를 포함하는 환경은 추가 단계와 정보가 필요합니다. 자세한 내용은 R82 Harmony Endpoint Security Server Administration Guide의 High Availability 를 참고하세요.

고가용성 재해 복구 (Disaster Recovery)

처음 설치한 관리 서버가 Primary이고 이후 설치한 서버는 모두 Secondary입니다. Primary는 동기화 마스터(synchronization master) 역할을 합니다. Primary가 다운되면, Secondary가 Primary로 승격되고 초기 동기화가 끝나기 전까지는 Secondary 서버들이 데이터베이스를 동기화할 수 없 습니다.

Primary 관리 서버를 영구히 못 쓰게 됐다면, Secondary를 Primary로 승격하고 원래 Primary의 IP 주소로 새 Primary를 만드는 절차를 따릅니다.

2단계 승격의 세부 절차는 다음과 같습니다.

   cpstop
   

원래 구성으로 되돌리기(원래 Primary를 다시 Primary로) — 위와 같은 방식으로, 새 Secondary 서버를 Active로 바꾸고 Primary로 승격(promote_util → cpstop → mgha* 제거 → mgmtha 라이선스 확인 → cpstart → 옛 Primary 객체 인스턴스 제거 후 install database)한 다음, 옛 Primary IP로 새 Secondary를 설치하고 SIC를 리셋·생성합니다.

Check Point Compliance 블레이드 는 Check Point 보안 인프라를 끊임없이 모니터링 하는 동적 솔루션입니다. CCM(Continuous Compliance Monitoring) 기술로 Security Gateway, Software Blade, 정책, 구성 설정을 방대한 규제 표준·보안 모범 사례 DB와 대조 하고, 보안 문제를 바로잡을 시정 조치(corrective measures)를 제안 합니다.

Compliance 블레이드는 다음 자동 스캔을 수행합니다.

물론 수동 스캔(manual scan) 도 할 수 있습니다.

블레이드 켜기 — SmartConsole의 Gateways & Servers 뷰에서 Security Management Server 객체를 더블클릭해 편집기를 열고, General Properties 페이지의 Management 에서 Compliance 를 선택한 뒤 OK 를 누릅니다.

대시보드 보기 — Logs & Events 뷰에서 + 를 눌러 새 탭을 열고 Compliance 를 클릭합니다.

Compliance 뷰

Compliance 뷰는 다섯 개의 위젯으로 이루어집니다 — Security Best Practices, Gateways, Blades, Action Items and Messages, Regulatory Compliance.

Compliance 점수 체계

Compliance 블레이드는 조직의 Security Gateway, Software Blade, 규정마다 각 모범 사례 테스트에 대해 숫자 점수 를 계산합니다. 점수는 검사된 각 객체의 테스트 결과의 평균입니다.

Security Best Practices 뷰

이 뷰는 각 모범 사례(best practice)의 상태 정보를 보여 줍니다. 위쪽 표에는 다음이 나옵니다.

아래 섹션에는 선택한 모범 사례 테스트에 대해 다음이 나옵니다.

검색 — 검색창에 문자열을 입력합니다. 특정 필드에서 특정 값을 찾으려면 필드명:문자열 형식으로 입력합니다. 결과를 묶으려면 grouping 필드에서 Blade 또는 Status 를 고르고, 특정 필드로 정렬하려면 해당 필드 헤더를 누릅니다.

사용자 정의 모범 사례 만들기

조직의 보안 요구에 맞춰 자신만의 사용자 정의 Security Best Practice를 정의할 수 있습니다.

새 Firewall Security Best Practice 만들기 — Compliance 탭 > Security Best Practices 창에서 See All 을 누르고, New > Firewall Best Practice 를 고르면 New Firewall Best Practice 창이 열립니다.

(선택) Advanced Settings 를 눌러 스캔할 Rule Base의 비율과 방향(Top 또는 Bottom)을 고릅니다. 예를 들어 Bottom 30% 를 고르면 Rule Base의 맨 아래(마지막 규칙)부터 30%를 스캔합니다.

새 Gaia OS Security Best Practice 만들기 — See All > New > Gaia OS Best Practice 를 고르면 창이 열립니다.

모범 사례 테스트 활성화·비활성화

모범 사례의 시행을 테스트별, Security Gateway별, Software Blade별, 또는 다른 객체별로 활성화·비활성화할 수 있습니다. 활성화 변경은 다음 스캔 이후에 적용 됩니다. 기본적으로 모든 모범 사례 테스트는 활성 상태입니다.

조직 전체에서 모범 사례 비활성화 — Security Best Practices 뷰에서 모범 사례를 선택하고 우클릭 → Deactivate 를 고르면 Expiration Details 창이 열립니다. Never(영구) 또는 만료 날짜를 입력하고(만료 날짜를 고르면 그날 자동으로 다시 활성화됩니다), Comment 에 비활성화하는 이유를 적습니다.

비활성 모범 사례 활성화 — Security Best Practices 뷰에서 모범 사례를 선택해 우클릭 → Activate 를 고릅니다. 또는 Manage & Settings > Blades > Compliance > Inactive Objects > Inactive Security Best Practices 에서 해당 모범 사례를 선택하고 Remove 를 누릅니다.

특정 Security Gateway에 대해 비활성화 — Manage & Settings > Blades > Compliance > Inactive Objects 로 가서 Inactive Gateways 섹션에서 Add 를 누르고 Security Gateway나 Cluster를 입력·선택합니다.

특정 객체에 대해 비활성화 — Manage & Settings > Blades > Compliance > Inactive Security Best Practices on Specific Objects 로 가서 Inactive Gateways 섹션에서 Add 를 누르고 Security Gateway나 Cluster를 입력·선택합니다.

Gateways 뷰

이 위젯은 Security Gateway의 보안 상태를 보여 줍니다 — Compliance 점수가 가장 높은 5개, 가장 낮은 5개, 또는 사전 정의한 Favorites 집합. 모든 게이트웨이 결과를 보려면 See All 을 누릅니다. 특정 게이트웨이/클러스터에 적용되는 모범 사례를 보려면 해당 게이트웨이/클러스터를 클릭합니다. 위쪽 표(Active·Blade·ID·Name·Status)와 아래 섹션(Description·Action Item·Dependency·Relevant Objects·Relevant Regulatory Requirements)의 구성은 Security Best Practices 뷰와 같습니다.

Blades 뷰

이 위젯은 Software Blade별 보안 상태를 보여 줍니다 — 구현된 보안 모범 사례 수가 가장 많은 5개 블레이드의 평균 점수. 특정 블레이드 결과를 보려면 클릭하고, 전체를 보려면 See All 을 누릅니다. 위쪽 표와 아래 섹션의 구성은 Security Best Practices 뷰와 동일합니다.

Action Items and Messages 뷰

모범 사례 테스트가 결함을 발견하면, Compliance 블레이드는 자동으로 Action Item(조치 항목) 을 생성합니다. Action Item은 결함을 바로잡을 시정 조치 설명을 보여 줍니다. Action Item에 due date(기한)를 부여하고 시정 단계를 모니터링할 수 있습니다. Action Item이 생성될 때는 기한이 자동 부여되지 않 습니다. 시정 단계를 마치면 다음 스캔 후 Compliance 블레이드가 그 Action Item을 삭제 합니다.

이 위젯에는 세 개 섹션이 있습니다.

상태 범주별 조치 항목을 열려면 Action Items 를 클릭합니다. 위쪽 표에는 Due Date, Blade, ID, Name, Status 가, 아래 섹션에는 Action Item Description, Due Date, Dependency, Relevant Objects, Relevant Regulatory Requirements 가 나옵니다. - Alert Messages — 구성 변경으로 Compliance 상태가 떨어질 때 경보가 생성됩니다. 모든 경보를 보려면 Security Alerts 를 클릭합니다. - System Messages — Compliance 관련 시스템 문제(예: Compliance 패키지 업데이트)를 알립니다. 모두 보려면 System Messages 를 클릭합니다.

Action Item에 기한 부여하기 — Logs & Events > Compliance 탭 > Action Items and Messages > Pending Action Items > Unscheduled items 에서 항목을 선택하고, Action Item Description 섹션에서 Schedule Now 를 누릅니다(이미 기한이 있으면 날짜 링크를 눌러 변경). 창에서 날짜를 입력·선택하고 OK 를 누릅니다.

Regulatory Compliance 뷰

이 위젯은 선택한 규제 표준에 대한 Compliance 통계를 보여 줍니다 — 각 표준에 대해 검사된 규제 요구 사항의 수와 평균 Compliance 점수입니다.

표시할 규제 표준 고르기 — Regulatory Compliance 창 오른쪽 위 아이콘을 클릭하고, Select Regulations and Standards 창에서 개요에 보일 표준을 고릅니다. 모든 규제 요구 사항의 점수를 보려면 See All 을 누릅니다. 특정 표준을 클릭하면 위쪽 표에 ID, Status, Name 이, 아래 섹션에 Description, Relevant best practices(해당 요구 사항의 모범 사례와 그 상태), Relevant objects 가 나옵니다.

규제 표준 활성화·비활성화 — 기본적으로 지원되는 모든 규제 표준이 활성 상태입니다. Manage & Settings > Blades > Compliance > Settings 로 가서 Active Regulations 섹션에서 표준을 선택/해제한 뒤 변경을 Publish 합니다.

규제 표준 가져오기(import) — 표준을 로컬에 XML 파일로 저장한 뒤, Manage & Settings > Blades > Compliance > Settings 로 가서 Active Regulations 섹션의 Actions > Import 를 누르고 XML 파일을 골라 Open 합니다. 그러면 그 규정이 User-defined Regulations 목록에 나타납니다. 규정을 더블클릭해 창을 열고 Save 를 누릅니다(몇 분 걸릴 수 있음). 그런 다음 변경을 Publish 합니다.

보고서 만들기 (Creating Reports)

Compliance 상태 요약이나 특정 규제 표준의 이행 보고서를 생성할 수 있습니다.

일반 보고서 — Logs & Events 뷰에서 + 로 새 탭을 열고 Reports 뷰를 고른 뒤, 목록에서 Compliance Blade 를 골라 Open 합니다. (선택) 툴바의 Actions 에서 PDF·CSV 형식으로 보고서를 만들 수 있습니다. 내보낸 보고서는 Logs & Events 뷰에서 새 탭을 열어 Archive 에서 찾습니다.

규정별 보고서 — Compliance 뷰의 Regulatory Compliance 창에서 See All 을 선택하고, 원하는 규제 표준을 클릭한 뒤 상단 툴바에서 Generate Report 를 누릅니다. 출력 형식은 PDF document, 첨부 PDF가 있는 이메일, 프린터 출력, 브라우저 HTML 출력 중에서 고릅니다.

온프레미스 Management Server와 Security Gateway를 Infinity Portal 에 연결할 수 있습니다. 이렇게 하면 다음이 가능합니다.

사전 요구 사항 (Prerequisites)

SmartConsole에서 서버·게이트웨이 객체를 Infinity Portal에 연결

구성 정보 공유 (Configuration Sharing)

로그 정보 공유 (Log Sharing)

Security Gateway 연결 타이밍 구성

서비스 연결과 문제 해결

SmartConsole에서 Infinity Portal의 서비스에 연결하려면, 왼쪽 탐색 패널에서 Infinity Services 를 클릭하고 해당 서비스로 가서 연결합니다(각 서비스 자세한 내용은 Infinity Portal Administration Guide 참고). 문제 해결은 sk181504 를 참고하세요.

Check Point 제품은 API 명령을 지원합니다(Check Point API Reference 참고). Management Server의 Gaia API Proxy 기능을 쓰면, 관리되는 Security Gateway와 Cluster Member에서 Gaia API 명령을 실행 할 수 있습니다.

R82 Management Server의 Gaia API Proxy 기능은 Gaia API를 지원하는 모든 관리 대상 Security Gateway·Cluster Member 와 동작합니다.

작업 흐름 (Workflow)

1. Management API login 명령으로 Management Server에 로그인. API Client에서 Check Point API login 명령을 실행해 Management Server에 로그인합니다.

2. 관리 대상에서 Gaia API 명령 실행. login 명령은 SID(Session Unique Identifier) 토큰 을 반환합니다. 같은 API Client에서, 관리 대상 Security Gateway·Cluster Member에 실행할 Gaia API 명령의 X-chkp-sid 필드에 이 SID 토큰을 씁니다. Gaia API 구문은 다음과 같습니다.

POST https://<IP Address of Management Server>/web_api/gaia-api/<Gaia API Version>/<Gaia API Command>

Gaia API 명령의 본문(body)은 다음 파라미터 중 하나로 관리 대상 Security Gateway·Cluster Member를 식별 해야 합니다.

3. Gaia API Proxy가 지정 대상에 로그인. Management Server의 Gaia API Proxy가 명령을 해석해 지정된 Security Gateway·Cluster Member에 로그인합니다.

4. Gaia API Proxy가 응답을 API Client로 전달.

예제

예제 1 — show-hostname (객체 기본 IP 주소로 식별):

POST https://<IP Address of Management Server>/gaia-api/show-hostname
Content-Type: application/json
X-chkp-sid: <Session ID>
{
"target" : "192.168.1.1"
}

응답:

{
"command-name" : "show-hostname",
"response-message" : {
"name" : "gw-832546"
}
}

예제 2 — show-interfaces (객체 이름으로 식별, Gaia API 버전 v1.4):

POST https://<IP Address of Management Server>/gaia-api/v1.4/show-interfaces
Content-Type: application/json
X-chkp-sid: <Session ID>
{
"target" : "gw-832546",
"name" : "eth0"
}

응답:

{
"command-name" : "v1.4/show-interfaces",
"response-message" : {
"ipv6-local-link-address": "Not Configured",
"type": "physical",
"name": "eth0",
"ipv6-mask-length": "Not-Configured",
"ipv6-address": "Not-Configured",
"ipv6-autoconfig": "Not configured",
"ipv4-address": "192.168.1.1",
"enabled": true,
"comments": "",
"ipv4-mask-length": "24"
}
}

예제 3 — show-diagnostics (객체 UID로 식별):

POST https://<IP Address of Management Server>/gaia-api/v1.4/show-diagnostics
Content-Type: application/json
X-chkp-sid: <Session ID>
{
"target" : "52048978-c507-8243-9d84-074d11154616",
"category" : "os",
"topic" : "disk"
}

응답:

{
"command-name" : "v1.4/show-diagnostics",
"response-message" : {
"to": 3,
"total": 3,
"from": 1,
"objects": [
{
"total": "34342961152",
"partition": "/",
"used": "5718065152",
"free": "28624896000"
},
{
"total": "304624640",
"partition": "/boot",
"used": "26991616",
"free": "277633024"
},
{
"total": "34342961152",
"partition": "/var/log",
"used": "455684096",
"free": "33887277056"
}
]
}
}