Access 는 어떻게 동작하나네트워크 대신 앱을 하나씩 엽니다

1. 사용자가 앱 주소를 열면 요청이 Cloudflare 엣지에 먼저 닿습니다.
2. Access가 로그인 화면을 띄우고, 사용자는 회사 IdP로 로그인합니다(정책이 요구하면 MFA까지).
3. 통과하면 Access가 JWT?를 발급해 쿠키 CF_Authorization에 담습니다.
4. 이후 요청은 토큰과 함께 앱으로 갑니다.

기본값이 «거부»라 Allow 정책에 맞는 요청만 들어갑니다.

Zero Trust?는 «사내망 안이니 믿는다»를 버리고, 요청마다 판단해 역할에 필요한 만큼만 엽니다.

사설 IP로만 닿는 앱은 Cloudflare 연결 네트워크 밖의 사용자에게 Cloudflare One Client가 필요합니다(브라우저 격리 방식은 예외). 공개 호스트 이름의 웹 앱은 브라우저만으로 됩니다.

cloudflared가 안에서 먼저 연 연결 위로 요청과 응답이 오갑니다.

• 방화벽은 cloudflared의 나가는 연결만 열어 둡니다(Cloudflare 7844 포트, TCP와 UDP).
• 서버에 공인 IP가 없어도 됩니다.

Tunnel 경로를 Access 앱보다 먼저 만들면 그 사이에 누구나 앱에 닿습니다. Access 앱을 먼저 만듭니다.

IP 허용 목록은 «어디서»만 봅니다. 같은 출구 IP 뒤라면 아래도 통과합니다.

• 같은 출구를 쓰는 방문객 Wi-Fi
• 악성 코드에 감염된 사내 PC
• 지금은 직원이 아닌 사람

IP 조건은 버리지 않고 Require에 남겨 «사무실에서, 우리 사람만»으로 겁니다.

퇴사자는 IdP 계정을 막고 세션을 회수하면 IP와 상관없이 막힙니다.

로그인 화면이 떠도 정책이 «누구를» 허용하는지가 전부입니다.

Include에 One-time PIN?을 넣고 이메일 도메인을 좁히지 않으면, 어떤 이메일로든 코드를 받아 들어옵니다.

허용 대상은 이메일 도메인이나 IdP 그룹으로 좁힙니다.

Zero Trust › Access › Applications › Add an application › Self-hosted

1. 로그인 수단: 조직을 만들면 Cloudflare 계정 로그인이 기본으로 붙고, 회사 IdP나 One-time PIN을 더합니다.
2. Access 앱과 정책: 정책이 없는 앱은 모든 요청을 거부합니다.
3. 시험: Policy tester?로 누가 통과하는지 미리 봅니다.
4. 연결: Tunnel 경로(published application route)를 만듭니다.
5. 오리진 검증: Tunnel의 Protect with Access를 켜거나 앱이 토큰을 직접 검증하게 합니다.

Zero Trust › Access › Policies › Add policy

모든 정책에는 Include가 하나 이상 있어야 합니다.

• 평가 순서: 각 묶음 안에서는 화면 위부터 보고, Allow나 Block에 맞으면 거기서 끝납니다.
• Block: Allow의 예외용입니다. 기본이 거부라 Block만 두면 의미가 없습니다.
• 2단계 인증: IdP가 알려 주는 인증 방식을 Require로 걸거나(지원 IdP만), Access가 직접 묻는 독립 MFA로 요구합니다.

Require에 값을 여러 개 넣으면 모두 «그리고»로 묶입니다. «한국 또는 미국»은 규칙 그룹을 Include로 만들고 Require에서 그 그룹을 부릅니다.

Zero Trust › Access controls › Service credentials › Service Tokens › Create Service Token

1. 이름과 만료 기간(Service Token Duration)을 정합니다. Client Secret은 이때 한 번만 보여 줍니다.
2. 정책 액션을 Service Auth로 둡니다. 다른 액션이면 IdP 로그인을 요구합니다.
3. 출발지까지 묶으려면 Require에 IP 범위(예: 192.0.2.0/24)를 더합니다.
4. 프로그램은 두 값을 헤더에 넣어 보냅니다.

curl -H "CF-Access-Client-Id: <CLIENT_ID>" \
  -H "CF-Access-Client-Secret: <CLIENT_SECRET>" \
  https://app.example.com

Client Secret은 비밀번호와 같습니다. 코드나 저장소에 그대로 두지 않습니다.

Zero Trust › Team & Resources › Users › 사용자 선택 › Action › Remove users

Free 플랜으로도 시작할 수 있고, 플랜별 좌석 수는 요금제와 계약에서 확인합니다.

외부인이 쓰는 화면(공개 문의 폼 등)에 Access 로그인을 걸면 로그인한 외부인마다 좌석을 씁니다.

Access는 Cloudflare 엣지에서만 동작해, 오리진에 직접 온 요청은 만나지 못합니다.

• Tunnel로 연결: 방화벽의 들어오는 방향을 닫습니다.
• 토큰 검증: 오리진이 토큰 없는 요청을 거절합니다. Tunnel이면 Protect with Access로 cloudflared가 대신 검증합니다.

• 토큰은 요청 헤더 Cf-Access-Jwt-Assertion으로 옵니다. 앱 도메인의 CF_Authorization 쿠키에도 들어 있습니다.
• 서비스 토큰 요청은 sub가 빈 문자열이고, Client ID는 common_name에 담깁니다.

서명을 검증하지 않고 헤더만 보면 누구나 같은 이름의 헤더를 만들어 보낼 수 있습니다.

원격 관리 터널은 경로의 Additional application settings에서, 설정 파일 터널은 originRequest에서 켭니다.

originRequest:
  access:
    required: true
    teamName: <팀 이름>
    audTag:
      - <AUD 태그>

• L7 요청마다 Access가 JWT를 Cf-Access-Jwt-Assertion 헤더로 보내고, cloudflared가 검증합니다.
• Access 앱이 보호하는 공개 호스트 이름 서비스에 겁니다.

오리진이 Tunnel 말고 다른 길로도 열려 있으면 그 길은 검증을 거치지 않습니다.

• 요청 단위 Access 로그는 Enterprise 대시보드에서 보이고, Logpush로 내보낼 수 있습니다.
• Policy tester는 사용자 전체(마지막으로 본 신원과 단말 기준)나 한 사람에게 정책을 돌려 허용과 거부를 보여 줍니다.
• 시험 대상은 App Launcher나 다른 Access 앱에 한 번 이상 로그인한 사용자입니다.
• 회수 직후 최대 1분 동안 그 사용자는 다시 로그인하지 못합니다.

API 토큰 권한은 Access: Apps and Policies Write입니다.

서비스 토큰 정책을 만드는 예:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "name": "Authenticate service with service token",
    "decision": "non_identity",
    "include": [{"service_token": {"token_id": "<SERVICE_TOKEN_ID>"}}],
    "require": [{"ip": {"ip": "192.0.2.0/24"}}]
  }'

계정 기본 한도(Enterprise는 늘릴 수 있음):

Bypass? 정책에는 이메일 같은 신원 조건도 쓸 수 없습니다.

• 공개할 경로만 따로 Access 앱(예: app.example.com/oauth/callback)으로 만들어 거기에만 겁니다.
• 기록이 필요한 기계 접근은 Service Auth와 서비스 토큰을 씁니다.
• 운영에 넣기 전에 시험합니다.