跳到主要内容

ZTNA 实施指南：从设计到生产

Zero Trust Network Access（ZTNA）项目真正成功的标志，是让访问决策更加明确，同时不让正常工作流程变得不必要地复杂。

因此，实施 ZTNA 并不只是安装一个网关。生产环境需要把身份、设备、受保护资源、访问策略、访问路径、日志、支持流程和灾难恢复整合到同一个运行模型中。

本指南重点介绍如何分阶段、可控地实施 ZTNA。它与ZTNA 如何工作中的架构说明以及VPN 到 ZTNA 迁移指南中的迁移流程相互补充。

1. 先定义目标，再设计策略​

首先明确你真正要解决的访问问题。

常见实施目标包括：

  • 将宽泛的远程 VPN 权限替换为资源级访问
  • 减少敏感系统的长期常驻权限
  • 将承包商访问与员工访问区分开
  • 在授权决策中加入身份和设备上下文
  • 提升私有资源访问的审计可见性
  • 支持本地部署、自托管或断网环境

不要一开始就建立庞大的策略矩阵。先确定业务目标，以及受到影响的用户和资源范围。

边界清晰的试点，比“在所有地方部署零信任”这样的宽泛项目更容易验证。

2. 建立身份、设备和资源清单​

ZTNA 决策依赖于三个基本问题：谁在请求、从什么设备请求、请求访问什么资源。

建议分别建立三份清单。

身份​

记录：

  • 员工组和管理员组
  • 承包商和临时用户
  • 身份来源与认证方式
  • 组或角色的责任归属
  • 入职、岗位变更和离职流程
  • 特权访问或审批访问要求

设备​

记录：

  • 受管与非受管终端
  • 设备注册方式
  • 纳入范围的操作系统
  • 设备所有权
  • 可用的 MDM 或 EDR 姿态信号
  • 无法使用标准受管访问路径的设备

资源​

记录：

  • 应用和服务器
  • 所需协议和端口
  • 业务负责人
  • 敏感程度
  • 真正需要访问的用户组
  • 对其他服务的依赖

如果实际需求只是访问某个应用或服务器，就不要只用一个整个子网来定义资源。

3. 有意识地选择部署模型​

不同 ZTNA 产品会把控制组件和执行组件放在不同位置。上线前应先决定哪种运行模式符合你的环境。

需要回答的问题包括：

  • 谁运行访问平台：组织自身、MSP，还是厂商？
  • 如果 Internet 不可用，核心访问是否必须继续工作？
  • 是否有受保护系统位于隔离或完全断网环境？
  • 哪些外部身份、设备姿态、监控或认证服务可以成为依赖？
  • 更新、许可、备份和灾难恢复如何处理？

ZTXGate 的核心平台可由客户或 MSP 运行，不强制依赖 CoreZT 托管的云控制平面。联网部署可选用 ZTXHub 集中管理软件更新和许可；独立部署则采用手动流程。

比较自托管与云 ZTNA

4. 在访问策略之前建立身份生命周期​

认证用于证明身份，而用户配置与生命周期控制决定该身份是否还应该存在，以及它具有什么组织上下文。

在启用生产访问前，应明确：

  • 用户在哪里创建
  • 组或角色如何分配
  • 身份变化如何同步到 ZTNA 平台
  • 用户离职后如何移除访问
  • 临时身份如何到期
  • 普通访问和敏感访问分别采用什么认证方式

ZTXGate 可使用 OIDC 进行认证，并使用 SCIM 进行用户配置和身份生命周期同步。

了解身份与设备信任

5. 设计设备注册与设备信任​

仅知道用户身份，还不足以说明请求来自哪个终端。

应定义：

  • 设备如何注册
  • 某些资源是否只允许已注册设备访问
  • 设备更换或丢失时如何处理
  • 如何撤销设备访问
  • 某些资源是否需要设备姿态信息

在联网环境中，ZTXGate 可使用受支持集成提供的设备姿态信息，包括 Microsoft Intune、Microsoft Defender for Endpoint、SentinelOne Singularity、CrowdStrike 和 Jamf。

设备姿态应作为策略输入，而不是替代身份验证或资源授权。

6. 围绕真实访问意图建模资源​

资源模型应该反映用户实际上被允许访问什么。

例如，与其让开发组访问整个网络段，不如分别定义真正需要的服务：

  • 源代码服务
  • 构建系统
  • 开发应用服务器
  • 内部文档

生产管理可以保持为独立资源，并采用单独的策略范围。

对每个资源都应回答：

  • 谁负责这个资源？
  • 谁需要访问？
  • 从哪些设备访问？
  • 使用什么协议？
  • 是否受时间或审批条件约束？
  • 是否需要额外认证？

少量清晰、容易解释的策略，通常比充满例外的复杂规则集更容易长期运维。

7. 为不同资源选择合适的访问路径​

并不是所有资源都需要相同的访问机制。

在 ZTXGate 中，有两种特别重要的访问模式。

受管访问​

受管终端通过基于 WireGuard 的连接访问已授权资源。隧道负责安全传输，而 ZTXGate 策略决定终端实际上能够访问哪些资源。

当终端需要通过网络协议访问受保护资源时，这种路径更合适。

无客户端 Web 访问​

获得许可的无客户端访问功能可以代理私有 HTTP 和 HTTPS 应用，使获授权用户无需在终端安装 WireGuard，即可通过浏览器访问这些应用。

这适合相应的 Web 应用，也适用于部分承包商或第三方访问场景。

应根据资源需求选择访问路径，而不是强制所有应用都使用同一种机制。

了解 WireGuard 与 ZTNA · 了解无客户端 ZTNA

8. 从简单策略开始​

第一条策略最好能够用一句话说明。

例如：

开发角色成员可以从已注册设备访问开发应用。

只有在确实解决实际需求时，才添加额外条件。

根据资源不同，策略可以考虑：

  • 身份和角色
  • 已注册设备
  • 可用的设备姿态
  • 网络位置
  • 时间
  • 资源
  • 访问时长
  • 审批状态
  • 额外认证要求

对敏感资源，可以根据需要使用临时访问、请求与审批流程以及加强认证。

不要自动复制所有历史 VPN 或防火墙规则。ZTNA 实施也是清理那些已经没有明确业务目的权限的机会。

9. 从试点阶段就纳入审计和监控​

不要把可见性建设推迟到上线之后。

试点期间，应确认运维人员能够回答：

  • 谁尝试访问？
  • 涉及哪台设备？
  • 请求了哪个资源？
  • 请求是允许还是拒绝？
  • 哪个策略条件影响了决策？
  • 临时访问何时授予或到期？
  • 相关事件是否可以发送到组织现有的监控流程？

ZTXGate 支持审计记录，并可通过受支持的格式和传输方式把相关事件转发到 SIEM 平台。

了解 SIEM 集成

10. 验证失败和拒绝场景​

一次成功连接只能证明正常路径可以工作。

应有意测试负面场景：

  • 用户不具备所需角色
  • 设备未注册或已撤销
  • 设备姿态条件不满足
  • 临时访问已经到期
  • 审批请求被拒绝
  • 加强认证失败
  • 外部身份或姿态依赖不可用
  • 目标资源不可用

预期结果应该让安全团队和用户支持团队都能够理解。

对于断网环境，应在实际预期的网络状态下测试系统。外部云服务在不可达时无法提供策略输入。

11. 使用边界明确的用户组进行试点​

选择访问需求已知、回退路径可控的试点范围。

一个合适的试点通常包括：

  • 一到两个用户组
  • 少量资源
  • 明确的资源负责人
  • 清晰的支持联系人
  • 可衡量的成功标准

在扩大范围之前，先验证正常日常工作是否稳定。

成功标准可以包括：

  • 用户可以访问所有获批资源
  • 未授权资源仍然不可访问
  • 入职和离职变更能够正确生效
  • 设备撤销能够正常工作
  • 临时访问按预期到期
  • 运维人员可以找到所需审计记录
  • 支持人员能够诊断常见失败情况

12. 分批扩展部署​

试点稳定后，再分批增加用户和资源。

一种可能的顺序是：

  1. 风险较低的内部应用
  2. 开发与工程资源
  3. 承包商或合作伙伴访问
  4. 管理服务
  5. 敏感生产系统

具体顺序取决于组织情况。关键是每一批都要足够小，以便理解、测试，并在必要时回退。

如果 ZTNA 正在替代 VPN 访问，应随着每一批稳定下来逐步缩小旧 VPN 的权限范围，而不是长期保留重复的宽泛访问。

13. 为运维与恢复做好准备​

ZTNA 进入生产后仍需要一个长期运行模型。

应明确以下责任：

  • 访问策略的归属和定期审查
  • 用户与设备生命周期
  • 临时访问审批
  • 身份和设备姿态集成
  • 证书和密钥管理
  • 日志保留与 SIEM 转发
  • 软件更新
  • 备份保护
  • 灾难恢复测试

ZTXGate 采用备份与恢复模式进行灾难恢复，而不是传统的集群高可用模式。因此，管理员需要规划如何保护备份，并在需要时如何恢复新的替代部署。

了解安全与信任

14. 上线后继续审查策略​

ZTNA 不应该变成另一套永久权限集合，然后长期无人检查。

应定期审查：

  • 已不再需要某项资源的用户
  • 应该撤销的设备
  • 已经变得过宽的角色
  • 从临时例外变成永久权限的规则
  • 不再使用的资源
  • 对外部服务的依赖
  • 持续产生拒绝或支持事件的策略

目标是让访问权限持续符合当前业务需要，而不是历史习惯。

示例实施顺序​

一个实际的首批部署可以按以下阶段推进：

阶段范围主要验证内容
1. 基础身份源、首批用户、设备注册用户和设备是否正确表示
2. 首批资源少量开发应用是否能在不开放宽泛网络权限的情况下访问资源
3. 策略角色、设备、时间、临时访问条件允许与拒绝结果是否符合预期
4. 可见性审计记录与 SIEM 转发运维人员是否能够调查访问活动
5. 试点一个边界明确的用户组日常工作是否稳定且可支持
6. 扩展更多团队和更高价值资源范围扩大后策略是否仍然清晰
7. 运维备份、恢复、审查、更新部署是否可以长期运行

ZTXGate 如何支持这些步骤​

ZTXGate 将上述实施能力整合在由客户或 MSP 运行的 ZTNA 平台中：

  • OIDC 认证与 SCIM 用户配置
  • 独立设备注册
  • 受支持的 MDM/EDR 姿态输入
  • 资源级访问策略
  • 在相关策略条件变化时持续执行
  • 基于 WireGuard 的受管访问
  • 获许可的无客户端 HTTP/HTTPS 访问
  • 临时访问与请求/审批流程
  • 加强认证选项
  • 审计记录与 SIEM 转发
  • 本地、云托管、混合及 air-gapped 部署选项
  • 可选 ZTXHub，用于集中更新和许可管理

合理的实施仍然应该从小规模开始：先建立身份和设备生命周期，定义有限资源，创建简单策略，验证正面和负面场景，只有在运行模型可靠后再继续扩展。

开始免费试用了解 ZTXGate

VPN 到 ZTNA 迁移 · ZTNA 如何工作 · ZTNA 架构

相关指南与后续步骤​