Cloudflare One 이해하기 시리즈 (8편 중 1편)
Cloudflare One은 Cloudflare의 SASE (Secure Access Service Edge) 플랫폼입니다. SASE는 기업 네트워킹 서비스와 제로 트러스트 (Zero Trust) 보안을 하나로 통합하는 아키텍처 모델이며, 제로 트러스트는 네트워크 안팎 어디에나 위협이 존재할 수 있다고 가정하고 모든 요청을 ID와 컨텍스트 (context) 기반으로 인증·인가하는 최소 권한 (least privilege) 보안 모델입니다.
Cloudflare One을 처음 접하면 제품 수가 많아 복잡해 보이지만, “트래픽이 어떻게 Cloudflare로 들어오고, 어디에서 검사되며, 어떻게 목적지로 나가는가”라는 흐름으로 보면 구조가 단순해집니다. 이 글에서는 Cloudflare One의 전체 구조와 연결 방식을 정리합니다.
Cloudflare 제품 전반은 Cloudflare 제품 총정리: 카테고리별 한눈에 보기에서, Cloudflare One 활용 사례는 Cloudflare 활용 사례 총정리: 서비스별 적용 방법에서 확인할 수 있습니다.
Cloudflare One 구성 요소
Cloudflare One은 여러 하드웨어 장비와 개별 솔루션을 조합하던 방식 대신, Cloudflare 글로벌 네트워크 위의 단일 컨트롤 플레인 (control plane)에서 네트워킹과 보안을 함께 관리합니다. 역할에 따라 구성 요소를 나누면 다음과 같습니다.
연결 (Connectivity) — 트래픽을 Cloudflare로 보내거나 Cloudflare에서 내부 인프라로 전달합니다.
Cloudflare One Client: 사용자 디바이스의 트래픽을 암호화해 Cloudflare로 전송하는 디바이스 에이전트입니다.
Cloudflare Tunnel: cloudflared데몬이 아웃바운드 연결만으로 내부 리소스를 Cloudflare에 연결합니다.
Cloudflare Mesh: 디바이스와 사설 네트워크를 서로 연결하는 양자 내성 암호 (post-quantum) 기반 메시 네트워킹입니다.
Cloudflare WAN: 지점 (Branch), 데이터센터, 클라우드 네트워크를 IPsec, GRE, 전용 회선으로 연결해 기존 MPLS (Multiprotocol Label Switching)와 SD-WAN을 대체합니다.
접근 제어 및 트래픽 검사 (Access & Inspection) — 누가 무엇에 접근할 수 있는지 판단하고 트래픽을 필터링합니다.
Access: 애플리케이션에 접근하는 사용자를 인증하고 요청마다 정책으로 인가합니다.
Gateway (Secure Web Gateway, SWG): DNS, Network, HTTP, Egress 트래픽을 검사하고 필터링합니다.
Cloudflare Network Firewall: 네트워크 계층에서 패킷 필터링을 수행하는 FWaaS (Firewall as a Service)입니다.
데이터 보호 (Data Protection) — 민감 데이터와 위험한 웹 콘텐츠로부터 조직을 보호합니다.
Browser Isolation (RBI): 브라우저 코드를 클라우드에서 실행해 위험한 웹사이트로부터 디바이스를 격리합니다.
Data Loss Prevention (DLP): 웹 트래픽과 SaaS 애플리케이션에서 민감 데이터를 탐지합니다.
Cloud Access Security Broker (CASB): SaaS와 클라우드 환경의 잘못된 설정과 데이터 노출 위험을 점검합니다.
이 밖에도 디바이스·네트워크·애플리케이션 성능을 모니터링하는 DEX (Digital Experience Monitoring), 이메일 보안 (Email security) 등이 Cloudflare One에 포함됩니다.
전체 트래픽 흐름
Cloudflare One의 트래픽 흐름은 크게 세 단계로 나눌 수 있습니다.
[ On-ramp ] [ Cloudflare global network ] [ Off-ramp / Destination ]
User device (Client) ---+ +--> Internet / SaaS
Branch / DC (WAN) ------+--> Access (AuthN / AuthZ) |
Office DNS (location) --+ Gateway (DNS / Network / HTTP) +--> Tunnel --> Private apps
Browser (PAC / RBI) ----+ DLP / Isolation / Firewall +--> Mesh / WAN --> Private networks- On-ramp: 사용자, 디바이스, 네트워크의 트래픽이 Cloudflare 네트워크로 들어옵니다.
- 정책 적용: 가장 가까운 Cloudflare 데이터센터에서 사용자 ID, 디바이스 상태, 목적지 등을 기준으로 Access, Gateway 등의 정책이 적용됩니다.
- Off-ramp / 목적지: 정책을 통과한 트래픽이 인터넷, SaaS, 또는 Tunnel·Mesh·WAN을 통해 사설 네트워크로 전달됩니다.
대표적인 세 가지 흐름을 예로 들면 다음과 같습니다.
- 사용자 → 인터넷 (SWG): Cloudflare One Client가 디바이스 트래픽을 Cloudflare로 보내면, Gateway가 DNS·Network·HTTP 정책으로 검사한 뒤 인터넷으로 내보냅니다. 사용자가 어디에 있든 동일한 인터넷 보안 정책이 적용됩니다.
- 사용자 → 사설 애플리케이션 (VPN 대체): Client가 사설 IP나 내부 호스트네임으로 향하는 트래픽을 Cloudflare로 보내면, Gateway와 Access 정책을 거친 뒤 Cloudflare Tunnel이 해당 트래픽을 내부 애플리케이션으로 전달합니다.
- 브라우저 → 웹 애플리케이션 (Clientless): Client 없이 공개 호스트네임으로 접속하면, Access가 IdP (Identity Provider) 로그인과 정책 평가를 수행하고, 허용된 요청만 Tunnel을 통해 오리진으로 전달됩니다.
On-ramp와 Off-ramp의 차이
Cloudflare One의 연결 방식은 On-ramp와 Off-ramp라는 개념으로 설명됩니다.
- On-ramp (진입 경로): 트래픽을 Cloudflare 네트워크 안으로 보냅니다. 예를 들어 Cloudflare One Client가 설치된 디바이스는 트래픽을 Cloudflare로 보내 검사와 정책 적용을 받습니다.
- Off-ramp (출구 경로): 트래픽을 Cloudflare 네트워크에서 고객 인프라로 보냅니다. 예를 들어 Cloudflare Tunnel은 사설 애플리케이션을 공용 인터넷에 노출하지 않고 트래픽을 전달합니다.
일부 연결 방식은 양방향 (bidirectional)을 지원하고, 일부는 한 방향만 지원합니다.
| 연결 방식 | 프로토콜 | 방향 | 배포 형태 | 사용 시점 |
|---|---|---|---|---|
| Cloudflare Tunnel | HTTP/2, QUIC | Off-ramp 전용 | 서버의 cloudflared 데몬 | 공인 IP 없이 사설 애플리케이션 공개 |
| Cloudflare One Client | MASQUE (기본값), WireGuard | 양방향 | 사용자 디바이스 에이전트 | 원격 근무자 (Remote worker) 디바이스 보호 |
| Cloudflare Mesh | MASQUE | 양방향 | Linux 호스트의 소프트웨어 | IoT, VoIP 디바이스가 있는 사이트 연결 |
| DNS locations | DNS (DoH, DoT, IPv4/IPv6) | On-ramp 전용 | DNS 리졸버 설정 | 에이전트 없이 DNS 필터링 |
| Proxy endpoints | HTTP/HTTPS | On-ramp 전용 | 브라우저 PAC 파일 | 에이전트 없이 웹 트래픽 필터링 |
| Clientless Web Isolation | HTTP/HTTPS | On-ramp 전용 | 접두사 URL + Access 인증 | 비관리 디바이스의 안전한 웹 접근 |
| GRE / IPsec 터널 | GRE, IPsec | 양방향 | 라우터·방화벽의 네트워크 터널 | 기존 네트워크 장비로 사이트 연결 |
| Cloudflare One Appliance | IPsec | 양방향 | 하드웨어·가상 어플라이언스 | 제로 터치 (zero-touch) 지점 (Branch) 배포 |
| Cloudflare Network Interconnect (CNI) | Direct, Partner, Cloud | 양방향 | 물리·가상 크로스 커넥트 | 공용 인터넷을 완전히 우회 |
Client, Tunnel, Mesh, WAN의 연결 대상과 방향
네 가지 핵심 연결 방식은 어디에 설치되는지, 무엇을 연결하는지, 어느 방향의 연결을 지원하는지에서 차이가 납니다.
| 구분 | Cloudflare One Client | Cloudflare Tunnel | Cloudflare Mesh | Cloudflare WAN |
|---|---|---|---|---|
| 설치 위치 | 사용자 디바이스 | 애플리케이션 근처 서버 (VM, 컨테이너, Kubernetes 등) | Linux 호스트 (헤드리스 모드) | 라우터·방화벽, Appliance, 전용 회선 |
| 연결 대상 | 디바이스 ↔ Cloudflare | Cloudflare → 사설 애플리케이션·네트워크 | 디바이스·서버·서브넷 간 | 지점 (Branch)·데이터센터·클라우드 네트워크 전체 |
| 방향 | 양방향 (L3 터널) | Off-ramp 전용 | 양방향 | 양방향 |
| 서버 시작 (server-initiated) 트래픽 | 지원 | 미지원 | 지원 | 지원 |
| 출발지 IP (source IP) | 디바이스 가상 IP로 연결 가능 | 오리진에는 cloudflared IP로 보임 | 종단 간 보존 | 터널 내에서 보존 |
- Cloudflare One Client: MASQUE (양자 내성 암호 지원) 또는 WireGuard로 디바이스 트래픽을 암호화해 Cloudflare로 보냅니다. 양방향 L3 터널이므로 디바이스의 가상 IP로 향하는 트래픽도 받을 수 있어, WAN이나 Mesh에 연결된 다른 리소스가 Client 디바이스로 연결을 시작할 수도 있습니다.
- Cloudflare Tunnel:
cloudflared가 포트7844(TCP/UDP)로 Cloudflare에 아웃바운드 연결만 생성하므로 방화벽에 인바운드 포트를 열 필요가 없습니다. 대신 서버에서 먼저 연결을 시작하는 프로토콜 (VoIP, SIP 등)은 지원하지 않고, HTTP가 아닌 트래픽 (SSH, RDP 등)은 오리진에서 원래 클라이언트 IP를 확인할 수 없습니다. HTTP 트래픽은CF-Connecting-IP헤더로 클라이언트 IP를 확인할 수 있습니다. - Cloudflare Mesh (beta): Linux 서버에서 Cloudflare One Client (
warp-cli)를 헤드리스 모드로 실행하는 Mesh 노드가 사설 Mesh IP를 받아 다른 참여자와 TCP, UDP, ICMP로 통신합니다. CIDR 경로를 광고 (advertise)해 클라이언트를 설치할 수 없는 IoT, 프린터, 레거시 서버가 있는 서브넷도 연결할 수 있습니다. - Cloudflare WAN: 기존 라우터·방화벽에서 GRE 또는 IPsec 터널을 만들거나, Cloudflare One Appliance, CNI로 사이트 전체를 연결합니다. Enterprise 전용 제품이며, WAN 자체는 연결 서비스이므로 검사와 정책은 Gateway나 Cloudflare Network Firewall로 적용합니다.
사용자·디바이스·서버·지점 (Branch)별 연결 방식
연결해야 하는 대상을 기준으로 정리하면 다음과 같습니다.
| 연결 대상 | 권장 연결 방식 | 설명 |
|---|---|---|
| 관리 디바이스를 사용하는 임직원 | Cloudflare One Client | 인터넷·사설 애플리케이션 트래픽 모두 On-ramp. Device Posture 검사 가능 |
| 협력사, 비관리 디바이스 (BYOD) | Access (공개 호스트네임), Clientless Web Isolation | 에이전트 설치 없이 브라우저로 접근 |
| 에이전트를 설치할 수 없는 사무실 네트워크 | DNS locations, Proxy endpoints | DNS 필터링 또는 PAC 파일 기반 HTTP 필터링 |
| 내부 웹·SSH·RDP 서버 | Cloudflare Tunnel | 공인 IP와 인바운드 포트 없이 Off-ramp |
| 양방향 통신이 필요한 서버·IoT·VoIP | Cloudflare Mesh | 서버 시작 트래픽과 출발지 IP 보존 필요 시 |
| 지점 (Branch), 데이터센터 | Cloudflare WAN (GRE/IPsec), Cloudflare One Appliance | 사이트 단위 연결, 기존 네트워크 장비 활용 |
| 공용 인터넷을 거치면 안 되는 환경 | Cloudflare Network Interconnect (CNI) | 전용 회선으로 직접 연결 (Enterprise) |
| 클라우드 VPC (AWS, Azure, GCP) | Multi-Cloud Networking, Tunnel, Mesh | 클라우드 VPN 연동 자동화 또는 소프트웨어 커넥터 |
도입을 주도하는 조직에 따라 시작점을 다르게 잡을 수도 있습니다. 보안팀은 네트워크 변경이 적은 Tunnel + Client, 네트워크 운영팀은 익숙한 라우팅 방식의 Cloudflare WAN (IPsec/GRE)이나 Appliance, DevOps 팀은 API로 자동화하기 쉬운 Mesh나 Tunnel부터 시작하는 것이 일반적입니다.
네트워크 연결과 접근 제어는 별개입니다
Cloudflare One을 설계할 때 자주 혼동하는 부분은 “연결되었다”와 “접근이 허용되었다”를 같은 의미로 보는 것입니다.
- 네트워크 연결 (Connectivity): Client, Tunnel, Mesh, WAN은 트래픽이 목적지까지 도달할 수 있는 경로를 만듭니다. Tunnel이 정상 (healthy) 상태라는 것은
cloudflared가 Cloudflare에 연결되었다는 의미일 뿐, 사용자가 애플리케이션에 접근할 수 있다는 뜻은 아닙니다. - 인증 (Authentication): Access가 IdP를 통해 사용자가 누구인지 확인합니다.
- 인가 (Authorization): Access 정책이 사용자 ID, 그룹, 디바이스 상태 (Device Posture), 위치 등을 평가해 이 요청을 허용할지 결정합니다. Access 정책은 기본 거부 (deny by default)이므로 경로가 있어도 허용 정책이 없으면 접근할 수 없습니다.
- 트래픽 검사 (Inspection): Gateway가 DNS, Network, HTTP 계층에서 트래픽 내용을 검사하고 필터링합니다.
즉, 연결 방식은 “길”을 만들고, Access와 Gateway는 그 길을 “누가, 어떤 조건에서, 어떤 트래픽으로” 지나갈 수 있는지를 결정합니다. Device Posture는 Client가 수집한 디바이스 상태 정보를 Access와 Gateway 정책의 조건으로 제공해 두 영역을 연결합니다.
여러 연결 방식을 조합할 때 고려 사항
대부분의 기업 환경에서는 여러 연결 방식을 함께 사용합니다. 이때 다음 사항을 확인해야 합니다.
- CIDR 중복 방지: 같은 IP 대역을 여러 연결 방식에 설정하지 않습니다. 중복될 경우 Cloudflare Tunnel이 Cloudflare WAN 경로보다 우선합니다.
- 자동 장애 조치 (failover) 없음: 서로 다른 연결 방식 간에는 자동으로 장애 조치되지 않으므로, 각 연결 방식 안에서 이중화를 구성해야 합니다. 예를 들어 운영 환경의 Tunnel은 별도 호스트에 여러
cloudflared커넥터를 두는 것이 좋습니다. - 가상 네트워크 (Virtual Networks): 여러 클라우드 VPC가
10.0.0.0/8처럼 같은 사설 대역을 사용하는 경우 가상 네트워크로 분리합니다. - MTU 계획: 터널이 겹쳐 캡슐화 (encapsulation)되면 유효 MTU가 줄어듭니다. 예를 들어 GRE는 1,476바이트, Cloudflare WAN 뒤의 Client는 약 1,300바이트이므로 엣지 장비에서 MSS 클램핑 (MSS clamping)을 설정해야 합니다.
- Mesh와 WAN 동시 사용: 레거시 라우팅 모드 계정에서는 Cloudflare WAN이 활성화된 상태로 Mesh를 사용할 수 없으며, Cloudflare One Unified Routing이 필요합니다.
대표 배포 패턴
- 원격 근무자 (Remote worker)와 지점 (Branch)이 있는 기업: 원격 근무자는 Cloudflare One Client, 지점은 IPsec 터널 (Cloudflare WAN), 클라이언트 없는 브라우저 접근이 필요한 내부 애플리케이션은 Cloudflare Tunnel로 연결합니다. Gateway 정책이 사용자 ID와 디바이스 상태를 기준으로 모든 트래픽을 검사합니다.
- 클라우드 중심 조직: 클라우드 VPC는 Multi-Cloud Networking으로 IPsec 터널을 자동 생성하고, Kubernetes·컨테이너 애플리케이션은 Tunnel, 임직원 디바이스는 Client로 연결합니다. Cloudflare WAN을 사용하지 않는다면 Mesh로 VPC 간 양방향 연결을 구성할 수 있습니다.
- 규제가 엄격한 기업: 데이터센터는 CNI로 공용 인터넷을 거치지 않고 연결하고, IPsec 터널을 백업 경로로 둡니다. 원격 근무자 (Remote worker)는 Client로 연결하며, 연결 방식과 관계없이 Gateway 정책으로 컴플라이언스 규칙을 적용합니다.
마치며
Cloudflare One은 On-ramp로 트래픽을 들여오고, Cloudflare 네트워크에서 Access와 Gateway 정책을 적용하고, Off-ramp로 목적지에 전달하는 구조입니다. 연결 대상 (사용자, 디바이스, 서버, 지점 (Branch))과 필요한 방향 (단방향, 양방향)을 먼저 정리하면 적합한 연결 방식을 쉽게 고를 수 있습니다.
다음 글에서는 사용자 디바이스의 On-ramp인 Cloudflare One Client와 디바이스 상태를 정책에 반영하는 Device Posture를 살펴봅니다.