如何在不中断业务的情况下实施零信任

在英国，98% 的企业表示他们计划或已经实施了零信任，但只有 15% 的企业报告已完全实施。差距不在于意识，而在于执行。英国的零信任研究表明，许多团队已经开始规划、分段或隔离的身份项目，但未将这些控制连接到一个运营模型中。

实际面临的问题不是零信任是否重要。而是如何在不中断实时服务、不让用户感到沮丧或不创建另一个孤立的安全产品集合的情况下实施零信任。答案是围绕身份、设备姿态、目录生命周期、安全 WiFi、分段和持续验证来安排迁移顺序。

为什么企业中的 Zero Trust 实施会陷入停滞

51% 的组织仍处于早期规划阶段，只有 15% 声称已全面实施，且 80% 面临技术或运营障碍。英国组织报告显示了选择发展方向与运行所需控制措施之间存在差距。团队通常从孤立的项目开始，随后发现身份、设备、目录、应用和网络之间相互依赖。

零信任消除了系统、网络和服务的固有信任。内部连接不应提供广泛的访问权限。旧账户在人员或供应商不再需要之后，不应继续保留权限。一个服务不应因为通过了一次身份验证检查，就无限期地保持受信任状态。

英国国家网络安全中心（NCSC）将零信任定义为分阶段迁移，而不是购买单一产品。其架构指南定义了八项设计原则，包括以身份为主导的访问决策和受保护的通信。NCSC 零信任系列指南于 2021 年发布，并在同年 9 月扩展了实施指南。NCSC 架构设计原则 非常有用，因为它们要求团队在选择技术之前先确定架构和信任决策。

产品优先的失败模式

失败的模式通常始于购买平台。团队部署了身份产品、分段工具或 ZTNA 网关，随后发现服务账户、非托管设备、遗留应用程序、无线身份验证以及目录注销从未被纳入规划。

其结果是例外清单不断增加。用户获得了临时解决方案，管理员保留了共享凭据，而安全团队无法判断策略是否得到了持续一致的执行。WiFi 会迅速暴露这一弱点。网络分段可以隔离流量，但如果用户仍通过共享密码加入，或者设备依然未知，它就无法建立基于身份的访问。具有基于证书的身份验证的无密码 WiFi 与设备记录和目录状态紧密绑定，可为策略提供可靠的身份信号。这样，当账户被禁用时，自动目录撤销应该直接移除访问权限，而不是等待手动清理。

传统的边界控制依然发挥着作用，但它们无法解决每一个访问问题。为什么传统 IT 安全会失效 解释了云服务、远程访问和分布式设备如何削弱了“内部网络自动安全”的假设。

实用规则： 在了解策略可能中断哪些身份、设备、WiFi 以及服务依赖关系之前，请勿编写执行策略。

可行的迁移遵循以下顺序：

• 发现资产：识别用户、设备、应用程序、服务和数据流。
• 定义边界：确定哪些资源需要隔离，以及哪些访问路径是合法的。
• 构建控制平面：连接身份、多因素身份验证（MFA）、基于证书的设备访问、姿态检查和目录生命周期。
• 在边缘强制执行：将策略应用于应用程序、网络和 WiFi，而不仅仅是 VPN 会话。
• 观察并扩展：从受控的工作负载开始，审查访问决策，并逐步扩展该模型。

这一流程使零信任成为一种运行模式，而非仅是一系列工具的堆砌。它还能让运维团队在身份控制、安全 WiFi 和分段机制不断成熟完善的同时，切实保障系统的可用性。

通过发现和信任边界奠定基础

首先进行资产盘点，以反映组织的实际运作方式，而不是网络拓扑图上的运行方式。NCSC 建议识别用户、所需权限、设备和服务，然后围绕这些发现来设计身份和访问管理。NCSC 迁移指南 还指出，团队应在部署前梳理传统依赖关系并对拟定架构进行威胁建模。

输出结果应当是一个处于活动状态的目录，而不是静态的电子表格。记录每个重要资源的拥有者、业务用途、身份验证方法、依赖关系、数据敏感度、预期用户以及故障影响。

构建四个清单

用户和身份排在首位。包括员工、承包商、特权管理员、服务账户和自动化身份。将个人的雇佣状态与其访问需求分开。承包商可能在特定期限内需要访问某个应用程序，而服务账户可能需要机器身份验证但无需交互式登录。

设备需要有自己的分类。记录托管的笔记本电脑、移动设备、共享终端、打印机、摄像头、建筑系统和其他物联网设备。注意哪些设备支持证书、现代加密和姿态报告。遗留设备通常无法满足员工身份验证要求，因此需要明确的遏制策略，而不是未跟踪的例外情况。

应用和服务应当与其身份和传输要求相映射。记录每个应用是支持 SSO、MFA、现代协议、证书、代理访问，还是仅支持传统的用户名和密码。识别上游目录、数据库、DNS 服务、API 和日志记录依赖项。

数据流和业务流程可以揭示信任边界。绘制员工如何访问临床系统、合同工如何访问维护门户，或者销售点终端设备如何与经批准的服务进行通信。如果未记录的依赖关系导致其跨越无限制的访问，那么网段划分就毫无意义。

在制定策略之前定义边界

信任边界应当回答三个问题：受保护的对象是什么、谁需要访问权限以及在何种条件下进行访问。这些条件可以包括身份保证、设备运行状况、网络上下文、应用程序敏感度以及有时间限制的审批。

访客 WiFi、物联网（IoT）和多租户场所需要特别关注。访客绝不应依赖员工的网络凭据。IoT 设备应仅与其次要功能所需的服务器进行通信。租户可以在共享物理基础设施的同时，保持逻辑隔离和独立的身份管理。

跨越每个边界的安全传输都至关重要。如果团队需要通俗易懂地温习证书、加密和浏览器信任，在记录应用和 WiFi 传输假设之前，Adwave Digital 的 SSL 指南 是一个有用的参考。

以威胁模型结束发现阶段。测试当目录账户被攻破、托管设备运行状况不佳、证书被撤销、无线控制器不可用或传统服务无法向新的身份提供商进行身份验证时会发生什么。这些失效路径应该决定部署的先后顺序。

将身份和设备状态构建为您的控制平面

零信任决策需要一个信任源。在大多数资产中，这意味着选择管理人员、组和生命周期事件的目录，例如 Microsoft Entra ID, Google Workspace 或 Okta。重要的设计选择不仅在于品牌本身。而在于每个访问系统是否能够使用相同的身份状态，并在该状态发生变化时做出反应。

离开组织的用户应当失去在所有重要位置的访问权限。合同工的合同期满后，不应因为管理员忘记删除单独的账户而继续在无线系统中保持活跃状态。自动配置和撤销功能使目录更改成为运营控制手段，而不再是行政性提醒。

对人员和设备进行身份验证

从针对员工应用的 SSO 和 MFA 开始。MFA 提高了可信度，而 SSO 减少了用户和技术支持台必须管理的凭证数量。NCSC 特别建议围绕 MFA 设计 IAM，并考虑在合适的情况下采用无密码身份验证。无密码方法可以同时提高安全性和易用性，但它们需要恢复流程、设备注册控制以及对失去主要验证器访问权限的用户提供支持。

对于员工 WiFi，基于证书的身份验证在运营上通常比共享密码更强大。通过 WPA2 或 WPA3-Enterprise 以及 802.1X，网络可以将访问权限与已注册的身份或设备证书进行绑定。这消除了分发公共密钥的需要，并使撤销操作更加精确。

设备姿态构成了决策的另一半。检查设备是否已托管、已加密、已打补丁、合规且使用了获得批准的证书。在未托管笔记本电脑上的合法用户，不应自动获得与该用户在健康的公司设备上相同的访问权限。

身份能够证明是谁在请求访问，而设备姿态则决定该访问请求是否足够安全以获准批准。

设计生命周期事件，而不仅仅是登录

入职流程应通过自动化工作流创建目录身份、分配正确的组、注册设备并颁发所需的证书。离职流程应禁用该身份、撤销会话和证书，并立即移除网络访问权限，无需等待专门的 WiFi 管理员进行操作。

合同工需要不同的路径。为他们提供范围严格受限的组群成员身份、过期或审批流程，并且仅允许访问其工作所需的应用和网络段。切勿通过将合同工放入广泛的员工网络中来解决其便利性问题。

遗留设备需要加以遏制。如果打印机、传感器或专用终端无法使用基于证书的身份验证，请使用专用网段、严格限制的防火墙规则以及受控的身份机制（例如个人预共享密钥）。这样可以保持例外的可见性，并限制其爆炸半径。

评估受身份限制的网络访问的团队可以查看 identity-based networking（基于身份的网络连接）作为一种实施模式。无论平台如何，架构原则都是相同的：目录状态、身份验证强度和设备状态必须共同影响访问决策。

实施策略的分段和安全 WiFi

分段是必要的，但它本身无法强制执行基于身份的访问。92% 受访的英国企业表示他们在某种程度上对其网络进行了分段，而 98% 的企业表示他们计划或已经实施了零信任。英国的研究表明，网络分区已广泛应用，但身份保证、持续验证和策略执行仍需引起重视。

VLAN 用于隔离流量，但它无法决定某个人、设备或会话是否应当保留访问权限。如果用户从符合合规要求的笔记本电脑切换到非托管设备，除非访问系统重新评估身份和设备姿态，否则该设备可能仍处于同一网段中。

比较成熟度级别

将 WiFi 视为身份边界

WiFi 通常是设备遇到的第一个企业接入决策。将其留到计划的后期处理，会在目录策略与物理连接之间产生差距。

对于员工，请使用带有 802.1X 的 WPA2 或 WPA3-Enterprise，并以证书或其他强身份方法为后盾。无密码 WiFi 从用户体验中消除了共享密钥，而基于证书的身份验证则将连接性与注册的身份和设备绑定。Passpoint 和 OpenRoaming 可以通过允许注册的设备在不重复输入密码的情况下进行身份验证来支持安全漫游。

我们的目标是从第一个数据包开始，就实现基于身份的加密连接。用户接受条款后即授予广泛访问权限的 Captive Portal 并不能提供这种控制。

如需对 企业 WiFi 安全 进行实用评估，请评估证书分发、身份提供商集成、撤销处理以及控制器兼容性。该设计必须适用于整个企业资产，包括 Meraki、Aruba、Ruckus、Mist 或 UniFi 设备。

访客需要独立的体验和策略。提供不带员工权限的互联网访问。IoT 设备需要受限的策略，仅允许访问其运行所需的外部目的地和服务器。

持续重新评估访问权限

英国国家网络安全中心（NCSC）将持续重新评估、可观测性和弹性列为明确的零信任要求。其 ZTNA 实施指南 支持在上下文发生变化时更改访问权限，而不是在会话生命周期内保持权限固定。

目录集成必须支持自动撤销。禁用的账户、删除的组成员身份或吊销的证书应该触发策略更新，而无需等待单独的 WiFi 管理员进行干预。其结果可能是升级身份验证、移至受限制的网络、阻止应用程序或立即撤销访问权限。

分段可以控制安全事件。身份、设备姿态和当前遥测数据决定了访问是否继续。这种结合弥合了网络隔离与真正的基于身份控制之间的差距。

部署监控并验证每一次访问决策

安全的部署是可控、可观察且可逆的。不要一开始就在所有用户、站点和设备类别中强制执行新策略。选择一个低风险的群组或位置（该群组或位置仍包含足够的真实复杂性以暴露问题），在扩大范围之前先验证访问路径。

在技术支持的情况下，先从监控模式开始。捕获策略将允许和拒绝的内容，将这些决策与业务需求进行对比，并调查未知的依赖关系。监控模式并不能代替强制执行。它是在强制执行影响生产环境之前，消除本可避免的意外的一种方法。

采用分阶段迁移

一个实际的步骤顺序如下：

1. 选择局部试点：选择一个风险较低、拥有明确负责人和清晰支持渠道的应用、站点或用户群组。
2. 记录基线：捕获成功和失败的身份验证、设备姿态、证书状态、网络位置、策略结果以及应用访问结果。
3. 测试拒绝路径：确认多因素身份验证（MFA）失败、已撤销的证书、已禁用的目录身份以及不合规的设备均被成功拦截。
4. 小范围强制执行：将策略应用于试点，并制定已归档的恢复预案，同时指定一名能够回滚更改的管理员。
5. 按依赖关系逐步扩展：仅在上一阶段拥有稳定日志和公认的支持流程之后，才添加新的群组、站点或服务。

试点项目应包含故障测试。禁用测试身份、移除其组群成员资格、将设备标记为不合规并撤销其证书。验证网络访问、应用程序访问以及活动会话是否均能按设计做出相应响应。

使遥测数据发挥作用

收集能够解释决策的事件，而不仅仅是证明已建立连接的的事件。至少应关联请求身份、设备标识符、身份验证结果、证书状态、安全姿态评估结果、网络分段、目标资源、策略版本以及最终决策。

寻找需要人工审查的模式：

• 异常身份使用：用户访问了其正常角色或获批群体之外的资源。
• 状态变化：此前合规的设备失去了管理、加密或证书状态。
• 重复失败：在多个账户或位置发生身份验证或状态校验失败。
• 策略异常：传统设备或服务反复依赖于一条宽泛的规则。
• 吊销延迟：已被禁用的目录身份继续获得网络或应用访问权限。

在评估基于身份的 WiFi 平台如何处理访问数据、安全控制和运营可见性时，请参考 Purple 的数据和安全概述。无论您选择什么工具，仪表板都应该支持决策。没人查看的日志不会改善执行效果。

回滚条件：当策略阻碍了关键业务流程、创建了不安全的依赖关系或导致无法解释的访问失败时，请撤销该策略。保留证据、修正设计并重新测试。切勿让应急例外设置永久保持开启状态。

将可用性保护作为安全的一部分

零信任依赖于目录、证书服务、策略引擎、网络控制器和连接性。为每个依赖项构建弹性。明确定义在身份提供商无法访问、证书无法验证、控制器故障或策略服务不可用时的应对方案。

谨慎使用故障安全服务设计。在某些环境中，当身份服务中断时，需要允许现有会话短期继续。而在其他环境中，则应立即限制对敏感资源的访问。正确的选择取决于资源、威胁模型和运营后果。

在执行前进行沟通。告知用户将发生哪些变化、他们将使用哪些登录方法、设备注册如何工作以及在哪里报告失败。在每个阶段结束后跟踪帮助台主题和访问分析。减少手动账户管理、减少共享凭证和加快撤销速度是运营模式改善的实际指标。

您的 Zero Trust 实施清单和后续步骤

一个可行的实施计划应该符合下一次架构会议的议程：

• 发现：清点人员、服务帐户、设备、应用程序和服务。
• 映射依赖关系：记录数据流、身份验证方法、遗留限制和运营所有者。
• 定义边界：根据资源需求区分员工、访客、IoT和租户访问权限。
• 加强身份管理：选择目录单一真理源，强制执行MFA并引入SSO。
• 采用更强的身份验证：引导合适的用户和设备转向无密码和基于证书的访问。
• 自动化生命周期：从目录组进行配置，并在身份或证书更改时撤销访问权限。
• 评估安全状况：在授予敏感访问权限之前检查管理、运行状况和合规性。
• 安全 WiFi：使用绑定身份的企业级身份验证，而不是共享的员工密码。
• 遏制遗留设备：将例外情况置于受限网段中，并采用范围狭窄的策略。
• 先监控：在观察模式下运行试点策略，然后通过回滚标准强制执行。
• 持续验证：测试被拒绝的访问、撤销、安全状况更改和服务故障。
• 谨慎扩展：仅在日志、所有权和支持流程准备就绪时才增加站点和工作负载。

最重要的实施决策是确定先后顺序。不要从最显眼的产品或最大的网络分段开始。从一个您可以理解、测量和撤销的流程开始。对于酒店和零售业，这可能意味着在实体场所中隔离员工、访客和运营设备。对于医疗保健行业，这可能意味着优先围绕敏感应用建立身份和设备控制。对于多租户住宅，这可能意味着在提供简便住户访问的同时，保持租户与建筑系统之间的隔离。

当平台能够消除真正的迁移障碍时，请选择该平台。如果您的资产需要无密码 WiFi、目录集成的员工访问、自动撤销以及减少对本地 RADIUS 的依赖，请评估 Purple 等平台是否符合现有的身份和网络架构。使这一决定与您的控制目标、集成要求和运营所有权保持一致。

通过证据衡量进度，而不是通过部署公告。您应该能够显示哪些身份具有访问权限、哪些设备是可信的、哪些策略拒绝了请求、撤销生效的速度有多快以及哪些地方仍存在异常。这就是零信任如何成为一种运营能力，而不是另一个停滞不前的安全项目。

Purple 提供基于身份的 WiFi 和网络，将员工和设备连接到现有的目录，支持无密码和证书级访问，并可随着目录状态的变化自动进行配置和撤销。访问 Purple 以评估其 WiFi 身份验证、设备姿态和网络集成如何支持分阶段的零信任部署。