零信任安全：为什么零信任对网络安全如此重要（不止访问安全）| F5

摘要

在过去的几年中，“零信任”概念一直是网络和应用访问领域的主题之一。本文展示了如何用一组简单的观念来表述零信任的核心特征；同时，这些观念不仅适用于访问，还适用于更广泛的网络安全领域。

本文提出了一个框架，涵盖了围绕零信任的广泛概念，并将其与激励当今应用安全业务领导者的现有业务背景联系起来。最后，本文还提出零信任观念系统的特征描述，即应对当前和新兴威胁的工具和安全实施背后的驱动力，这些内容将是后续文章的重点。

本文有两个目标：首先，向业务应用的领导者们传达应该接受的安全思维模式，第二，向安全从业人员介绍一种框架，我们会在后续推出的白皮书中详述该框架。

ZTS：从原则而非从技术开始

“零信任”这条术语在不同的抽象层面上与多种不同的概念相关联：它有时是一种具体的解决方案架构，有时是一种应用具体技术的方法，还有时可能指代一种产品属性。我们认为零信任安全的核心是一种思维模式（一种观念系统），技术和战术从中产生同时需要利用具体的技术手段应对广泛的安全威胁。

以零信任安全 (ZTS) 为基础的观念系统，可以看做安全思维模式演变的下一个阶段，这种演变从多年前的“深度防御”就开始了。深度防御需基于以下观念：即便可能性低微，任意单一防御屏障都会存在漏洞，但通过增加对重要资产的保护层就可以减少这种可能性，并减缓攻击者的速度，同时迫使他们使用更多的资源去完成一次成功的攻击。

零信任是这种思维模式臻至成熟的表现，体现在三个方面：

首先，它将保护的前提从一套简单的“过滤器”式门控访问进化为一套更适合保护资产的应用，并根据系统上下文将其应用于所有系统交易。每项交易的思维模式都是要理解：谁正试图对哪个对象做什么。“谁”和“对象”可以是系统内或正使用系统的任何组件，无论是人类、自动化组件亦或是一串代码。谁和对象的关键在于身份的概念，而一个身份被授予的特权的概念则用来编码可以做什么。
其次，它认为安全决策评估并不是静态和绝对的，而是更加动态且随需而变的，以便根据观察到的行为持续不断地进行重新评估。关于每项交易的处理决策（是否允许互动、是否阻止互动、是否建立额外信任等）也必须考虑更广泛的业务上下文，特别是风险与回报的权衡。
最后，一个既定事实是，无论提供多少保护层，一个动机充足或幸运的对手终将冲破或者绕过这些保护。因此，整个战略的关键还必须包括及时发现所有入侵并减少尝试中的攻击。

这种演变在一定程度上是时间和经验的结果，但是它越发被另外两种应用安全趋势的汇合所推动。具体来说，如今的应用架构为应用漏洞（特别是来自应用基础设施“内部”的威胁）开辟了更大的潜在空间，这些漏洞会被如今那些手段越发复杂巧妙的对手所利用。幸运的是，同步发展的安全工具能切实实现防御策略的关键部分，特别是在结合使用安全工具、现代数据集合以及分析功能时。

本引言的其余部分概述了零信任安全方法的框架和范围。接下来的章节将对问题陈述及其与其他当代零信任方法的关系进行扩展，然后讨论核心观念（即“为什么”），这种观念应该指导解决方案技术及其应用。后续文章会深入探讨“如何”，即对与零信任成熟度模型有关的具体技术（例如身份验证、访问控制和 AI 辅助分析）的要求。

ZTS：从为什么开始

Simon Sinek 的“从为什么开始”方法是介绍 ZTS 框架的有效工具，如下面的图 1 所示。可以用由外到内的角度来看这个图形，以 ZTS 应对的威胁类别开始，随后深入到所使用的安全方法，最后将其全部提炼为普遍原则。或者，可以从内到外的角度，以核心观念作为起点，从中产生适当的工具和技术，使你有能力应对广泛的威胁。

图 1 - 零信任安全：观念系统、工具和好处。

之后的章节会深入但简短地探讨该图的每个同心层。

该方法的核心观念来自于对用例的框定，如：
“谁在对哪个对象尝试做什么（操作）？”
- 为了确定谁以及对象，要明确验证所有身份证明。
- 一旦确定了谁，使用最小特权原则来限制可以执行什么。
- 持续评估并重新评估“谁”、“什么”、“对象”这三个因素，并且在政策约束内继续进行验证。
- 始终假定会发生漏洞和入侵。如果根据风险回报分析（身份验证中发生欺诈的可能性，以错误交易审批的业务影响为权重），该操作（对对象做了什么）超过了预定可接受的安全阈值，就要准备好进行干预。
所用的方法是：
- 身份验证和访问控制用于决定某信任级别的谁，然后限制该身份所允许进行的，与具体目标对象有关的什么（操作）特权。
- 可见性以及 ML 辅助分析 用于观察和持续评估每项交易的全部上下文，即谁正在对对象做什么。
- 自动风险意识修正会在风险回报级别超过特定的容忍阈值时对交易进行干预。
应用这些方法解决广泛的网络攻击：
- 传统的攻击，如破坏或数据泄露：可以通过检测身份入侵或特权升级来解决，利用身份验证和访问控制并根据政策限制谁可以做什么。
- 可用性/DDoS 攻击：将身份验证和访问控制与风险意识修正结合起来应对这些攻击。例如，可以阻止（或速率限制）未经身份验证或验证不力的行为者对资源密集型交易尝试进行的访问。
- 高级威胁（如勒索软件或供应链攻击）：可以通过检测谁正在对对象做什么行为中所发生的变化和异常，再配合风险意识修正来应对这些威胁。

ZTS 的范围

零信任安全可以全面延伸到整个应用、基础设施和交付堆栈，并应涵盖整个开发管道。更具体地说，应该包括：

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

传统上，零信任的重点已转向应用开发和交付团队，通常将它理解为 Dev、DevOps、DevSecOps 和 SRE 的角色。我们指出这一点主要是为了点明更广阔的图景；一个全面的零信任方法最好包括非传统角色和基础设施，以及额外的工作流，如供应链采购战略。

问题陈述

CIO 和 CISO 的首要任务之一，是将信息技术现代化，以便加速企业的发展。它们在企业风险治理上发挥着关键作用。其目的是为了帮助企业以新数字体验来让客户满意，通过与第三方的数字连接提高运营效率，保证员工无论在何处工作，工作效率都不会降低，并同时将商务风险降到最低，以此达到发展商务的目的。这要求 CIO 和 CISO 的团队允许它们的员工自由使用最新的技术、架构并灵活采用最佳实践，同时让这些人采取适当的安全措施，控制人们的行为、所访问的信息以及所使用的技术，以预防漏洞的损失。

企业必须了解并控制市场和宏观经济条件的变化、消费者行为、供应链和安全漏洞相关的风险。对风险的准确评估和采取快速缓解操作的能力是企业的竞争优势。在本文中，我们重点关注安全漏洞，安全漏洞在其他情况下可能引发知识产权的损失、业务流程的中断、个人身份信息的丢失以及监管机构的罚款。安全风险可以对所顾虑的情况进行评估，并根据情况中以下的几个方面来进行计算：

涉及的资产价值：
交易中涉及的资产有不同的重要级别。例如，包含个人身份信息的数据库，比包含销售企业所生产产品的零售点的数据库更有价值。安全和 IT 团队可以采用一个确定的流程来为所有资产创建清单，并按照代表资产“价值”的分数对清单内容进行分类。

入侵的影响：
入侵的性质决定了与其相关的影响。例如，若数据存储中含有个人身份信息，保证其隐蔽要比中断数据存储的使用更重要。虽然有些模糊，但可以列出各种类型的入侵，并给它们一个“影响”分数。

入侵的可能性：
交易导致资产被入侵的概率是评估交易相关风险时最不确定的因素。因为人类难以处理所需的观察规模，所以企业采用机器学习和人工智能来增加他们对入侵概率计算的信心。

目前的挑战是尽量实时地计算与每一项交易相关联的风险，并采取适当的缓解行动，以控制潜在的泄入侵风险。

认识到问题

业务加速的需求带来了新的实践，也加剧了网络安全风险。我们将在下文中详细讨论这一点。

图2 - 业务压力推动新实践，并增加了风险。

业务加速的需求
1. 数字体验：
  消费者的数字体验需求难以满足，他们要求对多个平台（个人电脑、平板电脑、手机）进行频繁改进。
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 财政年度 (FY) 结束前完成特定的网络安全标准和目标，以加强政府应对日益复杂和持久的威胁活动的防御。”¹行政命令和 OMB 的备忘录都提到了在 2020 年 8 月国家标准技术研究所 (NIST) 出版的 SP 800-207 中描述的零信任架构，并要求政府机构遵守这个结构。

零信任架构和成熟度模型

政府机构和私营企业的思想领袖已经发表了一些文件，帮助解释零信任体系架构，并就如何更好地采用该架构提供建议。我们将这些文件中的观点总结如下。我们注意到，这些文件中所包含的观点和建议，其极重要的本质是检查每一项交易，来评估谁在试图对对象采取什么行动，并根据对相关风险的计算，及时决定是否允许该交易。

国家标准技术研究所 (NIST)：零信任架构

NIST 团队在他们的文件 NIST SP 800-207中列举了零信任的原则并定义了一个抽象的零信任架构 (ZTA)。²此外，他们还讨论了零信任方法的差异以及部署抽象架构的不同方式。

本文讨论的关键抽象概念是政策决定点 (PDP) 和政策执行点 (PEP)，二者可以相互配合。政策决定点由政策引擎 (PE) 和政策管理员 (PA) 组成。政策引擎使用一种信任算法来决定是否应该将资源的访问权授予某个主体。这一决定由政策管理员执行，它与政策执行点进行沟通，决定是否允许一个新的会话，以及修改或终止一个现有的会话。此外，本文还讨论了信任算法的变化、零信任环境的网络组件，以及各种用例或部署场景。最后，还考虑了行为者会用来妨碍零信任架构的方法，以便实施者注意到攻击威胁，并采取适当的措施来保护他们的零信任架构组件。

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

为了协助各机构制定其零信任计划，网络安全和基础设施安全局 (CISA) 的思想领袖发布了一个零信任成熟度模型。³这个模型建立在 NIST SP 800 -207 文件中所描述的抽象零信任架构之上。作者们确定了五个领域，并建议在每个领域内，组织都能坚持在遵循零信任原则上取得进展。这些领域是 (i) 身份，(ii) 设备，(iii) 网络，(iv) 应用工作负载和 (v) 数据。他们建议在五个领域中都使用可见性和分析，以及自动化和业务流程。

该文件提供了一个高级别成熟度模型，涵盖了前面所确定的零信任全部五个领域的基本支柱，并深入到每个领域中。企业可以使用该成熟度模型来了解他们目前的状态，并设定一个向最优状态迭代的过程。

美国国防部 (DOD)：零信任参考架构

在发现太阳风攻击事件后，美国国家安全局 (NSA) 发布了指导意见，建议网络安全团队采用在其文件《拥抱零信任安全模型》中提到的零信任安全模型。⁴国防信息系统局 (DISA) 和国家安全局零信任工程团队的专家联合撰写了国防部 (DOD) 零信任参考架构。⁵作者表达了采用零信任的必要性，原话如下：“DOD 内外的数据泄露所暴露的漏洞表明，一个新式且更强大的网络安全模型必不可少，这种模型能帮助我们基于风险做出明智决定。”⁶

该参考架构以 NIST SP 800-207 零信任架构文件中所定义的抽象概念为基础提出建议。该文件提出了一个高级别的操作模型，并详细描述了其要素。它还包括一个高级别的成熟度模型，以及将零信任原则应用于各种利益领域的能力映射。这些文件共同帮助企业评估其当前状态并制定计划。

用零信任原则管理风险和治理

“假定漏洞”的态度和遵循零信任原则，可以帮助企业进行风险管理和治理实践。对参与交易的行为者，企业遵循“持续监控”和“明确验证”的零信任原则，能够让企业为所有行为者及其活动建立动态风险分数。这与 Gartner 的建议一致，即使用“持续适应性风险和信任评估”(CARTA) 的方法来加强现有的安全计划。采用只允许最小权限访问资源的原则，即使在发生漏洞后也能减少损失的风险。持续监控和明确验证所产生的信息在生成合规性报告时也很有用。

更详细的思维模式

本节旨在关注思维模式（即观念系统，“为什么”）。观念系统推动企业围绕为实现零信任安全所应采用的工具和设计制定战略和决策。事实上，我们可以将今天的零信任解决方案所采用的所有方法和组成技术的动力提炼为四个简单的关键原则。本节首先列举了这些原则，然后讨论了如何在应用开发生命周期的大背景下应用这些原则，也就是说，如何在设计阶段预先考虑这些原则，以及如何在应用的部署/运行阶段从操作上考虑这些原则。

零信任的操作原则

如果零信任解决方案被理解为从根本上建立对系统互动的信任（“谁在对对象做什么？”）那么，建立适合互动的信任级别的过程可以分解为四个部分。

明确验证

顾名思义，零信任的思维模式是一种“不要盲目信任，一定要验证”。因此，系统中的任何行为者（系统互动中的谁和对象）必须能够：

证明其身份，包括“匿名”身份的特殊情况，即使系统允许由匿名身份发起的或以匿名身份为目标的互动（例如航空公司预订系统中的匿名浏览器）。对于所有其他身份，行为者必须能够在系统接受的命名空间中说明他们是谁。
接收并验证行为者证明身份的附件“证明”（对于任何非匿名的证明身份）。这种“证明”（密码、证书、行为等）的性质可能不同，该证明的强度也可能不同，但系统必须能够确定对证明的信任达到某种程度级别。简单的系统可能对证明的信任有一个二进制的是/否的观点，而更高级的系统可能有一个数字信任分数，可以明确地作为以风险回报为基础的政策的一部分来参考。请注意，系统也可以通过其他方式增加或减少信任，如对主动质询的反应，甚至是对行为者行为的被动观察。
根据当前行为相对于过去行为的额外背景，评估和调整对已证实身份的信任。例如，系统可能会维护有关行为者的历史元数据，如行为人过去和现在的地理位置、硬件平台、IP 地址、声誉等，以便用于增加或减少对身份“证明”的信任。

此外，明确验证的原则不仅可以适用于身份，也可以适用于操作，即交易的内容。一个常见的用例是操作以 API 调用的形式出现，比如执行数据库查询的 API。在这个例子中，明确验证原则不仅可以用来信任调用 API 的行为者的身份，还可以用来验证使用 API 操作的正确性，比如验证传递给 API 的参数是否符合适当的约束。

在一个成熟的零信任思维模式中，“证明”几乎从来都不是绝对的。身份凭证可能被盗，设备可能被入侵，API 参数约束往往不完整。因此，在零信任的背景下，“信任”一词更应被解释为表明被证明的身份或交易参数是合法的可能性。因此，在决定允许、阻止或进一步检查一项交易时，“信任”级别应被视为一个关键因素，但不是唯一因素。

最小特权

一旦对参与交易的行为者建立了可接受的“信任”级别，零信任方法需要仅向行为者（通常是请求者，即“谁”）授予其所需的最小特权，以便其能够在该系统中完成其所设计的任务。这一原则体现了所谓的“积极安全模式”，即一种在默认情况下不允许所有操作，只有在需要运营系统时才授予特定特权的方法。例如，预订系统可能允许匿名用户浏览航班时刻表，但根据应用设计要求，可能不允许匿名用户预订航班。

这些特权可以适用于个别行为者，也可以适用于各类行为者。通常，应用使用者要么是人类行为者，要么是人类的代理，而且都按类别分组，例如“匿名用户”、“客户”、“合作伙伴”或“员工”。信任度较低的行为者类别通常需要较低的置信阈值就能通过身份验证，但他们也能访问更少或较不敏感的 API。应用或其基础结构内部的行为者，例如应用中的特定服务或容器，通常可能具有更多自定义特权，例如“只有容器和可以访问数据库，只有可以写入对象存储，但和可以从中读取。”

实施最小特权的一个重要注意事项是，要尽力以更具针对性的方式并且经过深思熟虑后应用它。⁷具体来说，成熟的零信任实施不应该在所有行为者或某类行为者中应用某组通用特权，而应该对尝试什么的操作有更详细的了解。例如，在粗颗粒水平上，“文件系统访问”可能被授予特权，但“文件系统读取”是对所需真正特权的更严格规范，这会带来对主动安全模式的高质量实施。

最后，可以共同实施以最小特权原则为基础更复杂的措施和成熟的“明确验证”，即不将授特权于行为者的行为视为绝对的，而是基于身份验证提供的信任度进行判断。因此，只有当已验证身份（谁）的信任度满足最小阈值时，才会授予特权，而阈值是针对正在尝试的操作。例如，某些特别有影响的操作（例如，关闭系统）可能要求行为者是管理员的信任度达到 90% 或更高。此例中，如果尝试关闭系统时，系统对身份的信任度只有 80%，那么在允许操作之前，系统将需要额外的验证来提高对已验证身份的信任度分数。

持续评估

明确验证和最小特权是关键概念；然而，持续评估原则捕捉到了这样一个事实：这些原则必须要受到持续评估，也就是说，

所有交易都必须经过验证和授权。换句话说，不应该只检查某个交易子集。比如“用户会话中的第一个交易”或“那些通过 Docker 容器工作负载启动的交易”。虽然听起来不言而喻，但许多零信任的实现并没有验证所有交易，要么是因为设计不当，要么是因为缺乏可见性。这一领域的常见缺陷是，只对外部行为者适用零信任，而不适用于内部行为者，和/或在很长一段时间内假设零信任裁决是正确的。
评估中的关键因素是行为者身份的信任度和允许该行为者享有的权利，必须要视其为动态易变的。例如，根据观察到的行为和边带元数据显示，身份的信任度可能会随着时间的推移而增加或减少，因此任何基于信任度的策略也必须动态调整以适应不断变化的信任度。此外，可能会在稍后撤销早先策略授予的特权阈值，或者某些操作所需的最低信任度可能会发生变化。虽然策略变更的时间尺度会有所不同，可能会缓慢变化（按照人工操作流程的时间尺度），也可能快速变化（通过自动化治理代理）。但系统应该能够动态响应和遵守它们。

假设违规

最后一项原则植根于健康的偏执狂背景下对高度积极的对手的假设。具体来说，前提是“假设您已违规”，其中“违规”被定义为“本应被拒绝（在完全知情和执行的情况下）却被允许的交易”。这种泄露的根本原因可能是不完善的知识体系（例如，由于欺诈凭证未经发现而导致的错误的高信任度的身份验证），或者可能是实施限制（例如，授予的特权没有足够的精细度特性，例如拥有“开放网络连接”作为一项特权，但无法根据网络目的地的地理位置进行区分），或者可能是由于未完全实现零信任（例如，未对内部使用易受攻击的开源组件应用零信任）。

因此，零信任的思维还必须处理好如何才能最好地管理/最小限度地降低这种违规行为的影响。

实施这一原则比其他原则变化更大，但一般表现为：

首先，识别尽管在技术上被政策允许，但却是可疑的任何交易。通常视具体情况而定，但常见解释是：(a) 与过去观察到的行为非常不同的异常交易；(b) 个体正常但集体不正常的交易组，例如，读写某个文件可能很常见，但以每秒钟读写 1000 个文件的速度可能是不正常的；或者 (c) 与突如其来的、以前未看到的系统影响相关的操作，例如，在某特定交易中，打开一个至 TOR 节点的网络连接或导致 CPU 系统负荷显著增加的模式。
然后，进行一些更深入的分析，或者通过完全自动化的工作流程，或者通过人工控制/ML 辅助混合工作流程，以确定这些交易是否无效。如果确定这些交易是无效的，则应用缓解措施。这可以采取一般政策更新的形式，或者作为额外的缓解层，为其他政策驱动的缓解措施提供“后盾”。

如果选择的方法是使用基于策略的调整，则可以通过利用任何可用的静态策略工具来应用调整。基于策略的调整的示例是限制详细交易的访问控制特权（即不再允许谁要对对象做什么），或者对行为者（或行为者类别）采取特定操作、应用更严格的“证明标准”（即需要 MFA 或更高的信任度分数）。

相反，如果选择使用额外“逆止”层的方法，则也可以用细粒或粗粒的方法实施该策略。最细粒的策略会精确拦截那些高于特定风险回报比的交易，尽管如此需要实施额外的分析，该解决方案也可能向某些允许的交易中添加不可接受的延迟级别。相反也可使用粗粒的策略，例如对来自该行为者的未来交易进行沙盒化，甚至完全不允许该行为者进入系统。在极端情况下，甚至采用更粗粒的缓解方法，例如关闭文件 I/O 这一做法，或许也是合适的。

当然，在其他条件相同的情况下，细粒逆止器通常是更佳选择。但往往必须根据可用解决方案的技术限制来进行权衡，粗粒逆止器通常比没有逆止器好。例如，如果粗粒逆止器对防止疑似勒索软件的响应是禁用文件 I/O，那么该响应的副作用仍然会比另一种选择更可取，即允许行为者继续在未检查过的系统中运营，前提是不作为的结果是加密了某个勒索软件的文件系统。

零信任：真正开始于操作之前

不出所料，安全应用开发使用零信任的最佳起点是在开始时。启用操作零信任原则的基本原则应内置于应用开发过程的设计阶段。因此，任何对集成至 CI/CD 流水线中的运营零信任解决方案的讨论都必须从了解这些基本要素开始，它们应该是最重要的设计考虑要素。

这些基本要素的核心应捕捉系统行为互动的期望/预期行为，再加上足够的可见性和控制，以检测偏差并采取行动。预期的互动行为被用来定义每个行为者（谁）对每个目标（对象）的预期操作集（什么）。也就是说，在一些场景和环境中，预期的互动模式可能是未知的。在这种情况下，企业可以利用更深入的可见性来“发现”某组适当的互动，⁸然后可以将其编入政策中。

例如，目前的 ZTNA 解决方案重点是对应用外部的 API 进行身份驱动的访问控制，该解决方案需要验证 API 的可见性和控制。或者，在云工作负载保护平台 (CWPP) 的背景下，检测受损的容器工作负载需要了解每个容器执行的操作的可见性，而且如果需要实时修复，则需要实时查看。

下列是与设计过程应注意的基本考虑要素有关的高级“存储桶”的清单，包括为每个关键点提供所要考虑具体问题的额外深入分析。

系统的黑盒接口——输入和输出的系统是什么？
- 与应用互动的各类用户（管理员、验证用户、非验证用户、合作伙伴）需要做什么？
- 所有通信都是通过定义的 API 进行的，还是“原始”网络通信或通过数据存储（如数据库或对象存储）进行的通信？
  - 对于 API 通信，就用户可以在哪些方面与之互动，以及与互动有关的限制（例如，参数限制、速率限制等）方面，API 的定义有多完善？
  - 对于任何网络通信，所有传输的数据都是加密的吗？
  - 如果有任何“原始”数据接口（例如，信息已通过对象存储或数据库共享给客户端和应用）的存在，是否有审核日志来追踪谁在何时访问了什么信息？
同样，在内部“白盒”层面，构成整个应用的组件服务是什么，包括由外部提供的任何服务，以及它们如何进行通信？
- 这些服务是如何通讯的？使用的 API 是什么？对这些互动的限制（角色、访问控制、速率限制、参数等）有哪些？
  - 如上所述，存在与 API 有关的形式及其限制和加密通信的类似问题。
  - “内部（例如，内部的工作负载/容器）”通信更有可能使用共享内存和基于文件系统的接口，任何此类接口都应可识别。
系统提供了哪些控制机制，以限制对黑盒接口和内部通信路径的访问？
- 是否有政策表明谁，即什么角色可以调用特定的 API？以及如果违反了政策将会发生什么？同样地，有什么手段可以检测和减少对 API 的任何形式的滥用（例如无效参数，或高频率调用）？这些策略是否可以根据其他系统的背景输入而进行动态更新？
- 类似地，是否有政策限制其他形式的内部工作负载通信（文件系统、对象存储、数据库表）？具体而言，规定谁可以访问哪些文件/存储/表，并防止滥用这些资源（例如，“SELECT * from”）。
  系统提供了哪些可见性工具（仪表板、日志、统计数据），以限制对黑盒接口和内部通信路径的访问？
  - 系统能否识别谁在什么时间调用了哪个 API？这些数据是否会保留，如果保留，保留多久？如何快速（实时，每小时等）提供这些数据？数据的可消费性如何？它是否是一个可以发送到安全事件和事故管理（SEIM）服务的结构化 JavaScript 对象表示法 (JSON)？还是记录在大数据库表中的数据？
  - 当涉及到其他通信路径（内存、文件、对象、数据库）时，同样问题的答案是什么？谁在做什么？这些数据是如何泄露的？
  除了通信路径之外，系统还提供了哪些控制和可见性，以防止资源超额订阅或过度使用？
  - 系统是否对资源消耗指标有可见性（CPU、内存、带宽、pod 伸缩等）？如果有，是什么粒度，以及该数据的可使用性如何？
  - 系统是否有针对资源使用的控制或防护措施（例如每工作负载内存 /CPU/ 文件 IO 限制、追踪调用创建系统进程、pod 的扩大/收缩限制、调用其他服务的 API 的速率限制）？
  明确地提出这些问题将帮助您发现在实现零信任的基础上还存在哪些差距。通常情况下，在设计早期，仅仅是询问操作就会解决差距，只需最小的额外设计投入。而且，在可能持续存在差距的情况下，对差距的简单认识将有助于引导额外的安全重点或识别脆弱的威胁面。
  做这种前期的安全开发分析是零信任精神象征的一个关键部分。然而，尽管如此，目前零信任的大部分重点与之后的初始设计所发生的事情有关，大多数企业的重点都集中在零信任的后期设计方面。然而，在设计阶段，需要对有效实施零信任的要求进行深思熟虑，以防止在部署应用后需要为“修补漏洞”作出更大增量的努力。

缓解注意事项：时效性、误报和风险

正如“假设违规”的前提所体现的那样，安全从业人员必须假设某个符合政策规则的“谁对谁做了什么”的实例，其中某些有足够动机的对手会设法执行一个恶意交易，但在一个完美的世界里，它是不允许存在的。在这种情况下，重点就转移到拥有一个有效的“后盾”机制，才能发现这些情况，通常是基于对交易模式和系统副作用的观察，正如前面“假如违规”部分所述。

然而，就像身份的概念一样，对特定交易是否是恶意的了解永远不会是完美的。因此，就像身份一样，理想的零信任解决方案应该报告交易合法性的“信任度”分数。例如，看到一个守护程序在 10 秒内以正常文件的 10 倍速率读写完毕，可能会导致 70% 的信任度分数（恶意），但看到速率增加至 100 倍，持续 1 分钟，可能会将信任度提高到 95%。此例中，采取抑制未来文件读写的补救措施仍有可能（30% 或 5% 的可能性）成为错误响应，即“误报”。因此，究竟是否决定补救必须考虑误报风险与允许可能存在的恶意行为的潜在影响。

此例重点是强调采取用户可见补救措施的任何决策实际上都是一个业务决策，一个考虑到可疑活动的所有风险、成本和回报的决策。在交易中引入额外的摩擦会增加无法收到价值的几率，但不干预/增加摩擦会带来妥协的风险。因此，在这种情况下，如果将采取行动（或不采取行动）视为函数，测此决定取决于以下三个输入：

允许恶意交易继续存在的风险有多大？
这种风险可能是直接的财务风险，例如银行资金的转移，也可能是间接成本，无论是运营成本（例如，加密密钥记录并索要赎金）还是品牌成本（例如，网站的破坏）。还可能有法律或合规成本，例如泄露客户个人数据。本质上，风险分配是一个治理问题，良好的治理将了解和量化应用的风险。

采取补救措施的副作用是什么？
副作用可以按照 (a) 引入的摩擦至 (b) 爆炸区这两个维度描述。摩擦是指进行合法交易时的困难程度；其范围可能从稍微不方便（例如，一个额外的验证级别）到不可能（根本不允许交易）。爆炸区指的是是否会影响其他任何独立的交易，如果是的话，有多少。例如，拦截某个特定用户只会影响该用户，但关闭某个日志服务会影响所有用户和交易的可审计性。