出海建站必备：用Cloudflare给你的后台加个安全门槛

vibe coding 的代码安全吗？

网站逐渐有数据之后，不得不考虑安全问题。最先要保护的，通常不是首页，而是后台入口。订单、用户、配置、密钥、内容管理都在后台里，后台一旦被扫到、撞库，或者链接被误分享出去，后面补救会很麻烦。

所以这次我先给后台入口加了一道邮箱白名单。访问者即使知道后台地址，也会先看到 Cloudflare 的登录页，必须用团队白名单里的邮箱收验证码，通过后才会被放行到后台。

同时我也把源站这段补上了 HTTPS 证书，让 Cloudflare 回源访问时走受信任的加密连接。

简单说，这次做的是两层保护：用户访问后台前先过邮箱白名单，Cloudflare 访问源站时走 HTTPS。

这类配置不复杂，但有几个细节很容易被忽略。

先把源站证书签好

源站证书是在 Cloudflare 的 SSL/TLS 里创建的。域名这里填了主域和通配符域名，也就是主域本身加上 *. 开头的子域名。这样后续子域名接入源站 HTTPS 时，不需要为每个后台入口单独重新签一张证书。

这个步骤里最重要的不是点哪个按钮，而是证书创建完成后的处理方式。

Origin Certificate 和 Private Key 会同时展示，私钥只显示这一次。我的做法是单独保存到本地受限权限文件里，再私发给需要部署的人，不放到群聊里，也不贴到工单或公开文档里。（准确来讲是codex的做法）

这一步看起来很普通，但它决定了后面源站和 Cloudflare 之间的 HTTPS 能不能干净跑起来。证书是给源站用的，不是给浏览器直接访问用的，这点也要区分清楚。

再给后台入口套 Cloudflare Access

第二步是在 Zero Trust 里创建一个 Self-hosted application。应用域名配置成后台入口子域名，路径留空，这样整个后台域名都会先经过 Access 判断。

策略采用最简单的邮箱白名单：新建一个 Allow policy，把团队成员的企业邮箱放进 Include 规则。这样访问后台的人不用记一组共享密码，只要邮箱在白名单里，就能通过邮箱验证码进入。离职或权限调整时，也只需要改白名单，不需要到处同步新密码。

Access policy 保存后的白名单策略

这个配置里我还特意把 Browser rendering 关掉。它是给浏览器内 RDP、SSH、VNC 这类场景用的，普通 Web 后台不需要开。误开以后页面上会多出不相关的协议选择，保存前最好回头看一眼。

保存后一定回看一次

这次有个小坑：Session Duration 页面上选过以后，前端显示和真实保存值不一定马上一致。最稳的做法是保存后重新回到应用详情或应用列表，看最终值有没有落下去。

这次最终配置里，后台应用是 Self-hosted，目的地是后台子域名，策略是 team-allowlist，Session Duration 保存为 1 week，也就是 168 小时。应用列表里也能看到应用、域名、策略和类型都已经挂上。

Cloudflare Access 的好处是它把“谁可以进后台”这件事前置到了边缘层。后台服务本身可以少暴露一层登录保护细节，团队权限也更容易集中管理。

这次可以复用的检查清单

配置完成后，我会固定检查四件事。

第一，源站证书的域名范围是不是覆盖主域和需要的子域名。

第二，私钥有没有只通过私密渠道交付。

第三，Access 应用的 destination、policy、session duration 是否保存后仍然正确。

第四，登录方式是不是符合团队预期，普通后台优先用邮箱验证码，先不接第三方登录。

这个流程适合所有临时上线的后台、运营工具、内部管理面板。只要入口是一个域名，就可以先用 Cloudflare Access 挡一层，把权限控制从业务代码里拿出来，后续再按需要补更细的应用内权限。