07운영과 고려사항운영과 고려사항
규칙을 잘 짜도 기능이 켜져 있지 않거나, 업데이트가 막혀 있거나, 다른 검사 기능과 어긋나 면 의도대로 동작하지 않습니다. 마지막으로 운영에서 챙겨야 할 점을 모았습니다.
활성화 — 게이트웨이와 Layer 양쪽
가장 흔한 실수가 한쪽만 켜는 것입니다. Application Control·URL Filtering·Content Awareness는 게이트웨이 와 규칙이 든 Layer 양쪽에서 켜져 있어야 합니다.
- Application & URL Filtering 이 꺼져 있으면 Services & Applications 칸에 Services만 보이고 앱·카테고리를 넣을 수 없습니다. 프로토콜 시그니처 기반 서비스 매칭도 이 기능을 켜야 동작합니다.
- Content Awareness 를 게이트웨이 General Properties와 Layer에서 켜야 Content 칸이 나타납니다.
업데이트 패키지와 프록시
Application Control과 URL Filtering은 Check Point가 끊임없이 갱신하는 앱·카테고리 데이터베이스에 의존 합니다. 따라서 게이트웨이가 업데이트 패키지를 받을 수 있어야 분류가 정확합니다.
게이트웨이·Cluster Member가 인터넷에 직접 연결되지 않은 환경이라면, Management Server를 프록시로 삼아 Application Control·URL Filtering 패키지를 받을 수 있습니다. 이 기능은 기본으로 켜져 있습니다. 끄거나 다시 켜려면 게이트웨이(각 Cluster Member)에서 Expert 모드로 실행합니다.
# 끄기
cpprod_util FwSetParam CP_BLADE_UPDATE_PROXY_MGMT_DISABLE 1
# 다시 켜기
cpprod_util FwSetParam CP_BLADE_UPDATE_PROXY_MGMT_DISABLE 0HTTPS Inspection과의 관계
오늘날 웹 트래픽은 대부분 HTTPS로 암호화되어 있습니다. 암호화된 트래픽은 게이트웨이가 속을 보지 못하므로, URL의 도메인 수준 분류는 가능해도 전체 경로나 콘텐츠 기반 판단은 제한됩니다. 더 정밀하게 앱·URL·데이터를 통제하려면 HTTPS Inspection 으로 트래픽을 복호화해 검사해야 합니다. HTTPS Inspection의 인증서·정책 설정은 Security Management 가이드의 HTTPS Inspection에서 다룹니다.
클러스터와 Scalable Platform의 대역폭
규칙 만들기에서 본 대역폭 제한(Limit)은 클러스터·Scalable Platform에서 멤버 수만큼 나뉘어 적용됩니다. ClusterXL Load Sharing이나 Security Group에서 총 30Gbps를 목표로 하고 멤버가 3개라면, Limit 객체를 30 / 3 = 10Gbps 로 설정해야 의도한 총량이 나옵니다. 클러스터 동작은 ClusterXL 가이드, Maestro·Scalable Platform은 Maestro 가이드를 참고하세요.
VSX 환경
VSX(가상 게이트웨이) 환경에서는 각 Virtual System마다 Application Control·URL Filtering을 따로 켜고 정책을 적용합니다. 가상 시스템별 블레이드 활성화는 VSX 가이드에서 다룹니다.
운영 체크리스트
정리하면, Application Control·URL Filtering·Content Awareness를 안정적으로 쓰려면 다음을 확인합니다 — 게이트웨이와 Layer 양쪽 활성화, 업데이트 패키지 수신 경로 확보, App Control과 URL Filtering 규칙 분리(sk174045), HTTPS 트래픽은 Inspection 연계, 클러스터·Scalable Platform의 대역폭 분할 보정 입니다. 이 가이드는 R82 Security Management Administration Guide의 Access Control 내용을 토대로 앱·웹·데이터 통제 관점에서 묶어 정리한 것으로, 더 깊은 정책 구조와 객체 관리는 Security Management 가이드를 함께 보면 좋습니다.