CloudflareMegazone

Cloudflare 기능 실습장

엔진 확인 중…

Cloudflare 기능 실습장

설정 화면을 구경하는 곳이 아니라 직접 걸고, 직접 쏘고, 막히는 것을 보는 곳입니다. 여기서 만드는 룰과 요청은 전부 진짜 Cloudflare 를 지나갑니다 — 흉내가 아닙니다. 로그인은 필요 없고, 무엇을 눌러도 다른 사람 서비스에는 영향이 없습니다.

1 아래에서 궁금한 기능을 고릅니다 2 설명을 읽고 값을 바꿔 봅니다 3 실제로 쏘고 결과·로그를 봅니다
M운영 매뉴얼 켜고 나서 실제로 부딪히는 것 — WAF · 봇 · 보안 설정 · 로그 주제마다 초급 · 중급 · 전문가 3단계, 근거는 공식 문서와 이 실습장의 실측입니다. 설치Cloudflare One Client 처음 설치 설치부터 회사 로그인, 연결 확인까지 Windows · macOS · Linux 별 설치 파일과 단계별 화면 안내를 별도 페이지에서 봅니다. 설치cloudflared 설치 · 터널 연결 서버에 Tunnel 커넥터를 설치하고 연결합니다 Windows · macOS · Linux 별 설치 → 웹 로그인 → 토큰 명령 실행 → 연결 확인까지 따라 합니다.

정말 진짜인가요? 네. 룰은 Cloudflare 존에 실제로 올라가고, 요청은 존 밖에서 엣지로 쏩니다. 결과에 붙는 Ray ID 로 Cloudflare 로그에서 그 요청을 그대로 찾을 수 있습니다. 다만 여기서 만드는 룰은 호스트 하나(lab.mzc.cflare.kr)에만 걸리도록 서버가 강제로 감쌉니다 — 무엇을 쓰셔도 다른 서비스에는 닿지 않고, 30분 뒤 자동으로 정리됩니다. 만든 곳: 메가존클라우드 Cloudflare 팀.

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

새 커스텀 룰 편집 화면. Rule name, When incoming requests match 의 Field·Operator·Value, Expression Preview, Then take action
도메인 › Security › Security rules › Create rule › Custom rules새 커스텀 룰 화면. 필드·연산자·값으로 조건을 만들면 아래 Expression Preview 에 식이 그대로 보입니다.
Choose action 목록이 펼쳐진 화면. Managed Challenge, Log, Block, Non-Interactive Challenge, Skip, Interactive Challenge
같은 화면 › Then take action › Choose action고를 수 있는 동작 목록입니다. 처음에는 Log 로 지켜본 뒤 Block 이나 챌린지로 바꿉니다.

① 룰을 씁니다

② 시험 결과 요청 여러 개를 이 룰에 통과시킵니다

왼쪽에 룰을 쓰고 시험 발사를 누르면, 어떤 요청이 막히고 어떤 요청이
지나가는지 여기 나옵니다. 막히면 안 되는 요청도 함께 쏩니다 — 과탐지가 진짜 사고입니다.

③ 실제로 쏴 봅니다 이 룰이 걸린 진짜 주소입니다 — curl 로 쏴도 같습니다

룰을 시험 발사하면 여기에 주소가 나옵니다.

④ 진짜 Cloudflare 를 통과시킵니다 AWS EC2 오리진까지 — 관리형 룰셋·봇 관리가 실제로 평가됩니다

위 ③의 경로를 같은 EC2 오리진을 보는 호스트 세 곳에 쏩니다 — 한쪽은 WAF 룰이 걸려 있고 한쪽은 없습니다. 두 응답의 차이가 곧 Cloudflare 가 한 일이고, 진짜 Ray ID 가 남습니다.
사례 실제 문의에서 나온 것 6건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Web assets 의 Operations 탭. 위험(zombie) 표시, 라벨, 호스트별 엔드포인트 표와 Sequences, Schema validation 탭
도메인 › Security › Web assets › OperationsCloudflare 가 찾아 저장한 API 엔드포인트 목록입니다. 위쪽 탭에서 Sequences, Schema validation 으로 넘어갑니다.

API Shield — 규격을 어긴 요청만 골라 막습니다

WAF 룰이 「이런 모양이면 나쁘다」를 적는 것이라면, API Shield 의 스키마 검증은 「이 API 는 이렇게 생겼다」를 적어 두고 거기서 벗어난 것을 전부 막습니다. 공격 패턴을 하나씩 쫓지 않아도 되는 것이 차이입니다.

지금 걸려 있는 것 규격 하나에 엔드포인트 두 벌이 걸려 있고, 조치 단계만 다릅니다. 규격이 같으니 결과가 갈리면 그 원인은 조치 하나뿐입니다.
표적조치규격을 어기면
/apishield/orders/{orderId}none 아무 일도 없습니다 — 그냥 지나갑니다
/apishield/strict/orders/{orderId}block 403 으로 막히고 오리진에 닿지 않습니다

규격이 정한 것 — orderId 는 정수이고 1~999999, currency 는 KRW·USD 만. 어느 회사의 것도 아닌 일반적인 주문 조회 모양입니다.

🔵 판정은 저희가 하지 않습니다. 이 화면은 두 표적에 같은 요청을 쏘고 돌아온 상태 코드와 Ray ID 를 그대로 옮길 뿐이고, 403 을 만든 것은 진짜 Cloudflare API Shield 입니다. 404 는 통과라는 뜻입니다 — 표적 경로에 실제 파일이 없어 오리진이 그렇게 답합니다. Cloudflare 가 막았다면 오리진까지 가지도 못합니다.

여기서 못 해 보는 것 — 그리고 그 이유

API Shield 는 엔타이틀먼트가 존 단위입니다. 이 실습 존에서 되는 것과 안 되는 것이 갈립니다 (2026-09-16 저희 존 네 곳을 조회해 확인했습니다).

기능이 실습장
엔드포인트 관리 · 스키마 검증됩니다 지금 보고 계신 것이 그것입니다
세션 식별자 · API 디스커버리안 됩니다 구성(configuration) 조회가 10403 입니다
BOLA · 볼류메트릭 남용 탐지안 됩니다 세션 식별자에 기대는 기능이라 같이 막힙니다
Sequence 분석 · 완화안 됩니다 공개 API 에 경로 자체가 없습니다 — 대시보드 베타로만 열립니다

「무엇이 왜 안 되는가」까지가 검토 결과입니다. 고객 존에서 되는지는 그 존에서 /api_gateway/configuration 을 조회해 10403 이 오는지로 판별합니다.

사례 실제 문의에서 나온 것 5건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Turnstile Add Widget 화면. Widget name, Hostname Management, Widget Mode 의 Managed(Recommended)·Non-interactive·Invisible
계정 › Turnstile › Add widget위젯 이름, 쓸 호스트 이름, 위젯 모드(Managed·Non-interactive·Invisible)를 정하는 화면입니다.

① 위젯 — 토큰이 만들어지는 곳 브라우저에서 도는 부분

시험용 사이트키를 골라 위젯이 어떻게 도는지 봅니다. 실제 키는 허용 도메인에 묶여 있어서, 다른 사이트 키를 쓰면 위젯이 뜨지 않습니다 — 화면에는 코드 문제처럼 보이고 콘솔에도 원인이 안 나옵니다.
사이트키
받은 토큰
아직 없다
토큰은 한 번 쓰면 끝이고 수 분 안에 만료됩니다. 그래서 브라우저에 저장해 두고 재사용하는 설계는 처음부터 성립하지 않습니다.

② 서버 검증 — siteverify 왕복 오리진에서 도는 부분

아래 버튼은 우리 워커가 challenges.cloudflare.com/turnstile/v0/siteverify 로 실제 왕복한 결과입니다. 브라우저가 아니라 서버가 물어야 합니다 — 브라우저 판정은 위조됩니다.
대기
아직 검증하지 않았습니다
왼쪽에서 토큰을 받은 뒤 「서버로 검증」을 누릅니다.
siteverify 응답 원문이 여기 나옵니다.

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Workers Routes 의 Add route 창. Route 입력칸과 Worker 선택, Save 단추(뒤 목록은 가림)
도메인 › Workers Routes › Add route주소 패턴(예: *.example.com/*)과 그 주소에서 돌 Worker 를 고릅니다.

지금 이 요청이 어떻게 여기까지 왔나실측

불러오는 중…

경로별로 누가 응답하나워커 / 오리진 / 자산

라우트는 host + path 패턴으로 잡습니다. 같은 호스트여도 경로에 따라 워커가 받을 수도, 오리진으로 그냥 갈 수도 있습니다. 아래는 이 사이트의 실제 경로들을 하나씩 쏴 본 결과입니다.
「경로 쏴 보기」를 누르면 결과가 여기 나옵니다.
사례 실제 문의에서 나온 것 1건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

새 고급 속도 제한 룰 화면. 조건, With the same characteristics 의 IP, Use custom counting expression, When rate exceeds
도메인 › Security › Security rules › Create rule › Rate limiting rules조건, 무엇으로 셀지(With the same characteristics), 몇 번을 넘으면 막을지를 한 화면에서 정합니다.
With the same characteristics 목록이 펼쳐진 화면. IP, IP with NAT support, Header value of, Cookie value of, Query value of, Host, Path
같은 화면 › With the same characteristics세는 기준 목록입니다. 사무실처럼 여러 사람이 한 IP 를 쓰면 IP with NAT support 나 헤더·쿠키 값을 고릅니다.

속도 제한 — 몇 번째부터 막히나표적 호스트로 연속 발사

🔴 이 발사는 실습장과 「같은 존」 안에서 나갑니다 — 그 존의 속도 제한·WAF 를 타지 않습니다. 여기서 「안 막혔습니다」가 나와도 실제로는 막힐 수 있습니다. 진짜 판정은 「WAF 룰」 탭의 「진짜로 판정」 (존 밖 발사)으로 보고, 속도 제한 자체는 바깥에서 curl 로 확인합니다.

같은 요청을 연속으로 쏴서 몇 번째 요청부터 상태코드가 바뀌는지를 봅니다. 속도 제한은 「임계값 + 기간 + 무엇으로 세는가(특성)」 셋으로 정해집니다 — IP 로 세는지 JA4 로 세는지에 따라 같은 발사가 전혀 다르게 보입니다.
발사하면 회차별 결과가 여기 나옵니다.
사례 실제 문의에서 나온 것 2건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Security Analytics 의 Bot analysis 막대 그래프. Automated, Likely automated, Likely human, Verified bot 건수
도메인 › Security › Analytics › Bot analysis요청을 봇 점수 구간(Automated·Likely automated·Likely human)과 검증 봇으로 나눠 보여 줍니다.
Security Settings 를 Bot traffic 으로 거른 화면. AI Labyrinth, Bot management(Always active), Challenge passage, Cloudflare managed ruleset
도메인 › Security › Settings › Bot traffic봇 관련 설정 모음입니다. Bot management 는 늘 켜져 있고, 차단은 커스텀 룰로 정합니다.

봇 판정 — 무엇을 보고 사람/봇을 가르나표적 호스트로 발사

🔴 이 발사도 「같은 존」 안에서 나가 그 존의 WAF·봇 룰이 평가되지 않습니다 — 전부 「통과」로 보이는 것이 정상입니다. 진짜 판정은 「WAF 룰」 탭의 「진짜로 판정」(존 밖 발사)으로 봅니다.

User-Agent 를 바꿔 가며 쏘고 판정이 달라지는지를 봅니다. 봇 점수 자체는 응답 헤더로 오지 않습니다 — 점수(1=확실한 봇 … 99=확실한 사람)와 검증된 봇 여부는 Security Events·Logpush 에서만 보이고, Enterprise + Bot Management 에서만 쓸 수 있습니다. 그리고 판정은 UA 만으로 정해지지 않습니다 — TLS 지문·행동·ASN 이 함께 들어갑니다. 그래서 UA 만 바꿔도 결과가 안 바뀔 수 있습니다.
발사하면 UA 별 판정이 여기 나옵니다.
사례 실제 문의에서 나온 것 1건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

New Cache Rule 화면. Cache everything, Bypass cache for everything, Cache default file extensions 템플릿과 Rule name, 조건 선택
도메인 › Caching › Cache Rules › Create rule자주 쓰는 세 가지(모두 캐시, 모두 우회, 기본 확장자만 캐시)는 템플릿으로 바로 시작합니다.

캐시 — 두 번째 요청이 어디서 오나cf-cache-status

같은 주소를 두 번 쏩니다. 첫 번째는 MISS(오리진까지 갔습니다), 두 번째가 HIT 면 엣지가 답한 것입니다. DYNAMIC 은 「캐시 대상이 아닙니다」라는 뜻이고, 쿼리스트링이 다르면 다른 주소로 봅니다.
발사하면 회차별 캐시 상태가 여기 나옵니다.
사례 실제 문의에서 나온 것 3건 — 제목을 누르면 창으로 열립니다

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Rules Overview 의 Rule templates 창. Redirect from HTTP to HTTPS, Redirect from WWW to root, Cache everything(뒤 목록은 가림)
도메인 › Rules › Overview › TemplatesHTTP→HTTPS, www→루트 같은 리다이렉트와 변환은 템플릿에서 시작하면 조건식을 쓰지 않아도 됩니다.

변환 · 리다이렉트 — 응답이 어떻게 바뀌나헤더 · 3xx

요청을 쏘고 돌아온 헤더와 상태코드를 그대로 보여 줍니다. 리다이렉트 룰이 걸려 있으면 3xx 와 location 이, 응답 헤더 변환이 걸려 있으면 그 헤더가 여기 나타납니다. 따라가지 않고 첫 응답을 그대로 봅니다 — 따라가면 무엇이 바꿨는지가 사라집니다.
발사하면 응답 헤더가 여기 나옵니다.
🧪 새 랩 — 소속별 접근 통제(PC·휴대폰): 본사·협력사·고객사 계정으로 직접 로그인해 같은 서버가 소속마다 열리고 막히는 것을 확인합니다. 처음이면 초급 안내부터 ↗
🧭 SSL-VPN 대체 — 비교 안내: SSL-VPN 과 Zero Trust 가 무엇이 어떻게 다르고, VPN 을 끄지 않으면서 무엇부터 옮기는지를 초급·중급·전문가 3단계로 정리했습니다. 비교 안내 보기 ↗

한눈에 보기 — 그림으로 따라가는 Zero Trust 로그인 처음 보는 사람용 · 여기는 읽는 곳이고, 실제로 눌러 보는 것은 ② 직접 해보기부터입니다

한 줄로 말하면: 회사 앱 앞에 Cloudflare 가 문지기로 서서, 「누구냐」(회사 로그인)와 「진짜 너냐」(휴대폰 6자리)를 물은 뒤에만 들여보냅니다. 아래 그림 7장이 그 문지기가 무엇을 언제 묻는지, 어디서 설정하는지, 막히면 어떻게 푸는지를 순서대로 보여 줍니다.

그림은 작게 줄이면 안 읽혀서 크기를 지켰습니다 — 옆으로 밀어서 보세요.

직원브라우저 · 휴대폰 Cloudflare Access문지기앱 앞에 서 있습니다 ① 누구냐회사 로그인 · 이메일 코드 ② 진짜 너냐휴대폰 6자리 (MFA) 앱 접속 묻습니다 통과하면 ①만 있으면 「비밀번호 유출 = 뚫림」. ②가 있어야 휴대폰까지 가진 사람만 들어옵니다.
1큰 그림. 문지기는 두 번 묻습니다. ①은 회사가 이미 갖고 있는 로그인이고, ②가 이 실습에서 새로 켜는 「2단계 인증(MFA)」입니다.
A · Access 가 직접 묻습니다 (Independent MFA — 회사 로그인은 손대지 않습니다) 직원 회사 로그인 (IdP)비밀번호만 · 그대로 둡니다 Access: 「6자리 주세요」등록·검증·삭제 전부 Cloudflare 안 앱 B · IdP 가 묻습니다 (회사 로그인 자체에 2단계가 있을 때) 직원 회사 로그인: 비밀번호 + 6자리IdP 가 「6자리도 맞았습니다」고 메모(amr) Access: 메모만 읽습니다직접 묻지 않습니다 앱 amr 주황 칸 = 6자리를 「누가」 묻는가. 회사 로그인(AD FS 등)에 2단계가 없으면 A 가 유일한 길입니다.
22단계는 두 군데서 걸 수 있습니다. A 는 회사 로그인을 건드리지 않고 Cloudflare 가 뒤에서 한 번 더 묻는 방식, B 는 회사 로그인 자체가 묻는 방식입니다.
처음 한 번 — 등록 앱 접속회사 로그인 뒤 「Setup MFA」등록이 없으면 뜹니다 App Launcher…/AddMfaDevice QR 을 휴대폰으로인증 앱에 항목 생김 6자리 입력맞으면 완료 App Launcher 가 꺼져 있으면 여기서 막힙니다「관리자에게 문의」 화면에서 끝 — 등록 자체가 불가능 그 다음부터 — 로그인 회사 로그인 「Authenticate your identity」 6자리 입력 앱 (지속시간엔 안 묻음)
3사용자가 겪는 순서. 등록은 딱 한 번이고 그 문이 App Launcher 입니다. 빨간 갈림길이 Demo2 에서 실제로 막혔던 자리입니다 — 관리자가 먼저 켜 둬야 합니다.
조직 (기본값) 허용 수단: 인증 앱·보안키·생체지속시간: 24h전역 강제: 끔 Access settings › MFA 앱 (이 앱만) Customize: 수단 3종지속시간: 15m또는 「조직 따름」 / 「끔」 앱 편집 맨 아래 Authentication › MFA 정책 (이 사람들만) 예: 공용 계정은 인증 앱만예: 관리자는 매번 묻기안 켜면 앱 값 그대로 정책 편집 › Additional settings 덮어씁니다 또 덮어씁니다 오른쪽이 이깁니다: 정책 › 앱 › 조직. 그래서 「MFA 설정 페이지」 하나가 없고 세 화면에 흩어져 있습니다.
4설정은 세 층이 덮어씁니다. 처음 켤 때는 조직에서 수단만 허용하고, 앱 하나에만 걸어 시작하는 것이 안전합니다(전역 강제를 켜면 모든 앱이 한꺼번에 묻습니다).
휴대폰 분실·교체6자리를 못 만듭니다 관리자: 기기를 지웁니다Users › 사용자 › MFA devices › Delete 사용자 다음 접속「Setup MFA」가 다시 뜹니다 새 휴대폰으로 재등록그림 3 의 첫 줄 반복 요청 복구 코드는 없습니다. 보안키·Windows Hello 를 하나 더 등록해 두면 관리자 없이 본인이 옛 기기를 지울 수 있습니다.
5잠겼을 때. 관리자가 할 일은 「지우기」 하나뿐입니다. 대신 등록해 주는 기능은 없고, 사용자가 다시 QR 을 찍습니다.
로그인 시점 8h24h0 단말(WARP) 세션기본 8h · 켜져 있으면 다른 셋을 전부 이깁니다 앱 · 정책 세션24h (앱마다 다르게 둘 수 있습니다) 전역 세션24h · 「다시 로그인」 을 보는 시점 MFA 지속시간별도 시계 · 「다시 6자리」 를 묻는 시점 (Require every login 이면 0) 재부팅 막대는 활동으로 늘어나지 않고 로그인 시점부터 고정으로 흐릅니다. 재부팅해도 막대는 그대로입니다 — 강제로 끊는 기능은 없습니다.
6세션은 시계 네 개. 「WARP 를 켜 두면 왜 계속 유지되나」의 답이 첫 줄입니다. 재부팅에 맞춰 끊고 싶으면 단말 세션을 짧게 두고, MFA 는 매번 묻게 하고, Windows 라면 「미인증 시 인터넷 차단(no_auth_no_internet)」을 더합니다.
가르는 질문은 하나 — 무엇이 Cloudflare 에 「도달」하나 설치 안 했을 때 브라우저로 그 앱에 갈 때만 브라우저사람만 확인 앱 주소 Cloudflare그 「요청」 만 압니다 회사 웹 앱 앱이 Cloudflare 뒤에 「게시」돼 있어서 지나갑니다 — 기기는 아무것도 안 보냅니다 이건 됩니다 · 브라우저로 여는 앱의 로그인 문지기(Access) · 브라우저로 여는 SSH · RDP · VNC · 격리 브라우저 · 인증서(mTLS) · 사무실 회선 DNS 필터 이건 안 됩니다 — 기기를 모르기 때문에 · 기기 상태 검사(디스크 암호화 · OS 버전 · 특정 프로그램) · 사람·기기별 인터넷 필터(브라우저 밖 트래픽 포함) · 사설망 접속(웹이 아닌 것 — DB · 파일서버 · 사내 도구) · 자료 유출 검사(DLP) · 나가는 IP 고정 · 무슨 SaaS 쓰나 Cloudflare 가 보는 것이 「그 요청」 하나뿐이라 판단할 근거가 없습니다 설치했을 때 그 기기의 트래픽을 기기가 「밀어 올립니다」 회사 PC등록됨 · 좌석 1 전부 Cloudflare그 「기기」 를 압니다 회사 앱 · 사설망 인터넷 전체 기기가 신원과 상태를 함께 보내므로 판단할 근거가 생깁니다 무엇을 설치하나 Cloudflare One Client — 옛 이름 WARP · 휴대폰은 Cloudflare One Agent Windows·macOS·Linux·iOS·Android·ChromeOS · 「팀 이름」 으로 조직에 붙습니다 왼쪽에서 되던 것 전부 + 아래가 열립니다 · 기기 상태 검사 — 조건을 못 채우면 로그인을 막습니다 · 사람·기기별 인터넷 필터 · 자료 유출 검사(DLP) · 사설망 접속 — 웹이 아닌 것까지, 공개 주소 없이 · 나가는 IP 고정 · 무슨 SaaS 를 쓰는지 파악 · 접속 품질 측정 · 서버 접속(SSH)에 짧게만 사는 인증서 + 기록 모드가 다섯입니다. 트래픽은 안 보내고 「기기 상태만」 주는 것도 있습니다 (Posture only mode) — 설치하지 않은 채로 상태 검사만 더하고 싶을 때 씁니다 대신 치르는 값 좌석 1개 · 배포와 프로파일 관리 · 제외 경로(스플릿 터널) 설계 · 세션이 하나 더 생깁니다(앱에서 켜면 그 세션이 나머지를 이깁니다)
7설치하면 「기기」를 알게 됩니다. 설치 안 하면 Cloudflare 가 보는 것은 그 앱으로 가는 「요청」 하나뿐이라, 기기 상태·사설망·인터넷 필터는 근거가 없어서 못 하는 것입니다. 능력 차이는 기능 목록이 아니라 도달 범위에서 나옵니다.
🔴 거꾸로, 「설치하지 않았으면 아예 못 들어오게」도 됩니다 — Access 정책의 Require 에 걸면 로그인 화면조차 통과하지 못합니다. 다만 WARP 로 걸면 개인용 WARP 를 켠 사설 노트북도 통과합니다. 「회사 PC 만」이 목적이면 Gateway 입니다 — 운영 매뉴얼 M17 에서 자세히 ↓
IdP 신분을 확인해 주는 곳 — 회사 로그인(AD FS·Okta·구글). 「누구냐」를 답합니다 MFA · 2단계 비밀번호 말고 한 번 더 확인. 「진짜 너냐」 TOTP · 인증 앱 30초마다 바뀌는 6자리를 만드는 휴대폰 앱(Google·Microsoft Authenticator) App Launcher 내가 들어갈 수 있는 앱 목록 화면. 인증 앱 등록 창구가 여기 amr IdP 가 「이렇게 확인했습니다」고 적어 보내는 메모. 그림 2 의 B 에서 Access 가 읽는 것 세션 한 번 확인받고 다시 안 묻는 시간. 활동으로 연장되지 않습니다 WARP · Cloudflare One Client 회사 PC 에 설치하는 접속 프로그램. 설치하면 Cloudflare 가 「그 기기」를 알게 됩니다(그림 7). 앱에서 「Authenticate with Cloudflare One Client」를 켜 두면 그때만 이 세션이 나머지를 이깁니다
읽는 순서: 그림 1 → 2 → 3 을 본 뒤 아래 「직접 해보기」 카드에서 실제로 눌러 봅니다. 4 는 관리자, 5·6 은 운영할 때, 7 은 「접속 프로그램을 설치해야 하나」를 정할 때.

내 계정으로 직접 — 만들고, 들어가고, 지워 봅니다 진짜 Cloudflare Zero Trust · 흉내 아님

아래 번호 다섯 개를 순서대로 누르시면 됩니다. 중간의 M 은 순서와 별개로, 로그인만 되면 언제든 해 볼 수 있는 2차 인증 등록입니다. 3·4·5번에서 실제로 지워집니다 — 그리고 무엇이 안 지워지는지가 이 실습의 요지입니다. 운영 매뉴얼 M5·M6 이 글로 설명하는 것을 여기서는 몸으로 겪습니다.

🔵 여기서 쓰는 것은 「여러분 이메일 하나」입니다. Cloudflare 계정을 만들 필요도, 회사 IdP 계정을 받을 필요도 없습니다 — 개인 지메일도 됩니다(주소에 +lab 처럼 붙여도 같은 메일함으로 코드가 옵니다). 홈에서 그 주소로 신청하면 이 실습 계정의 Zero Trust 사용자가 되고, 아래 ①~⑤ 는 전부 그 신원으로 돕니다 — 비밀번호는 만들지 않습니다.
그래서 화면에서 여러분을 찾을 자리는 ③ 좌석과 ④ 기기입니다. 로그인하면 거기 여러분 줄이 생기고, 그 줄이 생기고 사라지는 것을 보는 것이 이 실습입니다. ① 표는 회사 AD 를 흉내 낸 랩 IdP 목록이라 여기에 없는 것이 정상입니다
🔴 「④ 기기」에 줄이 생기려면 Cloudflare One Client 를 설치해야 합니다 — 예외가 없습니다. 기기 등록은 클라이언트가 조직에 붙을 때 만들어지는 것이라서입니다(데스크톱 Cloudflare One Client, 옛 이름 WARP · 휴대폰 Cloudflare One Agent).
· 브라우저로 앱에 들어가는 것은 클라이언트 없이 됩니다 — 대신 기기 등록이 생기지 않습니다 (그림 7: 그때 Cloudflare 가 아는 것은 「그 요청」 하나입니다). · 좌석은 기기가 아니라 신원에 붙습니다 — 클라이언트 없이 로그인만 해도 좌석은 잡힙니다(M7). · 트래픽을 안 보내고 기기 상태만 주는 모드(Posture only)도 클라이언트는 설치합니다.
🔵 이 랩에서 클라이언트로 붙어 보는 것도 됩니다 — 팀 이름은 mzccfteam 입니다(warp-cli teams-enroll mzccfteam, 또는 앱의 Team name 칸). 붙으면 「④ 기기」에 여러분 단말 줄이 생기고, M3·M4 의 함정 (지울수록 목록이 길어지는 것)을 본인 단말로 볼 수 있습니다.
🔴 다만 등록에는 등록 관문(Device enrollment permissions)이 따로 있고, 이 랩의 사람용 정책은 회사 도메인 주소만 허용하도록 되어 있습니다 — 개인 주소로는 거부될 수 있습니다 (그때 화면에 Enrollment request is invalid 로 끝납니다). 로그인·좌석·2차 인증 실습은 개인 주소로 전부 되고, 기기 등록만 이 제한을 받습니다.

왜 「지웁니다」가 넷으로 갈라지나

Cloudflare 에는 「사용자」라는 단일 객체가 없습니다. Zero Trust 의 전제가 「신원 저장소를 우리가 갖지 않습니다」이기 때문입니다 — 회사 신원은 회사 IdP(AD FS)에 있고 Cloudflare 는 판정만 합니다. 그래서 Cloudflare 가 가진 것은 사람이 아니라 아래 셋뿐이고, 넷은 서로를 이메일 문자열로만 가리킵니다. 참조가 아니라 이름이 우연히 같을 뿐입니다.

1IdP 가입자
계정과 비밀번호. IdP 서버에 있고 Cloudflare 는 이것을 모릅니다. 로그인할 때 IdP 가 서명해 보내는 「이 사람은 …입니다」를 믿을 뿐입니다.
2로그인 허용
조건식입니다. email == "a@b.c" 는 그 사람을 가리키는 게 아니라 문자열 비교입니다. 그래서 사람을 지워도 조건은 그대로 남습니다.
3좌석
과금 단위입니다. 「이 계정에서 몇 명이 쓰나」. 권한이 아니라 점유 상태라서, 반납해도 ②가 허용하면 다시 점유합니다.
4단말 등록
WARP 가 만든 기기별 키입니다. 사람이 아니라 기기에 붙고, 한 사람이 여러 개를 가집니다. 지우면 재인증 때 새 키·새 줄이 생깁니다.
그래서 「사용자 삭제」라는 동작이 성립하지 않습니다 — 지울 사용자 객체가 없기 때문입니다. 실측으로 확인할 수 있습니다: 사용자 레코드에는 email · last_successful_login · access_seat · seat_uid 뿐이고 비밀번호도 권한도 소속 정책도 없습니다. 정책의 include 도 사용자 ID 가 아니라 이메일 문자열입니다.
이것이 M5·M6 의 근본 이유이고, 아래 표가 넷을 한 줄에 놓는 이유입니다 — 어긋난 자리가 곧 답입니다.
계정은 두 군데서 만듭니다 — 여기가 제일 헷갈리는 지점입니다.
① 사내 IdP 가입 → AD FS 를 흉내 낸 SAML IdP 입니다. 이메일 + 비밀번호 + 6자리를 실제로 검증합니다. 사내 Active Directory 계정에 해당한다고 보시면 됩니다.
② 아래 실습 계정 신청 — 우리 명단이고, 여기 있으면 Cloudflare Access 가 들여보냅니다(승인 없음).
둘 다 있어야 끝까지 갑니다. 하나만 있으면 어디서 막히는지가 곧 실습입니다.
1가입 신청운영자?신청만으로는 좌석이 안 생깁니다. 좌석은 로그인에 성공한 순간 잡힙니다 (등록 화면에 로그인만 해도 잡힙니다 — 실측).

그래서 운영자가 볼 숫자는 가입 인원과 실제 좌석 수 둘이고, 이 둘은 어긋납니다 — 가입만 하고 한 번도 안 들어온 사람은 좌석이 없습니다.

🕒 1주일 로그인이 없으면 명단과 좌석을 함께 정리합니다. 승인이 없어진 뒤로 이 정리가 자리를 만드는 유일한 장치입니다 — 가입이 막히는 순간 자동으로 한 번 돕니다.
홈 화면에서 이메일을 넣습니다. 아직 아무 일도 일어나지 않습니다 — 우리 명단에 한 줄이 생길 뿐이고 Cloudflare 는 당신을 모릅니다.
2로그인
신청한 뒤 바로 누르면 이메일로 여섯 자리 코드가 옵니다. 통과하는 순간 Cloudflare Zero Trust 사용자가 생기고 좌석 하나를 차지합니다. 명단에 없는 주소로 누르면 막힙니다 — 그것도 실습입니다.
M2차 인증(MFA) 등록
인증 앱 · Windows Hello/지문 · 보안키 셋 다 켜 두었습니다. 등록은 App Launcher 안에서 합니다 — 그 화면이 어디 있는지 몰라서 못 찾는 것이 현장 1순위 질문입니다(운영 매뉴얼 M9).
3좌석을 반납해 봅니다
로그인하는 순간 Zero Trust 좌석 하나를 차지합니다. 그걸 지금 반납해 봅니다. 이 버튼이 보내는 요청은 대시보드 「Remove users」와 완전히 같습니다. 반납해도 이 화면은 그대로 열려 있고, 다시 로그인하면 좌석을 다시 차지합니다.
4내 기기 목록 · 지우기
WARP 로 등록한 단말이 여기 나옵니다. 지우면 그 단말이 다시 인증할 때 기기 줄이 새로 생깁니다 — 「지울수록 목록이 길어집니다」를 직접 보시게 됩니다.
5계정을 통째로 지웁니다
Access 허용 명단에서 빠집니다 — 다음부터는 코드조차 안 옵니다. 좌석도 함께 반납됩니다. 그런데 이 화면은 계속 열려 있습니다. 왜 그런지가 이 실습의 답입니다. 되돌릴 수 있습니다 — 「다시 신청」이 나옵니다.
여기서 지워지는 것은 셋이고, 셋이 서로 다릅니다.운영자?가입과 삭제는 비대칭입니다.

가입은 우리 명단만 바꿉니다(Cloudflare 설정 변경 0건). 반면 삭제는 명단과 함께 Cloudflare Access 정책과 좌석까지 정리합니다 — 좌석은 다음 로그인에 새로 잡힙니다.

들이는 것은 문턱 없이, 내보내는 것은 확실하게. 1주일 자동 정리도 같은 경로를 씁니다.
③은 좌석만(PATCH /access/seats), ④는 단말 등록만 (DELETE /devices/registrations/{id}), ⑤는 회원 자격 + 좌석을 함께 놓습니다. 이 워커의 토큰은 이 실습 계정의 좌석·사용자·정책·단말에만 닿고 그 밖은 403 입니다 — 그래서 공개 화면에서 눌러 보게 열어 두었습니다. 그 셋이 서로 다른 동작이라는 것이 바로 운영 매뉴얼 M5·M6 이 말하는 내용이고, 이 실습에서 직접 확인하시게 됩니다.

직접 해보기 — 진짜 OTP 를 등록하고, 진짜로 막히는지 봅니다 2026-09-09 두 트랙 실측 완주

2단계 인증(MFA)은 두 군데서 걸 수 있습니다. Access 가 직접 거는 것(Independent MFA — IdP 에 2단계가 없는 조직이 쓰는 방식)과 IdP 가 거는 것. 둘 다 이 랩에서 실제 인증 앱(Google · Microsoft Authenticator, Authy)으로 등록하고 검증합니다. 흉내가 아닙니다 — 틀린 코드는 막히고, 같은 코드를 두 번 쓰면 막히고, 등록 없이는 들어갈 수 없습니다. 휴대폰이 없으면 아래 totp.py 가 인증 앱 대신 6자리를 만듭니다 — 아무 곳에도 접속하지 않고 시계와 설정 키만 씁니다.
⬇ totp.py 내려받기 83줄 · 4KB · 표준 라이브러리만 씁니다(설치할 것 없음)
## 터미널에서 바로 받으시려면 (둘 중 아무거나)
curl -O https://waf-lab.mzc.cflare.kr/lab/py/totp.py
wget https://waf-lab.mzc.cflare.kr/lab/py/totp.py
파이썬 코드 보기 — totp.py · 83줄 · 받기 전에 무엇을 하는지 읽어 보실 수 있습니다

안에 공식 API 문서 주소도 함께 적어 두었습니다. 위 「복사」 단추로 전문을 한 번에 복사하실 수 있습니다.

#!/usr/bin/env python3
"""휴대폰이 없을 때 인증 앱 대신 6자리를 만듭니다 (실습 ② · 운영 매뉴얼 M9).

🟢 아무 곳에도 접속하지 않습니다. 계정도 토큰도 필요 없습니다 — 시계와 설정키만 씁니다.
표준 라이브러리만 씁니다 — 설치할 것이 없습니다.

  python totp.py JBSWY3DPEHPK3PXP          # 등록 화면의 「설정 키」를 그대로
  python totp.py JBSWY3DPEHPK3PXP --watch  # 30초마다 새 코드를 계속 찍습니다

어디서 설정키를 얻나 — 2차 인증 등록 화면(App Launcher › Account › MFA devices, 또는
`<팀이름>.cloudflareaccess.com/AddMfaDevice`)에서 QR 아래의 「Can't scan?」 같은 문구를
누르면 **영문·숫자 문자열**이 나옵니다. 그것이 설정 키(base32)입니다.

무엇을 계산하나 — RFC 6238 그대로입니다. 「지금 시각 ÷ 30초」를 8바이트로 만들고,
설정 키로 HMAC-SHA1 을 걸어 그 결과에서 6자리를 뽑습니다. 인증 앱이 하는 일과 같습니다.

🔴 **이 파일은 그 자체가 인증 수단입니다.** 설정 키를 넣고 돌리는 순간 그 계정의 6자리를
   만들 수 있으므로, 설정 키를 **파일이나 채팅에 남기지 마십시오**. 실습용으로 한 번 쓰고
   나면 등록을 지우고 휴대폰으로 다시 등록하시는 편이 낫습니다.

🔴 **시계가 틀리면 코드도 틀립니다.** 30초 창이라 앞뒤로 몇 십 초만 어긋나도 거절됩니다 —
   Cloudflare 쪽은 시계가 20초 이상 어긋나면 인증 토큰 자체를 무효로 봅니다(M15).

공식 문서
  Independent MFA  https://developers.cloudflare.com/cloudflare-one/access-controls/access-settings/independent-mfa/
  RFC 6238 (TOTP)  https://www.rfc-editor.org/rfc/rfc6238
"""
import argparse
import base64
import hashlib
import hmac
import struct
import sys
import time


def code(secret_b32, when=None, step=30, digits=6):
    """설정 키(base32) 로 그 시각의 코드를 만듭니다."""
    raw = secret_b32.strip().replace(" ", "").replace("-", "").upper()
    raw += "=" * ((8 - len(raw) % 8) % 8)          # base32 는 8자 단위 — 부족한 만큼 채웁니다
    try:
        key = base64.b32decode(raw, casefold=True)
    except Exception:
        sys.exit("설정 키가 base32 가 아닙니다. 등록 화면에 보이는 문자열을 그대로 넣어 주십시오.")
    counter = int((time.time() if when is None else when) // step)
    mac = hmac.new(key, struct.pack(">Q", counter), hashlib.sha1).digest()
    off = mac[-1] & 0x0F                            # 마지막 4비트가 「어디서 자를지」를 가리킵니다
    num = struct.unpack(">I", mac[off:off + 4])[0] & 0x7FFFFFFF
    return str(num % (10 ** digits)).zfill(digits)


def left(step=30):
    return step - int(time.time()) % step


def main():
    ap = argparse.ArgumentParser(description="인증 앱 대신 6자리를 만듭니다 (RFC 6238)")
    ap.add_argument("secret", help="등록 화면의 설정 키(base32)")
    ap.add_argument("--watch", action="store_true", help="30초마다 계속 찍습니다 (Ctrl+C 로 중단)")
    ap.add_argument("--digits", type=int, default=6)
    ap.add_argument("--step", type=int, default=30)
    a = ap.parse_args()

    if not a.watch:
        print("%s   (남은 시간 %d초)" % (code(a.secret, step=a.step, digits=a.digits), left(a.step)))
        return

    print("30초마다 새 코드를 찍습니다. Ctrl+C 로 멈춥니다.")
    last = None
    try:
        while True:
            c = code(a.secret, step=a.step, digits=a.digits)
            if c != last:
                print("%s   (남은 시간 %d초)" % (c, left(a.step)))
                last = c
            time.sleep(1)
    except KeyboardInterrupt:
        print("\n멈췄습니다.")


if __name__ == "__main__":
    main()
A
Access 가 직접 거는 MFA Independent MFA
Access 가 회사 로그인과 무관하게 2단계를 한 번 더 묻는 방식입니다. 여기서는 개념만 다룹니다 — 위 그림 2 가 그 차이이고, 설정 위치와 잠겼을 때의 복구는 운영 매뉴얼 M9(인증 수단을 잃었을 때)와 M17(클라이언트가 없으면 아예 못 들어오게)에 있습니다.
눌러 보는 실습은 오른쪽 B 입니다.
B
IdP 가 거는 MFA 랩 IdP · RFC 6238
① 실습 A ↗ 접속 → 선택 화면 없이 사내 IdP 로 → 사용자 선택
② 처음이면 QR 등록 화면(키 직접 입력도 가능) → 6자리로 등록 마감. 다음부터는 코드만
③ 통과 화면의 amr 에 ["pwd","otp","mfa"] 가 실려 옵니다 — 이것이 Access 「인증 방식」 정책의 근거
「등록 지우기」 버튼이 관리자 삭제를 흉내 냅니다(랩 전용) · 협력사 IdP(ZT 실습 B)는 「2단계 없이 진행」이 있습니다
A · Access 가 직접 (Independent MFA)B · IdP 가 (랩 IdP)
누가 검증하나Cloudflare Access. IdP 는 모릅니다IdP. Access 는 결과(amr)만 받습니다
등록하는 곳App Launcher <team>.cloudflareaccess.com/AddMfaDeviceIdP 로그인 화면(처음 로그인 때)
어디에 강제하나조직 → 앱 → 정책 순으로 덮어씁니다. 이 앱은 totp·biometrics·security_key · MFA 세션 15분IdP 정책(사내 필수 · 협력사 선택)
오리진이 보는 증거없습니다. JWT 에 MFA 표시가 안 실립니다 — 통과 못 하면 이 화면에 못 올 뿐amr · acr(OIDC) / AuthnContextClassRef(SAML)
잠기면관리자가 Zero Trust › Users › 사용자 › MFA devices 에서 삭제 → 다음 접속 때 재등록IdP 관리자가 풉니다(랩: 「등록 지우기」)
랩 IdP 상태 확인 중…
Access 앱 4개 + App Launcher · 인증 앱은 Google · Microsoft Authenticator · Authy 아무거나

대시보드에서는 어디를 눌러야 하나 — Independent MFA 설정 순서 Demo2 실제 화면 · 2026-09-09 캡처

찾기 힘든 이유가 있습니다. MFA 설정이 세 군데에 흩어져 있고(조직 · 앱 · 정책), 사용자 기기 삭제는 네 번째 화면(Users)에 있습니다. 아래 순서대로 누르면 됩니다. 아래 링크는 여러분이 로그인한 계정의 같은 화면을 엽니다 — 계정이 여러 개면 계정 목록이 먼저 떠서 고르면 되고, 하나면 바로 이동합니다. 로그인이 안 돼 있으면 로그인 뒤 같은 자리로 옵니다. 썸네일을 누르면 화면 캡처를 크게 볼 수 있습니다(캡처는 우리 데모 계정).
App Launcher 설정 화면
1App Launcher 를 먼저 켭니다 없으면 등록 불가
Access controls › Access settings › Manage your App Launcher › Manage
딥링크(내 계정) · 「App launcher policies」에 Allow 정책 하나(예: 사내 도메인) → Login methods 는 「Accept all available identity providers」 → Save. 사용자의 MFA 등록 화면이 이 앱 안에 있어서, 꺼져 있으면 「Setup MFA」가 「관리자에게 문의」로 끝납니다(Demo2 실측).
🔴 기본값은 꺼짐입니다 — 공식 문서 “By default, the App Launcher is disabled.” 즉 아무것도 안 한 계정에는 App Launcher 앱이 아예 없습니다. 목록에 안 보이면 고장이 아니라 그 상태입니다.
🔴 이 정책은 「포털 문」만 엽니다. 공식 문서가 못박습니다 — “These rules do not impact permissions for the applications secured behind Access.” 여기에 사내 도메인 Allow 를 걸었다고 뒤에 있는 앱들이 열리는 것이 아닙니다. 앱 권한은 앱마다의 정책이고, 이 정책은 「내가 쓸 수 있는 앱 목록 화면에 들어갈 수 있나」만 정합니다.
⚠️ 아래 API 는 공식 문서에 없습니다 — 저희가 실측으로 확인한 값입니다. 문서화되지 않은 것은 예고 없이 바뀔 수 있으니, 자동화하시려면 화면을 정본으로 두고 확인하십시오. API: POST /access/apps type:"app_launcher" · Pulumi idp-lab-app-launcher
조직 MFA 설정
2조직에서 허용 수단과 지속시간을 켭니다
Access controls › Access settings › Allow multi-factor authentication (MFA) (접혀 있으면 제목 클릭)
딥링크(내 계정) · MFA methods: Biometrics · Security key · Authenticator application On (PIV·FIDO2 는 인프라 앱용) → Authentication duration Edit(기본 24h) → 「Use identity provider MFA」는 IdP 가 amr 을 줄 때만 → 「Apply global MFA settings by default」는 끈 채로 Save. 켜면 이 계정 앱 25개 전부가 묻습니다. 두 번째 캡처: 지속시간·전역 체크박스. API: PUT /access/organizations mfa_config
앱 MFA 설정
3앱에 겁니다 — 편집 화면 맨 아래 Authentication 블록
Access controls › Applications › 앱 이름 › (스크롤) Authentication › 오른쪽 위 MFA 탭
딥링크(내 계정 · 앱 목록) → 앱 이름 클릭 · 세 선택지: Respect global enforcement setting(조직 값 따름) / Custom MFA settings(수단 + 지속시간, 「Requires MFA on every access」 포함) / Disable MFA. 실습 앱은 Customize · 3종 · 15분. 상단 필터 「Login methods」를 누르면 바로 내려갑니다. 같은 블록 Identity 탭이 로그인 방식(IdP · One-time PIN)과 「Apply instant authentication」 — 캡처. API: 앱 mfa_config · Pulumi mfaConfig
정책 MFA 설정
4(선택) 정책으로 더 좁게 — 이 값이 앱·조직을 이깁니다
Access controls › Policies › 정책 이름 › 오른쪽 Additional settings › Override global multi-factor authentication settings (MFA)
딥링크(내 계정) · 우선순위 정책 › 앱 › 조직. 예: 공용 계정 그룹만 「보안키 금지·인증 앱만」, 관리자 그룹만 「매 접속마다」. 켜지 않으면 앱 설정이 그대로 적용됩니다. API: 정책 mfa_config
사용자 MFA 기기 삭제
5잠긴 사용자 풀기 — Users 상세 맨 아래
Team & Resources › Users › 사용자 클릭 › 「User identity」 탭 (스크롤 끝) MFA devices › ⋯ › Delete
딥링크(내 계정 · Users) · 표에 MFA ID · 기기 이름 · 수단이 보입니다. 이 MFA ID 가 API 의 authenticator_id (목록 API 는 없습니다). 지우면 사용자는 다음 접속에 「Setup MFA」를 받습니다. 목록 화면 → 캡처. API: DELETE /access/users/{user_id}/mfa_authenticators/{authenticator_id}
사용자 목록
6사용자는 대시보드가 아니라 App Launcher 에서 등록합니다
https://<team>.cloudflareaccess.com/AddMfaDevice (Demo2: mzccfteam)
관리자 대시보드에는 「대신 등록」 기능이 없습니다. 사용자 본인이 위 링크에서 QR 을 찍습니다(App Launcher 안에서 합니다). 팀 이름은 Access settings 맨 위 「You can reach it at your team domain」 문장, 또는 Overview › Account details › Team domain 에서.

어느 실습이 어느 IdP 로 가나 — 그리고 계정은 어디에 있나

🔵 버튼이 셋이라 계정도 셋처럼 보이지만, 하나입니다. 한 번 가입하면 A·B·C 어디서나 같은 이메일·비밀번호로 들어가고, 2차 인증도 한 번만 등록하면 셋 다 통과합니다. 갈리는 것은 「그 IdP 가 2차 인증을 요구하는가」와 토큰에 실리는 값뿐입니다.

실습허용한 IdP첫 화면에서 벌어지는 일
실습 A 사내 IdP(랩) 하나
자동 이동 켬
선택 화면이 아예 안 뜹니다. 허용 IdP 가 하나이고 자동 이동을 켜면 Access 가 곧바로 그리로 넘깁니다.
실습 B 협력사 IdP(랩) + 사내 AD FS(랩)
자동 이동 끔
버튼 두 개짜리 선택 화면. 버튼 글씨는 IdP 표시명 그대로입니다 — IdP 이름을 지은 그대로 고객 눈에 보입니다.
실습 C 셋 전부 + One-time PIN
자동 이동 끔
버튼 셋 + 「or」 + 이메일 입력칸. One-time PIN 도 IdP 하나로 취급되므로 목록에 넣어야 그 칸이 생깁니다.
실습장 로그인
이 실습장에 들어올 때
One-time PIN + 사내 AD FS(랩) 버튼 두 개. 여러분이 이 화면을 보려고 지나온 길입니다.

그래서 무엇이 어디에 저장되나 — 다섯 군데이고 서로 다른 것을 담습니다.

무엇이어디에3개 IdP 가 공유하나
랩 IdP 계정
이메일 · 비밀번호
실습용 IdP 서버의 파일 하나
가입은 /signup
🔴 공유합니다. 계정을 찾을 때 어느 IdP 인지를 아예 보지 않습니다 — 이메일만 봅니다.
2차 인증 등록
인증 앱(TOTP) · 지문·보안키
같은 서버, 계정 하나에 붙습니다 🔴 공유합니다. A 에서 QR 을 찍으면 B·C 에서도 그 코드로 통과합니다.
One-time PIN
이메일로 오는 6자리
저장되는 계정이 없습니다 Cloudflare 가 그 자리에서 코드를 보내고 확인합니다. 가입이라는 것이 없습니다.
좌석 · 로그인 세션 Cloudflare(실습 계정) IdP 와 무관합니다. 좌석은 기기가 아니라 신원에 붙습니다(운영 매뉴얼 M6).
실습장 회원 명단
어느 탭을 볼 수 있나
이 실습장 서버 Cloudflare Access 정책에는 이 목록이 없습니다 — 로그인할 때마다 Access 가 이쪽에 물어봅니다.

🔴 그래서 「B 로 가입하고 A 로 로그인」 같은 것은 없습니다. 가입은 한 번이고, 그 뒤로는 어느 버튼을 누르는가만 고르는 것입니다. 실제 조직에서는 IdP 마다 계정이 따로인 경우가 많은데, 이 실습장은 일부러 하나로 두었습니다 — 갈리는 것이 「앱 설정」뿐이어야 그 차이가 보이기 때문입니다.

⚠️ 2차 인증 요구는 IdP 마다 다릅니다 — 사내 IdP·사내 AD FS 는 필수, 협력사 IdP 는 선택(「2단계 없이 진행」을 고를 수 있습니다). 같은 계정인데 지나온 IdP 에 따라 토큰에 실리는 값이 달라집니다(amr·acr) — 오리진은 그 값으로 「2단계를 진짜로 거쳤나」를 압니다. ⑤ 절에 그 값을 나란히 놓아 두었습니다.

링크는 여러분이 로그인한 계정으로 갑니다(주소가 dash.cloudflare.com/?to=/:account/… 꼴입니다). 화면·문구는 2026-09-09 기준 — Cloudflare 가 UI 를 바꾸면 경로가 달라질 수 있습니다

운영 매뉴얼 — 도입한 뒤에 실제로 부딪히는 것들 공식 문서 + 우리 랩 실측(2026-09-10) · 회사·고객 값 없음

위 카드가 「어떻게 켜나」라면, 이 카드는 「켜고 나서 무엇이 문제가 되나」입니다. 스물두 가지 전부 현장 질문에서 나왔습니다. 제목을 누르면 근거와 화면 경로가 열립니다. 🔴 는 문서만 읽어서는 안 나오는 것, 해 보기 는 본인 계정에서 그대로 밟는 절차가 함께 들어 있다는 뜻입니다.

🔴 여기 적힌 것은 우리 랩에서 직접 지우고 켜 보고 확인한 것이거나 화면이 기본값으로 감추는 지점입니다. 「해 보기」가 붙은 절에는 내려받아 그대로 돌릴 수 있는 파이썬 파일이 들어 있습니다 — 대부분 읽기만 하고, 바꾸는 것은 --apply 를 붙일 때뿐입니다. M4·M8 은 시험용 단말로만 하십시오.

시험 환경 — 구성도 · 사용자별 정책 · 접속·시험 순서 우리 랩 실측 2026-10-14~15 · 회사·고객 값 없음

이 탭의 실습·매뉴얼 내용을 실제 단말로 확인하려고 만든 랩입니다. 소속별 접근 통제와 앱 차단은 GH 랩(Windows·Android 단말 + 가상 업무서버)에서, DLP·격리 브라우저는 권한이 있는 데모 계정에서 봅니다. 계정 ID·사람 이메일·내부 주소·비밀번호는 가렸습니다(<…>). 개념 설명은 운영 매뉴얼 «소속별 접근 랩» 과 M22 «앱은 설치·실행되는데 쓸 수 없다» 에 있습니다.

① 구성도

팀원 브라우저 단말 화면을 «보기만» 한다 (noVNC · 팀 로그인 뒤) Cloudflare 데모 계정 A — 화면 보기 Access 팀 정책 한 개 Windows · Android 화면 주소 2개 터널(화면 보기용) noVNC 로만 잇는다 AWS EC2 (서울) · 상시 가동 Linux (nested virtualization) Android 14 에뮬레이터 Cloudflare One 앱 가상 업무서버 6 (nginx) 안내판 · 운영 · ERP · 협력사 · 고객사 X · Y cloudflared 두 개 ① 랩 계정: 사설 대역 10.77.0.0/16 ② 데모 계정 A: 화면 보기 Windows Server 2022 Cloudflare One Client VNC (Linux 에서만 열림) 관리: SSM (인바운드 포트 0) 화면 Cloudflare 랩 계정 — 정책이 걸리는 곳 팀 이름 mzccfteam · Zero Trust Free 로그인(IdP) 사내 AD FS(랩) SAML + TOTP — 본사·그룹 IT 협력사 IdP(랩) OIDC — 협력사·고객 항공사 단말 프로필 2 · 단말 조건 3 본사형 = 전체 터널 · 외부형 = 랩 대역만 Windows OS·방화벽 · Android ≥ 13 Gateway 정책 DNS: 카카오톡 차단(그룹 IT 예외) · ChatGPT 차단 L4: ChatGPT 차단 · SSH 22 는 그룹 IT 만 랩 웹 80 통과 · 랩 대역 나머지 차단 HTTP: 서버별 허용 소속 · ERP 단말 조건 권한 없는 소속 → 안내판 차단 화면 사설 경로 10.77.0.0/16 → 터널 ① 서버 이름은 DNS 가 사설 주소를 돌려준다 로그 Gateway DNS · Network · HTTP · Access (Free 플랜이라 보존 1일) WARP WARP (Android) 터널 ① → 업무서버 DLP·격리 시험 단말 시험 사용자 목록의 사람만 + Cloudflare 루트 인증서 또는 클라이언트 없이 격리 브라우저 주소로 데모 계정 B — DLP·격리 격리 권한(유료 애드온) 있음 TLS 복호화 ON G0 목록 밖 전원 → 검사 안 함 G1 인증서 고정 앱 → 검사 안 함 G2 ChatGPT → 격리 G3 민감정보 전송 → 차단
💡 왜 계정이 셋인가 — 정책은 랩 계정(시험받는 쪽)에 두고, 단말 화면 보기는 다른 데모 계정의 팀 로그인 뒤에 둡니다(보는 쪽). 랩 계정은 Zero Trust Free 라 격리 브라우저가 없어서(유료 애드온), DLP·격리는 권한이 있는 데모 계정 B 에 따로 만들었습니다. 셋 다 Pulumi 코드로 만들었습니다.

② 사용자별 정책

소속로그인 버튼2단계단말 프로필
본사 임직원사내 AD FS (랩) · SAML필수 인증 앱 6자리본사형 — 전체 터널(인터넷도 Gateway)
그룹 IT 총괄사내 AD FS (랩) · SAML필수 인증 앱 6자리본사형
협력사 A (조업)협력사 IdP (랩) · OIDC선택외부형 — 랩 대역(10.77.0.0/16)만 터널, DNS 는 Gateway
협력사 B (정비)협력사 IdP (랩) · OIDC선택외부형
고객 항공사 X협력사 IdP (랩) · OIDC선택외부형
고객 항공사 Y협력사 IdP (랩) · OIDC선택외부형
대상주소본사그룹 IT협력사 A협력사 B고객 X고객 Y
랩 안내판why.ghlab.nxlab.cflare.kr ↗✅✅✅✅✅✅
운영 업무시스템ops.ghlab.nxlab.cflare.kr ↗✅✅✅⛔⛔⛔
정산·ERP 단말 조건erp.ghlab.nxlab.cflare.kr ↗✅✅⛔⛔⛔⛔
협력사 포털partner.ghlab.nxlab.cflare.kr ↗✅✅✅✅⛔⛔
고객사 X 포털airline-x.ghlab.nxlab.cflare.kr ↗✅✅⛔⛔✅⛔
고객사 Y 포털airline-y.ghlab.nxlab.cflare.kr ↗✅✅⛔⛔⛔✅
SSH 22ops…:22⛔✅⛔⛔⛔⛔
카카오톡kakao.com 등⛔✅ 예외⛔⛔⛔⛔
ChatGPT 10-15chatgpt.com · openai.com⛔⛔⛔⛔⛔⛔

서버 주소는 랩 대역의 사설 주소라 WARP 밖에서는 이름을 알아도 열리지 않습니다 — 주소 링크는 WARP 에 연결된 단말(화면 보기) 브라우저에서 누르십시오. 웹에서 막히면 안내판의 «막혔습니다» 화면으로 넘어가고, 막은 정책·허용 정책·로그 링크가 함께 뜹니다.

순서종류Gateway 정책(랩 계정)동작대상
5100DNS메신저(카카오톡) 차단 — 그룹 IT 예외차단그룹 IT 외 5개 소속
5101DNSChatGPT 차단 — any(app.ids[*] in {1199 1862})차단6개 소속
5105L4ChatGPT 차단(네트워크) — 같은 조건차단6개 소속(전체 터널 단말에서 실효)
5110L4SSH(22) — 그룹 IT 만 허용허용그룹 IT
5120L4랩 서버 웹(80) — 페르소나 통과(소속 판정은 HTTP)허용6개 소속
5190L4All Block — 랩 대역의 나머지 전부차단전원
5200~5205HTTP서버별 허용 소속(위 표) · ERP 는 단말 조건 미충족을 먼저 차단(5201)허용서버마다
5280HTTP랩 안내판 — 전 소속 허용허용6개 소속
5290HTTP랩 서버 — 권한 없는 소속 차단(안내판 차단 화면으로)차단나머지
단말 조건기준
Windows OS 버전≥ 10.0.19045 (Server 2022 = 10.0.20348 통과)
Windows 방화벽켜짐
Android OS 버전≥ 13.0.0 (에뮬레이터 14 통과 — 15 로 올리면 막힘)
DLP·격리(데모 계정 B, HTTP)동작
G0 시험 사용자 목록 밖 전원검사 안 함 — 공용 계정 보호
G1 시험 사용자 · 앱 분류 Do Not Inspect(16)검사 안 함 — 인증서 고정 앱
G2 시험 사용자 · ChatGPT(1199)격리 — 붙여넣기·복사는 격리 안에서만, 업로드·다운로드·인쇄 차단
G3 시험 사용자 · DLP 프로필(주민번호·핸드폰 번호·PII·자격증명)차단
🔴 Windows 백신(Security Center) 조건은 없습니다 — 랩 단말이 Windows Server 라 Security Center 가 없습니다. 실제 PC(Windows 10·11)에서 따로 봅니다. 데모 계정 B 의 TLS 복호화는 계정 전체 설정이라, G0 을 먼저 만들고 나서 켰습니다(M22 함정 ①②).

대시보드 화면 — 어디서 설정하나

아래 링크는 계정 자리를 비운 딥링크입니다. 열면 «Select an account to continue» 가 먼저 뜨고, 본인 계정을 고르면 그 화면으로 바로 갑니다. 화면은 우리 랩 계정에서 2026-10-15 에 찍었고, 계정 이름과 랩과 무관한 항목은 가렸습니다. 그림을 누르면 원본 크기로 열립니다.

DNS 정책 목록 — 카카오톡 차단, ChatGPT 차단
DNS 정책 — 카카오톡 차단(그룹 IT 예외) · ChatGPT 차단(전 소속). 복호화 없이 이름 조회 단계에서 끊습니다.
Traffic controls › Firewall policies › DNS · 딥링크(내 계정) ↗
ChatGPT 차단 정책 편집 화면 — Application in ChatGPT, User Email in list
ChatGPT 차단 정책 안 — Traffic: Application in ChatGPT · Identity: User Email in list «전체 페르소나» → Block. 사람은 목록에만 넣고 정책은 목록만 봅니다.
정책 목록에서 이름을 누르고 Edit · 딥링크(내 계정) ↗
Network 정책 목록
Network(L4) 정책 — ChatGPT 차단 · SSH 22 는 그룹 IT 만 · 랩 웹 80 통과 · 랩 대역 나머지 차단(All Block). 위에서 처음 맞는 정책에서 멈춥니다.
Traffic controls › Firewall policies › Network · 딥링크(내 계정) ↗
HTTP 정책 목록
HTTP 정책 — 서버마다 허용 소속, ERP 는 단말 조건 미충족을 먼저 차단, 끝에서 권한 없는 소속 차단. 랩 서버는 평문 HTTP 라 TLS 복호화 없이 걸립니다(노란 안내는 HTTPS 이야기).
Traffic controls › Firewall policies › HTTP · 딥링크(내 계정) ↗
단말 프로필 목록 — 전체 터널, 업무 대역만, Default
단말 프로필 — 본사·그룹 IT = 전체 터널(Split Tunnels Exclude) · 협력사·고객사 = 업무 대역만(Include) · 나머지 = Default. 어느 프로필을 받았는지는 «Your devices» 탭에서 봅니다.
Team & Resources › Devices › Device profiles · 딥링크(내 계정) ↗
단말 조건 목록 — Android OS 버전, Windows 방화벽, Windows OS 버전
단말 조건(posture) — Android OS 버전(≥13) · Windows 방화벽 켜짐 · Windows OS 버전(≥10.0.19045). ERP 정책이 이 결과를 봅니다.
Reusable components › Posture checks · 딥링크(내 계정) ↗
목록 — 소속별 이메일 목록과 서버 IP 목록
목록(Lists) — 소속별 이메일 목록(User Emails) 6 + 전체 페르소나 1 · 서버별 IP 목록 5. 사람·서버를 더할 때는 여기만 고칩니다.
Reusable components › Lists · 딥링크(내 계정) ↗
데모 계정 B HTTP 정책 — G0~G3
DLP·격리 정책(데모 계정 B) — G0·G1 Do not inspect → G2 Isolate → G3 Block. Do not inspect 는 목록 순서와 상관없이 가장 먼저 평가됩니다.
Traffic controls › Firewall policies › HTTP · 딥링크(내 계정) ↗
격리 정책 편집 화면 — Isolation settings
G2 격리 정책 안 — Application in ChatGPT + 시험 사용자 목록 → Isolate. Isolation settings: 복사·붙여넣기 «격리 브라우저 안에서만», 키보드 허용, 인쇄·다운로드·업로드 «Do not allow».
정책 이름 → Edit · 딥링크(내 계정) ↗
DLP 차단 정책 편집 화면 — DLP Profile in
G3 DLP 정책 안 — DLP Profile in Credentials and Secrets · PII Record · 주민번호 · 핸드폰 번호 + 시험 사용자 목록 → Block. 걸린 값을 남기려면 «Log the payload of matched rule» 을 켭니다(암호화 키 필요).
정책 이름 → Edit · DLP 프로필은 Data loss prevention › Profiles · 딥링크(내 계정) ↗
그 밖에 여는 곳메뉴딥링크
TLS 복호화 켜기(DLP·격리·HTTPS 검사의 전제)Traffic controls › Traffic settings열기 ↗
단말이 어느 프로필·어느 계정으로 붙었나Team & Resources › Devices › Your devices열기 ↗
시험 결과(DNS·Network·HTTP 로그)Insights & Logs › Logs열기 ↗
로그인 기록Insights & Logs › Access authentication logs열기 ↗

내 계정에 템플릿 열기 — 눌러도 저장되지 않습니다

버튼을 누르면 계정 선택 → «Create new firewall policy» 양식이 이 값으로 채워진 채 열립니다. «Create policy» 를 누르기 전까지는 아무것도 저장되지 않습니다. 사람·서버 값은 예시(user1@example.com, 192.0.2.10)이니 본인 값으로 바꾼 뒤 저장하십시오. 우리 랩 계정에서 종류별로 열어 채워지는 것을 확인했습니다(2026-10-15).

종류템플릿채워지는 값바꿀 것열기
DNS메신저(카카오톡) 차단Application in Kakao Talk · User Email in 예시 2명 → Block사용자 이메일(또는 «User Email in list» 로 바꿔 목록 선택). 예외 소속이 있으면 그 사람을 빼거나 «not in list»템플릿 열기 ↗
DNSChatGPT 차단(이름 조회 단계)Application in ChatGPT · User Email → Block사용자 이메일템플릿 열기 ↗
NetworkChatGPT 차단(앱이 IP 로 바로 붙는 경우까지)Application in ChatGPT · User Email → Block사용자 이메일. 단말이 전체 터널일 때 실효템플릿 열기 ↗
NetworkSSH 22 — 지정 사용자만Destination IP 192.0.2.10 And Destination Port 22 · User Email → Allow서버 IP(192.0.2.10 은 예시)와 사용자템플릿 열기 ↗
Network내부 사설 대역 — 나머지 차단Destination IP in 10/8 · 172.16/12 · 192.168/16 → Block내 사설 대역. 허용 정책들보다 아래에 둡니다템플릿 열기 ↗
HTTP업무 서버 — 지정 사용자만 허용Destination IP 192.0.2.10 · User Email → Allow서버 IP 와 사용자. 끝에 «권한 없는 사람 차단» 을 따로 둡니다템플릿 열기 ↗
HTTPChatGPT — 격리 브라우저Application in ChatGPT · User Email → Isolate격리 권한(유료 애드온)이 있는 계정만 «Isolate» 가 채워집니다. 붙여넣기·업로드·다운로드·인쇄는 오른쪽 Isolation settings 에서 직접 고릅니다(기본 Allow)템플릿 열기 ↗
HTTP민감정보 전송 차단(DLP)DLP Profile in Financial Information · Social Security, Insurance, Tax, and Identifier Numbers · User Email → Block기본 제공 프로필 2개(모든 계정에 있음). 주민번호처럼 나라별 형식은 DLP › Profiles 에서 사용자 정의 프로필을 만들어 추가. TLS 복호화 필요템플릿 열기 ↗
💡 동작 이름은 화면 표기 그대로 채워집니다. 단말 조건(posture)·목록(Lists)은 계정마다 ID 가 달라 템플릿에 넣지 않았습니다 — 양식에서 «+ Add condition» 으로 고르십시오. 대시보드 정책 메뉴의 «Duplicate» 는 양식이 아니라 복제본을 바로 만듭니다 — 시험 삼아 누르지 마십시오.

③ 접속·시험 순서

시나리오별 — 어디서, 어떤 계정으로 들어가면, 무엇이 열리고 막히나. 계정 이메일·비밀번호는 팀 내부에서 보관합니다(<본사 계정> 처럼 가렸습니다). 막히면 무엇이 막았는지 안내판 차단 화면과 로그로 확인합니다.

#시나리오어디서(단말)어떤 계정으로 · 로그인받는 프로필열리는 것막히는 것상태
S1본사 임직원Windows 또는 Android 단말<본사 계정> · «사내 AD FS (랩)» SAML + 인증 앱 6자리본사형 — 전체 터널안내판 · 운영 · ERP(단말 조건 충족 시) · 협력사 포털 · 고객사 X·Y 포털SSH 22 · 카카오톡 · ChatGPT미시험
S2그룹 IT 총괄Windows 또는 Android<그룹 IT 계정> · «사내 AD FS (랩)» SAML + 6자리본사형 — 전체 터널S1 전부 + SSH 22 + 카카오톡(예외)ChatGPT미시험
S3협력사 A (조업)Windows<협력사 A 계정> · «협력사 IdP (랩)» OIDC외부형 — 랩 대역만안내판 · 운영 · 협력사 포털ERP · 고객사 X·Y · SSH 22 · 카카오톡 · ChatGPT(DNS 는 Gateway 경유)확인 10-14·15
S4협력사 B (정비)Windows 또는 Android<협력사 B 계정> · «협력사 IdP (랩)» OIDC외부형안내판 · 협력사 포털운영 · ERP · 고객사 X·Y · SSH · 카카오톡 · ChatGPT미시험
S5고객 항공사 XWindows 또는 Android<고객 X 계정> · «협력사 IdP (랩)» OIDC외부형안내판 · 고객사 X 포털운영 · ERP · 협력사 포털 · 고객사 Y · SSH · 카카오톡 · ChatGPT미시험
S6고객 항공사 YWindows 또는 Android<고객 Y 계정> · «협력사 IdP (랩)» OIDC외부형안내판 · 고객사 Y 포털운영 · ERP · 협력사 포털 · 고객사 X · SSH · 카카오톡 · ChatGPT미시험
S7단말 조건 미충족Windows — 방화벽을 끈 뒤S1 또는 S2 계정본사형ERP 외 나머지는 S1·S2 와 같음ERP — «보안 기준 미충족» 차단 화면(새 세션으로 시험)미시험
S8Android OS 기준Android(에뮬레이터 14)S1~S6 아무 계정소속대로기준 ≥13 이면 소속대로기준을 15 로 올리면 단말 조건이 걸린 ERP 가 막힘미시험
S9페르소나가 아닌 계정아무 단말랩 사용자 목록에 없는 계정(예: 회사 계정)Default인터넷은 그대로(랩 정책 대상 아님)랩 서버 전부(All Block · 권한 없는 소속 차단)지금 Android 상태
S10DLP·격리 시험 사용자아무 브라우저(클라이언트 없이) 또는 WARP 단말 + 루트 인증서데모 계정 B 의 <시험 사용자>—ChatGPT 는 격리 화면으로 열림(보기·입력)붙여넣기 · 파일 올리기 · 다운로드 · 인쇄 · 민감정보 전송단말 시험 전
S11DLP·격리 시험 사용자가 아닌 사람데모 계정 B 에 붙은 아무 단말시험 사용자 목록 밖—모두 그대로 — 검사·격리하지 않음(G0)—정책 확인
A. Windows 단말
  1. 팀 전용 화면 보기 주소 <Windows 화면 주소> → 팀 로그인 → VNC 비밀번호(팀 내부 보관).
  2. 작업 표시줄의 Cloudflare One Client 를 엽니다. 다른 소속을 보려면 설정 › 계정에서 로그아웃합니다.
  3. 로그인 → 팀 이름 mzccfteam → 소속 버튼(위 표) → 페르소나 계정. 본사·그룹 IT 는 인증 앱 6자리.
  4. Connected 가 되면 단말 브라우저로 http://why.ghlab.nxlab.cflare.kr ↗(정답표·정책 링크 모음)부터 엽니다.
B. Android 단말
  1. 팀 전용 화면 보기 주소 <Android 화면 주소> → 팀 로그인.
  2. 홈의 Cloudflare One 앱 → Next → 개인정보 처리 안내 동의.
  3. 팀 이름 mzccfteam → 페르소나 로그인 → VPN 연결 허용.
  4. Chrome 으로 위 표의 주소를 엽니다.
C. 무엇을 확인하나
  1. 웹 — 표대로 «접속에 성공했습니다» / «막혔습니다».
  2. SSH — Test-NetConnection ops.ghlab.nxlab.cflare.kr -Port 22 : 그룹 IT 만 열림.
  3. 앱 차단 — nslookup kakao.com · nslookup chatgpt.com → 162.159.36.12(Gateway 차단 응답)이면 막힌 것. 앱은 실행되지만 서버에 붙지 못합니다.
  4. ERP 단말 조건 — 방화벽을 끄고 새 세션으로 ERP 를 엽니다(이미 열린 연결은 안 끊깁니다).
D. DLP·격리(데모 계정 B)
  1. 클라이언트 없이: https://<팀이름>.cloudflareaccess.com/browser/https://chatgpt.com → 시험 사용자로 로그인 → 붙여넣기·파일 올리기가 막히는지.
  2. WARP 단말: 시험 사용자로 로그인 + Cloudflare 루트 인증서 설치 → https://chatgpt.com 이 격리 화면으로 열리는지.
  3. DLP: 가짜 주민번호 형식 값을 보내면 막혀야 합니다 — curl -X POST https://httpbin.org/post -d "jumin=900101-1234567"
  4. 결과는 Insights › Logs › HTTP request logs 에서 정책 이름으로 거릅니다.

④ 확인한 결과

시험결과상태
협력사 A — 웹 접근 전체(Windows)안내판·운영·협력사 포털 열림 / ERP·고객사 X·Y 는 안내판 차단 화면 — 정답표와 일치확인 10-14
협력사 A — SSH 22배너 0바이트(같은 서버 80 은 200) — 차단확인 10-14
협력사 A — 카카오톡kakao.com → 162.159.36.12확인 10-14
협력사 A — ChatGPTchatgpt.com·openai.com → 162.159.36.12, 대조군 example.com 정상. 외부형(랩 대역만 터널)이어도 DNS 는 Gateway 를 거쳐 막힘확인 10-15
나머지 5개 소속A 순서대로 로그아웃 → 다른 페르소나로 로그인미시험
Android앱이 랩 계정에 연결돼 있지만 페르소나가 아닌 계정으로 로그인돼 Default 프로필을 받고 있습니다(Your devices 화면 확인) — 페르소나 목록 밖이라 랩 정책이 걸리지 않습니다. 앱에서 로그아웃 → 페르소나로 다시 로그인해야 시험이 됩니다재로그인 필요
DLP · 격리(데모 계정 B)정책 적용·TLS 복호화 켜기까지 확인(설정 전후 비교 — 다른 설정 값은 그대로)단말 시험 전
문서: Traffic policies · Split Tunnels · Posture checks · Remote browser isolation · DLP

현장에서 꼭 나오는 질문 4가지 — 단말 수 · 2차 인증 · 세션과 재부팅 · One 과 WARP 의 차이 공식 문서 2026-09-09 재확인 + Demo2 실측

Q1사용자당 단말 수를 제한할 수 있나 (Device limit)
없습니다. Device registration 문서에 상한·자동 만료 항목이 없습니다. 등록은 관리자가 지우기 전까지 누적되고, 지워도 그 단말에서 다시 인증하면 새 등록이 생깁니다(「Deleting one registration does not affect other registrations on the same device」). 자동 정리는 사용자 단위뿐 — Settings › Admin controls › Remove inactive users from seats(1개월~1년, 매일 검사, 인증 이벤트와 단말 Last seen 둘 다 없을 때). 활성 사용자에게 쌓인 옛 단말은 API(GET/DELETE /devices)로 스크립트 정리 — dry-run 부터. 문서: Device registration · Seat management
Q22차 인증은 어떻게 접속하고, 안 될 땐 어떻게 하나
위 두 카드가 그 답입니다 — 등록은 <team>.cloudflareaccess.com/AddMfaDevice, 로그인 때 IdP 뒤에 6자리. 안 될 때 1순위 원인은 App Launcher 가 꺼진 것(등록 화면이 그 안에 있습니다 — Demo2 실측). 2순위는 휴대폰 분실·교체 → 관리자가 Users › 사용자 › MFA devices › Delete → 다음 접속에 재등록. 복구 코드는 없고, 수단 2개 이상 등록이 예방책. 공용 계정은 같은 QR 을 여러 휴대폰에 등록. 문서: Independent MFA
Cloudflare One Client authentication 설정
Q3WARP 를 켜 두면 세션이 얼마나 가나 · 재부팅하면 강제로 끊을 수 있나
Access controls › Access settings › (맨 아래) Cloudflare One Client authentication › Session duration
단말(WARP) 세션은 여기서 정합니다 — Demo2 기본 8 hours, 화면 안내 「36시간을 넘기지 말 것」. IdP 재인증 시점부터 고정으로 흐르고 사용 중이라고 연장되지 않습니다. 앱에 「Authenticate with Cloudflare One Client」가 켜져 있으면 이 값이 앱·정책·전역 세션을 전부 이깁니다 — 「24시간 지났는데 안 묻습니다」의 원인이 대개 이것. 만료되면 다음 접속에 IdP 재로그인, 이미 열린 SSH/RDP 는 안 끊깁니다.
재부팅 강제 로그오프 기능은 없습니다(2026-09-09 재확인). 가장 가까운 조합 셋: ① 단말 세션을 근무 주기보다 짧게(8~10h) ② MFA 지속시간 「Require every login」 ③ Windows MDM no_auth_no_internet(WARP 2026.5.0+, 2026-05 신설) — 미인증 상태면 부팅 직후부터 인터넷을 막고 인증해야 풉니다. 단 「매 부팅마다 인증」이 아니라 「미인증이면 차단」이라 세션이 살아 있으면 재부팅해도 안 묻습니다 → ①과 묶어야 「부팅 = 로그인」에 근접. 제약: Windows 전용 · 인증 창이 WebView2 라 기본 브라우저 의존 IdP 는 실패 가능. 문서: Session management · Client sessions · no_auth_no_internet
Q4Cloudflare One 하고 WARP 는 뭐가 다른가 · WARP 는 없어지나
층이 다릅니다. Cloudflare One 은 제품군 전체를 부르는 우산 이름(Access·Gateway·DLP·Tunnel…)이고, WARP 는 그중 단말에 까는 프로그램 하나입니다 — 트래픽을 Cloudflare 로 끌어오는 진입로 역할이라, 같은 자리에 Tunnel·GRE·IPsec 도 들어옵니다.
없어지지 않습니다 — 이름만 One 쪽으로 합쳐졌습니다. 데스크톱은 Cloudflare One Client(공식 문서 표기 「formerly WARP」), 모바일은 Cloudflare One Agent(옛 1.1.1.1 앱을 대체). 기능·요금은 그대로입니다.
🔴 속은 아직 전부 warp 입니다 — cloudflare-warp, service_mode: warp 같은 설치·배포 값을 새 이름으로 치환하면 깨집니다. 문서: 클라이언트 내려받기
세션 4층(단말 › 정책 › 앱 › 전역)은 「활동으로 연장」이 아니라 「인증 시점부터 고정 만료」입니다 — 규정에 맞추려면 단말 세션과 전역 세션 두 값을 줄입니다.

실습용 IdP 는 어떻게 만들었나「진짜인가 흉내인가」에 답합니다

로그인 화면에 실습용 IdP (a) · 발급자 https://idp.nxlab.cflare.kr/a 라고만 뜨면, 보는 사람은 이게 진짜 OIDC 인지 화면만 흉내 낸 것인지 알 수 없습니다. 답부터 드리면 — 표준 그대로입니다. Cloudflare Access 가 이 서버의 서명을 실제로 검증하고, 통과해야 로그인이 됩니다. 아래는 무엇으로 어떻게 만들었는지입니다.
직원 브라우저실습 앱에 들어가려는 사람 Cloudflare Access문지기 실습용 IdPidp.nxlab.cflare.kr/a ① 실습 앱에 접속합니다 ② 이 IdP 는 무엇을 지원하나 — /a/.well-known/openid-configuration ③ 「저 IdP 로 가세요」 (302) → /a/authorize ④ 「누구로 로그인할지」 고릅니다 (랩이라 비밀번호를 묻지 않습니다) ⑤ 2단계 — /a/mfa 6자리 숫자 · 지문 · 보안키 (RFC 6238 · WebAuthn 실제 구현) ⑥ 한 번 쓰고 버리는 코드를 들고 돌아옵니다 ⑦ 이 코드를 토큰으로 바꿔 주세요 — /a/token ⑧ RS256 으로 서명한 id_token ⑨ 서명을 맞춰 볼 공개키 — /a/jwks (②에서 읽은 주소 · 보통 미리 받아 둡니다) 🔴 여기서 서명을 실제로 검증합니다 ⑩ 통과 — 앱으로. JWT 안에 amr(2단계를 거쳤나)
1「진짜 OIDC 인가」의 답은 ⑧⑨⑩ 세 칸에 있습니다. 화면만 흉내 낸 서버라면 ⑧에서 서명을 만들지 못합니다. Access 는 ⑨로 가져온 공개키로 그 서명을 맞춰 보고, 맞지 않으면 로그인을 시키지 않습니다 — 우리가 통과시키는 것이 아니라 Cloudflare 가 검사해서 통과시키는 것입니다.
Access 에 등록된 IdP — 서로 다른 회사로 보입니다 메가존 사내 IdP (랩) · OIDC 협력사 IdP (랩) · OIDC 레거시 SAML IdP (랩) · SAML 2.0 /a /b /saml 프로세스 하나 Node 기본 모듈만 · 설치한 것 0개 127.0.0.1:8093 에서만 듣습니다 경로가 다르면 다른 IdP 입니다 발급자·키·사용자 목록이 각각 따로입니다
2IdP 를 셋 세운 이유는 ⑤ 절 때문입니다. 로그인 화면이 갈리는 것을 보려면 「IdP 가 여럿인 상태」가 필요한데, 정작 필요한 것은 그 상태이지 특정 벤더가 아니었습니다. 그래서 t3.micro 한 대에 프로세스 하나로 그 상태를 만들었습니다.

왜 Keycloak 을 안 쓰고 직접 만들었나

랩 EC2 는 t3.micro(총 913MB · 여유 438MB)이고, 그 위에서 WAF 실습장 오리진과 러너 다섯이 이미 돌고 있습니다. Keycloak·Authentik 은 그것들을 내려야 올라갑니다 — 실습장을 세우려고 실습장을 끄는 셈입니다. 그리고 필요한 것은 「IdP 가 여럿입니다」라는 상태이지 특정 벤더가 아니었습니다. 그래서 의존성 0 · 프로세스 1개짜리 서버를 Node 기본 모듈만으로 짰습니다.

한 프로세스가 IdP 셋인 척합니다 — 경로로 갈립니다

경로프로토콜Access 에는 이렇게 보입니다
/aOIDC메가존 사내 IdP (랩)
/bOIDC협력사 IdP (랩)
/samlSAML 2.0레거시 SAML IdP (랩)

Access 에는 완전히 별개의 IdP 셋으로 등록돼 있습니다. 그래야 로그인 화면에 버튼이 여러 개 생기고, ⑤ 절에서 보는 「화면이 왜 다른가」가 성립합니다.

표준을 실제로 구현한 것

엔드포인트무엇을 하나
/a/.well-known/openid-configurationOIDC discovery — Access 가 여기부터 읽습니다
/a/jwks공개키. Access 가 id_token 서명을 검증하는 근거
/a/authorize「누구로 로그인할지」 고르는 화면 · authorization code 발급
/a/mfa2단계 — TOTP 또는 지문·보안키
/a/tokencode → RS256 서명 id_token 교환
/a/userinfo토큰으로 신원 조회
/saml/metadata · /saml/ssoSAML 2.0 — HTTP-Redirect 로 요청 받고, 서명한 Assertion 을 HTTP-POST 로 ACS 에 보냅니다
/zt실습 앱 오리진. Access JWT 를 서버에서 풀어 어느 IdP · amr · MFA 여부를 사람이 읽게 보여 줍니다
/signup · /whoami · /health실습 계정 만들기 · 지금 누구인지 · 살아 있나

2단계 인증은 흉내가 아닙니다

처음에는 「여섯 자리면 통과」 였습니다. 그건 2단계를 배우는 데 아무 쓸모가 없어서 걷어냈습니다. 지금은 RFC 6238 그대로입니다 — 사용자마다 비밀키를 만들어 otpauth:// QR 로 인증 앱(Google·Microsoft Authenticator)에 등록하고, HMAC-SHA1 · 30초 창으로 검증하며, 같은 코드는 두 번 받지 않습니다. 등록은 파일에 남아 서버를 다시 켜도 유지됩니다.

지문 · 얼굴 · 보안키(WebAuthn)도 실제로 됩니다 — Windows Hello · Touch ID · USB 보안키. 실제 AD FS 가 Windows Hello 를 지원하므로, 랩이 AD FS 를 흉내 내려면 이게 있어야 맞기 때문입니다.

🔴 이메일 코드·푸시 승인 흉내는 지웠습니다. 진짜가 아닌 것은 화면에 두지 않습니다 — 그게 이 실습장의 규칙입니다.

🔴 이 서버는 랩 전용입니다 — 비밀번호를 묻지 않습니다. 「누구로 로그인할지」를 버튼으로 고릅니다. 사람을 인증하는 것이 목적이 아니라, Access 로그인 화면이 설정에 따라 어떻게 달라지는지를 보는 것이 목적이기 때문입니다. 그래서 이 서버는 실습 네트워크 밖으로 나가면 안 됩니다 — Cloudflare 프록시 뒤, 랩 존 안, 127.0.0.1:8093 로만 듣습니다. 회사 계정·고객 계정과는 완전히 다른 계정이고, 여기서 만든 신원으로는 실습 앱 말고는 아무 데도 못 들어갑니다.
서버는 의존성 0 · 한 프로세스짜리 Node 입니다 · 호스트 idp.nxlab.cflare.kr (우리 랩 EC2)

같은 계정 · 같은 사람인데, 앱 설정만 다르면 로그인 화면이 달라집니다 2026-09-08 실측

아래 넷은 같은 Cloudflare 계정의 앱이고 정책도 같습니다(사내 도메인 허용). 다른 것은 허용 IdP 조합과 Access MFA 여부뿐입니다. 눌러 보면 화면이 어떻게 갈리는지 바로 보입니다 — IdP 는 실습용이라 비밀번호를 묻지 않고 「누구로 로그인할지」를 고릅니다.
직원 Access 문지기 앱 설정을 보고「무슨 버튼을 보여 줄지」결정합니다 허용 IdP 목록 · 자동 이동 · MFA A IdP 1개 → 화면 없이 회사 로그인으로 바로 이동 B IdP 2개 → 버튼 두 개 「어디로 로그인할까요」 C IdP 3개 + 이메일 코드 → 버튼 셋 + 이메일 입력칸
같은 문지기인데 앱 설정에 따라 첫 화면이 셋으로 갈립니다. 아래 표의 링크를 눌러 A·B·C 를 실제로 비교해 봅니다. 로그인이 끝나면 통과 화면이 뜨는데, 거기 amr 값이 「2단계를 진짜로 거쳤나」의 유일한 증거입니다.

🔵 IdP 가 셋이라 계정도 셋처럼 보이지만 하나입니다 — 한 번 가입하면 A·B·C 어디서나 같은 이메일·비밀번호로 들어갑니다. 무엇이 어디에 저장되는지는 ② 직접 해보기 절의 「어느 실습이 어느 IdP 로 가나」 ↓ 에 표로 정리해 두었습니다.

앱허용 IdP로그인 화면에서 벌어지는 일
실습 A ↗
실습 계정 mzccfteam
사내 IdP 하나 MFA 필수 선택 화면이 아예 안 나옵니다. Access 가 곧바로 그 IdP 로 넘깁니다 (앱 설정 auto_redirect_to_identity). 사용자는 Cloudflare 화면을 못 봅니다.
실습 B ↗
실습 계정 mzccfteam
협력사 IdP + SAML IdP 버튼 두 개짜리 선택 화면. 버튼 글씨는 「프로토콜 · IdP 표시명」 입니다 — 즉 IdP 이름을 지은 그대로 고객 눈에 보입니다.
실습 C ↗
실습 계정 mzccfteam
셋 전부 + One-time PIN 버튼 셋 + 「or」 + 이메일 입력칸. One-time PIN 도 IdP 하나로 취급되므로 허용 목록에 그 id 를 넣어야 이 칸이 생깁니다(안 넣으면 버튼만 셋).

IdP 가 거는 2단계는 어디서 갈리나

위 카드의 B 이야기입니다(Access 가 직접 거는 것은 그림 2 의 A). IdP 가 걸면 같은 앱이라도 어느 IdP 로 들어왔느냐에 따라 2단계가 강제되기도, 건너뛰어지기도 합니다. 랩 IdP 는 셋의 정책을 일부러 다르게 두었습니다. 셋 다 진짜 TOTP(QR 등록 · HMAC 검증)입니다:
  • 필수
    메가존 사내 IdP
    사용자 선택 뒤 반드시 인증 앱 코드. 처음이면 QR 등록부터.
  • 선택
    협력사 IdP
    같은 화면이지만 「2단계 없이 진행」을 고를 수 있습니다.
  • 선택
    레거시 SAML IdP
    같은 화면. 통과 여부가 AuthnContextClassRef 로 나갑니다.

그래서 오리진은 무엇을 받나 — 실측

Access JWT 의 custom 클레임 (zt-a 로그인, 사내 IdP + TOTP 통과) {"groups":["se","admin"],"amr":["pwd","otp","mfa"],"acr":"urn:cloudflare:lab:mfa"}
IdP 가 「어떻게 인증했는지」(amr)가 Access 를 지나 오리진까지 그대로 옵니다. Access 정책의 「인증 방식(Authentication Method)」 규칙이 보는 값이 이것이고, SAML 쪽에서는 AuthnContextClassRef 가 같은 자리를 맡습니다. 2단계를 건너뛴 토큰에는 ["pwd"] 만 실립니다 — 정책으로 가르는 근거가 됩니다.

2단계를 건너뛰면 토큰이 달라집니다 — 나란히 비교

어떻게 들어왔나오리진이 받은 값
사내 IdP · TOTP 통과 amr: ["pwd","otp","mfa"] · acr: …:mfa
협력사 IdP · 「2단계 없이 진행」 amr: ["pwd"] · acr: …:pwd — 같은 앱·같은 정책인데 값이 다릅니다
SAML IdP · 2단계 통과 groups 와 mfa: "true" 가 어서션 속성 그대로 넘어옵니다
여기가 정책이 붙는 자리입니다. 「MFA 를 거친 사람만」이라는 규칙은 Access 가 이 값을 보고 판정합니다 — IdP 를 믿는 것이 아니라 IdP 가 「어떻게 인증했습니다」고 말한 내용을 보는 것입니다.

SAML 을 직접 붙일 때 밟는 함정

해결
서명 대상 XML 에 빈 태그(<x/>)를 쓰면 검증이 깨집니다
exclusive c14n 의 정규형은 <x></x> 라, 자기닫힘으로 서명해 두면 검증하는 쪽 다이제스트와 어긋납니다. Access 는 그 실패를 Failed to fetch user/group information from the identity provider 라는 「사용자 정보를 못 읽었습니다」 문구로 보여 줘서 원인이 서명이라는 것이 드러나지 않습니다. 2026-09-08 이 랩에서 그대로 겪었고, 빈 태그를 짝 태그로 바꾸자 바로 통과했습니다.
IdP 서버: idp.nxlab.cflare.kr · 랩 EC2 · 실습 뒤 회수 대상
사례 실제 문의에서 나온 것 4건 — 제목을 누르면 창으로 열립니다

WARP 진단 묶음 받기

WARP 클라이언트 점검

고객 현장과 실습 서버에서 WARP 를 쓰다 겪은 장애와 주요 기능을 세 OS 실습 PC 에서 직접 다시 해 본 기록입니다. 판정 색은 왼쪽 목록의 묶음 머리를 보십시오.

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Waiting Room 화면. 웨이팅 룸 한 개(상태 Not queueing, Enabled), Create 단추, SEO Crawler Bypassing
도메인 › Traffic › Waiting Room웨이팅 룸 목록과 만들기 단추, 검색 로봇을 줄 세우지 않는 SEO Crawler Bypassing 설정이 있습니다.

① 웨이팅 룸을 설계합니다 줄을 세워 오리진을 지킵니다 — 막는 게 아니라 「흘려보내는」 기능입니다

② 이렇게 흐릅니다 동시 접속이 몰렸을 때 몇 명이 줄을 서고 얼마나 기다리나

왼쪽 값을 정하고 대기열 계산을 누르면, 몇 명이 바로 들어가고 몇 명이 얼마나 기다리는지 나옵니다.

③ 진짜 웨이팅 룸에 들어가 봅니다 계산이 아니라 실제 Cloudflare 대기열입니다

「지금 확인」을 누르면 실제로 쏴 봅니다.

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Edge Certificates 화면의 HSTS(Enable HSTS)와 Minimum TLS Version(TLS 1.2 선택)
도메인 › SSL/TLS › Edge Certificates방문자 쪽 인증서 설정 화면입니다. HSTS 와 최소 TLS 버전도 여기서 정합니다.

사례 인증서 갱신 안내 메일이 몇 주째 반복해서 옵니다실제로 1번 겪은 일 · 가장 최근 2026-09-13 · 마지막 수정 2026-10-15

이렇게 보입니다「조치 필요: 도메인을 검증하세요」 메일이 같은 도메인으로 계속 오고 간격이 하루로 좁아지기도 합니다. 서비스는 멀쩡해 보여도 만료일이 지나면 방문자가 연결하지 못합니다.

왜 그런가요CNAME 방식(부분 설정) 도메인은 권한 DNS 가 다른 곳에 있어 Cloudflare 가 검증 레코드를 대신 넣지 못합니다. 갱신마다 사람이 TXT 를 등록해야 해서, 한 번 밀리면 만료까지 밀립니다. 도메인이 이미 Cloudflare 로 향하지 않아도 같은 메일이 오는데, 이때는 권한 DNS 가 응답하지 않아 TXT 를 넣는 것 자체가 불가능합니다. 메일 본문이 그 사유를 세 가지 중 하나로 알려 줍니다.

이렇게 합니다반복을 끊는 방법은 둘입니다. ① 위임 DCV: 일회성 CNAME 을 한 번 넣으면 이후 갱신은 Cloudflare 가 검증 레코드를 배치합니다. 부분 설정을 유지할 때 씁니다. ② 전체 설정 전환: 네임서버를 옮기면 검증이 완전히 자동입니다. 어느 쪽인지는 짐작하지 말고 도메인 상태 조회에서 설정 종류와 권한 네임서버로 확인합니다. 「네임서버를 옮겼다」고 알아도 부분 설정으로 남은 경우가 있습니다. 토큰은 재발송마다 바뀔 수 있으니 등록 직전 최신 메일의 값을 씁니다. 바뀌는 때는 인증서 묶음이 새로 발급될 때라, 며칠째 같은 값도 정상입니다.

여기서 해 보기 — 쓰지 않는 도메인을 일시정지하거나 요금제를 낮춰도 메일은 계속 옵니다. 도메인이 계정에 남으면 인증서도 남습니다. 「정리했는데 또 온다」면 삭제였는지 일시정지였는지부터 확인합니다.

공식 문서 — SSL — Delegated DCV · DNS — Full setup

사례 레코드를 넣었는데 도메인이 켜지지 않거나, 켜졌는데 인증서가 안 나옵니다실제로 3번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다새 도메인에 안내받은 레코드를 넣었는데 절반만 진행됩니다. 도메인이 계속 「대기」이거나, 활성인데 인증서가 며칠째 안 나옵니다.

왜 그런가요안내되는 레코드는 두 종류입니다. ① 소유 검증 TXT: 통과해야 도메인이 활성화됩니다. ② 인증서 검증용 CNAME: 통과해야 SSL 인증서가 나옵니다. 이름도 넣는 위치도 달라서 하나만 넣으면 나머지 절반이 조용히 멈추고, 오류 화면이 없어 「다 넣었다」고 믿기 쉽습니다. 여러 도메인을 한꺼번에 올릴 때 특히 샙니다. 도메인 3개면 6건인데, 표를 도메인 단위로 읽다 한 종류를 통째로 빠뜨립니다.

이렇게 합니다넣기 전에 건수(도메인 수 × 2)를 세십시오. 증상으로 빠진 쪽이 갈립니다. 활성화가 안 되면 TXT, 활성인데 인증서가 없으면 CNAME 입니다. 전환 예정일이 있으면 역산하십시오. 둘 다 DNS 전파를 기다리므로 전환 당일 아침에 넣으면 인증서 없이 전환되어 방문자에게 보안 경고가 뜹니다. 값은 도메인마다 달라 복사해 쓰면 통과하지 않습니다. 자동 안내를 「무시하라」고 들었다면 다시 물으십시오. 「넣지 않아도 된다」가 아니라 「지금은 넣지 말라」라면 언제 누가 넣을지 미정이고, 그대로 두면 전환 시각에 도메인이 대기로 들어갑니다. 요청서에 몇 종류를 적었는지도 점검하십시오. 상대는 받은 목록대로 넣으므로 한 종류만 적으면 완벽히 일하고도 절반만 끝낸 채 「등록 완료」로 회신합니다. 회신을 받으면 두 종류를 각각 조회하십시오. 상대 말이 아니라 조회가 답입니다.

여기서 해 보기 — 등록 뒤에는 도메인 상태와 인증서 상태를 따로 확인하십시오. 별개 절차라 한쪽만 보면 「다 됐다」로 오해합니다. 조회만으로 되며 설정을 바꿀 필요가 없습니다.

공식 문서 — SSL — Domain control validation · DNS — Zone setups

사례 검증 레코드는 전부 맞는데 인증서 갱신이 「검증 대기」에서 멈춰 있습니다실제로 1번 겪은 일 · 가장 최근 2026-09-17 · 마지막 수정 2026-10-15

이렇게 보입니다위임 DCV 를 걸었고 위임용 CNAME·TXT 값도 Cloudflare 게시 값과 같은데, 갱신이 며칠째 검증 대기입니다. 공개 DNS 조회는 될 때와 안 될 때가 섞이고, 될 때는 토큰까지 정상입니다.

왜 그런가요이름이 읽히지 않는 순간이 섞이면 검증은 실패합니다. 인증기관은 한 번 묻고, 그 한 번이 실패에 걸리면 갱신이 멈추며 재시도도 확률입니다. 그러니 「무엇이 틀렸나」가 아니라 「왜 읽히지 않나」를 찾습니다. 흔한 원인은 둘입니다. ① 권한 네임서버 일부만 존을 가짐: 그 대를 고른 조회만 거절되고, 두 대 중 한 대면 실패율이 대략 절반입니다. 리졸버는 「권한 있는 서버에 닿을 수 없다」는 확장 오류와 함께 거절한 주소를 알려 주는 경우가 많습니다. ② 맨 윗단(apex) CNAME: 맨 윗단은 NS·SOA 를 반드시 갖는데 CNAME 은 같은 이름의 다른 레코드와 공존할 수 없어 규격 위반입니다. 둘을 섞지 마십시오. 맨 윗단 CNAME 은 정리할 문제지만 이번 실패의 원인이라는 뜻은 아닙니다. 같은 네임서버에서 같은 모양의 맨 윗단 CNAME 을 가진 다른 이름이 멀쩡히 조회되는 경우가 실제로 있습니다.

이렇게 합니다① 실패율을 셉니다. 같은 질의를 10회 이상 반복해 절반쯤 실패하면 권한 서버 일부만 존을 가진 쪽, 매번 실패하면 이름 자체가 성립하지 않는 쪽입니다. ② 확장 오류 코드를 읽습니다. 거절한 서버 주소가 위임 네임서버 중 하나면 범인이 좁혀집니다. 코드 번호의 뜻은 짐작하지 마십시오. 번호와 이름은 RFC 8914 등록부에 정해져 있고, 전달받은 설명이 실제와 다른 경우가 있습니다. ③ 대조군을 만듭니다. 같은 네임서버의 다른 이름이 멀쩡하면 그 이름만의 문제입니다. 이 비교가 잘못된 원인 지목을 막습니다. ④ 권한 네임서버에 직접 묻습니다. 공개 리졸버는 어느 서버를 골랐는지 감춥니다. 서버마다 따로 질의하면 존이 없는 대가 드러나고 추론이 실측이 됩니다. ⑤ 그다음 고칩니다. 존이 없는 서버에 존을 올리는 것이 본 조치이고, 맨 윗단 CNAME 정리는 별건으로 함께 합니다. 맨 윗단으로도 트래픽을 받아야 하면 CNAME 대신 A 레코드를 씁니다.

여기서 해 보기 — 판정은 도구가 아니라 횟수와 대조군이 가릅니다. 한 번 실패로 원인을 정하지 말고, 열 번 반복해 비율을 보고 같은 네임서버의 다른 이름과 비교한 뒤, 위임된 서버마다 직접 물어보십시오.

공식 문서 — SSL — Delegated DCV · DNS — Zone apex and CNAME flattening · DNS — Troubleshooting SERVFAIL

사례 와일드카드 레코드를 넣었는데 일부 주소에서만 보안 경고가 뜹니다실제로 1번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다한 단계 아래 이름을 한꺼번에 받으려고 별표(와일드카드) DNS 레코드를 만들었습니다. 처음 만든 주소는 정상인데 나중에 쓰기 시작한 주소에서만 인증서 경고가 뜹니다. DNS 는 응답하고 있습니다.

왜 그런가요레코드가 와일드카드인 것과 인증서가 와일드카드인 것은 다릅니다. CNAME 방식(부분 설정)에서는 기본 인증서가 프록시된 호스트마다 발급되고, 서브도메인 깊이와 무관하게 자동 발급·갱신됩니다. 그래서 레코드를 만들어 프록시한 이름은 문제가 없습니다. 문제는 아직 레코드가 없는 이름입니다. 별표가 DNS 응답은 만들지만 프록시 호스트로 등록된 적이 없어 그 이름을 덮는 인증서가 없고, «연결은 되는데 인증서만 안 맞는» 모양이 됩니다. 이름이 고정된 소수인지 계속 늘어나는지를 묻지 않고 구성하면 필요 없는 인증서 상품을 사거나, 새 이름마다 사람이 손대는 구조가 됩니다.

이렇게 합니다먼저 그 아래 이름이 몇 개이고 늘어나는지 확정하십시오. ① 고정된 소수: 이름마다 레코드를 만들고 프록시를 켜면 기본 인증서가 자동으로 붙어 추가 구매가 필요 없습니다. ② 동적으로 늘어남: 별표를 덮는 상위 인증서 상품을 따로 발급하고, 부분 설정 존이면 위임 DCV 도 걸어 검증·갱신이 사람 손을 타지 않게 합니다. 별표는 맨 앞 한 레이블에만 유효하고, 정확한 이름의 레코드가 따로 있으면 그 레코드가 우선합니다. 「한 주소만 다르게 동작한다」면 대개 개별 레코드가 이미 있는 경우입니다.

여기서 해 보기 — 조회만으로 갈립니다. 문제 이름과 정상 이름을 각각 열어 어떤 이름이 적힌 인증서가 오는지 비교하십시오. 정상 쪽은 그 이름 전용, 문제 쪽은 그 이름이 없는 인증서가 옵니다.

공식 문서 — SSL — Universal SSL · SSL — Advanced Certificate Manager · DNS — CNAME setup (partial)

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Create Custom Token 화면. Token name, Permissions, Account Resources, Client IP Address Filtering, TTL
My Profile › API Tokens › Create Token › Custom token토큰은 필요한 권한·계정만 고르고, Client IP Address Filtering 과 TTL 로 쓸 곳과 기한을 좁힙니다.
Create an alert 화면. Abuse, Access 서비스 토큰 만료·유출, Bot management 탐지, Brand Protection 알림 목록과 Select 단추
계정 › Notifications › Create an alert만료·유출·공격 탐지 같은 알림을 제품별로 골라 받습니다.

사례 요청받은 이름으로 설정을 찾는데 아무 데도 없습니다실제로 2번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다「○○ 에 이 IP 를 추가해 주세요」처럼 이름 하나만 달린 요청이 옵니다. 도메인별 보안 룰과 허용 목록을 뒤져도 걸리는 것이 없어, 비슷한 것을 골라 손대고 싶어집니다.

왜 그런가요설정은 두 층에 삽니다. 도메인(존)마다 붙는 것과 계정 전체에 붙는 것입니다. 요청자는 업무 시스템의 이름을 옮겨 적을 뿐 어느 층인지는 적지 않습니다. 특히 API 접근 열쇠의 「사용 가능한 IP 제한」은 계정 층인데, 흔히 「IP 접근 제어」라 부르고 도메인 쪽에도 같은 이름의 기능이 있어 말로는 갈리지 않습니다. 이름까지 겹치면 위험이 커집니다. 요청 번호를 이름 뒤에 붙이는 관행이 있으면 앞부분이 같은 열쇠가 여러 개 생기고, 틀린 쪽에 대역을 열어도 오류가 없습니다. 조용히 적용되고 요청한 쪽은 여전히 막힙니다.

이렇게 합니다① 이름보다 어느 층인지를 먼저 가르십시오. 도메인별 보안 룰과 허용 목록에 하나도 안 걸리면 다른 층에 있다는 신호이니 계정 층의 접근 열쇠 목록을 봅니다. ② 비슷한 이름이 둘 이상이면 멈추고 되물으십시오. 만든 날짜와 만든 사람까지 붙여 확인받습니다. 변경 이력에 있어 조회만으로 됩니다. ③ 요청 값이 이미 들어가 있지 않은지 보십시오. 같은 대역이 다른 쪽에 이미 있으면 「추가」가 아니라 대상이 바뀐 것일 가능성이 높고, 그대로 넣으면 양쪽 모두 열린 채 남습니다. 대역은 지울 수 있어도 그 사이 오간 요청은 되돌릴 수 없으니 대상 확정 전에는 넣지 않는 편이 항상 쌉니다.

여기서 해 보기 — 조회만으로 갈립니다. 요청받은 이름을 도메인별 보안 룰·허용 목록·계정 접근 열쇠 세 곳에서 찾아, 한 곳에만 걸리면 그것이 대상이고 두 곳 이상이면 되묻습니다.

공식 문서 — Fundamentals — API token permissions · Fundamentals — Create an API token · WAF — IP Access rules

사례 특정 도메인만 볼 수 있게 권한을 주려는데 그 항목이 목록에 없습니다실제로 1번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다「이 사람들에게 이 도메인의 이 기능만 보여 주자」는 요청이 옵니다. 다른 기능처럼 될 줄 알았는데 도메인 단위 역할 목록에 그 기능이 없고 계정 단위에만 있습니다.

왜 그런가요설정이 사는 층이 기능마다 다릅니다. 방화벽 규칙·DNS 처럼 도메인에 붙는 기능은 도메인별로 권한을 쪼갤 수 있지만, 계정에 붙는 기능은 자원이 도메인에 속하지 않아 쪼갤 수 없습니다. 대표가 봇 방지 위젯입니다. 계정에서 만들고 키를 받아 아무 사이트에나 붙이는 구조라 「어느 도메인의 위젯」이라는 개념이 없고, 읽기 권한도 계정 단위로만 줍니다. 요청하는 쪽에는 두 종류가 나란히 비슷한 이름으로 보여 「왜 이것만 안 되나」로 받아들이기 쉬우니, 되는지 안 되는지 먼저 갈라 주는 것이 답변의 절반입니다.

이렇게 합니다① 그 기능이 어느 층인지 확인합니다. 가장 빠른 방법은 API 주소 모양입니다. 계정 아래에만 있으면 도메인별로 쪼갤 수 없습니다. ② 이유와 대안을 함께 줍니다. 「불가능합니다」로 끝내면 요청한 쪽은 이유를 모른 채 남습니다. 계정 단위 읽기 권한이 현실적 대안이면 제시하되 ③을 반드시 덧붙입니다. ③ 계정 단위로 주면 그 계정의 그 기능 전체가 보입니다. 도메인을 나누려던 이유가 조직 분리나 최소 권한 원칙이었다면 이 대안은 그 목적을 충족하지 못합니다. 그래도 나눠야 하면 남는 길은 계정 분리입니다. 비용과 운영 부담이 따르니 권한 요청 단계에서 꺼내야 합니다. 나중이면 구조가 굳은 뒤입니다.

여기서 해 보기 — 조회만으로 확인됩니다. 역할 목록을 계정 단위와 도메인 단위에서 각각 열어 그 기능이 어느 쪽에 있는지 보십시오.

공식 문서 — Turnstile — Get started · Fundamentals — Manage members and roles · Fundamentals — Account permissions

대시보드에서는 이 화면입니다실습장 랩 계정 · 2026-10-15 캡처 · 눌러서 크게 보기

Support Portal 첫 화면. Submit a case, My cases, Chat with a human, Emergency hotline, Report abuse
계정 › Support케이스 열기, 내 케이스, 채팅, 긴급 전화(Enterprise), 악용 신고가 한 화면에 있습니다.
Submit a support case 양식. Describe your issue, 영향 등급(P4), 파일 첨부, Select the affected zones, Add others
Support › Submit a case증상과 빈도, UTC 시각, 재현 순서를 적고 영향 등급과 대상 존을 고릅니다.

사례 지원 케이스가 「종료」로 바뀌었습니다. 요청한 설정은 켜진 걸까요실제로 3번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다기능을 켜 달라고 연 지원 케이스에 「이 케이스는 종료되었습니다」 알림이 옵니다. 끝났다는 뜻으로 읽히지만, 화면을 열면 설정이 그대로이거나 무엇이 켜져 있는지 알 수 없습니다.

왜 그런가요「종료」는 대화가 끝났다는 뜻이지 설정이 바뀌었다는 뜻이 아닙니다. 담당자가 답하면 「해결됨」이 되고, 정해진 시간 안에 되묻지 않으면 아무도 손대지 않아도 자동으로 「종료」됩니다. 답이 「요청 대상이 아니고 화면에서 직접 켜는 것입니다」나 「이미 하나 있습니다」일 때 특히 헷갈립니다. 설정은 아무것도 바뀌지 않았고, 「이미 있다」는 것이 무엇인지도 확인되지 않은 채 종료됩니다. 종료된 케이스는 되살릴 수 없어 새 케이스를 열어 옛 번호를 인용하고 맥락을 다시 설명해야 합니다.

이렇게 합니다① 종료 알림을 완료로 읽지 마십시오. 설정은 화면이나 조회로 직접 확인해야 확정됩니다. ② 「이미 있습니다」를 받으면 무엇이 있는지까지 받으십시오. 이름과 적용 범위를 확인하지 않으면 원하던 것인지 끝내 모릅니다. ③ 「해결됨」이 되면 자동 종료 시계가 돕니다. 확인할 것이 남았다면 그 창 안에 되물으십시오. 지나면 새 케이스밖에 없습니다. 닫기 전에 「무엇을 요청했고, 무엇이 바뀌었고, 무엇이 안 바뀌었나」 한 줄을 남기십시오. 없으면 몇 주 뒤 같은 질문을 처음부터 합니다. 종료 문장이 「고쳤습니다」가 아니라 「방법을 드렸습니다」면 아직 아무것도 바뀌지 않은 것이고, 그 방법이 통하는지는 받은 쪽이 확인해야 합니다. 창이 열려 있을 때 한 번 돌려 보십시오.

여기서 해 보기 — 종료된 케이스가 다룬 기능을 지금 화면에서 직접 열어 보십시오. 조회만으로 되며, 「켜져 있다고 생각했는데 아니었다」가 여기서 드러납니다.

공식 문서 — Support — Contacting Cloudflare Support · Waiting Room — Get started

사례 남의 답을 기다리는 중인데 지원 케이스가 자꾸 「곧 종료됩니다」라고 합니다실제로 1번 겪은 일 · 가장 최근 2026-09-22 · 마지막 수정 2026-10-15

이렇게 보입니다지원 케이스에서 요청받은 자료를 다른 쪽(고객사·협력사·다른 팀)에 넘겨 기다리는 중인데, 「아직 계신가요? 며칠 뒤 자동으로 해결됨 처리됩니다」 알림이 옵니다. 기다릴수록 케이스가 닫히는 쪽으로 밀립니다.

왜 그런가요자동 종료 시계는 일이 막힌 곳이 아니라 당신이 답하지 않은 기간을 셉니다. 지원 쪽은 마지막으로 공을 넘긴 것이 자기들이라, 회신이 없으면 「해결됐거나 관심이 식었다」로 봅니다. 자료를 구하는 중인지 잊은 것인지 시계는 구분하지 않습니다. 한 번 답하면 되감기지만 꺼지지 않고 다시 돌아, 상대가 두 주를 끌면 같은 알림을 여러 번 받습니다. 더 조용한 함정은 「기다리는 중」이라는 답이 자료 제출로 오해되는 것입니다. 시계는 멈춰도 요청받은 것은 미제출이라 진행은 하루도 나아가지 않습니다.

이렇게 합니다① 기다리는 중이라고 그 창 안에 적으십시오. 한 줄이면 시계가 되감깁니다. 무엇을 누구에게 넘겼고 언제쯤 받을지까지 적으면 상대도 알림 주기를 조정해 줍니다. ② 상태 보고와 자료 제출을 구분하십시오. 「기다리는 중」은 시계만 멈추고 요청을 채우지 않습니다. ③ 지금 낼 수 있는 것부터 내십시오. 요청 자료 중에는 상대 회신 없이 우리 관측만으로 뽑히는 것이 섞인 경우가 많고, 그것을 내야 실제로 앞으로 갑니다. ④ 오래 걸릴 것 같으면 미리 말하십시오. 「2주쯤 걸릴 예정」이라고 적는 편이 매번 경고에 답하는 것보다 품이 적게 듭니다.

여기서 해 보기 — 열린 케이스 목록에서 마지막 코멘트를 쓴 사람을 보십시오. 상대 쪽이고 며칠이 지났다면 이미 시계가 돌고 있습니다.

공식 문서 — Support — Contacting Cloudflare Support