一键保护你的内部应用程序
AI 使每个团队的员工能够比以往更快地构建应用程序。但这种快速发展也让每位 CISO 在夜里难以入眠：任何员工都可以构建一个应用程序，将其部署到公共互联网，并不小心暴露内部工作或公司数据。
今天，我们推出了新工具，使您可以轻松保持在 Workers 上托管的应用程序私密。您现在可以直接将 Cloudflare Access 应用到某个 Worker 或您账户中的每个 Worker，从而使您的应用程序默认通过公司登录保护，无需依赖每个开发人员自行设置。
您可以：
- **在账户级别设置政策**，确保所有 [预览](https://developers.cloudflare.com/pages/configuration/preview-deployments/) 和生产部署默认受公司登录保护。
- **对单个应用程序设置政策**，确保每个与其相关的域名都强制进行身份验证，无论它是如何部署的。
- **确切查看谁在访问您的应用程序。** 直接在您的代码中获得每个经过身份验证的用户的电子邮件、姓名和组，无需进行 JWT（JSON Web Token）验证。
- **部署一个内部平台，确保所有部署默认私密。** 我们开源了一个 [示例](https://github.com/cloudflare/templates/tree/main/internal-sites-template)：一个内部静态站点平台，所有部署的 Worker 都是私密的。
## 在 Workers 上的 Access：工作原理
当您在 Worker 上启用 Access 时，Cloudflare 会在任何请求到达您的应用程序代码之前强制进行身份验证。请求到达 Worker 的方式无关紧要，无论是通过自定义域、路由、workers.dev 子域，还是预览 URL。如果启用了 Access，用户必须首先进行身份验证。
以前，您需要在主机名级别进行配置，这意味着需要在 Worker 可访问的每个域上设置 Access 策略。如果您想为 Worker 添加一个新的自定义域，您需要先更新 Access 策略，否则该主机名将可以无身份验证访问。
现在，该策略附加到 Worker 本身，因此与该 Worker 相关的任何域或 URL 都会自动受到保护。您可以选择保护哪些内容：仅预览 URL，或所有主机名。
如果您设置为仅预览，每个为该应用程序创建的预览 URL，无论是 [workers.dev](http://workers.dev) 预览 URL 还是您用于预览的自定义域，在您部署新版本时都将需要身份验证。如果您设置为所有主机名，与该 Worker 相关的每个域都受到保护，包括自定义域、路由、[workers.dev](http://workers.dev) 子域和预览 URL。
Access 让您控制用户的身份验证方式。您可以连接现有的身份提供程序，以便员工使用他们已经使用的凭据登录，或者限制访问特定电子邮件地址、电子邮件域或组。对于代理，您可以通过服务令牌授予访问权限。
在 [Cloudflare Access for Workers 文档](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) 中了解更多信息。
## 默认将每个 Worker 设为私密
如果您的组织中有开发人员正在部署 Workers，您不想依赖每个人都记得启用 Access。您希望默认设置为私密。
您可以在账户级别设置一次 Access 策略，您账户中的每个 Worker，从创建之时起就是私密的。
您可以选择政策覆盖范围：仅预览 URL 流量、所有生产流量，或两者兼而有之。仅预览在您的生产 Workers 有意公开时很有用，但您永远不想暴露正在进行中的部署。
需要将某个 Worker 设置为公开？可以在该 Worker 上绕过账户范围的政策。
### 保护特定 Worker
如果您不需要账户级别的默认设置，只想锁定一个特定的 Worker，您可以直接将 Access 应用到该 Worker。
Worker 视图中的新 Access 选项卡显示该应用程序适用的政策。如果您有多个，最特定的会优先：主机名政策优先，然后是 Worker 政策，最后是账户政策。
## 查看访问您应用程序的人
当 Access 保护您的 Worker 时，您可以获取有关每个请求的信息——他们的电子邮件、姓名和组——这样您就可以个性化他们看到的内容、强制执行权限，或者记录每个用户的活动。
这通过您的 [Worker 的上下文对象 (ctx)](https://developers.cloudflare.com/workers/runtime-apis/context/) 实现。每个对您 Worker 的请求都携带一个 ctx，包含关于该请求的元数据。当 Access 启用时，我们将经过身份验证的用户身份附加到它上面作为 ctx.access。接下来，调用 `ctx.access.getIdentity()` 来获得用户的电子邮件、姓名和 [更多信息](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/)。
以前，这意味着需要自己验证 JWT——解析令牌、验证签名并提取声明。而现在，当 Access 在您的 Worker 上启用时，每个经过身份验证的请求都包含 ctx.access。
获取用户身份所需的内容如下：
## 在部署之前进行本地测试
我们展示了如何使用 `ctx.access.getIdentity()` 提供有关请求发起者的信息——他们的电子邮件、姓名和组。
您可以在使用 wrangler dev 开发本地时使用此功能。在您的 `wrangler.jsonc` 中添加一个 access 块，以模拟经过身份验证的用户：
您的 Worker 通过 `ctx.access.getIdentity()` 获取该信息——返回的身份对象的形状与您在生产中得到的一样。更改配置中的电子邮件以测试不同用户。
这意味着您可以在每次进行更改时验证正确内容是否显示给正确的用户，而无需每次都进行部署并通过 Access 签入。
## 部署一个每个应用程序默认都是私密的内部平台
如果您管理一个内部平台，员工可以原型设计和部署应用程序，则需要使每个应用程序在未配置访问控制的情况下默认私密。
[Workers for Platforms](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) 让您可以大规模部署 Workers。每个 Worker 都存在于一个命名空间内，所有流量都通过一个单一的入口点：dispatch Worker。
对您的 dispatch Worker 设置 Access 策略后，通过它部署的每个 Worker 默认都是私密的。
我们还有一个 [开源示例](https://github.com/cloudflare/templates/tree/main/internal-sites-template)，您可以用来自行部署内部拖放部署平台——只需在调度 Worker 上配置一次访问，所有通过它部署的站点默认都是私密的。
点击下面的按钮自己部署吧！
有关完整架构，请参见我们的 [Workers for Platforms 参考架构](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/)。
## 建立在坚实基础之上
此功能的实现得益于 FL2，这一新的 [基于 Rust 的模块化代理](https://blog.cloudflare.com/20-percent-internet-upgrade/)，为 Cloudflare 的边缘计算提供支持。Access 是您应用程序的前门，因此它传统上在请求管道中的所有 Worker 逻辑之前运行。但为了让 Access 应用程序能够针对特定 Worker，而不是它们的主机名，Access 需要知道某个请求要到达哪个 Worker。因此，我们需要将 Workers 的 **路由** 与 Workers 的 **执行** 分开，并移动路由逻辑，以便在 Access 之前运行。
在我们基于 NGINX 的旧 FL1 系统中，使用 Lua 编写的模块，这一变更会变得复杂且有风险。产品之间的交互可能非常微妙，而将逻辑移动到请求管道的早期阶段，如果依赖于由其他产品修改的共享状态，可能会很不安全。
FL2 让这一切都变得简单。它严格的模块系统将逻辑分为明确且一致的阶段，声明其输入和输出。我们能够依赖编译器发现各阶段之间的任何破损交互，并自信地逐步推出这一重构。
## 今天就来尝试
该功能现已向所有人开放。可以在 [仪表盘](https://dash.cloudflare.com/account/workers-and-pages) 中进行尝试，或者阅读 [Cloudflare Access for Workers 文档](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) 开始使用。
## 感谢
感谢 Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt "TK" Taylor、Brendan Irvine-Broque、Yomna Shousha 和 Mike Aizatsky 进行的工程和设计工作，使这一切成为可能！
---
原文链接：[点击查看](https://blog.cloudflare.com/workers-protected-by-access/)
今天，我们推出了新工具，使您可以轻松保持在 Workers 上托管的应用程序私密。您现在可以直接将 Cloudflare Access 应用到某个 Worker 或您账户中的每个 Worker，从而使您的应用程序默认通过公司登录保护，无需依赖每个开发人员自行设置。
您可以：
- **在账户级别设置政策**，确保所有 [预览](https://developers.cloudflare.com/pages/configuration/preview-deployments/) 和生产部署默认受公司登录保护。
- **对单个应用程序设置政策**，确保每个与其相关的域名都强制进行身份验证，无论它是如何部署的。
- **确切查看谁在访问您的应用程序。** 直接在您的代码中获得每个经过身份验证的用户的电子邮件、姓名和组，无需进行 JWT（JSON Web Token）验证。
- **部署一个内部平台，确保所有部署默认私密。** 我们开源了一个 [示例](https://github.com/cloudflare/templates/tree/main/internal-sites-template)：一个内部静态站点平台，所有部署的 Worker 都是私密的。
## 在 Workers 上的 Access：工作原理
当您在 Worker 上启用 Access 时，Cloudflare 会在任何请求到达您的应用程序代码之前强制进行身份验证。请求到达 Worker 的方式无关紧要，无论是通过自定义域、路由、workers.dev 子域，还是预览 URL。如果启用了 Access，用户必须首先进行身份验证。
以前，您需要在主机名级别进行配置，这意味着需要在 Worker 可访问的每个域上设置 Access 策略。如果您想为 Worker 添加一个新的自定义域，您需要先更新 Access 策略，否则该主机名将可以无身份验证访问。
现在，该策略附加到 Worker 本身，因此与该 Worker 相关的任何域或 URL 都会自动受到保护。您可以选择保护哪些内容：仅预览 URL，或所有主机名。
如果您设置为仅预览，每个为该应用程序创建的预览 URL，无论是 [workers.dev](http://workers.dev) 预览 URL 还是您用于预览的自定义域，在您部署新版本时都将需要身份验证。如果您设置为所有主机名，与该 Worker 相关的每个域都受到保护，包括自定义域、路由、[workers.dev](http://workers.dev) 子域和预览 URL。
Access 让您控制用户的身份验证方式。您可以连接现有的身份提供程序，以便员工使用他们已经使用的凭据登录，或者限制访问特定电子邮件地址、电子邮件域或组。对于代理，您可以通过服务令牌授予访问权限。
在 [Cloudflare Access for Workers 文档](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) 中了解更多信息。
## 默认将每个 Worker 设为私密
如果您的组织中有开发人员正在部署 Workers，您不想依赖每个人都记得启用 Access。您希望默认设置为私密。
您可以在账户级别设置一次 Access 策略，您账户中的每个 Worker，从创建之时起就是私密的。
您可以选择政策覆盖范围：仅预览 URL 流量、所有生产流量，或两者兼而有之。仅预览在您的生产 Workers 有意公开时很有用，但您永远不想暴露正在进行中的部署。
需要将某个 Worker 设置为公开？可以在该 Worker 上绕过账户范围的政策。
### 保护特定 Worker
如果您不需要账户级别的默认设置，只想锁定一个特定的 Worker，您可以直接将 Access 应用到该 Worker。
Worker 视图中的新 Access 选项卡显示该应用程序适用的政策。如果您有多个，最特定的会优先：主机名政策优先，然后是 Worker 政策，最后是账户政策。
## 查看访问您应用程序的人
当 Access 保护您的 Worker 时，您可以获取有关每个请求的信息——他们的电子邮件、姓名和组——这样您就可以个性化他们看到的内容、强制执行权限，或者记录每个用户的活动。
这通过您的 [Worker 的上下文对象 (ctx)](https://developers.cloudflare.com/workers/runtime-apis/context/) 实现。每个对您 Worker 的请求都携带一个 ctx，包含关于该请求的元数据。当 Access 启用时，我们将经过身份验证的用户身份附加到它上面作为 ctx.access。接下来，调用 `ctx.access.getIdentity()` 来获得用户的电子邮件、姓名和 [更多信息](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/)。
以前，这意味着需要自己验证 JWT——解析令牌、验证签名并提取声明。而现在，当 Access 在您的 Worker 上启用时，每个经过身份验证的请求都包含 ctx.access。
获取用户身份所需的内容如下：
## 在部署之前进行本地测试
我们展示了如何使用 `ctx.access.getIdentity()` 提供有关请求发起者的信息——他们的电子邮件、姓名和组。
您可以在使用 wrangler dev 开发本地时使用此功能。在您的 `wrangler.jsonc` 中添加一个 access 块，以模拟经过身份验证的用户：
您的 Worker 通过 `ctx.access.getIdentity()` 获取该信息——返回的身份对象的形状与您在生产中得到的一样。更改配置中的电子邮件以测试不同用户。
这意味着您可以在每次进行更改时验证正确内容是否显示给正确的用户，而无需每次都进行部署并通过 Access 签入。
## 部署一个每个应用程序默认都是私密的内部平台
如果您管理一个内部平台，员工可以原型设计和部署应用程序，则需要使每个应用程序在未配置访问控制的情况下默认私密。
[Workers for Platforms](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) 让您可以大规模部署 Workers。每个 Worker 都存在于一个命名空间内，所有流量都通过一个单一的入口点：dispatch Worker。
对您的 dispatch Worker 设置 Access 策略后，通过它部署的每个 Worker 默认都是私密的。
我们还有一个 [开源示例](https://github.com/cloudflare/templates/tree/main/internal-sites-template)，您可以用来自行部署内部拖放部署平台——只需在调度 Worker 上配置一次访问，所有通过它部署的站点默认都是私密的。
点击下面的按钮自己部署吧！
有关完整架构，请参见我们的 [Workers for Platforms 参考架构](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/)。
## 建立在坚实基础之上
此功能的实现得益于 FL2，这一新的 [基于 Rust 的模块化代理](https://blog.cloudflare.com/20-percent-internet-upgrade/)，为 Cloudflare 的边缘计算提供支持。Access 是您应用程序的前门，因此它传统上在请求管道中的所有 Worker 逻辑之前运行。但为了让 Access 应用程序能够针对特定 Worker，而不是它们的主机名，Access 需要知道某个请求要到达哪个 Worker。因此，我们需要将 Workers 的 **路由** 与 Workers 的 **执行** 分开，并移动路由逻辑，以便在 Access 之前运行。
在我们基于 NGINX 的旧 FL1 系统中，使用 Lua 编写的模块，这一变更会变得复杂且有风险。产品之间的交互可能非常微妙，而将逻辑移动到请求管道的早期阶段，如果依赖于由其他产品修改的共享状态，可能会很不安全。
FL2 让这一切都变得简单。它严格的模块系统将逻辑分为明确且一致的阶段，声明其输入和输出。我们能够依赖编译器发现各阶段之间的任何破损交互，并自信地逐步推出这一重构。
## 今天就来尝试
该功能现已向所有人开放。可以在 [仪表盘](https://dash.cloudflare.com/account/workers-and-pages) 中进行尝试，或者阅读 [Cloudflare Access for Workers 文档](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) 开始使用。
## 感谢
感谢 Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt "TK" Taylor、Brendan Irvine-Broque、Yomna Shousha 和 Mike Aizatsky 进行的工程和设计工作，使这一切成为可能！
---
原文链接：[点击查看](https://blog.cloudflare.com/workers-protected-by-access/)
评论
暂无评论。