多年来， Cloudflare一直通过我们的 Zero Trust 网络访问（ZTNA） 服务Cloudflare Access 提供身份感知的访问控制，帮助组织现代化对内部资源的访问。通过使用我们针对与公共主机名绑定的 Access 应用的直观工作流程，客户加快了尤其是 Web 应用的 ZTNA 实施。
然而，鉴于我们的架构设计，我们主要通过我们的安全 Web 网关（SWG）服务Cloudflare Gateway 的网络防火墙组件处理专用网络应用访问（与专用 IP 地址或主机名绑定的应用）。我们提供了 Access 的一个小型封装来连接这两种体验。虽然这种实施方式从技术上完成了任务，但存在一些明显的缺点，我们的客户也经常提到这种不一致性。
今天，我们欣然宣布，已重新设计了 Access 中的自托管私有应用管理体验，使其与公共主机名上的 Web 应用体验一致。我们正在推出直接在 Access 中支持专用主机名和 IP 地址定义的应用，以及可重用的访问策略。这些更新共同使 ZTNA 对我们的客户来说更易于部署，并简化了日常策略管理。
为了更好地理解此功能如何改进 Access 的整体功能，我们来探讨一下什么构成了“专用”应用，它们通常是如何访问的，使用此功能之前能做到什么，以及新功能支持什么。如果您是网络专家或爱好者，可以直接跳到“回顾：在 Access 专用 IP 地址和主机名支持推出之前使用 Cloudflare Zero Trust 保护私有应用”部分。
在这种情况下，私有应用指只能通过专用 IP 地址或主机名访问的应用。
专用 IP 地址
专用 IP 地址，通常被称为 RFC 1918 IP 地址，仅限于特定网络范围内使用，只能由该网络上的用户访问。公共 IP 地址在整个互联网中必须是唯一的，而专用 IP 地址可以在各网络中重复使用。任何设备或虚拟机都将拥有一个专用 IP 地址。例如，如果我在自己的 Windows 机器上运行 ipconfig，我可以看到地址是 192.168.86.172。
通过这个地址，我自己网络上的任何其他计算机都可以用来引用该特定计算机并与其进行通信。专用 IP 地址可重复使用，而且只需在其特定网络中是唯一的，因而可用于应用和短暂的基础设施（动态启动/关闭的系统）。这比为资源分配公共 IPv4 地址要容易管理得多 — 实际上，我们已经用尽了可用的公共 IPv4 地址空间！
为了在我的网络中一台机器上托管一个应用，我需要使该应用对网络中的其他机器可用。通常，这是通过将应用分配到特定端口来实现的。然后，对该应用的请求可能形如：http://10.128.0.6:443，这表示“使用超文本传输协议，连接到我网络中地址为 10.128.0.6 的机器，并使用 443 端口。”连接到应用可以在浏览器中进行，通过 SSH、RDP、胖客户端应用，或其他很多通过 IP 地址访问资源的方法。
在这个例子中，我们有一个 Apache2 示例 W 服务器，运行在该地址和端口组合上。
如果我尝试在运行该网络服务器的机器所在网络之外访问这个 IP 地址，那么我要么得不到任何结果，要么会得到一个完全不同的应用（如果在该其他网络中有其他应用运行在相同的 IP 地址/端口组合上）。
专用主机名
我们不希望每次访问该应用时都记住 10.128.0.6 。就像互联网一样，可以在我们的专用网络中使用 DNS 。公共 DNS 充当整个互联网的电话簿，而专用 DNS 则更像是学校通讯录，仅对校园内的电话号码有效。
对于私有应用，我可以配置一个DNS 记录，这与向全世界公开一个公共网站非常相似。相反，我将 DNS 记录映射到一个专用 IP 地址，而这个地址只能在我自己的网络中访问。此外，专用 DNS 不需要向注册商注册域名或遵循已定义的顶级域。我可以在 application.mycompany 上托管应用，这是一个有效的内部 DNS 记录。
在本例中，我在 Google Cloud 上运行 Web 服务器，并将调用应用 kennyapache.local。在我的本地 DNS 中， kennyapache.local 有一个 A 记录，将其映射到我在 Google Cloud (GCP) 上的专用网络中的一个 IPv4 地址。
这意味着我网络中的任何计算机都可以使用 https://kennyapache.local，而不必记住明确的IP地址。
专用网络要求您的机器或虚拟机直接连接到与目标专用 IP 地址或主机名相同的网络。这一个特性有助于防止未授权用户访问应用，但是如果您要使用的应用在本地网络之外，那么就会带来问题。
虚拟专用网络（VPN）、正向代理和代理协议（又名“ PAC 文件 ”）都是让您的专用网络之外的机器访问专用网络内的专用 IP 地址/主机名的方法。这些工具向计算机添加一个额外的网络接口，并指定某些请求需要通过远程专用网络（而不是计算机当前连接的本地网络）路由或进入公共互联网。
当我将设备连接到正向代理（此处指 Cloudflare 的设备客户端 WARP），并运行 ipconfig 命令时，我看到列表中新增一个网络接口和 IP 地址：
这个额外的网络接口将控制特定的网络请求，并将请求路由到一个外部专用网络，而不是我的机器的默认行为，即路由到我自己本地网络上的这个 IP 地址。
回顾：在 Access 专用 IP 地址和主机名支持推出之前使用 Cloudflare Zero Trust 保护私有应用”部分
我们将继续使用托管在 GCP 专用域上的 Apache2 服务器作为示例私有应用。我们将简单介绍一下 Cloudflare Zero Trust，以前是如何用于保护私有应用的，以及为什么这个新功能是向前迈出的一大步。Cloudflare Zero Trust 有两个主要组件用于保护应用流量： Cloudflare Access 和 Gateway。
Cloudflare Access
Cloudflare Access 的作用是在无需传统 VPN 的情况下可保护内部应用和资源。Access 允许组织通过身份提供商（例如 Okta、Azure AD 或 Google Workspace）对用户进行身份验证和授权，然后再授予他们访问内部系统或 Web 应用的权限。
到目前为止，Access 要求应用必须使用公共DNS 记录定义。这意味着，用户必须将其应用暴露在互联网上，才能利用 Access 并使用其所有精细化的安全功能。这并不像听起来那么可怕，因为 Access 允许您实施强大的用户、设备和网络安全控制。实际上，NIST 和许多其他主要安全组织都支持这种模式。
在实践中，管理员可使用我们的应用连接器 Cloudflare Tunnel 将其内部 IP 地址或主机名映射到一个公共 URL。
然后，管理员创建与该公共 URL 对应的 Access 应用。然后，Cloudflare 会对用户发送到该应用的任何请求通过一个单点登录流程。
不过，如果组织严格要求绝不通过公共 DNS 暴露应用，这种方法就行不通了。此外，这不适用于浏览器以外的应用，例如 SSH、RDP、FTP 和其他胖客户端应用，这些都是连接到私有应用的选项。
如果我尝试使用 SSH 登录到我受 Access 保护的公共主机名，我会得到一条错误消息，无法进行身份验证，因为没有简单的方法通过浏览器与 SSH 结合进行单点登录。
访问专用网络应用
在此之前，由于 Access 使用公共主机名运行，我们一直通过 Cloudflare Gateway 的网络防火墙部分为客户处理专用网络访问。几年前，我们推出了访问 Access Private Network 应用，其自动生成所需的 Gateway 阻止策略。然而，这是一种有限制性的方法，最终只是两个 Gateway 策略前面的封装。
Cloudflare Gateway
Cloudflare Gateway 是一个安全 Web 网关，通过过滤和保护 DNS 和 Web 流量，保护用户免遭公共互联网威胁。Gateway 充当最终用户和在线资源之间的保护层，通过执行安全控制来执行安全控制，例如阻止恶意域名、限制访问高风险类别的网站以及防止数据泄露 。
网关还用于将用户流量路由到专用网络中，并充当正向代理。它允许客户为专用 IP 地址和主机名创建策略。这是因为 Gateway 依赖于流量从用户机器代理到 Gateway 服务本身。这通常使用 Cloudflare WARP 客户端完成。WARP 允许配置将哪些 IP 地址和主机名发送到 Gateway 进行过滤和路由。
连接到某个专用网络后，用户可以通过 Gateway 直接连接到为该网络配置的专用 IP 地址和主机名。
然后，我可以配置特定的网络防火墙策略，允许或阻止发往专用 IP 地址的流量。
太棒了！看来我们已经解决了使用 Gateway 保护私有应用的问题。遗憾的是，并非如此，因为 Gateway 的一些组件对于以应用为中心的安全模型而言并不是理想选择。虽然上面没有讨论，但我们在使用 Gateway 进行应用访问控制时遇到了一些挑战，包括：
私有应用与通用 Gateway 网络防火墙规则混合在一起，使配置和维护变得复杂
在 Terraform 中无法定义和管理私有应用
应用访问日志被掩埋在通用网络防火墙日志中（这些日志可以包含一个组织的所有互联网流量！）
Gateway 内的执行依赖于特定的 WARP客户端会话，缺乏细粒度的身份细节
管理员无法使用 Access 规则组或专为管理应用访问控制而构建的其他 Access 功能
我们知道我们可以做得更好。
了解这些限制后，我们着手扩展 Access 的功能，使其支持任何应用，无论是公共还是私有。这个原则指着我们在 Cloudflare Access 中创建统一应用定义的工作。任何自托管的应用，无论是公共可路由的还是专用可路由的，都应该在单一应用类型中定义。结果非常简单直接：Access 应用现在支持专用 IP 地址和主机名 。
然而，工程工作并不像在 Cloudflare Access 中添加私有 IP 地址和主机名选项那么简单。鉴于我们平台的架构，Access 无法自行路由私有请求。对于这个部分，我们仍然必须依赖 Gateway 和 WARP 客户端。
应用感知的防火墙
这意味着我们需要在 Gateway 的防火墙中添加一个特定于应用程序的阶段。这个新阶段检测用户的流量是否与定义的应用匹配，如果匹配，则将流量发送到 Access，对用户及其会话进行身份验证和授权。这需要扩展 Gateway 的网络防火墙，以了解哪些私有 IP 地址和主机名被定义为应用。
得益于这一新的防火墙阶段，管理员现在可以配置在整个网络防火墙中的具体什么位置对其私有应用进行评估。
私有应用会话
我们必须解决的另一个问题是每个应用的会话管理。在 Access 公共应用中，我们以 cookie 的形式发布 JSON Web 令牌（JWT），其中包含了相关过期时间。这相当于会话过期时间。对于私有应用，我们并非总是能够存储 cookie。如果请求不是通过浏览器发出的，就没有地方可以放置 cookie。
对于基于浏览器的私有应用，我们遵循与公共应用完全相同的模式，并发布 JWT 作为跟踪会话的方式。应用管理员也获得了额外的好处，能够对这些应用进行 JWT 验证。非基于浏览器的应用需要向 Gateway 的防火墙添加一个新的应用会话。这些应用会话绑定到特定设备，并跟踪用户下次在访问应用前必须进行身份验证的时间。
访问私有应用
在 Gateway 的防火墙中解决了应用感知和会话管理之后，我们就可以扩展 Access，以支持以专用 IP 地址和主机名定义的应用。管理员现在可以使用专用 IP 地址和主机名直接定义 Access 应用：
您可以看到，私有主机名和私有 IP 地址现在是定义 Access 应用时的配置选项。
如果是非 HTTPS 应用（无论是 HTTP 或非浏览器），用户将收到一个客户端弹出窗口，提示重新验证：
HTTPS 应用的行为与具有公共主机名的 Access 应用的行为将完全相同。系统将提示用户通过单点登录登录，然后向该特定域颁发 JWT。
然后，我们看到一个发布给应用本身的 JWT。
作为这项工作的一部分，我们解决了 Access 中另一个长期存在的痛点——跨多个应用管理策略是一个耗时且容易出错的过程。策略作为嵌套对象存在于各个应用下，这要求管理员要么高度依赖 Access Groups，要么在每个应用中重复相同的配置。
通过可重用策略，管理员现在可以创建标准化的策略（例如高、中或低风险），并跨多个应用分配。对可重用策略进行的一次更改将传播到所有关联的应用，从而大幅简化管理。凭借这一新功能，我们预计许多客户将能够从管理数百个访问策略转变为仅管理少数几个。我们还将“Access Groups”（访问组）更名为“Rule Groups”（规则组），以使其符合实际功能，并避免与身份提供商（IdP）组混淆。
除了这些功能更新外，我们根据多年的用户反馈，对用户界面进行了重大更新。新界面一目了然地提供更多信息，并为定义和管理应用提供一致、直观的工作流程。
虽然今天的发布是一个重大进步，但未来还会有更多新功能推出。目前，私有主机名支持仅限于启用了 TLS 检查端口 443。在 2025 年晚些时候，我们计划将支持扩展到任何端口和协议上的任意私有主机名，进一步扩大 Access 的功能。
这些 Access 新功能现已上线，供您探索。如果贵组织尚未启用现代远程访问方式，欢迎注册一个免费帐户来亲身体验一下。无论是保护私有资源，还是简化策略管理，我们都很期待这些更新能够增强您的 Zero Trust 体验。一如既往，，我们随时为您提供帮助——如有任何问题或反馈，请联系您的客户团队。