Cloudflare Access 应用与策略上线清单：Allow/Block/Bypass、Service Auth 和 Session 怎么排

Access 默认拒绝所有未匹配 Allow 策略的流量，但动作顺序、session 层级和 Service Auth 才是上线关键。

1. 01先读摘要，判断是否与你的场景相关。
2. 02再看来源，保留继续查证的路径。
3. 03最后看步骤、风险和可复用动作。

Cloudflare Access 最容易被误解的地方是“建了应用就等于安全了”。实际上，Access 默认拒绝所有未匹配 Allow 策略的流量，但 Bypass、Service Auth、Block、Allow 的执行顺序和 session 时长会共同决定谁能进去、能待多久。下面这套流程按官方文档的 Applications、Policies、Session management 和 Policy tester 顺序排，适合把小团队后台或自托管工具安全发布到公网。

适用场景

• 你要把管理后台、内部工具或自托管应用通过 Cloudflare 暴露到公网。
• 团队使用 Google Workspace、Microsoft Entra 或其他 IdP 作为统一身份源。
• 你需要给不同角色设置不同访问时长，例如正式员工 24 小时、外包 1 小时。
• 你希望 API、cron 或机器对机器流量不弹登录页，但仍受策略和日志约束。

不适用场景

• 应用完全不需要登录，也不需要审计，Bypass 会让 Access 失去记录。
• 你还没有 IdP 和明确的用户组，策略只能按 Everyone 放行，这等于没做控制。
• 你的流量是纯后端 API，且服务端不能正确处理重定向和 session token。
• 你只想把 Access 当成一次性开关，不准备维护策略、日志和回收流程。

准备材料

• Cloudflare Zero Trust 组织权限，能创建 Access applications 和 reusable policies。
• IdP 连接信息，以及至少一个真实测试用户。
• 应用域名、路径、需要公开的端点列表。
• 服务 token 或 mTLS 证书，用于 Service Auth 场景。
• 负责人名单，明确谁能改 Allow、Block、Bypass 和 session 设置。

步骤一：先建立身份源和用户分组

Access 策略的判断依据来自 IdP 属性、设备 posture、国家/地区和 session。先把 IdP 接到 Zero Trust，并确认用户组、邮箱域或身份属性能被读取。不要在还没有用户分组时直接写 “Everyone Allow”，因为后续很难知道谁实际能访问。

1. 在 Zero Trust 的 Access 设置中连接目标 IdP。
2. 验证一个测试用户能完成登录并出现在 Access 身份记录中。
3. 按团队职责建立组，例如 admins、ops、contractors。
4. 在策略中使用组而不是个人邮箱，减少后续维护。

步骤二：把应用分成 self-hosted、SaaS 或非 HTTP 类型

Cloudflare 官方说明 Access 支持 SaaS、self-hosted 和非 HTTP 应用。self-hosted 应用适合你自己控制的域名和源站；SaaS 应用只能控制首次登录和重发 session；非 HTTP 应用适合 SSH、RDP 等。选错类型会导致 session 行为和日志能力不符合预期。

• 管理后台、Jenkins、Grafana 等自己部署的服务选 self-hosted。
• Salesforce、Jira Cloud 等托管 SaaS 按官方 SaaS 应用流程配置。
• SSH/RDP 走非 HTTP 应用，并配置 Cloudflare One 客户端或服务认证。
• 在应用配置里写清域名、路径和是否允许子路径。

步骤三：用 Allow、Block、Bypass 和 Service Auth 组成最小策略

官方文档把策略动作分为 Allow、Block、Bypass 和 Service Auth。Access 默认 deny by default，因此 Allow 策略决定谁能进入；Block 用于在 Allow 中挖出例外；Bypass 会完全关闭 Access 强制并停止请求记录；Service Auth 则允许服务 token 或 mTLS 不登录但仍受策略约束。Bypass 应只在少数必须公开的端点上使用，并且要测试后再上线。

1. 先创建 Include rule 定义初始用户池，例如 admin 组。
2. 用 Require rule 增加必选条件，例如设备 posture 或独立 MFA。
3. 用 Exclude rule 排除离职名单或受限组。
4. 为 API 端点创建 Service Auth 策略，不要用 Bypass 代替服务认证。
5. 只对真正需要公开的静态资源或回调路径使用 Bypass。

步骤四：设置 session 层级，避免一次登录永久有效

官方 session 管理说明存在 global session、application session、policy session 和 client session 多层。global session 控制用户多久需要回到 IdP；application session 是应用默认值；policy session 可以覆盖某类用户的时长；client session 启用时优先于其他设置。通常把 contractors 的 policy session 设短，把管理员设为稍长但不超过业务需求。

• 先设 application session，默认 24 小时通常太长，可先降为 8 小时或 4 小时。
• 外包、客服等低信任角色用 policy session 覆盖为 1 小时。
• 管理员也设置最大 session，不依赖 IdP 无限期会话。
• 高风险应用启用 client session 强制设备重新认证。

步骤五：上线前用 Policy tester 测试真实用户

官方提供 policy tester 可以对组织内现有用户跑测试，并查看某个具体用户会被 Allow、Block 还是 Bypass。上线前至少测试三批人：正常管理员、外包成员、离职账号。不要只测试自己，因为你很可能匹配了所有预期条件。

1. 保存策略后进入 Applications 的 Policy tester。
2. Test policies 查看全组织允许和拒绝比例。
3. 对具体用户执行单用户测试，确认其身份、匹配策略和最终结果。
4. 用无痕浏览器从真实外网访问应用，验证登录页和 session 到期行为。

步骤六：检查日志、撤销和回收

Access 的日志能记录谁登录、谁被拒绝、Bypass 请求不记录。发布后要把日志接到长期存储或 SIEM，并定期检查异常国家、重复失败和离职账号。Bypass 端点因为没有日志，更要单独记录在维护文档里。

• 确认 Access 审计日志能看到成功登录和失败尝试。
• 把异常登录和策略变更通知发给安全负责人。
• 离职时从 IdP 禁用账号，同时删除其在组中的成员关系。
• 每季度检查 Bypass 列表，能改成 Service Auth 的尽快改。

可复制检查表

应用名称：\n应用类型：self-hosted / SaaS / non-HTTP\n域名：\n公开路径：\nIdP：\n用户组：\nInclude / Require / Exclude：\n策略动作：Allow / Block / Bypass / Service Auth\napplication session：\npolicy session：\nclient session：\n服务 token：\nPolicy tester 结果：\n审计日志：\n负责人：

实际例子：小团队把 Grafana 从内网转发改成 Access 发布

一个 8 人团队原来用 VPN 访问 Grafana，新同事配置麻烦，离职账号也常被遗漏。迁移到 Cloudflare Access 后，他们把 IdP 设为 Google Workspace，Grafana 建为 self-hosted 应用；admin 组 Allow + Require 设备 posture，外包只读用户使用 1 小时 policy session。API 健康检查改用 Service Auth token，不再 Bypass。Policy tester 发现两个外包账号仍匹配旧组，清理后正式上线，日志能按用户定位访问记录。

验收清单

• IdP 已连接，用户组能正确返回。
• 应用类型选择正确，域名和路径准确。
• 至少有一个 Allow 策略，未被误设为 Bypass Everyone。
• Block、Exclude 或 Require 已按业务需求配置。
• session 时长已分层，没有永久会话。
• Policy tester 对真实用户结果符合预期。
• 审计日志、异常通知和离职回收流程已就绪。

常见坑

• 把应用配置成 Bypass Everyone，等于让 Access 形同虚设。
• 在 Allow 策略里同时加 Exclude 和 Require，却不知道哪个条件优先。
• 所有用户共享 30 天 session，离职后 IdP 禁用前一直可访问。
• SaaS 应用误以为 Access 能控制应用内部权限。
• API 用 Bypass 代替 Service Auth，导致日志缺失。
• 上线前只测自己，忽略 contractors 和离职账号的匹配结果。

排错路径

• 用户被拒绝：打开 Policy tester 看其匹配了哪些规则，再检查 IdP 属性。
• 登录成功但页面空白：确认源站域名、Host header 和应用路径没有冲突。
• session 过期太快：分别检查 global、application、policy 和 client session 层级。
• API 请求弹登录页：改用 Service Auth token 或 mTLS，确认服务端发送正确凭据。
• Bypass 流量没有日志：这是预期行为，应把 Bypass 改为 Service Auth 或减少使用。

后续维护建议

更新日期：2026-08-16。Access 上线后建议每月复查一次策略和 session 设置，每季度跑一遍 Policy tester，并在 IdP 组变化时重新检查外聘、离职和临时账号。新增应用时先按本清单做测试，不要复制旧应用的 Bypass 配置。Cloudflare One 文档更新后，还应核对策略执行顺序和 Service Auth 行为是否有变化。

公开来源

1. Cloudflare One Docs: Access policies
2. Cloudflare One Docs: Manage Access policies
3. Cloudflare One Docs: Session management