09Access Control 정책 만들기Access Control 정책 만들기

핵심은 여러 보안 기능을 하나의 Rule Base로 통합 한다는 것입니다. 다음 기능을 따로 관리하지 않고 한 정책에 함께 담습니다.

별도의 Rule Base를 여러 개 운영할 필요가 없습니다. 예를 들어 "지정한 네트워크의 사용자가 특정 애플리케이션은 쓰되, 정해진 크기를 넘는 파일 다운로드는 막는다" 같은 직관적인 규칙 하나에 다음 객체를 모두 함께 쓸 수 있습니다.

그리고 이 모든 기능의 정보가 하나의 로그 에 모입니다 — 네트워크, 프로토콜, 애플리케이션, 사용자, 접근한 자원, 데이터 타입까지 한곳에서 봅니다.

규칙은 여러 열로 이뤄집니다. 일부는 기본으로 숨겨져 있으니, Rule Base 헤더를 우클릭 해서 보이게 켜면 됩니다.

Source·Destination 열

Source·Destination 열에는 모든 종류의 그룹을 포함해 네트워크 객체 를 넣을 수 있습니다. 대표적으로 다음이 있습니다.

네트워크 객체를 만들고 관리하는 자세한 방법은 객체 관리(Managing Objects) 절을 참고하세요.

VPN 열

VPN 열로 Site-to-Site VPN, Remote Access VPN, Mobile Access Portal·클라이언트 에 대한 규칙을 만듭니다. 특정 VPN Community에 적용하려면 Site-to-Site Community 나 Remote Access VPN Community 객체를 이 열에 추가하고, 모든 VPN Community에 적용하려면 Any 를 고릅니다.

게이트웨이에서 Mobile Access 를 켜면 그 게이트웨이는 자동으로 RemoteAccess VPN Community 에 추가됩니다. 규칙의 VPN 열에 그 Community를 넣거나 Any 를 써서 Mobile Access 게이트웨이에 규칙이 적용되게 합니다. 게이트웨이가 VPN Community에서 제거되었다면 VPN 열은 반드시 Any 여야 합니다.

IPsec VPN

IPsec VPN 은 게이트웨이가 다른 게이트웨이·클라이언트와 주고받는 트래픽을 암호화·복호화하게 해 줍니다. SmartConsole로 게이트웨이와 원격 장치 사이의 VPN 연결을 손쉽게 구성합니다. Site-to-Site Community에서는 VPN 네트워크의 Star·Mesh 토폴로지를 구성하고 서드파티 게이트웨이도 포함할 수 있습니다.

VPN 터널은 다음 세 가지를 보장합니다.

여기서 IKE 와 IPsec 두 프로토콜이 쓰입니다. IKE(Internet Key Exchange)는 VPN 터널을 만드는 표준 키 관리 프로토콜이고, IPsec 은 사설·공용 네트워크에서 인증·암호화된 안전한 IP 통신을 지원하는 프로토콜입니다.

Mobile Access로 네트워크 접속

Check Point Mobile Access 는 원격 사용자가 인터넷을 통해 안전하고 쉽게 내부 네트워크에 접속하게 해 줍니다. 원격 사용자는 표준 HTTPS 요청을 Mobile Access 게이트웨이로 보내고, 하나 이상의 보안 인증 방식으로 인증합니다. Mobile Access Portal 은 모바일·원격 근무자가 인터넷으로 핵심 자원에 안전하게 접속하게 하고, Check Point Mobile Apps 는 관리되지 않는 스마트폰·태블릿에서도 회사 자원(내부 앱·메일·일정·연락처)에 암호화 통신으로 접근하게 합니다.

Services & Applications 열

이 열에는 규칙에 포함할 애플리케이션·사이트·서비스 를 정의합니다. 한 규칙에 다음을 하나 이상 담을 수 있습니다.

Service 매칭

게이트웨이는 서비스를 IP 프로토콜, TCP·UDP 포트 번호, 프로토콜 시그니처 로 식별(매칭)합니다. 프로토콜 시그니처로 서비스를 매칭하려면 게이트웨이와 Ordered Layer 양쪽에서 Application & URL Filtering을 켜야 합니다. TCP·UDP 서비스는 출발지 포트(source port) 로 매칭하도록 구성할 수도 있습니다.

Application 매칭

애플리케이션이 정책에서 허용 되면, 규칙은 그 애플리케이션의 Recommended services(권장 서비스) 에서만 매칭됩니다. 이 기본 설정은 모든 서비스에서 허용하는 것보다 안전합니다. 예를 들어 Facebook을 허용하는 규칙은 Facebook을 Application Control Web Browsing Services(http, https, HTTP_proxy, HTTPS_proxy)에서만 허용합니다.

반대로 애플리케이션이 차단 되면 모든 서비스, 즉 모든 포트에서 차단 됩니다. 기본 매칭 설정은 바꿀 수 있습니다.

허용된 애플리케이션의 매칭 구성 — 허용된 애플리케이션·카테고리가 어떤 서비스에서 매칭될지 다음 방식으로 바꿀 수 있습니다.

차단된 애플리케이션의 매칭 구성 — 기본적으로 차단된 애플리케이션은 모든 서비스(모든 포트)에서 차단됩니다. 이를 권장 서비스에서만 매칭되게 바꿀 수 있습니다.

다음 표는 "Block" 규칙에서의 애플리케이션 매칭을 요약합니다.

규칙에 서비스·애플리케이션·사이트 추가하기

사용자 정의 애플리케이션·카테고리·그룹 만들기

Application Database에 없는 애플리케이션·카테고리·그룹을 직접 만들 수 있습니다.

새 애플리케이션·사이트 만들기

사용자 정의 카테고리 만들기

R77.30 이하 게이트웨이와 업그레이드 후의 동작

R77.30 이하 게이트웨이는 TCP·UDP 서비스를 포트 번호로만 매칭 하며 프로토콜 시그니처로는 매칭하지 못합니다. 애플리케이션은 애플리케이션 시그니처로 매칭합니다. Management Server를 R80 이상, 게이트웨이를 R80.10 이상으로 업그레이드하면, Application & URL Filtering Rule Base에 정의된 애플리케이션이 권장 포트에서 허용 되도록 동작이 바뀝니다.

Content 열

규칙의 Content 열에 Data Type 을 넣어 데이터 자산을 보호합니다. 이 열을 쓰려면 게이트웨이의 General Properties와 레이어 양쪽에서 Content Awareness를 켜야 합니다.

Data Type 은 데이터의 분류입니다. 게이트웨이는 드나드는 트래픽을 Data Type으로 분류해 정책을 적용합니다. 데이터 방향은 정책에서 Download Traffic(조직 안으로)·Upload Traffic(조직 밖으로)·Any Direction 으로 정합니다.

Data Type에는 두 종류가 있습니다 — Content Types(파일 내용을 분석해 분류)와 File Types(파일 ID를 분석해 분류).

Content Awareness에 대해 알아 둘 점이 여럿 있습니다.

제한 사항도 있습니다.

Action — 트래픽에 무엇을 할지

우클릭 후 More 를 선택하면 추가 설정이 나옵니다.

Track 열 — 로깅

게이트웨이는 연결에 적용할 규칙을 결정 하는데, 이를 "연결 매칭"이라고 합니다. 이 동작을 이해하면 Rule Base 성능을 끌어올리고 매칭된 연결의 로그를 해석 하는 데 도움이 됩니다. 아래 예시들은 설명을 명확히 하려고 일부러 모범 사례를 따르지 않았습니다.

예시 1 — 첫 패킷에서 바로 결정

FTP 연결의 매칭 절차입니다.

예시 2 — 여러 번 검사하며 좁혀 간다

파일 공유 웹 사이트를 탐색할 때의 절차입니다. 위에서 아래로, 또 왼쪽에서 오른쪽으로 따라 읽습니다.

예시 3 — 본문 검사 후 위쪽 규칙으로 되돌아 매칭

업무용 웹 사이트에서 실행 파일을 내려받을 때의 절차입니다.

이 예시들이 보여 주는 점은 다음과 같습니다.

게이트웨이는 Access Control Rule Base 라는 규칙 집합으로 컴퓨터·클라이언트·서버·애플리케이션 접근을 통제합니다. 강력한 Rule Base는 권한 있는 연결만 허용해 취약점을 막고, 사용자에게 올바른 내부 자원 접근을 주며, 연결을 효율적으로 검사 합니다.

Use Case — 기본 Access Control

단순한 보안 정책의 예입니다(Hits·VPN·Content 열은 생략).

각 규칙의 뜻은 다음과 같습니다.

Use Case — 부서별 Inline Layer

부서마다 하위 정책을 둔 예입니다. 각 부서 규칙은 Inline Layer 안에 있으며, Inline Layer는 Rule Base의 나머지와 독립적입니다. 레이어별로 다른 관리자에게 소유권을 위임할 수 있습니다.

기본 셀 값(Default Cell Values)

R81.10부터 새 규칙의 Source·Destination·Services & Applications 열 기본값은 "None" 입니다(R81 이하는 "Any"). 또한 셀에서 마지막 객체를 지운 뒤 남는 기본값도 "None" 입니다(R81 이하는 "Any"). "마지막 객체"란 다른 객체를 모두 지운 뒤 셀에 마지막으로 남았던 객체를 뜻합니다.

"None" 값 규칙의 적용 — R80.10~R81 게이트웨이에서는 한 셀 이상에 "None"이 든 규칙을 빼고 정책이 설치됩니다. 규칙에 "None"이 있을 때 나오는 메시지는 Manage & Settings > Policy Settings > Rule Base Cell Settings > 'None' object behavior 에서 구성합니다.

R81 이하에서 업그레이드 — Management Server를 R81 이하에서 업그레이드하면, 세 열의 기본값은 "Any"로 유지되고, 마지막 객체 제거 후 기본값은 "None"이 됩니다.

Application Control·URL Filtering 정책은 SmartConsole의 Access Control 뷰에서 Access Control Policy로 관리합니다. 이 규칙은 조직 안에서 누가 어떤 애플리케이션·사이트를 쓸 수 있는지, 그 사용을 로그에 어떻게 남길지 정의합니다. 위험도가 높은 애플리케이션·카테고리는 Access Tools의 Application Wiki 에서, 정책·트래픽 개요는 Logs & Events > New Tab > Views 의 Access Control 뷰에서 봅니다.

게이트웨이·클러스터 멤버가 인터넷에 직접 연결되어 있지 않으면 Management Server를 프록시로 써서 Application Control·URL Filtering 패키지를 업데이트합니다. 이 기능은 기본으로 켜져 있습니다. Expert mode에서 다음을 실행해 끄거나 켭니다.

cpprod_util FwSetParam CP_BLADE_UPDATE_PROXY_MGMT_DISABLE 1   # 비활성화
cpprod_util FwSetParam CP_BLADE_UPDATE_PROXY_MGMT_DISABLE 0   # 다시 활성화

애플리케이션 모니터링

시나리오: 조직 내 모든 Facebook 트래픽을 모니터링하고 싶습니다.

애플리케이션 차단 및 사용자 안내

시나리오: 포르노 사이트를 차단하고 사용자에게 위반 사실을 알리고 싶습니다.

이 규칙은 포르노 사이트 트래픽을 차단하고 접근 시도를 로깅합니다. 위반한 사용자는 차단 사유를 알리는 UserCheck 메시지를 받으며, 메시지에 잘못된 카테고리 신고 링크를 넣을 수 있습니다.

애플리케이션 트래픽 제한

시나리오: 스트리밍 미디어가 업무를 방해하지 않도록 직원 접근을 제한하고 싶습니다.

차단하지 않고 제한하는 방법은 두 가지입니다.

아래 예시 규칙은 비업무 시간에만 스트리밍 미디어를 허용하고, 업로드 처리량을 1 Gbps로 제한합니다.

Identity Awareness 기능을 규칙에 쓰기

시나리오: 특정 사용자 그룹에는 어떤 Remote Access 애플리케이션을 허용하고 나머지에게는 막으며, 다른 Remote Access 애플리케이션은 모두에게 막고 싶습니다.

게이트웨이에서 Identity Awareness 를 켜면 Access Role 객체로 사용자·머신·네트워크 위치를 하나의 객체로 정의해 규칙에 쓸 수 있습니다. 이 예에서는 식별된 모든 사용자를 나타내는 Access Role Identified_Users 가 이미 있다고 가정합니다. 두 규칙을 추가합니다.

사이트 차단 (사용자 정의 그룹 활용)

시나리오: 법적 책임을 부를 수 있는 카테고리의 사이트를 차단하고 싶은데, 대부분 Application Database에 있지만 직접 정의한 사이트도 포함해야 합니다.

이때는 사용자 정의 그룹 을 만들어 해당 카테고리들과 사이트를 모두 넣습니다. 이 예에서는 Access Role Identified_Users 와 사용자 정의 사이트 FreeMovies 가 이미 있다고 가정합니다.

사용자 정의 그룹 만들기

이제 이 그룹을 Rule Base에 씁니다.

URL 카테고리 차단

시나리오: 포르노 사이트를 차단하고 싶습니다.

모든 포르노 자료 사이트를 담는 Pornography 카테고리로 차단 규칙을 만들면 됩니다. 절차는 위 "애플리케이션 차단 및 사용자 안내"와 비슷합니다. Identity Awareness를 켜면 Access Role과 함께 써서 특정 사용자에게만 적용할 수도 있습니다.

정책은 게이트웨이가 드나드는 트래픽에 적용하는 규칙의 집합이며, Access Control과 Threat Prevention이 서로 다른 정책을 갖습니다. Access Control 규칙은 Ordered Layer와 Inline Layer 로 더 관리하기 쉬운 묶음으로 정리할 수 있습니다.

레이어가 필요한 이유

레이어를 쓰면 사이버 보안을 더 효율적으로 관리할 수 있습니다.

Inline Layer의 규칙 적용 순서

Ordered Layer는 Inline Layer를 포함할 수 있습니다. Inline Layer의 예입니다.

Inline Layer는 부모 규칙(예: 규칙 2)과 하위 규칙(예: 2.1, 2.2) 으로 이뤄지고, 부모 규칙의 Action이 Inline Layer 이름입니다.

Ordered Layer의 규칙 적용 순서

패킷이 게이트웨이에 도착하면, 게이트웨이는 첫 Ordered Layer의 규칙을 위에서 아래로 순차 검사해 처음 맞는 규칙을 적용합니다. 매칭 규칙의 Action이 Drop 이면 이후 규칙 검사를 멈추고 패킷을 드롭하며, Accept 이면 다음 Ordered Layer 규칙 검사를 이어 갑니다.

Ordered Layer의 규칙이 아무것도 안 맞으면 명시적 Default Cleanup Rule 이 적용되고, 없으면 Implicit Cleanup Rule이 적용됩니다. 모든 Ordered Layer는 자체 Implicit Cleanup Rule 을 가지며 레이어 설정에서 Accept·Drop으로 구성합니다.

Inline Layer 만들기

Inline Layer를 만드는 흐름은, 공통 속성(같은 source·service·user 등)을 가진 부모 규칙 을 만든 다음, 더 상세한 조건의 하위 규칙 을 만드는 것입니다.

Ordered Layer 만들기

Access Control Policy에 Ordered Layer 추가하기

R77.30 이하 게이트웨이용 URL Filtering·Application Control 레이어는, 위와 비슷하게 새 레이어를 만들되 General 뷰에서 이름(권장: Application)을 주고 Blades 에서 Application & URL Filtering 을 켜서 만듭니다.

Access Control 기능 켜기(Enabling Features)

정책을 만들기 전에, 쓸 기능을 게이트웨이와 레이어 양쪽 에서 켜야 합니다.

게이트웨이에서 켜기

Ordered Layer에서 켜기

Inline Layer에서 켜기 — 부모 규칙의 Action 열 우클릭 > Inline Layer > Edit Layer 에서 Blade를 켭니다.

Rule Base의 규칙 종류

Rule Base에는 세 종류의 규칙이 있습니다 — explicit(명시), implied(암묵), implicit.

Explicit rules — 관리자가 직접 구성해 트래픽을 허용·차단하는 규칙입니다.

Implied rules — Global Properties의 일부로 제공되며 편집할 수 없 는 기본 규칙입니다. 선택해서 Rule Base 내 위치만 정할 수 있습니다.

Implied rules는 게이트웨이가 쓰는 서비스 연결을 허용하도록 구성됩니다. 예를 들어 Accept Control Connections 규칙은 정책 설치, 게이트웨이→Management Server 로그 전송, RADIUS·TACACS 같은 서드파티 서버 연결 등을 제어하는 패킷을 허용합니다.

Implicit cleanup rule — 레이어의 명시·암묵 규칙 어디에도 안 맞는 트래픽을 처리하는 기본 "catch-all" 규칙입니다. 레이어를 만들 때 자동 생성되며 Rule Base에는 표시되지 않 습니다. R80.10 이상에서 기본 동작은 Drop 입니다(대부분 정책이 Accept 기반 Allow List이므로). Drop 기반 Blacklist 정책이라면 Layer Editor에서 Accept로 바꿉니다. R77.30 이하에서는 Network Layer는 Drop, Application & URL Filtering 레이어는 Accept입니다.

게이트웨이가 규칙을 적용하는 순서

Implied Rules 구성 — Access Control Policy 선택 후 도구 모음의 Actions > Implied Rules 로 Implied Policy 창을 열고, Configuration 에서 규칙을 켜고/끄고 위치(First·Last·Before Last)를 정한 뒤 OK·정책 설치합니다. 이 창은 명시적 규칙은 보여 주지 않고 암묵 규칙만 보여 줍니다.

Implicit Cleanup Rule 구성 — Menu > Manage Policies and Layers > Layers 에서 레이어 선택 후 Edit > Advanced 에서 Drop·Accept로 구성합니다.

레이어 관리자·공유·섹션

레이어와 정책 관리 — Menu > Manage policies and layers 의 Layers 창에서 각 레이어의 Name, Number of Rules, Modifier(마지막 변경 관리자), Last Modified 와 Layer Details(쓰인 정책, Mode: Ordered·Inline·Not in use)를 봅니다. 레이어 우클릭 > Open layer in policy 로 규칙을 봅니다.

Use Case — Application Control·Content Awareness Ordered Layer

애플리케이션과 콘텐츠를 한 Ordered Layer에서 통제하는 통합 정책의 예입니다.

Use Case — 웹 트래픽용 Inline Layer

웹 트래픽을 통제하며 웹 서버 규칙을 Inline Layer에 둔 예입니다.

Use Case — Content Awareness Ordered Layer

조직을 드나드는 데이터의 업로드·다운로드를 통제하는 정책입니다.

Use Case — Application & URL Filtering Ordered Layer

인터넷 브라우징을 모니터링·통제하는 전형적 정책의 예입니다(Hits·VPN·Install On 열은 생략).

R82에서 고도로 자동화된 네트워크 환경을 위한 새 Dynamic Layer 가 도입되었습니다. 이 레이어는 Gaia API 호출 set-dynamic-content 로 게이트웨이에서 직접 생성한 규칙의 컨테이너 로, JSON 파일 배포로 프로비저닝·구성을 정기적으로 다루는 환경을 위한 것입니다.

흐름은 이렇습니다. (1) Management Server의 Access Control에서 새 Policy Layer를 만들어 Dynamic Layer 로 구성하고, (2) 게이트웨이에서 Gaia API set-dynamic-content(JSON)로 그 Dynamic Layer에 규칙을 구성합니다. Dynamic Layer는 컨테이너로만 동작하며, 게이트웨이에서 API를 실행하면 SmartConsole에서 구성한 그 Dynamic Layer의 모든 규칙을 무시 합니다. 영구 규칙(예: 원격 API 클라이언트 접근 허용)이 필요하면 Dynamic Layer가 아닌 Management Server의 주 정책에 구성해야 합니다(sk182252).

요구 사항

제한 사항

알아 둘 점

구성 — SmartConsole로 연결한 뒤 새 Policy Layer를 추가해 Dynamic Layer로 구성합니다(SmartConsole에서, 또는 Management API add-access-layer dynamic-layer true 로). 특정 정책의 Ordered Layer 로 구성할 때는 Manage policies and layers > Policies에서 패키지 Edit > Access Control의 + > New Layer 로 만들고, General의 Blades에서 필수: Firewall, 선택: Application & URL Filtering 을 고른 뒤, Advanced에서 Implicit Cleanup Action: Drop(기본) 을 선택하고(게이트웨이에서 API를 실행하기 전까지 매칭 트래픽을 모두 드롭), Dynamic Layer 섹션에서 Set as a Dynamic Layer 를 선택합니다. Permissions 페이지에서 Dynamic Layer를 편집할 수 있는 권한 프로필을 고릅니다(권한 프로필은 Manage & Settings > Permissions & Administrators > Permission Profiles에서 Access Control > Policy의 Edit layers by the selected profile in a layer editor 가 선택되어야 함).

특정 규칙 안의 Inline Layer 로 구성할 때는 Action 셀 > Inline Layer > New Layer 로 만들고, Advanced의 Implicit Cleanup Action을 Accept 로 둡니다(API 실행 전까지 매칭 트래픽을 허용). 공유 Ordered Layer 는 Manage policies and layers > Layers > Access Control에서 New로 만들어 여러 정책에서 씁니다.

이후 단계는 다음과 같습니다.

로컬 Gaia API Reference는 https://<Gaia 관리 인터페이스 IP>/gaia_docs/#web/set-dynamic-content 에서 보고, 상단의 Web Services 탭을 클릭합니다. 원격 REST API 클라이언트(Postman 기준) 흐름은, Postman 설치 → sk143612에서 Gaia REST API 컬렉션 받기·임포트 → API 변수 구성 → login 으로 SID 받기 → SID 변수 설정·저장 → set-dynamic-content 의 Body 탭에 JSON 구성 후 Send → 응답의 Task ID를 show task 로 확인합니다.

구성한 변수는 다음과 같습니다.

구성한 dynamic 규칙을 확인하려면 특정 Dynamic Layer는 show-dynamic-layer, 모든 Dynamic Layer는 show-dynamic-layers 를 게이트웨이에서 실행합니다.

Dynamic Layer 리셋 — 모든 dynamic 규칙을 지우려면 게이트웨이에서 set-dynamic-content 를 "operation": "reset" 으로 실행합니다.

"access-layers-content": [
  {
    "name": "<Name_of_Dynamic_Layer>",
    "operation": "reset",
    "rulebase": []
  }
]

효율적 매칭을 위한 모범 사례

대신 이렇게 정의합니다.

이유(2·3): Application Control·Content Awareness 규칙은 콘텐츠 검사가 필요해, 헤더·본문을 검사할 때까지 연결을 허용하므로 성능에 영향을 줄 수 있습니다. 4. Data Type 규칙에서는 File Type 규칙을 Content Type 규칙보다 위 에 둡니다(File Type이 더 빨리 매칭됨). 5. 한 규칙에 Application Control과 URL Filtering을 함께 쓰지 않습니다(sk174045).

R77.30 이하 Management Server(R77.30 이하 게이트웨이 관리)를 R80.10 이상으로 업그레이드하면, 기존 정책이 이렇게 변환됩니다.

R80.x Management Server에서 pre-R80.10 게이트웨이용 새 정책은 다음 구조여야 합니다 — (1) 첫 레이어는 Network Layer(Firewall blade), (2) 두 번째 레이어는 Application & URL Filtering Layer, (3) 그 외 레이어 없음. 구조가 다르면 설치가 실패합니다. 레이어 이름은 바꿔도 됩니다. Network Layer는 Drop, Application Control Layer는 Accept로 두기를 권장합니다.

Hit Count 는 각 규칙에 매칭된 연결 수를 보여 줍니다. 이를 통해 매칭 연결이 없는 규칙을 삭제 하고 정책 동작을 더 잘 이해할 수 있습니다.

Hit Count 값은 전체 대비 백분율과 지시 수준(very high·high·medium·low·zero) 으로 표시됩니다. 켜면 Management Server가 지원 게이트웨이(R75.40 이상)에서 데이터를 모읍니다. Hit Count는 로깅과 무관하게 동작 하며 Track이 None이어도 집계합니다.

전역으로 켜고 끄기 — Menu > Global properties > Hit Count 에서 Enable Hit Count 를 켜고, Keep Hit Count data up to 에서 보관 기간(기본 3개월)을 고른 뒤 OK·정책 설치합니다. 게이트웨이별 로는 Gateway Properties > Hit Count에서 Enable Hit Count 를 켜고 정책을 설치합니다. 켜고 끈 뒤에는 반드시 정책을 설치 해야 수집이 시작·중지됩니다.

Hits 열 표시 구성

Rule Base에 Hit Count를 보이려면 헤더 우클릭 > Hits. 규칙별로는 규칙 번호 우클릭 > Hit Count 에서 Timeframe(All·1 day·7 days·1 month·3 months)과 Display(Percentage·Value·Level)를 고르고, Refresh 로 갱신합니다.

IP spoofing 은 신뢰할 수 없는 출발지 IP를 가짜로 신뢰된 IP로 바꿔 연결을 가로채는 공격입니다. 공격자는 이를 멀웨어·봇 유포, DoS 공격, 무단 접근에 씁니다. Anti-Spoofing 은 어떤 인터페이스 뒤에 있어야 할 IP를 가진 패킷이 다른 인터페이스로 들어오는지 탐지해 차단합니다. 예를 들어 외부 네트워크에서 온 패킷이 내부 IP를 갖고 있으면 차단합니다.

Anti-Spoofing은 인터페이스 토폴로지를 기준으로 동작하며, 토폴로지는 인터페이스가 어디로 이어지는지(Leads To: External(Internet) 또는 Internal)와 인터페이스의 Security Zone 을 정의합니다. 내부 인터페이스를 포함한 모든 인터페이스 에 Anti-Spoofing을 구성하세요.

인터페이스에 Anti-Spoofing 구성하기

Anti-Spoofing 옵션 요약

이 절은 NAT 전반과, IPv6→IPv4 변환인 NAT64 구성을 다룹니다. NAT64는 IPv6 전용 클라이언트와 IPv4 전용 서버의 통신을 가능하게 하며, IPv4/IPv6 변환 알고리즘(RFC 6145)으로 패킷 헤더를 변환합니다.

NAT 시작하기

NAT 는 Firewall Software Blade의 기능으로, IPv4·IPv6 주소를 바꿔 보안을 더합니다. 내부 IP를 인터넷에 노출하지 않 아 네트워크 정체를 보호합니다. 게이트웨이는 패킷의 출발지 IP, 목적지 IP, TCP/UDP 포트를 바꿀 수 있습니다.

흐름 예: (1) 내부 컴퓨터가 외부로 패킷 전송 → (2) 게이트웨이가 출발지 IP를 새 IP로 변환 → (3) 외부에서 응답이 돌아옴 → (4) 게이트웨이가 새 IP를 원래 IP로 되돌림 → (5) 패킷이 올바른 내부 컴퓨터로 전달.

NAT Rule의 종류

NAT Method의 종류

자동·수동 NAT 규칙 모두에서 다음 Method를 쓸 수 있습니다.

Hide — 한 출발지의 모든 연결의 출발지 IP를 같은 IP 로 바꿉니다. 게이트웨이의 나가는 인터페이스 IP(Hide behind gateway) 또는 직접 지정한 IP(Hide behind IP address)를 씁니다.

Hide NAT 흐름 예: 내부 컴퓨터 A(10.10.0.26)가 외부로 패킷을 보내면 게이트웨이가 출발지를 192.0.2.1, 포트 11000으로 변환합니다. 외부에서 192.0.2.1:11000으로 응답이 오면 게이트웨이가 다시 10.10.0.26으로 되돌려 A에게 보냅니다.

Static — 한 출발지의 모든 연결의 출발지 IP를 직접 지정한 IP 로 바꿉니다.

Static NAT 흐름 예: 외부에서 192.0.2.5로 보낸 패킷을 게이트웨이가 10.10.0.26으로 변환해 A에게 전달하고, A의 응답은 192.0.2.5로 변환합니다. 내부 B(10.10.0.37)는 192.0.2.16으로 변환됩니다.

SmartConsole의 NAT 규칙

NAT Rule Base는 IP·포트가 어떻게 변환되는지를 보여 주는 두 섹션을 갖습니다 — Original(Source·Destination·Services)과 Translated(Source·Destination·Services). 자동 NAT 규칙에서는 = Original(변환 없음), S(Static), H(Hide) 표기가 쓰입니다.

NAT Rule 적용 순서

게이트웨이는 NAT Rule Base를 No. 열 순서대로 순차 적용하되, 자동과 수동 규칙을 다르게 다룹니다.

자동 NAT 규칙 다루기

자동 NAT 규칙은 게이트웨이, Host, Network, Address Range 객체에 만들 수 있습니다. Static NAT는 출발지·목적지 변환을 위해 두 규칙을, Hide NAT는 출발지 변환을 위해 한 규칙을 만듭니다. Network·Address Range 객체에는 인트라넷 트래픽을 변환하지 않는 별도 규칙도 생깁니다(같은 객체 내 컴퓨터끼리는 변환 안 됨).

자동 NAT 구성

예시 배포: 내부망의 Email·Web 서버에 Static NAT(공인 주소로 인터넷에서 접근 가능), 내부망 사용자에게 Hide NAT(인터넷 접근, 외부에서 접근 불가)를 구성합니다. 각 서버 객체의 NAT 페이지에서 Add Automatic Address Translation Rules 를 켜고 Translation method를 고른 뒤(Web/Mail은 Static + Hide behind IP Address, LAN은 Hide + Hide behind Gateway), 정책을 설치하면 Management Server가 자동 NAT 규칙을 생성합니다.

외부 네트워크로 자동 Hide NAT — 크고 복잡한 네트워크에서는 모든 내부 IP의 Hide 설정이 비현실적입니다. 대신 게이트웨이가 외부 인터페이스로 가는 모든 트래픽을 그 인터페이스의 유효 IP로 자동 Hide NAT 하게 할 수 있습니다.

게이트웨이 객체 > NAT > Hide internal networks behind the Gateway's external IP 를 선택하고 정책을 설치합니다.

수동 NAT 규칙 다루기

다음 같은 배포에는 수동 NAT가 필요합니다 — 특정 출발지·목적지 IP로 한정, 한 패킷에서 출발지·목적지를 함께 변환, 한 방향만 Static NAT, 서비스(목적지 포트) 변환, 특정 서비스만 사용, 동적 객체 변환.

일반 흐름: (1) 유효(NATed) IP를 쓰는 객체를 만들고, (2) 원래 IP를 유효 IP로 변환하는 수동 NAT 규칙을 만들고, (3) 변환된 객체로 가는 트래픽을 허용하는 Access Control 규칙을 구성합니다.

수동 NAT 구성

예시 배포: DMZ의 내부 웹·메일 서버를 하나의 IP로 외부에서 접근하게 하려면, DMZ 네트워크 객체에 Hide NAT를 구성하고 서버용 수동 NAT 규칙을 만듭니다. HTTP는 Web 서버로(Original Source: Any, Original Destination: Alaska_GW, Original Services: http, Translated Source: S Alaska_DMZ_Web), SMTP는 Mail 서버로(smtp → S Alaska_DMZ_Mail) 변환하고, 마지막에 HTTP·SMTP를 허용하는 Access Control 규칙을 추가한 뒤 정책을 설치합니다.

NAT46 규칙 다루기

NAT46은 세션 정보를 유지하지 않고 IPv4 트래픽을 IPv6로 변환합니다(Stateless). 1:1 IP 매핑 을 수행하며, 변환된 출발지 IPv6는 96비트 prefix의 IPv6 Network 객체 + 32비트 출발지 IPv4 접미사 로 만들어집니다.

변환 흐름 예(IPv4 Client 192.168.2.55 ↔ IPv6 Server):

알려진 제한 — R80.20 이상에서만 지원하고, VoIP·FTP, Control·Data 연결 간 상태 정보가 필요한 프로토콜 은 지원하지 않습니다.

NAT46 구성(Step 1 — 게이트웨이 준비)

set static route <NATed IPv4>/<Net Mask> nexthop gateway logical <Interface> on
save config

Step 2 — NAT46 규칙 구성 — NAT46 규칙은 수동 NAT 규칙 으로 만들고, 이 NAT 트래픽을 허용하는 Access Control 규칙도 추가합니다. 출발지 IPv4 객체(Host·Address Range·Network), 목적지 IPv4 Host 객체, 96비트 prefix의 변환 출발지 IPv6 Network 객체, 변환 목적지 IPv6 Host 객체를 만듭니다(객체들의 NAT 페이지는 구성하지 않음). 수동 NAT 규칙에서 Translated Source의 IPv6 Network 객체를 우클릭 > NAT Method > Stateless NAT46 을 고르면 46 아이콘이 표시됩니다. Original Services는 Any, Translated Services는 = Original 로 둡니다.

지원하는 NAT46 규칙 조합 요약:

NAT46 로깅 — 로그에는 출발지·목적지 IPv6가 원래 IPv6 형식으로 표시됩니다. Log Details의 More 섹션에서 NAT46 항목을 확인합니다 — Xlate (NAT) Source IP(변환된 출발지 IPv6), Xlate (NAT) Destination IP(변환된 목적지 IPv6), More(Nat46 enabled).

NAT64 규칙 다루기

NAT64(RFC 6146)는 IPv6 전용 클라이언트가 unicast UDP·TCP·ICMP로 IPv4 전용 서버와 통신하게 합니다(Stateful). 주소 변환은 RFC 6145(IP/ICMP Translation Algorithm)와 RFC 6052를 따릅니다.

Stateful NAT64 특성 — N:M 변환 (N > M, M=1이면 단일 IPv4 뒤 Hide NAT, M>1이면 IPv4 범위 뒤 Hide NAT), 좋은 IPv4 주소 절약(포트 다중화), 연결 상태·바인딩 저장, IPv6 주소 할당 방식 제약 없음(Manual·DHCP6·SLAAC), 확장성.

알려진 제한 — VoIP, HTTPS Inspection, SSL de-multiplexer, HTTP Proxy 모드 게이트웨이, IPS "HTTP Header Spoofing" 보호를 지원하지 않습니다.

지원 표준 — RFC 6144, 6146, 6052, 6145, 2428, 6384.

변환 흐름 예(IPv6 Client 1111:1111::0100 ↔ IPv4 Server 10.0.0.100):

NAT64 구성(Step 1 — 게이트웨이 준비) — NAT46과 비슷하되, 목적지 IPv4 네트워크에 연결되는 인터페이스에 prefix 길이 96 이하 인 IPv6 주소가 있어야 하고, NATed IPv6(NAT64 규칙의 Original Destination)로 가는 트래픽이 그 인터페이스로 나가도록 IPv6 라우팅을 구성합니다.

set ipv6 static-route <NATed IPv6>/<96 이하> nexthop gateway <인터페이스 IPv6 서브넷의 IPv6 주소> on
save config

IPv6 CoreXL 인스턴스 수도 IPv4와 같게 맞춥니다(fw6 ctl multik stat, fw ctl multik stat).

Step 2 — NAT64 규칙 구성 — 수동 NAT 규칙으로 만듭니다. 출발지 IPv6 Network 객체, IPv4-embedded IPv6 주소 를 가진 변환 목적지 IPv6 객체(80개의 0비트 + 16개의 1비트 + IPv4 32비트, 예: 192.168.3.0 → 0:0:0:0:0:FFFF:192.168.3.0), 변환 출발지 IPv4 Address Range 객체를 만듭니다.

수동 NAT 규칙에서 Translated Source의 IPv4 Address Range 객체를 우클릭 > NAT Method > Stateful NAT64 를 고르면, Translated Destination이 = Embedded IPv4 Address 로 바뀌고 두 열에 64 아이콘이 표시됩니다. Original Services는 Any, Translated Services는 = Original 입니다.

Step 3 — NAT64 추가 설정 — RFC 6145를 따르는 변환 동작을 조정할 수 있습니다.

모든 SmartConsole을 닫고, Database Tool(GuiDBEdit Tool) 로 Management Server에 연결한 뒤 Table > Global Properties > properties > firewall_properties 에서 다음 필드를 우클릭 > Edit 로 true·false를 설정합니다.

File > Save All 후 Database Tool을 닫고, SmartConsole로 연결해 정책을 설치합니다.

NAT64 로깅 — NAT46과 마찬가지로 Log Details의 More 섹션에서 확인합니다 — Xlate (NAT) Source IP(변환된 출발지 IPv4), Xlate (NAT) Destination IP(변환된 목적지 IPv4), More(Nat64 enabled).

고급 NAT 설정

Automatic·Proxy ARP — NAT로 내부 컴퓨터에 외부 네트워크 IP를 주면 그 컴퓨터가 외부망에 있는 것처럼 보입니다. 자동 NAT에서는 게이트웨이가 변환된 객체를 대신해 외부망의 ARP 요청에 응답 합니다. 수동 NAT 규칙을 쓰면 Proxy ARP 항목을 직접 구성 해, 변환된 IP를 그 IP와 같은 네트워크의 게이트웨이 인터페이스 MAC과 연결해야 합니다(sk30197). CGNAT 변환 Address Range는 Proxy ARP가 자동 생성되지 않으니 수동 구성합니다. IPv6 수동 NAT의 Proxy NDP는 sk91905를 보세요.

NAT와 Anti-Spoofing — NAT는 Anti-Spoofing 검사 후 수행되며, 검사는 패킷의 출발지 IP에만 적용됩니다. 따라서 스푸핑 보호도 NAT와 같은 방식으로 인터페이스에 구성합니다.

VPN 터널에서 NAT 비활성화 — VPN 안 통신에는 보통 NAT가 필요 없습니다. VPN community 객체에서 클릭 한 번 으로 끌 수 있습니다. NAT 규칙으로 끄는 방식은 VPN 성능을 떨어뜨립니다.

중첩 주소 내부 통신(Overlapping Addresses) — 두 내부망의 IP가 겹치면 표준 NAT로는 통신할 수 없으므로 인터페이스별 overlapping NAT 를 씁니다. 예를 들어 Network 2A·2B가 모두 192.168.1.0/24일 때, 2A는 2B로 갈 때 192.168.30.0/24를, 2B는 2A로 갈 때 192.168.20.0/24를 목적지로 씁니다.

라우팅은 192.168.20.0/24 → 192.168.2.2, 192.168.30.0/24 → 192.168.3.2 로 구성합니다. 활성화는 Database Tool(또는 dbedit)로 인터페이스별 파라미터를 설정합니다.

Multicast Access Control — 멀티캐스트는 각 데이터그램의 사본 하나를 멀티캐스트 주소로 보내 그룹의 각 수신자가 자기 사본을 받습니다. 게이트웨이 객체 > Network Management > 인터페이스 Edit > Interface > Advanced > Drop Multicast packets by the following conditions 에서 정책을 고릅니다 — 목록 내 목적지 드롭 또는 목록 외 모두 드롭. 멀티캐스트 주소 범위는 224.0.0.0 ~ 239.255.255.255(Class D)이며, 224.0.0.0~224.0.0.255는 라우터가 전달하지 않는 LAN용 영구 호스트 그룹입니다. Rule Base에 그 범위를 Destination으로 하는 규칙을 추가하고 멀티캐스트 프로토콜(PIM·DVMRP·MOSPF·IGMP)을 서비스에 넣은 뒤 정책을 설치합니다.

Security Management behind NAT — Management Server가 사설(RFC 1918)·비라우팅 IP를 쓸 때, 클릭 한 번으로 Static·Hide NAT 를 구성하면서도 관리 게이트웨이와의 연결을 유지할 수 있습니다(Management HA·Log Server에도 적용).

Management Server 객체 > NAT 에서 Add Automatic Address Translation rules 선택, Static 과 IP 구성 후, Install on Gateway(이 NAT를 수행할 게이트웨이) 또는 Do not create automatic NAT rules(서드파티 장비가 NAT 처리) 중 하나를 고릅니다. Connections from Security Gateways to this server 에서 topology 기준·원본 IP·변환 IP 중 하나를 고르고, 필요하면 Apply for Security Gateway control connections(VPN 컨트롤 연결에 NAT 적용)를 선택합니다. 게이트웨이별로는 NAT > Management / Log Servers 에서 기본값(서버 설정 사용)을 쓰거나 재정의합니다.

IP Pool NAT — IP Pool은 게이트웨이로 라우팅되는 IP 범위로, MEP(Multiple Entry Point) 게이트웨이 VPN 시나리오 에서 암호화 연결의 라우팅을 보장합니다. 연결이 한 MEP 게이트웨이로 라우팅되면 응답 패킷도 같은 게이트웨이로 돌아와야 하므로, 각 MEP 게이트웨이가 자신으로 라우팅되는 IP 풀을 유지하고 출발지 IP를 풀의 IP로 치환합니다.

NAT 우선순위 는 1. Static NAT → 2. IP Pool NAT → 3. Hide NAT 순입니다. 비암호화 연결에서 IP Pool NAT는 Hide NAT보다, (1) NATed 호스트로 새 back connection(예: X11)을 열 수 있고, (2) IP당 한 연결 프로토콜의 사용자-서버 매핑이 여러 호스트와 동작하며, (3) IPsec·GRE·IGMP를 NAT할 수 있다는 장점이 있습니다(Hide NAT는 TCP·UDP·ICMP만).

IP Pool 구성 절차

Check Point Mobile Access 는 원격 사용자가 표준 HTTPS로 Mobile Access 게이트웨이에 접속·인증해 내부망에 안전하게 접근하게 합니다. Rule Base에 넣으려면 Services & Applications 열에 Mobile Application 을, 특정 클라이언트 접근은 Source 열에 그 클라이언트용 Access Role 을 넣습니다. 모든 솔루션은 엔터프라이즈급 보안 연결, 강력한 사용자 인증, 세밀한 접근 통제를 제공합니다(최신 정보는 sk67820).

Client-Based vs. Clientless — Check Point 원격 접속은 IPsec·SSL 암호화를 쓰며 NAT·핫스팟·프록시를 통과합니다.

Mobile Access 클라이언트 — Capsule Workspace(보안 컨테이너로 내부 웹·파일 공유·Exchange 접근), Capsule Connect(전체 L3 터널), Check Point Mobile for Windows(Windows IPsec VPN). Mobile Access Web Portal 은 clientless SSL VPN으로 Outlook Web App·위키 등에 접근하고, SSL Network Extender 는 브라우저에서 설치되는 on-demand SSL VPN 클라이언트입니다.

Mobile Access 구성

샘플 워크플로 — (1) Mobile Access Software Blade를 켜고, (2) 구성 마법사로 모바일 클라이언트 선택·포털 정의·애플리케이션 정의·AD 연결을 설정하고, (3) 정책 유형을 고르며(기본은 Legacy Policy, 통합 정책은 Gateway Properties > Mobile Access에서 선택), (4) 정책에 규칙을 추가하고, (5) 인증 설정을 하고, (6) 정책을 설치합니다. (선택) Capsule Workspace 앱에 인증서 인증으로 접근을 줄 수 있습니다(Authentication > Settings > Require client certificate, Certificate Creation and Distribution Wizard로 인증서 발급).

구성 마법사 사용 — Mobile Access Blade를 켜면 마법사가 열립니다. 인터넷·모바일 장치 연결 허용 옵션(Web, Mobile Devices, Desktops/Laptops) 선택 → 포털 URL 입력(기본 https://<게이트웨이 IPv4>/sslvpn) → 애플리케이션 구성(Demo web application, Mail/Calendar/Contacts에서 Exchange 도메인과 Mobile Mail, ActiveSync Applications, Outlook Web App) → AD 도메인·자격 증명 입력 후 Connect → Users 페이지에서 그룹(예: Mobile Access) 추가 → Finish.

모바일 연결 허용 — 마법사는 Blade를 켜고 구성하지만, VPN 클라이언트 연결을 허용하는 Firewall 규칙을 추가 해야 합니다. Exchange 서버용 Host Node 객체를 만듭니다(나머지는 사전 정의됨).

이 규칙은 RemoteAccess VPN community에서 Exchange 서버로 가는 HTTP·HTTPS·MS Exchange만 허용하며, MobileAccessGW 그룹의 게이트웨이에 설치됩니다.

애플리케이션 접근 정의 — Security Policies 페이지에서 사용자·사용자 그룹, Mobile Access 애플리케이션, Mobile Access 게이트웨이 객체로 규칙을 만듭니다(마법사에서 선택한 앱은 자동 추가됨).

Single Sign-On(SSO) 활성화 — SSO를 켜면 사용자가 한 번 인증으로 Mobile Access 세션의 여러 애플리케이션을 씁니다. 포털 로그인 자격 증명이 각 애플리케이션 인증에 재사용되며, 세션 동안 게이트웨이에 안전하게 저장됩니다. HTTP를 쓰는 새 애플리케이션에는 기본으로 켜집니다. 웹 폼 애플리케이션은 Security Policies > Shared Policies > Mobile Access > Open Mobile Access Policy in SmartDashboard 에서 애플리케이션 Edit > Single Sign On 페이지에서 Advanced > This application reuses the portal credentials 와 This application uses a Web form ... 를 선택합니다.

Citrix 서버 연결 — Mobile Access Blade는 Citrix 클라이언트·서비스를 통합하며 자체 STA 엔진을 써서 별도 STA 서버가 필요 없 습니다(STA·CSG 배포에서도 사용 가능). 서버 인증서는 게이트웨이 FQDN으로 발급해야 합니다.

구성은 Manage & Settings > Blades 의 Mobile Access에서 Configure in SmartDashboard > Applications > Citrix Services > New 로 Citrix 서버 객체를 만들고, Web Interface 서버용 Host 객체 생성, 지원 서비스(HTTP·HTTPS) 선택, Link in Portal(링크 텍스트·URL·툴팁) 구성, Single Sign On 켜기(자격 증명 저장) 후, Policy 에서 규칙의 Applications 셀에 Citrix 객체를 추가하고 정책을 설치합니다.

Compliance Check

Mobile Access Blade의 Endpoint Security on Demand 로 컴플라이언스 정책을 만들어, 모바일·컴퓨터가 연결 전에 한 번 스캔 되어 준수하는지 확인합니다. 스캐너는 ActiveX(Windows의 IE)나 Java로 설치되며, 브라우저가 포털을 열려 할 때 스캔이 시작됩니다.

컴플라이언스 정책 규칙 종류: Windows security(핫픽스·패치·SP), Anti-Spyware protection, Anti-Virus protection(버전·시그니처), Firewall(개인 방화벽), Spyware scan, Custom(애플리케이션·파일·레지스트리 키), OR group(그룹 내 한 규칙만 충족해도 준수).

컴플라이언스 정책 만들기 — Manage & Settings > Blades > Mobile Access > Configure in SmartDashboard > Endpoint Security on Demand > Endpoint Compliance > Edit policies > New Policy 로 이름·설명을 주고 Add 로 규칙을 고릅니다(New Rule 로 새 규칙 생성 가능). 필요하면 Bypass spyware scan 을 선택합니다.

게이트웨이 컴플라이언스 설정 — 같은 위치에서 게이트웨이를 Edit 한 뒤 Scan endpoint machine when user connects 와 Threshold policy(예: Laptop Computer)를 고르고 정책을 설치합니다.

Secure Workspace — 원격 사용자가 엔드포인트에서 ="실제" 작업 공간과 격리된 가상 보안 환경== 으로 접속하게 합니다. 사용자는 이 환경에서 Mobile Access Portal을 통해서만 데이터를 보내고, 허용된 애플리케이션·파일만 씁니다. 컴퓨터에 My Secured Documents 라는 암호화 폴더를 만들며, 세션이 끝나면 이 폴더와 모든 세션 데이터를 삭제합니다. Manage & Settings > Blades > Mobile Access > Configure in SmartDashboard > Endpoint Security on Demand > Secure Workspace 에서 게이트웨이 Edit > This gateway supports access to applications from within Check Point Secure Workspace 를 선택하고 정책을 설치합니다.

Site-to-Site VPN의 바탕은 암호화된 VPN 터널 입니다. 두 게이트웨이가 링크를 협상해 터널을 만들며, 한 터널에 여러 VPN 연결이, 한 게이트웨이에 동시에 여러 터널이 있을 수 있습니다. 두 게이트웨이가 IKE 협상으로 터널을 만들고 IPsec으로 호스트 간 데이터를 암호화·복호화합니다.

VPN Communities — VPN Domain 은 게이트웨이가 VPN 트래픽을 주고받는 내부망의 모음입니다. 각 게이트웨이의 VPN Domain을 정의한 뒤 게이트웨이를 VPN community(VPN 터널과 속성의 모음) 로 묶습니다. Community는 Mesh(게이트웨이 쌍마다 터널)와 Star(각 satellite가 central에만 터널) 토폴로지를 씁니다.

Star Community 구성 예 — Security Policies > Access Tools > VPN Communities > New > Star Community 로 community를 만들고 Encryption 에서 암호화 방식을 구성합니다. 각 게이트웨이는 General Properties에서 IPsec VPN 을 켜고, Network Management > VPN Domain 에서 central은 Manually defined(Internal-network 객체), satellite는 All IP addresses 로 두고, IPsec VPN 에서 community에 Add 합니다. 이후 community의 Gateways 페이지에서 Center Gateways·Satellite Gateways 를 추가합니다.

조합 community 예 — London·New York 게이트웨이는 내부망을 공유하는 Mesh community로 묶이고, 회사 파트너의 외부망은 London·New York 내부망에 접근하지 못하지만, Star community로 각자 협업하는 사이트의 내부망에 접근합니다.

VPN 연결 허용 — 특정 community 간 VPN 연결을 허용하려면 그런 연결을 Accept하는 Access Control 규칙을 추가합니다. 모든 VPN 트래픽을 허용하려면 community 속성의 Encrypted Traffic 섹션에서 Mesh는 Accept all encrypted traffic, Star는 Accept all encrypted traffic on Both center and satellite gateways 또는 on Satellite gateways only 를 선택합니다.

샘플 VPN Access Control 규칙(Action=Allow, Track=Log, Time=Any 가정):

직원이 여러 위치·장치에서 민감 정보에 원격 접근할 때 그 접근이 보안 취약점이 되지 않게 해야 합니다. Remote Access VPN 은 원격 사용자와 내부망 사이에 VPN 터널을 만들며, Mobile Access Software Blade 가 많은 클라이언트·배포로 기능을 확장합니다.

VPN 연결 모드 — 원격 클라이언트 연결에는 IP 미상·내부 IP가 부여된 LAN(호텔 등)·미지원 프로토콜 같은 어려움이 있습니다. IPsec VPN Blade는 이를 위해 두 모드를 제공합니다.

샘플 워크플로 — (1) Remote Access VPN을 켜고, (2) 원격 사용자 정보를 추가하며(LDAP Account Unit 생성·구성 또는 SmartConsole 사용자 DB 입력, 선택적으로 사용자 인증 구성), (3) Access Control·암호화 규칙을 정의하고, (4) 규칙에 쓸 그룹 객체(LDAP Group·User Group)를 만들고, (5) Menu > Global properties > Remote Access > VPN - Authentication and Encryption 에서 VPN community의 암호화를 구성하고, (6) 내부망으로의 VPN 트래픽을 허용하는 Access Control 규칙을 추가합니다.

Remote Access community용 게이트웨이 구성 — VPN Blade를 켠 뒤, 게이트웨이 객체 > IPsec VPN 에서 Remote Access community에 Add 하고, Network Management > VPN Domain 에서 VPN Domain을 구성합니다. Visitor·Office Mode는 VPN Clients > Office Mode 에서 설정합니다.

Check Point Management Server와 관리 객체(게이트웨이·클러스터 멤버·Log Server 등)는 Check Point 프로토콜로 서로 통신합니다. 기본적으로 모든 Access Control 정책에는 필요한 내부 Check Point 통신을 허용하는 사전 정의된 Implied Rules 가 들어 있습니다.