Access controls와 Traffic controls앱 앞의 문과 나가는 길의 검문소

쉽게 말해 Access는 건물의 각 사무실 문, Traffic controls는 직원이 드나드는 정문 검색대입니다.

Traffic controls는 WARP? 등으로 Cloudflare를 거친 트래픽만 봅니다. 앱을 끄거나 안 깐 단말의 트래픽은 정책을 만나지 않습니다.

사설 IP 서버는 두 방법 모두 됩니다. 앱마다 로그인 기록과 세션 시간이 필요하면 Access 사설 앱을 고릅니다.

대역 단위로 넓게 막고 소속별로 예외를 여는 구조라면 Traffic controls가 간단합니다.

Access는 내가 등록한 앱 주소에 온 요청만 봅니다. 직원이 다른 사이트로 가는 것은 Access와 관계없습니다.

• 인터넷 통제가 목적: Traffic controls 정책과 단말 앱(WARP) 배포가 함께 필요합니다.
• 앱 보호가 목적: Traffic controls만으로는 앱별 로그인 화면과 세션이 생기지 않습니다.

2026-10-12 대시보드 개편으로 Zero Trust 메뉴가 주 대시보드 메뉴와 합쳐졌습니다. 예전 «Traffic policies»가 지금 «Traffic controls»입니다.

아래 다섯 가지는 모두 Traffic controls로 트래픽을 보내는 길입니다. 어느 길로 오든 판정은 Traffic controls 정책이 합니다.

프록시 엔드포인트와 격리 브라우저는 Access controls가 아닙니다. Access 로그인 화면을 빌려 «누구인지»만 확인하고, 허용과 차단은 Traffic controls 정책이 정합니다.

• 소속별 앱 차단과 차단 화면까지: WARP가 맞습니다. 실습장 랩이 이 방식입니다.
• 사무실 전체 악성 도메인 차단만: DNS 위치 하나로 됩니다. 단말에 아무것도 깔지 않습니다.

단말 상태 조건(posture?)은 WARP가 단말에서 정보를 모아야 해서 WARP 없이는 쓸 수 없습니다. 출발지 IP로 묻는 프록시 엔드포인트는 Enterprise 플랜 기능입니다.

«없음»은 그 메뉴를 쓰지 않는다는 뜻입니다. 한 회사 안에서도 여러 줄이 함께 쓰이고, 아래 네 절에 환경마다 거는 순서를 적었습니다.

Zero Trust › Traffic controls › Firewall policies

1. DNS: 보안 위협(Security Risks) 분류를 막고, 회사가 정한 콘텐츠 분류와 앱(메신저 등)을 막습니다.
2. Network: 사내 서버마다 허용 소속을 한 줄씩 열고, 맨 끝에 사내 대역 전체 차단을 둡니다. 앱이 IP로 바로 붙는 경우도 여기서 막습니다.
3. HTTP: TLS 복호화를 켠 뒤 인증서 고정 앱을 Do Not Inspect로 먼저 빼고, DLP와 격리, 테넌트 제어를 겁니다.
4. 단말 조건: OS 버전, 방화벽, 디스크 암호화 같은 검사를 만들어 민감한 서버의 허용 줄에만 붙입니다.

휴대폰은 인증서 고정 앱이 많습니다. Do Not Inspect를 빼먹으면 복호화를 켜는 순간 은행이나 메신저 앱이 끊깁니다.

실습장 «소속별 접근 랩»의 협력사와 고객사가 첫 줄 방식입니다. 단말 등록 권한에 외부 계정을 넣어야 로그인이 됩니다.

• 사무실 DNS 위치: 사무실 공유기나 DNS 서버가 Gateway 주소를 보게 합니다. 단말에 아무것도 깔지 않고 DNS 정책으로 악성 도메인과 분류를 막습니다.
• 지점과 데이터센터: 사이트 라우터에서 IPsec이나 GRE로 Cloudflare WAN에 붙입니다. DNS, Network, HTTP 정책을 모두 쓰지만 조건은 출발지 IP와 목적지입니다.
• 사람 기준이 필요하면: 같은 사무실 안에서도 사람마다 달라야 하는 정책은 WARP 단말에서만 됩니다. 네트워크 정책은 바닥을 깔고, 사람별 정책은 WARP가 맡습니다.

DNS 위치만 쓰면 IP로 바로 붙는 연결과 웹 내용은 보지 못합니다. 앱 차단을 DNS 위치 하나로 끝냈다고 보고하지 않습니다.

소속별로 나눌 때는 둘 다 사람을 리스트나 IdP? 그룹으로 묶고, 정책은 그 묶음만 보게 합니다. 사람이 늘어도 정책을 고치지 않습니다.

• Access: 정책이 없는 앱은 모든 요청을 거부합니다. 들어올 사람을 Allow로 하나씩 엽니다.
• Traffic controls: DNS, Network, HTTP 모두 맞는 정책이 없으면 그대로 내보냅니다. 사내 대역을 지키려면 허용 줄들 아래에 «나머지 전부 차단»을 둡니다.
• 예외: HTTP 정책 설정에서 기본 동작을 Block으로 바꾸면 HTTP만 기본 차단이 됩니다.

1. 서버마다 «허용 소속이면 Allow» 한 줄씩 둡니다.
2. 맨 끝에 «사내 대역 전체 Block»을 둡니다.
3. 허용 줄을 끝줄보다 아래로 끌어 내리면 그 서버는 아무도 못 들어갑니다.

Zero Trust › Insights & Logs › Logs

DNS 정책은 이름 조회 단계만 막습니다. IP로 바로 붙는 연결은 Network 정책이 막아야 합니다.

• 사설 앱 하나에 정책 두 줄: 같은 신원과 단말 조건으로 DNS 정책(도메인 리스트)과 Network 정책(IP 리스트)을 짝으로 둡니다.
• 웹 앱이면 HTTP 정책: 차단 화면과 경로 단위 통제가 필요할 때 더합니다.

1. 조회 전에 보는 선택자를 쓴 DNS 정책(도메인, 앱 등)
2. Resolver 정책(쓰는 경우)
3. 조회 후에 보는 선택자를 쓴 DNS 정책(응답 IP 등)
4. Egress 정책(쓰는 경우)
5. Network 정책
6. HTTP 정책

HTTP 안에서는 동작 종류가 먼저입니다. Do Not Inspect, Isolate, 그다음 Allow·Block·Do Not Scan, 마지막으로 본문 검사(DLP, 백신)입니다.

2025-07부터 Network가 HTTP보다 먼저입니다. 같은 목적지를 Network에서 조용히 막으면 사용자는 HTTP 차단 화면을 보지 못합니다.

• 기본 위치: 사설 주소 Access 앱의 정책은 모든 Gateway Network 정책 뒤에 평가됩니다.
• 위치 바꾸기: Network 정책에 «Self-hosted Access App with Private Address is Present → Allow»를 만들고 순서를 옮깁니다. 이 Allow는 길만 터 주고, 사용자는 Access 정책을 그대로 통과해야 합니다.
• 호스트 이름 우선: 같은 IP를 가리키는 사설 호스트 이름 앱과 사설 IP 앱이 있으면 호스트 이름 앱이 이깁니다.

Zero Trust › Traffic controls › Firewall policies › Network

실습장 랩은 사내 대역 웹(80)을 Network에서 통과시키고, 소속 판정은 HTTP 정책에 맡겼습니다. 권한 없는 소속은 사유가 적힌 차단 화면을 봅니다.

Network 차단에도 알림이 필요하면 정책의 «Display block notification for Cloudflare One Client»를 켭니다. 단말 OS 알림으로 뜨며 Enterprise 플랜 기능입니다.

"traffic": "any(app.ids[*] in {1199})"

Terraform 제공자 v4는 Gateway precedence에 해시를 덧붙여(예: 1000 → 1000901) 순서 변경 시 오류가 납니다. v5로 올리거나 API로 순서를 맞춥니다.

사설 주소가 Access 앱으로 등록돼 있으면 Gateway가 허용해도 Access 정책을 따로 통과해야 합니다.

• 확인 순서: Gateway Network 로그에서 Allow인지 본 뒤, Access authentication logs에서 같은 사용자의 거부 기록을 찾습니다.
• 정리 원칙: 한 목적지는 한쪽이 판정하게 합니다. 둘 다 걸어야 하면 Gateway는 길, Access는 사람으로 역할을 나눕니다.