一、Bootstrapping Trust
二、正在使用控制平面进行身份验证的设备
三、存货[库存]管理
四、更新和测量设备的信任关系
五、软件配置管理
六、使用设备数据进行用户授权
七、Trust Signals
八、场景演练
Chapter 5. Trusting Devices
在零信任网络中信任设备是极其关键的；这也是一个极其困难的问题。设备是安全决定成败的战场。大多数妥协涉及恶意行为者访问受信任的设备；一旦获得访问权限，就不能信任设备来证明自己的安全性。本章将讨论需要对网络中部署的设备有充分信任的许多系统和进程。我们将专注于这些系统在真正信任一个设备的更大目标中所扮演的角色。每一种技术本身都很复杂。虽然我们不能对每个协议或系统进行详尽的细节，但我们将努力提供足够的细节来帮助您理解该技术，并在使用它时避免任何潜在的陷阱。
我们首先从学习设备如何获得信任开始。
一、Bootstrapping Trust
当一个新设备到达时，它通常被分配一个与制造商和分销商同等的信任级别。对大多数人来说，这是一种相当高的信任水平（无论是否合理）。然而，这种继承的信任纯粹存在于肉类空间中，并且有必要将这种信任“注入”到设备本身中。
有许多方法可以注入（并保持）这种对硬件的信任。当然，设备生态系统是庞大的，确切的方法会根据具体情况而有所不同，但有一些基本原则全面适用。这些原则减少了在实现细节上的大多数差异。
这些原则中的第一个早已为人所知：黄金形象。无论你如何接收你的设备，你都应该总是在它们上加载一个已知的好图像。软件很难审查；与其匆忙地做很多次（或者根本不做），做一次并认证发行图像是很有意义的。
将一个“干净”的图像加载到设备上可以获得它极大的信任。您可以合理地确保运行在那里的软件已被您验证，并确保安全。因此，记录最后一次设备被成像是确定它在网络上获得多少信任的好方法。
❗安全启动
当然，有一些方法可以破坏设备，使它们在再成像和其他低水平手术中保留植入物，因为这些情况下的植入物本身通常是相当低水平的。安全引导是帮助抵御这类攻击的一种方法。它涉及到将一个公钥加载到设备的固件中，该固件用于验证驱动程序和操作系统加载程序的签名，以确保两者之间没有任何内容。虽然有效，但支持仅限于某些设备和操作系统。稍后会有更多关于这个的信息。
能够认证在设备上运行的软件只是第一步。该设备仍然需要能够向其试图访问的资源识别自己。这通常是通过生成一个由私有证书颁发机构签名的唯一设备证书来完成的。当与网络资源进行通信时，该设备会显示其已签名的证书。该证书不仅证明了它是一个已知的设备，而且还提供了一种识别方法。使用证书中嵌入的详细信息，设备可以与设备清单中的数据进行匹配，可用于进一步的决策。
1.1 生成和确保身份
当提供可以识别设备的签名证书时，需要以安全的方式存储关联的私钥。这并不是一项容易的任务。窃取私钥将使攻击者能够伪装成一个受信任的设备。这是设备身份验证中最糟糕的情况。一种简单但不安全的方法是配置对密钥的访问权限，以便只有享有最高特权的用户（根用户或管理员）才能访问它。这是最不理想的存储方法，因为获得更高访问权限的攻击者可以渗透出未受保护的密钥。
另一种方法是加密私钥。这比依赖简单的权限要好，尽管它提出了可用性问题，因为必须提供密码（或其他秘密材料）才能解密和使用密钥。这对最终用户设备来说可能不会造成问题，因为可以提示用户输入密码，尽管这对于服务器部署通常是不可行的；每次重启软件时都需要人工交互。
迄今为止，存储设备密钥的最好方法是通过使用安全的加密处理器。这些设备，通常被称为硬件安全模块（HSMs）或受信任的平台模块（TPMs），提供了一个可以执行加密操作的安全区域。它们提供了一个有限的API，可以用于生成非对称加密密钥，其中私钥永远不会离开安全模块。由于即使是操作系统也不能直接访问由安全模块存储的私钥，所以很难窃取它们。
1.2 静态和动态系统中的身份安全
在相对静态的系统中，在提供新的主机时，通常会涉及到操作员。这使得注入故事变得容易——受信任的人可以直接代表主机切断新密钥。当然，随着基础设施的增长，这种开销将会有问题。
在自动化配置和签名过程中，有一个重要的决定要做：在签署新证书时是否应该涉及到人员？答案在很大程度上取决于你的敏感性。
已签名的设备证书具有相当大的功能，可以将私钥的任何内容标识为真实和可信的设备。就像我们采取措施保护他们在当地的盗窃行为一样，我们也必须保护他们这些轻浮的一代。如果您的安装特别敏感，那么您可能会选择在每次签署新证书时都使用一个人员。
❗法律和证书颁发机构
现代浏览器广泛支持来自许多国家，包括许多其他国家的知名认证机构颁发的证书和欧盟，但这种信任容易受到地缘政治紧张局势的影响。例如，在2022年的俄乌战争期间，俄罗斯开始提供自己的受信任的证书颁发机构，以取代需要由外国更新的证书。如果没有这一行动，俄罗斯的网站将无法更新他们的证书，因为制裁阻止了许多国家的签署当局接受来自俄罗斯的付款。这是一个鲜明的提醒，因为发行当局受到当地法律的约束，他们可能会造成自己的困难。
如果配置是自动化的，但仍然是人为驱动的，那么允许人为驱动该操作也授权相关的签名请求是很有意义的。每次都有一个人参与其中是防止未经授权的请求被批准的最佳方法。然而，人类并不完美。他们很容易感到疲劳和其他缺点。因此，建议他们只负责批准他们自己已经提出的请求。
通过使用基于时间的一次性密码（TOTP），可以在一个步骤中完成配置和签名授权。TOTP可以与配置请求一起提供，并传递给签名服务进行验证，如图5-1所示。这种简单而强大的机制允许人类控制新证书的签名，同时只施加最小的管理开销。由于TOTP只能使用一次，因此TOTP验证失败是一个重要的安全事件。
图5-1.提供TOTP的人员可以安全地授权证书的签名
不用说，如果您想完全自动化配置新主机，那么这些都不适用。通常被称为“自动缩放”，即可以自己增长和收缩的系统，通常可以在大型的、高度自动化的安装中找到。
允许系统自身扩大规模减少了所需的护理和喂养量，显著减少了行政开销和成本。签署证书是一种需要大量信任的操作，就像对其他零信任组件一样，这种信任必须来自某个地方。有三个常见的选择：
· A human
· The resource manager
· The image or device
对于相对静态的基础设施或终端用户设备来说，人是一个简单而安全的选择，但对于自动化基础设施来说，人显然是不可能启动的。在这种情况下，您必须选择资源管理器或映像...或两者都选择。
资源经理处于特权位置。它有增长和缩小基础设施的能力，并且很可能会影响其可用性。它提供了一个很好的模拟，以模拟人类在一个更静态的系统。它可以断言：“是的，我打开了这个新主机，这是我所知道的一切。”它可以使用此职位直接或间接授权一个新证书的签署。
为了使资源管理器的工作更容易，许多云供应商，如微软、谷歌和其他公司提供内置的身份支持，可以以一种定义良好的方式对特定服务进行身份验证。了解更多关于谷歌的服务帐户和微软的管理身份。
根据您的需要，最好不要将此能力完全授予资源管理器。在这种情况下，凭据可以被烘焙到图像中。这通常不建议作为一种主要机制，因为它对图像存储承担了太多的责任；保护和旋转图像可能会充满危险。以类似的方式，可以利用hsm或tpm来提供与硬件绑定的设备证书。这比将材料烘焙到图像中要好，尽管要求tpm支持的设备签署新证书仍然不理想，特别是在考虑到基于云的部署时。
减轻这些问题的一个好方法是同时需要资源管理器和一个受信任的映像/设备。嵌入到映像中的通用认证材料（或已注册的TPM密钥）可以用于保护与签名服务的通信，并可以作为多方面授权中的一个组件。以下是供授权考虑的组件示例：
· 已注册的TPM键或图像键
· 正确的IP地址
· 有效的TOTP（由资源管理器生成）
· 预期的证书属性（即，预期的公共名称）
通过验证所有这些点，证书签名服务可以相对地确定该请求是合法的。资源管理器不能单独请求证书，而且由于它不能访问它提供的主机，因此攻击者可以做的最多的事情是影响可用性。类似地，被盗的映像不能请求证书，因为它需要资源管理器验证它已经配置了主机并期望请求。
通过拆分这些责任并要求多个系统来维护有效性，我们可以安全地（尽可能安全地）将人类从循环中移除。
❗资源管理器和容器
有时，这一切都可以归结为术语术语。在以主机为中心的系统中，资源管理人员创建自动缩放系统，并决定何时何地需要容量。在容器化的环境中，由资源调度器做出并执行相同的决策。对于零信任应用程序，这些组件实际上是相同的，并且这些原则同样适用于以主机为中心和以容器为中心的环境。
二、正在使用控制平面进行身份验证的设备
现在我们已经知道了如何在一个新的设备或主机中存储身份了，我们就必须弄清楚如何通过网络来验证该身份。幸运的是，有许多开放的标准和技术可以用来实现这一目标。
在这里，我们将讨论其中两种技术，以及为什么它们对设备认证如此重要：首先，我们将讨论X.509，然后继续研究tpm。
这些技术享有广泛的部署和支持，尽管情况并非总是如此。当我们在第8章中讨论保护遗留设备的实际方法时，我们将在这里进一步探讨，在遗留硬件中，零信任支持的未来可能会发生什么。
2.1 X.509
X.509可能是我们在设备身份识别和认证方面最重要的标准。它定义了公钥证书、撤销列表和验证认证链的方法的格式。它提出的框架有助于在本书中讨论的几乎所有协议中用于安全设备认证的身份。
关于X.509最酷的事情之一是，它用来证明身份的公钥/私钥对也可以用来引导加密通信。这只是X.509对互联网安全如此有价值的众多原因之一。有关X.509证书格式和所支持的属性的更多信息，请参阅RFC 5280、RFC 4519和ITU-X.509文档。
要使证书具有任何意义，它必须值得信任。任何人都可以创建证书，所以只要有一个正确的名称并没有多大意义。受信任的一方必须通过数字签名来认可该证书的有效性。没有“真实”签名的证书被称为自签名证书，通常只用于开发/测试目的。
注册颁发机构（通常由证书颁发机构担任的职责）有责任在允许签署证书之前确保证书的细节是准确的。在签名证书时，将创建从签名证书到父证书的可验证链接。如果已签名的证书具有正确的属性，它可以签名进一步的证书，从而产生一个链。证书颁发机构位于此链的根目录上。
通过信任证书颁发机构（CA），您将信任由它签署的所有证书的有效性。这是相当方便的，因为它允许我们预先只预先分发少量的公钥——即CA公钥。从那里提供的所有证书都可以链接回已知的受信任CA，因此也是受信任的。我们在第二章中详细讨论了CA的概念和一般的PKI。
X.509证书的主要能力是证明身份。它利用了两个键，而不是一个：公钥和私钥。公钥被分发，私钥由证书的所有者持有。
所有者可以通过加密一小部分数据来证明它们是在私钥的存在下存在的，而这些数据只能通过公钥进行解密。
这被称为公钥密码学，或非对称密码学。
X.509证书本身包含了大量可配置的信息。它有一组标准字段，以及一个相对健康的扩展生态系统，这允许它携带可用于授权目的的元数据。以下是在X.509证书中找到的典型信息样本：
发卡机构字段指定颁发证书，主题字段指定此证书的对象。发卡机构和主题字段均包含诸如Country (C), State (S), Locality Name (L),
Organization (O), and Common Name (CN)等信息。上述样本证书可发给一个设备，并包括以下信息：
· Country，国家(C)：美国。这是设备指定的国家。
· State，州(S)：德克萨斯州，德克萨斯州的缩写。这是该设备的已分配的状态。
· Locality Name，当地名称(L)：达拉斯。这是设备指定的城市。
· Organization，组织(O)：Contoso公司。这是设备指定的组织。
· Common Name，公用名称（CN）：这是分配给该设备的设备名称或唯一标识符。
此外，主题替代字段还包含附加信息，如设备的IPv4和IPv6地址。由于证书是已签名和受信任的，因此我们可以使用此信息来进行授权决策。
以这种方式利用X.509字段意味着，只要服务器知道它应该期待什么，就可以在不调用外部服务的情况下授权设备访问。
❗组织单位的折旧
您可能已经在X.509证书中看到了组织单位（OU）字段的使用。然而，在2021年6月，CA/浏览器论坛通过了SC47投票，反对从所有公共信任的TLS/SSL证书中使用组织单位（OU）字段。进行此更改是因为OU代表了一个组织(O)中的一个小得多的单元，这使得CA很难一致地维护其身份。拟议中的改变已于2022年9月1日生效。
如前所述，X.509处理的是密钥对，而不是单个密钥对。虽然这些是RSA密钥对非常常见，但它们并不一定是。X.509支持许多类型的密钥对，我们最近已经开始看到其他密钥类型（如ECDSA）的普及。
X.509对于设备身份验证非常有用，但它并不能解决所有的问题。它仍然有一个私钥，而且这个私钥必须受到保护。如果私钥被泄露，该设备的身份和隐私也将很容易受到攻击。虽然其他零信任度量有助于防止这可能造成的损害（如用户/应用程序身份验证或授权风险分析），但这被认为是最坏的情况，应该不惜一切代价避免。
私钥在存储时可以进行加密，需要一个密码才能解密。这是一个很好的做法，因为它需要的不仅仅是磁盘访问，而且只针对面向用户的设备实用。在数据中心中，加密私钥并不能解决这个问题，因为您仍然需要存储密码，或者以某种方式将其传输到服务器，这样密码就会变得像私钥本身一样麻烦。
硬件安全模块（HSMs）在试图保护私钥方面有很大的距离。它们包含可以生成公钥/私钥对并将私钥存储在安全内存中的硬件。无法从HSM中读取私钥。只能让HSM代表您对它进行操作。这样，私钥就不能被窃取，因为它在硬件中受到保护。我们将在下一节中讨论更多关于tpm，一种HSM。
X.509在零信任网络中设备认证的应用是巨大的。它是证明我们所拥有的几乎所有协议的设备身份的基本基石，并在实现端到端加密方面发挥了重要作用。零信任网络中的每一台设备都应该具有X.509证书。然而，有一个重要的考虑因素要做。我们正在使用X.509来验证一个设备，但整个方案的核心——私钥——显然是基于软件的。如果私钥被盗，整个设备身份验证都是一个骗局！
这些证书通常被用作真正的设备身份验证的代理，因为这些密钥太长、太笨重，因此您永远不会写下或记住一个证书。它们是可以被下载和安装的东西，正因为如此，它们往往不喜欢跟踪用户——他们更典型地关注设备。虽然可以确定与私钥问题相关的风险是可以接受的，但它仍然是一个严重的问题，特别是对于零信任来说。幸运的是，我们可以看到一些前进的道路，通过利用tpm，我们可以不可避免地将私钥与硬件结合起来。
2.2 TPMs
可信平台模块（TPM）是一种嵌入在一个被称为加密处理器的计算设备中的特殊芯片。这些芯片致力于以可信和安全的方式执行加密操作。它们包括它们自己的固件，通常被认为是芯片上的计算机。这种设计支持一个小型和精简的硬件API，很容易审计和分析漏洞。通过提供加密操作工具，并排除检索私钥的接口，我们获得了所需的安全性，而无需向操作系统公开密钥。相反，它们与硬件绑定。
这是一个非常重要的特性，也是tpm在零信任网络中的设备身份验证中如此重要的原因。优秀的身份识别和身份验证软件框架（如X.509）为设备身份验证做了很多工作。但是，如果没有一种方法来将软件密钥绑定到它所试图识别的硬件设备上，我们就不能真正称之为设备标识。tpm解决了这个问题，并提供了必要的绑定。
tpm生成并存储所谓的存储根键或SRK。此密钥对表示TPM设备的信任根目录。使用其公钥加密的数据只能由原始TPM解密。精明的读者可能会质疑该函数在批量数据加密的应用中是否有用。我们知道非对称加密操作非常昂贵，因此不适合对相对较大的数据块进行加密。因此，为了利用TPM进行大容量数据加密，我们必须减少SRK负责保护的数据量。
一种简单的方法是生成一个随机加密密钥，使用已知的性能对称加密（即AES或高级加密标准）对批量数据进行加密，然后使用SRK对生成的AES密钥进行加密。此策略，如图5-2所示，确保加密密钥无法恢复，除非有最初保护它的TPM存在。
大多数可用于开放消费的TPM库通过使用助手方法为您执行这些步骤。建议在使用这些方法前，应检查其内部操作情况。
接下来，让我们考虑中间键。许多TPM库（如TrouSerS）在使用TPM加密数据时创建中间密钥。也就是说，他们要求TPM创建一个新的非对称密钥对，使用公钥加密AES密钥，最后使用SRK加密私钥。在解密数据时，您必须首先解密中间私钥，使用它解密AES密钥，然后解密原始数据。
这个实现看起来很奇怪，但也有一些相对合理的原因。一个原因是，额外的间接级别允许对安全数据的分布具有更大的灵活性。SRK和中间密钥都支持密码短语，因此使用中间密钥可以使用额外的、可能更广为人知的密码短语。
这对于您的特定部署可能有意义，也可能没有意义。为了实现“此密钥只能在此设备上解密”的目的，如果需要，可以绕过使用中间密钥（而且具有更高的性能）。tpm支持的安全存储最重要的应用是保护设备的X.509私钥。这个密钥用于权威地证明设备的身份，如果被偷，其身份也是如此。使用TPM加密私钥意味着，虽然密钥仍可能从磁盘中获取，但如果没有原始硬件，它将无法恢复。
❗钥匙盗窃仍然有可能发生
加密设备的私钥并用SRK包装密钥并不能解决所有的盗窃向量。它保护密钥不从磁盘直接读取，尽管具有高级特权的攻击者仍然可以从内存中读取密钥，或者简单地要求TPM为它们执行操作。以下的“平台配置寄存器”和“远程认证”部分提供了关于如何进一步验证硬件身份（超过X.509身份）的附加信息。
平台配置寄存器（PCRs）是TPM的一个重要特性。它们提供存储运行软件的散希的存储槽。它从BIOS的散列开始，然后是引导记录、它的配置，等等。然后，可以使用这个散列序列来证明系统处于已批准的配置或状态。下面是存储在TPM中的前几个寄存器的一个截断示例：
这在很多方面都很有用，包括确保只允许经过授权的软件配置来解密数据。当PCR值使用TPM加密某些数据时，可以通过传入一组已知的良好的PCR值来实现。这被称为“密封”数据。密封的数据只能由密封它的TPM解密，并且只能在PCR值匹配时解密。
由于PCR值不能被修改或回滚，我们可以使用TPM密封来确保我们的秘密数据不仅被锁定到设备上，而且还被锁定到特定的软件配置和版本上。这有助于防止攻击者使用设备访问来获得私钥，因为只有未经修改和批准的软件才能解锁它。
我们已经学会了许多可以使用嵌入式设备安全来保护私钥和其他敏感的设备相关数据的方法。不幸的事实是，只要一个私钥存储在一个物理TPM之外，它仍然很容易被盗窃。这个事实仍然存在，因为恢复私钥所需要的就是说服TPM解锁它一次。此操作公开实际的私钥—这是存储在TPM上时不可能的。
幸运的是，TPM为我们提供了一种唯一地识别它的方法。这是另一对键，称为背书键（EK），每个TPM都有一个唯一的键。EK的私有组件只存在于TPM本身上，因此操作系统仍然完全无法访问。
远程认证是一种方法，通过它，TPM生成一个被称为“引用”的东西，然后将其安全地传输到远程方。该报价包括一个当前PCR值的列表，使用EK签名。远程事务方可以使用此方法来断言主机标识（因为EK对TPM是唯一的）和软件状态/配置（因为无法修改PCR）。我们将在第8章中进一步讨论如何传递该引用。
❗为什么不只是TPM呢？
您可能会发现自己想知道：为什么不将TPM专门用于设备身份识别和身份验证，为什么还要包括X.509呢？目前，TPM访问非常繁琐且性能不佳。它可以提供一个X.509证书来确认其身份，但它与私钥的交互受到限制。例如，用于认证的密钥只能对源自TPM的数据进行签名。对于像TLS这样的协议，这是一个交易破坏者。
有一些人试图迫使TPM认证协议形成一种更灵活的形式（比如IETF草案，它定义了通过TPM进行设备认证的TLS扩展），尽管在撰写本文时没有一个得到广泛采用。
有一些远程认证的开源实现，包括流行的IKE守护进程trongSwan。这不仅为利用TPM数据来验证IPsec（互联网协议安全）连接打开了大门，而且还通过使用PCR数据来验证主机运行的是真实的和未经修改的软件。
2.3 设备身份验证的TPMs
很明显，tpm是成熟零信任网络中强设备认证的最佳选择。它们提供了软件身份和物理硬件之间的关键点。然而，这里也有一些限制。
许多数据中心的工作负载都是异构的和孤立的，比如虚拟机或容器，这两者都需要诉诸TPM虚拟化，以允许孤立的工作负载来实现类似的目标。虽然有可用的实现（例如Xen的vTPM），但信任仍然必须植根于硬件TPM，并且设计一个安全的基于TPM的系统，能够实时迁移是具有挑战性的。此外，尽管TPM有许多用途和优点，但其支持仍然很少。虽然在成熟的零信任网络的设备身份验证中可以使用TPM，但它不应该被认为是一种要求。采用TPM支持是一个小的成就，在零信任采用和迁移方面还有许多低调的结果。
2.4 HSM和TPM攻击向量
HSM和TPM攻击向量最近出现在新闻中，发现了新的攻击，可以用来绕过这些设备的安全特性。这些攻击通常基于hsm和tpm的实现方式；它们都使用共享密钥来加密和解密数据。此共享的密钥被称为“背书密钥”（EK）。EK用于加密和解密第二个密钥，称为“存储根密钥”（SRK）。SRK用于加密和解密存储在HSM或TPM上的数据。
问题是，EK通常是由HSM或TPM制造商生成的，并且不保密，这意味着如果攻击者可以获得EK，他们可以使用它来解密SRK，然后访问使用SRK加密的数据。已经开发了几种攻击，可以用于从HSM或TPM获取EK：
1.第一次袭击被称为“ROCA”袭击，是在2017年被发现的。ROCA攻击是一种数学攻击，如果攻击者能够访问使用HSM或TPM加密的少量数据，就可以用来计算EK。
2.第二次袭击被称为“侧通道”攻击，于2018年被发现。侧通道攻击是一种物理攻击，可以用来在加密或解密数据时，通过测量HSM或TPM的电特性来获得EK。
3.第三次攻击被称为“故障注入”攻击，于2019年被发现。故障注入攻击是一种物理攻击，可用于在加密或解密数据时将故障引入HSM或TPM。这些故障可以用来获得EK。
这些攻击引起了人们对hsm和tpm安全的担忧。为了应对这些担忧，一些公司一直在致力于解决方案，以保护hsm和tpm免受这些攻击载体的攻击。
已经提出的一个解决方案是“机密计算”。机密计算是一种安全技术，可用于保护在HSM或TPM上存储或处理的数据。这种方法在存储或处理数据时使用加密来保护数据，这意味着即使攻击者获得了EK，他们也将无法解密数据。
我们还注意到在“引导信任”中提出的另一个解决方案，称为“安全引导”。安全引导是一种安全技术，可用于确保只能让受信任的软件在HSM或TPM上运行。安全引导使用加密签名来验证HSM或TPM上的软件的身份，这样即使攻击者获得了EK，他们也无法在HSM或TPM上运行恶意软件。
随着对造血管理和tpm的攻击变得更加复杂，确保您的造血管理和tpm免受这些攻击载体是很重要的。除了机密计算和安全引导技术外，请确保您：
· 让您的hsm和tpm更新最新的安全补丁。
· 使用来自信誉良好的供应商的hsm和tpm。
· 使用经过独立审计的hsm和tpm。
· 使用物理上和逻辑上的安全措施来保护您的hsm和tpm。
· 让您的机密数据离线。
· 当你不再需要你的机密数据时，就销毁它。
2.5 基于硬件的零信任供应商吗？
在零信任网络中支持遗留设备的最常见方法是使用身份验证代理。身份验证代理终止零信任关系，并将连接转发到遗留主机。虽然可以在身份验证代理和遗留后端之间强制执行策略，但这种操作模式并不理想，并且与传统的周长网络共享少量的攻击向量。在处理遗留设备时，希望将零信任终止点尽可能接近该设备。
如果可能，最好是使用专用的硬件设备，而不是使用应用程序代理。该设备可以作为一个零信任的请求者，携带一个TPM芯片，并直接插入到一个遗留设备的以太网端口。在库存管理系统中将两者配对，可以实现遗留设备和零信任网络之间的无缝集成。有许多应用程序将显著受益于这样的设备。例如，我会想到SCADA（监控和数据采集）和暖通空调（供暖、通风和空调）系统。
三、存货[库存]管理
验证设备的身份和完整性可以提供强大的零信任安全性，但能够识别设备属于该组织只是挑战的一部分。为了计算政策和做出执行决策，我们还需要很多其他的信息。
库存管理涉及到对设备及其属性的编目。维护这些记录对于服务器和客户机设备都同样重要。有时，把这些设备看作是网络实体而不是物理设备更有用。虽然它们确实通常是物理设备，但它们也可能是网络上的逻辑实体。
例如，可以想象，根据您的需求，一个虚拟机或一个容器可以被认为是一个“设备”。毕竟，它们有很多与真正的服务器可能具有的相同的描述性属性。将来自单个主机的所有虚拟机流量集中到一个策略中，我们可以直接回到周边模型。相反，零信任模型主张跟踪工作负载，以驱动它们所需要的网络策略。在这种情况下，可以专门使用这个库存（或工作负载）数据库，以适应虚拟化/容器化环境所经历的高更改率。因此，虽然传统的库存管理系统和工作负载调度程序可能是不同的系统，但它们仍然可以一起工作；就本书而言，调度器服务可以充当各种库存管理系统，如图5-3所示。
图5-3：调度程序和配置管理数据库作为控制平面的库存存储
有多个库存管理系统并不少见。例如，许多公司都拥有资产管理和配置管理软件。这两种存储对我们都有用的设备元数据；它们只是存储不同的集合，以不同的方式收集。
❗配置管理作为一个库存数据库
许多配置管理（CM）系统，如Chef或Puppet，提供了一种模式，将它们运行的节点的数据持久化到一个集中的数据库中。服务器的名称、IP地址和“类型”是通常在cm支持的数据库中找到的信息类型的例子。如果您还没有库存数据库，那么以这种方式使用配置管理是开发库存数据库的第一步。
3.1 知道期待什么
零信任网络的强大力量之一是，它知道接下来会发生什么。受信任的实体可以将期望推入系统，默认情况下允许拒绝所有级别的访问——只允许预期的操作/请求。
库存数据库是实现这一功能的主要组件。可以从这些数据中生成大量关于期望的信息；比如用户或应用程序应该在它上运行，我们可能期望它在什么位置，甚至是操作系统，都是可以用来设置期望的信息。
在数据中心中，这些期望可能非常强烈。例如，在配置新服务器时，我们通常知道它将被分配到什么IP地址，以及它将用于什么目的。我们可以使用这些信息驱动网络acl（访问控制列表）和/或基于主机的防火墙，只有在必要时才为特定的IP地址漏洞。这样，我们就可以拒绝所有的流量，只允许我们所期望的非常具体的流量。可以期望的属性越多，就越好。
然而，对于面向客户机的系统来说，这并不是一个很容易实现的前景。客户总是以新的和意想不到的方式运作，知道什么和什么时候是非常困难的。数据中心中的服务器通常与一组定义良好的主机或服务有相对静态和长期的连接。相比之下，客户倾向于与各种服务建立许多短暂的连接——它们的时间、频率和模式可以有机地变化。
为了解决面向客户的系统的疯狂性，我们需要一种稍微不同的方法。实现这一点的一种方法是简单地允许对服务的全局访问，并使用相互身份验证的TLS保护服务，迫使客户端在与设备证书通信之前提供设备证书。设备证书可用于在库存数据库中查找设备，并确定是否为其进行授权。其优点是，许多系统已经支持相互身份验证的TLS，并且不严格要求专门的客户端软件。人们可以提供相当强大的安全性，而不会严重阻碍可访问性或可用性。
然而，这种方法的一个显著缺点是，该服务是全球可访问的。要求客户端证书是减轻这种危险的一个好方法。然而，我们已经从像“心脏出血”这样的漏洞中看到，TLS服务器的攻击表面相对较大。此外，资源的存在可以通过简单地扫描它们来发现，因为我们在使用资源进行身份验证之前对资源进行TCP（传输控制协议）对话。我们如何才能确保我们不吸引不受信任的客户呢？毕竟，必须要有一些不可信的沟通。在身份验证之前会发生什么？
3.2 安全介绍
来自新设备的第一个连接是不稳定的。毕竟，这些数据包必须在某个地方被允许，如果它们没有经过严格的身份验证，那么就会存在风险。因此，新设备接触的第一个系统需要一种机制，通过它可以验证这个初始接触。这种安排通常被称为安全介绍。它是一个新的实体被引入到现有的实体，以信任转移到它的过程。有许多方式可以实现这一点；操作员向TOTP代码传递给提供者以授权证书请求的方法是一种安全介绍形式。
做一个安全的介绍的最好的（也许也是唯一的）方法是通过设置一个期望。安全的介绍实际上总是涉及到一个值得信任的第三方。这是一个已经被引入的系统，并且它具有引入新系统的能力。这个受信任的第三方是然后协调/验证要引入的系统的细节并设置适当的期望的系统。
❗针对客户端系统的安全介绍
由于野生客户端的特性难以预测，面向客户端的系统的安全引入可能很困难。当公开公开面向客户端的端点被认为风险太大时，有必要转向更复杂的方案。目前被接受的方法是使用一种称为预身份验证的信令形式，它会在采取行动之前宣布客户机的意图。我们将在第8章中更多地讨论预身份验证。
是什么使一个好的、安全的介绍系统？有三个主要的标准需要考虑：
与引入程序相关联的凭据和特权应该是一次性的，以防止攻击者妥协和重用密钥。
与引入相关联的凭据和特权应该是短暂的，以防止有效但未使用的密钥的积累。
利用第三方进行引入，可以分离职责，防止引入糟糕的安全做法，并减轻操作上的麻烦。
虽然这些要求乍一看起来很严格，但它们可以通过相当简单的方法来满足。在厨师实现主机介绍的方式中可以找到一个很好的例子。最初，有一个单独的秘密（被认为是“验证证书”），它有资格允许任何拥有它的主机作为一个新节点。因此，介绍将涉及将这个秘密复制到目标机器（或将其烘焙到图像中），使用它来注册新节点，然后删除它。
这种方法既不是一次性使用的，也不是短暂使用的。如果秘密被恢复，它可以被恶意行为者用来将应用程序流量引导到攻击者控制的主机，甚至触发拒绝服务。
Chef在以后的版本中采用了一种不同的方法。配置系统（通过Chef客户端实用程序“sknive”）与Chef服务器通信，并创建一个新的客户端和相关的客户端证书。然后它创建新主机并传递它的客户端证书。这样，就已经设置了对新客户端的期望。虽然这些证书不是短暂的，但它仍然是一种优越的方法。
四、更新和测量设备的信任关系
重要的是要接受这样一个事实，即没有任何安全级别是完美的——甚至连你的也不是。一旦这一事实得到承认，我们就可以开始减轻其后果了。自然的进展是，一个设备运行的时间越长，它受到损害的可能性就越大。这就是为什么设备年龄是一个严重加权的信任信号。
因此，旋转是非常重要的。我们之前详细地谈到了旋转的重要性，设备也不例外。当然，这种“旋转”以不同的方式表现出来，这取决于你对“设备”的定义。如果您的基础设施是在云中运行的，那么一个“设备”可能就是一个主机实例。在这种情况下，旋转很简单：只需删除实例并构建一个新的实例（您使用的是配置管理，对吧？）。然而，如果您运行的是物理硬件，那么这种前景就会有点困难。
重成像是逻辑旋转设备的好方法。这是一个相当低级的行动，并将成功地消除今天在野外看到的大多数持续存在的威胁。人们可以相信一个已经运行了一年的设备。虽然重成像不能解决硬件攻击或其他如图5-4所示的低级攻击，但在物理旋转更困难的地方，这是一个合理的妥协。数据中心和供应链安全部分减轻了这种担忧。
图5-4。一个磁盘映像显示了包含绝大多数恶意软件的部分，但它肯定不是全部
当涉及到管理客户端设备时，情况会变化很大。重新成像客户端设备对用户来说是非常不方便的。随着时间的推移，他们以难以有效或安全保存的方式定制设备（及其内容）。通常，当他们得到一个新设备时，他们想要传输旧的图像！这对那些试图保护客户端设备安全的人来说并不是什么好消息。
解决方案在很大程度上取决于您的用例。在这一领域，安全和便利之间的权衡将会非常明显。每个人都同意客户端设备应该经常旋转和/或重新成像，但频率取决于你。有一个重要的关系需要记住：一个设备被旋转或重成像的频率越少，您的端点安全性就必须越严格。如果没有旋转得到的设备安全保证，我们必须寻找其他方法来恢复对长期运行的设备的信任。有两种通用的方法可以用来实现这一点：局部测量或远程测量。
4.1 Local Measurement
本地测量可以有两种类型之一：硬件支持或软件支持。硬件支持的测量更安全和可靠，但能力有限。软件支持的测量远远不够安全和可靠，但其测量能力实际上是无限的。
对于硬件支持的本地度量的一个很好的选择是利用TPM来进行远程认证。远程认证使用一个硬件设备来提供一个签名响应，概述当前在该机器上运行的软件的哈希值。这种反应是非常可靠的，而且很难复制。然而，它通常只给出一个低级软件或特定目标软件的图片。如果攻击者已经成功地在用户空间中运行了一个未经授权的进程，那么TPM在其检测方面将不会很有用；因此，它的能力有限。有关详细信息，请参见“远程认证”。
软件支持的本地度量涉及到在端点上安装的某种用于报告运行状况和状态度量的代理。这可以是从托管的防病毒客户端到策略执行代理的任何东西。这些代理人为了证明和证明他们所报告的测量结果的有效性，付出了很大的努力，但即使是粗略的思考也能很快得出结论，即这些努力通常是徒劳的。软件支持的度量缺乏硬件度量提供的保护，具有足够特权的攻击者可以破坏这样的系统。
4.2 Remote Measurement
远程测量是两种选择中最好的一种，原因很简单：它受益于职责分离。一个被破坏的主机可以报告任何它想要的东西，可能是伪造信息以隐藏攻击者。这对于远程或被动测量是不可能的，因为一个完全不同的系统正在决定所涉主机的运行状况。
传统上，远程测量是作为一个简单的漏洞扫描来执行的。该系统将由一个扫描设备定期进行探测，该扫描设备可以观察响应。响应会提供一些信息，比如该设备上可能运行什么操作系统，哪些服务可能是活跃的，甚至可能是这些服务的什么版本。
扫描结果可以与已知的不良签名进行交叉引用，比如恶意软件或合法软件的脆弱版本。检测已知的不良签名可能会适当地影响设备的信任。在漏洞扫描领域中，有许多开源和商业选项可供选择，包括OpenVAS、Nessus和元漏洞利用。这些项目都是相当成熟的，并且被许多组织所依赖。
不幸的是，漏洞扫描具有与局部度量相同的基本问题：它依赖于对端点的询问。这是问别人他们是否抢劫了银行和看着他们抢劫银行之间的区别。当然，有时你可以让抢劫犯承认是他们干的，但专业人士永远不会上当。当场抓住他们要有效得多。有关如何解决这一困境的更多信息，请参见“网络通信模式”。
4.3 统一端点管理（UEM）
端点管理是基于软件的远程管理的一个例子。UEM系统允许管理员从集中式控制台管理组织中所有设备的安全姿态，并在实现和维护设备信任方面发挥关键作用。微软Intune、VMware空中手表、移动iron、clear通行证和免费IPA都是端点管理系统的例子。虽然UEM系统的设计没有以安全性为重点，但它们已经成为安全生态系统的重要组成部分，因为它们经常被用于在设备上执行安全策略。例如，它们可以确保设备在被允许连接之前具有最低限度的安全级别。这些系统还可以监控设备是否符合安全策略，集中推送更新，并被配置为在系统不再管理设备时提醒安全团队。
持续监控是信任设备的关键组成部分。安全团队必须不断注意可能表明妥协的设备行为的变化。例如，网络流量模式的变化可能表明设备已经感染了恶意软件，现在正在与恶意服务器通信，而文件访问模式的变化可能表明未经授权的用户正在试图访问敏感数据。
安全团队必须了解所有设备更改，以正确评估这些更改带来的风险。然而，仅仅监控设备是不够的；安全团队还需要能够在检测到妥协时采取行动。UEM系统提供了远程锁定或清除该设备的能力，如果该设备被确定为被破坏，以确保即使该设备丢失或被盗，其数据也将保持机密。
还必须建立一个程序来恢复人们对已经妥协的设备的信任。通常情况下，组织会清除一个被破坏的设备，然后从一个新的设备重新开始。虽然这可能是最安全的选择，但它通常并不实用或不划算。
相反，最好在设备重新生产之前有一个彻底清洗和验证的过程。设备信任是零信任安全的一个重要组成部分。
通过了解用于实现设备信任的各种技术和流程，您将能够更好地保护您的组织免受攻击。
❗设备符合性变化信号
OpenID基金会目前正在开发一个名为共享信号和事件（SSE）框架的新标准，该标准旨在标准化合作各方之间关于设备、用户和机器身份变化以及应用程序和会话状态变化的状态信号交换。特别是OpenID连续访问评估概要文件，提供了特定的语义，以JSON的形式发出信号的设备遵从性变化，如本示例所示：
五、软件配置管理
配置管理是严格控制和记录所有软件更改的过程。所需的配置通常被定义为代码或数据，并检入修订控制系统，允许对更改进行审计、回滚等等。有许多商业和开源的选项可供选择，其中最受欢迎的是Chef, Puppet, Ansible, andCFEngine。
配置管理软件在数据中心和客户端部署中都很有用，而且只需要超出一定的规模。利用这类软件会带来许多安全胜利，比如能够在漏洞发布后快速升级包，或者同样地断言在野外没有脆弱的包。
除了审计和严格的变更控制之外，配置管理还可以用作动态策略配置的代理。如果一个节点能够获得可靠和可信的世界视图（或至少是其一部分），那么它可以使用它来计算策略并在本地安装它。这个功能实际上仅限于数据中心，因为动态的数据中心托管系统显然比客户机系统更静态和可预测。稍后我们将详细讨论这种零信任操作的模式。
端点管理和软件配置管理之间的主要区别是，端点管理侧重于单个设备的安全性，而软件配置管理侧重于在这些设备上运行的软件的安全性。
5.1 CM-Based Inventory:基于CM的库存
我们已经多次提到了使用配置管理数据库用于库存管理目的的想法。这是迈向成熟的库存管理系统的一个伟大的第一步，它可以提供有关在基础设施中运行的各种主机和软件的丰富信息来源。我们喜欢认为，基于cm的库存管理是一种“免费赠品”，因为配置管理通常被用于它带来的大量其他好处。
将它作为库存数据库通常是出于方便。维护这个视图很重要：配置管理系统不是被设计成库存管理系统……它们被设计为配置管理系统！这样使用它肯定会带来一些粗糙的边缘，而且你最终会超越它。这并不是说不要这么做。通过尽可能多地利用现有技术来实现零信任网络，比因为进入障碍而永远不实现要好。一旦我们接受了这个事实，我们就可以开始利用CM代理提供给我们的丰富数据。
5.2 可搜索的库存
一些CM系统集中存储由其代理生成的数据。通常，这个数据存储是可搜索的，这为年轻的零信任网络打开了许多可能性。例如，代理可以执行搜索，以检索数据中心a中所有web服务器的IP地址，并使用这些结果来配置基于主机的防火墙。审计和报告的生成也通过可搜索的库存而大大增强。这不仅适用于数据中心主机，也适用于客户端。通过存储代理数据并使其可搜索，您可以确保您更改了CM代码以升级该易受攻击的包，并且该包确实在它所说的地方进行了更新。
5.3 真理的安全来源
当在零信任控制平面上使用CM系统时，需要记住的一件重要的事情是，CM系统可用的绝大多数数据都是自我报告的。理解这一点是至关重要的，因为一个受损的机器可能会歪曲自己。如果在设计过程中不考虑这些事实，这可能会导致零信任网络的完全妥协。
回顾信任管理，在这种情况下，受信任的系统是提供者。
无论是人类系统还是某种自动化系统，它都最能维护一个设备的关键方面，其中包括以下方面：
· Device type
· Role
· IP address (in datacenter systems)
· Public key
这些属性被认为是关键的，因为它们经常被用于进行授权或身份验证决策。例如，如果攻击者可以更新设备角色，那么他们可能可以迫使网络公开受保护的服务。因此，限制对这些属性的写访问是很重要的。当然，您仍然可以使用自我报告的属性来做决定，但它们在任何情况下都不应被视为事实。把自我报告的属性看作是暗示而不是事实是很有用的。
六、使用设备数据进行用户授权
零信任模型要求对设备和用户或应用程序进行身份验证和授权。由于设备身份验证通常出现在用户身份验证之前，因此必须在没有通过用户身份验证获得的信息的情况下完成。但对于用户身份验证的情况并非如此。
当发生用户身份验证时，设备身份验证已经成功，并且网络知道设备身份。这个位置可以用于各种有用的上下文知识，使我们能够进行比以前可以实现的更强的用户身份验证。
最常见的检查方法之一是，考虑到设备的类型或问题的地点，检查我们是否会期望使用这个用户。例如，您不太可能看到工程师的证书来自发给人力资源部的移动设备。因此，虽然人力资源员工可以使用自己的凭据自由访问特定资源，但使用其他凭据的用户身份验证尝试可能会被阻止。
另一个很好的信号是用户认证频率。如果你在一年多的时间里没有看到用户从他们的设备登录，突然间该设备请求提供用户的凭证——嗯，我认为有点怀疑是公平的。它会是被偷了吗？当然，这个请求也很有可能是合法的。在这样的情况下，我们降低了信任分数，以表明事情有点可疑。较低的分数可以在很多方面表现出来，比如仍然足够的信任来阅读内部wiki的部分，但不足以登录金融系统。能够做出这样的决策是零信任体系结构的一个重要组成部分，并强调了一个健壮的库存管理数据库的重要性。由于设备身份验证的原因，严格要求库存管理，但用户身份验证的上下文优势是无价的。
七、Trust Signals
本节可作为在计算设备信任分数和编写策略时有用的各种信任信号的参考。
7.1 Time Since Image
随着时间的推移，一个设备受到破坏的可能性会急剧增加。端点安全实践旨在降低与长期寿命或长期运行设备相关的风险。然而，这些做法还远非完美。
成像一个设备可以确保硬盘驱动器的内容与已知的产品相匹配。虽然对一些较低级别的攻击无效，但它提供了相当强大的信任保证。
在映像恢复后的立即时刻，设备中存在着大量的信任，因为只有硬件或恢复系统本身能够污染整个过程。
不过，随着时间的推移，随着系统的长期暴露，这种信任会逐渐消失。
7.2 历史访问
设备身份验证模式，类似于用户身份验证模式，对于理解风险非常重要，并且可以作为行为过滤的良好代理。那些有一段时间没有见过的设备比那些经常来来去去的设备更可疑。也许怀疑是一个错误的词，但看到它肯定是不寻常的。
所讨论的请求也可以与资源绑定，在此上下文中一起考虑设备和资源是明智的。例如，一个数月前的请求访问新资源的设备比它在一段时间以来每周访问的资源的请求更可疑。这就是说，对某一特定资源的“最初几次”访问尝试将比随后的尝试产生更多的怀疑。
类似地，我们可以通过分析频率来理解一个资源是否被可疑地过度利用。一个设备在最后一天发出了100个请求，但过去一个月只有104个请求，肯定比最后一天有0个请求，上个月有4个请求更可疑。
7.3 Location
虽然网络位置，包括地理位置、IP地址等属性，通常是我们的目标，而不是对零信任模型做出强有力的决策，但在许多情况下，它们仍然提供可靠的信任信令。其中一种情况可能是突然的位置变化。由于我们谈论的是设备认证，所以我们可以对设备的移动方式设置一些合理的期望。例如，如果我们在几个小时前在美国办公室授权了同样的设备，那么来自欧洲的设备身份验证尝试可能会非常可疑。
应该注意的是，当涉及到零信任模型时，这有点滑坡。零信任旨在消除网络中的优势位置，因此使用网络位置来确定访问权限可以被认为有点矛盾。作者认识到这一点，并承认与位置相关的数据在做出授权决策时是有价值的。
也就是说，重要的是，这种考虑不是二元的。人们应该在位置上寻找模式，而永远不要仅仅根据位置来做出绝对的决定。例如，规定只能从办公室访问应用程序的策略直接违反了零信任模型。
7.4 网络通信模式
对于连接到运营商拥有的网络的设备，有机会度量通信模式，以开发一种规范。这一规范的突然变化是可疑的，并可能影响系统对这种设备的信任程度。网络仪器仪表和流量采集可以通过在网络上观察入侵来快速检测入侵。通过此检测来做出授权决策是非常强大的。一个例子可能是关闭对特定web服务器的数据库访问，因为该web服务器开始对另一个大陆上的托管提供商进行DNS查询。
这也同样适用于客户端设备。考虑一个以前从未启动SSH连接，但现在经常SSH到互联网主机。公平地说，这种行为上的变化是可疑的，应该会导致设备比以前更不受信任。
7.5 Machine Learning
机器学习通过考虑访问请求的整个上下文，包括用户、设备和资源，以及识别异常请求的历史活动，来帮助计算信任分数。机器学习模型通常会随着时间的推移进行训练，以区分异常的和合法的访问模式。因此，机器学习可以帮助减少在识别恶意请求时的任何潜在盲点。然而，与零信任的其他方面一样，不建议仅仅依赖机器学习；相反，将它与其他信任信号结合使用会产生最好的结果。
八、场景演练
我们将通过扩展前一章的场景演练，并了解设备信任在评估Bob的授权请求中的作用，以此来结束这一章。
让我们从仔细看看设备数据存储区开始，如图5-5所示。设备数据包含特定于您所期望的设备的详细信息，如设备模型、操作系统详细信息、固件相关信息，以及最重要的是，设备是否符合组织的策略以及报告最后一次遵从性检查的时间。此外，请注意使用普遍唯一标识符（UUIDs）来唯一识别机器，并使用国际移动设备标识符（IMEI）来唯一识别移动设备。
图5-5.数据存储中记录设备的数据，包括设备的软件、硬件和投诉状态
属性“不遵从性”可能需要做出一些解释，因为它在驱动设备信任方面至关重要。它用于指示设备是否符合组织的合规标准，这主要是由当前的设备加密的驱动下，安装最新的安全补丁，固件版本，和设备上必要的任何其他软件代理的执行，包括但不限于反恶意软件等。
组织通常存储设备遵从性状态和最后一次作为设备数据的一部分进入数据存储。此外，如果遵从性检查失败，或者设备在一段时间后，如48小时后无法用于遵从性检查，那么设备往往会不符合遵从性，但这个持续时间通常由组织的遵从性策略决定。接下来，我们将检查活动日志，如图5-6所示，它描述了来自Bob的两个注册设备的活动。通过记录设备活动，信任引擎可以检查它们是否有异常行为。攻击者通常会先感染设备，然后使用它们来执行网络扫描，然后利用收集到的信息锁定关键资源。
示例活动日志只显示了几个基本属性，如设备ID、IP地址和地理定位，但这可以很容易地扩展到包括一组更丰富的属性，如正在访问的应用程序或API、活动的结果等等。
图5-6.活动日志记录设备活动并作为审计跟踪，这对于确定设备的异常行为和计算信任分数非常有用
如图5-7所示，用户存储包含Bob的用户（身份）数据，其中包括他的姓名、已注册的身份验证方法、设备ID、地理位置、IP地址和名称。需要记住的一件事是，某些用户属性的变化频率低于其他用户属性。例如，用户名在大多数情况下往往保持不变，而设备id可能每隔几年就会更改一次，作为一个典型组织的设备刷新的一部分，或者在携带您自己的设备（BYOD）的情况下，用户利用一个非公司发布的设备。
总有添加更多用户属性的空间，以及在维护用户数据方面面临的挑战，我们将在第7章中作为用户信任讨论的一部分来讨论这些问题。虽然该场景主要关注用户身份，但所讨论的要点也适用于机器身份。
图5-7.Bob的用户身份数据包括他的姓名、已注册的认证方法、设备ID、地理位置和IP地址
如图5-8所示，信任引擎将计算并分配一个信任分数，以使用动态和静态规则访问来自Bob的请求。它积极地使用来自数据存储中不同实体的数据，并部署机器学习，以确保任何盲点都被识别出来，以及针对特定条件使用静态规则。在这种情况下，使用机器学习动态计算信任分数，以使用活动日志检测异常行为，该活动日志存储历史用户和设备活动日志。机器学习模型将请求归类为高度异常，信任得分为1或2；中度异常，信任分数为3或4；或低异常，信任得分为5或6。
信任引擎还会考虑到用户的身份验证方法，特别是是否使用MFA来验证他们的身份。只有一个因素的请求获得低信任分数3分，而有MFA的请求获得高信任分数5分。最终的信任分数是通过平均分配给一个请求的所有分数来计算的。请记住，在现实世界的零信任实现中如何计算信任分数在很大程度上依赖于计算分数的软件，但是每个请求必须接收策略引擎可以用于决策的最终信任分数。
图5-8。信任引擎使用动态和静态规则对访问请求进行评估并分配信任分数
最后，如图5-9所示，我们有一个策略引擎，它基于授权请求的总体上下文来定义规则，其中包括用户、应用程序、设备、法规要求和信任分数。策略引擎也采用了“拒绝所有内容”的方法。本质上，除非其中一个规则明确允许该请求，否则它将被拒绝访问该资源。
图5-9。策略引擎最终负责授予或拒绝访问请求
让我们来介绍一下一些用例。
8.1 用例： Bob想发送一个文档以进行打印
以下是我们对Bob的请求的了解：
· Bob正在请求访问权限，以将文档发送到组织的打印机。
· Bob正在使用他的笔记本电脑，设备标识为“ABC”。
· Bob使用了MFA，也使用了密码作为身份验证的第一个因素。
· Bob是在办公时间提出这个要求的。
请求分析
1.Bob的访问请求（操作：打印文档，设备id：ABC，身份验证： pwd/mfa，位置：纽约，IP： 1.2.3.4，日期时间：2022年7月24日-上午10：00-美国东部时区）到达执行组件。
2.强制执行组件将访问请求转发到策略引擎以进行批准。
3.策略引擎接收请求，并与信任引擎进行咨询，以确定请求的信任分数。
4.信任引擎将评估该请求:
· 它没有发现任何异常，因为设备访问请求模式以及IP地址和位置似乎与历史数据相一致。它的信任度分为6分。
· Bob也完成了MFA，所以信任分数是5分。
· 该设备已达到符合性要求，并在不到36小时前进行了最近的符合性检查。
· 最后，信任引擎计算信任分数的平均值，它为5.5，并将其返回给策略引擎。
5.策略引擎从信任引擎接收到5.5分的信任分数。
6.对于授权，策略引擎会将请求与所有策略规则进行比较：
第一个规则导致授予（或允许）操作，因为请求是在允许的办公时间内提出的。
第二个规则会导致授予（或允许访问打印机）操作，因为该请求的信任分数大于3。
规则3和规则4不适用于当前的访问请求，因为它是专门针对打印机的。
第五个规则不适用于当前的请求，因为信任分数大于3。
第六条规则不适用于当前的请求，因为该请求不适用于帮助台。
第七条规则，这也是一个默认规则，将不适用。
此规则仅在不执行其他规则时执行。策略引擎停止处理，并最终决定允许打印机访问。
7.策略引擎会向强制执行组件发送一个允许允许的操作。
8.强制执行组件接收策略引擎的结果，并允许Bob的请求打印文档。
8.3 用例： Bob想删除一个电子邮件
以下是我们对Bob的请求的了解：
· Bob想从他的收件箱中删除一封电子邮件。
· Bob正在使用他的手机，设备ID为“XYZ”。
· Bob使用了MFA，也使用了他的密码作为身份验证的第一个因素。
· Bob是在办公时间提出这个要求的
请求分析
1.Bob的访问请求（操作：删除电子邮件，设备id：XYZ，身份验证： pwd/mfa，位置：达拉斯，IP： 6.7.8.9，日期：2022年7月24日-9：45am-时间时区）到达执行组件。
2.强制执行组件将访问请求转发到策略引擎以进行批准。
3.策略引擎接收请求，并与信任引擎进行咨询，以确定请求的信任分数。
4.信任引擎将评估该请求：
· 它没有发现任何异常，因为设备访问请求模式以及IP地址和位置似乎与历史数据相一致。它的信任度分为6分。
· Bob也完成了MFA，所以信任分数是5分。
· 该设备具有符合性，但其最近的符合性检查是在36个多小时前进行的，因此分配的信任分数为4分。
· 最后，信任引擎计算信任分数的平均值为5，并将其返回给策略引擎
5.策略引擎从信任引擎接收信任分数5。
6.对于授权，策略引擎会将请求与所有策略规则进行比较：
第一个规则导致授予（或允许）操作，因为请求是在允许的办公时间内提出的。
第二个规则不适用于当前的访问请求，因为该请求不适用于打印机。
第三个规则不适用于当前的访问请求，因为信任分数低于7。
第四条规则确实适用于当前的访问请求，因为信任分数小于7，这将电子邮件访问限制为只读的（不允许删除或发送电子邮件）。
第五个规则不适用于当前的请求，因为信任分数大于3。
第六条规则不适用于当前的请求，因为该请求不适用于帮助台。
第七条规则，这也是一个默认规则，将不适用。
此规则仅在不执行其他规则时执行。策略引擎停止处理，并最终决定只允许Bob只读访问电子邮件收件箱，而没有删除权限。
7.策略引擎的决定由执行组件接收，该组件授予Bob的电子邮件收件箱只读权限，但拒绝他删除电子邮件。这是确保用户Bob的生产能力不会完全受阻的一个好方法，但是诸如电子邮件删除等特权任务是有限的。
Summary
本章重点介绍了一个系统如何信任一个设备。这是一个令人惊讶的难题，因此需要应用许多不同的技术和实践来确保对设备的信任是必要的。
我们首先研究了人类操作人员是如何将信任注入到一个设备中的。对于相对静态的系统，我们可以让一个人参与提供关键的凭据，但是对于动态的基础设施，需要委托该流程。这些证书非常有价值，我们讨论了如何安全地管理它们。
设备最终需要参与网络，了解它们如何验证自己是很重要的。我们介绍了几种技术，如X.509和tpm，它们可以用于验证网络上的设备。将这些技术和预期库存数据库一起使用，可以大大提供赋予设备可信度的制衡。
信任是转瞬即逝的，并且随着时间的推移而退化，所以我们谈到了更新信任的机制。此外，我们还讨论了许多可以持续用于衡量设备的可信度的信号，以及用于管理设备的机制。也许最重要的教训是，一个设备一开始就处于可信状态，然后只会变得更糟。它的信任度下降的速度是我们想要控制的速度。
场景演练回顾了上一章中的Bob，但这次的重点是设备信任，以及策略引擎以及信任引擎和数据存储等其他组件如何处理各种用例。
下一章将介绍我们如何对系统的用户建立信任。