Cloudflare One 소개와 전체 개념제품 소개부터 기능 열세 가지까지

예전 회사 보안은 정문 경비와 같았습니다. 정문(VPN)만 지나면 건물 안 어느 방이든 들어갈 수 있었습니다.

Cloudflare One 은 방마다 출입증을 봅니다. 들어갈 때마다 누구인지, 어떤 노트북인지, 어디로 가는지를 다시 확인합니다.

이 확인은 회사 안 장비가 아니라 전 세계 Cloudflare 데이터센터가 합니다. 그래서 집이나 카페에서 일해도 회사 안과 똑같이 보호받습니다.

이런 방식을 Zero Trust?라고 부릅니다. 보안과 연결을 한 서비스로 묶은 것을 SASE?라고 하며, Cloudflare One 은 Cloudflare 의 SASE 서비스입니다.

제품은 일곱 묶음입니다. 이름을 누르면 그 기능 절로 갑니다.

그림의 색은 늘 같은 뜻입니다. 청록은 Cloudflare, 보라는 회사 쪽 설비, 회색은 직원 단말과 인터넷, 빨강은 차단입니다.

직원 한 명의 하루로 따라가 봅니다. 3번부터 5번은 관리자가 그 정책을 켜 둔 경우입니다.

세션만 끊으면 회사 계정이 살아 있는 동안 다시 로그인할 수 있습니다. 퇴사나 분실이면 회사 계정(IdP)도 함께 끕니다.

관리자의 하루는 이렇습니다.

• 아침에 Insights 에서 어제 막힌 요청과 로그인 실패를 봅니다.
• 인터넷 정책(Gateway)을 바꾸면 다음 요청부터 바로 새 정책으로 판정합니다.
• 사내 앱 정책(Access)의 이메일, 그룹 조건은 직원의 다음 로그인부터 적용됩니다.
• «막혔어요»라는 문의는 로그에서 그 요청을 찾아 어느 정책에 걸렸는지 봅니다. «느려요»는 DEX 로 봅니다.
• 퇴사자는 회사 계정을 끄고 세션을 끊습니다. 직후 1분 정도는 다시 로그인해도 오류가 납니다.

가격과 요금제별 전체 비교는 Cloudflare 요금제 페이지에서 봅니다. 이 페이지는 가격을 적지 않습니다.

이 실습장이 우리 랩에서 해 보고 권하는 순서입니다. Cloudflare 가 정한 순서는 아닙니다.

• 늘 시험 그룹에서 먼저 확인하고, 로그에서 오탐이 없을 때 대상을 넓힙니다.
• 아래 기능 절도 이 순서로 놓았습니다.

프로그램이 켜져 있으면 사내 앱 접속과 인터넷 보호가 자동으로 걸립니다. 동시에 단말 상태를 보고해, 규칙을 못 지키는 단말을 중요한 앱에서 막을 수 있습니다.

1. 직원이 팀 이름을 넣고 회사 계정으로 로그인하면 단말이 조직에 등록됩니다.
2. 등록된 단말은 관리자가 정한 단말 프로필(동작 모드, 분할 터널?)을 받습니다.
3. DNS 질의는 DoH?로, 나머지 트래픽은 암호화 터널로 Cloudflare 에 갑니다.
4. Gateway 정책을 지난 트래픽만 인터넷과 사설망에 닿습니다.

• 지원: Windows, macOS, Linux, iOS, Android, ChromeOS
• 배포: 직접 설치하거나 단말 관리 제품(MDM?)으로 일괄 배포

OS 버전, 방화벽, 디스크 암호화처럼 단말의 상태를 정기적으로 확인합니다. 회사 보안 제품(EDR?, MDM?)의 판정을 API 로 받아 쓸 수도 있습니다.

1. One Client 가 기본 5분마다 단말을 검사해 결과를 보냅니다.
2. 보안 제품 연동은 관리자가 정한 주기로 Cloudflare 가 그 제품의 API 를 조회합니다.
3. Access 앱이나 Gateway 정책에 «이 검사를 통과한 단말만» 조건을 겁니다.

• 이럴 때 씁니다: 회사 관리 단말에서만 관리 화면 열기, 암호화 안 된 노트북의 업로드 막기

VPN 처럼 회사망 전체를 열지 않고, 앱마다 누가 어떤 단말로 들어올지 정합니다. 직원은 VPN 버튼 없이 평소처럼 앱 주소를 엽니다.

1. 브라우저가 앱 주소를 열면 요청이 먼저 Cloudflare 의 Access 에 닿습니다.
2. Access 는 국가, IP, 단말 상태처럼 신원이 아닌 조건을 먼저 보고, 맞으면 회사 IdP? 로그인 화면을 띄웁니다.
3. 로그인과 MFA?를 마치면 정책을 평가하고, 허용이면 서명된 증명서(JWT?)를 붙여 앱으로 넘깁니다.
4. 앱은 사내의 Tunnel? 커넥터 뒤에 있어 인터넷에서 직접 보이지 않습니다.

• 이럴 때 씁니다: 사내 웹 앱과 관리 화면, SSH 서버, 협력사에게 앱 하나만 열어 줄 때

1. 커넥터 cloudflared?가 7844 포트로 Cloudflare 에 바깥 방향 연결을 엽니다. 정상이면 커넥터마다 연결이 네 개입니다.
2. 직원이나 방문자의 요청은 Access 와 Gateway 정책을 먼저 지납니다.
3. 통과한 요청은 이미 열려 있는 연결을 거꾸로 타고 사내 서버에 닿습니다.

공개 이름(사내 웹 앱 주소)으로 내보내거나, 사설 IP 대역(SSH, DB)을 단말 사용자에게 연결합니다. 커넥터는 여러 대 두어 이중화합니다.

• Mesh: 단말끼리, 네트워크끼리 양방향 사설 연결

1. One Client 나 사무실 공유기가 DNS 질의를 Gateway 로 보냅니다(DoH, DoT, 리졸버 IP).
2. 도메인과 카테고리처럼 해석 전에 볼 수 있는 조건을 먼저 평가합니다.
3. 이름을 풀고 나서 응답 IP 와 그 국가 같은 해석 후 조건을 평가합니다.

기본 차단 페이지 문구는 «This site is blocked. Please contact your administrator for further assistance.» 입니다(실습장 랩 정책 화면에서 확인).

DNS 로 막아도 IP 주소를 직접 쓰면 열립니다. 꼭 막아야 할 곳은 네트워크나 HTTP 정책도 함께 둡니다.

1. 직원 앱이 연결을 열면 Gateway 가 목적지 서버에 먼저 연결해 봅니다.
2. 서버가 응답하면 네트워크 정책을 위에서부터 평가합니다.
3. HTTP 와 HTTPS 연결은 허용된 뒤 HTTP 정책 단계로 이어집니다.

사설망을 붙이면 기본값은 전체 허용입니다. 허용할 서버를 위에, 나머지 사설 대역 차단을 맨 아래에 둡니다.

1. 먼저 Do Not Inspect 정책을 봅니다. 맞으면 HTTPS 를 풀지 않고 그대로 보냅니다.
2. 나머지는 TLS 복호화?로 풀어 Isolate 정책을 봅니다.
3. 그다음 Allow, Block, Redirect 같은 정책을 위에서부터 봅니다.
4. 허용된 요청은 본문을 검사합니다(DLP?, 백신, 샌드박스).

Gateway HTTP 정책의 동작을 Isolate 로 두면 걸린 페이지만 격리됩니다. 새로 생긴 도메인이나 보안 위험 분류처럼 위험한 곳만 고르는 방식이 보통입니다.

단말 프로그램 없이 쓰려면 팀 도메인의 /browser/ 주소 뒤에 열 주소를 붙입니다(클라이언트 없는 격리).

격리된 사이트에는 평소 브라우저의 쿠키와 로그인이 넘어가지 않습니다. 그 사이트가 쓰는 로그인 사이트도 함께 격리합니다.

1. TLS 복호화로 HTTPS 요청의 본문을 엽니다.
2. DLP 프로필(탐지 항목 묶음)로 본문을 검사합니다.
3. HTTP 정책의 «DLP Profile» 조건이 그 결과를 보고 동작을 정합니다.
4. 같은 프로필로 SaaS 에 이미 저장된 파일도 CASB?가 검사합니다.

• 이럴 때 씁니다: 개인 웹하드와 메일로 개인정보 올리기 막기, AI 서비스에 민감정보 입력 막기

예를 들어 누구나 볼 수 있게 공유된 파일이나 2단계 인증이 꺼진 관리자를 찾아 심각도와 함께 보여 줍니다. 스캔은 앱마다 다르며 보통 1시간에서 24시간마다 돕니다.

연동 권한은 기본이 읽기 전용입니다. Read-Write 모드로 연동하면 지원하는 항목은 화면에서 바로 고칠 수 있습니다.

직원이 몰래 쓰는 앱(Shadow IT)은 CASB 가 아니라 Gateway 로그로 파악합니다.

배달 전 방식은 메일 길목(MX?)을 Cloudflare 로 돌립니다. 배달 뒤 방식은 Microsoft 365 와 Google 에 API 나 BCC 로 붙어, 이미 온 메일을 옮기거나 지웁니다.

메일마다 판정(처분?)이 하나 붙습니다. 위험한 순서로 Malicious, Spam, Bulk, Suspicious, Spoof 입니다.

직원이 «느려요»라고 하면 단말, 네트워크, Cloudflare, 앱 가운데 어디가 원인인지 좁힙니다. 시험은 One Client 가 켜져 있을 때만 돌고, 단말 상태 정보는 늘 모입니다.

MPLS 전용선이나 본사를 거쳐 돌아가는 구조 대신, 가까운 Cloudflare 데이터센터에서 경로와 보안을 처리합니다. 엔터프라이즈 플랜 기능입니다.

1. 거점 라우터가 IPsec? 이나 GRE? 터널로 Cloudflare 에 붙습니다.
2. 패킷은 먼저 Cloudflare Network Firewall(L3, L4 필터)을 지납니다.
3. 다른 거점으로 가는 트래픽은 WAN 경로로, 인터넷행은 Gateway 정책을 거쳐 나갑니다.

단말 프로그램 없이 들어온 WAN 트래픽에는 사람 신원이 없습니다. 정책은 출발 IP 대역이나 단말 검사 결과로 나눕니다.

«왜 막혔나요?»라는 질문에 로그 한 줄로 답할 수 있습니다. 기능마다 남는 로그는 위 표의 «관리자 로그» 칸에 적었습니다.

단말을 등록하고 사설망 경로를 붙이면 기본값은 그 사설망 전체 허용입니다. 공식 문서도 같은 내용을 적고 있습니다.

허용할 곳만 여는 Gateway 네트워크 정책과, 나머지 사설 대역을 막는 정책을 함께 만들어야 VPN 보다 좁아집니다.

Cloudflare One 대시보드 ↗

1. Cloudflare 계정을 만들고 2단계 인증을 켭니다.
2. 대시보드에서 Zero Trust 를 고르고 팀 이름을 정합니다. 팀 이름은 단말을 손으로 등록할 때 넣는 값이고 App Launcher 주소가 됩니다.
3. 요금제를 고릅니다. Free 도 결제 정보 단계를 거치지만 청구되지 않습니다.
4. 기본 로그인 수단으로 Cloudflare 계정 IdP 가 자동으로 붙습니다. 회사 IdP 를 따로 연결합니다.

요금제는 Zero Trust Free, Pay-as-you-go, Enterprise 입니다. 기능별 차이는 각 절에 적었고 가격은 요금제 페이지에서 봅니다.

격리와 DLP 는 TLS 복호화와 단말 인증서가 있어야 HTTPS 에서 동작합니다. 피싱 차단은 DNS 정책만으로도 됩니다.

1. 0일차: Integrations › Identity providers 에서 회사 IdP 를 붙입니다. 팀 App Launcher 를 열어 회사 계정으로 로그인되면 끝입니다.
2. 1주차: Team & Resources › Devices 에서 등록 권한과 단말 프로필을 정하고 시험 그룹에 One Client 를 깝니다. 클라이언트가 Connected 이고 단말 목록에 보이면 다음으로 갑니다.
3. 1주차: Firewall policies › DNS 에 차단 정책 하나를 만듭니다. 시험 단말에서 그 사이트가 막히고 DNS 로그에 Block 이 남으면 끝입니다.
4. 2주차: Networking › Tunnels 로 사내망을 붙이고, 허용 정책을 위에, 나머지 사설 대역 차단을 맨 아래에 둡니다. 허용 계정과 비허용 계정으로 각각 열어 로그와 맞으면 다음으로 갑니다.
5. 3~4주차: 인증서를 배포하고 Traffic settings 에서 TLS 복호화를 켭니다. 먼저 Do Not Inspect 예외를 두고, 인증서 경고 없이 열리는지 본 뒤 HTTP 정책을 더합니다.
6. 그다음: 격리, DLP, CASB, 이메일 보안을 필요한 순서대로 더합니다. 시험 업로드가 막히고 로그에 DLP 항목이 남는지 봅니다.

실제 화면은 예제 1(DNS 차단), 예제 2(소속별 서버), 예제 3(로그인), 예제 4(단말) 에 있습니다.

실습장 GH 랩(Zero Trust 실습 계정)의 Windows 단말에서 협력사 A 시험 계정으로 2026-10-16 에 직접 해 본 화면입니다. 계정 이름, ID, 시험 계정 메일, 공인 IP 는 가렸습니다.

1. 정책: Firewall policies › DNS 에서 Domain in 메신저 도메인, User Email in list 소속 목록, 동작 Block 입니다. 차단 페이지를 켜고 사유 문구를 적었습니다.

1. 직원 화면(http 주소): Cloudflare 기본 차단 페이지에 정책 사유가 그대로 나옵니다.

1. 직원 화면(https 주소, 인증서 없음): 차단 페이지 대신 브라우저 경고가 뜹니다. 단말에 Cloudflare 루트 인증서를 깔아야 차단 페이지가 보입니다.

1. 관리자 로그: Insights & Logs › Logs › DNS 에서 Block 으로 거르면 그 질의와 걸린 정책 이름이 나옵니다.

• 같은 원리의 설정 방법: DNS 정책 설정

실습장 GH 랩(Zero Trust 실습 계정)의 Windows 단말에서 협력사 A 시험 계정으로 2026-10-16 에 직접 해 본 화면입니다. 계정 이름, ID, 시험 계정 메일, 공인 IP 는 가렸습니다.

1. 정책: 서버마다 «목적지 IP 리스트 + 허용 소속 이메일 리스트» 허용 정책을 위에 두고, 맨 아래에 나머지를 막는 정책을 둡니다. 막을 때는 차단 페이지 대신 랩 안내판 주소로 보내도록 했습니다.

1. 직원 화면(허용): 협력사 A 는 운영 업무시스템에 허용된 소속이라 바로 열립니다.

1. 직원 화면(차단): 정산 ERP 는 허용 소속이 아니라 맨 끝 차단 정책에 걸려 안내판으로 넘어갑니다.

1. 관리자 로그: Insights & Logs › Logs › HTTP 에서 같은 요청이 block 으로 남습니다.

• 이 랩의 전체 구성과 소속별 권한 표는 소속별 접근 통제 랩 에 있습니다. 설정 방법은 네트워크 정책과 HTTP 정책 절입니다.

1. 정책: Access 앱에 Allow 정책(Include 이메일이나 그룹)을 붙입니다.

1. 직원 화면: 팀 App Launcher 를 열면 로그인 전 화면이 뜹니다(GH 랩 Windows, 2026-10-16).

1. 직원 화면: 사설 IP 앱을 열었을 때의 로그인 화면입니다. 회사 IdP 단추와 이메일 코드 로그인이 함께 보입니다.

1. 관리자 로그: Insights & Logs › Logs › Access 에 로그인 시도마다 허용과 차단이 한 줄씩 남습니다.

• 설정 방법: Access 설정

관리자는 Team & Resources › Devices 에서 그 단말과 받은 프로필을 봅니다.

• 설정 방법: One Client 설정

Zero Trust › Integrations › Identity providers

내 계정에서 열기 ↗

IdP 에 MFA 가 없으면 앱마다 Cloudflare 자체 MFA 를 켭니다. 방식은 인증 앱, 생체 인증, 보안 키 가운데 고릅니다.

Zero Trust › Access controls › Applications › 앱 › Authentication › MFA

Zero Trust › Team & Resources › Devices › Device profiles

내 계정에서 열기 ↗

1. 단말 등록 권한에 등록할 수 있는 사람(이메일, 그룹)을 넣습니다.
2. 프로필을 만들고 적용 대상을 정합니다. 위에서부터 처음 맞는 프로필이 적용됩니다.
3. 동작 모드와 분할 터널?을 고릅니다.
4. HTTPS 검사를 쓸 거면 Cloudflare 인증서를 단말에 자동 설치하게 합니다.

Zero Trust › Reusable components › Posture checks

내 계정에서 열기 ↗

1. 검사를 만듭니다. One Client 검사이거나 보안 제품 연동입니다.
2. Team & Resources › Devices 에서 단말을 열고 Posture checks 탭에서 통과와 실패를 확인합니다.
3. Access 정책의 Require 나 Gateway 정책의 Device Posture 조건에 넣습니다.

• 기본 검사: OS 버전, 방화벽, 디스크 암호화
• Windows 백신, 회사 단말 일련번호, 클라이언트 인증서
• 단말 보안 제품 연동: CrowdStrike, Intune, SentinelOne 등

단말 검사는 트래픽이 One Client 를 지나야 동작합니다. IdP, 팀 도메인, 보호하는 앱을 분할 터널에서 빼면 검사가 실패합니다.

Zero Trust › Access controls › Applications › Add an application

내 계정에서 열기 ↗

1. 앱 종류를 고릅니다. 사내 웹 앱은 Self-hosted, 사설 IP 앱은 Private network 입니다.
2. 앱 주소(공개 이름이나 사설 IP)와 로그인 수단을 정합니다.
3. 정책을 붙입니다. 맞는 정책이 없으면 기본은 거부입니다.
4. 세션 시간을 정합니다. 앱 세션 기본값은 24시간입니다.
5. 공개 이름 앱이면 Tunnel 경로를 연결하고, 허용 계정과 비허용 계정으로 각각 열어 봅니다.

Zero Trust › Access controls › Policies

내 계정에서 열기 ↗

규칙은 세 종류입니다. Include 는 하나라도 맞으면, Require 는 모두 맞아야, Exclude 는 맞으면 뺍니다.

Bypass 는 누가 들어왔는지 남지 않습니다. 사내 앱에는 쓰지 않습니다.

퇴사자는 IdP 에서 계정을 끄고 사용자 화면에서 세션 회수?를 누릅니다. 회수 직후 1분 정도는 다시 로그인해도 오류가 납니다.

Zero Trust › Team & Resources › Users › 사용자

내 계정에서 열기 ↗

Networking › Tunnels

내 계정에서 열기 ↗

1. 터널을 만들고, 화면이 주는 설치 명령으로 사내 서버에 cloudflared 를 띄웁니다.
2. 공개 이름 앱이면 이름과 서비스 주소를, 사설망이면 CIDR 경로를 넣습니다.
3. 공개 이름 앱은 Access 앱과 정책을 먼저 만든 뒤 경로를 엽니다.
4. 같은 터널에 커넥터를 두 대 이상 띄워 이중화합니다.

• 커넥터는 Cloudflare 쪽으로 7844 포트(TCP 와 UDP)만 씁니다.
• 양방향 연결은 Mesh(Beta) ↗, 경로는 Routes ↗ 에서 봅니다.

Zero Trust › Traffic controls › Firewall policies › DNS

내 계정에서 열기 ↗

1. Add a policy 를 누릅니다.
2. 조건을 고릅니다. Domain, Content Categories, Security Categories, Application 이 자주 쓰입니다.
3. 동작을 고릅니다.
4. Block 이면 «Modify Gateway block behavior»로 차단 페이지를 켜고, 필요하면 One Client 알림도 켭니다.
5. 예외는 위에, 넓은 차단은 아래에 둡니다.

• 사무실 기기는 Resolvers & Proxies ↗ 에서 DNS 위치를 만들어 리졸버 주소를 받습니다.
• 사내 도메인을 사내 DNS 로 보내는 것은 Resolver policies ↗ 입니다.
• 차단 페이지 문구와 로고는 Custom pages ↗ 에서 바꿉니다.

Zero Trust › Traffic controls › Firewall policies › Network

내 계정에서 열기 ↗

1. 서버별 허용 정책을 만듭니다. 목적지 IP, 포트, 사람이나 그룹 조건을 함께 겁니다.
2. 맨 아래에 나머지 사설 대역 차단 정책을 둡니다.
3. 허용된 계정과 허용되지 않은 계정으로 각각 접속해 대조합니다.

net.dst.ip in {192.0.2.0/24} and net.dst.port == 443

Network Override 의 대상 IP 가 닿지 않으면 연결이 조용히 실패하고 로그도 남지 않습니다. 대상이 살아 있는지 먼저 봅니다.

Zero Trust › Traffic controls › Firewall policies › HTTP

내 계정에서 열기 ↗

1. Traffic settings ↗ 에서 프록시와 TLS 복호화?를 켭니다.
2. 단말에 Cloudflare 루트 인증서를 배포합니다. One Client 가 자동으로 설치하게 할 수 있습니다.
3. 인증서를 고정해 쓰는 앱을 Do Not Inspect? 정책으로 먼저 뺍니다.
4. Allow, Block, Isolate 정책을 씁니다.

Allow 정책의 «Untrusted certificate action»은 목적지 인증서가 잘못됐을 때 직원 화면을 정합니다. Error(Gateway 오류 화면), Block(차단 페이지), Pass through(경고 없이 연결) 가운데 고릅니다.

Zero Trust › Browser isolation › Browser isolation settings

내 계정에서 열기 ↗

1. HTTP 정책을 만들고 동작을 Isolate 로 고릅니다.
2. 오른쪽 격리 설정에서 복사, 붙여넣기, 키보드, 인쇄, 다운로드, 업로드를 정합니다.
3. 그 사이트가 쓰는 로그인 사이트도 같은 정책에 넣어 함께 격리합니다.
4. 단말 프로그램이 없는 사람에게는 클라이언트 없는 격리를 켜고 Access 정책으로 쓸 사람을 정합니다.

다운로드 «Do not allow»는 원격 브라우저 안으로 받는 것까지 막지 않습니다. 받는 것 자체를 막으려면 Download Mime Type 조건의 HTTP Block 정책을 둡니다.

Zero Trust › Data loss prevention › Profiles

내 계정에서 열기 ↗

1. Gateway 프록시와 TLS 복호화를 켭니다.
2. 기본 제공 프로필을 열어 쓸 탐지 항목을 켭니다.
3. Test scan 으로 샘플 내용이 걸리는지 봅니다.
4. HTTP 정책을 만듭니다. 예: DLP Profile in 프로필, HTTP Method in POST, 동작 Block.
5. 시험 사이트에서 올려 보고 Insights › Logs › HTTP request logs 의 DLP Profiles 필터로 확인합니다.

사이트마다 업로드를 보내는 방식이 다릅니다. 시험 사이트에서 막혀도 다른 사이트에서 같다고 보장할 수 없으니 실제 쓰는 서비스로도 시험합니다.

Zero Trust › Cloud & SaaS findings › Posture Findings

내 계정에서 열기 ↗

1. Integrations ↗ 에서 앱을 고르고 화면 안내대로 권한을 승인합니다.
2. Save integration 으로 첫 스캔을 돌립니다.
3. 발견 항목의 Manage 에서 영향받은 자산(인스턴스)을 봅니다.
4. 심각도를 바꾸거나 숨기고, 웹훅으로 외부 시스템에 보냅니다.
5. 바로 고치려면 연동을 Read-Write 모드로 바꾸고, 지원하는 항목의 조치를 고릅니다.

직원 화면에는 아무것도 뜨지 않습니다. 관리자 조치로 SaaS 공유 설정이 바뀌면 그때 직원이 변화를 봅니다.

Zero Trust › Email security › Overview

내 계정에서 열기 ↗

1. 방식을 고르고 메일 서비스 쪽 설정(MX 레코드, API 승인, BCC 규칙)을 합니다.
2. 판정별 자동 이동(어느 폴더로 옮기거나 지울지)을 정합니다.
3. 사칭 대상이 될 임원 이름을 사칭 등록부에 넣습니다.
4. 직원과 보안팀 신고를 보고 잘못된 판정을 다시 분류합니다.

Zero Trust › Insights › Digital experience

1. HTTP 시험 또는 traceroute 시험을 만들고 대상 주소와 주기를 넣습니다.
2. DEX 규칙으로 시험을 돌릴 사람과 그룹을 정합니다.
3. 결과 화면에서 단말별 응답 시간과 가용성을 봅니다.
4. 품질이 떨어질 때 받을 알림을 만듭니다.
5. 특정 단말의 문제는 진단에서 속도 시험이나 원격 캡처로 봅니다.

직원 화면에는 아무것도 뜨지 않습니다. 시험은 One Client 가 켜져 있을 때만 돌기 때문에, 꺼 둔 단말은 결과가 비어 보입니다.

1. 거점 라우터가 IPsec 이나 GRE 와 문서의 IPsec 설정값을 지원하는지 확인합니다.
2. Cloudflare 와 라우터 양쪽에 터널을 만듭니다. Cloudflare One Appliance 를 쓰면 자동으로 붙습니다.
3. 경로를 넣습니다. 정적 경로 또는 BGP 입니다.
4. MSS 를 줄입니다. GRE 는 1,436 바이트, IPsec 은 1,360 바이트 이하입니다.
5. 인터넷행 HTTPS 를 검사하려면 거점 단말에 Cloudflare 인증서를 깔거나 Do Not Inspect 로 뺍니다.

경로는 Routes ↗ 에서 봅니다.

Zero Trust › Insights & Logs › Logs

로그 열기 ↗ 분석 화면 열기 ↗

• Access 인증 로그: 로그인 시도마다 허용과 차단
• Gateway 로그: DNS, 네트워크, HTTP 로 나뉨
• 관리자 활동, 단말 상태, 터널 변경 기록도 따로 있습니다.

• 이메일, 도메인, IP 목록: Lists ↗
• 차단 페이지, 로그인 화면: Custom pages ↗
• 단말 보안 제품: Service providers ↗
• CASB 연동: Cloud & SaaS ↗
• 앱 정보: Application library ↗
• 기계용 인증: Service credentials ↗
• MCP? 서버 묶음: MCP Portals ↗

협력사 이메일은 목록 하나로 두고 정책은 목록 이름만 부르면, 인력이 바뀌어도 목록 한 곳만 고칩니다.

2026년 10월 실습장 랩 계정에서 확인했습니다. 터널 관리가 계정 메뉴의 Networking 으로 옮겨졌습니다.

옛 문서나 캡처의 경로를 따라가다 막히면 Networking › Tunnels 로 갑니다.

• 검사와 저장 지역은 Data Localization Suite 로 정합니다.
• 네트워크 쪽에는 Network Firewall, One Appliance, Multi-Cloud Networking 이 같은 플랫폼으로 붙습니다.
• 전체 설계는 SASE 참조 아키텍처를 기준으로 잡습니다.
• 설정을 코드로 관리하는 방법은 설정을 코드로 절에 있습니다.

직원의 하루 장면으로 보면 이렇습니다.

권한을 빼도 열려 있는 Access 세션은 만료까지 유지됩니다. 즉시 차단은 세션 회수입니다.

• Local proxy 모드는 MASQUE 터널에서만 됩니다. 기본 포트는 40000 이고, 요청이 10초를 넘으면 끊깁니다.
• Traffic only 모드는 도메인 기반 분할 터널처럼 DNS 에 기대는 기능이 꺼집니다. Windows, macOS, Linux 만 됩니다.
• MDM 으로 배포한 설정 파일은 대시보드의 단말 프로필보다 우선합니다.
• 차단 알림은 1분에 한 번까지이고 문구는 100자 이하입니다. 방해 금지나 화면 공유 중에는 안 뜰 수 있습니다.

• 주기는 API 의 schedule(One Client 검사)과 interval(보안 제품 연동)로 바꿉니다.
• 예: 주기를 10분으로 두면 Gateway 정책에는 최대 15분 늦게 반영됩니다.
• Gateway 는 연결을 시작할 때만 단말 조건을 봅니다. SSH 처럼 열린 세션은 검사가 실패해도 유지됩니다.
• 결과는 새 값으로 덮어쓸 때까지 유효합니다. API 로 만료 시간을 줄 수 있습니다.
• Access 연동 전용 검사는 Gateway 정책에 쓸 수 없습니다.
• 백신 검사는 Windows 만, 디스크 암호화는 데스크톱 OS 만 지원합니다. 모바일은 OS 버전 위주로 봅니다.

차단 시험은 늘 새 연결로 합니다.

• 로그인하면 토큰이 두 개 생깁니다. 팀 도메인의 전역 토큰(기본 24시간, 15분에서 1달)과 앱 토큰(앱이나 정책 세션)입니다.
• 세션 길이는 One Client 세션, 정책 세션, 앱 세션, 전역 세션 순으로 앞의 것이 이깁니다.
• 앱 토큰이 끝나면 전역 토큰이 살아 있는 동안 정책을 다시 보고 새 토큰을 줍니다. 전역 토큰도 끝났으면 IdP 로 다시 보냅니다.
• 즉시 차단은 앱별 «Revoke existing tokens» 또는 사용자별 Revoke 입니다. 로그아웃 주소 /cdn-cgi/access/logout 을 쓰면 20~30초 안에 옛 토큰이 거부됩니다.
• 단일 페이지 앱은 요청에 X-Requested-With: XMLHttpRequest 헤더를 붙이면 세션 만료 때 401 을 받습니다.
• 서비스 토큰은 CF-Access-Client-Id 와 CF-Access-Client-Secret 헤더로 보냅니다.
• SaaS 앱은 처음 로그인과 SaaS 세션 재발급 때만 Access 가 봅니다. 그 뒤 세션은 SaaS 몫입니다.

앱 서버가 공인 IP 로도 열려 있으면 Cloudflare 를 거치지 않고 들어올 수 있습니다. Tunnel 뒤에 두거나 앱에서 JWT 를 검증합니다.

• 방화벽은 7844 포트를 TCP(http2)와 UDP(quic) 모두 열어 둡니다.
• 한 서버에 서비스로 띄울 수 있는 cloudflared 는 하나입니다. 경로를 더할 때는 기존 터널에 넣습니다.
• 터널로 들어온 요청에는 Authenticated Origin Pulls 가 적용되지 않습니다. 커넥터 자격증명이 이미 출처를 증명합니다.

위 두 정책이면 example.com 은 막힙니다. Domain 은 해석 전 조건이라 순서가 위인 Allow 보다 먼저 평가됩니다.

• 한 정책에 해석 전과 해석 후 조건이 섞이면 정책 전체를 해석 후에 봅니다.
• Resolver policy(Enterprise)는 해석 전 정책과 해석 후 정책 사이에 끼어 어느 DNS 로 보낼지 정합니다.
• 차단 응답은 A 0.0.0.0, AAAA ::, 그 밖의 레코드는 REFUSED 입니다.
• Override 는 해석 후 조건과 함께 못 쓰고, A, AAAA, HTTPS 외 질의에는 REFUSED 를 줍니다.
• 다른 VPN, iCloud Private Relay, Chrome IP Protection 은 Gateway DNS 를 우회할 수 있어 끄도록 안내합니다.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" --request POST
  --json '{"name":"예시","action":"block","filters":["dns"],"traffic":"any(dns.domains[*] == \"example.com\")","enabled":true}'

• 목적지가 응답하지 않으면 정책을 평가하지 않습니다. 그 연결은 Gateway 활동 로그에 없고 네트워크 세션 로그에만 남습니다.
• 네트워크 Block 과 HTTP Block 이 함께 맞으면 차단 페이지 없이 막히고, 알림은 네트워크 정책 설정을 따릅니다.
• 맞는 정책이 없으면 허용입니다. 기본 차단으로 바꾸려면 맨 아래에 전체 차단을 두고 그 위에 허용을 둡니다.
• 사설 IP 가 Access 앱으로 보호돼 있으면 Gateway Allow 를 지나도 Access 정책을 다시 봅니다. Gateway Block 은 그 자리에서 끝냅니다.

net.dst.ip in {192.0.2.0/24} and net.dst.port == 443

1. Do Not Inspect 정책 전부(위에서부터). SNI?로 맞히고, 맞으면 나머지 HTTP 정책을 모두 건너뜁니다.
2. Isolate 정책 전부
3. Allow, Block, Do Not Scan, Quarantine, Redirect 정책(위에서 처음 맞는 것)
4. Forward 정책(베타). 처음 맞는 Worker 를 부릅니다.
5. 본문 검사: DLP, 백신, 파일 샌드박스
6. 응답 검사

• 격리와 차단은 함께 적용됩니다. example.com 을 격리하고 하위 경로를 막으면 원격 브라우저 안에서 그 경로가 막힙니다.
• TLS 복호화가 없으면 URL 경로, 파일 형식, DLP, 업로드 통제가 동작하지 않고 HTTP 정책은 도메인 수준만 봅니다.
• 차단 페이지는 단말 인증서가 없으면 526 오류가 뜨거나 연결이 닫힙니다.

HTTP 정책의 목적지 IP 는 배열 필드라 그냥 in 을 쓰면 파싱 오류가 납니다(실습장 랩 계정에서 확인).

any(http.conn.dst_ip[*] in {192.0.2.10})

• 평소 브라우저의 쿠키와 세션은 원격 브라우저로 넘어가지 않습니다. 제3자 쿠키로 로그인하는 사이트는 로그인 사이트도 격리합니다.
• 다운로드와 업로드 차단 설정은 원격 브라우저 안의 다른 경로(클라우드 파일 관리자, 다른 격리 탭의 다운로드)까지 막지 않습니다. MIME 형식 조건의 HTTP Block 을 더합니다.
• 키보드를 막아도 마우스 입력과 사이트 안의 가상 키보드는 됩니다.
• 클라이언트 없는 격리 안의 사이트는 Do Not Inspect 에 맞아도 격리됩니다.
• 동작이 막힐 때 띄울 맞춤 안내(custom block dialog)는 베타이며 계정 팀을 통해 켭니다.

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" --request POST
  --json '{"name":"보안 위험 격리","action":"isolate","filters":["http"],"traffic":"any(http.request.uri.security_category[*] in {68 80})","enabled":true}'

• Forward(베타)를 쓰면 원래 본문을 검사한 뒤 Worker 에 넘깁니다. Worker 가 바꾼 요청 본문은 다시 검사하지 않습니다.
• Personally Identifiable Information(PII) Record 프로필은 서로 다른 탐지 항목 세 개가 가까이 있어야 맞습니다.
• 걸린 내용은 기본으로 로그에 남지 않습니다. «Log the payload of matched rule»을 켜면 암호화해 남깁니다.
• Test scan 에서는 맞는데 트래픽에서 안 맞으면 정책, 트래픽 경로, TLS 복호화 가운데 하나가 원인입니다.
• 오탐은 로그의 DLP details 에서 «Report DLP false positive»로 보냅니다.
• AI 프롬프트만 검사하려면 Gateway 대신 AI Gateway 의 DLP 를 쓸 수도 있습니다.

• Content Findings 는 자산 하나가 한 줄이고, 맞은 DLP 프로필이 묶입니다.
• 심각도를 바꾸면 그 연동에만 적용됩니다. 같은 앱의 다른 연동은 그대로입니다.
• Microsoft Purview 민감도 레이블을 DLP 프로필로 쓰는 연동 프로필은 CASB 가 있어야 합니다.
• 발견 인스턴스는 웹훅으로 외부 시스템에 보낼 수 있습니다.

• Spam 판정은 머리에 UCE 로 붙습니다.
• 배달 뒤 방식은 위협을 받은편지함에 들어온 뒤에 지웁니다. 직원이 그 사이에 열 수 있다는 뜻입니다.
• BCC, 저널링 방식에서 자동 이동을 쓰려면 API 연동도 함께 붙여야 합니다.
• 배달 전(MX) 방식은 메일을 막거나 격리하거나 고쳐서 넘길 수 있습니다.
• 계약 전에는 Retro Scan 으로 지난 메일을 점검합니다.

• 시험은 One Client 가 켜져 있을 때만 돕니다. 주기는 5분에서 60분입니다.
• 시험 대상 사람과 그룹은 DEX 규칙으로 정합니다.
• Logpush 데이터셋 이름은 dex_application_tests 입니다.
• EU 메타데이터 경계(Customer Metadata Boundary)를 켜면 DEX 로그는 EU 에만 저장됩니다.
• AI 도구에서 묻고 답하려면 DEX MCP 서버를 씁니다.

• 평가 순서: Network Firewall, Egress 정책, 목적지 연결 확인, 네트워크 정책, HTTP 정책
• Gateway 네트워크와 HTTP 의 Block 은 첫 TCP SYN 이 목적지에 가는 것까지 막지 못합니다. SYN 자체를 막으려면 Network Firewall 규칙을 씁니다.
• 단말 프로그램을 같이 쓰는 거점이면 One Client 검사로, 아니면 거점의 사설 대역으로 정책을 나눕니다.
• 경로를 자동으로 주고받으려면 BGP, 환경을 나누려면 가상 네트워크를 씁니다.

• Access 인증 로그는 로그인 시도 단위입니다. 세션 안의 행동은 담지 않습니다.
• Gateway 로그는 DNS, 네트워크, HTTP 로 나뉩니다.
• 분석 데이터는 GraphQL API 로도 꺼낼 수 있습니다.

코드로 관리하는 설정을 대시보드에서 손으로 바꾸면 다음 적용 때 되돌려집니다. 한쪽으로 정합니다.

정책과 목록 개수에는 계정 한도가 있습니다. 큰 구성 전에 확인합니다.

Terraform 공급자 4 버전은 정책 순서 값에 해시를 더해(1000 이 1000901 이 되는 식) 순서 바꾸기가 꼬입니다. 5 버전으로 올립니다.

Access 는 세션이 끝나야 바뀐 정책을 봅니다. 급하면 Revoke sessions 를 함께 누릅니다.

단말 상태는 보고 주기가 있습니다. 이미 열린 연결도 그대로 남으므로 시험은 새 연결로 합니다.