11HTTPS InspectionHTTPS Inspection
HTTPS로 오가는 인터넷 트래픽은 TLS(Transport Layer Security) 프로토콜로 암호화되어 데이터의 기밀성과 무결성을 지켜 줍니다. 좋은 일이지만 동시에 위험도 따라옵니다 — 암호화된 HTTPS 안에는 불법적인 사용자 활동이나 악성 트래픽이 숨 어 있을 수 있고, 게이트웨이는 암호화된 트래픽을 그대로는 들여다볼 수 없기 때문입니다. 그래서 HTTPS Inspection 기능을 켜면, Security Gateway가 외부 서버와 새 TLS 연결을 맺고, 그 새 연결을 거치는 트래픽을 복호화해 검사 합니다.
이 장은 HTTPS Inspection의 두 검사 방향과 연결 흐름, 정책 구성과 규칙 베이스, 인바운드·아웃바운드 인증서 다루기, 게이트웨이별 설정과 전역 설정, 세션 로그와 통계 뷰, SNI 분류·비표준 포트·TLS 1.3 검사 까지 원문의 모든 절차와 표·파라미터·주의사항을 빠짐없이 풀어 정리합니다.
두 가지 검사 방향
HTTPS Inspection에는 두 종류가 있습니다.
- Outbound HTTPS Inspection — 내부 클라이언트가 외부 사이트나 서버로 보내는 악성 트래픽 으로부터 보호합니다.
- Inbound HTTPS Inspection — 인터넷이나 외부 네트워크에서 내부 서버로 오는 악성 요청 으로부터 내부 서버를 보호합니다.
어느 방향이든 게이트웨이는 인증서를 사용해 클라이언트 컴퓨터와 보안 웹 사이트 사이의 중개자(intermediary) 가 됩니다. 검사 과정에서 다뤄지는 모든 데이터는 HTTPS Inspection 로그에 비공개로 보관 되며, HTTPS Inspection 권한이 있는 관리자만 그런 로그의 모든 필드를 볼 수 있습니다.
HTTPS 연결의 검사 흐름
Outbound HTTPS 연결
Outbound(나가는) 연결은 내부 클라이언트에서 외부 서버로 가는 HTTPS 연결 입니다. 흐름은 다음 순서로 진행됩니다.
- 내부 클라이언트가 외부 서버로 보내는 HTTPS 요청이 Security Gateway에 도착 합니다.
- Security Gateway가 그 HTTPS 요청을 검사 합니다.
- 그 요청이 기존 HTTPS Inspection 규칙에 매칭되는지 판단 합니다.
- 규칙에 맞지 않으면 HTTPS 페이로드를 검사하지 않 습니다.
- 규칙에 맞으면 다음 단계로 진행합니다.
- Security Gateway가 외부 서버의 HTTPS 인증서를 검증 합니다. 이때 OCSP(Online Certificate Status Protocol) 표준을 사용합니다.
- 그 연결을 위한 새 인증서를 생성 합니다.
- HTTPS 연결을 복호화 합니다.
- 복호화된 HTTPS 연결을 검사 합니다.
- Security Policy가 이 트래픽을 허용하면 HTTPS 연결을 다시 암호화 합니다.
- HTTPS 요청을 외부 서버로 전송 합니다.
Inbound HTTPS 연결
Inbound(들어오는) 연결은 외부 클라이언트에서 시작해 DMZ나 내부 네트워크의 서버로 향하는 HTTPS 연결 입니다. 흐름은 다음과 같습니다.
- 외부 클라이언트가 내부 서버로 보내는 HTTPS 요청이 Security Gateway에 도착 합니다.
- Security Gateway가 그 HTTPS 요청을 검사 합니다.
- 그 요청이 기존 HTTPS Inspection 규칙에 매칭되는지 판단 합니다.
- 규칙에 맞지 않으면 HTTPS 페이로드를 검사하지 않 습니다.
- 규칙에 맞으면 다음 단계로 진행합니다.
- Security Gateway가 내부 서버의 인증서를 사용해 외부 클라이언트와 HTTPS 연결 을 만듭니다.
- 내부 서버와는 새 HTTPS 연결 을 만듭니다.
- HTTPS 연결을 복호화 합니다.
- 복호화된 HTTPS 연결을 검사 합니다.
- Security Policy가 이 트래픽을 허용하면 HTTPS 연결을 다시 암호화해 내부 서버로 전송 합니다.
R82부터 HTTPS Inspection 정책은 Inbound Policy와 Outbound Policy로 나뉘 며(정책 관리 기초), 이 검사 결과는 Application Control·URL Filtering·Content Awareness·DLP·IPS·Anti-Virus·Anti-Bot·Threat Emulation 같은 블레이드가 활용합니다(Access Control 정책). 인증서 발급·관리는 내부 인증 기관(ICA)을 바탕으로 하며(인증 인프라), 인증서를 전용 하드웨어에 보관하려면 Security Gateway 가이드의 HSM을 참고하세요.
시작하기 — 전체 구성 순서
다음은 아웃바운드·인바운드 HTTPS 트래픽을 모두 검사하도록 Security Gateway를 구성 하는 전체 흐름의 예입니다.
| 단계 | 작업 |
|---|---|
| 1 | Security Gateway에서 관련 Software Blade를 활성화 합니다. |
| 2 | HTTPS Inspection 정책(Inbound·Outbound)을 구성 합니다. 아래 "HTTPS Inspection 정책" 참고. |
| 3 | Security Gateway가 인바운드 인증서를 사용 하도록 구성합니다. 아래 "인바운드 CA 인증서 다루기" 참고. |
| 4 | Security Gateway에서 HTTPS Inspection을 구성합니다 — (a) 아웃바운드 인증서를 사용 하도록 구성하고 조직에 배포, (b) HTTPS Inspection 활성화, (c) 추가 설정 구성. 아래 "Security Gateway에서 HTTPS Inspection 구성" 참고. |
| 5 | Access Control 정책을 설치 합니다. |
HTTPS Inspection 정책
HTTPS Inspection 규칙(rule) 은 게이트웨이가 HTTPS 트래픽을 어떻게 검사할지를 정의합니다. R82부터 이 정책은 Inbound Policy와 Outbound Policy로 나뉩 니다.
규칙은 URL Filtering 카테고리 를 활용해 사이트·애플리케이션별 트래픽을 식별할 수 있습니다. 예를 들어 사용자의 사생활을 보호하려고, 은행·금융 기관으로 가는 HTTPS 트래픽은 검사하지 않는(Bypass) 규칙을 만들 수 있습니다.
기본적으로 Security Gateway는 지원되는 모든 Software Blade에 대해 HTTPS Inspection을 적용 합니다. HTTPS Inspection을 지원하는 블레이드는 다음과 같습니다.
- Access Control
- Application Control
- URL Filtering
- Content Awareness
- Data Loss Prevention
- Threat Prevention
- IPS
- Anti-Virus
- Anti-Bot
- Threat Emulation
- Threat Extraction
- Zero Phishing
특정 Software Blade에만 HTTPS Inspection을 적용하려면 다음을 해야 합니다.
- Security Gateway 객체에서 원하는 Software Blade를 활성화 합니다.
- HTTPS Inspection 정책에 적절한 규칙을 만들고, Blade 열 에서 그 Software Blade를 선택합니다.
정책 패키지마다 서로 다른 HTTPS Inspection 레이어 를 만들 수 있습니다. 새 정책 패키지를 만들 때는 미리 정의된 HTTPS Inspection 레이어를 쓰거나, 보안 요구에 맞게 직접 커스터마이즈할 수 있습니다. 또한 하나의 HTTPS Inspection 레이어를 여러 정책 패키지에서 공유 할 수도 있습니다.
HTTPS Inspection 보안 정책의 열(Columns)
HTTPS Inspection 보안 정책 규칙에는 다음 열이 있습니다(열 표시·숨김은 아무 열 머리글에서나 우클릭).
| 필드 | 설명 |
|---|---|
| No. | HTTPS Inspection Rule Base에서의 규칙 번호. |
| Name | 관리자가 이 규칙에 붙이는 이름. |
| Source | 트래픽이 시작되는 위치를 정의하는 네트워크 객체. |
| Destination | 트래픽의 목적지를 정의하는 네트워크 객체. |
| Services | 검사하거나 우회할 네트워크 서비스. 기본적으로 443 포트의 HTTPS, 8080 포트의 HTTP_and_HTTPS proxy를 검사 합니다. 목록에서 서비스를 추가·삭제할 수 있습니다. |
| Site Category | 검사하거나 우회할 애플리케이션·웹 사이트의 카테고리. |
| Action | HTTPS 트래픽이 규칙에 매칭됐을 때의 동작. 검사(Inspect)하거나 무시(Bypass)합니다. |
| Track | 트래픽이 규칙에 매칭됐을 때의 추적·로깅 동작. |
| Blade | 기본값은 All 로, 지원되는 모든 Software Blade에 HTTPS Inspection을 적용합니다. 특정 블레이드만 골라 그 블레이드에만 적용할 수도 있습니다. |
| Install On | HTTPS Inspection 정책을 적용할 네트워크 객체. HTTPS Inspection이 켜진 Security Gateway만 선택 할 수 있습니다(기본적으로 이 열에 나타나는 게이트웨이는 HTTPS Inspection이 켜져 있습니다). |
| Certificate | Inbound Policy에만 있는 열 입니다. 이 열에서 규칙에 사용할 내부 서버의 인증서를 선택합니다. |
| Comment | 규칙 설명을 적는 선택적 필드. |
HTTPS Inspection 정책 구성하기
아웃바운드·인바운드 트래픽에 대해 각각의 정책 안에서 별개의 규칙 을 세웁니다. 인바운드 규칙은 내부 서버마다 다른 인증서 를 사용합니다.
또한 민감해서 검사하면 안 되는 트래픽을 위해 bypass 규칙 을 만들 수 있습니다.
Outbound·Inbound 정책을 조금이라도 수정하면 Access Control 정책을 다시 설치 해야 합니다.
Outbound HTTPS Inspection Rule Base 예시
전형적인 정책의 아웃바운드 규칙 베이스 예입니다.
| No | Name | Source | Destination | Services | Site Category | Action | Track | Install On |
|---|---|---|---|---|---|---|---|---|
| 1 | Financial sites | Any | Internet | HTTPS, HTTP_HTTPS_proxy | Financial Services | Bypass | Log | HTTPS Policy Targets |
| 2 | Outbound traffic | Any | Internet | HTTPS, HTTP_HTTPS_proxy | Any | Inspect | Log | HTTPS Policy Targets |
- 규칙 1 (Financial sites) — Financial Services 카테고리에 정의된 웹 사이트로 가는 HTTPS 트래픽은 검사하지 않는 bypass 규칙입니다.
- 규칙 2 (Outbound traffic) — 인터넷으로 가는 HTTPS 트래픽을 검사합니다. 이 규칙은 Outbound CA 인증서 를 사용합니다.
Inbound HTTPS Inspection 규칙 예시
| No | Name | Source | Destination | Services | Action | Certificate |
|---|---|---|---|---|---|---|
| 1 | Inbound traffic | Any | WebCalendar Server | HTTPS | Inspect | WebCalendarServer CA |
- Inbound traffic — 네트워크 객체 WebCalendarServer 로 가는 HTTPS 트래픽을 검사하며, WebCalendarServer 인증서 를 사용합니다.
HTTPS Inspection 정책 적용(Enforcement)
HTTPS Inspection Rule Base 적용은 두 단계 로 이뤄집니다.
- 연결을 Rule Base에 매칭 합니다.
- 수행할 Action을 계산 합니다.
Action은 매칭된 규칙, 그 규칙에 정의된 Software Blade, 규칙 예외 에 따라 계산됩니다. 어떤 경우에는 매칭된 규칙의 Action이 Inspect 인데도 2단계 계산 결과 Action이 Bypass로 바뀌 기도 합니다. 이때 HTTPS Inspection 로그는 매칭된 규칙의 데이터를 담아 보내지지만, 로그의 Action은 Bypass 로 기록됩니다.
인바운드 CA 인증서 다루기
인바운드 HTTPS Inspection용 서버 인증서 할당
조직 외부의 클라이언트가 내부 서버로 HTTPS 연결을 시작하면, Security Gateway가 그 트래픽을 가로챕니다. 게이트웨이는 인바운드 트래픽을 검사한 뒤 게이트웨이에서 내부 서버로 가는 새 HTTPS 연결 을 만듭니다. HTTPS Inspection을 가능하게 하려면 게이트웨이가 원래 서버의 인증서와 개인 키(private key) 를 써야 하며, 내부 서버와의 TLS 연결에 이 인증서와 키를 사용합니다.
서버 인증서를 CER 형식 으로 게이트웨이에 가져온(import) 뒤, 그 객체를 HTTPS Inspection 정책에 추가합니다. 이 절차는 조직 외부 클라이언트의 연결 요청을 받는 모든 서버에 대해 수행하세요.
인바운드 HTTPS Inspection용 서버 인증서 추가하기
| 단계 | 작업 |
|---|---|
| 1 | SmartConsole에서 Security Policies 뷰 > HTTPS Inspection > Inbound Policy > 상단 도구 모음에서 Inbound Certificates 클릭. |
| 2 | Import 클릭 → Import Inbound Certificate 창이 열립니다. |
| 3 | Certificate name 과 Comment(선택)를 입력합니다. |
| 4 | 인증서 파일을 찾아 지정합니다. |
| 5 | Password 를 입력합니다. 서버에서 인증서의 개인 키를 보호하는 데 쓴 것과 같은 암호 를 입력하세요. |
| 6 | OK 클릭. |
| 7 | Close 클릭. |
서버 인증서를 처음 가져올 때 Successful Import 창이 열려, 인증서 객체를 HTTPS Inspection 정책 어디에 추가해야 하는지 알려 줍니다. 매번 이 창을 보고 싶지 않으면 Don't show this again 을 클릭하고 Close 를 누릅니다.
Security Gateway에서 HTTPS Inspection 구성
HTTPS Inspection은 각 Security Gateway마다 따로 구성 해야 합니다.
| 단계 | 작업 |
|---|---|
| 1 | SmartConsole Gateways & Servers 뷰에서 Security Gateway 객체를 더블 클릭합니다. |
| 2 | HTTPS Inspection 을 클릭합니다. |
| 3 | (선택) 아웃바운드 CA 인증서가 다른 게이트웨이용으로 이미 만들어져 있으면, 전역 인증서를 쓰거나 게이트웨이별로 다른 인증서로 override 할 수 있습니다. override 하려면 HTTPS Inspection > Step 1 로 가서 Override global setting 을 선택하고 드롭다운에서 인증서를 고릅니다. |
| 4 | HTTPS Inspection용 아웃바운드 CA 인증서를 Import 또는 Create 합니다. 아래 "아웃바운드 CA 인증서 다루기" 참고. |
| 5 | 아웃바운드 인증서를 조직에 Export·Deploy 합니다. 아래 "생성된 CA 인증서 내보내기·배포" 참고. |
| 6 | Step 3 에서 Enable HTTPS Inspection 을 선택합니다. |
| 7 | HTTPS Inspection Deployment Mode 를 구성합니다(아래 설명). |
| 8 | Additional Settings > Edit 에서 클라이언트 측·서버 측 fail mode 를 구성합니다(아래 설명). |
| 9 | Bypass Under Load 를 구성합니다(아래 설명). |
| 10 | OK 클릭 후 Access Control 정책을 설치 합니다. |
Deployment Mode — Full inspection vs Learning mode (7단계)
| 모드 | 설명 |
|---|---|
| Full inspection | HTTPS 연결을 HTTPS Inspection 정책에 따라 모두 검사 합니다. |
| Learning mode | HTTPS Inspection을 부분 배포해 연결성·성능 영향을 가늠 합니다. 게이트웨이가 트래픽의 작은 일부만 검사해 연결성 문제를 찾고, 설정된 정책에 필요한 자원 소비를 추정합니다. 효과나 게이트웨이 상태를 보려면 Security Policies 뷰 > HTTPS Inspection > Outbound Policy 또는 Inbound Policy > HTTPS Inspection Tools 의 Deployment 클릭. 자세한 내용은 아래 "HTTPS Inspection Deployment 뷰" 참고. |
Fail Mode — 연결 오류 시 동작 (8단계)
연결 오류가 났을 때의 동작을 클라이언트 측과 서버 측 각각 에 대해 정합니다.
| 모드 | 설명 |
|---|---|
| Fail Open | 서버 측·클라이언트 측에서 실패한 연결은 HTTPS Inspection을 수행하지 않 고 우회(bypass)합니다. |
| Fail Close | 내부 시스템 오류·서버 연결 오류(서버 측), 또는 클라이언트 연결 문제로 실패한 연결을 차단 합니다. |
서버·클라이언트 오류는 전역 설정을 따를 수도, 게이트웨이별로 override 할 수도 있습니다. 전역 설정은 아래 "Fail Mode(전역 설정)"를 보세요. 특정 게이트웨이에 fail mode를 구성하려면:
- Additional Settings 에서 Edit 클릭 → HTTPS Inspection Settings 창이 열립니다.
- Server Side Fail Mode 를 구성합니다(내부 시스템 오류·서버 연결 오류 시).
- Use the global setting — 기본 전역 설정은 Fail Open.
- Override global settings — Fail-Open 또는 Fail-Close 선택.
- Client-Side Fail Mode 를 구성합니다(클라이언트 연결 문제 감지 시).
- Use the global setting — 기본 전역 설정은 Fail Open.
- Override global settings — Fail-Open 또는 Fail-Close 선택.
Bypass Under Load (9단계)
Bypass Under Load 는 Security Gateway가 과부하 상태일 때 연결성을 보장 하는 기능입니다(부하는 HTTPS Inspection이 아니라 어떤 이유로든 생길 수 있습니다). 게이트웨이는 안정될 때까지 HTTPS 연결을 우회 하며, 그 동안에는 HTTPS 페이로드를 검사하지 않습니다. 다시 안정되면 HTTPS Inspection이 자동으로 재개 됩니다. 이 기능은 기본적으로 비활성화 되어 있습니다.
HTTPS Inspection Deployment 뷰
이 뷰는 Learning Mode로 HTTPS Inspection을 켠 게이트웨이의 상태와 권장 사항 을 보여 줍니다. 또한 각 게이트웨이의 검사 상태를 다음과 같이 표시합니다.
| 상태 | 의미 |
|---|---|
| Full inspection | 게이트웨이에 Full Inspection이 설정됐을 때. 정책에 따라 모든 HTTPS 연결을 검사합니다. |
| Learning mode | Learning mode가 설정됐을 때. 배포 효과와 HTTPS Inspection 배포 권장 사항을 볼 수 있습니다. |
| Categorized HTTPS Inspection only | 게이트웨이에서 HTTPS Inspection이 비활성화되어 있고, Categorized HTTPS websites가 전역으로 구성 됐을 때(Manage and Settings 뷰 > Blades > Application Control & URL Filtering > Advanced Settings > URL Filtering). |
| Disabled | HTTPS Inspection이 비활성화되어 있고 Categorized HTTPS websites 옵션도 꺼져 있을 때. |
아웃바운드 CA 인증서 다루기
아웃바운드 CA 인증서 는 Security Management Server가 관리하는 게이트웨이들이 사용합니다. 게이트웨이 중 하나에서 HTTPS Inspection을 처음 켤 때, 아웃바운드 CA 인증서를 새로 만들거나 이미 조직에 배포된 CA 인증서를 가져와야 합니다. R82부터는 추가 아웃바운드 인증서 도 만들거나 가져올 수 있습니다.
아웃바운드 CA 인증서 만들기
아웃바운드 CA 인증서는 CER 파일 확장자로 저장 되며, 암호로 파일의 개인 키를 암호화 합니다. 게이트웨이는 이 암호로 HTTPS Inspection용 인증서에 서명합니다. 이 CA 인증서를 가져오는 다른 Security Management Server도 같은 암호로 파일을 열 기 때문에, 이 암호는 반드시 안전하게 보관해야 합니다.
아웃바운드 CA 인증서를 만든 뒤에는 반드시 내보내(export) 내부 클라이언트에 배포 해야 합니다. 배포하지 않으면 사용자가 HTTPS 사이트에 접속할 때 브라우저에 TLS 오류 메시지 가 뜹니다. 이런 연결을 로그로 남기는 문제 해결 옵션도 설정할 수 있습니다. 만든 인증서는 HTTPS Inspection 정책에서 아웃바운드 HTTPS 트래픽을 검사하는 규칙 에 사용합니다.
| 단계 | 작업 |
|---|---|
| 1 | SmartConsole Gateways & Servers 뷰에서 Security Gateway 객체를 더블 클릭 → Gateway Properties 창이 열립니다. |
| 2 | 탐색 트리에서 HTTPS Inspection 클릭. |
| 3 | Step 1 에서 Create 클릭. |
| 4 | 필요한 정보를 입력합니다(아래 표). |
| 5 | OK 클릭. |
| 6 | CA 인증서를 Export·Deploy 합니다. 아래 "생성된 CA 인증서 내보내기·배포" 참고. |
4단계에서 입력하는 정보는 다음과 같습니다.
| 항목 | 설명 |
|---|---|
| Issued by (DN) | 조직의 도메인 이름을 입력합니다. |
| Private key password | CA 인증서의 개인 키를 암호화하는 데 쓸 암호를 입력합니다. |
| Retype private key password | 암호를 다시 입력합니다. |
| Valid from | CA 인증서가 유효한 날짜 범위를 선택합니다. |
아웃바운드 CA 인증서 가져오기(Import)
조직에 이미 배포된 CA 인증서 를 가져오거나, 한 Security Management Server에서 만든 CA 인증서를 다른 Server로 가져올 수 있습니다.
HTTPS Inspection이 켜진 게이트웨이를 가진 각 Security Management Server 에서 다음을 해야 합니다.
- CA 인증서를 가져옵니다(Import).
- Server가 CA 인증서 파일을 열고 사용자용 인증서에 서명할 때 쓰는 암호를 입력합니다. 이 암호는 새 Server에 인증서를 가져올 때만 입력합니다.
| 단계 | 작업 |
|---|---|
| 1 | CA 인증서가 다른 Server에서 만들어졌다면, 만든 Server에서 먼저 인증서를 내보냅니다. 아래 "한 Server에서 다른 Server로 인증서 내보내기" 참고. |
| 2 | Gateways & Servers 뷰에서 Security Gateway 객체를 더블 클릭합니다. |
| 3 | 탐색 트리에서 HTTPS Inspection 클릭. |
| 4 | Step 1 에서 Import 클릭. |
| 5 | 인증서 파일을 찾아 지정합니다. |
| 6 | private key password 를 입력합니다. |
| 7 | OK 클릭. |
| 8 | CA 인증서가 다른 Server에서 만들어졌다면 클라이언트에 배포합니다. 아래 "생성된 CA 인증서 내보내기·배포" 참고. |
생성된 CA 인증서 내보내기·배포
사용자가 HTTPS Inspection이 쓰는 생성된 CA 인증서에 대해 경고를 받지 않도록 하려면, 그 CA 인증서를 신뢰할 수 있는 CA(trusted CA)로 설치 해야 합니다. Windows GPO 같은 배포 메커니즘으로 배포하면 클라이언트 컴퓨터의 신뢰할 수 있는 루트 인증서 저장소 에 추가됩니다. 사용자가 표준 업데이트를 돌리면 이 CA가 CA 목록에 들어가므로 브라우저에서 인증서 경고를 받지 않습니다.
GPO로 인증서 배포하기
| 단계 | 작업 |
|---|---|
| 1 | Security Gateway에서 인증서를 내보냅니다(두 방법 중 하나). |
| 2 | Group Policy Management Console 로 인증서를 Trusted Root Certification Authorities 인증서 저장소에 추가합니다. 아래 "그룹 정책으로 인증서 배포" 참고. |
| 3 | GPO 정책을 조직 내 클라이언트 컴퓨터에 Push 합니다. |
| 4 | 클라이언트 중 하나에서 HTTPS 사이트에 접속해 CA 인증서 배포가 됐는지 테스트 합니다. CA 인증서에 Issued by 필드에 입력한 이름 이 표시되는지도 확인합니다. |
인증서 내보내기(1단계)는 두 가지 방법이 있습니다.
- Option 1 — SmartConsole Security Policies 뷰 > HTTPS Inspection > Outbound Policy > 상단 도구 모음의 Outbound Certificates 클릭 → Manage Outbound Certificates 창에서 인증서를 고르고 내보내기 버튼 클릭 → 저장할 폴더를 골라 Save.
- Option 2 — SmartConsole Gateways & Servers 뷰에서 게이트웨이 객체를 더블 클릭 → 왼쪽 메뉴 HTTPS Inspection > Step 2 의 Export Certificate 클릭 → 폴더 선택 후 Save.
그룹 정책으로 인증서 배포
Active Directory Domain Services 와 GPO(Group Policy Object) 로 여러 클라이언트에 인증서를 배포하는 절차입니다. GPO는 여러 구성 옵션을 담을 수 있고, GPO 범위 안의 모든 컴퓨터에 적용됩니다.
| 단계 | 작업 |
|---|---|
| 1 | Microsoft Windows Server에서 Group Policy Management Console 을 엽니다. |
| 2 | 기존 GPO를 찾거나 새 GPO를 만들어 인증서 설정을 담습니다. 정책을 적용할 사용자가 속한 도메인·사이트·OU에 GPO를 연결 했는지 확인합니다. |
| 3 | GPO를 우클릭하고 Edit 선택 → Group Policy Management Editor 가 열립니다. |
| 4 | Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers 를 엽니다. |
| 5 | Action > Import 클릭. |
| 6 | Certificate Import Wizard 의 안내를 따라, SmartConsole에서 내보낸 인증서를 찾아 가져옵니다. |
| 7 | 탐색 창에서 Trusted Root Certification Authorities 를 클릭하고 5–6단계를 반복해 그 저장소에도 인증서 사본을 설치합니다. |
한 Security Management Server에서 다른 Server로 인증서 내보내기
조직에서 둘 이상의 Security Management Server 를 쓴다면, CA 인증서를 만든 Server에서 export_https_cert CLI 명령으로 먼저 내보낸 뒤에야 다른 Server로 가져올 수 있습니다.
명령 구문:
export_https_cert -helpexport_https_cert {[-local] | [-s <server address>]} [-f
<certificate file name in the FWDIR/tmp/ directory>]CA 인증서를 내보내려면 Security Management Server에서 다음 명령을 실행합니다.
$FWDIR/bin/export_https_cert -local -f <certificate file name in
the FWDIR/tmp/ directory>예:
$FWDIR/bin/export_https_cert -local -f mycompany.cer아웃바운드 HTTPS Inspection용 Trusted CA 다루기
클라이언트가 서버로 TLS 연결을 시작하면 게이트웨이가 연결을 가로채, 검사한 뒤 게이트웨이에서 지정된 서버로 가는 새 TLS 연결 을 만듭니다. 이때 게이트웨이는 서버 인증서를 검증 해야 합니다.
HTTPS Inspection은 미리 구성된 신뢰할 수 있는 CA 목록(Trusted CAs) 과 함께 제공됩니다. 이 목록은 필요할 때 Check Point가 갱신하며, Check Point Download Center에서 Management Server로 자동 다운로드 됩니다. Trusted CA 업데이트를 받은 뒤에는 게이트웨이에 정책을 설치 해야 합니다. 자동 업데이트를 끄고 수동으로 갱신할 수도 있습니다(sk64521 참고).
게이트웨이가 신뢰되지 않는 서버 인증서 를 받으면, 기본적으로 사용자는 생성된 인증서 대신 자체 서명(self-signed) 인증서 를 받습니다. 페이지에 서버 보안 인증서에 문제가 있다는 안내가 뜨지만, 사용자는 계속 서버로 진행할 수 있습니다. 신뢰되지 않는 서버 인증서를 차단 하도록 기본 설정을 바꾸려면 Security Policies > HTTPS Inspection > HTTPS Inspection Tools > Advanced Settings > Server Validations 에서 Untrusted server certificates 를 선택하세요.
Trusted Certificates 목록 관리하기
- SmartConsole Security Policies 뷰 > HTTPS Inspection > HTTPS Inspection Tools 의 Trusted Certificates 클릭 → Trusted Certificates 창이 열립니다.
- trusted CAs 패키지가 최신인지 확인합니다. status 섹션에서 다운로드된 패키지 버전, 마지막 업데이트 시각, 마지막 점검 시각 을 볼 수 있습니다.
- 인증서를 둘 중 한 방법으로 갱신합니다.
- Automatic update — Trusted CAs 패키지가 매일 새벽 2시에 자동 갱신 됩니다.
- Manual update — Updated Trusted CAs Package manually 를 선택하고 Update Now 를 눌러 수동 갱신합니다.
- Certificate 섹션에서 패키지에 포함된 모든 인증서를 봅니다. 활성화·비활성화하려면:
- 체크박스로 해당 인증서를 선택합니다(맨 위 체크박스를 누르면 전체 선택).
- 상단 메뉴의 Actions 에서 Enable 또는 Disable 선택.
- Custom trusted certificates 탭에서는 인증서를 import·export·delete 할 수 있습니다.
HTTPS Inspection 전역 설정(Global Settings)
모든 게이트웨이에 적용되는 전역 설정은 Security Policies > HTTPS Inspection > HTTPS Inspection Tools > Advanced Settings 에서 구성합니다.
Fail Mode (전역)
전역 fail mode를 바꾸려면:
- Security Policies 뷰 > HTTPS Inspection > Inbound Policy 또는 Outbound Policy > HTTPS Inspection Tools 의 Advanced Settings 클릭.
- Fail Mode 로 가서 설정을 고릅니다.
- Server Side Fail Mode — Bypass all requests (Fail-Open) 또는 Block all requests (Fail-Close).
- Client Side Fail Mode — Bypass all requests (Fail-Open) 또는 Block all requests (Fail-Close).
Categorization Mode
HTTPS 사이트를 분류하는 모드를 설정합니다.
| 모드 | 설명 |
|---|---|
| Background | 분류가 끝날 때까지 모든 요청을 허용 합니다. 캐시된 응답으로 분류할 수 없으면 uncategorized 응답을 받고 사이트 접근을 허용합니다. 백그라운드에서 Check Point Online Web Service 가 분류를 계속하고, 그 결과를 로컬에 캐시해 다음 요청에 씁니다. 지연(latency)이 줄어 듭니다. |
| Hold | 기본 설정 입니다. 캐시된 응답으로 분류할 수 없으면, Online Web Service가 분류를 마칠 때까지 요청을 차단 합니다. |
Server Validations
게이트웨이가 웹 사이트 서버로부터 신뢰되지 않는 인증서를 받았을 때 언제 연결을 끊을지 를 이 섹션에서 정합니다.
- Untrusted server certificate
- 선택하면 — 신뢰되지 않는 서버 인증서를 쓰는 사이트의 트래픽을 즉시 drop 합니다. 사용자는 브라우저가 페이지를 표시할 수 없다는 오류 페이지를 봅니다.
- 해제하면 — 신뢰되지 않는 서버 트래픽일 때 자체 서명 인증서 가 클라이언트에 표시됩니다. 사용자는 보안 인증서에 문제가 있다는 알림을 받지만 계속 진행할 수 있 습니다(기본값).
- Revoked server certificate (validate CRL)
- 선택하면 — 게이트웨이가 각 서버의 사이트 인증서를 OCSP 표준으로 검증 합니다. OCSP는 R80.10 미만에서 쓰던 CRL(Certificate Revocation List) 검증보다 빠르고 메모리를 훨씬 적게 씁니다.
- 해제하면 — 게이트웨이가 서버 사이트 인증서의 폐기 여부를 확인하지 않습니다.
서버 인증서에 OCSP가 지원되지 않으면 게이트웨이는 CRL 검증 을 씁니다. CRL에 닿을 수 없으면 그 인증서를 신뢰함(trusted)으로 간주 하며(기본 구성), CRL에 닿지 못했다는 HTTPS Inspection 로그가 발행됩니다. 이 동작은 Database Tool(GuiDBEdit Tool) 에서 바꿀 수 있습니다 — Other > SSL Inspection > general_confs_obj 에서 drop_if_crl_cannot_be_reached 속성을 false에서 true로 바꾸고, Access Control 정책을 설치 합니다.
CRL을 검증하려면 게이트웨이가 인터넷에 접근 할 수 있어야 합니다. 예를 들어 조직 환경에 프록시 서버가 있으면, 게이트웨이가 그 프록시를 쓰도록 구성해야 합니다.
프록시 구성: 1. SmartConsole Gateways & Servers 뷰에서 프록시가 필요한 게이트웨이를 더블 클릭. 2. Network Management > Proxy 로 이동. 3. Use custom proxy settings for this network object 와 Use proxy server 를 선택하고 프록시 IP 주소를 입력. (선택으로 기본 프록시 설정을 써도 됩니다.) 4. OK 클릭. 5. Access Control 정책을 설치 합니다.
- Expired Server Certificate
- 선택하면 — 서버 인증서가 만료됐으면 게이트웨이가 연결을 drop 합니다.
- 해제하면 — 게이트웨이가 만료 날짜를 가진 인증서를 만들어, 사용자가 계속 진행 할 수 있습니다(기본값).
- Track validation errors — 서버 검증을 로그로 남길지(SmartConsole Logs & Events 뷰 > Logs 에서 확인), 아니면 다른 알림을 띄울지 선택합니다.
Certificate Blocking
차단할 인증서 목록 을 만들 수 있습니다. 이 인증서를 쓰는 서버의 트래픽은 drop됩니다. 이 목록의 인증서가 Trusted CAs 목록에도 있으면, 차단 목록이 우선 합니다.
| 동작 | 설명 |
|---|---|
| New | 인증서를 추가합니다. 인증서 일련번호(16진수 HH:HH 형식) 와 인증서를 설명하는 코멘트를 입력합니다. |
| Edit | 차단된 인증서 목록의 세부 정보를 변경합니다. |
| Delete | 차단 목록에서 인증서를 삭제합니다. |
| Search | 차단 목록에서 인증서를 검색합니다. |
| Track dropped traffic | drop된 트래픽을 로그로 남길지(Logs & Events 뷰 > Logs), 다른 알림을 띄울지 선택합니다. |
Bypass Allow Lists
Check Point는 우회해야 더 잘 동작하는 잘 알려진 업데이트 서비스와 인증서 고정(certificate-pinned) 애플리케이션 목록을 동적으로 갱신 합니다.
- Well-known update services — 일부 잘 알려진 업데이트 서비스는 제대로 동작하려면 우회 해야 합니다. 갱신되는 서비스 목록은 sk98655 참고.
- Certificate-pinned Applications — 일부 모바일·데스크톱 앱은 특정 서버 인증서만 신뢰 합니다. 이런 앱은 HTTPS Inspection의 아웃바운드 CA 인증서로 서명된 인증서를 받으면 신뢰 문제로 연결을 끊을 수 있습니다. 인증서 고정 앱으로 분류된 클라이언트의 연결이 감지되면 선택한 동작을 취합니다.
선택할 수 있는 동작:
| 동작 | 설명 |
|---|---|
| Bypass | HTTPS Inspection을 우회해 끊김 없는 연결성 을 보장하고, 'bypass' 로그를 보냅니다. |
| Detect | 우회하지 않고 'detect' 로그를 보냅니다. 앱에 오류가 나거나 오작동 할 수 있습니다. |
| None | 우회하지 않고 전용 로그도 보내지 않습니다. 앱에 오류가 나거나 오작동할 수 있습니다. |
Session Logs
R82부터 게이트웨이는 통과하는 TLS 트래픽의 시각적 개요를 제공하는 세션 로그 를 보낼 수 있습니다. 이를 허용하려면:
- Send session logs 를 선택합니다.
- HTTPS Inspection Rule Base에서 해당 규칙의 Track 열을 Log 로 설정합니다.
세션 로그는 다음 공통 특성을 기준으로 개별 연결을 하나의 세션 로그로 묶 습니다.
- Source IP
- Destination IP
- SNI(Server Name Indication)
- HTTPS Inspection Action — 트래픽을 우회했는지 검사했는지.
- Bypass Reason — 우회한 경우에만 해당.
- Time Window — 같은 3시간 구간 안에 일어난 연결.
이렇게 묶은 세션 로그는 Bypass·Inspect 결정 같은 통계 뷰 를 만드는 데 쓰입니다. 자세한 내용은 아래 "HTTPS Inspection 통계 뷰" 참고.
Other — Intermediate CA
Certificate Authority Information Access 확장을 사용해, 인증서 동작에서 빠진 인증서를 가져 옵니다.
- 선택하면(기본값) — 인증서 체인에 포함되지 않은, 신뢰된 루트 CA가 발급한 중간(intermediate) CA 인증서를 인증서 정보를 이용해 자동으로 가져 옵니다.
- 해제하면 — 중간 CA가 서명했지만 인증서 체인에 포함되지 않은 웹 서버 인증서를 신뢰되지 않음으로 간주 합니다.
Bypass Under Load Logging
Bypass Under Load의 로그 유형을 설정하려면:
- Security Policies 뷰 > HTTPS Inspection > Inbound Policy 또는 Outbound Policy.
- HTTPS Inspection Tools 의 Advanced Settings 클릭.
- Other 클릭.
- Bypass Under Load Logging 섹션의 Track 필드에서 옵션을 선택.
- OK 클릭.
- Access Control 정책을 설치 합니다.
HTTPS Inspection 통계 뷰
R82부터 Logs & Events 뷰와 SmartView 에서 HTTPS Inspection 통계를 볼 수 있습니다. 이 뷰는 게이트웨이를 통과하는 HTTPS 트래픽의 시각적 개요(bypass·inspect 통계 포함) 를 제공하며, 게이트웨이가 세션 로그를 보낼 때마다 갱신 됩니다(위 "Session Logs" 참고).
구성
1. Management Server 또는 Log Server에서 필요한 Software Blade 활성화
- SmartConsole로 Management Server에 연결합니다.
- 왼쪽 탐색 패널에서 Gateways & Servers 뷰로 이동.
- 게이트웨이가 로그를 보내는 Management Server 또는 Log Server 객체를 더블 클릭.
- 왼쪽 패널에서 General Properties 클릭.
- Management 탭에서 다음 블레이드를 선택 — Logging & Status, SmartEvent Server, SmartEvent Correlation Unit.
- OK 클릭 후 변경을 publish 합니다.
- 좌측 상단의 Menu > Install database 클릭.
- 모든 객체를 선택하고 Install 클릭.
- 좌측 하단에서 작업 진행 상황을 확인합니다.
2. 게이트웨이에서 HTTPS Inspection 세션 로그 활성화
- SmartConsole Manage & Settings 뷰 > Blades > HTTPS Inspection > Advanced Settings → HTTPS Inspection - Global Settings 창이 열립니다.
- 왼쪽 탐색 트리에서 Session Logs 로 이동.
- Session Logs 를 선택하고 OK 클릭.
HTTPS Inspection 통계 보기
두 곳에서 통계를 볼 수 있습니다.
SmartConsole에서
- 왼쪽 탐색 패널에서 Logs & Events 클릭.
- 상단에서 [+] 를 눌러 새 탭을 엽니다.
- 왼쪽 섹션에서 Views 클릭.
- 상단 검색 필드에
HTTPS입력. - HTTPS Inspection Statistics 뷰를 더블 클릭.
SmartView에서
- 웹 브라우저로, 게이트웨이가 로그를 보내는 Management Server 또는 Log Server의 SmartView 포털에 접속합니다. 예:
- 상단에서 [+] 를 눌러 새 탭을 엽니다.
- 왼쪽 섹션에서 Views 클릭.
- 상단 검색 필드에
HTTPS입력. - HTTPS Inspection Statistics 뷰를 더블 클릭.
로그 상세를 보려면:
- 통계 뷰에서 차트·그래프를 더블 클릭해 관련 세션 로그를 모두 봅니다.
- 세션 로그를 더블 클릭해 관련 연결 로그(아래 패널에 표시) 를 봅니다.
- 연결 로그를 더블 클릭해 완전한 로그 상세 를 봅니다.
SNI 기반 사이트 분류
R80.30부터, HTTPS Inspection이 시작되기 전에 HTTPS 사이트를 분류 해 검사가 실패하더라도 연결성 장애를 막는 기능이 추가됐습니다.
SNI(Server Name Indication) 는 TLS 프로토콜의 확장으로, TLS 핸드셰이크가 시작될 때 호스트 이름을 알려 줍니다. 분류는 핸드셰이크 초반의 client hello 메시지에서 SNI 필드를 살펴 이뤄집니다. 올바른 사이트에 닿았는지 확인하기 위해, SNI는 인증서에 나오는 호스트의 Subject Alternative Name과 대조 검증 됩니다. 호스트의 신원이 확인되면 사이트를 분류하고, 그 연결을 검사할지 말지를 결정 합니다.
SNI 지원은 기본적으로 활성화 되어 있습니다.
비표준 포트의 HTTPS Inspection
HTTP를 쓰는 애플리케이션은 보통 HTTP 트래픽을 TCP 80 포트 로 보내지만, 일부 앱은 다른 포트로도 보냅니다. 일부 Software Blade는 80 포트의 HTTP만 검사하게 하거나, 비표준 포트의 HTTP도 검사 하게 설정할 수 있습니다.
보안 정책은 비표준 포트로 보내진 것까지 포함해 모든 HTTP 트래픽을 검사 하며, 이 옵션은 기본적으로 활성화되어 있습니다. 이 옵션은 Manage & Settings 뷰 > Blades > Threat Prevention > Advanced Settings > General > HTTPS Inspection 에서 설정합니다. 변경하면 Access Control 정책을 설치 해야 합니다.
TLS v1.3 트래픽 검사
R81부터 Check Point Security Gateway는 TLS(Transport Layer Security) v1.3에 기반한 트래픽을 검사 할 수 있습니다(RFC 8446 참고).
R81.10부터는 이 기능이 User-Space Firewall Mode(USFW)를 쓰는 게이트웨이(및 Cluster Member)에서 기본 활성화 됩니다. 지원 플랫폼 목록은 sk167052를 참고하세요.
HTTPS Inspection 기능은 트래픽을 복호화해 고급 위협·봇·기타 멀웨어로부터 더 잘 보호 합니다.