07게이트웨이 만들기·관리게이트웨이 만들기·관리

게이트웨이에 정책을 설치하려면 먼저 SmartConsole에서 게이트웨이 객체를 정의해야 합니다. 흐름은 이름·IP 입력 → Communication 으로 신뢰 맺기 → 플랫폼(어플라이언스 모델) 선택 → One-time password 입력 → Initialize 로 SIC 신뢰 수립 → 토폴로지 가져오기 → 하드웨어·버전·OS 지정 → 켤 Software Blade 선택 입니다. 단계별로 따라가 봅시다.

여기서 두 가지가 핵심입니다. 첫째, 플랫폼(어플라이언스 모델)을 정확히 골라야 합니다 — 틀리면 정책 설치가 실패할 수 있습니다. 둘째, 모든 신뢰의 바탕은 SIC(Secure Internal Communication) 이라서(인증 인프라), 관리 서버와 게이트웨이가 SSL로 서로를 인증 합니다.

네트워크가 바뀌면 게이트웨이의 토폴로지를 갱신 해야 합니다. 토폴로지는 어느 인터페이스가 내부망을 향하고 어느 인터페이스가 외부망을 향하는지를 알려 주는 지도이며, 이 정보로 Anti-Spoofing(스푸핑 방지)이 동작합니다. 갱신 방식은 수동 과 동적 두 가지입니다.

수동으로 토폴로지 갱신하기

Get Interfaces API

SmartConsole 대신 Check Point API로 Get Interfaces 명령을 실행할 수도 있습니다. API 방식은 GUI보다 강력합니다.

Get Interfaces API 명령은 Gaia 운영체제에서 동작하는 Security Gateway와 ClusterXL만 지원 합니다. 사용법은 Check Point Management API Reference를 참고하세요.

동적으로 토폴로지 갱신하기

동적 토폴로지 갱신은 관리자가 Get Interfaces 를 누르거나 정책을 설치하지 않아도 내부 인터페이스 뒤의 IP 주소 범위를 기본 1초마다 자동으로 다시 계산 하게 해 줍니다. 이 기능은 Security Gateway R77.20 이상 에서만 지원됩니다.

동적 갱신을 켜는 방법은 이렇습니다.

기본 갱신 주기는 SmartConsole > Preferences 에서 1초로 설정되어 있고, 여기서 정한 값은 Domain 안의 모든 게이트웨이의 모든 내부 인터페이스에 적용 됩니다. 특정 인터페이스에만 다른 주기를 주려면 다음과 같이 합니다.

동적 Anti-Spoofing

Anti-Spoofing이 켜진 상태에서 Get Interfaces 를 누르면, 게이트웨이는 인터페이스의 IP 주소·넷마스크와 그 인터페이스에 할당된 경로(route)를 바탕으로 유효한 IP 주소 목록 을 만듭니다. Anti-Spoofing은 패킷이 들어온 인터페이스 뒤의 네트워크에 속하지 않는 출발지 IP를 가진 패킷을 폐기 합니다. 예를 들어 외부 인터페이스로 들어왔는데 출발지가 내부 IP인 패킷을 막습니다.

여기서 Network defined by routes 옵션을 Perform Anti-Spoofing based on interface topology 와 함께 선택하면 동적 Anti-Spoofing 이 됩니다. 이렇게 하면 관리자가 Get Interfaces 를 누르거나 정책을 설치하지 않아도 유효 IP 범위가 자동으로 계산됩니다.

Network Object(네트워크 객체) 는 SmartConsole에서 정의하고 Check Point 고유의 객체 데이터베이스에 저장됩니다. 객체는 물리·가상 네트워크 구성요소(게이트웨이, 서버, 사용자 등)와 논리 구성요소(IP 주소 범위, Dynamic Object 등) 를 나타냅니다. 객체를 만들기 전에 조직의 필요를 먼저 분석하세요.

객체 범주(Object Categories)

SmartConsole은 객체를 다음 범주로 나눕니다.

객체로 할 수 있는 작업(Actions with Objects)

객체는 추가·편집·삭제·복제(clone)할 수 있습니다. clone 은 이름만 다른 원본의 복사본 입니다. 정책 안의 한 객체를 다른 객체로 교체(replace) 할 수도 있습니다. 작업하려면 객체 트리나 Object Explorer 에서 객체를 오른쪽 클릭하고 원하는 동작을 고릅니다. 사용되지 않는 객체는 삭제 할 수 있고, 어떤 객체가 어디에 쓰이는지(Where Used) 도 찾아볼 수 있습니다.

객체 복제(clone): 객체를 오른쪽 클릭 → Clone → Clone Object 창에서 복제본 이름 입력 → OK.

객체가 어디 쓰이는지 찾기: 객체를 오른쪽 클릭 → Where Used.

한 객체를 다른 객체로 교체: 객체를 오른쪽 클릭 → Where Used → Replace 아이콘 클릭 → Replace with 목록에서 대상 선택 → Replace.

객체의 모든 사용처를 한꺼번에 삭제: 객체를 오른쪽 클릭 → Where Used → Replace 아이콘 클릭 → Replace with 목록에서 None (remove item) 선택 → Replace.

추가로 기억할 점이 두 가지 있습니다. 기존 객체("객체 1")의 편집기 안에서 새 객체("객체 2")를 만들면 객체 2가 객체 1 편집기에 바로 나타나지 않을 수 있으니, 객체 1을 OK 로 닫았다 다시 열면 보입니다. 그리고 SmartConsole에서는 이름이 두 글자 이상인 객체만 검색·필터할 수 있습니다.

객체 태그(Object Tags)

Object tag 는 검색을 위해 네트워크 객체나 객체 그룹에 붙이는 키워드 또는 라벨 입니다. 두 가지 유형이 있습니다.

각 태그는 이름과 값을 가지며, 값은 정적이거나 탐지 엔진이 동적으로 채울 수도 있습니다.

객체에 태그를 다는 방법: (1) 네트워크 객체를 편집용으로 엽니다. (2) Add Tag 필드에 라벨을 입력합니다. (3) Enter 를 누르면 태그가 필드 오른쪽에 표시됩니다. (4) OK 를 클릭합니다.

네트워크 객체 유형

Networks(네트워크)

Network 는 네트워크 주소와 넷마스크로 정의되는 IP 주소의 묶음 입니다. 넷마스크는 네트워크의 크기를 나타냅니다. Broadcast IP 는 지정한 네트워크의 모든 호스트로 향하는 주소인데, 이 주소를 포함시키면 브로드캐스트 IP도 네트워크의 일부로 간주됩니다.

Network Groups(네트워크 그룹)

Network Group 은 호스트, 게이트웨이, 네트워크, 또는 다른 그룹의 모음 입니다. 같은 객체 집합을 Rule Base의 여러 곳에서 쓸 때, 그룹으로 묶어 두면 그룹 하나만 수정해도 모든 사용처에 반영 되어 관리가 간단해집니다. 또 SmartConsole이 객체를 하나만 고르게 하는 곳에서 여러 객체가 필요할 때도 그룹이 쓰입니다. 예를 들어 Security Gateway > Network Management > VPN Domain > Manually defined 에서는 드롭다운에서 객체를 하나만 고를 수 있는데, 여러 개를 넣고 싶으면 그룹을 만들어 드롭다운에서 그 그룹을 고르면 됩니다.

네트워크 객체 그룹을 만드는 방법:

R80.20.M2 버전부터는 객체 편집기에서 직접 그 객체를 그룹들에 연결 할 수도 있습니다. 객체 편집기를 열고 탐색 트리에서 Groups 로 간 뒤, 추가할 그룹마다 [+] 를 클릭해 고르면 됩니다.

Check Point Hosts

Check Point Host 는 여러 인터페이스를 가질 수 있지만 라우팅은 하지 않는 종단점입니다. 자기 인터페이스로 들어온 트래픽을 자신이 받습니다(반면 Security Gateway는 여러 인터페이스 사이에서 트래픽을 라우팅합니다). 예를 들어 서로 연결되지 않은 두 네트워크가 공용 관리 서버·Log Server를 함께 쓴다면, 그 공용 서버를 Check Point Host 객체로 구성합니다.

Check Point Host는 하나 이상의 Software Blade를 설치하지만, Firewall 블레이드를 켜더라도 Security Gateway로는 동작하지 못합니다. Host는 실제 Security Gateway가 제공하는 SIC 등의 기능을 필요로 합니다. Check Point Host는 라우팅 기능이 없고, IP 포워딩을 못 하며, Anti-Spoofing 구현에도 쓸 수 없습니다. 이런 일이 필요하면 Security Gateway로 전환 해야 합니다. 관리 서버 객체 자체도 Check Point Host 입니다.

Gateway Cluster(게이트웨이 클러스터)

cluster 는 하나의 논리 객체로 구성된 여러 Security Gateway의 묶음 입니다. 클러스터로 묶인 게이트웨이는 High Availability(고가용성)나 Load Sharing(부하 분산)으로 이중화 를 더합니다. 자세한 내용은 ClusterXL 가이드를 참고하세요.

Address Ranges(주소 범위)

Address Range 는 가장 낮은 IP와 가장 높은 IP로 정의되는 IP 주소의 범위 입니다. 네트워크 IP와 넷마스크로는 범위를 정의할 수 없을 때 사용합니다. NAT와 VPN 구현에도 Address Range 객체가 필요 합니다.

Wildcard Objects(와일드카드 객체)

Wildcard object 는 공통 패턴을 공유하는 IP 주소 객체 로, 그 패턴에 맞는 주소들을 보안 정책에서 한꺼번에 허용·차단할 수 있습니다. 이 기능은 Security Gateway R80.20 이상 에서만 지원됩니다.

만드는 방법: Object Explorer > New > More > Network Object > Wildcard object 를 열고, Wildcard IP address 와 Wildcard Netmask 를 IPv4나 IPv6 형식으로 입력한 뒤 OK 를 클릭합니다.

와일드카드 객체 이해하기

와일드카드 객체는 wildcard IP 주소 와 wildcard 넷마스크 로 이뤄집니다. wildcard 넷마스크는 IP 주소 중 어느 비트가 반드시 일치해야 하고 어느 비트는 아무 값이어도 되는지 를 나타내는 비트 마스크입니다.

Wildcard IP      : 194.29.0.1
Wildcard Netmask : 0.0.3.0

세 번째 옥텟이 마스크 비트를 나타냅니다. 3을 이진수로 바꾸면 00000011 입니다. 마스크의 0 부분은 IP 주소의 해당 비트와 반드시 일치 해야 하고, 1 부분은 일치하지 않아도 되며 아무 값이나 될 수 있습니다.

0 0 0 0 0 0 1 1
└── 반드시 일치 ──┘ └ 일치 안 해도 됨 ┘

이 이진 넷마스크가 만드는 십진 값은 다음과 같습니다.

따라서 이 넷마스크는 다음 IP 주소만 허용합니다 — 194.29.0.1, 194.29.1.1, 194.29.2.1, 194.29.3.1.

사용 사례 1 — 한 슈퍼마켓 체인의 모든 계산대가 194.29.x.1 서브넷에 있고(x가 지역을 나타냄), 이 지역의 모든 계산대가 194.30.1.1의 데이터베이스 서버에 접근해야 한다고 합시다. 256개의 호스트(194.29.0.1 ~ 194.29.255.1)를 일일이 정의하는 대신, 관리자는 그 지역의 모든 계산대를 나타내는 와일드카드 객체 하나를 만듭니다.

Wildcard IP   : 194.29.0.1
Wildcard Mask : 0.0.255.0

이 객체를 Access Control 정책에 넣습니다.

사용 사례 2 — 슈퍼마켓 체인이 유럽과 아시아에 매장을 두고, 192.30.0-255.1 네트워크가 두 지역과 그 안의 매장을 모두 담는다고 합시다. 세 번째 옥텟에 와일드카드를 걸되, 앞 4비트는 지역, 뒤 4비트는 매장 번호 를 나타내게 합니다.

지역 비트   매장 비트
0000        0000

Wildcard IP에서 아시아 지역은 0001xxxx(십진 Region 1), 유럽 지역은 0010xxxx(십진 Region 2)로 표현합니다.

한 지역의 모든 매장을 포함하려면 와일드카드 마스크의 뒤 4비트를 1(십진 15)로 둡니다.

따라서 모든 아시아 매장을 나타내는 객체는 Wildcard IP 192.30.16.1(지역), Wildcard netmask 0.0.15.0(매장)이 되어 192.30.16-31.1 범위를 가리키고, 모든 유럽 매장은 Wildcard IP 192.30.32.1, Wildcard netmask 0.0.15.0 으로 192.30.32-47.1 범위를 가리킵니다. 이를 정책에 씁니다.

사용 사례 3 — 마스크 비트가 연속되지 않은 경우입니다.

Wildcard IP   : 1.1.0.1   → 00000001.00000001.00000000.00000001
Wildcard Mask : 0.0.5.0   → 00000000.00000000.00000101.00000000

세 번째 옥텟의 마스크 5(= 00000101)에서 비트 위치 21과 23이 "일치 안 해도 됨"으로 풀려, 다음 IP만 매칭됩니다.

IPv6

같은 원리가 IPv6 주소에도 적용 됩니다. 예를 들어 와일드카드 객체가 IPv6 Address 2001::1:10:0:1:41, Wildcard netmask 0::ff:0:0 이면, 2001::1:10:0-255:1:41 을 매칭합니다.

Domains(도메인 객체)

Domain object 는 IP 주소 없이 이름만으로 호스트나 DNS 도메인을 나타내는 객체입니다. Access Control 정책의 Source·Destination 열에 쓸 수 있고, 두 가지 방식으로 구성합니다.

Updatable Objects(자동 갱신 객체)

Updatable Object 는 Office 365, AWS, GEO 위치 같은 외부 서비스를 나타내는 네트워크 객체입니다. 외부 서비스 제공자가 자기 서비스 접근에 쓰이는 IP·도메인 목록을 게시하면, Check Point가 이를 클라우드로 올리고, 제공자가 목록을 바꿀 때마다 게이트웨이의 객체가 자동으로 갱신 됩니다. 업데이트를 적용하려고 정책을 설치할 필요가 없습니다.

Updatable Object는 Access Control, Threat Prevention, HTTPS Inspection 세 가지 정책 모두에서 Source나 Destination으로 쓸 수 있고, Threat Prevention에서는 Protected Scope로도 쓸 수 있습니다.

예를 들어 Office365를 쓰는 고객이 Microsoft Exchange 서비스 접근을 허용하려는 경우, Microsoft Exchange Updatable Object 를 추가합니다.

갱신은 Logs & Events > Logs 뷰에서 추적할 수 있습니다. SmartConsole > Logs & Events로 가서 검색창에 Updatable Objects 를 입력하고 로그를 더블클릭하면 Log Details 창이 열리며, 업데이트가 성공하면 Status 필드에 Succeeded 가 표시됩니다.

Dynamic Objects(동적 객체)

Dynamic Object 는 IP 주소가 게이트웨이마다 다르게 해석되는 "논리" 객체 로, dynamic_objects 명령으로 해석합니다. Security Gateway R80.10 이상 에서는 SecureXL Accept 템플릿을 지원하므로, 동적 객체를 쓴 규칙이나 그 뒤 규칙의 성능에 영향이 없습니다. Dynamic Object는 LocalMachine-all-interfaces 용으로 미리 정의되어 있어, DAIP 컴퓨터의 인터페이스(정적·동적 모두)가 이 객체로 해석 됩니다.

Generic Data Center Objects

R81부터는 외부 웹 서버에 놓인 파일에 정의된 IP 주소 에 대한 접근을 적용할 수 있습니다. 이를 위해 SmartConsole에서 Generic Data Center 객체를 씁니다. 이 객체는 접근하려는 IP 주소가 담긴 외부 서버의 JSON 파일 을 가리키므로, 정책에서 이 객체를 쓰면 SmartConsole이 필요할 때마다 JSON 파일에서 IP 정보를 가져옵니다. JSON 파일은 관리 서버에 로컬로 둘 수도 있습니다.

이 기능은 한 관리자가 Rule Base와 객체를 정의하고 다른 관리자가 객체 내용을 관리하는 상황에 유용하며, Access Control, Threat Prevention, HTTPS Inspection, NAT Rule Base에서 지원됩니다. 단 관리 서버 R81 이상, Security Gateway(Cluster) R81 이상 에서만 지원됩니다. 객체를 만든 뒤에는 파일의 변경이 정책 설치 없이 자동으로 게이트웨이에 적용 됩니다. JSON 파일 작성 지침은 sk167210을 따르세요.

정책에서 쓰는 방법:

제한 사항

Security Zones(보안 영역)

Security Zone 으로 네트워크 부분들 사이의 트래픽을 제어하는 강력한 Access Control 정책 을 만들 수 있습니다. Security Zone 객체는 네트워크의 한 부분(예: 내부망, 외부망)을 나타내며, 게이트웨이의 네트워크 인터페이스를 Security Zone에 할당한 뒤 그 객체를 Rule Base의 Source·Destination 열에 씁니다. Security Zone을 쓰면 같은 규칙을 여러 게이트웨이에 적용 해 정책을 단순화할 수 있고, Rule Base를 바꾸지 않고도 게이트웨이 인터페이스에 네트워크를 추가 할 수 있습니다.

예를 들어 전형적인 네트워크에 세 개의 Security Zone — ExternalZone(1), DMZZone(2), InternalZone(3) — 이 있고, 게이트웨이(4)는 인터페이스 3개를 각각 한 영역에, 게이트웨이(5)는 인터페이스 2개를 ExternalZone과 InternalZone에 할당할 수 있습니다. 게이트웨이의 한 인터페이스는 한 Security Zone에만 속할 수 있지만, 서로 다른 네트워크를 향하는 인터페이스들이 같은 Security Zone에 속할 수는 있습니다.

전체 작업 흐름은 이렇습니다.

Security Zone 만들기: Objects bar(F11)에서 New > More > Network Object > Security Zone 을 클릭 → 이름 입력 → 선택적 주석·태그 입력 → OK.

인터페이스를 Security Zone에 할당하기:

미리 정의된 Security Zone

제한 사항

Externally Managed Gateways and Hosts(외부 관리 게이트웨이·호스트)

Externally Managed Security Gateway/Host 는 Check Point 소프트웨어가 설치되어 있지만 외부 관리 서버가 관리하는 게이트웨이나 호스트입니다. Check Point Security Policy를 받지는 않지만, Check Point VPN 커뮤니티와 솔루션에는 참여 할 수 있습니다.

Interoperable Devices(상호 운용 장비)

Interoperable Device 는 Check Point Software Blade가 전혀 설치되지 않은 장비 입니다. 정책을 설치할 수는 없지만, Check Point VPN 커뮤니티와 솔루션에는 참여 할 수 있습니다.

VoIP Domains(VoIP 도메인)

VoIP Domain 객체에는 다섯 가지 유형이 있습니다 — VoIP Domain SIP Proxy, VoIP Domain H.323 Gatekeeper, VoIP Domain H.323 Gateway, VoIP Domain MGCP Call Agent, VoIP Domain SCCP Call Manager.

많은 VoIP 네트워크에서는 제어 신호(control signal)가 미디어와 다른 경로를 따라 흐릅니다. 신호 라우팅 장비가 통화를 관리할 때가 그렇습니다. SIP에서는 Redirect Server·Registrar·Proxy가, H.323에서는 Gatekeeper·Gateway가 신호를 라우팅합니다. 신호 라우팅 위치를 강제하는 것이 VoIP 보안의 중요한 부분 이며, 신호 라우팅 장비가 관리해도 되는 종단점들을 지정할 수 있는데 이 위치 집합을 VoIP Domain 이라 부릅니다. 자세한 내용은 R82 VoIP Administration Guide를 참고하세요.

Logical Servers(논리 서버)

Logical Server 는 같은 서비스를 제공하는 머신들의 그룹 으로, 작업 부하가 멤버들에 분산됩니다. Server group 필드에 서버 그룹을 지정하면 클라이언트가 그 물리 서버에 묶입니다. 동작 모드는 두 가지입니다.

Balance Method(부하 분산 방식)

부하 분산 알고리즘은 트래픽을 서버들 사이에 어떻게 나눌지를 정합니다.

자세한 내용은 R82 Quantum Security Gateway Guide의 ConnectControl - Server Load Balancing 장을 참고하세요.

Open Security Extension (OSE) Devices

OSE 기능으로 제3자 장비를 Check Point SmartConsole에서 관리 할 수 있습니다. 관리 가능한 장비 수(하드웨어·소프트웨어 패킷)는 라이선스에 따라 다릅니다. OSE 장비는 보통 라우팅·전용 NAT·인증 어플라이언스 같은 하드웨어 보안 장비이며, Security Policy에서 Embedded Devices 로 관리됩니다. 관리 서버는 Security Policy에서 Access List를 만들어 선택한 라우터와 보안 장비로 내려보냅니다.

Check Point Rule Base에 다음 객체가 있으면 관리 서버가 Access List를 생성하지 않으므로 두면 안 됩니다 — Drop(Action), Encrypt(Action), Alert(Action), RPC(Service), ACE(Service), Authentication Rules, Negate Cell.

OSE 장비 인터페이스 정의

OSE 장비는 부팅 시 자신의 네트워크 인터페이스와 설정을 보고합니다. 장비마다 구성을 나열하는 명령이 다르며, 장비마다 인터페이스를 최소 하나는 정의해야 합니다. 그러지 않으면 Install Policy가 실패합니다.

OSE Device Properties — General 탭

Anti-Spoofing 파라미터와 OSE 장비 설정(Cisco)

Cisco(버전 10.x 이상) 장비는 anti-spoofing 파라미터에서 생성되는 필터 규칙의 방향 을 지정해야 하며, 이 방향은 각 라우터의 Setup 탭에서 Spoof Rules Interface Direction 속성으로 정의합니다.

Access List No 는 적용되는 Cisco access list의 번호입니다. Cisco 라우터 12.x 이하는 ACL 번호 범위 101-200 을, 12.x 이상은 101-200 과 2000-2699 를 지원합니다. 2000-2699 범위를 입력하면 더 많은 인터페이스를 지원 할 수 있습니다.

각 자격 증명마다 옵션을 고릅니다 — None(자격 증명 불필요), Known(관리자가 직접 입력), Prompt(관리자에게 입력을 요청).

Check Point 플랫폼·제품은 다음 SIC 수단으로 서로를 인증합니다 — 인증서(Certificates), 안전한 채널 생성을 위한 표준 기반 TLS, 암호화(Encryption). SIC는 게이트웨이·관리 서버·기타 Check Point 구성요소 사이에 신뢰 연결 을 만듭니다. 게이트웨이에 정책을 설치하고, 게이트웨이와 관리 서버 사이에 로그를 주고받으려면 이 신뢰가 반드시 필요합니다.

신뢰 초기화(Initializing Trust)

처음 신뢰를 맺을 때 게이트웨이와 관리 서버는 일회용 비밀번호(one-time password) 를 씁니다. 초기 신뢰가 맺어진 뒤의 통신은 보안 인증서를 기반 으로 합니다.

신뢰를 초기화하는 절차:

이때 ICA가 게이트웨이에 인증서를 서명·발급합니다. 신뢰 상태는 처음에 Initialized but not trusted(초기화됨, 아직 신뢰 안 됨) 가 됩니다. ICA(Internal Certificate Authority, 내부 인증기관)가 게이트웨이용 인증서를 발급했지만 아직 전달하지는 않은 상태입니다. 이어서 두 통신 상대가 공유한 Activation Key로 SSL 위에서 서로를 인증 하고, 인증서를 안전하게 내려받아 게이트웨이에 저장하며, Activation Key는 삭제 됩니다. 이제 게이트웨이는 같은 ICA가 서명한 인증서를 가진 Check Point 호스트들과 통신할 수 있습니다.

SIC 상태(SIC Status)

게이트웨이가 ICA 발급 인증서를 받은 뒤, SIC 상태는 관리 서버가 이 게이트웨이와 안전하게 통신할 수 있는지를 보여 줍니다.

신뢰 상태(Trust State)와 재설정

신뢰 상태가 손상(키 유출, 인증서 분실)되거나 객체가 바뀌면(사용자 퇴사, open server가 어플라이언스로 업그레이드 등) 신뢰 상태를 재설정해야 합니다. 신뢰를 재설정하면 SIC 인증서가 폐기(revoke) 됩니다. 폐기된 인증서의 일련번호로 CRL(Certificate Revocation List, 인증서 폐기 목록) 이 갱신되고, ICA가 갱신된 CRL에 서명해 다음 SIC 연결 때 모든 게이트웨이에 발급합니다. 두 게이트웨이의 CRL이 다르면 서로 인증할 수 없습니다.

SIC 문제 해결(Troubleshooting SIC)

SIC 초기화에 실패하면 다음을 확인합니다.

원격 사용자 접근과 Mobile Access

Mobile Access Software Blade가 이미 켜진 게이트웨이에 인증서를 설치하면, 반드시 정책을 다시 설치 해야 합니다. 그러지 않으면 원격 사용자가 네트워크 리소스에 닿지 못합니다.

게이트웨이에 새 신뢰 상태를 맺으려면, 먼저 게이트웨이 명령줄에서 다음을 합니다.

그다음 SmartConsole에서:

Check Point 내부 인증기관(ICA) 이해하기

ICA(Internal Certificate Authority) 는 관리 서버를 처음 구성할 때 그 위에 생성 됩니다. ICA는 다음 인증을 위해 인증서를 발급합니다.

ICA 클라이언트

대부분의 경우 인증서는 객체 구성의 일부로 처리됩니다. ICA와 인증서를 더 세밀하게 다루려면 다음 클라이언트 중 하나를 씁니다.

ICA의 감사 로그는 SmartConsole Logs & Events > New Tab > Open Audit Logs View 에서 봅니다.

SIC 인증서 관리

SIC 인증서는 게이트웨이 속성 창의 Communication 탭 과 The ICA Management Tool 에서 관리합니다. 인증서에는 다음 설정 가능한 속성이 있습니다.

관리 서버에서 First Time Configuration Wizard 를 실행하고 관리 서버가 User Center 에 연결되면, 자동으로 라이선스를 활성화 합니다. 활성화 전에 인터넷 연결이 끊기면 주기적으로 다시 시도합니다. User Center에서 관리 서버의 Management Software Blade 라이선스를 바꾸면, 그 변경이 관리 서버에 자동으로 동기화 됩니다.

서버·게이트웨이 라이선스 관리

R81부터는 SmartConsole에서 라이선스를 수동으로 추가·제거할 수 있습니다.

라이선스 추가·제거 방법은 다음과 같습니다.

라이선스 정보 열은 다음과 같습니다.

SmartConsole에서 라이선스 보기

라이선스 정보를 보려면 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭하고 Columns 드롭다운에서 Licenses 를 선택합니다. 그러면 다음 열을 볼 수 있습니다.

License Status 의 값은 다음과 같습니다.

Software Blade별 라이선스 정보 보기

게이트웨이나 관리 서버를 선택한 뒤, 아래 Summary 탭에서 객체의 License Status(예: OK)를 클릭하면 Device & License Information 창이 열립니다. 이 창은 객체 기본 정보와 License Status, 라이선스 만료일, 그리고 블레이드별 중요한 quota 정보(Additional Info 열)를 보여 줍니다. quota 정보·quota 의존 상태·블레이드 정보 메시지는 R80 이상에서만 지원되며, SKU의 툴팁은 제품명입니다. 블레이드 License Status 값은 다음과 같습니다.

VSX 라이선스 정보 보기

SmartConsole은 Virtual System이나 Virtual Router 객체의 라이선스를 보려 하면 오류 를 냅니다. VSX 라이선스 정보를 보려면 Virtual System·Virtual Router가 아니라 VSX Gateway 또는 VSX Cluster 객체를 선택 하세요.

SmartConsole에서 라이선스 모니터링

라이선스 문제를 추적하는 옵션은 다음과 같습니다.

SmartEvent 블레이드를 쓰면 Logs & Events 뷰에서 License Status·Inventory 정보를 맞춤 구성할 수 있습니다. SmartEvent 블레이드를 켜지 않고도 Gateways & Servers 뷰에서 라이선스 정보를 보고 License Inventory report 를 내보낼 수 있습니다.

Gateways & Servers 뷰에서 License Inventory report 보기: SmartConsole에서 Gateways & Servers → 상단 도구 모음 Actions > License Report → SmartView 로드 대기. 기본 리포트는 Inventory 페이지(Blade Names, Devices Names, License Statuses)와 License by Device 페이지(Devices Names, License statuses, CK, SKU, Account ID, Support Level, Next Expiration Date)를 담습니다. 내보내기: 오른쪽 위 Options → Export to Excel 또는 Export to PDF.

Logs & Events 뷰에서 License Status report 보기: Logs & Events → 상단 New Tab 또는 [+] → 왼쪽 Views → 목록에서 License Status 더블클릭. 필터: 오른쪽 위 Options > View Filter → Edit View Filter 에서 Field(Device Name, License Status, Account ID 등) 선택 → 논리 연산자(Equals/Not Equals/Contains) 선택 → 값 선택·입력 → OK. 필터는 X 아이콘으로 삭제하고 + 아이콘으로 추가합니다. 내보내기는 Options > Export to Excel/PDF.

Logs & Events 뷰에서 License Inventory report 보기: 위와 비슷하되 왼쪽에서 Reports → License Inventory 더블클릭하고, 필터는 Options > Report Filter 에서 설정합니다.

라이선스·quota 변경 반영

SmartConsole GUI 클라이언트는 라이선스·quota 변경을 실시간으로 알지 못합니다. 그래서 관리 서버에서 quota를 초과해도 License quota Exceeded 경고가 즉시 뜨지 않습니다. 변경을 보려면 SmartConsole로 관리 서버에 접속해 Logs & Events → [+] 로 새 탭을 열고 Compliance 뷰를 엽니다(자세한 내용은 sk120256). entitlement·compliance의 quota 데이터는 다음 시점에 갱신됩니다 — Compliance 자정 스캔, 라이선스 변경, 관리 서버에서 cpstop ; cpstart 실행.

관리자가 여러 게이트웨이를 다룰 때, Security Gateway indicators 기능은 어떤 Jumbo Hotfix Accumulator가 설치되어 있는지 확인하고 모든 게이트웨이가 권장 버전인지 점검 하도록 돕습니다. Gateways & Servers 뷰의 Version 열이 각 게이트웨이에 설치된 현재 Jumbo Hotfix Accumulator를 보여 주며, 열에 마우스를 올렸을 때 설치된 take가 권장이 아니면 권장 take를 제안하는 메시지가 뜹니다.

Version 열의 색 지표는 게이트웨이 상태에 따라 다릅니다.

지표 예외 목록은 sk182159를 참고하세요. 이 지표는 각 게이트웨이의 Summary 탭에도 나타납니다. Gateways & Servers 뷰는 지표로 필터할 수 있는데, 상단 도구 모음의 필터 아이콘에서 version warning 을 고르고 None(색 없음), Unsupported(빨강), Alert(노랑), N/A(회색) 중에서 선택합니다.

권장 take를 게이트웨이에 설치하기

게이트웨이에 마우스를 올리면 설치할 Jumbo Hotfix Accumulator를 알리는 메시지가 뜹니다.

설치를 나중으로 미루려면: 메시지의 Options 버튼을 클릭하면 권장 take 번호가 적힌 창이 열립니다. 드롭다운에서 미룰 시점을 고르고, Apply to all gateways and servers 를 체크하면 이 핫픽스가 적용되는 모든 게이트웨이·서버에 알림 이 설정됩니다. OK 를 누르면 관련 모든 장비에서 지표가 꺼집니다.

권장 Jumbo Hotfix Accumulator를 설치하려면:

Central Deployment 로 SmartConsole에서 다음을 일괄(batch) 배포 합니다.

패키지는 Check Point Cloud 또는 관리 서버의 Package Repository 에서 배포할 수 있습니다. Repository에서 배포하려면 먼저 패키지를 올려 두어야 합니다. API로 Central Deployment를 쓰는 법은 Check Point Management API Reference를 참고하세요.

사전 조건(Prerequisites)

일부 게이트웨이에는 권장 핫픽스가 있습니다 — Gateways & Servers 뷰의 Recommended Jumbo 열을 보세요. 권장 take나 특정 take를 배포할 수 있습니다. Central Deployment를 쓰려면:

Check Point Cloud에서 직접 배포하려면 관리 서버와 대상 모두 Check Point Cloud에 연결 될 수 있어야 합니다.

제한 사항(Limitations)

Package Repository에 패키지 추가하기

완료되면 패키지가 Manage & Settings 뷰의 Package Repository 창에 나타납니다.

여러 게이트웨이·Cluster Member에 핫픽스나 업그레이드 패키지 설치하기

Version Upgrade 를 골랐다면 Upgrade Version 창에서 Upgrade to the Recommended Major Version 또는 Upgrade to a Specific Major Version(버전 번호 입력 후 검색)을 고릅니다. 5. Gateways 영역에서 설치 대상을 확인합니다. 6. Settings 영역에서 High Availability 클러스터 옵션을 고릅니다 — Install on all cluster members(모든 멤버, failover로 트래픽 끊길 수 있음) 또는 Install on non-active members only(standby만; Once installation is complete, turn non-active member to active 로 active 전환). 7. Advanced 영역에서 다운로드 출처를 고릅니다 — Automatic, Gateway(클라우드 직접, 인터넷 필요), Management(관리 서버에서). 8. 아래쪽 Verify 를 클릭합니다(설치 가능 여부·핫픽스 덮어쓰기·디스크 공간 확인). 진행은 Tasks 뷰의 Details 로 봅니다. 9. Install 을 클릭합니다. 10. Central Deployment가 Access Control Policy 설치를 확인합니다. 11. 설치 후 대상에 알맞은 Threat Prevention 정책을 설치 해야 합니다.

핫픽스·Jumbo Hotfix Accumulator 제거하기

Central Deployment가 클러스터를 업그레이드하는 방식

ClusterXL High Availability 모드나 VSX Cluster(non-VSLS)의 모든 멤버에 패키지를 설치할 때, Central Deployment는 다음 순서를 따릅니다.

게이트웨이가 정책을 가져오거나 로그를 보낼 때, 관리 서버나 Log Server의 NAT된 IP 주소로 접근 하도록 구성할 수 있습니다. 절차는 이렇습니다.

   vsenv <VSID>
   

     ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 FORCE_NATTED_IP -n 1
     

     ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 FORCE_NATTED_IP -n 0
     

관리자가 SmartConsole에서 Security Policy와 검사 설정을 구성하면, 정책 설치 때 관리 서버가 알맞은 파일을 만들어 대상 게이트웨이로 전송 합니다. 관리 서버는 SmartConsole의 Security Policy, Global properties, 게이트웨이 속성, 그리고 여러 네트워크 프로토콜의 검사를 제어하는 다수의 구성 파일 을 바탕으로 이 파일들을 만듭니다. 이 구성 파일들을 (Check Point INSPECT 언어로) 직접 수정해 네트워크 검사를 미세 조정할 수 있습니다.

이 구성 파일에는 두 부류가 있습니다 — 관리 서버와 같은 소프트웨어 버전 의 게이트웨이용 파일과, 관리 서버보다 낮은 버전 의 게이트웨이용 파일(이 부류를 Backward Compatibility 라 부름).

구성 절차

   mdsenv <IP Address or name of Domain Management Server>
   

   cp -v /<Full Path to File>/<File Name>{,_BKP}
   

예:

   cp -v $FWDIR/conf/user.def.FW1{,_BKP}
   

   vi /<Full Path to File>/<File Name>
   

예:

   vi $FWDIR/conf/user.def.FW1
   

구성 파일의 위치(R82 관리 서버 기준)

각 파일은 대상 게이트웨이의 버전에 따라 위치가 다릅니다. R82 대상은 관리 서버의 $FWDIR 아래 본래 경로에 있고, 그보다 낮은 버전(Backward Compatibility)은 /opt/CP...CMP-R82/ 아래 별도 디렉터리에 있습니다. 대표 위치는 다음과 같습니다.

HealthCheck Point(HCP) 는 스스로 업데이트되는 점검 도구 모음 으로, 다음 세 가지를 합니다.

HCP는 관리되는 게이트웨이에서 6시간마다 실행 되어 상태 보고를 관리 서버로 보냅니다. SmartConsole의 HCP 상태 보고는 기본적으로 꺼져 있으며, 켜면 SmartConsole이 HCP 상태를 전체 시스템 상태의 일부로 보여 줍니다.

모든 장비에 대해 켜기/끄기: Gateways & Servers 뷰 상단 Actions 에서 Enable HealthCheck Point Alerts 또는 Disable HealthCheck Point Alerts 를 고릅니다.

특정 장비에 대해 켜기/끄기: Gateways & Servers 뷰에서 장비 객체를 오른쪽 클릭하고 Actions > Enable(또는 Disable) HealthCheck Point Alerts 를 고릅니다.

SmartConsole의 상태(Statuses)

SmartConsole은 Gateways & Servers 뷰에서 다음 상태를 보여 줍니다 — Success, Warning, Error, No status was reported(상태 보고 없음).

HCP 상태를 보는 방법:

제한 사항

HCP에 관한 자세한 내용은 sk171436을 참고하세요.