Cloudflare One 이해하기 시리즈 (8편 중 5편)
이전 글에서는 Access가 애플리케이션 접근을 인가하는 방식을 살펴봤습니다. 이번 글부터는 트래픽과 데이터 보안으로 넘어가, Cloudflare One으로 들어온 트래픽의 내용을 검사하고 필터링하는 
Cloudflare Gateway의 정책을 정리합니다.
Cloudflare Gateway란
Cloudflare Gateway는 Cloudflare의 SWG (Secure Web Gateway)입니다. SWG는 사용자와 인터넷 사이에서 아웃바운드 트래픽을 검사해 보안 정책을 적용하고, 위협을 차단하고, 데이터 유출을 막는 보안 서비스입니다.
과거에는 네트워크 경계의 하드웨어 방화벽이 이 역할을 했지만, 사용자는 집과 공용 Wi-Fi에서 접속하고 업무 애플리케이션은 SaaS로 옮겨 가면서 경계 기반 모델로는 가시성과 통제를 유지하기 어려워졌습니다. Gateway는 트래픽을 중앙 데이터센터로 되돌려 보내는 대신, 사용자와 가까운 Cloudflare 데이터센터에서 정책을 적용합니다.
기존 방화벽에 익숙하다면 Gateway의 정책 계층을 다음과 같이 대응해 볼 수 있습니다.
| Gateway 정책 | 대응하는 기존 보안 기능 |
|---|---|
| DNS 정책 | DNS 계층 필터링 (연결 전에 도메인 차단) |
| Network 정책 | L4 상태 기반 방화벽 (stateful firewall), FWaaS |
| HTTP 정책 | L7 애플리케이션 방화벽 (TLS 복호화와 심층 검사를 수행하는 포워드 프록시) |
Gateway 정책의 종류
Gateway 정책은 트래픽을 서로 다른 계층에서 검사하는 여러 개의 검문소라고 볼 수 있습니다.
- 패킷 필터링 (Packet filtering): 사용자나 세션 정보 없이 출발지 IP, 프로토콜 같은 패킷 속성으로 트래픽을 차단합니다. 다른 정책이 실행되기 전에 불필요한 트래픽을 걸러 냅니다. Cloudflare Network Firewall이 담당하며 Enterprise 전용입니다.
- DNS 정책: 모든 DNS 쿼리를 검사해, 일치하면 도메인이 IP로 해석되지 않도록 차단합니다.
- Network 정책: TCP, UDP, GRE 패킷을 IP 주소, 포트, 프로토콜, SNI (Server Name Indication) 기준으로 검사합니다.
- HTTP 정책: URL, 헤더, 업로드·다운로드 파일 등 웹 요청의 전체 내용을 검사합니다.
- Egress 정책: 조직 전용 고정 IP로 트래픽을 내보내, 허용 IP 목록으로 접근을 제한하는 파트너 서비스에 연결할 수 있게 합니다 (Enterprise).
- Resolver 정책: DNS 쿼리를 기본 Cloudflare 리졸버 대신 지정한 DNS 서버로 보내, 내부 호스트네임을 해석하게 합니다 (Enterprise).
이 글에서는 핵심인 DNS, Network, HTTP 정책을 중심으로 살펴봅니다.
DNS, Network, HTTP 정책 비교
| 구분 | DNS 정책 | Network 정책 | HTTP 정책 |
|---|---|---|---|
| 검사 계층 | DNS 쿼리 (연결 이전) | L4 (TCP, UDP, GRE) | L7 (HTTP/HTTPS) |
| 볼 수 있는 정보 | 도메인, 쿼리 유형, 해석된 IP, 응답 레코드 | 목적지·출발지 IP, 포트, 프로토콜, SNI | 전체 URL, HTTP 메서드, 헤더, 파일 유형·크기, 애플리케이션, DLP 프로필 |
| 주요 선택자 | Domain, Host, 콘텐츠·보안 카테고리, Application, Resolved IP, Location | Destination IP/Port, Protocol, Detected Protocol, SNI, Virtual Network, Device Posture | Domain, URL, HTTP Method, 파일 유형, Application, DLP Profile, Device Posture |
| 주요 Action | Allow, Block, Override, Safe Search, YouTube Restricted Mode | Allow, Block, Network Override | Allow, Block, Redirect, Isolate, Do Not Inspect, Do Not Isolate, Do Not Scan, Quarantine |
| 적용 범위 | 모든 프로토콜·애플리케이션 (DNS를 사용하는 한) | 모든 포트의 TCP·UDP 트래픽 | 웹 트래픽 |
| TLS 복호화 필요 여부 | 불필요 | 불필요 (SNI는 암호화 전에 전송됨) | HTTPS의 URL·본문을 보려면 필요 |
| 대표 용도 | 악성·유해 도메인 전체 차단 | SSH·RDP 등 비 HTTP 서비스, 특정 포트 차단 | 특정 URL 차단, 파일 업로드·다운로드 통제, 악성코드 검사, 계정 로그인 제어 |
- DNS 정책은 연결이 시작되기 전 가장 이른 단계에서 동작하므로 배포가 가장 빠르고 적용 범위가 가장 넓습니다. 차단 시에는 차단 페이지를 보여 주거나, 차단 페이지를 끄면
0.0.0.0(IPv6는::)으로 응답합니다. - Network 정책은 DNS·Network·HTTP 정책 중 HTTP가 아닌 트래픽의 연결을 제어하는 계층입니다. Device Posture나 사용자 ID 같은 조건을 쓰려면 Client처럼 사용자를 식별할 수 있는 연결이 필요합니다.
- HTTP 정책은 DNS와 Network 정책이 볼 수 없는 내용까지 검사합니다. 예를 들어 회사 Google Workspace 계정은 허용하고 개인 Gmail 로그인은 차단하는 식의 세밀한 제어가 가능합니다. 다만 HTTPS 트래픽의 내용을 보려면 TLS 복호화와 사용자 디바이스의 Cloudflare 루트 인증서 설치가 필요하며, 이는 다음 글에서 자세히 다룹니다.
On-ramp에 따라 적용 가능한 정책
Gateway가 어떤 정책을 적용할 수 있는지는 트래픽이 어떤 On-ramp로 들어오는지에 따라 결정됩니다.
| 연결 방식 (On-ramp) | DNS 정책 | Network 정책 | HTTP 정책 | 적합한 대상 |
|---|---|---|---|---|
| Cloudflare One Client | O | O | O | 관리 디바이스를 쓰는 이동 사용자 |
| DNS 리졸버 설정 (DNS location) | O | X | X | 비관리 디바이스, 네트워크 전체, 초기 도입 |
| Proxy endpoint (PAC 파일) | X | X | O (브라우저만) | 에이전트 없이 브라우저 수준의 HTTP 필터링 |
| 네트워크 터널 (Cloudflare WAN의 IPsec/GRE) | O | O | O | 지점 (Branch), 데이터센터 등 사이트 단위 |
- Client는 가장 넓은 범위를 제공하며, 디바이스 단위 배포에 권장되는 방식입니다. 다만 2편에서 본 것처럼 Client 모드에 따라 적용 범위가 달라집니다 (예: DNS only 모드는 DNS 정책만 적용).
- DNS 리졸버 설정은 라우터나 디바이스의 DNS 설정만 바꾸면 되므로 가장 빨리 도입할 수 있지만 DNS 정책만 적용됩니다.
- 여러 On-ramp를 함께 사용할 수 있습니다. 예를 들어 원격 근무자 (Remote worker)는 Client, 지점 (Branch)은 네트워크 터널로 연결합니다.
ID와 디바이스 컨텍스트
Client로 연결한 사용자에 대해서는 트래픽 속성뿐 아니라 사용자와 디바이스 정보도 정책 조건으로 사용할 수 있습니다.
- 사용자 ID: IdP에서 받은 이메일, 그룹 구성원, SAML 속성 등
- Device Posture: OS 버전, 디스크 암호화, 방화벽 상태, 관리 디바이스 시리얼 번호 일치 여부 등
예를 들어 “특정 그룹에 속하고 동시에 디스크 암호화가 켜진 디바이스에서만 민감한 SaaS 애플리케이션을 허용”하는 HTTP 정책을 만들 수 있습니다. 4편에서 설명했듯이 Gateway의 그룹 조건은 Access 규칙 그룹이 아니라 IdP·SCIM으로 동기화된 IdP 그룹을 사용합니다.
정책 평가 순서 (Order of enforcement)
Gateway 정책을 설계할 때 가장 중요한 것은 정책이 어떤 순서로 평가되는지입니다.
정책 유형 간 순서
DNS query ----> [DNS policies (pre-resolution)]
[Resolver policies]
[DNS policies (post-resolution)] ----> Resolved / Blocked
Connection ---> [Network Firewall] -> [Egress] -> TCP SYN to origin
-> [Network policies] -> HTTP(S)?
|-- HTTPS -> [Do Not Inspect?] ---> [Isolate]
|-- HTTP ------------------------> [Isolate]
| -> [Allow/Block/...] -> [DLP / AV]
+-- non-HTTP ---------------------> Internet- 해석 전에 평가되는 선택자를 가진 DNS 정책
- Resolver 정책 (설정한 경우)
- 해석 후에 평가되는 선택자를 가진 DNS 정책
- Egress 정책 (설정한 경우)
- Network 정책
- HTTP 정책
이 순서에서 알아 둘 점은 다음과 같습니다.
- DNS 정책은 독립적입니다. DNS 정책으로 사이트를 차단해도 대응하는 Network·HTTP 정책이 없으면, 사용자가 IP 주소를 직접 알고 있을 경우 접근할 수 있습니다. 중요한 차단은 DNS와 HTTP (또는 Network)를 함께 구성합니다.
- Network 정책이 HTTP 정책보다 먼저 평가됩니다. Network 정책에서 차단된 트래픽은 HTTP 정책의 차단 페이지가 표시되지 않고, Network 정책의 클라이언트 알림 설정을 따릅니다.
- 정책 평가 전에 오리진 연결을 먼저 확인합니다. Gateway는 목적지 서버로 TCP 연결을 먼저 맺고, 성공한 경우에만 정책을 적용합니다. 따라서 Network·HTTP Block 정책으로는 최초 TCP SYN이 목적지에 도달하는 것까지 막을 수 없으며, 이를 막으려면 Cloudflare Network Firewall (Enterprise) 규칙이 필요합니다.
같은 정책 유형 안에서의 순서
- 기본은 우선순위 순서의 처음 일치 (first match)입니다. Allow 또는 Block 정책에 일치하면 평가를 멈추므로, 구체적인 예외 정책을 위에, 일반적인 정책을 아래에 둡니다.
- DNS 정책은 해석 전 선택자 (예: Domain)를 가진 정책이 해석 후 선택자 (예: Resolved Country)를 가진 정책보다 먼저 평가됩니다. 예를 들어 우선순위 1이 “해석된 IP가 미국이면 Allow”, 우선순위 2가 “
example.com이면 Block”이라도example.com은 차단됩니다. 한 정책에 두 종류의 선택자가 섞여 있으면 전체가 해석 후에 평가됩니다. - HTTP 정책은 Action 유형에 따라 단계적으로 평가됩니다.
- Do Not Inspect 정책 (일치하면 나머지 HTTP 정책을 모두 건너뛰고 허용)
- Isolate 정책
- Allow, Block, Do Not Scan 정책
- 요청 본문 검사 (DLP, 안티바이러스, 파일 샌드박싱)
HTTP 정책은 처음 일치한 결정을 먼저 기록한 뒤 본문을 검사하므로, Allow 정책으로 허용 기록이 남은 요청이 이후 DLP Block 정책으로 차단될 수도 있습니다. 이 동작은 8편에서 DLP와 함께 다시 살펴봅니다.
기본 동작과 Access와의 관계
- 일치하는 정책이 없으면 기본적으로 허용됩니다 (DNS, Network, HTTP 모두). 즉, Gateway는 허용 기본 (permissive) 모델입니다. 기본 차단 모델이 필요하면 가장 낮은 우선순위에 전체 차단 정책을 두고, 그 위에 허용할 대상을 정의합니다.
- Gateway Allow는 Access를 우회하지 않습니다. 사설 IP로 향하는 트래픽이 Access 애플리케이션으로 보호되고 있다면, Gateway에서 허용되더라도 Access 정책이 다시 평가됩니다. 반면 Gateway Block에 일치하면 그 즉시 평가가 끝납니다.
- 정책을 만들거나 수정하면 모든 Cloudflare 데이터센터에 반영되기까지 최대 60초가 걸릴 수 있습니다.
목적별 정책 선택 기준
| 목적 | 정책 유형 | 이유 |
|---|---|---|
| 특정 URL 경로만 차단 | HTTP | 도메인이 아닌 전체 URL 경로를 검사 |
| 도메인 전체 차단 | DNS | 도메인이 해석되지 않도록 차단 |
| SSH, RDP 등 비 HTTP 트래픽 차단 | Network | 모든 포트의 TCP·UDP 검사 |
| 악성코드와 위협 차단 | DNS와 HTTP | DNS는 알려진 악성 도메인을, HTTP는 허용된 트래픽 속의 위협을 차단 |
| 파트너에게 고정 출발지 IP 제공 | Egress | 서드파티가 조직의 IP로 식별 |
| 다른 정책 이전에 트래픽 차단 | 패킷 필터링 | 사용자 정보 없이 패킷 속성으로 차단 |
| 내부 도메인을 사내 DNS로 해석 | Resolver | 기본 Cloudflare 리졸버를 대체 |
계층형 정책 설계 예시
실제 환경에서는 여러 계층의 정책을 겹쳐 구성합니다.
- DNS: 모든 보안 위협 카테고리 (악성코드, 피싱, C2 등)를 차단합니다. Gateway 도입 시 가장 먼저 권장되는 정책입니다.
- DNS: 성인물, 도박 등 허용 사용 정책 (AUP)에 어긋나는 콘텐츠 카테고리를 차단합니다.
- Network: 개발자 그룹이 아닌 사용자의 SSH (22번 포트) 접근을 차단하고, 사설 네트워크 대역은 관리 디바이스 Posture를 통과한 경우에만 허용합니다.
- HTTP: 승인되지 않은 파일 공유 서비스로의 업로드를 차단하고, 실행 파일 다운로드는 안티바이러스로 검사합니다.
- HTTP: 분류되지 않았거나 새로 등록된 도메인은 Browser Isolation으로 격리합니다 (7편).
정책을 적용할 때는 기기 연결 → Gateway 로그로 트래픽 수신 확인 → 권장 보안 정책 적용 → 조직별 정책 추가 순서로 진행하고, 넓은 범위의 차단 정책은 파일럿 그룹에 먼저 적용하는 것이 안전합니다. 정책이 의도대로 동작하지 않으면 Gateway 활동 로그에서 어떤 정책에 일치했는지부터 확인합니다.
마치며
Gateway는 DNS 정책으로 연결 전에 도메인을, Network 정책으로 포트와 프로토콜을, HTTP 정책으로 웹 요청의 내용을 검사합니다. 어떤 정책을 적용할 수 있는지는 On-ramp가 결정하고, 실제 결과는 정책 유형 간 순서와 같은 유형 안의 처음 일치 원칙에 따라 정해집니다.
다음 글에서는 HTTP 정책의 전제 조건인 TLS Decryption이 왜 필요하고 어떻게 동작하는지, 그리고 HTTP 정책과 어떻게 연계되는지 살펴봅니다.