零信任安全：零信任为何至关重要（而且不只是用于访问控制）

摘要

过去几年，“零信任”一直是网络和应用访问领域的重要主题之一。本文将说明，零信任的核心可以概括为一组简单的基本理念。这些理念不仅适用于访问，还可更广泛地应用于网络安全领域。

本文提出了一个涵盖零信任广泛概念的框架，并将这些概念与推动当今应用安全业务领导者采取行动的现有业务背景联系起来。最后，本文阐述了零信任信念体系。该体系是应对当前及新兴威胁的工具和安全实施方案背后的驱动力，也将是后续论文的重点。

本文有两个目标：一是阐述应用业务领导者应秉持的安全理念；二是为安全从业人员介绍一个框架，并将在后续白皮书中进一步阐述。

ZTS：从原则出发，而非从技术出发

“零信任”一词在不同抽象层面涉及多种概念：有时指特定的解决方案架构，有时指采用特定技术的指导原则，有时也可能指产品的一项属性。我们认为，零信任安全的核心是一种思维方式，也是一套信念体系。在此基础上形成的技术和策略会利用特定技术，进而用于应对广泛的安全威胁。

零信任安全（ZTS）背后的理念体系，可以视为安全思维演进的下一阶段。这一演进始于多年前提出的“纵深防御”。纵深防御基于这样一种理念：任何单一防线都存在较小但切实的失守可能性，而为关键资产增加更多保护层可以降低这种可能性，既能减缓攻击者的行动，也会迫使其投入更多资源才能成功实施攻击。

零信任从三个维度推动了这一安全理念的成熟：

首先，它将保护理念从使用一组简单的“过滤器”控制应用访问，演进为根据具体情境对任何系统事务实施一组更适合相关资产的保护措施。每项事务都需要明确：谁正试图对谁执行什么操作。“谁”和“谁”可以是系统内或使用系统的任何组件，无论是人员、自动化组件还是一段代码。身份概念是确定谁和谁的关键，而授予身份的权限则用于明确哪些操作可以执行。
其次，它并不将安全决策评估视为静态且绝对的过程，而是更具动态性和适应性，并根据观察到的行为持续重新评估。决定如何处置每项事务（例如允许交互、阻止交互或进一步增强可信度等）时，还必须考虑更广泛的业务背景，尤其是风险与回报之间的权衡。
最后，该方法认为，无论设置多少层防护，只要攻击者动机足够强烈或足够幸运，就可能攻破或绕过这些防护。因此，及时检测任何失陷情况并缓解漏洞利用企图，也必须成为整体策略的关键组成部分。

这种演变在一定程度上源于时间的积累和经验的沉淀，但也日益受到另外两种应用安全趋势交汇的推动。具体而言，当今的应用架构带来了更大的潜在应用漏洞空间，尤其是来自应用基础设施“内部”的威胁。随着当今攻击者的手段日益复杂，这些漏洞可能被利用。与此同时，安全工具也在不断进步，尤其是与现代数据收集和分析能力结合使用时，已使防御策略关键组成部分的实际实施成为可能。

本引言的其余部分将概述我们的零信任安全方法框架及其范围。随后各节将进一步阐述问题陈述及其与其他当代零信任方法的关系，并探讨应指导解决方案技术选择与应用的核心理念，即“为什么”。后续论文将深入探讨“如何做”，即零信任成熟度模型对身份验证、访问控制和AI辅助分析等特定技术提出的要求。

ZTS：从“为什么”开始

如下图1所示，Simon Sinek的“从为什么开始”方法是阐释ZTS框架的有效工具。可以由外向内查看此图：先了解ZTS所应对的威胁类别，再深入了解所采用的安全方法，最后将其归纳为共同原则。也可以由内向外查看：以核心理念为指引，由此选择适当的工具和技术，进而应对广泛的威胁。

图1：零信任安全的信念体系、工具和优势

后续章节将深入介绍此图中的每个同心层，简要来说：

核心理念源于将用例表述为：
“谁正试图对谁执行什么操作？”
- 要确定 “谁” 和 “对谁”， 明确验证 任何身份声明。
- 确定主体后，运用最小权限原则限制可执行的操作。
- 持续评估和重新评估以下三个因素：谁、什么以及对谁，并根据策略约束持续进行验证。
- 始终假定会发生入侵和失陷。如果相关操作（对谁执行什么操作）经风险收益分析后超过预先设定的可接受安全阈值，请做好干预准备。风险收益分析是指结合错误批准交易所造成的业务影响，对身份验证中的欺诈可能性进行权衡。
采用的方法如下：
- 身份验证和访问控制，用于以一定的置信度确定谁，然后限制该身份针对特定哪些对象可执行的哪些操作。
- 可见性和机器学习辅助分析，用于观察并持续评估每笔事务的完整上下文，即谁对谁做了什么 to 。
- 自动化风险感知修复，在风险回报水平超过指定的容忍阈值时介入交易。
应对多种网络攻击，具体方法如下：
- 传统攻击，例如篡改网站或数据外泄。可以通过以下方式应对这些攻击：检测身份凭据泄露或权限提升，并运用身份验证和访问控制技术，通过策略限制谁可以执行哪些操作。
- 可用性攻击和DDoS攻击：将身份验证和访问控制与风险感知型补救措施相结合，以应对此类攻击。例如，阻止（或限制速率）未经身份验证或身份验证不充分的行为者访问资源密集型事务。
- 高级威胁，例如勒索软件或供应链攻击。通过检测以下行为的变化和异常，可以应对这些威胁：谁正在对什么对象执行何种操作，并结合风险感知型修复措施。

ZTS的范围

零信任安全应全面覆盖整个应用、基础设施和交付堆栈，并贯穿完整的开发管道。具体而言，应包括：

完整的“自上而下”应用和基础设施堆栈
- 硬件计算基础，包括服务器、网络接口卡、协处理器和系统板组件
- 硬件的底层固件和BIOS。
- 最底层的操作系统，例如虚拟机监控程序或运行时执行程序。
- 应用程序级操作系统或容器操作系统。
- 导入的第三方应用组件，包括商业组件或开源组件。
- 任何内部开发或定制的应用软件。
完整的“从左到右”应用交付堆栈
- 用于持续维护和升级“自上而下”堆栈中各个元素的供应链。
- 任何内联应用交付组件，例如防火墙、负载均衡器、API网关、入口/出口/网格控制器以及内联欺诈缓解设备。
- 任何间接影响流量处理的应用交付组件（例如域名系统（DNS）解析器），或间接接收元数据的应用交付组件（例如安全信息和事件管理（SIEM）解决方案或联合身份服务）。

传统上，零信任主要面向应用开发和交付团队，通常涉及Dev、DevOps、DevSecOps和SRE等角色。之所以指出这一点，主要是为了从更广阔的视角审视零信任：理想情况下，全面的零信任方法还应涵盖非传统角色和基础设施，以及供应链采购策略等其他工作流。

问题陈述

CIO和CISO的首要任务之一是推动信息技术现代化，助力业务加速发展。他们还在企业风险治理中发挥关键作用。其目标是在尽可能降低业务风险的同时，帮助企业通过全新的数字体验赢得客户，借助与第三方的数字化连接提高运营效率，并让员工能够随时随地高效工作。为此，CIO和CISO所在组织既要让员工能够采用最新技术、架构和最佳实践来提升敏捷性，又要要求这些员工采取适当的安全措施，并对人员行为、所访问的信息及所使用的技术实施管控，以防范损失风险。

组织必须了解并控制与市场和宏观经济状况变化、消费者行为、供应链及安全暴露相关的风险。准确评估风险并迅速采取缓解措施的能力，有助于企业形成竞争优势。本文重点探讨安全暴露风险，此类风险可能导致知识产权损失、业务流程中断、个人身份信息丢失以及监管机构罚款等后果。可通过评估所考察情形的以下方面来计算安全风险：

相关资产的价值
交易涉及的资产具有不同的重要程度。例如，包含个人身份信息的数据库比列出企业产品零售网点的数据库更有价值。安全和IT团队可以采用确定性流程创建所有资产的清单，并根据代表资产“价值”的评分对其进行分类。
失陷影响
失陷的性质决定其造成的影响。例如，包含个人身份信息的数据存储中，信息被秘密窃取所造成的影响远高于数据存储可用性中断所造成的影响。尽管这一指标相对难以明确界定，仍可列出各种失陷类型，并为其分配“影响”评分。
失陷的可能性
交易导致资产失陷的概率，是评估该交易相关风险时最难以确定的因素。人类无法处理如此大规模的必要观测数据，因此组织会采用机器学习和人工智能，提高失陷概率计算结果的可信度。

当前面临的挑战是，近乎实时地计算每笔交易的相关风险，并采取适当的缓解措施，以控制潜在失陷造成的影响。

认识问题

业务加速发展的需求催生了新的实践方式，进一步加剧了网络安全风险。下文将对此进行更详细的讨论。

图2：业务压力推动采用新做法，进而加剧风险。

业务加速需求
1. 数字体验
  消费者对数字体验的需求持续增长，并要求在多个平台（PC、平板电脑、手机）上频繁改进体验。
2. 互联业务
  数字化业务流程需要与合作伙伴、供应商、分销商以及其他企业提供的服务建立连接。
3. 移动办公团队
  员工需要能够随时随地访问业务应用，以提高工作效率。
满足业务需求的实践
1. 敏捷开发方法
  企业从注重按时交付项目的顺序式瀑布开发方法，转向采用增量式、迭代式的敏捷开发方法，更加重视客户满意度。
2. 使用现成软件
  为了尽快提供全新的数字体验，开发人员会复用业内同行开源的代码。
3. 合同开发
  将工作外包给合同制开发人员，有助于企业按需扩充人员规模。
4. 使用云基础设施
  云具有敏捷性、灵活性和可扩展性，且易于使用，使开发人员能够按需获取所需的基础设施。
5. 采用SaaS
  软件即服务（SaaS）有助于业务运营应用减少在私有数据中心采购、部署和维护此类应用所带来的大量负担。
6. 微服务架构
  团队使用微服务实现持续交付，加快产品上市速度。
7. 分布式应用组件
  组织通过在配备适用工具的基础设施中运行微服务，提高服务功能的开发或交付效率。近期对传统工作流的扩展采用现代应用架构，需要与传统组件通信，而两者通常运行在不同的基础设施上。
8. 开放API
  由多种服务构成的生态系统，比企业自行开发所有服务更高效。
9. 与第三方的网络连接
  企业通过加密隧道与合作伙伴、供应商和分销商建立连接，从而实现业务流程自动化并简化流程。
安全风险加剧
1. 攻击面扩大
  使用第三方软件和开源库会为供应链攻击创造可乘之机，同时还会继承外部开发软件中的所有漏洞。合同开发人员的主要目标是按时完成功能开发，安全并非其关注重点。此外，一旦他们交付软件并退出项目，内部团队便需要耗费大量时间和精力审查代码并查找安全漏洞。敏捷冲刺能够高效交付功能，但开发速度加快后，往往没有足够时间开展详细的安全审计和测试。只要一个存在漏洞的微服务能够与其他微服务通信，就会增加整个系统的安全风险。互联业务虽然提高了运营效率，但也会带来严重后果：其中任何一方的安全漏洞都会影响所有相关方。攻击者会找到最薄弱的环节，并以此为突破口向其他部分扩散。SaaS平台或云基础设施中的漏洞或安全疏漏会成为额外的攻击途径，而责任共担模型可能会增加早期检测和修复的难度。
2. 架构复杂性增加
  分布式应用组件采用不同的架构开发，并部署在多种基础设施上，因此具有不同的安全与合规需求。这使安全团队难以设计和部署适当的机制来保护企业应用和数据，并满足监管合规要求。
3. 资金充足、动机强烈且技术娴熟的黑客
  从2010年的“极光行动”到2020年的Solargate，十年间发生了多起高级网络攻击，往往在造成严重损害后才被发现。即使相关组织配备了先进的安全技术，并由训练有素的安全团队负责运营，仍然发生了安全事件。攻击者在这些组织的IT基础设施中长期潜伏，之后才被发现。知识产权和个人身份信息遭窃，业务运营中断，组织遭到勒索软件劫持。与此同时，IT和安全团队不仅遵守了旨在防范网络攻击的法规要求，还采取了额外措施。

美国政府指令

在美国多个联邦、州和地方政府机构以及数家美国企业持续遭受一连串网络攻击后，乔·拜登总统于《关于改善国家网络安全的行政命令》2021年5月12日签署了该行政命令。其中一项关键内容是要求政府机构运用零信任原则，为应对网络攻击做好准备。随后，拜登政府于2022年1月26日向各行政部门和机构负责人发布了美国管理和预算办公室（OMB）备忘录。这份OMB备忘录“制定了联邦零信任架构（ZTA）战略，要求各机构在2024财年结束前达到特定的网络安全标准和目标，以加强政府抵御日益复杂且持续不断的威胁活动的能力。”¹该行政命令和OMB备忘录均引用了美国国家标准与技术研究院（NIST）出版物SP 800-207中所述的零信任架构。该出版物于2020年8月发布，行政命令和备忘录均要求政府机构遵循这一架构。

Zero trust architecture与成熟度模型

政府机构和私营部门的思想领袖已发表多篇论文，帮助阐释零信任架构，并就如何更好地采用该架构提出建议。下面概述这些论文中的观点。需要指出的是，这些论文所述观点和建议的核心在于审查每笔事务，以评估谁正试图对谁执行什么操作，并根据计算得出的相关风险，实时决定允许还是拒绝该事务。

美国国家标准与技术研究院（NIST）：Zero trust architecture

NIST团队在其论文NIST SP 800-207中列出了零信任原则，并定义了一种抽象的零信任架构（ZTA）。²此外，他们还探讨了零信任方法的不同变体，并介绍了部署该抽象架构的不同方式。

本文讨论的关键抽象概念包括相互协作的策略决策点（PDP）和策略执行点（PEP）。策略决策点由策略引擎（PE）和策略管理器（PA）组成。策略引擎使用信任算法来决定是否应授予主体访问资源的权限。策略管理器负责执行该决策，并与策略执行点通信，以允许或拒绝建立新会话，以及修改或终止现有会话。此外，本文还讨论了信任算法的不同形式、零信任环境中的网络组件，以及各种用例或部署场景。最后，本文探讨了攻击者可能破坏零信任架构的方式，以提醒实施人员注意相关威胁，并采取适当措施保护零信任架构组件。

网络安全和基础设施安全局（CISA）：零信任成熟度模型

为帮助各机构制定零信任计划，美国网络安全和基础设施安全局（CISA）的思想领袖发布了零信任成熟度模型（https://www.cisa.gov/zero-trust-maturity-model）。³该模型以NIST SP 800-207文件中描述的抽象零信任架构为基础。作者确定了五个领域，并建议组织在每个领域持续推进零信任原则的落实。这些领域包括：（i）身份、（ii）设备、（iii）网络、（iv）应用工作负载和（v）数据。他们建议在这五个领域中运用可见性与分析，以及自动化与编排。

该文档针对前文确定的零信任五大基础支柱提供了一个总体成熟度模型，并进一步深入探讨各个领域。组织可以利用该成熟度模型了解自身现状，并制定迭代式改进路径，逐步迈向理想状态。

美国国防部（DOD）：零信任参考架构

在发现SolarWinds攻击后，美国国家安全局（NSA）发布了指导文件《采用零信任安全模型》，建议网络安全团队采用零信任安全模型。⁴ 国防信息系统局（DISA）与美国国家安全局联合零信任工程团队的专家编写了美国国防部（DOD）零信任参考架构。⁵ 作者通过以下陈述说明了采用零信任的必要性：“DOD内外发生的数据泄露事件所暴露的漏洞表明，需要一种更稳健的新型网络安全模型，以便基于充分信息和风险做出决策。”⁶

此参考架构基于NIST SP 800-207零信任架构文档中定义的抽象概念提出建议。该文档提供了高层级运营模型，并详细说明其组成要素。文档还包括高层级成熟度模型，以及将零信任原则应用于各个重点领域所需的能力映射。这些文档共同帮助组织评估当前状态并制定计划。

运用零信任原则管理风险与治理

秉持“假定已发生入侵”的理念并遵循零信任原则，有助于组织开展风险管理和治理。通过遵循“持续监控”和“显式验证”交易参与者的零信任原则，组织可以为所有参与者及其活动建立动态风险评分。这与Gartner建议采用“持续自适应风险与信任评估”（CARTA）方法来增强现有安全计划的理念一致。采用仅允许以最小权限访问资源的原则，即使发生入侵，也能降低损失风险。持续监控和显式验证所生成的信息也有助于生成合规报告。

深入了解思维方式

本节重点介绍思维模式，即推动企业围绕零信任安全所采用的工具和设计制定策略并做出决策的信念体系和“原因”。事实上，当今零信任解决方案所采用的各种方法和组件技术，其背后的驱动力可以归纳为4项简单的关键原则。本节首先列出这些原则，然后探讨如何在更广泛的应用开发生命周期中运用这些原则，即如何在前期设计阶段考虑这些原则，以及如何在应用的部署和运行阶段将其落实到运营中。

零信任运营原则

如果将零信任解决方案理解为从根本上在系统交互中建立信任，即“谁在对谁做什么？”，那么，建立与交互相适应的信任级别可分为四个组成部分。

显式验证

顾名思义，零信任理念强调“不要盲目信任，始终进行验证”。因此，系统中的任何参与者，也就是系统交互中的“主体”和“客体”，都必须能够：

证明其身份，包括“匿名”身份这一特殊情况，前提是系统允许以匿名身份为来源或目标的交互，例如航空公司预订系统中的匿名浏览器。对于所有其他身份，参与者必须能够在系统接受的命名空间中声明自己是谁。
接收并验证用于佐证参与者所声明身份的“证明”（适用于任何已声明的非匿名身份）。此类“证明”的性质（如密码、证书、行为等）及其证明力可能各不相同，但系统必须能够确定该身份声明具有一定的可信度。简单系统可能仅以“是/否”二元方式判断证明的可信度，而更高级的系统可能采用数值化的置信度评分，并将其明确用作基于风险与回报的策略的一部分。请注意，系统还可以通过其他方式提高或降低置信度，例如根据参与者对主动质询的响应，甚至通过被动观察参与者的行为来调整置信度。
通过结合历史行为进一步分析当前行为的上下文，评估并调整对已证实身份的置信度。例如，系统可以保留有关行为主体的历史元数据，如其过去和当前的地理位置、硬件平台、IP地址、信誉等，以提高或降低对身份“证明”的置信度。

此外，“显式验证”原则不仅适用于身份，也适用于操作，即交易中的“内容”。一种常见用例是以API调用表示操作，例如调用API执行数据库查询。在此示例中，“显式验证”原则不仅可用于确认API调用者的身份可信度，还可用于验证API操作的使用是否正确，例如验证传递给API的参数是否符合相应的约束条件。

在成熟的零信任理念中，“证明”几乎从来都不是绝对的。身份凭据可能被盗，设备可能遭到入侵；API参数约束通常并不完整。因此，在零信任语境下，“置信度”应理解为一种指标，用于表明经验证的身份或事务参数为合法信息的可能性。因此，在决定允许、阻止还是进一步检查事务时，应将“置信度”水平视为一个关键因素，但不是唯一因素。

最小权限

在对参与交易的主体建立可接受程度的“信任”后，零信任方法要求仅向该主体（通常是请求者，即“谁”）授予其在该系统中完成预定任务所需的最低权限。这一原则体现了所谓的“正向安全模型”，即默认禁止所有操作，仅根据系统运行需要授予特定权限。例如，预订系统可以允许匿名用户浏览航班时刻表，但根据应用设计要求，可能不允许匿名用户预订航班。

这些权限可应用于单个参与者，也可应用于参与者类别。通常，应用使用者是人类参与者或其代理，并按“匿名用户”“客户”“合作伙伴”或“员工”等类别分组。可信度较低的参与者类别通常只需达到较低的置信度阈值即可通过身份验证，但其可访问的API数量更少，或敏感程度更低。应用或其基础设施内部的参与者（例如应用中的特定服务或容器）通常可以拥有更加定制化的权限，例如：“只有容器<X>和<Y>可以访问数据库；只有<X>可以写入对象存储，但<Y>和<Z>可以从中读取数据。”

实施最小权限时，一个重要的考虑因素是经过周密规划，以更有针对性的方式应用最小权限。⁷具体而言，成熟的零信任实施不应对所有参与者或某类参与者统一应用一套通用权限，而应更细致地判断正在尝试执行什么操作。例如，从非常粗的粒度来看，可以授予“文件系统访问”权限，但“读取文件系统”能更精确地界定实际所需的权限，从而高质量地实施正向安全模型。

最后，更成熟的最小权限实施方式可以与成熟的“显式验证”实施方式结合使用，即不将参与者获得的授权权限视为绝对权限，而是以身份验证所提供的置信度为依据。因此，只有当经证明身份（谁）的置信度达到最低阈值时，才会授予权限，并且阈值会根据尝试执行的具体操作而定。例如，某些影响特别重大的操作（如关闭系统）可能要求系统对参与者是管理员这一身份的置信度达到90%或更高。在此示例中，如果尝试关闭系统时，系统对该身份的置信度仅为80%，则系统会要求进行额外验证，以提高经证明身份的置信度评分，然后才允许执行该操作。

持续评估

显式验证和最小权限是关键概念；但“持续评估”原则强调，必须持续评估这些原则，具体而言：

所有交易都必须经过验证和权限检查。换言之，不能只检查部分交易，例如“用户会话中的第一笔交易”或“通过Docker容器工作负载发起的交易”。这看似不言自明，但许多零信任实施方案并未验证所有交易，原因可能是设计不当或缺乏可见性。这方面的常见缺陷包括：仅对外部主体而非内部主体应用零信任，和/或假定零信任判定会在较长时间内持续有效。
评估中的关键因素，即对行为主体身份的置信度以及允许该主体拥有的权限，必须被视为动态且可能发生变化。例如，根据观察到的行为和旁路元数据，对某个身份的置信度可能会随时间提高或降低，因此，任何基于置信度的策略也必须随置信度的变化进行动态调整。此外，策略先前授予的权限阈值可能会在稍后撤销，执行某项操作所需的最低置信度也可能发生变化。策略变化的时间尺度各不相同，既可能较慢（与人工运维流程的时间尺度相当），也可能较快（通过自动化治理代理实现）；系统应能够动态响应并遵循这些变化。

假定已发生入侵

最后一项原则以适度的警惕为背景，基于攻击者具有强烈动机这一假设。具体而言，其前提是“假设已发生入侵”，其中“入侵”是指“在具备完备知识并正确执行的情况下本应拒绝、却被允许的事务”。此类漏网情况的根本原因可能是掌握的信息不完善（例如，未检测到欺诈性凭据，导致身份验证给出错误的高置信度评分），也可能是实施方面的限制（例如，授予的权限不够精细，如授予了“打开网络连接”权限，却无法根据网络目标的地理位置加以区分），还可能是零信任实施不完整所致（例如，未对内部使用的易受攻击的开源组件应用零信任）。

因此，零信任思维还必须考虑如何妥善管理此类违规事件并尽可能降低其影响。

这一原则的实施方式比其他原则更为多样，但通常体现为：

首先，识别技术上符合策略规定但存在可疑之处的事务。“可疑”通常高度依赖具体情境，但常见的判断包括：（a）与以往观察到的行为存在显著差异的异常事务；（b）单独来看正常、但整体来看异常的一组事务，例如，读写文件可能很常见，但以每秒1,000个文件的速率进行读写则可能异常；（c）与不希望出现且此前未曾发现的系统影响相关的操作，例如，某种模式下，特定事务会与TOR节点建立网络连接，或导致系统CPU负载显著增加。
然后，开展更深入的分析，可采用完全自动化的工作流，也可采用由人工控制、机器学习辅助的混合工作流，以确定这些事务是否无效。如果确定这些事务无效，则采取缓解措施。具体方式可以是更新通用策略，也可以增设一道“兜底”防线，作为其他策略驱动型缓解措施的补充。

如果选择基于策略的调整方法，则可利用任何可用的静态策略工具来实施调整。例如，可以限制事务粒度的访问控制权限（即不再允许谁对谁执行什么操作），也可以改为对某个行为主体（或某类行为主体）执行特定操作采用更严格的“证明标准”（即要求进行MFA或达到更高的置信度分数）。

如果选择增加一层“兜底”机制，也可以采用细粒度或粗粒度方式实施。粒度最细的策略是仅精准阻止风险收益比超过特定阈值的交易；但如果实施时需要额外分析，这种方案也可能导致某些获准交易出现不可接受的延迟。也可以改用粒度较粗的策略，例如将该行为主体后续的交易置于沙箱中，甚至完全禁止该行为主体访问系统。在极端情况下，可能适合采用粒度更粗的缓解措施，例如关闭文件I/O。

当然，在其他条件相同的情况下，通常更适合采用粒度更细的后备缓解措施。不过，往往需要根据现有解决方案技术的限制进行权衡，而且采用粗粒度后备措施通常比不采取后备措施更好。例如，如果为防范疑似勒索软件而采取的粗粒度响应是禁用文件I/O，那么在不采取行动会导致文件系统被勒索软件加密的前提下，这种响应的副作用可能仍比另一种选择更容易接受，即任由该行为主体继续在系统中不受约束地活动。

零信任：真正始于运营之前

采用零信任进行安全应用开发，合适的起点自然是开发之初。要将零信任原则落实到实际运营中，就应在应用开发流程的设计阶段融入相关基础原则。因此，在讨论集成到CI/CD流水线中的零信任运营解决方案时，必须先了解这些基础要素，并将其作为设计时的首要考虑因素。

这些基础要素的核心应体现系统行为交互的预期行为，并提供足够的可见性和控制能力，以便检测偏差并采取相应措施。预期交互用于定义每个行为主体（做什么）针对每个目标（谁）所执行的一组预期操作（对谁）。不过，在某些场景和环境中，预期交互模式可能尚不明确。在这种情况下，组织可以利用更深入的可见性来“发现”一组适当的交互，⁸然后将其编入策略。

例如，当前的ZTNA解决方案侧重于基于身份控制对应用外部API的访问，因此需要具备对身份验证API的可见性和控制能力。又如，在云工作负载保护平台（CWPP）场景中，要检测遭入侵的容器工作负载，需要了解每个容器执行的操作；如果需要实时修复，还必须实时获取这些信息。

以下列出了设计过程中应纳入的基础考量因素类别，并进一步细分了各项要点需要思考的具体问题：

系统的黑盒接口（输入和输出）有哪些？
- 与应用交互的用户分为哪些类别（管理员、已认证用户、未认证用户、合作伙伴），他们需要执行哪些操作？
- 所有通信是否都通过已定义的API进行？还是也存在“原始”网络通信，或通过数据库、对象存储等数据存储进行的通信？
  - 对于API通信，API是否明确定义了哪些用户可以与其交互，以及这些交互受到哪些约束（例如参数约束、速率限制等）？
  - 对于任何网络通信，传输的所有数据是否都经过加密？
  - 如果存在任何“原始”数据接口（例如，客户端与应用程序通过对象存储或数据库共享信息），是否有审计日志可用于跟踪何人在何时访问了哪些信息？
同样，从内部“白盒”层面来看，构成整个应用的组件服务有哪些（包括任何由外部提供的服务），这些服务之间如何通信？
- 这些服务如何通信？使用什么API？这些交互受到哪些约束（角色、访问控制、速率限制、参数等）？
  - 围绕API的规范程度及其约束条件，以及通信加密，也存在与上述类似的问题。
  - “内部”（例如，工作负载或容器之间）通信更有可能使用共享内存和基于文件系统的接口；应识别所有此类接口。
系统提供哪些控制机制来限制对黑盒接口和内部通信路径的访问？
- 是否有策略规定哪些人员（即哪些角色）可以调用特定API，以及违反策略时会发生什么？同样，系统提供了哪些机制来检测和缓解任何形式的API滥用，例如使用无效参数或调用频率过高？这些策略能否根据其他系统提供的上下文信息进行动态更新？
- 同样，是否有策略对工作负载之间的其他通信形式（文件系统、对象存储和数据库表）加以限制，规定哪些主体可以访问哪些文件、存储或表，并防止滥用这些资源（例如，“SELECT * from <table>”）？
系统提供哪些可观测信息（仪表板、日志、统计数据），以限制对黑盒接口和内部通信路径的访问？
- 系统能否识别何人在何时调用了哪个API？这些数据是否会保留？如果会，保留多长时间？此类数据多久可以获取（实时、每小时等）？数据是否便于使用？它是非结构化文件日志、可发送至安全事件和事件管理（SEIM）服务的结构化JavaScript对象表示法（JSON）数据，还是记录在大数据数据库表中的数据？
- 对于内存、文件、对象和数据库等其他通信路径，上述问题的答案是什么？谁在执行哪些操作？这些数据如何公开？
除了通信路径之外，系统还提供哪些控制和可见性，以防止资源超额分配或过度消耗？
- 系统是否能够查看资源消耗指标，例如CPU、内存、带宽和Pod扩缩容等？如果可以，数据的粒度如何，是否便于使用？
- 系统是否设有资源消耗控制措施或防护机制，例如每个工作负载的内存、CPU和文件I/O限制，进程创建系统调用跟踪，Pod纵向扩展和横向扩展限制，以及调用其他服务的API速率限制？

明确提出这些问题，有助于发现实现零信任所需的基础中存在哪些缺口。通常，只需在设计初期提出这些问题，就能以极少的额外设计工作弥补缺口。对于可能持续存在的缺口，了解其存在也有助于确定需要重点加强安全防护的方面，或识别易受攻击的威胁面。

开展此类前期安全开发分析是零信任理念的重要组成部分。然而，当前零信任的关注重点大多是初始设计之后的工作，大多数企业也主要关注零信任在设计完成后的相关方面。不过，如果在设计阶段充分考虑有效实施零信任的要求，就能避免应用部署后为“填补漏洞”而投入更多额外工作。

缓解措施的考量因素：及时性、误报与漏报以及风险

正如这种思维模式所体现的“假定已遭入侵”前提，安全从业人员必须假定，某些动机足够强烈的攻击者终将设法执行恶意事务，即某个“谁对谁做了什么”的实例虽然符合策略规则，但在理想情况下本不应获准执行。在这种情况下，重点将转向建立有效的“兜底”机制，以发现此类情况。该机制通常基于对事务模式和系统副作用的观察，具体如前文“假定已遭入侵”部分所述。

然而，与身份概念一样，我们永远无法完全确定某项具体事务是否具有恶意。因此，与身份一样，理想的零信任解决方案应报告事务合法性的“置信度”评分。例如，如果观察到某个守护进程以正常文件读写速率的10倍持续读写10秒，其恶意行为的置信度可能为70%；但如果速率提高到正常水平的100倍并持续1分钟，置信度可能会升至95%。在此示例中，采取阻止后续文件写入的补救措施仍有一定概率（30%或5%）属于错误响应，即“误报”。因此，在决定是否采取补救措施时，必须权衡误报风险与允许潜在恶意行为可能造成的影响。

该示例旨在说明，任何采取用户可感知的补救措施的决定，本质上都是一项业务决策，需要综合考虑可疑活动涉及的所有风险、成本和收益。增加交易阻力会提高无法实现预期价值的可能性，但不干预或不增加阻力则会带来遭受入侵的风险。因此，在此类情况下，是否采取行动取决于以下三个输入因素：

允许可能存在恶意的交易继续进行会带来哪些风险？
这类风险可能是直接的经济损失，例如银行资金被转走；也可能产生间接成本，包括运营成本（例如关键记录被加密并遭到勒索）或品牌成本（例如网站被篡改）。此外，还可能产生法律或合规成本，例如客户个人数据泄露所导致的成本。归根结底，风险评估属于治理问题，良好的治理能够识别并量化应用面临的风险。
采取补救措施会产生哪些副作用？
副作用可从以下两个维度衡量：（a）引入的阻力；（b）影响范围。阻力是指合法交易继续进行的难度增加了多少，程度可能从略有不便（例如，增加一层身份验证）到完全无法进行（即不允许该交易）。影响范围是指其他独立交易是否也会受到影响，以及会影响多少交易。例如，阻止特定用户只会影响该用户，但关闭日志记录服务会影响所有用户和交易的可审计性。
认为该交易具有恶意的置信度有多高？
提高置信度通常意味着收集更多数据点，并对更多数据源进行关联分析，而这两项工作都需要时间。因此在实践中，这种权衡往往可以归结为：“在决定采取行动之前，应该观察多长时间？”

因此，尽管零信任策略必须正视安全事件必然会发生这一事实，但对于已获准却显得可疑的事务，审慎的做法是在采取补救措施时权衡风险与回报。这种权衡需要考虑不同应用事务的风险级别以及采取补救措施的后果，并且仅在风险级别超过预期业务回报时才采取补救措施。

_{¹ https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
² https://csrc.nist.gov/publications/detail/sp/800-207/final
³ https://www.cisa.gov/zero-trust-maturity-model
⁴ https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
⁵https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
⁶https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v1.1(U)_Mar21.pdf
⁷ 如后文所述，这种预先考量始于设计阶段。
⁸或者至少是系统似乎需要的一组“被认为适当的”交互。通过观察得出的交互集合始终可能不完整，也可能存在某些既有风险。因此，最好始终在设计阶段预先加以考量。}

发布于2022年5月4日

联系F5