零信任安全：零信任为何如此重要（不仅仅针对访问）| F5

抽象的

过去几年，网络和应用访问的主要主题之一是“零信任”的概念。在本文中，我们展示了零信任的核心是如何通过一小组简单的信念来表征的，这些信念不仅可以应用于访问，而且可以更广泛地应用于整个网络安全领域。

本文提出了一个框架来涵盖零信任的广泛概念，并将其与激励当今应用安全业务领导者的现有业务背景联系起来。最后，本文对零信任信念体系进行了描述——这是解决当前和新出现的威胁的工具和安全实施的驱动力，这将是后续论文的重点。

本文的目标有两个：首先，传达应用业务领导者应秉持的安全思维；其次，为安全从业人员介绍一个框架，我们将在未来的白皮书中对此进行扩展。

零点转换：从原则开始，而不是技术

“零信任”一词与不同抽象层次的许多不同概念相关：有时作为特定的解决方案架构，有时作为应用特定技术的规定，有时可能指产品的属性。我们认为，零信任安全本质上是一种思维方式——一种信仰体系，技术和策略由此产生并利用特定技术，然后可应用于应对广泛的安全威胁。

零信任安全（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. 数字体验
  消费者对于数字体验有着无尽的渴望，他们要求多个平台（PC、平板电脑、手机）上不断改进。
2. 关联业务
  数字业务流程需要与合作伙伴、供应商、分销商以及其他企业提供的服务建立连接。
3. 移动劳动力
  为了提高执行效率，员工需要能够从任何地方访问业务应用。

满足业务需求的实践
1. 敏捷开发方法
  企业转向增量、迭代的敏捷开发方法，重点关注客户满意度，而不是注重及时交付项目的顺序瀑布方法。
2. 使用现成的软件
  为了尽快提供新的数字体验，开发人员重复使用业内同事开源的代码。
3. 合同开发
  将工作外包给合同开发商有助于企业根据需要扩大劳动力规模。
4. 使用云基础设施
  云的敏捷性、灵活性和可扩展性及其易用性使开发人员能够按需获得所需的基础设施。
5. 采用 SaaS
  软件即服务 (SaaS) 对于业务运营应用有利，因为它减少了在私有数据中心采购、部署和维护此类应用的负担。
6. 微服务架构
  团队使用微服务实现持续交付并缩短上市时间。
7. 分布式应用组件
  组织通过在提供开发或提供服务功能的最佳工具的基础设施中运行微服务来实现效率。对遗留工作流程的最新扩展是使用需要与遗留元素通信的现代应用架构完成的，并且两者通常在不同的基础架构上运行。
8. 开放 API
  一个由各种服务组成的生态系统比企业独自开发所有服务的效率更高。
9. 与第三方的网络连接
  企业使用加密隧道与其合作伙伴、供应商和分销商相互连接，以实现业务流程的自动化和简化。

增强安全风险
1. 增加攻击面
  使用第三方软件和开源库为供应链攻击创造了机会，并且所有外部开发软件的漏洞都会被继承。合约开发人员有动力按时完成功能，安全性不是他们关心的问题。此外，一旦他们交付软件并退出项目，内部团队将很难且耗费时间检查代码并查找安全漏洞。敏捷冲刺在交付特性功能方面非常高效，但是开发速度的提高并没有给详细的安全审计和测试留下太多的时间。一个存在漏洞的微服务能够与其他微服务进行通信，这会增加整个系统的安全风险。
  业务互联互通虽然提高了运营效率，但一个严重的后果是，其中任何一个业务的安全漏洞都会影响所有业务。攻击者找到最薄弱的环节，然后通过其余环节进行扩散。 SaaS 平台或云基础设施中的安全漏洞或漏洞会成为额外的攻击媒介，而共享责任模型可能会使早期检测和补救变得复杂。
2. 增加架构复杂性
  使用不同架构开发并部署在多个基础设施上的分布式应用元素具有不同的安全性和合规性需求。这使得安全团队很难设计和部署适当的机制来保护企业应用和数据，并满足监管合规性要求。
3. 资金充足、积极性高、技术娴熟的黑客
  从2010年的极光行动到2020年的太阳能门事件，我们经历了十年的先进网络攻击，这些攻击只有在造成巨大危害后才被发现。漏洞发生在配备了最先进安全技术并由训练有素的安全团队操作的组织中。在被发现之前，攻击者已经在这些组织的 IT 基础设施中驻扎了很长一段时间。尽管 IT 和安全团队竭尽全力遵守旨在防范网络攻击的法规，但知识产权信息被窃取、业务运营中断、组织被勒索软件劫持。

美国政府指令

在美国联邦、州和地方各政府机构以及多家美国企业遭受一系列持续网络攻击后，总统乔·拜登于 2021 年 5 月 12 日发布了一项关于改善国家网络安全的行政命令。该命令的关键要素之一是政府机构使用零信任原则来应对网络攻击。拜登政府遵循这一命令，于2022年1月26日向行政部门和机构负责人发布了一份来自管理和预算办公室（OMB）的备忘录。 OMB 的这份备忘录“提出了一项联邦零信任架构 (ZTA) 战略，要求各机构在 2024 财政年度结束前达到特定的网络安全标准和目标，以加强政府对日益复杂和持续的威胁活动的防御能力。”¹ 该行政命令和 OMB 备忘录均提及了美国国家标准与技术研究所 (NIST) 出版物 SP 800-207 （于 2020 年 8 月发布）中描述的零信任架构，并要求政府机构遵守该架构。

零信任架构和成熟度模型

政府机构和私营部门的思想领袖发表了一些论文，有助于解释零信任架构并就如何最好地采用它提供建议。我们在下面总结了这些论文中所包含的思想。我们注意到，这些论文中所包含的思想和建议的关键本质是检查每笔交易，以评估谁正在对谁采取什么行动，并根据与交易相关的风险计算实时做出允许或禁止交易的决定。

美国国家标准与技术研究院 (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) 零信任参考架构。⁵ 作者通过以下声明表达了采用零信任的必要性： “国防部内部和外部数据泄露所暴露的漏洞表明需要一个新的、更强大的网络安全模型，以促进基于风险的明智决策。”⁶

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

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

拥有“假设违规”的态度并遵循零信任原则可以帮助组织进行风险管理和治理实践。对交易参与者的“持续监控”和“明确验证”零信任原则使组织能够为所有参与者及其活动建立动态风险评分。这符合 Gartner 的建议，即使用“持续自适应风险和信任评估”（CARTA）方法来增强现有的安全计划。采用仅允许最小权限访问资源的原则可以降低违规行为发生后造成损失的风险。持续监控和明确验证产生的信息对于生成合规报告也很有用。

更详细地了解心态

本节旨在关注思维方式——信仰体系、“为什么”——它激发了企业为实现零信任安全而应采用的工具和设计的策略和决策。事实上，我们可以将当今零信任解决方案所采用的所有方法和组件技术的动力提炼为四个简单的关键原则。本节首先列举这些原则，然后讨论如何在应用开发生命周期的更广泛背景下应用它们 - 即如何在设计阶段以及在应用的部署/运行时预先考虑这些原则。

零信任运营原则

如果将零信任解决方案理解为从根本上建立系统交互中的信任——“谁对谁做什么？”——那么建立适合交互的信任级别可以分为四个部分。

明确验证

顾名思义，零信任思维就是“不要盲目信任，要始终验证”。因此，系统中的任何参与者（系统交互中的谁和谁）必须能够：

如果系统允许匿名身份进行交互（例如航空预订系统中的匿名浏览者），则证明其身份，包括“匿名”身份的特殊情况。对于所有其他身份，参与者必须能够在系统接受的命名空间中声明他们是谁。
接收并验证行为人证明身份的附属“证据”（对于任何非匿名证明身份）。 “证明”的性质（密码、证书、行为等）可能有所不同，证明的强度也可能有所不同，但系统必须能够确定对证明的一定程度的信心。简单的系统可能对证明的信心有一个二元的“是/否”观点，而更先进的系统可能有一个数字置信度分数，可以作为基于风险回报的政策的一部分明确引用。请注意，系统还可以通过其他方式增加或减少信心，例如响应主动挑战，甚至是被动观察演员的行为。
根据当前行为相对于过去行为的额外背景，评估和调整对证明身份的信心。例如，系统可以维护有关行为者的过去和当前的地理位置、硬件平台、IP 地址、声誉等，以用于增加或减少身份“证明”的信心。

此外，明确验证的原则不仅适用于身份，也适用于行动——交易的内容。一种常见的用例是将操作表示为 API 调用，例如执行数据库查询的 API。在这个例子中，显式验证原则不仅可以用来对调用 API 的参与者的身份有信心，还可以用于验证 API 操作使用的正确性，例如验证传递给 API 的参数是否符合适当的约束。

在成熟的零信任思维中，“证明”几乎从来都不是绝对的。身份凭证可能被盗，设备可能受到损害；API 参数约束通常不完整。因此，零信任环境中的“信心”一词应更多地解释为表明证明的身份或交易参数合法的可能性。因此，在决定允许、阻止或进一步检查交易时，“信心”水平应被视为一个关键因素，但不是唯一因素。

最小权限

一旦在参与交易的参与者中建立了可接受的“信任”水平，零信任方法就要求参与者（通常是请求者，“谁” ）仅被授予在该系统中完成其设计任务所需的最低限度的特权。这一原则体现了所谓的“积极安全模型”——一种默认情况下不允许所有操作，仅根据系统操作的需要授予特定权限的方法。例如，预订系统可能允许匿名用户浏览航班时刻表，但是根据应用设计要求，匿名用户可能不允许预订航班。

这些特权可能适用于个别演员，也可能适用于某一类演员。通常，应用消费者要么是人类参与者，要么是人类的代理，并分为几类，例如“匿名用户”、“客户”、“合作伙伴”或“员工”。信任度较低的参与者通常需要较低的置信度阈值才能通过身份验证，但他们也可以访问更少或不太敏感的 API。应用或其基础设施内部的参与者（例如应用内的特定服务或容器）通常可能具有更多自定义权限，例如“只有容器<X>和<Y>可以访问数据库，只有<X>可以写入对象存储，但<Y>和<Z>可以从中读取”。

实施最小特权的一个重要考虑是努力以更有针对性的方式、经过深思熟虑地应用它。⁷ 具体来说，成熟的零信任实施不应该对所有参与者或一类参与者应用一组通用的权限，而应该对正在尝试采取的行动有更细致的了解。例如，在非常粗粒度的情况下，“文件系统访问”可能会被授予特权，但“文件系统读取”是对所需真正特权的更严格规范，从而产生积极安全模型的高质量实现。

最后，最小特权的更复杂的体现可以与“明确验证”的成熟实现一起工作，通过将参与者的授权特权视为不是绝对的，而是基于身份验证提供的信心。因此，仅当对证明身份（ Who ）的信心达到最低阈值时，才会授予特权，而该阈值特定于正在尝试的操作。例如，某些特别有影响力的行动（例如关闭系统）可能需要 90% 或更高的置信度来确认参与者是管理员。在这个例子中，如果在尝试关闭时系统对身份的信心只有 80%，那么系统将需要额外的验证来提高已证明身份的信心分数，然后才允许执行该操作。

持续评估

明确验证和最小特权是关键概念；然而，持续评估的原则体现了这样一个事实，即这些原则必须持续评估，即：

所有交易均须经过验证和特权。换句话说，不应该只有一部分交易需要接受检查——例如“用户会话中的第一个交易”或“通过 Docker 容器工作负载发起的交易”。虽然这听起来不言而喻，但许多零信任实施并未验证所有交易，要么是因为设计不佳，要么是因为缺乏可见性。该领域的常见缺陷在于仅对外部参与者应用零信任，而不对内部参与者应用零信任，和/或假设零信任裁决在较长时间内仍然有效。
评估中的关键因素——对行为者身份的信任度以及赋予该行为者的权利——必须被视为动态的、可能发生变化的。例如，根据观察到的行为和边带元数据，身份的置信度可能会随着时间的推移而增加或减少，因此任何基于置信度的策略也必须动态调整以适应不断变化的置信度。此外，政策先前授予的特权阈值可能会稍后被撤销，或者某些操作所需的最低置信度可能会发生变化。虽然政策变化的时间表会有所不同——它可能会缓慢变化（按照人类操作流程的时间表）或快速变化（通过自动治理代理）——但系统应该能够动态响应并遵守这些变化。

假设违反

最后一条原则是，在健康的偏执背景下，假设对手有高度的积极性。具体来说，前提是“假设你已经被违反”，其中“违反”的定义是“本应被拒绝（在完全了解和执行的情况下）但却被允许的交易”。这种逃避的根本原因可能是知识不完善（例如，由于未检测到的欺诈性凭证而导致的身份验证的高置信度分数不正确），或者可能是实施限制（例如，授予的特权没有足够的细粒度特异性，例如具有“开放网络连接”作为特权，但没有根据网络目的地的地理位置进行区分的能力），或者可能是由于零信任实施不完整造成的（例如，没有对内部使用的易受攻击的开源组件应用零信任）。

因此，零信任思维还必须解决如何最好地管理/最小化此类违规行为的影响。

该原则的实施与其他原则相比差异较大，但总体表现为：

首先，识别任何虽然政策技术上允许但可疑的交易。 “可疑”通常与具体情况有关，但常见的解释是：（a）异常交易与过去观察到的行为非常不同，（b）一组单独来看正常但集体来看不寻常的交易 - 例如，读取和写入文件可能很常见，但以每秒 1000 个文件的速度读取和写入可能不寻常，或（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/文件 IO 限制、进程创建系统调用的跟踪、pod 的扩大/缩小限制、调用其他服务的 API 的速率限制？

明确地提出这些问题将帮助您发现实现零信任的基础中存在哪些差距。通常，在设计早期只需询问一下，就能以最少的额外设计努力解决差距。而且，如果差距可能仍然存在，那么简单地意识到差距将有助于引导额外的安全重点或识别脆弱的威胁面。

进行这种前期的安全开发分析是零信任思维的关键部分。然而，尽管如此，当今零信任的大部分焦点都集中在初始设计之后发生的事情上，大多数企业的重点都集中在零信任的后设计方面。然而，在设计阶段仔细考虑有效实施零信任的要求，将避免在应用部署后“修补漏洞”所需的更大增量努力。

缓解措施：及时性、误报/漏报和风险

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

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

这个例子的重点是强调，任何采取用户可见的补救措施的决定实际上是一个商业决策，需要考虑到可疑活动的所有风险、成本和回报。在交易中引入额外的摩擦会增加无法收到价值的可能性，但不干预/增加摩擦会带来妥协的风险。因此，在这种情况下是否采取行动的决定取决于三个输入因素：

允许可能的恶意交易继续进行有什么风险？
这种风险可能是直接的货币风险，例如银行资金的转移，也可能产生间接成本，包括运营成本（例如，关键记录被加密并被扣押以勒索）或品牌成本（例如，网站被毁坏）。还可能存在法律或合规成本，例如泄露个人客户数据。本质上，风险分配是一个治理问题，良好的治理将了解并量化应用的风险。

采取补救措施的副作用是什么？
副作用可以通过（a）引入的摩擦和（b）爆炸区两个维度来表达。摩擦是指合法交易进行起来的难度；它可能从稍微不方便（例如，额外级别的身份验证）到不可能（交易根本不被允许）。爆炸区指的是其他独立交易是否也会受到影响，如果会，影响到多少。例如，阻止特定用户只会影响该用户，但关闭日志服务将影响所有用户和交易的可审计性。