목차/13. 관리 서버 운영

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 등 위젯 제공).