一、了解应用程序管道
二、Trusting Source Code
三、Trusting Builds
四、信任分配
五、人在循环中
六、信任一个实例
七、运行时安全性
八、安全软件开发生命周期（SDLC）
九、保护应用程序和数据的隐私
十、场景演练
Chapter 7. Trusting Applications
硅谷著名投资者马克·安德森曾宣称“软件正在吞噬世界”。在很多方面，这种说法从未如此真实过。正是运行在数据中心的软件使所有的奇迹发生，因此，我们希望相信它的执行并不是什么秘密。在受信任的设备上运行的代码将被忠实地执行。受信任的设备是信任代码的先决条件，我们将在第5章中介绍这一点。然而，即使我们的执行环境是安全的，我们仍然有更多的工作要做，以相信在设备上运行的代码是可信的。
因此，信任这个设备只是故事的一半。我们还必须信任代码和编写它的程序员。由于目标是确保正在运行的应用程序的完整性，我们必须找到将这种人类信任从代码本身一直扩展到执行的方法。信任代码是指确保在软件应用程序中使用的代码没有漏洞，由可信的来源产生，并且没有被篡改。为了建立对代码的信任，需要满足一些最低要求：
· 生成代码的人本身就是可信的，并遵循安全的编码实践。
· 对代码进行漏洞扫描、签名，并进行精确处理，以生成一个值得信赖的应用程序。
· 受信任的应用程序将被正确地部署到要运行的基础设施中。
· 不断监视受信任的应用程序，以获取对组件、依赖项的更新，以及使用恶意操作强制应用程序的任何尝试。
本章将讨论保护这些步骤的方法，重点讨论从人类到生产应用程序的信任继承。
一、了解应用程序管道
在计算机系统中，代码的创建、交付和执行是一个非常敏感的事件链。这些系统是对手的一个有吸引力的目标，因为它们提供了获得更多访问权限的能力。攻击的每一步都存在攻击向量，在这些阶段的颠覆很难被发现。
必须了解整个应用程序管道，包括开发、构建和分发过程。管道从开发开始，在那里创建和测试应用程序。下一步是构建过程，在那里应用程序被编译和打包以便分发。最后，将应用程序分发给最终用户或部署在生产环境中。因此，我们必须努力确保这个链的每个链接（如图7-1所示）都以一种可检测到颠覆的方式进行保护。
这一过程类似于供应链安全，以及世界各国政府加强安全的集体努力。确保军事装备的安全建造/采购对于确保作战部队的有效性至关重要，软件的创建和交付也不例外。
❗供应链安全
供应链安全是指为保护供应链的完整性和安全所采取的步骤。它包括确保产品在生产、运输、储存和分销过程中不被篡改或污染。它还包括验证产品是否符合所有的安全和质量标准。以下是一些供应链安全被损的例子。
2020年12月，一场对太阳风公司软件供应链的恶意攻击被曝光。作为全球组织的IT管理和网络监控解决方案的领先提供商之一，这对所有依赖其服务的人都构成了巨大的威胁。通过破坏太阳风公司的软件构建过程，攻击者能够将恶意代码插入到一个软件更新中，然后将其分发给数千名客户。这一事件产生了广泛的影响，几家政府机构和大公司报告称，他们的网络已因此次袭击而受到破坏。
2023年3月，拥有超过1200万用户的著名VoIP软件提供商3CX披露，恶意代码已经感染了其Windows和macOS的桌面应用程序。这次攻击是由朝鲜黑客组织UNC4736实施的，据报道，该组织与APT（高级持续威胁）组织拉撒路有关。这一事件也是第一次报道的双重供应链攻击，后来的攻击利用了早期的攻击；它涉及3CX和X_TRADER的软件链。更多的信息可以在这里找到。
这些事件重申了安全供应链的价值，并强调了组织需要优先将供应链安全作为其整体网络安全战略的一个关键组成部分。这些事件不仅让我们想起了与供应链攻击相关的危险，而且还敦促企业将更安全的措施纳入他们的网络安全计划中。通过今天采取的行动，我们可以防范未来的威胁。
应用程序构建管道通常从存储在Git等存储库中的源代码开始。然后，通过连续集成（CI）和连续交付（CD）流程，自动构建、测试和打包代码。接下来，由受信任的第三方进行代码签名，以验证代码的完整性，并确保它没有任何恶意代码。然后将签名的代码分发到执行它的适当服务器或设备。在整个过程中，会执行持续的监控，以识别和纠正任何安全事件。
❗防御软件供应链的攻击
根据网络安全和基础设施安全局（CISA）的说法，软件材料清单（SBOM）已经“成为软件安全和供应链管理的关键组成部分”。软件材料清单是对软件应用程序中使用的组件和依赖项的清单，它在确保应用程序的可信度方面起着至关重要的作用。此外，CISA和国家标准与技术研究所（NIST）共同发布了关于软件客户和供应商如何使用NIST网络安全供应链风险管理（C-SCRM）程序和安全软件开发框架（SSDF）来识别、评估和减轻软件供应链风险的建议。进一步的细节包括在这里。
在一个安全的软件交付链中，该过程中的每个步骤都应该是完全可审计的，在每个关键点都要进行加密验证。
一般来说，这些步骤可以分为四个不同的阶段（图7-1)：
· Source code
· Build/compilation
· Distribution
· Execution
让我们从信任源代码本身开始。
图7-1.构建管道既依赖于创建源代码和配置系统的工程师的安全性，也依赖于管道组件的安全性
二、Trusting Source Code
源代码是运行任何一段软件的第一步。简单地说，很难信任由不可信任的人编写的源代码。即使经过仔细的代码审计，恶意的开发人员仍然有可能有意地编码（并隐藏）一个显而易见的漏洞。虽然即使是善意的开发人员也会无意中给应用程序添加弱点，但零信任网络将专注于识别恶意使用，而不是消除这些用户的信任。将受信任的开发人员问题放在一边一分钟后，我们仍然面临着安全地存储和分发源代码本身的问题。通常，源代码存储在一个集中的代码存储库中，许多开发人员会对其进行交互并提交工作。这些存储库也必须受到严格的控制，特别是当它们被构建/编译相关代码的系统直接使用时。
2.1 保护存储库
在保护软件存储库时，维护传统的安全方法仍然是有效的，并且并不禁止添加更高级的安全特性。这些包括基本原则，比如最少访问原则，即用户只获得完成手头任务所需的对存储库的访问权限。在实践中，这通常表现为严重受限制/受限制的写访问。
虽然这种方法仍然有效并被推荐，但随着分布式源代码控制的引入，情况发生了一些变化。由于代码存储库位于多个地方，因此并不总是能够保护一个单一的、集中化的实体。然而，在这种情况下，这个集中式存储库仍然有一种类似的情况——存储构建系统读取其中的代码的系统.
在这种情况下，仍然非常希望通过传统方法保护这个系统；然而，问题变得更加困难，因为代码可以以任意多种方式进入分布式存储库。因此，逻辑扩展是，仅保护构建源存储库是不够的。
2.2 真实的代码和审计跟踪
许多版本控制系统（VCSs），特别是那些分布式的版本控制系统，都使用加密技术存储源代码历史记录。这种方法称为内容可寻址存储，它使用被存储的内容的加密哈希值作为数据库中该对象的标识符，而不是它的位置或坐标。可以看到源文件如何进行散列并存储在这样的数据库中，从而确保源文件中的任何更改都会产生新的散列。这个属性意味着文件被不可改变地存储了：一旦存储了，就不可能更改文件的内容。
一些vcs通过将历史记录本身存储为内容可寻址数据库中的一个对象，进一步推进了这种存储机制。Git是一个流行的分布式VCS项目，它将向存储库提交的历史记录存储为有向无环图（DAG）。提交是数据库中的对象，它们存储了诸如提交时间、作者和祖先提交的标识符等详细信息。
通过在每个提交本身上存储祖先提交的加密哈希，我们形成了一个Merkle树，它允许人们以加密方式验证提交链是未修改的（图7-2）。如果DAG中的提交被修改，它的更新将影响图中的所有子代提交，更改每个提交的内容，并通过扩展更改其标识符。
随着源历史被分发给许多贡献者，系统获得了另一个有益的属性：不可能在没有其他贡献者注意的情况下更改历史。
图7-2.Git的数据库使不必要的更改变得困难，因为对象是使用其内容的散列进行引用的
以这种方式存储DAG给我们提供防篡改历史：不可能颠覆性地改变历史。但是，此存储并不能确保历史记录中的新提交是经过授权的和真实的。想象一下，在一个受信任的开发人员被说服将恶意提交推送到官方存储库之前，将恶意提交拉到他们的本地存储库中。通过依赖于受信任的开发人员的推送访问，现在已将此提交添加到存储库中。更令人担忧的是，作者元数据只是纯文本：恶意的提交者可以在该字段中放置他们想要的任何细节（这一事实被有趣地用来让提交看起来是由Linus Torvalds在GitHub上编写的）。
为了防止这种攻击向量，Git能够使用可信开发人员的Gnu隐私保护（GnuPG）密钥签署提交和标记。在特定历史记录中指向头部提交的标签，可以使用GnuPG键进行签名，以确保发布的真实性。已签名的提交允许用户更进一步并验证整个Git历史记录，这使得攻击者不可能在不首先窃取另一个提交者的GnuPG密钥的情况下模拟另一个提交者的密钥。
已签名的源代码显然提供了显著的好处，并且应该尽可能地使用。它不仅为人类，而且也为机器提供了健壮的代码身份验证。如果CI/CD系统会自动构建和部署代码，那么这一点尤为重要。完全签名的历史记录允许构建系统在编译部署之前加密验证代码是可信的。
❗一开始，什么都没有
许多存储库从未签名提交开始，稍后将转换为已签名提交。在这个棕色案例中，第一个要签署的承诺本质上是认可在它之前的所有承诺。理解这一点很重要，因为您可能希望在此时执行审计。话虽如此，执行此类审计的开销或困难不应阻止或延迟向已签名代码的转换；如果您选择这样做，审计可以在适当的时候执行。
2.3 代码审查
正如我们在第6章中所了解到的那样，将强大的功能集中在单个用户上可能是很危险的。当考虑到源代码的贡献时，这也没有什么不同。签名贡献使我们能够对提交代码的开发人员进行身份验证，但不能确保所提交的代码是正确的或安全的。当然，我们确实对开发人员有了极大的信任，尽管这并不意味着开发人员应该单方面向敏感项目提交代码。为了减轻这种风险，大多数成熟的组织都实施了一个代码审查过程。在代码审查下，所有的贡献必须得到一个或多个其他开发人员的批准。这个简单的过程不仅大大提高了软件的质量，而且还降低了被引入漏洞的速度，无论它们是有意的还是偶然的。
三、Trusting Builds
构建服务器在软件开发生命周期中扮演着关键的角色，因为它们可以自动化了编译、测试和将代码打包成可部署的软件产品的过程。此外，构建服务器还负责将代码转换为可执行代码，并确保其满足质量和安全标准。由于这些服务器提高了访问权限，并产生了直接执行到生产过程中的代码，因此它们也经常成为持续威胁的目标。检测在构建阶段被破坏的工件可能非常困难，因此对这些服务应用强保护措施是很重要的。
3.1 软件材料清单（SBOM）：风险
在信任一个构建系统时，我们通常需要断言三件事：
· 它所构建的源代码是我们所打算构建的代码。
· 构建过程/配置是我们的意图。
· 构建本身是忠实地执行的，没有任何操作。
构建系统可以接收有符号的代码并产生有符号的输出，但是在两者之间应用的函数（即构建本身）通常不受加密保护——这是最重要的攻击向量所在。
这个特定的向量是一个功能强大的向量，如图7-3所示。如果没有正确的过程和验证，这种颠覆可能很难或不可能被发现。例如，想象一个受损的CI/CD系统，它接收有签名的C代码，并将其编译成一个有符号的二进制文件，然后分发并在生产中运行。生产系统可以验证二进制文件是否已签名，但将无法知道在构建过程中是否已经编译了额外的恶意代码。通过这种方式，一个看似安全的系统可以在生产中成功运行恶意代码而没有检测。也许更糟糕的是，消费者被骗到认为产出是安全的。这种链条的断裂构成了巨大的威胁，是一个强大的攻击载体。
图7-3.与源代码和生成的工件相比，构建配置及其执行不受加密保护
由于构建过程的敏感性，应仔细评估外包的责任。像可重复构建这样的东西可以帮助识别这一领域的妥协（更多细节），但并不能总是阻止它们的分发。这真的是你希望一个第三方供应商为你做的事情吗？你有多信任他们？他们的安全姿态应该与你自己成为高价值目标的机会相权衡。
❗主机的安全性仍然很重要
本节重点保护软件构建过程的各个步骤，但需要注意的是，构建服务器本身的安全性仍然很重要。我们可以保护构建的输入、输出和配置，但如果构建服务器受到损害，那么就不能再信任它忠实地执行其职责。可复制的构建、不可变的主机和零信任模型本身都可以在这方面提供帮助。
3.2 可信输入，可信输出
如果我们认为构建系统是一个可信的操作，那么很明显，我们需要信任该操作的输入，以产生受信任的输出。让我们从信任构建系统的输入开始。在前面，我们讨论了信任源代码控制系统的机制。构建系统作为版本控制系统的消费者，负责验证源代码的可信度。版本控制系统应该通过一个经过身份验证的通道进行访问，通常是TLS。此外，为了获得额外的安全保证，应该签名标记和/或提交，并且构建系统应该在开始构建之前验证这些签名或签名链。
构建配置是构建系统的另一个重要输入。攻击构建配置可能允许攻击者引导构建系统链接到恶意库上。即使是看似安全的优化标志在安全关键代码中也可能是恶意的，定时攻击缓解代码可能会意外地优化。将此配置置于源代码控制下，并可以通过签名提交进行版本控制和证明，这有助于确保构建配置也是一个受信任的输入。
如果输入足够安全，我们就可以将注意力转向构建过程的输出。构建系统需要对生成的工件进行签名，以便下游系统能够验证其真实性。构建系统通常还会生成构建工件的加密哈希，以防止损坏或恶意尝试替换二进制文件。
保护构建工件和散列，然后将它们分发给下游消费者，从而完成构建系统的受信任输出。
3.3 可重复生成
可重复性的构建是我们能够防止构建管道被颠覆的最佳工具。简而言之，支持可重复构建的软件是以一种确定性的方式编译的，以确保生成的二进制文件对于给定的源代码是完全相同的，无论是谁构建的。这是一个非常强大的属性，因为它允许多方检查源代码并生成相同的构建，从而获得了用于生成特定二进制文件的构建过程不会被篡改的信心。
这可以通过多种方式来实现，但它通常涉及一个编码的构建过程，并允许开发人员设置自己的构建环境来生成与分布式版本逐步匹配的二进制文件。使用可重复的构建，您可以“监视”CI/CD系统的输出，并将其输出与本地编译的结果进行比较。这样，就可以很容易地检测到构建过程中的恶意干扰或代码注入。当与有签名的源代码结合起来时，我们得到了一个相当健壮的过程，它能够同时验证源代码和它产生的二进制文件。
❗虚拟化的构建环境支持可复制的构建
在纸上有可重复的构建听起来很容易，但是复制一个已构建的二进制文件，所以它的逐字节相同是一个非常困难的问题。分发版历来在虚拟文件系统（chroot监狱）中构建包，以确保在构建配置中捕获构建的所有依赖关系。虚拟机或容器可以是确保构建环境与运行构建的主机完全隔离的有用工具。
3.4 解耦发行版和工件的版本
不可变构建对于确保构建和发布系统的安全性至关重要。如果没有它们，就有可能替换一个已知的好版本，从而为针对底层构建工件的攻击打开了大门。这将使攻击者能够将一个“坏的”版本伪装成一个“好的”版本。因此，由构建系统生成的工件应该有写一次读多语义。
考虑到不可变的工件需求，这些工件的版本控制会产生一种自然的张力。许多项目更喜欢在其版本中使用有意义的版本号（例如，语义版本控制），以通过升级其软件来向下游消费者传达潜在的影响。这种将意义附加到版本号上的愿望可能很难合并到一个构建系统中，以确保每个版本都是不可变的。
例如，在处理一个主要版本时，一个项目可能有一个配置错误的构建，从而导致构建系统产生不正确的输出。维护人员现在面临着一个选择。他们可以使用补丁级别的凸块重新发布版本，或者他们可能决定弯曲规则并使用新的构建工件重新发布相同的版本。许多项目选择了后一种选择，他们更喜欢享受一个更清晰的营销故事，而不是更正确的回归。这是一个坏习惯，当考虑到刚刚描述的伪装时。
从这个示例中可以清楚地看出，在任何一种情况下，都生成了两个独立的构建工件，并且与构建工件相关联的版本号是项目的单独选择。因此，在创建构建系统时，最好让构建系统生成独立于公开通信版本的不可变版本。以后的系统（分发系统）可以管理发布版本的映射，以构建构件版本。这种方法使我们能够维护不可变的构建构件，而不牺牲可用性或引入糟糕的安全实践。
四、信任分配
选择将哪些构建工件交付给下游消费者的过程称为分发。构建系统会产生许多工件，其中一些是用于下游消费。因此，我们需要确保分发系统保持最终交付的控制。
4.1 推广一个工件
基于我们之前关于不可变构建工件的讨论，推广是指在不更改该工件的内容的情况下指定构建工件为权威版本的行为。这个行为本身应该是不可变的：一旦一个版本被分配并发布了，它就不能被更改了。相反，需要以越来越高的版本号生成和发布一个新的工件。这种约束呈现了一个鸡和蛋的场景。软件通常包括一种向用户报告其版本号的方法，但是如果该版本号直到构建过程的后期才被分配，那么如何在不更改构建工件的情况下添加该版本信息呢？
一种简单的方法是在升级过程中微妙地更改工件，例如，将版本号存储在构建工件中一个简单修改的位置。然而，这种方法并不可取。相反，发布工程师应该在公开发布的版本号和构建号之间明确区分，构建号是发布信息的一个额外组成部分。使用这个模型，生成了许多使用相同的公共发布版本的构建工件，但是每个构建都额外标记了一个唯一的构建号（图7-4）。因此，发布该版本的行为是选择将被签名和分发的构建工件。一旦发布了这样的版本，所有的新版本都应该被配置为使用下一个目标版本号。
图7-4。这个铬公开发布版本是117.0.5938.92，使用版本控制格式MAJOR.MINOR.BUILD。“补丁”
当然，这种推广必须以一种方式传达给消费者，使他们能够验证他们拥有被推广的构建，而不是一些中介的和潜在的有缺陷的构建。有很多方法可以做到这一点，而且这在很大程度上是一个已经解决的问题。一种解决方案是用仅发布的密钥对升级的工件进行签名，从而向消费者传达他们有推广的构建。另一种方法是发布一个已签名的清单，列出已发布的版本及其加密散列。许多流行的软件包分发系统，如APT，都使用这种方法来验证从它们的分发系统中获得的构建。
4.2 分发安全
软件分配类似于配电，即电力由一个集中的电源产生，并通过一个配电网络传输，以便交付给广泛的消费者群体。然而，与电力不同的是，所生产的软件在传输配电系统时必须得到保护，允许消费者独立验证其完整性。有许多被广泛采用的包装分发和管理系统，实际上所有这些系统都围绕分发过程实施了保护措施，并允许消费者验证通过它们收到的包装的真实性。在本节中，我们将使用流行的包管理软件高级打包工具（APT）作为示例，说明如何在现实生活中某些概念被实现，尽管必须记住有许多可用的选项——APT只是其中一个。
4.3 完整性和真实性
在软件分发系统中，有两种主要机制用于维护完整性和真实性：哈希和签名。软件版本的散列涉及计算和分发表示发布的二进制文件的加密散列，消费者可以验证，以确保二进制文件在离开开发人员手后没有被更改。签署发布涉及作者用私钥加密版本的哈希，允许消费者验证软件是由授权方发布的。这两种方法都是有效的，而且并不一定是相互排斥的。为了更好地理解这些方法如何在分发系统中应用，查看APT存储库的结构和安全性是很有用的。
APT存储库包含三种类型的文件：发布文件、包文件和包本身。包文件作为存储库中所有包的索引。它在存储库中包含的每个包上存储一些元数据，如文件名、描述和校验和。此索引的校验和用于在安装之前验证下载的包的完整性。这提供了完整性，确保我们保证内容在飞行中没有改变。然而，它主要是对腐败有效，因为如果目标是交付修改后的软件，攻击者可以简单地修改索引散列。这就是发布文件所在的位置。
发布文件包含关于repo本身的元数据（与包文件相反，包文件存储关于其中包含的包的元数据）。这包括回购所针对的操作系统发行版的名称和版本。它还包括一个包文件的校验和，允许消费者验证索引的完整性，这反过来可以验证我们下载的包的完整性。这很好，除了攻击者可以简单地用包文件的更新哈希来修改发布文件，然后就上路了
因此，我们引入了加密签名（图7-5)。签名不仅提供了签名文件内容的完整性（因为签名中包含哈希），而且还提供了真实性，因为签名的成功解密证明生成方在私钥存在的情况下。使用这个原则，软件回购的维护者用私钥签名发布文件，私钥有一个众所周知的、分布良好的公钥。每当更新repo时，包文件哈希都将在索引中更新，索引的最终哈希将在发布文件中更新，然后对发布文件进行签名。这个散列链的根目录被签名，它为消费者提供了对他们即将安装的软件进行身份验证的能力。
如果您无法以某种方式签署软件版本，则必须回到标准的安全实践中去。您需要确保所有通信都是相互身份验证的——这意味着到任何分发存储库、从任何分发存储库之间的通信。此外，您还需要确保存储库所利用的存储是充分安全的，无论是亚马逊简单存储（亚马逊S3），还是其他存储。
图7-5.维护人员签署发布文件，该文件包含包索引的哈希值，其中包含包本身的哈希值
4.4 信任分销网络
当分发具有大型或地理上不同的消费者基础的软件时，通常会将软件复制到多个位置或存储库，以满足可扩展性、可用性或性能挑战。这些副本通常被称为镜子。在某些情况下，特别是在处理公共使用的软件时，托管镜像的服务器不受生产该软件的组织的控制。这显然是一个问题，并强调了软件回购必须对作者（而不是回购所有者）进行身份验证的要求。
回到APT的哈希和签名方案，可以看出，我们实际上可以使用它的签名对作者的发布文件进行身份验证。这意味着，对于我们访问的每一个镜像，我们都可以检查发布签名，以验证该镜像实际上是原始版本的忠实副本。
有人可能会认为，通过签署发布文件，软件可以通过不受信任的镜像安全地分发。此外，存储库通常托管在没有TLS的情况下，即发布的签名足以保护分发网络。不幸的是，这两个断言都是不正确的。
当连接到不可信的镜像时，会打开几种攻击类型，尽管您所获得的工件最终已签名。例如，可以强制降级到较旧的（已签名的）版本，因为所提供的工件仍然是合法的。其他攻击向量可以包括针对软件包管理客户机本身。为了保护您的客户，始终确保他们连接到一个受信任的分发镜像。
由于缺乏受tls保护的存储库，这也给软件的分发带来了另一个漏洞。能够修改不受保护的响应的攻击者可以执行与不受信任的镜像相同的攻击。因此，解决这个问题的最佳方案是将包分发转移到tls保护的机制。通过添加TLS，客户端可以验证它们实际上正在连接到一个受信任的存储库，并且不会对通信发生篡改。
❗提高软件供应链的完整性
太阳风、科德科夫等网络攻击暴露了供应链完整性缺陷的严重后果，造成了严重破坏。此外，他们还证明，不仅代码本身存在固有风险，而且在将该代码合并到软件系统或软件供应链的复杂过程中的多个位置也存在固有风险。这就是像软件工件的供应链级别（SLSA）这样的框架可以帮助自动化，将代码处理从源代码跟踪到二进制文件，确保无论软件供应链的复杂性如何，都不会被篡改。这也灌输了一种信心，即对源代码进行的分析和审查将在构建和分发过程之后继续适用于二进制文件。
五、人在循环中
通过设计了一个安全的管道，我们就可以考虑到人类参与该管道的位置。通过将人类的参与限制在几个关键点上，发布管道保持安全，同时也确保攻击者不能利用管道中的自动化来交付恶意软件。将代码提交到版本控制系统的能力是人类参与的地方。根据项目的敏感性，要求人员只签入已签署的提交，这提供了对提交是真实的强烈信心。
一旦任务完成，人类就不需要参与软件工件的构建。理想情况下，这些工件应该在一个安全的系统中自动生成。然而，人类应该参与到选择最终分发哪种文物的过程中来。这种参与可以使用各种机制来实现：例如，将一个工件从构建数据库复制到发布数据库中，或者在源代码控制中标记一个特定的提交。人类证明一个可释放的二进制文件的机制并不重要，只要该机制是安全的。
在构建安全系统时，采取极端措施来减轻任何可能想到的威胁都是很诱人的，但人类所面临的负担应该与潜在的风险相平衡。对于广泛分布的软件，私有签名密钥应该得到很好的保护，因为旋转一个被破坏的密钥的努力将是极端的。发布这样的软件的组织通常会使用“代码签名仪式”，即签名密钥存储在硬件安全模块（HSM）上，并使用来自多方的授权进行解锁，以缓解这一高度敏感密钥的盗窃。对于内部使用的软件，旋转密钥的努力可能相当少，所以更宽松的安全实践是合理的。一个组织可能仍然更喜欢一个特别敏感的内部应用程序的代码签名仪式——例如，一个存储信用卡详细信息的系统。
❗代码签名系统不安全的后果
正如本章前面提到的，在2020年，一家领先的IT管理和监控软件提供商，太阳风成为了一场高度复杂的网络攻击的受害者。攻击者破坏了该公司的软件开发环境，并将恶意代码插入其猎户座平台，分发给世界各地的众多政府机构、财富500强公司和其他组织。攻击者使用有效的代码签名证书对被泄露的软件更新进行签名，允许它绕过安全措施并渗入目标网络。此事件突出显示了保护代码签名密钥的重要性。风险较高的组织应该考虑实施强大的安全措施，比如代码签名仪式，以保护其数字资产免受潜在的攻击。
六、信任一个实例
在设计零信任网络时，了解基础设施中运行的内容很重要。毕竟，如果你不知道在你的主机上发生什么，你怎么知道在你的网络上发生什么？对数据中心中运行的软件（和版本）的深入了解将对漏洞检测和漏洞缓解方面大有帮助。
6.1 仅升级策略
软件版本是决定您所拥有的代码版本和年龄的重要结构。也许最重要的是，它们被大量使用是为了确定它们运行的版本可能暴露到什么漏洞。漏洞公告/发现通常与版本号相关联（联机服务漏洞为例外），并且通常包括已修复该漏洞的版本号。考虑到这一点，我们可以看到，为了暴露一个已知的漏洞，诱导一个版本降级可能是可取的。这是一个有效的攻击向量，因为被强制运行的软件经常是被授权和受信任的，因为它是一个完全有效的版本，尽管是一个较旧的版本。
如果该软件是为内部分发而构建的，也许分发系统只提供最新的副本。这样做可以防止损坏或配置错误的系统拉下可能包含已知漏洞的旧版本。也有可能在硬件中实施这种向前滚的心态。众所周知，苹果iOS系统使用硬件安全芯片来验证软件更新，并确保只有在当前安装的软件后构建的签名软件才能被加载。
6.2 授权实例
了解正在运行的内容的重要性比简单地了解最新部署的版本更为微妙。会出现许多边缘情况，比如从部署系统中脱落的主机——它以前已经被授权，但现在由于不再接收更新而成为“流氓”。为了防止这样的情况，单独授权运行的实例是非常重要的。
可以使用第4章中描述的技术来构建动态网络策略，以努力授权应用程序实例，但是网络策略通常是面向主机/设备的，而不是面向应用程序的。相反，我们可以利用一些更以应用程序为中心的东西来追求授权一个正在运行的实例：秘密。
大多数运行中的应用程序都需要某种秘密来完成它们的工作。这个秘密可以以多种方式显示出来：API密钥、X.509证书，甚至是消息队列的凭据都是常见的例子。应用程序必须获得该秘密才能运行，而且，该秘密必须是有效的。一个秘密的有效性（尽管它听起来很明显）是授权一个正在运行的应用程序的关键，就像验证就会失效一样。终生一个秘密对限制滥用是极其有效的。
通过为每个部署的实例创建一个新的秘密，并将该秘密附加一个生命周期，我们可以断言我们精确地知道在运行什么，因为我们精确地知道我们生成了多少秘密，我们把它们给了谁，以及它们的一生。允许秘密过期可以确保“流氓”实例不会无限期地运行，从而减轻它们的影响。
当然，必须有人负责在运行时生成和注入这些秘密，而这是一个不小的责任。承担这一责任的系统最终是授权实例运行的系统。因此，这种责任落在部署系统的手中是有意义的，因为它已经承担了类似的责任。
❗实例授权中的可信第三方
与其让您的部署系统直接访问秘密，还可以利用受信任的第三方，从而允许部署系统分配策略，指示正在运行的实例可以访问哪些秘密。例如，HashiCorp的仓库有一个被称为响应包装的特性，授权方可以请求生成和存储一个秘密，以便以后检索。在部署系统的上下文中，部署本身可以联系Vault并代表被授权的实例直接创建秘密，向运行时注入一次性令牌，应用程序可以使用该令牌来检索生成的秘密，如图7-6所示。
在这样的系统中，部署服务将即将发生的更改通知给秘密管理服务，并授权新的应用程序实例。在部署过程中，部署服务注入密钥(s)，新实例使用密钥标识自己到秘密管理系统，秘密管理系统期待它们的请求。然后，秘密管理系统提供唯一的时间限制凭据，将它们返回给应用程序，并进一步继续管理它们的生命周期。
图7-6.提供每个部署凭据的系统的示例流程
要实现一个能够创建和（可能地）检索秘密的系统的力量，并不需要花多少心思。巨大的权力就带来了巨大的责任。如果允许一个自主的系统生成和分发机密给您的组织带来了太大的风险，那么您可以考虑在这个步骤中包括一个人员。理想情况下，这将表现为一个经人类批准的部署，其中提供了TOTP或其他认证代码。此代码将用于授权部署系统创建/检索秘密。
七、运行时安全性
相信一个应用程序实例已被授权/批准只是整个问题的一半。还需要验证它能否在其整个生命周期中安全地、可靠地运行。我们知道如何安全地部署应用程序，并验证其部署已被授权，但它在整个生命周期中仍然是授权和可信的部署吗？
有许多向量可以破坏完全授权的应用程序实例，了解这些是最常用的向量可能也不足为奇。例如，腐败现有的政府代理人通常比伪装成一个代理人或试图成为一个代理人更容易。由于这个原因，有未偿债务的个人通常会被拒绝获得安全许可。他们在获得许可时可能完全得到信任，但如果他们负债，他们有多容易受到贿赂呢？在这种情况下，他们可以被信任吗？
7.1 安全编码实践
大多数（全部？）应用程序级漏洞始于一个潜在的漏洞，攻击者可以利用该漏洞迫使受信任的应用程序执行不希望的操作。单独修复每个漏洞将导致一场打地鼠游戏，开发者修复一个影响安全的漏洞，却发现另外两个。真正减少这种暴露需要应用程序开发人员改变思维方式来保护编码实践。注入攻击是指利用用户提供的数据来利用应用程序或相关系统中的漏洞，通常会在用户数据在处理前没有得到适当验证时发生。这种类型的攻击可以通过引入几层防御来减轻。应用程序库将仔细地构造api，以避免信任用户提供的数据。例如，数据库查询库将提供api，允许程序员将静态查询与用户提供的变量分开。通过在逻辑和数据之间建立一个明确的分离，就大大降低了注入攻击的可能性。
拥有清晰的api还可以支持应用程序软件的自动扫描。具有安全意识的组织正在越来越多地对其源代码运行自动化分析工具，以检测并警告应用程序开发人员不安全的编码做法。这些系统警告如何使用不安全的API，例如，通过突出显示使用字符串连接而不是前面讨论的API构建的数据库查询。除了对不安全的api警告之外，还可以跟踪应用程序逻辑来识别丢失的检查。例如，这些工具可能会确认每个系统事务都包含一些授权检查，从而减轻了允许攻击者引用不应该允许他们访问的数据的漏洞。这些示例仅代表了代码分析工具所拥有的少数功能。
主动识别已知漏洞是有用的，但有些漏洞太微妙，无法确定地检测。因此，正在使用的另一种缓解技术正在模糊。此实践将随机数据发送到正在运行的应用程序，以检测意外错误。这些错误暴露时，通常是攻击者用来在系统中获得立足点的弱点。模糊化可以在构建管道的早期作为功能测试套件的一部分来执行，甚至可以针对生产基础设施进行持续执行。有一整本关于安全编码实践的书，其中一些取决于正在创建的应用程序的类型。程序员应该熟悉适当的实践，以提高其应用程序的安全性。
许多组织选择让安全顾问检查他们的应用程序和开发实践，以识别问题。
7.2 Isolation
在零信任网络中，通过限制它们可以访问的资源集来隔离已部署的应用程序是很重要的。应用程序传统上是在共享环境中执行的，其中用户的应用程序在执行环境中运行，对这些应用程序如何交互的限制很少。
如果应用程序受到损害，这种共享环境会产生大量的风险，并提出类似于周边模型的挑战。应用程序隔离试图通过明确定义应用程序可用的资源来限制可能受到损害的应用程序的损害。隔离将限制操作系统提供的功能和资源：
· CPU time
· Memory access
· Network access
· Filesystem access
· System calls
当实现其最佳状态时，每个应用程序都被赋予完成其工作所需的最少的访问量。一个受损的约束良好的应用程序很快就会发现，在更大的系统中没有获得额外的杠杆作用。因此，通过隔离应用程序，大大减少了来自受损应用程序的潜在损害。
在多进程环境中（例如，运行多个服务的服务器），其他仍然安全的服务受到保护，不受尝试在该系统上横向移动的影响。应用程序隔离可以使用许多不同的技术来实现：
SELinux, AppArmor FreeBSD jails
Virtualization/containerization
Apple’s App Sandbox
Windows Isolated Applications
Docker
Kubernetes
Firejail
Google’s gVisor
隔离通常被视为可分为两种类型：虚拟化和共享的内核环境。虚拟化通常被认为是更安全的，因为应用程序包含在虚拟硬件环境中，而虚拟硬件环境由虚拟机（VM）执行环境之外的管理程序提供服务。在管理程序和虚拟机之间有一个明确的边界，就可以创建两者中最小的表面积。
共享内核环境，如在容器化或应用程序策略系统中使用的内核环境，提供了一些隔离保证，但程度不如完全虚拟化的系统。共享的内核执行环境使用更少的资源来运行同一组应用程序，因此在注重成本的组织中越来越受青睐。当虚拟化试图通过提供对底层硬件的更直接的访问来解决资源效率问题时，虚拟化环境的安全优势开始看起来更像是共享的内核环境。根据您的威胁模型，您可能会选择根本不共享硬件。
7.3 主动监控
与任何生产系统一样，仔细的监控和日志记录都是至关重要的，而且在安全方面尤其重要。传统的安全模型集中于外部攻击向量。零信任网络鼓励内部活动的严格程度。早期发现攻击可能是完全妥协和完全预防之间的区别。除了在整个基础设施中一般记录安全事件，例如失败或成功的登录，这被认为是被动监视之外，还存在一个整个类别的主动监视。
例如，我们之前讨论过的模糊扫描可能需要时间来发现新的漏洞——可能比您愿意在发布管道的早期花费的时间还要多。一种主动监控策略主张，扫描也要根据生产情况连续运行。
❗不要在生产过程中这样做！
偶尔，在生产过程中采取某些行动的愿望可能会遇到阻力，因为害怕影响整个系统的可用性或稳定性。安全扫描经常落入这个桶中。实际上，如果安全扫描会破坏您的系统的稳定，那么就存在一个更大的潜在问题，这甚至可能是一个漏洞本身。与其在生产过程中避免潜在危险的扫描，不如问问为什么它们可能有风险，并通过解决导致该问题的任何系统缺陷来确保它们可以安全运行。
当然，模糊化只是一个例子。自动扫描可以成为确保系统中行为一致的有用工具。例如，可以将预期收听服务的数据库与实际收听服务的自动扫描进行比较，从而可以解决偏差。然而，并不是所有的扫描都会产生如此清晰的操作。例如，扫描已安装的软件通常用于根据网络面临或期望看到的威胁驱动升级的优先级。
有效的系统扫描需要多种类型的扫描仪，每种扫描仪都要以略微不同的方式检查系统：
· Fuzzing (i.e., afl-fuzz)
· Injection scanning (i.e., sqlmap)
· Network port scanning (i.e., nmap)
· Common vulnerability scanning (i.e., nessus)
那么，当所有这些监控都真正发现了一些东西时，你该怎么办呢？答案通常取决于信号的强度。传统上，可疑的（但不是关键的）事件会被丢弃到报告中，并定期进行审查。这种做法是到目前为止最不有效的，因为它会导致报告疲劳，报告一次几周都被忽视。或者，重要的事件可以对人类进行积极的调查。这些事件有足够强烈的信号，足以唤醒某个人。在大多数情况下，这是最有力的防线。
❗应用程序监控应用程序
应用程序安全监控是指参与单个集群或服务的应用程序可以主动监控其对等点的健康状况，并与其他人就其完整性达成共识。这可能表现为TPM引用、行为分析以及介于两者之间的一切。通过允许应用程序相互监控，您可以获得一个很高的信噪比，同时将责任分配到整个基础设施中。这种方法最有效地防止了侧通道攻击，或通过多租户启用的攻击，因为这些向量不太可能在整个集群中共享。
然而，在高度自动化的环境中，第三个选项就会打开：主动响应。“有些事情出了问题”的强烈信号可能会触发基础设施中的自动化行动。这可能意味着撤消属于可疑实例的密钥，将其引导出集群成员身份，甚至向数据中心管理软件发出信号，要求实例应该离线和隔离以进行取证。
当然，与任何高级自动化一样，在使用主动响应时，可以很快造成很多损害。有可能使用这种机制引入拒绝服务攻击，或者更有可能的是，由于操作员错误而关闭服务。在设计主动响应系统时，设置一些故障保险装置是很重要的。例如，如果集群大小非常低，则不应触发从集群中喷出主机的主动响应。考虑构建这样的主动响应限制，可以确保主动响应过程本身的完整性。
八、安全软件开发生命周期（SDLC）
在零信任环境中，在整个软件开发生命周期中集成安全最佳实践和工具至关重要的。通过这样做，组织可以在漏洞到达生产环境之前识别和修复它们，降低安全漏洞的风险，并促进更安全的应用程序环境。接下来让我们讨论安全SDLC的关键方面。
8.1 要求和设计
在软件开发的初始阶段，应该定义安全需求，并评估潜在的风险。这涉及到考虑应用程序的体系结构、数据流和潜在的攻击向量。威胁建模等安全措施可以帮助在设计阶段识别和解决潜在的漏洞。通过设计原则整合隐私，还可以保护整个应用程序生命周期中的敏感数据。
8.2 编码和实施
开发人员应该遵循安全的编码实践，如输入验证、输出编码和适当的错误处理，以尽量减少在代码中引入漏洞的可能性。组织应该建立编码标准和指导方针，以确保整个开发团队的一致性。使用具有内置安全特性的安全编程语言和框架可以减少引入漏洞的风险。
8.3 静态和动态代码分析
实现静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）工具可以帮助在开发过程中识别漏洞和编码缺陷。SAST分析源代码的潜在安全问题，而DAST测试运行的应用程序可能只在执行期间明显的漏洞。将这些工具与持续集成和持续部署（CI/CD）管道集成起来，可以实现自动化和持续的安全评估。
8.4 同行评审和代码审核
定期的同行评审和代码审计可以帮助识别自动化工具可能遗漏的安全问题。这个过程鼓励开发团队之间的知识共享，培养一种安全意识的心态。除了内部审查之外，由独立安全专家进行的外部审计还可以提供对应用程序的安全姿态的公正评估。
8.5 质量保证和测试
安全测试应该是质量保证过程的一个组成部分，测试用例旨在评估应用程序对各种攻击场景的弹性。由内部或外部安全专家执行的渗透测试，可以提供进一步了解应用程序的安全态势。自动化的安全测试应与CI/CD管道集成，以确保持续的应用程序安全验证。
8.6 部署和维护
部署应用程序后，必须及时更新最新的安全补丁和更新。应实施监测和日志记录机制，以发现潜在的安全事件，以便及时响应和缓解。此外，应该有配置管理工具和流程，以确保应用程序和更新的一致性和安全部署。
8.7 持续改进
组织应从安全事件中吸取教训，并将经验教训纳入其SDLC流程中。定期审查和更新安全策略、程序和实践，以确保组织保持敏捷和响应新出现的威胁。对安全事件进行事后分析，并与开发团队分享研究结果，可以导致更好的安全意识和改进的实践。
通过整合这些实践，组织可以培养以安全为中心的文化，并促进对其应用程序的信任。
九、保护应用程序和数据的隐私
在前面的章节中，您了解了在零信任网络上下文中保护软件开发生命周期的各个阶段的重要性；本节将简要介绍机密计算的作用。它是一种保证代码/数据完整性和机密性的技术，同时允许应用程序被部署和操作，特别是在公共云中，以及在任何其他敌对的环境中（如客户端设备，如手机）。
9.1 当您在公共云中托管应用程序时，您如何能信任它呢？
将现有的应用程序提升并转移到公共云上不是很方便吗？当然，如果您正在阅读这篇文章，您很可能已经在以某种形式使用公共云，因为它提供了全面的DevSecOps、监视、可伸缩性和弹性。但是有一个警告——您能相信托管应用程序的云运营商不会篡改代码和数据吗？在零信任的情况下，云操作员不能被隐式地信任。为什么原因有各种各样，从监管（如政府发出的传票）到恶意（例如，不满的雇员，间谍活动），导致数据和代码进入未经授权的资源手中。
虽然数据通常在静止状态下（使用基于磁盘的加密，如FIPS）和在遵循安全最佳实践时（使用TLS）受到保护，但在执行计算时（例如，在内存中计算时），云操作人员仍然可以访问数据和代码。为了减轻这种风险，您需要由云运营商提供的加密证明，证明在使用时未经授权的一方（包括云运营商）不能访问代码和数据，以及证明在数据上操作的代码从未被篡改。在现代云平台上部署和运行应用程序时，这是建立信心的重要一步-- 永远不要信任，总是验证.
机密计算提供了这种保证。
9.2 机密计算
机密计算一词由机密计算联盟（CCC）定义为“通过在基于硬件的、经过验证的可信执行环境（TEE）中执行计算来保护正在使用的数据。”TEE是一个安全的计算环境，它由软件和硬件组件组成，并确保只执行已授权的应用程序。存储在TEE中的数据不受未经授权的访问或外部代码操作的影响。机密计算威胁模型的目标是减轻或最小化云提供商运营商和环境中的其他实体在执行过程中获得对代码和数据的未经授权访问的可能性。
❗是什么使机密计算不同于其他计算？
请注意，在计算过程中，还有其他几种隐私增强技术可以保护数据，如同态加密（HE）、安全多方计算（SMPC）和零知识证明（ZKP）等。机密计算的显著特点是它能够验证在数据上操作的代码没有以任何方式被篡改，并且完全符合预期的那样。第12章还涵盖了增强隐私的技术，并为感兴趣的读者提供了额外的参考资料。
9.3 了解基于硬件的信任根（RoT）
基于硬件的信任根（RoT）是一个不可改变的硬件组件，通常是硅芯片或芯片簇，被设计为能够防止广泛的攻击被篡改。使用RoT，加密密钥嵌入在硬件中，并与之不可分割；没有人可以访问它们，甚至连云提供商也无法访问它们。
RoT在TEE中用于实现硬件隔离、内存保护、加密、安全存储和认证功能。这本质上是可用于保护应用程序的最低保护级别（最接近硅级），包括代码和数据。
9.4 Role of Attestation
认证是建立对硬件和软件组件的信心的关键一步。首先，认证确保了TEE硬件的完整性和可靠性，验证TEE是基于预期的硬件（制造商、版本、固件等）。与该硬件相关的内存保护功能已被启用。其次，在TEE内运行的软件是真实的（版本、运行时属性等）。也没有被篡改过。
❗在公共云中的认证？
大多数大型硬件芯片制造商提供认证作为云运营商支持的内置功能，以便组织可以在云中运行应用程序时使用它来实现高水平的信心。有关进一步信息，请参考：Intel®软件保护扩展远程认证、AMD SEV-SNP认证、NVIDIA Hopper机密计算认证验证、AWS加密认证、微软Azure认证、谷歌认证策略和IBM安全执行认证。
需要记住的一件事是，尽管机密计算提供了强大的保护，但它可能仍然有威胁（就像任何其他技术一样），必须进行评估和通过威胁建模。我们鼓励读者检查由机密计算联盟概述的机密计算威胁模型，以了解有关此主题的更多细节。
十、场景演练
让我们来进行另一个场景演练。关键组件如图7-7和7-8所示，接下来将执行请求分析。
10.1 用例： Bob将高度敏感的数据发送到财务应用程序中进行计算
以下是我们对Bob的请求的了解：
· Bob正在向金融应用程序FinApp发送高度敏感的计算数据。
· Bob使用FinApp提供的公钥对敏感数据进行了加密。
· Bob正在使用他的工作笔记本电脑，设备标识为“ABC”，这完全符合组织策略。
· Bob使用了一个密码进行身份验证和SMS作为一种MFA方法。
· Bob是在办公时间提出这个要求的。
图7-7.活动日志、用户数据和监控日志
以下是我们对FinApp的了解：
· FinApp运行在一个可信的执行环境/安全的硬件飞地中。
· 所有到FinApp的通信都是通过一个加密的TLS通道。
· 持续监控定期运行认证检查，以确保FinApp运行的是预期的版本，并且没有被篡改。
图7-8.策略引擎和信任引擎
请求分析
1.Bob的访问请求(action: compute-score, app-id: FinApp, deviceid: ABC, authentication: FIDO2, location: Dallas, IP:6.7.8.9, datetime:
23-Dec-2023-4:00pm-est-timezone）到达执行组件。
2.强制执行组件将访问请求转发到策略引擎以进行批准。
3.策略引擎接收请求，并与信任引擎进行咨询，以确定请求的信任分数。
4.信任引擎将评估该请求：
· 基于用户活动日志没有检测到异常行为，监控日志也显示应用程序正确响应认证请求。
· 该设备符合合规，不到36小时前进行了最近的合规检查，所以在信任分数上增加4分。
· Bob还使用了FIDO2作为一种MFA方法，它可以抵抗网络钓鱼，所以在信任分数中再增加8分。
· 最后，信任引擎计算信任分数的平均值为6，并将其返回给策略引擎。
5.策略引擎从信任引擎接收到的信任分数为6。
6.对于授权，策略引擎会将请求与所有策略规则进行比较：
第一个规则导致授予（或允许）操作，因为请求是在允许的办公时间内提出的。
第二个规则不适用，因为访问请求是通过TLS发出的。
第三条规则不适用，因为从信任引擎接收到的信任分数是6，它高于3。
第四个规则确实适用于当前的请求，因为该请求的信任分数大于5。该请求已被设置为授予。
第五条规则不适用，因为FinApp请求不会失败任何认证检查，如监控日志所示。
第六条规则不适用，因为该请求使用了一种强大的、抗网络钓鱼的MFA机制。
第七条规则不适用，因为该请求不适用于帮助台支持服务中心门户。
第八条规则不适用，因为它是默认的，并且只适用于任何其他先前的规则不适用。在这种情况下，第四条规则被适用于允许该请求。
策略引擎会向强制执行组件发送一个允许允许的操作。
7.强制执行组件从策略引擎接收结果，并授予Bob对FinApp的访问权限。
Summary
本章深入研究了如何保护零信任网络中的应用程序。零信任网络需要关注应用程序安全，这似乎违反直觉。毕竟，网络是不受信任的，因此应该期望在网络上存在的不值得信任的应用程序。然而，虽然网络可以检测和识别恶意的应用程序活动，但如果已部署的应用程序在被授权运行之前没有经过适当的审查，那么这个目标就不可能实现了。因此，本章的大部分内容都关注如何在零信任网络中安全地开发、构建和部署应用程序，然后监视正在运行的实例，以确保它们保持值得信任。
本章介绍了可信应用程序管道的概念，它是一种将由受信任的开发人员编写的软件转换为内置应用程序，然后部署到基础设施中的机制。这个管道对潜在的攻击者来说是一个非常有价值的目标，因此它值得特别关注。我们深入研究了安全的源代码托管实践，将源代码转换为可信对象的可靠实践，以及安全地选择这些对象并分发给下游消费者。应用程序管道可以可视化为管道早期输入的一系列不可变转换，因此我们探索了如何在过程中不引入太多摩擦的情况下实现该管道的目标。
在一个安全的系统中，人类的注意力是一种稀缺但又重要的资源。随着软件发布速度的不断提高，仔细考虑在这个过程中何时最好地引入人类是很重要的。我们讨论了将人类放入循环的哪里，以确保管道保持安全。一旦构建了应用程序，确保它们在生产环境中持续执行的过程就会发生一些变化。由于发现了漏洞，旧的、受信任的应用程序将来可能会变得不可信，因此我们讨论了在运行应用程序时只使用升级策略的重要性。对于安全工程师来说，秘密管理通常是一项困难的任务，而更改凭证通常是一件非常繁重的工作。
然而，通过平稳的凭证发放过程，就会出现一个频繁旋转凭证的新机会，即使用凭证发放过程本身作为确保只有已授权的应用程序继续在生产环境中运行的机制。我们在这一章的最后讨论了良好的应用程序安全卫生。学习安全的编码实践，在孤立的环境中部署应用程序，然后积极地监视它们，这是一个值得信赖的生产环境的最后一个方面。最后，我们以一个关于安全软件开发的讨论结束了这一章。
通过了零信任网络的所有组成部分，下一章将重点讨论如何保护网络通信本身。