Access 身份访问控制

隧道把内网服务暴露到公网后，新的问题来了，谁拿到域名都能访问。管理后台、内部工具、测试环境，这些服务本来只该给团队成员用，暴露出去等于裸奔。Cloudflare Access（Cloudflare 的零信任访问控制服务）就是给这些服务加一道身份验证门，无论谁访问都得先过 Cloudflare 的身份校验，通过了才能到达后端服务。

为什么需要 Access

光有 Tunnel 不够安全的几种场景

场景	风险
管理后台	没有自身登录机制的内部工具
测试环境	想给团队看但不对外公开
开发环境	调试中包含敏感数据
内部 API	只允许特定服务或人员调用
老旧应用	没有现代认证机制，补丁又不便加

这些服务暴露到公网后，依赖服务自身的认证往往不够。Access 在 Cloudflare 边缘层做拦截，未授权请求根本到不了后端，相当于在服务前面加了一道独立门禁。

Zero Trust 概念

传统安全模型是城堡式，内网可信，外网不可信，进了内网就畅通无阻。这种模型一旦边界被突破，攻击者就能横向移动。Zero Trust（零信任）反过来，默认不信任任何人，每次访问都要验证身份，不管请求来自内网还是外网。

对比项	城堡式安全	零信任
信任边界	内网整体可信	没有默认信任
验证时机	进内网时一次	每次访问都验证
暴露面	服务对内网开放	服务对任何人都不可见
失效影响	边界突破即失守	单点突破不扩散

Cloudflare 把 Zero Trust 落地成一套产品，Access 是其中的身份访问控制部分。所有请求先到 Cloudflare 边缘，Access 在这里做身份校验，通过的才转发到 Tunnel 或其他后端。后端服务本身可以完全不暴露公网入口，只接受来自 Cloudflare 的流量。

启用 Access

Access 在 Cloudflare Zero Trust 控制台里配置，不写代码。前提是已经把域名托管在 Cloudflare，并且有可用的 Tunnel 暴露了服务。

第一步，进入 Cloudflare 控制台，左侧菜单选 Zero Trust。

第二步，首次进入会引导设置团队名，形如 myteam.cloudflareaccess.com，这是身份验证页面的入口域名。

第三步，选择身份提供商。Access 不自己做账号系统，而是对接已有的 IdP（身份提供商）。

身份提供商	适合场景
Google	团队都用 Gmail
GitHub	开发团队，已有 GitHub 账号
Microsoft	用 Microsoft 365 的企业
One Time Pin (OTP)	临时方案，邮箱验证码登录
SAML	企业自建 IdP，如 Okta、Azure AD

OTP 最简单，不需要外部 IdP，输入邮箱收到验证码就能登录，适合个人或小团队快速上手。

创建应用

身份提供商配好后，创建一个 Access Application 保护具体服务。在 Zero Trust 控制台 Access > Applications 里点 Add an application，选 Self-hosted。

关键配置项

字段	作用	示例
Application name	应用名，便于识别	内部管理后台
Session Domain	受保护的域名	admin.example.com
Session Duration	登录会话有效期	24 hours
Identity providers	允许的身份提供商	One Time Pin, GitHub

配置完成后，Access 会在这条域名前加一层校验。

访问策略

光配了身份提供商还不够，要指定谁能进。策略（Policy）就是访问规则，定义哪些用户或条件可以通过。

一个应用可以有多条策略，按顺序匹配，命中任一条即放行。策略字段

字段	作用
Policy name	策略名
Action	Allow 允许，Deny 拒绝，Bypass 跳过验证
Include	满足任一条件即匹配
Require	必须同时满足
Exclude	排除特定情况

常见组合

场景	配置
只允许特定邮箱	Include Emails ending with @mycompany.com
只允许 GitHub 组织成员	Include GitHub organization myteam
允许所有人除某 IP	Include Everyone, Exclude IP 1.2.3.4
工作时间才放行	Include Email x@y.com, Require Time 9-18

策略匹配逻辑是 Include 选出候选，Require 进一步约束，Exclude 排除特例，最后 Action 决定放行还是拒绝。

访问流程

用户第一次访问受保护域名时

浏览器访问 admin.example.com
  -> Cloudflare 边缘拦截
    -> 无有效会话，跳转到 Access 登录页
      -> 用户选身份提供商登录
        -> IdP 验证通过，回调 Access
          -> Access 校验策略
            -> 命中 Allow，签发会话 cookie
              -> 重定向回原域名
                -> 带 cookie 再次访问
                  -> 边缘识别 cookie 有效，转发到 Tunnel
                    -> 到达本地服务

会话 cookie 有效期内重复访问不会再次登录，过了 Session Duration 要重新验证。

保护内部应用实例

假设本地跑着一个 Grafana 监控面板，监听 3000 端口，只想给团队成员看。完整配置步骤。

第一，Tunnel 把 Grafana 暴露到 grafana.example.com，config.yml 片段

ingress:
  - hostname: grafana.example.com
    service: http://localhost:3000
  - service: http_status:404

第二，DNS 路由

cloudflared tunnel route dns demo-tunnel grafana.example.com

第三，Zero Trust 控制台创建应用

字段	值
Application name	Grafana 监控
Session Domain	grafana.example.com
Session Duration	12 hours
Identity providers	One Time Pin

第四，添加策略

字段	值
Policy name	允许团队成员
Action	Allow
Include	Emails ending with @myteam.com

保存后访问 grafana.example.com，会先跳到 Access 登录页，输入团队邮箱收到验证码，验证通过才能看到 Grafana。

服务令牌保护 API

不只是浏览器访问，API 调用也要身份验证。Access 服务令牌（Service Token）给机器到机器的调用用。

在 Zero Trust 控制台 Access > Service Auth 里创建服务令牌，得到一对凭证

凭证	形如
Client ID	cfgr2x3b4c5d6e7f8a9b0c1d2e3.service
Client Secret	1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f

调用受保护 API 时在请求头带上这两个值

curl https://api.example.com/data \
  -H "CF-Access-Client-Id: cfgr2x3b4c5d6e7f8a9b0c1d2e3.service" \
  -H "CF-Access-Client-Secret: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f"

Access 识别到服务令牌直接放行，不走 IdP 登录流程。要给策略加上服务令牌的放行规则

字段	值
Action	Allow
Include	Service Token

服务令牌有过期时间，到期自动失效，适合定时任务、CI 调用内部 API 的场景。

审计日志

Access 记录每次登录和访问，在 Zero Trust 控制台 Logs > Audit 里查看。

日志字段	说明
User	登录的用户邮箱
Application	访问的应用
Action	login、allow、deny
IP Address	来源 IP
Timestamp	事件时间
User Agent	浏览器或客户端标识

审计日志能追溯谁在什么时候访问了哪个应用，是否符合预期。异常访问模式比如陌生 IP、非工作时间大量 deny，都能从日志里发现。

小结

Access 给 Tunnel 暴露的服务加了一层身份门禁，把 Zero Trust 的每次访问都验证落到具体应用上。身份提供商对接 Google、GitHub 或 OTP，策略灵活控制谁能进。服务令牌解决机器到机器调用。这套组合让内网服务既能从任意地点访问，又不会被无关人员窥探，比传统 VPN 更轻量也更可控。

上一篇命名隧道与多服务配置