Cloudflare 推出了“一键式”Zero Trust Access 选项，让开发者无需编写任何代码即可锁定内部 Cloudflare Workers 应用。这个新的开关为任何暴露在互联网上的 Worker 添加了基于身份的身份验证，将开放的端点转变为受控的服务。

为什么内部 Workers 需要锁定

AI 驱动的低代码工具让任何人都能在几分钟内搭建起仪表板、数据浏览器和各类小工具。销售主管可以通过提示词引导工具，获得一个功能完备的应用，并将其发布到公共 URL。缺点是：许多此类工具在发布时并没有登录界面，因此任何发现该 URL 的人都可以与应用及其数据进行交互。对于依赖内部工具进行销售、支持或运营的中小型企业来说，这种暴露造成了明显的安全漏洞。

一键式集成的运作方式

  • 单键操作 – 只需点击一次，Cloudflare 就会自动使用其 Zero Trust 网关为应用提供保护。
  • 支持身份提供商 – 用户必须通过 Google Workspace、Microsoft Entra（原 Azure AD）或 Okta 进行身份验证，具体取决于组织的配置。
  • 无需更改代码 – 网关位于 Worker 前端；开发者无需添加身份验证逻辑、编写中间件或重新部署。

其结果是为原本暴露在开放互联网上的 Worker 构建了一个安全周界。

谁将从中受益

该功能面向那些允许非工程师人员搭建内部工具的中小型企业。支持经理可以原型化一个工单查询仪表板，并只需一键即可确保只有经过身份验证的员工才能查看。销售团队可以保护快速收入预测小组件，产品团队则可以屏蔽内部数据可视化工具。

局限性与注意事项

  • 仅限 Workers – 该开关仅适用于 Cloudflare Workers。托管在其他地方的应用仍需使用其自身的身份验证。
  • 依赖 IdP – 安全性取决于所连接的身份提供商（IdP）的强度。如果组织的 Google Workspace 或 Okta 账户遭到破坏，受保护的 Worker 也会面临同样的风险。

后续操作建议

  1. 审计您的 Workers – 列出所有可以通过互联网访问的内部 Worker。
  2. 检查登录机制 – 识别哪些 Worker 缺乏原生的身份验证层。
  3. 开启开关 – 为每个暴露的 Worker 启用 Zero Trust Access，并选择合适的 IdP。

展望未来

安全不再是一个在应用构建完成后必须事后补救的独立项目。通过简单的操作，开发者在保持 Workers 快速迭代优势的同时，也堵住了最明显的暴露点。

来源：dev.to 关于该功能的文章