两三个人的 SaaS 团队最容易忽略访问控制。大家都忙着发版，后台先用一个密码，预览环境直接发链接，Grafana 或日志面板藏在一个没人记得的子域名下。直到兼职同事离开、外包拿着旧链接还能打开页面，才开始补。

Cloudflare Zero Trust 不是大公司专属。小团队更应该早做，因为系统少，迁移成本低。

先保护哪些应用？

按风险排序，不按技术栈排序。

优先级应用原因
P0管理后台、数据库控制台、支付后台跳转页能改用户数据和钱
P1GitHub / Vercel / Cloudflare preview可能暴露未发布功能和调试信息
P1日志、监控、错误追踪有用户数据、token、请求内容
P2内部文档、Notion 镜像、运营看板信息泄露风险高
P3Demo、临时工具容易被忘记

不要一开始就追求全覆盖，把 P0 和 P1 做掉，团队会马上感到差异。

Cloudflare Access 的基本模型是：给一个应用域名配置 Access application，再用 policy 决定谁能访问。身份源可以是 Google Workspace、GitHub、Azure AD、Okta，也可以先用 email pin。

Cloudflare Access 最小配置怎么做？

以 admin.example.com 为例：

  1. 在 Cloudflare Zero Trust 控制台里添加 Access application。
  2. 类型选 self-hosted，域名填 admin.example.com。
  3. 绑定身份源，比如 Google Workspace 或 GitHub。
  4. 添加 allow policy，只允许公司邮箱域名或指定成员。
  5. 打开 session duration，别设太长。内部后台 8 到 24 小时比较合理。
  6. 测试无痕窗口访问，确认未登录会被拦截。
  7. 再用普通成员账号测试，确认能进应用但没有管理员权限。

这里有个细节：Access 只证明这个人能进这个域名，不代表他在应用里应该是 admin。你的应用仍然要有角色权限。不要因为外层有 Access，就让内部后台默认全员管理员。

团队成员和设备怎么管？

小团队可以先用「身份 + 邮箱域名」起步，等人多了再加设备姿态。不要第一天就搞复杂策略，否则大家会绕流程。

我会这样分阶段：

阶段做法
1-5 人Google / GitHub 登录 + 指定邮箱 allowlist
5-15 人按角色分组，后台、监控、文档分开策略
15 人以上加设备要求、国家或地区规则、日志审计

离职流程要写清楚：

  • 从身份源移除账号。
  • 从 Cloudflare Access group 移除成员。
  • 轮换共享过的 API key。
  • 检查最近 30 天访问日志。
  • 关闭对方设备上的密码管理器共享。

别只改应用密码。远程团队的入口往往不止一个。

预览环境要怎么处理？

Vercel preview、Cloudflare Pages preview、临时 staging 域名都应该加 Access。原因很简单：这些页面最容易被复制到 Linear、Slack、Notion、微信群，然后没人知道谁打开过。

推荐做法：

场景访问策略
PR preview只允许工程和产品成员
staging允许团队成员和指定测试客户
internal docs只允许公司邮箱
public demo不加 Access，但不要放真实数据

如果你要给外部测试客户看 staging，不要把客户加进全局团队组。单独建一个 Access group，只允许访问那一个域名，并设置较短 session。

跨地区远程工作要注意什么？

远程团队常见问题不是「某个人进不去」，而是「每个人的登录环境都不一样」。A 在共享办公，B 在酒店 Wi-Fi，C 在家里，D 用手机热点。排查访问问题时，很难判断是身份源、DNS、Cloudflare、应用本身还是本地网络。

我建议给核心成员固定一套工作访问方式。尤其是要处理 GitHub Actions、Cloudflare、Stripe、监控后台的人，不要频繁切换环境。需要长期协作时，可以准备 独立开发者出海稳定专线，再配合密码管理器、2FA 和 Access policy。线路只解决连通性，权限还是要靠身份和策略。

同时准备一张排查表：

问题看哪里
登录页打不开DNS、Cloudflare 状态、浏览器 Network
身份验证失败身份源、邮箱、组织成员状态
通过 Access 后应用 403应用内角色权限
只有某地失败本地网络、DNS、运营商路径
全员失败Access policy 或应用部署

应急账号怎么留？

一定要有 break-glass 方案。不是为了偷懒，而是防止身份源故障或策略写错时全员被锁在门外。

我的最低配置：

  • 至少两个 founder 管理员。
  • 一个独立保存的 Cloudflare 备份登录方式。
  • 关键域名和 DNS 修改需要二次确认。
  • Access policy 改动先在 staging 应用测试。
  • 应急账号不用于日常登录，只定期验证可用。

应急账号也要有审计。谁用过、什么时候用、为什么用，写下来。否则它会变成新的共享后门。

上线前检查清单

  • P0 和 P1 应用已列完整。
  • 每个应用都有 owner。
  • Access application 域名配置正确。
  • 身份源可用，至少两个管理员能登录。
  • 普通成员只拿到需要的应用。
  • 应用内角色没有被 Access 替代。
  • preview 环境不会裸露内部页面。
  • 离职回收流程包含 Access、身份源、密码管理器和 API key。
  • break-glass 账号测试过，但不用于日常。

Zero Trust 不是把所有东西都锁死。对小团队来说，它更像一套好习惯：谁能访问、为什么能访问、离开后怎么收回。写清楚，比临时补洞强。

相关阅读