一键保护所有内部vibe-coded应用
内容提要
Cloudflare推出新工具，使Workers应用默认私有化。用户可在账户或单个Worker级别设置Access策略，强制所有部署需公司登录认证，无需开发者手动配置。代码中可直接获取用户身份信息，无需验证JWT。该功能基于FL2架构实现，现已全面开放。
延伸解读
默认私有化：从源头降低数据泄露风险
文章指出，AI让员工能快速构建应用，但也可能意外将内部工作或公司数据暴露到公网。Cloudflare的新功能允许在账户级别设置Access策略，使所有Worker部署默认需要公司登录认证，无需开发者手动配置。这从源头减少了因开发者疏忽或配置遗漏导致的数据泄露风险，尤其适合拥有大量内部应用的组织。
策略优先级与灵活性：兼顾安全与公开需求
新功能提供了多级策略设置：账户级、Worker级和主机名级。当多个策略同时存在时，最具体的优先（主机名>Worker>账户）。这意味着组织可以设置全局默认私有，同时允许特定Worker或主机名公开（如面向公众的网站）。这种灵活性让安全团队能统一管控，又不妨碍必要的公开访问。
简化身份集成：无需手动验证JWT
启用Access后，Worker代码中可直接通过ctx.access.getIdentity()获取用户身份信息（如邮箱、姓名、组），无需自行解析和验证JWT。这简化了开发流程，减少了因JWT验证错误导致的安全漏洞。同时，本地开发时可通过wrangler配置模拟身份，方便测试不同用户场景。
技术架构升级：FL2支撑新功能
该功能基于Cloudflare的FL2架构实现，它采用Rust编写的模块化代理，将路由逻辑与执行分离，使Access能在请求到达Worker前进行认证。相比旧系统，FL2的模块化设计让这种跨产品改动更安全、更易部署。这体现了底层架构升级对产品能力扩展的重要性。
Q&A
Cloudflare 新推出的工具如何帮助保护内部 vibe-coded 应用？
Cloudflare 推出了新工具，允许用户将 Cloudflare Access 直接应用到 Worker 或账户级别的所有 Worker，使得应用默认需要公司登录认证，无需开发者手动配置。
如何在 Cloudflare Workers 上为单个应用设置访问策略？
您可以在 Worker 视图中找到新的 Access 标签页，直接为单个 Worker 设置 Access 策略。策略会应用于该 Worker 关联的所有域名，包括自定义域名、路由、workers.dev 子域名和预览 URL。
账户级别的 Access 策略如何工作？
您可以在账户级别设置一次 Access 策略，该策略将应用于账户中所有现有的和未来的 Worker。您可以选择保护预览 URL、生产流量或两者。如果需要某个 Worker 公开，可以单独绕过该策略。
如何在 Worker 代码中获取已认证用户的信息？
当 Access 启用时，每个请求的上下文对象（ctx）会包含 ctx.access。您可以调用 ctx.access.getIdentity() 来获取用户的邮箱、姓名和组等信息，无需自己验证 JWT。
如何在本地开发时模拟已认证用户？
在 wrangler.jsonc 中添加 access 块，配置 dev 对象，包含 aud 和 identity（如 email）。这样在 wrangler dev 中，ctx.access.getIdentity() 会返回模拟的身份信息，方便测试不同用户。
Workers for Platforms 如何实现所有部署默认私有？
通过 Workers for Platforms，所有 Worker 都位于命名空间中，流量通过一个 dispatch Worker 进入。您只需在 dispatch Worker 上设置 Access 策略，所有通过它部署的 Worker 都会默认私有。
Cloudflare 的 FL2 架构如何支持这一新功能？
FL2 是 Cloudflare 新的基于 Rust 的模块化代理，它允许将 Workers 路由逻辑与执行逻辑分离，使 Access 可以在路由阶段之前运行，从而能够针对单个 Worker 而不是主机名进行访问控制。FL2 的严格模块系统使得这种重构安全可靠。
