大多数 Cloudflare 的文档（通常也是该领域大多数供应商的文档）都是在假设采用 Zero Trust 产品需要放弃某些东西的前提下编写的。在没有构建任何内容，或者没有工具可以实现您的团队试图完成的目标的情况下，这有时可能会令人困惑和疏远。新的初创公司尤其服务不足；当您将所有精力都集中在启动业务上时，阅读针对正在经历网络转型的企业编写的文档可能会非常耗时或令人困惑。
本指南介绍了如何在您建立安全、网络和开发运营实践的早期，使用 Cloudflare 建立 Zero Trust 架构的基础 — 目标是创建一个基于 Zero Trust 安全原则的、可持续且可扩展的业务。
建立“业务”的共同原则已经发生了根本性的变化。二十年前，这可能看起来像获得办公空间（或车库），购买一些硬件基础设施、服务器和用户机器以开始构建。随着构建的继续，您添加硬件堆叠的防火墙和安全设备以创建企业边界，并保护主要存在于一个地方的事物。关于网络和安全实践的演变，有很多很好的书面内容，所以我们在这里不再赘述；重要的细节是认识到“新”模型在您构建时对您的初创公司意味着什么。
今天，您的大部分基础设施很有可能存在于公共云提供商中。您的大部分代码将通过常见的存储库管理工具推送和审查，您的大部分开发人员将在 MacOS 或 Linux 机器上编写代码，并且可能在很大程度上依赖某种形式的容器化进行本地开发。在这种模式下，当您的业务发展到包含多个复杂功能、部门以及不断扩大的资产和数据集时，Zero Trust 安全原则同样相关 — 尽管更容易实现。
使用 Cloudflare Zero Trust 是初创公司开发全面 Zero Trust 战略的一种简单（有时是免费的！）方法，该战略将随您的业务有机地发展。
Cloudflare 有很多与我们的 Zero Trust 产品集的迁移和实施相关的现有内容。本文档直接面向年轻初创组织的技术创始人或创始工程师，他们希望从第一行代码开始，使用现代安全控制开发现代企业网络的框架。
在本文档中，我们将探讨：
- 开始使用实用的 Zero Trust 远程访问 (ZTNA) 功能
- 建立身份、设备状态的事实来源，并学习如何使用它们
- 网络构建，包括传统和网状网络
- 将 Zero Trust 构建到内部工具中
- 审查互联网上的威胁
- TLS 解密及其与您目标的相关性
- 探索 SaaS 工具的 Zero Trust
- 导航承包商和客户访问
- 使用基础架构即代码 (IaC) 进行构建
本文档中未明确涵盖的一些内容：
- 基本 Zero Trust 术语和概念的介绍
- 对特定第三方供应商使用的建议或反对建议（虽然本文档中提到了其他供应商，但这纯粹是说明性的，不应被视为 Cloudflare 的正式建议）
- 关于为什么应该探索采用 Zero Trust 安全方法的详细信息（我们在下面的链接中有很多详细说明此内容的良好资源）
- 微分段和自治 Zero Trust 概念（这些可能会在将来的更新中涵盖）
- 无密码身份验证（这是一个很酷且新兴的领域，我们将来会在这里提供一些建议）
为了建立对 Cloudflare 的更强基础了解，我们建议您使用以下资源：
- Cloudflare 是什么？| 网站 ↗（5分钟阅读）或 视频 ↗（2分钟）
- 博客：Zero Trust, SASE, and SSE: foundational concepts for your next-generation network ↗（14分钟阅读）
- 参考架构：Evolving to a SASE architecture with Cloudflare（3小时阅读）
在考虑您的远程访问或安全目标之前，清点您当前的资产非常重要。考虑以下问题的答案：
- 已经存在哪些东西，并且需要一个可持续的安全模型？
- 如果您已经开始在公共云提供商中构建基础架构，您已经建立了多少个不同的虚拟私有云 (VPC)？它们之间如何通信？更重要的是，您的用户如何以及为何访问这些环境？
- 是否都是通过控制台和基于浏览器的管理工具或终端工具？
- 您是否已经通过 HTTPS 或 SSH 为某些服务设置了公共 IP 访问？
- 是否存在可能允许从互联网访问但旨在完全私有的资源？
- 您是否建立了传统的 VPN 以允许对环境进行远程访问？它是如何进行门控的？
接下来，建立您的物理和虚拟专用基础架构（本质上是任何包含公司数据的事物）的地图。对于许多初创公司来说，这可能只是通过单个云提供商实施。记下该环境中由人类用户、其他基础架构或公共/私有 API 访问的所有资源 — 然后记录每个接收常规流量的服务的用途。在这样做的同时，尝试回答以下问题：
- 这是一个构建用于监控您的构建管道的内部基于 Web 的工具吗？
- 它是一个像 Grafana 这样的自托管分析工具，还是像 Prometheus 这样的支持指标服务器？
- 用户是如何访问该服务的 — 通过公共 IP、私有 IP 还是本地路径？
- 用户是否能够从其他云环境或 VPC 访问该服务？如果是，它们是如何连接的？
一旦您列出了现有资源的全面列表，这将作为您开发 Zero Trust 架构的资产清单。如果您不知道需要保护什么，即使您拥有多少安全工具，也很难保护它。
有价值的第三步可能是开始按漏洞发生时的风险级别对这些服务进行排名，以便稍后确定您的安全策略的具体性。例如，您的用于就构建状态发出警报的内部工具可能是 3 级，但您用于存储客户信息的生产数据库将是 1 级。如果用户能够满足您的身份控制要求，他们可能能够在自己的设备上访问 3 级应用程序，但 1 级应用程序可能需要从公司设备访问并使用特定类型的多因素身份验证 (MFA)。
许多使用 Cloudflare 的初创公司都受到外部来源的鼓励采用 Zero Trust 安全态势：投资者、合作伙伴、供应商、风险分析师或合规官员。即使这是由外部各方推动的项目或评估，您仍然可以设定共同目标以确保其产生可衡量、期望的影响。
我们从客户那里听到的一些常见目标：
- 使我们的用户能够轻松安全地访问内部工具
- 将安全性构建到开发管道中
- 在不牺牲用户和工作体验的情况下提高安全性
- 定义和执行自带设备 (BYOD) 战略
- 简化网络和应用程序访问的管理
- 保护 SaaS 应用程序和公司网络上的数据
- 确保可审计性（“快速查看正在发生的事情、谁在做，以及是否没问题”）
- 向我们的客户和最终用户展示安全最佳实践
您的目标也可能比这更简单或更具战术性；例如，采用现代远程访问工具，安全地连接我的内部网络，或仅允许公司设备连接到我的 Gitlab Enterprise 租户。无论您的目标是什么，目标设定中最重要的元素是确定您现在需要什么，并根据您在近期或中期可能需要或期望的需求来平衡它。如果您打算大幅增长，期望与要求苛刻的安全审查的客户签约，或准备申请新的合规认证（例如 SOC II 或 PCI）。为了实现这一目标，从 Zero Trust 供应商开始至关重要，该供应商可以帮助添加额外的安全工具和功能，而不会呈指数级增加复杂性或成本。
目标设定也是确定优先级的一项重要练习。如果您知道您的主要目标是识别所有内部服务并在其前放置具有身份意识的安全保护，但在接下来的六个月中您打算限制 BYOD 对 3 级应用程序的使用，那么您的第一个目标需要战略性地支持第二个目标的执行。了解未来几个月优先事项的排名（知道初创公司中事情变化很快！）可以节省您在重新架构讨论上花费的时间，或者与那些在短期内满足您需求但不在中期的供应商拆解技术或商业决策。
身份是每个 Zero Trust 战略的核心。最终，大多数客户目标围绕使用集中身份源来验证、验证和记录用户采取的所有操作，涵盖“自有”（托管、私有网络）应用程序和 SaaS 应用程序。身份（例如，通过 SSO 提供商）然后可用于添加额外的安全控制，如多因素身份验证或抗网络钓鱼身份验证。
您在早期可以做的最重要的事情之一是指导用户习惯使用多因素身份验证。像物理密钥、本地身份验证器和生物识别身份验证等抗网络钓鱼的 MFA 选项，被 Cloudflare 认为是阻止 2022 年影响 Twilio 和其他 SaaS 公司的违规尝试 ↗的一个主要因素。
在开始使用 Zero Trust 的背景下，您决定使用的身份提供商类型（Google Workspace 和 Microsoft Entra Identity 是最常见的）不如您的实施策略重要。只要您拥有一个安全的目录，允许抗网络钓鱼的身份验证方法，并被指定为您的事实来源，您就拥有与 Cloudflare 等 Zero Trust 供应商集成并为所有公司工具提供连续验证该身份即安全状态的必要组件。
许多目录服务还提供直接与 SaaS 应用程序集成的单点登录 (SSO) 解决方案。虽然这是一个简单且合乎逻辑的选择，但许多企业应用程序使 SSO 集成成为一项挑战，而且将大量的 SaaS 应用程序加载到任何一个目录服务可能会导致供应商锁定。随着您的组织不断发展，您的身份战略不可避免地会发生变化和成熟，保持灵活性以应对意想不到的挑战（例如我们在 2023 年看到的一些供应商违规事件）非常重要。
除了与灵活性相关的挑战外，许多 SSO 提供商尚未将设备状态概念完全集成到其“事实来源”模型中。一些供应商（如 Okta）提供机器证书作为身份验证事件的一部分，但这仅限于 Okta 的 FastPass 产品，并不包含来自其他来源或供应商的信号以更好地确定构成公司设备的内容。
最后，您并不总是拥有用于访问您的系统的身份。您可能会聘请外部审计员，他们需要使用自己的公司身份进行身份验证。您可能决定允许承包商使用他们现有的 GitHub 身份来访问私有 GitHub 存储库。有时您可能只需要向仅提供电子邮件地址的某人提供对低风险资源的访问权限，例如向客户显示新产品界面的预览。因此，您的 Zero Trust 解决方案需要允许除中心目录之外的身份也能获得访问权限。
在本文档的后面，我们将描述使用 Cloudflare Zero Trust 保护您的内部应用程序，以及如何将 Cloudflare 作为 SaaS 应用程序前方的 SSO，以在各地提供简单、统一的安全状态。
在这种情况下，Cloudflare 之所以重要，是因为一旦您确定了身份提供商的事实来源，您就需要工具来对您的用户群体执行连续身份验证。这个工具很难构建和维护，正如许多知名科技公司在 2023 年退役其内部构建的 Zero Trust 代理并转用 Cloudflare 所证明的那样，他们提到管理复杂性以及无法添加新安全功能。
Cloudflare 可以通过成为针对您的私有应用程序、网络、开发者服务和 SaaS 应用程序的身份的单一执行点来简化您的架构。Cloudflare 是唯一能够作为 Web 代理（第 7 层服务）、VPN 替代方案（第 3/4 层服务）和安全 Web 网关提供 Zero Trust 身份验证概念的供应商之一。
随着您的业务增长并开始实施向用户群体分发端点，设备状态成为强大 Zero Trust 战略的关键组成部分。一旦您验证了用户的身份状态，您还可以采取其他操作来进一步降低数据泄露的风险。考虑一下：即使您的用户有效且具有活动的身份会话，他们的设备在理论上也可能被感染，攻击者可能受益于（或劫持）其有效的身份会话。
公司使用设备状态来证明连接来自受信任的设备。在列出一些常见策略和入门方法之前，让我们先看看设备状态背后的理论。在这个例子中，您有位于 AWS 某处的敏感数据。这些数据对您业务的运营至关重要。它（理应）受到具备身份感知能力的身份验证的保护，因此您确信它只能由拥有适当身份状态的用户访问。您的用户都是远程的，并从预配置了您选择的端点检测和响应 (EDR) 软件的 Macbook 连接到 AWS。使用配置了企业 EDR 软件的 Macbook 的用户，比他们使用个人笔记本电脑访问公司数据时，发生潜在泄露的风险要低。但是，您如何证明拥有有效身份状态的用户仅从那些存在较低泄露风险的设备访问您的敏感数据呢？
随着您的安全组织不断发展，并且您开始实施数据防泄漏 (DLP) 策略和工具，这变得倍加重要。如果您的用户理论上可以在不提供对用于访问的设备的举证责任的情况下访问敏感数据，用户可能能够（有意或无意地）规避您的安全工具，造成数据渗出的风险，或者至少在您的可见性和可审计性中造成盲点。
常见的设备状态策略通常依赖于端点管理工具（如 JAMF、Intune 等）、公司证书和可能位于设备上的安全工具（如 EDR 软件）的组合。如果您支持，其中一些工具能够以可通过外部验证的方式提取您设备的指纹。为了通过设备状态验证实现 Zero Trust 访问控制，通常需要将来自 Zero Trust 供应商的端点代理部署在设备上。然后，它用于在应用该设备状态用于策略之前，‘独立地’验证来自第三方供应商的声明。在评估供应商时，评估他们相对频繁地轮询状态的能力非常重要，以便他们遵守 Zero Trust 策略哲学进行状态的“连续评估”。
当您开始使用第三方供应商获得 Zero Trust 安全结果时，这些供应商需要提取第一方信号以帮助您做出最佳的安全决策。在这种情况下，Cloudflare 成为您执行设备状态（以及身份状态）策略的执行点。Cloudflare 设备代理将评估您的设备所有权或健康指标，并将它们与关于用户身份的策略结合使用，以确保对敏感资源的访问既有适当的身份验证，又来自具有可接受安全控制级别的合规设备。
在“旧世界”模式（也称为城堡和护城河安全架构）中，您的基础设施可能将是同质的，并受到防火墙的保护。要访问网络资源，不在办公室的用户（或其他第三方、供应商等）需要通过 VPN 和防火墙连接到网络，或者使用另一种可通过公共 IP 地址路由的可用网络。由于大多数基础设施现在都在云中，而且大多数初创公司一开始就是远程优先，因此在设计“公司网络”初始阶段时，几乎所有传统网络概念都不会有明显的关联。
在这种更传统的网络模型中，您的基础设施可能以下列几种方式结构化：
- 它将存在于一个或多个 VPC 中（可能由也可能不由云提供商的中转网关连接）
- 您的服务的寻址可能由您的云提供商管理
- 您将使用像 AWS 的 Route53 DNS 这样的云提供商的内部 DNS（大多数企业仍然在某种程度上依赖内部 DNS，无论它们多么云原生）
- 只要您维护自己的基础设施，总可能有理由维护私有网络空间的一些概念
- 并非所有用户都需要理解或使用您的内部 DNS 基础设施进行导航（但技术用户和服务很可能需要）
当您开始在所构建的基础设施中建立模式时，您很可能会围绕单一的、主要的云提供商进行组合。与本文档相关的主要概念将集中于用户连接到您的网络以访问内部资源和服务，以及您的内部服务广泛与互联网通信的方式。云基础设施权限和策略的管理，以及识别内部服务之间通信的方式，对全面的 Zero Trust 战略同等重要，但将在本文档未来的更新中深入讨论。
这可能是大多数初创公司最常见的 Zero Trust 用例之一。您可能会问自己，我如何在不管理 VPN 硬件或使我的业务暴露于风险的情况下，让我的用户访问我的内部网络或应用程序？当您寻求将用户连接到您的专用网络和服务的最佳方式 — 同时仍遵守 Zero Trust 原则 — 时，有两点重要的事情需要考虑：
- 限制暴露 — Zero Trust 理念鼓励组织限制访问网络或服务的方式数量。向您的网络中引入公共 IP 地址或入口路径可能会带来不必要的风险。这通常是通过使用出站专用代理连接到 Zero Trust 供应商来实现的，该代理只允许将经过身份验证的流量代理到您的网络中，并且不需要任何类型的公共 IP 访问。
- 限制横向移动 — 减小潜在数据泄露半径的最佳方法之一是对所有资源实施最低权限访问。最低权限访问是 Zero Trust 架构的核心原则，在此架构中，用户仅获得其角色所需的访问级别，而不是获得对整个公司网络的完全访问权限。与 Zero Trust 框架相关的最类似的类比概念是“微型隧道” — 一种受推荐的方法，在这种方法中，需要访问的每个应用程序或服务都会获得自己独立的“路由”。与微型隧道类似，最低权限访问使您能够建立一种仅明确的服务和用户才能访问特定资源的实践，从而帮助有利地定位未来的安全组织。
为基础设施创建和管理定义清晰的策略 — 连同可预测的内部 IP 和 DNS 记录结构 — 在您的组织继续发展时，对于访问和保护您的资产来说，将具有不可估量的价值。在文档稍后部分，我们将进一步阐述您如何使用自动化工作流程来创建可立即与您选择的 Zero Trust 安全提供商集成的基础设施。如果您清楚地掌握现有基础设施以及当前的寻址方式，那么在您的访问控制模型之上分层安全策略将显著更容易。
Cloudflare Zero Trust 可以通过端点软件和云网络连接器的组合，将私有网络概念扩展到您的终端用户。在这种情况下，您可以将 Cloudflare 用作“覆盖”网络，将安全访问扩展到终端用户的内部网络，而无需暴露公共 IP，允许从您的云环境进入，或者引入通常伴随远程访问而来的任何额外风险。
利用此“覆盖”网络，一段软件驻留在您的网络中，提供“网络”隧道（赋予用户对内部网络上服务的管理访问权限，取代传统的开放堡垒概念）和“应用程序”隧道（微型隧道，只允许经过身份验证的用户显式达到隧道中定义的单一服务）。
这大大简化了对多个独立专用网络环境的用户访问管理，而不强迫用户更改其配置文件、切换设置或持续断开或重新连接一个或多个客户端。它还使您能够轻松地向特定受众公开单个私有应用程序或服务，同时遵守 Zero Trust 原则。
对于大多数初创公司来说，网络连接并不在他们最需更改的事项列表顶部。通常，企业遵循阻力最小的路径，这往往包括管理 AWS 或 GCP 中连接的 VPC，以及可能建立一些到物理位置的外部连接。然而，大多数企业发现他们的增长会导致日益复杂的网络拓扑 — 这个过程通常发生得非常快。
在简化公司网络时，一些常见的扩展可能包括客户网络、合作伙伴、多云、收购、灾难恢复计划等。随着您的安全组织成熟，将会有越来越多的理由将基础设施分散在多个 VPC 中（甚至在同一个云环境中）。而且，随着这些 VPC 的安全组变得越来越复杂，您会发现您正在管理多个具有不同策略，有时不同操作的内部网络。
随着这些网络扩展对您的业务变得更加重要，值得审查哪些连接选项最合理，并探索构建功能复杂且根本上安全的网络的策略。
传统的网络连接方法无论在物理环境还是云环境中仍然具有重要价值，但如何有效使用它们同时维持有效的安全边界却是一个挑战。当企业只有物理连接需求时，例如分支机构或补充数据中心，框架要简单得多。你要么使用边缘设备（如路由器或防火墙）来终止物理连接，要么使用专用的前端设备在站点之间构建 VPN（“虚拟”）网络连接。本质上，你将通过为初始站点的所有机器提供到新网络或子网的新路由，从而将两个“网络”连接在一起。
除了创建 WAN 连接外，桥接多个站点的最终目标是简化管理。拥有统一的网络意味着支持边缘路由、网关和通过 DHCP 的寻址等网络功能变得更加容易。然而，这也可能导致管理过宽的策略，并且很难管理不断增长的、具有日益复杂的边缘用例和独特场景的网络的安全性影响。
对于现代初创公司来说，问题可能不完全如上所述，但您可能仍然需要解决不断增长的网络复杂性。应对此问题的最佳方法是有效规划。如果您在开始建立公司网络时就考虑到安全性和可扩展性，随着安全和 IT 组织的成长，您将能够轻松解决不断增加的复杂性。
虽然传统的网络连接概念主要集中在将网络相互连接，但网状或点对点网络概念则将网络与资产或独立端点（例如最终用户设备，如笔记本电脑和手机，或物联网设备，如智能灯和安全摄像头）连接起来。
在传统网络中，您可能有一个 VPN 隧道，在 10.0.0.0/8 和 192.168.0.0/24 的 IP 空间之间创建站点到站点的连接，使得任一网络中的所有设备都有一个网关来与任一网络上的设备进行本地通信。相反，在网状网络模型中，您可能只想让某些 IP 空间相互通信 — 例如，启用 10.2.3.4 与 IP 地址 192.168.0.50 的设备通信。
如果您只使用“微型隧道”操作（即离散 X 只能到达离散 Y），您可以极大地减少横向移动的机会。例如，使用网状网络模型意味着 IP 地址 10.2.3.4 将无法访问另一个 192.168.0.0/24 地址上的敏感数据（尽管在传统网络模型中这可能行得通）。然而，这种提高的安全状态也带来了复杂性的增加。不仅您（通常）需要在网状网络中的每个相关端点上管理代理，而且还需要准备好为每个资产和连接路径构建和管理离散策略。
如果这两种操作模型听起来都很复杂且不完美，那是因为它们的确如此。正因如此，Cloudflare 认为这两者的结合通常是适合各种规模企业的正确方法。
如果您的组织正在尝试网状连接，Cloudflare 可以帮助支持离散连接模型，同时层加独特的身份概念，并在您构建旨在支持未来增长的网络框架时，支持您的安全和可扩展性需求。
通常最适合初创公司的 Cloudflare 产品是针对用户设备的 Cloudflare One Client、用于发布私有服务的 Cloudflare Tunnel (cloudflared) 和用于双向和站点到站点连接的 Cloudflare Mesh。这允许您从单个仪表板管理远程访问、网状连接和传统网络连接。在更精细的级别上，这意味着您可以从单一策略执行点配置设备状态信息、身份信息、客户端证书和常见的 L4 指标（如端口、IP 和源/目标协议） — 从而能够为人类和自主网络交互构建稳健的安全策略。
这种网络模型的混合旨在支持广泛的用例，无论您是试图为公司网络提供远程访问，扩展公司网络以涵盖本地设备上的云环境，还是继续建立关键基础设施之间的网状连接模型，同时不引入额外风险或管理开销。
在 Cloudflare 合作的几乎所有初创公司（以及成熟公司）中，内部工具的安全性始终是一个普遍存在的挑战。您可能会构建特定于业务任务所需的工具，或者选择自托管或使用开源软件 — 这也可以被视为流行的 SaaS 应用程序用于服务、监控或其他功能。
前几节中概述的原则涉及管理对此类资源的远程访问并主要涉及身份验证。总而言之，在实践中实现 Zero Trust 模式要求您确保对每个内部服务的访问受控于持续进行身份验证的代理，最好该代理物理隔离于网络边缘，具有清晰的可审计性，并能根据需要快速撤销用户的访问。
然而，企业开始实施 Zero Trust 模型时面临的最大挑战之一不是身份验证，而是授权。在 Zero Trust 模式下将用户带入应用的前门（相对）容易，但是管理其凭据进行身份验证和授权、确保两者匹配并同时保持积极和非侵入式的用户体验，这可能非常困难。
在一个理想的世界里，我们认为身份验证和授权应由同一服务处理。这意味着在讨论如何保护内部应用（无论是直接在其中构建 OAUTH 功能还是与 SaaS 应用程序的主要 SSO 直接集成）时，您还将考虑身份验证方法可能会怎样冲突，或与身份验证方法发生重复。主要有两种利用这些概念来为您的身份验证和授权创建可扩展成功的方式。
“供应商令牌”的概念并非所有 Zero Trust 或 SSE 供应商都有。这是由于 Cloudflare 相对独特的方法；因为我们是全球最大的权威 DNS 提供商，我们在提供到达您的内部应用程序的“外部”路径的 DNS 之后，再创建用户访问令牌。
这些令牌基于身份提供商在成功验证事件后传输至 Cloudflare 的信息创建，与应用程序的自定义策略匹配。每个令牌都包含与用户通过其 IdP 签署的身份验证事件相关的所有内容：姓名、用户名、电子邮件、组以及存在的任何其他值。它也获得一个独特的标记，以显示其与特定应用的关联。
在 Cloudflare 令牌创建完成后，将其发送到内部应用以验证其请求并授权访问您的内部工具。每个应用需处理的最少额外工作之一，可将其内置到应用创建的工作流中。否则，该流将需要完全的 OAUTH 集成或 SSO 集成。
通过使用 Cloudflare 令牌，您的用户将能够在您既定的 Zero Trust 代理上享有无缝的身份验证，并使用相同的信息获取其应用的直接授权访问体验。
一些 Zero Trust 供应商提供作为 SSO 提供商操作的能力，直接与您的应用（如具有预构建 SSO 连接器的开源或自托管解决方案）集成。在此流程中，您的 SSO 负责控制至应用的授权，而您的 Zero Trust 供应商访问身份提供商进行身份验证决策，而无需管理多个主目录。
对于 Cloudflare 用户，这带来许多好处：帮助简化身份验证 (AuthN) 和授权 (AuthZ)，减少对特定 SSO 供应商的依赖，并在同时使用多个身份提供商方面提供支持。更重要的是，它可实现更轻松的采用和向新身份提供商的切换。企业在 25 到 50 个用户规模使用的身份提供商可能与 300 到 500 个用户规模不同。硬切换向另一个 SSO 集成带来巨大的摩擦。同时考虑到某些应用程序繁琐的 SSO 集成时更是如此。使用 Cloudflare 作为 SSO 提供商可通过将所有的身份、设备状态以及针对单一策略实施点的风险集成聚合，在此方面不仅简化了 AuthZ/AuthN，也为您提供了在自托管应用程序前增加额外保护的控制。
我们推荐使用我们的 Cloudflare Access 产品为内部服务实现远程访问（借由使用本地网络的 Cloudflare Tunnel 软件）。配合 Cloudflare Access，您可以使用 JWT，该 JWT 是由 Cloudflare Access 创建并在其中执行；或采用 Access for SaaS 将该产品当作针对预载 SSO 连接器的私有或自托管应用之 SAML 和 OAUTH 代理。
在很多情况下，您甚至可以对应用程序访问使用这两种产品。例如，如果您正在自托管无法在公共互联网上使用的 Sentry ↗ — 请执行以下操作：
- 设置结合了 Cloudflare Access 的公开主机名称，使得用户能够借此导航至 Sentry 上。
- 安装带有关联 Published application（已发布的应用程序） 的 Cloudflare Tunnel，指向本地 Sentry 服务。
- 将 Sentry 与 Access for SaaS 集成为 SSO 提供商。
现在，从网络外部访问该应用的用户将已携带 Cloudflare JWT，并会无缝通过身份验证进入应用程序。
已确立并广为接受的公司用户远程访问模式，并不总是适用于混合用户群体。这类用户通常包括承包商、第三方供应商，有时也包括客户。这些用户都可能有访问私有和企业内部资源的合理理由。您可能聘请开发或维护承包商，他们需要访问网络或应用程序的部分内容，但提供完整网络访问会带来不必要的风险。
此外，您可能向客户提供托管或管理服务，并由客户部署在自己的网络中。此时您需要连接到这些服务以便妥善管理。或者，您可能在自己的环境中为客户托管私有资源，并需要让他们安全地仅访问其相关租户。
每当确定第三方用户需要访问您的环境时，应首先确定以下三项属性：
- 他们需要访问什么
- 该访问需要什么级别的身份验证
- 这种访问的相关时间有多长
确定范围以后，您必须敲定最适合此类受众的最低权限访问模式。这可能意味着集成一个辅助身份提供商（可能是客户或供应商的 IdP）以用于身份验证事件，或者使用临时身份验证方法，如一次性 PIN，仅对他们的电子邮件地址进行身份验证。
一些企业还将供应商和承包商用户添加到他们的身份提供商，以简化身份验证和控制方法（如使用 MFA 和其他身份验证因素）。最低建议是，我们希望您采用支持多头平行的身份验证方法的 Zero Trust 安全提供商，并且可以通过特定策略或应用程序应用它们。
这允许您保持所有现有安全远程访问方法的统一。您的外部用户群将使用相同的路径进入您的网络，并将受到所有安全控制措施的约束。同时，您将收到详细的日志记录和审计跟踪，以准确规定用户可以访问哪些内容，他们访问的频率，以及他们在您的网络中执行了什么样的操作。分配最低权限控制也可以轻松建立访问模型，同时确保用户无法在您的网络内执行任何横向操作或不必要地访问资源。
如果这种访问无法通过网络浏览器建立并且需要网络级别的控制，您的外部用户可能需要部署用于 Zero Trust 部署的端点代理。例如，承包商组通常具有连接到单个用户机器的多个端点代理，这可能会引入网络路由的复杂性 — 甚至冲突，如果其中一些私有网络在不同的企业之间重叠。
为确保第三方访问流程简单、可管理，请考虑以下问题：
- 您的 Zero Trust 供应商是否支持用于部署端点代理的多个配置文件？ 承包商用户应使用严格限定范围的路由控制，以限制对网络的访问，并降低与设备上其他代理冲突的风险。
- 第三方访问是否与公司用户访问存在实质性差异？ 如果没有，可以通过为第三方构建职能身份和集成来简化行政管理。只要能够区分并纳入审计，就不一定需要创建新策略。
在个别实例里，企业用户需要对客户环境进行安全的（持续的或临时的）访问，或者客户可能需要类似的安全访问您网络内独特的托管环境。这个过程可能包括为客户托管软件租户，在客户托管的软件上运行维护，或为与客户内部网络连接的产品功能提供连接器。
对于这些用例，传统推荐模型通常是站点到站点 VPN 等网络配置。这些方案可以适当限定范围，但往往会导致企业网络与客户网络之间连接过宽，并可能带来风险或过于宽泛的访问能力。
在 Zero Trust 安全框架中，这种访问应在最低权限模型中明确限定。这可以通过设置具有身份感知或服务感知的站点到站点连接，或使用单向连接器模型提供任一方向的安全访问来实现，该连接器可以作用于特定的操作上。
Cloudflare 可以帮助为您的第三方用户在 Zero Trust 框架中提供限制范围的 Web 和网络连接的安全访问。
- Cloudflare Access 可以同时集成并使用多个身份提供商。 这可以限定在单个应用程序和单个策略，并可以精细地“强制”某些用户以特定方式进行身份验证。还有许多面向第三方的工作流——例如目的证明——既能让第三方轻松访问，也便于管理员记录和控制。
- Cloudflare Zero Trust 可以使用灵活的端点代理参数和逻辑分组为承包商和第三方用户部署。 如果外部用户需要内部访问，可以严格限定范围，并降低与其他外部系统冲突的风险。
- Cloudflare Tunnel 可用作单向访问模型，为企业用户提供对特定客户资源的访问。 它轻量、易于部署，甚至可以内置到部署包中，与您在客户环境中管理的服务一起部署。
- Cloudflare Mesh（原 WARP Connector）可帮助您为每个客户控制的网络建立可扩展的安全网络。 当需要双向（站点到站点）流量来与客户互动、访问其应用程序或处理其他管理问题时，这一点尤其有用。Cloudflare Mesh 包含与其余部署相同的内联安全策略和可审计控制，因此您可以在实现客户连接的同时保持 Zero Trust 安全状态。
传统上，Zero Trust 访问的概念明确地专门用于用户或机器对内部或特权资源的访问。在功能层面，这要求替换网络扩展、减少权限过大，并尽量缩小通常由 VPN 远程访问连接产生横向移动以及威胁向量。但是对大多数企业组织来说，他们的 VPN 不仅代理其私有网络流量。它还管理他们的互联网流量，使他们保持统一视角的威胁应对 — 通常是通过发送至云服务提供商的 DNS 查询模块，或者通过直接回传所有用户流量至公司网络以穿过公司防火墙。
这种城堡与护城河模型产生的安全性和复杂性挑战迫使许多供应商解决这两个 VPN 提供的主要功能。现在，在同一句话中或作为同一产品的一部分讨论安全 Web 网关 (SWG) 和 Zero Trust 访问 (ZTNA) 是很常见的。
尽管这种转变是由供应商和分析师而非安全研究人员推动的，但它似乎改善了客户的安全可管理性，同时简化了初创公司的购买和部署流程。即，部署单个代理来处理您的公司和互联网流量，比使用多个设备代理来处理各种安全工具要有意义得多。
在旧世界，边界由公共出口 IP 地址标识，表示流量在进入互联网之前已经过一系列安全控制，例如防火墙、IPS 或 IDS。因此，企业开始要求流量必须来自特定源 IP 才能被“信任”；这被用于与供应商、第三方和 SaaS 应用程序合作。源自企业网络（使用企业源 IP）的流量曾是“信任”的最大指标之一。现在已不再如此简单。
如今，您的业务很可能已经没有中央“边界”。它很可能诞生于云端，将用户端点以裸机或预配置安全控制的形式发放出去，并远程、异步地运行一切。这种模式对生产力和扩展能力影响很大。但随着安全组织成长和成熟，建立一套标识新边界的基线安全“态势”会带来固有好处。
在一个您的 Zero Trust 提供商和 SSO 应该能够保护您的大部分私有应用程序、网络、服务和 SaaS 应用程序的世界中，用户应该比以往任何时候都更有能力在任何地方工作 — 并且如果您遵循最佳实践，您那异步、高效的工作方式不需要被中断。换句话说，您对“安全”端点的定义成为您的新企业边界。
一个定义明确的安全端点，凭借清晰的可测量性，对安全状态有着显著更好的效果，因为与源 IP 地址不同，它是高度针对性的且不断被验证的。在旧世界中，这意味着通过防火墙出口并受到安全控制。在新世界中，这通常意味着验证加密、询问设备上的状态以及确定来自机器的流量是否已由安全 Web 网关检查。它甚至可能仍然包括将源 IP 地址作为验证方法，但绝不是主要控制。
在考虑如何管理自带设备 (BYOD) 的使用（并确保公司数据被安全访问）时，您只需先确定什么构成安全端点策略。然后，考虑应如何检查发往敏感资源的请求，以确保它们符合该策略。例如，想想用户访问 Workday（或其他以 PII 为主的系统）需要采取的步骤。在授予访问权限之前，您可能希望将他们的流量发送到安全 Web 网关并应用数据丢失防护策略。现在问自己，还需要采取哪些其他步骤来执行这些要求？
在此讨论中，我们将互联网安全（如安全 Web 网关、DNS 过滤、流量代理等）视为一组高级安全信号，据此为敏感资源应用更准确、更精细的 Zero Trust 策略。尽早开始使用 DNS 过滤也是良好实践，因为随着业务和安全需求增长，在端点上部署软件并代理流量只会更复杂。当您开始考虑 HTTP 过滤和数据丢失防护等其他高级安全控制时，建议阅读 TLS 解密入门，了解解密流量前需要做出的决定。
除了为内部应用程序、网络远程访问和 SaaS 应用程序提供 Zero Trust 安全功能外，Cloudflare 还提供以下功能：
- DNS 过滤
- 第 4 层防火墙
- 安全 Web 网关 (SWG) — 具备应用识别、TLS 解密、数据丢失防护、CASB、浏览器隔离，以及直接从 Cloudflare 网络采用专用出口 IP 的能力
我们的所有 SWG 功能都通过考虑用户身份、设备状态和用户风险的策略进行控制，并通过与您的 Zero Trust 控件相同的端点代理提供 — 使用相同的策略引擎和策略执行机会。
Cloudflare 允许您通过识别托管端点设备上的出站流量并应用策略，功能性地构建一个新的边界。您可以实现与旧城堡和护城河边界相同的统一安全控制，同时应用独立的、粒度化的安全评估（而无需回传任何用户流量）。然后，您可以利用该安全评估对受 Zero Trust 保护的应用程序应用更强大的控制，帮助您区分低、中、高风险用户，以及对处理 BYOD 流量的方式做出决策等等。
关于 SaaS 安全的概念对很多人来说意味着很多东西。正因为如此，这是一个有些争议的话题，特别是当它涉及 Zero Trust 时。在第一波 COVID 期间，SaaS 服务看到了巨大的用户人口激增，这在很大程度上要归功于远程工作的显著增加。几乎在一夜之间，用户连接到企业基础设施之外的服务的实用性远远大于连接到内部服务。
有些人提出这样的论点，即 SaaS 应用程序：1）在集成了 SSO 的情况下本质上是安全的，或 2）本质上是 SaaS 提供商有责任去保护它。虽然这些论点涉及访问和保护您的 SaaS 投资的方式，但它们并未说明为什么公司使用 SaaS — 这通常是为了存储公司信息。在您确定有关 SaaS 安全决策的考虑因素时，“敏感数据存在的位置”的激增将是一个越来越重要的因素。
以上声明都暗示您知道用户接触了什么 SaaS 工具，但情况通常并非如此。首先，我们将讨论“受批准”的 SaaS 采用，然后我们将讨论与“未经批准”SaaS（也称为影子 IT）相关的概念。
在建立任何类型的安全策略之前，确定所需的安全性状态是您的第一步。因此，如果您拥有包含大量公司数据或受合规性法律或其他法规约束的其他数据的应用程序，那么将这些应用程序专门限制在符合您上述“边界”的设备上可能是有意义的。
实现这一目标的最佳方法是找到一个集中信号源（如 Cloudflare 的 Access for SaaS），它可以确保您的安全策略的所有独立部分都在持续应用于用户访问。您能使用传统的 SSO 供应商完成所有这些工作吗？也许可以。例如，Okta 的 FastPass 通过验证安装在本地设备上的证书，然后确定请求的源 IP 地址来确定机器身份。然而，在大多数情况下，FastPass 无法告诉您有关用户流量中存在的安全检查事件的更多信息，或者有关最终用户设备健康状况的任何其他信息。就这一点而言，值得注意的是，您的 SSO 提供商的有用性仅取决于它可以消耗以做出策略决策的数据量。
如果您决定仅有机器证书或其他信号度量标准足以标识公司设备，这在企业安全成熟度的任何阶段都是完全合适的——事实上，许多企业尚未采用任何类型的设备状态。
管理受批准 SaaS 应用程序的另一种方法是通过 API 与您的 Zero Trust 供应商集成。然后，您可以扫描它们以查找错误配置或是否存在意外敏感数据。此过程独立于传统的 Zero Trust 访问控制，但大多数 Zero Trust 供应商都提供此过程，并且可以在单一视图中反映所有 SaaS 工具所需的持续配置更改。
通过评估您管理的 SaaS 应用程序中敏感数据的存在，您可以开始形成政策优先级的概念。换句话说，它可以改变您关于什么应该能够通过 BYOD 访问与什么应该需要来自管理终端的授权访问的思考方式。或者，相反，您如何量化 BYOD 访问的风险，以便有效调节用户？
当您从您可以控制的 SaaS 应用程序（即可以与 SSO 和其他第三方工具集成）转向您无法控制的应用程序时，安全模型会发生显著变化。属于此类别的 SaaS 应用程序通常被分类为“未经批准的”应用程序 — 有时，因为它们由不支持 SSO 的二级供应商管理，或者因为它们是未被您的 IT 组织明确批准使用的服务。这些未经批准的应用程序被称为影子 IT。
这些应用程序如何在您的环境中激增？逻辑很简单，尤其是对于初创公司。用户喜欢快速移动，并可能倾向于使用最便捷的方法来完成他们的工作。有时，这可能意味着使用尚未经过审查或批准使用的工具（或可能存储敏感数据的工具）。
影子 IT 通常被作为一般互联网安全计划的一部分来解决，该计划有时与 Zero Trust 部署属于同一考察范围（或供应商）。降低未经批准的 SaaS 应用程序的风险几乎总是围绕着可见性展开。您能做的最重要的事情（在没有 SSO 或 CASB 工具与应用程序集成的情况下）是了解影子 IT 的使用广度。
记录未经批准的应用程序通常需要使用正向代理工具，如 DNS 过滤器、安全 Web 网关或一些特定于电子邮件的工具。这些工具可以提供关于哪些用户与未经批准的 SaaS 应用程序进行了交互的见解，甚至可能包括他们是如何与之交互的（他们是否上传/下载了文件，他们传输了多少带宽等）。
通过实施记录 SaaS 使用情况的策略和策略，您可以开始更好地了解您的敏感数据在 SaaS 工具中是如何存储、移动或被操纵的。一些企业将 SaaS 的使用限制在明确批准的公司工具上，而另一些企业则更为宽松。这没有错误的方法，但是构建早期捕获使用信息的框架可以帮助您在这些成为组织紧迫问题时从后往前追溯。
此框架还可以为您的 IT 组织提供考虑进行采购周期的工具方向。例如，如果已经有大量用户群在使用某个工具，有时为该工具获取企业功能是有意义的，这可以降低影子 IT 的风险或允许您的团队实施额外的安全功能，而有时并不会显著改变成本。
Cloudflare 可以帮助为您对于影子 IT 环境及随后的发现的可见性和管理设置基础。用户到互联网的流量可以从 Cloudflare One 客户端和我们的安全 Web 网关 (SWG) 进行审计和组织，您可以了解您的敏感数据是在何处移动到贵公司接受的 SaaS 租户之外。
这随后可以成为进一步扩展您的 Zero Trust 战略的机会，通过确保这些新发现的工具被明确阻止或允许，在它们上设置特定的数据安全控制，或者将它们与您的 Zero Trust 供应商集成（使用类似 Access for SaaS 来应用安全策略）。
我们交谈过的许多初创公司最终都关心管理那些对他们的用例来说显得复杂或过度配置的安全工具所需的员工人数和专业知识。他们已经在开发中执行的许多操作都是通过编排工具、基础架构即代码以及直接通过 API 进行管理的——但他们通常希望实现 DevSecOps 状态，其中所有 Zero Trust（以及其他安全工具）项目都可以作为代码构建、管理和维护。
虽然这对于传统安全工具来说是一个新兴的概念，但它在您评估潜在供应商时仍然应是一个关键的考虑因素。请记住，尽管像 Terraform 这样的概念受到许多 Zero Trust 供应商的支持，但这些供应商可能不支持（或发布）其产品中每个概念的提供程序或 API 端点，这可能会导致管理工作出现重复或分歧。
如果您的组织的目标是将网络和安全堆栈作为代码进行管理，那么在您的 Zero Trust 旅程早期就开始该框架非常重要。虽然可能会有一些需要导航的挑战，但是在您的业务和安全需求不可避免地变得越来越复杂和难以管理时，在网络开发上取得领先将会获得回报。
随着您继续评估 Zero Trust 或一般安全计划的供应商合作伙伴，我们建议您确保其整个产品组合和管理控制拥有完善的文档记录和完整的 API 端点，以及有关编排和基础架构即代码工具（如 Terraform）的文档。
Cloudflare 对 DevSecOps 环境下的 Zero Trust 安全性充满热情。我们将 API 优先作为所有产品的主要精神，在功能可用的第一天向客户提供所有相关的 API 端点，并附有详尽的文档。
另外，许多客户可以在甚至不用触碰我们的仪表板的情况下管理他们的 Cloudflare Zero Trust 部署；取而代之的是，他们将 Terraform 或类似工具用于其整个管理平面。如果这是您的情况，我们有一个全面和完整的 Terraform 提供商 ↗，使您能够将 Zero Trust 视为代码来完成。
总之，今天就您的公司如何对待安全和身份验证的基础知识做出几个经过深思熟虑的选择，将使您的初创公司在未来几年受益。您现在做出的决策奠定了现代安全基础架构的基础，该基础架构将随着您的业务增长顺利扩展。无论您如何前进，一些明智的举措将确保您的初创公司建立在可持续的、可扩展的 Zero Trust 安全原则之上。
如果您想更详细地讨论您的 Zero Trust 要求并联系我们的一位架构师，请访问 https://www.cloudflare.com/cloudflare-one/ ↗ 并申请咨询。