Cloudflare One 이해하기 시리즈 (8편 중 4편)
이전 글까지 사용자 디바이스와 애플리케이션을 Cloudflare에 연결하는 방법을 살펴봤습니다. 하지만 연결은 트래픽이 지나갈 “길”을 만들 뿐, 누가 그 길을 지나갈 수 있는지는 결정하지 않습니다. 이 역할을 담당하는 것이 
Cloudflare Access입니다.
이 글에서는 Access의 인증·인가 구조와 정책 구성 방법, 그리고 사용자와 디바이스 정보를 조합한 접근 정책을 정리합니다.
네트워크 연결과 Access는 무엇이 다른가
1편에서 정리한 내용을 다시 짚어 보면 다음과 같습니다.
| 단계 | 담당 | 질문 |
|---|---|---|
| 네트워크 연결 (Connectivity) | Client, Tunnel, Mesh, WAN | 트래픽이 목적지까지 도달할 수 있는가 |
| 인증 (Authentication) | Access + IdP | 요청한 사용자·서비스가 누구인가 |
| 인가 (Authorization) | Access 정책 | 이 사용자·디바이스·조건에서 허용할 것인가 |
| 트래픽 검사 (Inspection) | Gateway | 허용된 트래픽의 내용이 안전한가 |
Access는 애플리케이션 앞에서 모든 요청을 Access 정책과 대조한 뒤에만 통과시킵니다. 그리고 Access 정책은 기본 거부 (deny by default)입니다. Tunnel이 정상이고 경로가 설정되어 있어도 사용자가 Allow 정책에 일치하지 않으면 접근할 수 없습니다.
인증 (Authentication): 사용자가 누구인지 확인
Access는 사용자를 직접 관리하지 않고, 조직이 이미 사용하는 IdP (Identity Provider)에 인증을 위임합니다.
- IdP 연동: Microsoft Entra ID, Okta, Google, GitHub, 일반 SAML·OIDC IdP 등을 연동할 수 있고, 여러 IdP를 동시에 사용할 수 있습니다. 예를 들어 임직원은 Entra ID로, 협력사는 별도 IdP로 로그인하게 할 수 있습니다.
- One-time PIN: IdP가 없는 사용자에게 이메일로 일회용 PIN을 보내 인증합니다. 협력사나 임시 사용자에게 유용합니다.
- 다중 인증 (MFA): IdP가 수행한 MFA 방식을 정책 조건으로 확인하거나, IdP와 별개로 Access에서 독립적인 MFA를 요구할 수 있습니다.
- SCIM 프로비저닝: IdP에서 사용자를 비활성화하거나 그룹 구성원을 변경하면, SCIM으로 Access에 반영해 사용자가 모든 속성을 다시 인증하도록 강제할 수 있습니다.
한 가지 주의할 점은, Access와 Client가 사용자의 마지막 인증 상태를 기준으로 ID를 평가한다는 것입니다. 사용자가 IdP로 로그인한 뒤 One-time PIN 같은 다른 방법으로 다시 로그인하면, 이후에는 IdP 그룹 정보가 평가되지 않습니다.
인가 (Authorization): 애플리케이션 유형별 보호 방식
Access로 보호하는 대상은 애플리케이션 단위로 정의하며, 유형에 따라 연결 방식과 제어 범위가 다릅니다.
| 구분 | Self-hosted | SaaS | Infrastructure | Bookmark | 디바이스 등록 (warp) |
|---|---|---|---|---|---|
| 보호 대상 | 직접 운영하는 리소스 (공개 웹앱, 사설 네트워크 대상, Workers) | Salesforce, Atlassian, Workday 같은 서드파티 SaaS | 개별 서버·인프라 대상 | App Launcher에 표시할 외부 URL | Cloudflare One Client의 조직 등록 |
| Client 필요 여부 | 대상 유형과 정책에 따라 다름 | 불필요 | 필요 | 불필요 | 필요 (등록 대상) |
| 인증·인가 방식 | Access 정책 + 애플리케이션 토큰 | Access 정책 + SAML/OIDC 어설션 | 프로토콜 인식 정책 (포트, 사용자 이름) | App Launcher 노출 정책만 | Access 정책 (IdP 로그인, 서비스 토큰, mTLS). Device Posture 사용 불가 |
| 감사 로그 | 인증 이벤트 + 요청별 Access 로그 | 인증 이벤트 | 인증 이벤트 + SSH 명령 로그 | App Launcher 인증만 | 등록 시 인증 이벤트 |
디바이스 등록 (warp) 애플리케이션은 2편에서 설명한 디바이스 등록 권한 (Device enrollment permissions)이 내부적으로 사용하는 Access 애플리케이션입니다. 누가 Cloudflare One Client로 디바이스를 조직에 등록할 수 있는지를 Access 정책으로 결정하므로, 등록이 실패하면 이 애플리케이션의 정책과 로그인 방법을 먼저 확인합니다. Client는 등록이 끝난 뒤에야 상태를 검사할 수 있으므로 이 정책에서는 Device Posture를 조건으로 쓸 수 없습니다.
Self-hosted 애플리케이션은 가장 범용적이며 대부분의 Access 배포가 여기에 해당합니다.
- 공개 호스트네임 (Public hostname): Cloudflare DNS로 관리되는 호스트네임 앞에 Access를 두면, Cloudflare가 요청을 프록시하면서 로그인 페이지를 보여 주고 정책을 통과한 요청만 오리진으로 전달합니다. 사용자 디바이스에 아무것도 설치할 필요가 없어 가장 일반적인 시작점입니다.
- 사설 애플리케이션 (Private): 사설 IP, 호스트네임, CIDR 대역과 포트를 대상으로 정책을 적용합니다. 사용자는 Cloudflare One Client로 트래픽을 보내야 하고, 사설 네트워크는 Tunnel이나 Mesh로 연결되어 있어야 합니다. VPN처럼 네트워크 전체를 열어 주는 대신 애플리케이션·서비스 단위로 접근을 제어할 수 있습니다.
- Workers: Worker 이름으로 직접 지정해 모든 경로와 프리뷰 배포 앞에 Access를 둘 수 있습니다.
cloudflaredCLI 인증: 브라우저 로그인이 어려운 SSH, API 호출 같은 CLI 작업에서는cloudflared access login <hostname>으로 Client 없이 인증할 수 있습니다.
SaaS 애플리케이션에서는 Access가 SAML 또는 OIDC 기반의 SSO 제공자 역할을 합니다. 사용자가 SaaS에 로그인하면 Cloudflare가 IdP 인증과 Access 정책 평가를 수행한 뒤 SaaS에 서명된 어설션을 발급합니다. 이를 통해 SaaS에도 Device Posture나 Client 연결 여부 같은 조건을 적용할 수 있고, 여러 IdP를 SaaS마다 따로 연동하지 않아도 됩니다. 다만 SaaS 안에서의 권한은 SaaS 자체 역할 설정으로 관리해야 합니다.
Infrastructure 애플리케이션은 사용자가 서버에 “도달할 수 있는가”뿐 아니라, 접속 후 어떤 UNIX 사용자 이름으로 로그인할 수 있는지 같은 프로토콜 수준의 권한까지 제어하고 SSH 명령 로그를 남깁니다.
Access 정책의 구성 요소
모든 Access 정책은 네 가지 요소로 구성됩니다.
- Action: 정책에 일치했을 때의 동작 (Allow, Block, Bypass, Service Auth)
- 규칙 유형 (Rule type): 조건을 결합하는 방식 (Include, Require, Exclude)
- 선택자 (Selector): 확인할 속성 (이메일 도메인, 국가, Device Posture 등)
- 값 (Value): 비교할 값 (
@example.com등)
Action
| Action | 동작 | 사용 시점 |
|---|---|---|
| Allow | 조건을 만족한 사용자의 접근 허용 | 기본적인 접근 허용 |
| Block | 조건을 만족한 사용자의 접근 차단 | Allow 정책 안에서 예외를 만들 때 |
| Bypass | 해당 트래픽에 Access 적용을 해제. 보안 제어와 로깅이 모두 적용되지 않음 | 반드시 공개되어야 하는 특정 경로 |
| Service Auth | IdP 로그인 없이 서비스 토큰이나 mTLS로 인증 | 서버 간 통신, 자동화 |
Access는 기본 거부이므로, Block 정책에 일치하지 않는 사용자도 Allow 정책에 명시적으로 일치하지 않으면 차단됩니다. Bypass는 로그가 남지 않으므로 내부 애플리케이션에 대한 영구적인 접근 수단으로 쓰지 않는 것이 좋습니다. 인증 없이 호출해야 하는 경우라도 로깅이 필요하다면 Service Auth를 검토합니다.
규칙 유형
| 규칙 유형 | 논리 연산 | 의미 |
|---|---|---|
| Include | OR | 정책의 기본 대상. 여러 Include 중 하나만 만족하면 됨. 모든 정책에 최소 하나 필요 |
| Require | AND | 모든 Require 조건을 만족해야 함 |
| Exclude | NOT | 하나라도 해당하면 제외 |
예를 들어 “포르투갈에서 접속하고, @team.com 이메일을 가지며, 특정 두 사용자는 제외”하는 정책은 다음과 같습니다.
| Action | 규칙 유형 | 선택자 | 값 |
|---|---|---|---|
| Allow | Include | Country | Portugal |
| Require | Emails ending in | @team.com | |
| Exclude | user-1@team.com, user-2@team.com |
Require 규칙의 함정: 하나의 Require 규칙에 여러 값을 넣으면 값끼리도 AND로 결합됩니다. 예를 들어 Require Country에 United States와 Portugal을 함께 넣으면 “두 나라에 동시에 있어야” 하므로 아무도 접근할 수 없습니다. Require 안에서 OR 조건이 필요하면 규칙 그룹 (Rule group)을 만들어 Include로 여러 값을 묶은 뒤, 정책에서 그 그룹을 Require합니다.
평가 순서
하나의 애플리케이션에 여러 정책이 있을 때는 다음 순서로 평가됩니다.
- Bypass와 Service Auth 정책을 UI에 표시된 순서대로 먼저 평가
- 그다음 Allow와 Block 정책을 위에서부터 순서대로 평가
- Allow 또는 Block에 일치하면 평가를 멈추고, 이후 정책은 결과를 바꿀 수 없음
예를 들어 정책이 Allow A → Block B → Service Auth C → Bypass D → Allow E 순서로 배치되어 있다면, 실제 평가 순서는 Service Auth C → Bypass D → Allow A → Block B → Allow E입니다. 따라서 예외를 만드는 Block 정책은 넓은 Allow 정책보다 위에 두어야 합니다.
자주 하는 설정 실수
다음 규칙을 Allow 정책에 넣으면 사실상 누구나 애플리케이션에 접근할 수 있게 됩니다.
Include+EveryoneInclude+Login Methods=One-time PIN(유효한 이메일만 있으면 누구나 PIN을 받을 수 있음)
선택자: 사용자, 디바이스, 네트워크, 서비스
선택자는 확인하는 정보에 따라 네 가지로 나눌 수 있습니다. 중요한 차이는 로그인 시점에만 확인되는지, 세션 중에도 계속 확인되는지입니다. ID 기반이 아닌 속성은 세션 중 새 HTTP 요청마다 다시 평가됩니다.
| 분류 | 주요 선택자 | 로그인 시 확인 | 세션 중 지속 확인 |
|---|---|---|---|
| 사용자 (ID 기반) | Emails, Emails ending in, Identity provider group, SAML Group, OIDC Claim, Login Methods, Authentication Method (MFA) | O | X |
| 사용자 위험도 | User Risk Score (Enterprise) | O | O |
| 디바이스 | Device posture, Warp, Gateway, Common Name, Valid Certificate | O | O |
| 네트워크 | IP ranges, Country | O | O |
| 서비스 | Service Token, Any Access Service Token, Linked App Token (Service Auth 필요) | O | O |
| 외부 판단 | External Evaluation (외부 API의 사용자 정의 로직) | O | X |
- Identity provider group은 Entra ID, GitHub, Google, Okta, 또는 SCIM으로 그룹을 프로비저닝하는 IdP에서 사용할 수 있습니다. 그룹 이름과 속성 값은 대소문자를 구분하므로 IdP가 보내는 실제 값을 확인한 뒤 정책을 만들어야 합니다.
- Device posture 선택자는 2편에서 설명한 Posture 검사를 만든 뒤에 나타납니다.
Gateway선택자는 디바이스가 Client를 통해 우리 조직의 Zero Trust 인스턴스에 연결되어 있는지를,Warp선택자는 개인용을 포함해 Client에 연결되어 있는지를 확인합니다. - SaaS 애플리케이션에서는 지속 확인 선택자라도 최초 로그인과 SaaS 세션 재발급 시점에만 적용됩니다. 그 이후의 세션은 SaaS가 관리합니다.
사용자·디바이스 기반 접근 정책 예시
사용자 ID와 디바이스 상태를 조합하면 “누가”와 “어떤 디바이스에서”를 함께 확인하는 정책을 만들 수 있습니다.
| 시나리오 | Action | 규칙 구성 |
|---|---|---|
| 임직원 전용 사내 위키 | Allow | Include: Emails ending in @company.com |
| 재무 시스템은 관리 디바이스에서만 | Allow | Include: IdP group finance / Require: Device posture (디스크 암호화), Gateway |
| 협력사는 특정 국가에서만, 짧은 세션 | Allow | Include: Login Methods (협력사 IdP) / Require: Country South Korea / 정책 세션 시간 1시간 |
| 관리자 콘솔은 MFA와 회사 인증서 필수 | Allow | Include: IdP group admins / Require: Authentication Method (MFA), Valid Certificate |
| 퇴사 예정자 차단 | Block (Allow보다 위) | Include: IdP group offboarding |
| CI/CD 파이프라인의 API 호출 | Service Auth | Include: Service Token ci-deploy |
이처럼 Include로 대상 사용자를 정하고, Require로 디바이스·네트워크 조건을 더하고, Exclude나 상위 Block 정책으로 예외를 처리하는 방식이 기본 패턴입니다. 자주 쓰는 조합은 재사용 가능한 정책 (reusable policy)으로 만들어 여러 애플리케이션에 적용할 수 있습니다.
세션과 토큰
사용자가 로그인하면 Access는 두 개의 서명된 JWT (JSON Web Token)를 발급합니다.
| 토큰 | 역할 | 만료 | 저장 위치 |
|---|---|---|---|
| 전역 세션 토큰 (Global session token) | IdP 로그인 정보를 저장하고 모든 Access 애플리케이션의 SSO 제공 | 전역 세션 시간 (기본 24시간, 15분~1개월) | Cloudflare 팀 도메인 |
| 애플리케이션 토큰 (Application token) | 특정 애플리케이션 접근 허용 | 정책 세션 시간 (기본값은 애플리케이션 세션 시간, 기본 24시간) | 보호 대상 호스트네임 |
- 애플리케이션 토큰이 만료되면, 전역 토큰이 유효하고 사용자가 여전히 정책을 만족하는 경우 새 애플리케이션 토큰이 자동 발급됩니다. 전역 토큰까지 만료되면 IdP 로그인을 다시 요구합니다.
- 세션 시간은 Client 세션 → 정책 세션 → 애플리케이션 세션 → 전역 세션 순으로 구체적인 설정이 우선합니다. 예를 들어 엔지니어는 7일, 협력사는 24시간처럼 정책별로 다르게 설정할 수 있습니다.
- SSH, RDP, VNC의 경우 세션 시간은 새 연결을 시작할 수 있는 기간을 의미하며, 이미 열린 세션의 길이는 제어하지 않습니다.
- 오리진 애플리케이션은 Access가 전달하는 JWT (
Cf-Access-Jwt-Assertion헤더)를 검증해, 요청이 실제로 Access를 거쳤는지 확인할 수 있습니다.
사람이 아닌 접근: 서비스 토큰과 mTLS
서버 간 통신, 자동화 스크립트, IoT 디바이스처럼 IdP 로그인이 불가능한 주체는 Service Auth Action으로 인증합니다.
- 서비스 토큰 (Service token): Client ID와 Client Secret을 요청 헤더에 담아 인증합니다. 특정 애플리케이션 전용 토큰 또는 계정의 모든 서비스 토큰을 허용할 수 있습니다.
- mTLS (상호 TLS): 클라이언트 인증서를 검증합니다. 유효한 인증서만 요구하거나 특정 Common Name을 요구할 수 있습니다.
- Linked App Token: 특정 Access 애플리케이션에 발급된 OAuth 액세스 토큰을 확인합니다.
Access와 Gateway의 역할 구분
Access와 Gateway는 모두 정책을 적용하지만 역할이 다릅니다.
| 구분 | Access | Gateway |
|---|---|---|
| 목적 | 애플리케이션 접근 인가 | 트래픽 검사와 필터링 |
| 판단 기준 | 사용자 ID, 그룹, 디바이스, 위치, 서비스 인증 | DNS 쿼리, IP·포트, URL, 파일, 애플리케이션 등 트래픽 속성 + ID |
| 적용 대상 | 등록한 애플리케이션 | Client, DNS location, PAC 등으로 들어온 모든 트래픽 |
| 그룹 개념 | 규칙 그룹 (Cloudflare 객체) | IdP·SCIM으로 동기화된 IdP 그룹 |
사설 애플리케이션처럼 ID 기반 접근 제어와 트래픽 검사가 모두 필요하다면 두 제품을 함께 사용합니다. Access 규칙 그룹은 Gateway 정책에서 사용할 수 없고, Gateway의 그룹 조건은 IdP에서 동기화된 그룹을 사용한다는 점도 기억해야 합니다. Gateway 정책은 다음 글에서 자세히 다룹니다.
검증과 운영
- 테스트 케이스: 허용 대상 사용자, 비허용 사용자, Posture 검사에 실패한 디바이스, 서비스 토큰, 여러 IdP 로그인 흐름을 각각 테스트합니다.
- Access 인증 로그: 누가 어떤 애플리케이션에 인증했고, 어떤 정책에 일치했는지 확인할 수 있어 “왜 차단되었는가”를 분석하는 출발점입니다.
- 단계적 적용: 넓은 범위의 정책은 파일럿 그룹에 먼저 적용하고, 결과를 확인한 뒤 확대합니다.
마치며
Cloudflare Access는 IdP로 사용자를 인증하고, 정책으로 사용자·디바이스·네트워크 조건을 평가해 애플리케이션 접근을 인가합니다. Include로 대상을 정하고 Require로 조건을 더하는 구조, 기본 거부 원칙, Bypass·Service Auth가 먼저 평가되는 순서를 이해하면 대부분의 접근 정책을 안전하게 설계할 수 있습니다.
다음 글부터는 트래픽 및 데이터 보안으로 넘어가, Gateway의 DNS·Network·HTTP 정책이 각각 어떤 역할을 하고 어떤 트래픽에 적용되는지 살펴봅니다.