零信任架构能继承遗留系统吗

本文目录导读：

1. 核心挑战：遗留系统为何与零信任“格格不入”？
2. 继承策略：让遗留系统“融入”零信任环境
3. 实施步骤建议
4. 底线与建议

这是一个非常实际且重要的问题,简短的回答是：可以，但需要分阶段、有策略地进行，并且通常需要对遗留系统进行适配改造或使用辅助技术。

零信任架构（ZTA）的核心原则是“永不信任，始终验证”，它并不要求所有系统都是全新的，遗留系统可以成为零信任架构的一部分，前提是它们能够满足或通过外部手段满足零信任的核心控制要求。

以下是详细的继承策略和需要考虑的关键点：

核心挑战：遗留系统为何与零信任“格格不入”？

1. 缺乏身份验证能力：很多遗留系统（如老旧的生产线控制系统、大型机应用或基于Windows NT的应用程序）使用硬编码密码、共享账户，或完全不支持现代的身份认证协议（如SAML、OIDC）。
2. 不加密通信：许多遗留应用通过网络明文传输数据（如HTTP、Telnet、FTP），违反了零信任“加密所有通信”的原则。
3. 难以实现微隔离：遗留系统通常部署在扁平网络中，依赖网络边界（防火墙）进行安全防护，难以在其内部实现细粒度的应用层隔离。
4. 难以修改：由于代码过于老旧、缺乏文档、或供应商已停止支持，修改遗留系统本身的代码成本极高，甚至不现实。

继承策略：让遗留系统“融入”零信任环境

核心思路是 “不信任遗留系统本身，而是通过其外围的控制点来弥补其安全缺陷”，主要策略包括：

身份与访问管理（IAM）代理

这是最常用的方法,在遗留系统前面放置一个代理或网关，由它来接管身份验证和授权。

• 实现方式：部署一个反向代理（如 nginx， Envoy， 或专门的零信任代理如 Zscaler Private Access, Cloudflare Access 等）。
• 工作流程：用户访问代理 -> 代理要求使用现代SSO（单点登录，如Okta、Azure AD）进行身份验证 -> 验证通过后，代理将用户身份（通过HTTP Header，如 X-Forwarded-User）传递给后端的遗留系统。
• 优点：无需修改遗留系统代码，即可引入多因素认证（MFA）、设备健康检测等零信任能力。
• 缺点：遗留系统内部仍然不“知晓”用户身份（可能仍使用共享账户），需要在代理上做精细的授权规则。

部署软件定义边界（SDP）或客户端代理

在用户设备上安装一个轻量级代理,该代理负责与远端的控制器通信，建立安全通道。

• 实现方式：用户需要访问遗留系统时，客户端代理先与SDP控制器进行双向验证（检查用户身份、设备合规性），验证通过后，控制器动态地在用户设备和遗留系统之间建立一个加密的、经过授权的隧道。
• 优点：实现真正的“隐式网络”，遗留系统只对已授权的、通过验证的连接可见，所有通信被强制加密。
• 缺点：需要部署和维护SDP基础设施和客户端代理。

应用层网关 / API网关

如果遗留系统暴露的是API（例如老旧的SOAP服务或REST API），可以在应用层加入网关。

• 实现方式：部署一个API网关（如Kong， Apigee， AWS API Gateway），所有API请求都必须通过网关，网关负责认证、限流、审计。
• 优点：可以精确控制每个API端点的访问策略，进行细粒度的日志审计。
• 缺点：适用于有API的遗留系统；如果是对用户界面（UI）的操作，则需要配合代理方案。

网络微隔离（微分段）

对于无法通过代理或API网关解决的遗留系统（例如老旧的生产控制协议，如Modbus/TCP），可以在网络层面进行微隔离。

• 实现方式：在虚拟化平台（如VMware NSX、OpenShift SDN）或网络硬件上，建立基于身份的防火墙策略，只允许特定的、经过“安全加固”的跳板机访问遗留系统，并严格限制其能访问的端口（如仅允许SSH或特定TCP端口）。
• 优点：不修改应用，降低了攻击面。
• 缺点：管理复杂，粒度较粗；无法获得应用层身份信息，容易产生浮肿的防火墙规则。

实施步骤建议

1. 全面发现与分类：绘制一张完整的资产地图，找出所有遗留系统，按风险等级（如面向互联网、内含敏感数据、无法更新补丁）和修改难度进行分类。
2. 确定保护优先级：优先处理面向互联网或持有敏感数据的遗留系统，对于风险极低、完全内网的系统，可以暂时延后改造。
3. 选择“寄生”策略：对一个高风险的遗留系统，选择 代理/网关 作为切入方案，通常这是投入产出比最高的。
4. 进行概念验证（PoC）：在测试环境中，搭建代理，验证身份认证、SSO、MFA、设备合规性检查等功能能否正常工作。
5. 逐步迁移：不要求一步到位，可以先让一个团队通过零信任代理访问一个测试遗留系统，验证无问题后再推广到生产环境。
6. 持续监控与审计：零信任架构的核心是日志，确保代理能产出详细的访问日志（谁、什么时间、从哪个设备、访问了什么），用于异常检测和事后审计。

底线与建议

• 可以继承，但不要天真地直接接入。 将老旧的、未打补丁的Windows Server 2003系统直接暴露在零信任代理后面，它依然容易受到已知漏洞的攻击（如EternalBlue）。零信任解决了身份和网络访问控制问题，但不能替代操作系统级别的补丁管理。
• 优先考虑“隔离+跳板”：对于极度老旧、无法打补丁的系统（例如Windows NT 4.0或运行在DOS上的应用），建议：
  • 将其隔离在一个独立的、受严格NAC（网络准入控制）保护的VLAN中。
  • 只允许一个经过强化的跳板机（如Linux堡垒机，运行最新的OS和防病毒软件）通过SSH/RDP反向隧道连接到它。
  • 要求用户通过零信任代理先登录跳板机,再通过跳板机访问遗留系统。
• 预算与ROI：改造遗留系统的成本可能会高于其本身的价值，需要评估是延长其寿命（通过上述方法加固），还是计划将其淘汰或迁移到现代平台（如云原生的容器化应用）。

零信任架构不要求你淘汰遗留系统，但它会迫使你为遗留系统设计一个牢固的“安全外壳”，通过部署代理、SDP或API网关等技术，你可以让那些“老古董”在零信任的环境下安全地继续运行，直到它们被最终替代。