13관리 서버 운영관리 서버 운영
관리 서버를 안정적으로 굴리는 데 필요한 환경설정(리비전), 고가용성, 규정 준수 세 가지를 묶어 다룹니다.
환경설정 — Database Revisions
Security Management 아키텍처에는 Revision(리비전) 이 내장되어 있습니다. publish할 때마다 직전과의 변경분만 담은 새 리비전이 생성 됩니다. 덕분에 위기 시 정상 리비전으로 안전하게 복구 하고, 설치 버전 간 차이만 보므로 정책 검증이 빠르며, Management 고가용성도 더 효율적 입니다.
다만 한계가 있습니다. Backup 관리 서버에서는 revert 불가, 이전 리비전으로 되돌리면 그보다 새 버전은 사라지는 비가역 작업, 객체에만 적용(파일 시스템·Task·SIC·License는 제외), revert는 다른 접속 사용자를 끊고 그들의 private 세션을 버림 입니다. 이 밖에도 SmartConsole의 Preferences and Management Settings 에서 여러 관리 설정을 다룹니다.
Management 고가용성(HA)
Management High Availability 는 관리 서버의 이중화·데이터베이스 백업 입니다. 동기화된 서버들은 같은 정책·규칙·사용자 정의·객체·시스템 설정 을 갖고, 내장 리비전 기술로 마지막 동기화 이후 변경분만 동기화 해 실시간 갱신을 최소 자원으로 해냅니다.
구성은 하나의 Active 서버와 하나 이상의 Standby 서버 입니다. 첫 설치 서버가 Primary(동기화 마스터), 이후가 Secondary(기본 Standby) 이며, Active가 일정 간격으로·publish할 때 Standby를 동기화합니다(미게시 세션은 동기화 안 됨). Standby는 읽기 전용으로만 열 수 있고, Active 장애 시 changeover는 자동이 아니라 수동 으로 합니다. Active와 통신이 끊겨 두 Active가 생긴 상태가 Collision Mode 인데, 이때는 동기화가 멈추며 한쪽을 Standby로 바꾸면 그 데이터가 Active 것으로 덮어쓰입니다.
Secondary 구성은 Primary의 SmartConsole에서 Secondary용 Check Point Host 객체를 만들고 Network Policy Management를 켠 뒤 SIC 신뢰를 맺고 publish 하면 동기화가 시작됩니다. 그다음 각 게이트웨이의 Fetch Policy 에 Secondary를 추가합니다. Primary가 영구히 못 쓰게 되면, promote_util 로 Secondary를 Primary로 승격 하고 원래 Primary IP로 새 Secondary를 세우는 재해 복구 절차를 따릅니다(라이선스는 IP에 묶이므로 승격 서버 IP로 재할당 필요).
Compliance — 규정 준수
Compliance 블레이드 는 Check Point 보안 인프라를 끊임없이 모니터링 하는 동적 솔루션입니다. CCM(Continuous Compliance Monitoring) 기술로 게이트웨이·블레이드·정책·설정을 방대한 규제 표준·보안 모범 사례 DB와 대조 하고, 문제를 바로잡을 시정 조치를 제안 합니다.
자동 스캔은 두 가지입니다 — 하루 한 번(CLI·스크립트로 바뀐 설정을 잡는) 일일 스캔 과 관리자가 게이트웨이·정책에 영향 주는 객체를 바꿔 publish하면 도는 스캔 (수동 스캔도 가능). 켜려면 관리 서버 객체의 General Properties > Management 에서 Compliance 를 선택 하고, 대시보드는 Logs & Events 뷰의 새 탭에서 Compliance 로 봅니다(Security Best Practices·Gateways 등 위젯 제공).