Cloudflare One 이해하기 시리즈 (8편 중 2편)
- 전체 구조와 연결 방식
- Cloudflare One Client와 Device Posture (현재 글)
- Tunnel, Mesh, Cloudflare WAN 비교와 적용 시나리오
- Access 인증·인가와 접근 정책
- Gateway DNS·Network·HTTP 정책
- TLS Decryption과 HTTP 정책
- Browser Isolation 구조와 적용 시나리오
- DLP, Data Classification, CASB
이전 글에서 Cloudflare One은 On-ramp로 트래픽을 들여오고, Cloudflare 네트워크에서 정책을 적용한 뒤, Off-ramp로 목적지에 전달하는 구조라고 정리했습니다. 이 글에서는 사용자 디바이스의 대표적인 On-ramp인 Cloudflare One Client와, Client가 수집한 디바이스 상태를 정책에 반영하는 Device Posture를 살펴봅니다.
Cloudflare One Client의 역할
Cloudflare One Client (이전 이름: WARP)는 디바이스의 트래픽을 암호화해 Cloudflare 글로벌 네트워크로 보내는 디바이스 에이전트입니다. Client는 두 가지 방식으로 Cloudflare와 연결합니다.
- 프록시 터널 (Proxy tunnel): 디바이스의 인터넷 트래픽과 사설 네트워크 트래픽을 WireGuard 또는 MASQUE 프로토콜로 암호화해 Cloudflare로 보냅니다.
- DNS 프록시 (DNS proxy): 디바이스의 DNS 쿼리를 DoH (DNS over HTTPS)로 Cloudflare에 보내, Gateway DNS 정책으로 필터링할 수 있게 합니다.
동시에 Client는 OS 버전, 디스크 암호화 상태, 특정 애플리케이션 설치 여부 같은 디바이스 상태 정보를 보고합니다. 즉, Client는 트래픽을 들여오는 On-ramp이자 디바이스 상태를 알려 주는 센서 역할을 함께 합니다.
Client는 주요 OS를 모두 지원하며, Intune, JAMF, JumpCloud 같은 엔드포인트 관리 (MDM) 도구로 배포할 수 있습니다. 디바이스에는 GUI와 백그라운드 서비스 (WARP daemon) 외에 CLI 도구인 warp-cli와 진단 도구인 warp-diag가 함께 설치됩니다.
Client를 배포하면 다음 기능을 사용할 수 있습니다.
- 위치와 무관한 보안 정책: 사용자가 사무실 밖에 있어도 동일한 Gateway 정책이 적용됩니다.
- 고급 웹 필터링과 위협 방어: HTTP 필터링, 안티바이러스 (AV) 검사, Browser Isolation, ID 기반 정책
- 가시성: Shadow IT Discovery로 사용 중인 SaaS를 파악하고, DEX로 디바이스·네트워크 성능을 모니터링
- Device Posture 검사: 디바이스 상태를 Access와 Gateway 정책의 조건으로 사용
- 사설 네트워크·인프라 접근: Cloudflare Tunnel 뒤의 내부 네트워크 접근, 단기 인증서 (short-lived certificate) 기반 SSH 접근 (Access for Infrastructure)
Client 동작 모드
Client의 동작 모드 (Client mode)는 어떤 트래픽을 Cloudflare로 보낼지를 결정하고, 그에 따라 사용할 수 있는 Zero Trust 기능이 달라집니다.
| 모드 | 적합한 용도 | DNS 필터링 | Network 필터링 | HTTP 필터링 | 사용 가능한 주요 기능 |
|---|---|---|---|---|---|
| Traffic and DNS (기본값) | 전체 보안 적용 | O | O | O | DNS·Network·HTTP 정책, Browser Isolation, ID 기반 정책, Device Posture, AV 검사, DLP |
| DNS only | 트래픽 라우팅 없이 DNS 필터링만 | O | X | X | DNS 정책 |
| Traffic only | 기존 DNS 필터링 솔루션 유지 | X | O | O | Network·HTTP 정책, Browser Isolation, ID 기반 정책, Device Posture, AV 검사, DLP |
| Local proxy | 특정 애플리케이션 트래픽만 필터링 | X | X | O | 로컬 프록시로 보낸 트래픽에 대한 HTTP 정책, Browser Isolation, DLP 등 |
| Posture only | 트래픽 라우팅 없이 디바이스 상태만 수집 | X | X | X | Access 정책의 Device Posture 조건 |
- Traffic and DNS 모드는 모든 포트와 프로토콜의 트래픽과 DNS 쿼리를 Cloudflare로 보내므로, Cloudflare One의 기능을 가장 넓게 사용할 수 있습니다.
- Traffic only 모드는 DNS를 OS에 맡기므로, 도메인 기반 Split Tunnels와 Local Domain Fallback처럼 Client의 DNS 처리에 의존하는 기능은 사용할 수 없습니다. Windows, Linux, macOS에서만 지원됩니다.
- Local proxy 모드는 Client가
127.0.0.1의 지정 포트 (기본값40000)에서 SOCKS5/HTTP 프록시로 동작하며, 애플리케이션이나 시스템 프록시 설정에서 명시적으로 지정한 트래픽만 처리합니다. MASQUE 프로토콜이 필요하고, 요청당 10초의 타임아웃 제한이 있습니다.
Client 배포 구조: 등록, Device Profile, Split Tunnels
Client의 배포와 동작은 크게 세 가지 설정으로 제어됩니다.
| 구성 요소 | 결정하는 것 | 설정 위치 |
|---|---|---|
| 디바이스 등록 권한 (Device enrollment permissions) | 누가 디바이스를 조직에 등록할 수 있는가 | Access 정책 (warp 유형 애플리케이션) |
| Device Profile | 등록 후 Client가 어떻게 동작하는가 (모드, Split Tunnels 등) | Device profiles |
| Split Tunnels | 어떤 목적지의 트래픽을 Client 터널로 보낼 것인가 | Device Profile 내부 설정 |
디바이스 등록 권한
디바이스 등록 권한은 Access 정책으로 정의합니다. 예를 들어 @company.com으로 끝나는 이메일을 가진 사용자만 등록을 허용하고, 로그인 방법으로 사용할 IdP를 지정할 수 있습니다. 내부적으로는 warp 유형의 Access 애플리케이션으로 동작하므로, 등록 관련 문제는 Devices 메뉴가 아니라 Access 설정에서 확인해야 합니다.
- Device Posture는 등록 정책에 사용할 수 없습니다. Client는 등록이 끝난 후에야 상태를 검사할 수 있기 때문입니다.
- 사람이 로그인하지 않는 디바이스 (서버, 키오스크 등)는 서비스 토큰 (service token)으로 등록합니다.
Service Auth액션 정책에 서비스 토큰을 지정하고, MDM 배포 파라미터에 토큰의 Client ID와 Client Secret을 넣습니다. 이렇게 등록된 디바이스는non_identity@<team-name>.cloudflareaccess.com으로 표시되며, ID 기반 정책은 적용되지 않습니다. - Enterprise 고객은 등록 시 mTLS (상호 TLS) 인증서를 요구할 수도 있습니다.
Device Profile
Device Profile은 특정 디바이스 집합에 적용할 Client 설정입니다. 사용자 이메일, IdP 그룹, OS 종류와 버전, 관리 네트워크 (managed network), SAML 속성, 서비스 토큰 등을 조건으로 여러 프로필을 만들 수 있습니다.
- 프로필은 위에서부터 순서대로 평가되고 처음 일치한 프로필이 적용 (first match)됩니다. 어느 프로필에도 일치하지 않으면 기본 (Default) 프로필이 적용됩니다.
- ID 기반 조건은 사용자가 IdP 로그인으로 디바이스를 등록한 경우에만 동작합니다. 서비스 토큰으로 등록한 디바이스는 IdP 그룹 조건에 일치하지 않습니다.
- 모드, Local Domain Fallback, Split Tunnels를 변경하면 Client 연결이 재시작되어 잠시 연결이 끊길 수 있으며, 변경 사항이 디바이스에 반영되기까지 최대 10분이 걸릴 수 있습니다.
- MDM 설정 파일로 배포한 경우, 파일에 지정된 설정이 대시보드의 프로필 설정보다 우선합니다. 대시보드에서 바꾼 설정이 반영되지 않는다면 MDM 설정을 먼저 확인해야 합니다.
Split Tunnels
Split Tunnels는 어떤 IP 주소나 도메인의 트래픽을 Client 터널로 보낼지 결정합니다. 프로필마다 Exclude 또는 Include 중 하나의 모드만 선택할 수 있으며, 모드를 바꾸면 기존 항목이 기본값으로 초기화됩니다.
| 모드 | 동작 | 적합한 목적 |
|---|---|---|
| Exclude (기본값) | 지정한 대상을 제외한 모든 트래픽을 Cloudflare로 전송 | 인터넷 보안 (SWG), VPN 대체 + SWG |
| Include | 지정한 대상의 트래픽만 Cloudflare로 전송 | 사설 네트워크 접근만 필요한 경우, 다른 VPN과 공존 |
Split Tunnels를 설계할 때는 다음 사항을 주의해야 합니다.
- 기본 Exclude 목록에는 사설 IP 대역이 포함되어 있습니다.
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10등이 기본적으로 제외되므로, Tunnel 뒤의 사설 네트워크에 접근하려면 해당 대역을 Exclude 목록에서 빼야 합니다. - Include 모드에서는 Zero Trust 도메인을 직접 추가해야 합니다. Device Posture와 세션 관리처럼 Client를 통과하는 트래픽에 의존하는 기능을 쓰려면
<team-name>.cloudflareaccess.com등을 Include 목록에 넣어야 합니다. Include 목록에 없는 트래픽은 Network·HTTP 정책의 적용을 받지 않습니다. - Split Tunnels는 IP 트래픽에만 영향을 줍니다. DNS 쿼리는 여전히 Gateway가 처리하므로, 내부 도메인을 사내 DNS 서버로 보내려면 Local Domain Fallback을 설정해야 합니다.
- 가능하면 도메인보다 IP 주소로 항목을 추가하는 것이 권장됩니다.
Device Posture: 디바이스 상태를 정책의 조건으로
Device Posture 검사를 설정하면 관리되고 있거나 안전한 상태의 디바이스에서만 보호된 애플리케이션이나 네트워크 리소스에 접근하도록 제한할 수 있습니다. 사용자 ID가 “누구인가”를 확인한다면, Device Posture는 “어떤 디바이스에서 접근하는가”를 확인합니다.
Posture 검사의 세 가지 유형
| 유형 | 검사 주체 | Client 필요 여부 | 사용 가능한 정책 |
|---|---|---|---|
| Cloudflare One Client 검사 | Client가 디바이스를 직접 검사 | 필요 | Access, Gateway |
| 서비스 간 연동 (Service-to-service) | 서드파티 EDR·MDM API에서 상태 조회 | 필요 | Access, Gateway |
| Access 연동 검사 (Access integration) | Access가 인증 시점에 확인 | 불필요 | Access만 |
Cloudflare One Client 검사는 Traffic and DNS, Traffic only, Posture only 모드에서 지원됩니다. 대표적인 검사 항목과 지원 OS는 다음과 같습니다.
| 검사 항목 | macOS | Windows | Linux | iOS | Android/ChromeOS |
|---|---|---|---|---|---|
| OS 버전 (OS version) | O | O | O | O | O |
| Require Gateway / Require WARP | O | O | O | O | O |
| 디스크 암호화 (Disk encryption) | O | O | O | X | X |
| 애플리케이션 실행 확인 (Application check) | O | O | O | X | X |
| 파일 확인 (File check) | O | O | O | X | X |
| 클라이언트 인증서 (Client certificate) | O | O | O | X | X |
| 디바이스 시리얼 번호 (Device serial numbers) | O | O | O | X | X |
| 방화벽 (Firewall) | O | O | X | X | X |
| 도메인 가입 (Domain joined) | X | O | X | X | X |
| 안티바이러스 (Antivirus) | X | O | X | X | X |
이 외에도 SentinelOne, Carbon Black처럼 에이전트 실행 여부를 Client가 로컬에서 확인하는 검사가 있습니다.
서비스 간 연동은 Client가 설치된 디바이스에 대해 Cloudflare가 서드파티 API에서 상태 정보를 가져옵니다. CrowdStrike, Kolide, Microsoft Endpoint Manager, SentinelOne, Tanium, Uptycs, Workspace ONE과 사용자 정의 연동 (Custom integration)을 지원합니다. 예를 들어 EDR의 디바이스 위험 점수를 Access 정책 조건으로 사용할 수 있습니다.
Access 연동 검사는 Client 없이 동작하며 Access 정책에서만 사용할 수 있습니다. Microsoft Entra ID 조건부 액세스 (Conditional Access)와 mTLS가 여기에 해당합니다. Client를 설치할 수 없는 환경에서 디바이스 신뢰를 확인할 때 유용합니다.
Posture 결과를 정책에 적용하기
Posture 검사를 활성화하면 결과를 다음 정책에서 사용할 수 있습니다.
- Access 정책: 활성화된 Posture 속성이 선택자 (selector) 목록에 나타납니다. 예를 들어 “재무팀 그룹이면서 디스크 암호화가 된 디바이스”만 재무 시스템에 접근하도록
Require규칙을 구성할 수 있습니다. - Gateway Network·HTTP 정책:
Passed Device Posture Check선택자로 조건을 지정합니다. 예를 들어 회사 디바이스 시리얼 번호 목록에 없는 디바이스의 사설 네트워크 접근을 차단할 수 있습니다.
Access 정책의 구성 방법은 4편, Gateway 정책은 5편에서 자세히 다룹니다. 정책에 적용하기 전에는 대시보드의 디바이스 상세 정보에서 Posture checks 탭을 열어 Pass/Fail 결과가 예상과 일치하는지 먼저 확인하는 것이 좋습니다.
Posture 검사가 동작하기 위한 조건
Client 검사와 서비스 간 연동 검사는 트래픽이 Client를 통과해야 디바이스를 식별할 수 있습니다. 특히 Split Tunnels를 Include 모드로 쓰는 경우 다음 대상이 Client 터널에 포함되어야 합니다.
- Access 정책에 Posture를 사용하는 경우: Zero Trust 인증에 사용하는 IdP와
<team-name>.cloudflareaccess.com - Access 또는 Gateway 정책으로 보호하는 애플리케이션
정책 반영 주기
Posture 결과는 실시간이 아니라 주기적으로 갱신되므로, 반영 시점을 이해하고 설계해야 합니다.
- 폴링 주기 (Polling frequency): Client 검사는 기본 5분마다 디바이스 상태를 확인합니다. 서비스 간 연동은 연동 설정 시 지정한 주기로 서드파티 API를 조회합니다.
- Access: 폴링 주기와 같은 속도로 Posture 변화를 감지합니다.
- Gateway: 요청마다 정책을 평가하기 때문에 Posture 결과를 로컬 캐시에 두고 5분마다 갱신합니다. 따라서 폴링 주기가 10분이면 Gateway가 변화를 감지하기까지 최대 15분이 걸릴 수 있습니다.
- 진행 중인 세션: Gateway는 세션 시작 시점에만 Posture를 평가합니다. 예를 들어 Posture 검사를 통과해 SSH 세션을 연 뒤 검사가 실패하더라도, 이미 열린 세션은 유지됩니다.
- 만료 (Expiration): Posture 결과는 기본적으로 새 데이터로 덮어쓰기 전까지 유효합니다. API로 만료 시간을 지정할 수 있으며, 폴링 주기의 두 배 이상으로 설정하는 것이 권장됩니다.
Device --(schedule)--> Client ------> Cloudflare ------------> Access policy
|
+--(5 min cache)----> Gateway policy
Device --> EDR / MDM --(interval)---> Cloudflare운영 시 고려 사항
- 단계적 적용: Posture 조건은 처음부터 전체 사용자에게 적용하기보다, 파일럿 그룹에 먼저 적용해 Pass/Fail 결과와 오탐 (false positive)을 확인한 뒤 넓혀 가는 것이 안전합니다.
- 다른 VPN과의 공존: 다른 VPN 클라이언트가 DNS를 제어하면 Client의 DNS 처리와 충돌할 수 있습니다. 이 경우 Split Tunnels를 Include 모드로 쓰거나 Traffic only 모드를 검토합니다.
- 공용 Wi-Fi 로그인 페이지 (Captive portal): 호텔이나 공항 Wi-Fi의 로그인 페이지를 감지하면 Client가 일시적으로 연결을 해제합니다. 사용자 불편이 자주 발생하는 지점이므로 관련 설정을 미리 검토해야 합니다.
- 등록 해제 방지: 사용자가 등록 후 조직에서 임의로 탈퇴하지 않도록 Allow devices to leave organization 설정을 비활성화할 수 있습니다.
마치며
Cloudflare One Client는 디바이스 트래픽을 Cloudflare로 보내는 On-ramp이자, 디바이스 상태를 정책에 제공하는 센서입니다. 등록 권한은 Access 정책으로, 동작 방식은 Device Profile로, 터널 대상은 Split Tunnels로 제어하며, 수집한 Device Posture는 Access와 Gateway 정책에서 사용자 ID와 함께 접근 조건으로 활용됩니다.
다음 글에서는 사설 애플리케이션과 네트워크를 Cloudflare에 연결하는 Cloudflare Tunnel, Cloudflare Mesh, Cloudflare WAN의 차이와 적용 시나리오를 살펴봅니다.