一、Authorization Architecture
二、Enforcement
三、Policy Engine
四、Trust Engine
五、Data Stores
六、场景演练
Chapter 4. Making Authorization Decisions
授权可以说是发生在零信任网络中的最重要的过程，因此，做出授权决策不应该轻易采取。每一个流程和/或请求最终都将要求您做出一个决定。
我们将在这里讨论的数据库和支持系统是一起做出并影响这些决策的关键系统。它们一起是访问控制的权威，因此需要严格隔离。应仔细区分这些责任，特别是在决定是否将它们分解为一个单一的系统时，一般应尽可能避免这样做。考虑到现实情况，本章将重点讨论做出零信任授权决策所需的组件的高级架构安排，以及它们如何组合在一起并执行上述决策。
一、Authorization Architecture,授权体系结构
零信任授权体系结构由四个主要组件组成，如图4-1所示：
Enforcement
Policy engine
Trust engine
Data stores
这四个组成部分的职责是不同的，因此，我们将它们视为单独的系统。从安全的角度来看，我们非常希望将这些组件相互隔离。这些系统代表了零信任安全模型的实际皇冠，因此在维护和安全姿态时应特别小心。从实现的角度来看，这些组件之间存在隔离是至关重要的，因此，从安全和可用性的角度来看，对这些组件的入侵不会自动导致整个系统的入侵。
这通常由基于云的系统来处理，其中基于saas的服务允许基于各种因素进行隔离，而服务仍然在单个供应商的保护伞下可用。另一种常见的模式是微服务的使用，其中各种服务分布在各个提供者之间，并通过定义良好的api公开。由于目前软件系统通常分布广泛，因此应尽早优先考虑隔离计划。
图4-1.零信任授权系统
强制执行是实际影响授权决策结果的组件。它通常表现为负载均衡器、代理器，甚至是防火墙。这个组件与策略引擎交互，这是我们用来进行实际决策的部分。强制组件确保对客户端进行身份验证，并将每个流/请求的上下文传递给策略引擎。策略引擎将请求及其上下文与策略进行比较，并通知执行者是否允许该请求。执行组件应该在整个系统中大量存在，并且应该尽可能接近工作负载。
信任引擎利用多个数据源来计算风险评分，类似于信用评分。这个分数可以用于保护未知的未知数，并帮助保持策略的强大和健壮性，而不会使边缘案例和签名复杂化。策略引擎将它用作可以作出授权决策的附加组件。谷歌的碧公司被广泛认为是这项技术的先驱。策略引擎利用信任引擎进行风险分析。
最后，各种数据存储代表了被用于通知授权的数据的真实来源。该数据用于绘制特定流/请求的完整上下文图片，使用小的经过身份验证的数据位作为主要查找键（即用户名或设备的序列号）。这些数据存储，无论是用户数据、设备数据，还是其他数据，都被策略引擎和信任引擎大量利用，并代表了衡量所有决策的支持。
二、Enforcement，执行
强制执行组件（如图4-2所示）是一个很自然的起点。它位于授权流程的“前线”上，负责执行授权系统其他部分的决策。
图4-2.代理接收预授权信号，使用传统执行机制授予对系统的访问。这些系统一起构成了强制执行的组成部分。
强制执行可以分为两个主要职责。首先，必须与策略引擎进行交互。这通常是授权请求本身（例如，一个负载均衡器已经收到了一个请求，并且需要知道它是否被授权）。第二个是决策的实际安装和持续的执行。虽然这两个职责代表了零信任授权体系结构中的单个组件，但您可以选择它们是一起履行还是单独履行。
您选择的处理这个问题的方式很可能取决于您的用例。例如，一个身份感知的代理可以调用策略引擎来主动授权它已经接收到的请求，并在同一步骤中使用对服务的响应或拒绝该请求。这是一个将这些关注点视为统一问题的例子。或者，预授权守护进程可能会接收到访问特定服务的请求，然后该请求调用策略引擎进行授权。在授权成功后，守护进程可以操作本地防火墙规则，以允许特定的请求。通过这种方法，我们依赖于由零信任控制平面通知/编程的“标准”执行机制。
但是，需要注意的是，这种方法需要一个客户端钩子，以便通知控制平面的授权请求。这可能是可接受的，也可能是不可接受的，这取决于您需要对设备和应用程序的控制级别。
执行组件的位置非常重要。由于它表示数据平面内的控制点，因此我们必须确保将强制组件放置得尽可能接近端点。否则，信任可以集中在“后面”执行组件，破坏零信任安全性。幸运的是，强制组件可以被建模为各种客户端，并在整个系统中广泛应用。这与其他被建模为服务的授权组件形成了鲜明对比。
三、Policy Engine：策略引擎
策略引擎是一个有能力进行决策的组件。它将来自执行组件的请求与策略进行比较，以确定该请求是否被授权。一旦确定，结果将返回到执行部分以进行实际实现。
执行层和策略引擎的安排允许做出动态的、时间点的决策，从而允许快速发生撤销。因此，重要的是要单独和独立地考虑这些组件。然而，这并不是说它们不能共存。
根据许多因素，可以发现策略引擎与执行机制并排托管。这方面的一个例子可能是通过进程间通信而不是（IPC）代替远程呼叫来授权请求的负载均衡器。此体系结构最吸引人的好处是授权请求的延迟更低。低延迟授权系统允许对网络活动进行细粒度的全面授权；例如，可以授权单个HTTP请求，而不是通常部署的会话级授权。应该注意的是，最好在策略引擎和执行层之间保持过程级的隔离。
位于用户数据路径中的执行层更加暴露；因此，在同一过程中集成策略引擎可能会使其暴露于不必要的风险中。将策略引擎部署为自己的过程，可以确保执行层中的bug不会导致策略引擎妥协。
3.1 Policy Storage
需要存储策略引擎所引用的规则。这些策略规则最终会被加载到策略引擎中，但强烈建议在策略引擎本身之外捕获这些规则。将策略规则存储在版本控制系统中是很理想的选择，它有以下几个好处：
· 可以随着时间的推移而跟踪对策略的更改。
· 在版本控制系统中跟踪更改策略的基本原理。
· 可以根据实际的执行机制来验证预期的当前策略状态。
这些好处中有许多历来都是通过使用严格的变更管理程序来实现的。在该系统中，在最终应用之前，会请求并批准对系统配置的更改。生成的变更管理日志可以用来确定系统处于当前状态的原因。
当系统可以通过编程方式进行配置时，将策略定义移动到版本控制中是变更管理过程的逻辑结论。我们可以将该策略作为程序可以读取和应用的数据来捕获，而不是依赖于人类系统管理员来将所需的策略加载到系统中。在许多方面，加载策略都类似于可部署的软件。因此，系统管理员可以使用标准的软件开发过程（即代码审查和升级管道）来管理策略中的更改。
3.2 什么是好的政策？
零信任网络中的策略在某些方面与传统的网络安全相似，但在其他方面却有本质上的不同。
❗零信任策略仍然没有标准化
今天的现实情况是，零信任策略仍然没有像面向网络的策略那样标准化。因此，定义在零信任网络中使用的标准策略语言是一个很好的机会。
让我们先看看什么是相似的。在零信任网络中的良好策略是细粒度的。粒度级别将根据网络的成熟度而变化，但期望的目标是针对被保护的单个资源的策略。这与传统的网络安全模型没有太大的不同，后者旨在分割网络以减少攻击表面积。
在用于定义策略的控制机制中，零信任模型开始偏离传统的网络安全。与其根据网络实现细节（如IP地址和范围）来定义策略，不如最好根据网络中的逻辑组件来定义策略。这些组成部分通常包括：
Network services
Device endpoint classes
User roles
❗在云的时代的规模：pets 和 cattle
随着越来越多的企业作为“数字转型”的一部分，他们正在减少对本地数据中心的依赖。云计算带来了一个企业从未经历过的规模水平。通过使用轻量级容器和无服务器的技术，应用程序可以在几秒钟内扩展以支持非常高的吞吐量，然后缩减，在不再需要容器或无服务器实例时删除这些实例；因此，“cattle”一词通常用来指代它们。相比之下，在本地数据中心中，物理服务器由企业命名和维护多年，所以它们被称为“pets”。在零信任的上下文中，策略必须足够动态，以便在在发生时时一致工作，这适用于放大和缩小。
从网络中存在的逻辑组件定义策略，允许策略引擎根据其对网络当前状态的了解来计算执行决策。具体地说，今天运行在一台服务器上的web服务明天可能会运行在另一台服务器上，甚至可能按照工作负载调度程序的指示在服务器之间自动移动。我们所定义的政策需要脱离这些实施细节，以适应这一现实。图4-3显示了来自库伯内特斯项目的这种策略风格的一个示例。
图4-3.来自Kubernetes的一个网络策略的片段。这些策略使用工作负载标签，在必要时计算底层的基于ip的执行规则。
虽然没有单一的方法或标准来定义策略，但它们通常以JSON或YAML格式配置，并且在语义上易于理解。考虑谷歌的自定义访问级云策略，它定义了已知设备的条件，如运行已知操作系统的公司拥有和管理批准的设备：
零信任网络中的策略也依赖于信任分数来预测未知的攻击向量。通过使用信任分数组件定义策略，管理员能够减轻特定策略无法捕获的风险。因此，大多数策略都应该包含一个信任分数组件。看看下面微软Azure云中的条件访问策略示例，该策略要求任何风险评分为“中”或“高”的用户在登录HR应用程序时执行强制性的多因素身份验证。本章后面将在下面详细介绍信任分数：
❗缺乏政策标准
在撰写本文时，还没有全行业的政策定义标准；然而，国家卓越网络安全中心（NCCoE）等组织正在为此做出努力。它已经创建了一个公开的描述，要求实现网络安全参考设计的零信任的实践步骤，以及零信任的各种组成部分，包括政策。你可以通过访问NCCoE网站了解更多信息。
政策不应该仅仅依赖于信任分数。被授权的请求的特定特征也可以是策略定义的一部分。例如，这可能是某些用户角色应该只能访问特定的服务。
3.3 Who Defines Policy?
零信任网络策略应该是细粒度的，这可能会给系统管理员带来巨大的负担，以保持该策略的最新状态。为了帮助分散此配置负担的负荷，大多数组织决定跨团队分配策略定义，以便他们能够帮助维护他们所拥有的服务的策略。向整个组织开放策略定义可能会带来某些风险，比如创建过于广泛的策略的善意用户，从而增加他们打算限制的系统的攻击表面积。零信任系统依赖于两个组织的工作流来抵消这种暴露。
3.4 Policy Reviews：政策审查
首先，由于策略通常存储在版本控制下，因此让另一个人审查对策略的更改有助于确保更改得到了充分的考虑。安全团队还可以另外审查这些更改，并提出一些探究性的问题，以确保所定义的策略的范围尽可能严格。由于策略是使用逻辑意图而不是物理组件来定义的，因此策略的变化将比用物理术语定义的策略更快。
使用的第二个组织度量是在细粒度策略的基础上分层构建广泛的基础设施策略。例如，一个基础设施组可能会正确地要求只允许一组特定的角色来接受来自互联网的流量。因此，基础设施团队将定义强制执行该限制的策略，并且不允许任何用户定义的策略来规避该限制。执行这种约束可以采取几种形式：对拟议策略的自动测试，或者可能是一个只会拒绝来自不可信来源的过于广泛的策略断言的策略引擎。这种强制执行也可以用于法规遵从性和监管要求。
虽然没有标准的零信任过程来定义该策略，但吉卜林方法为定义零信任策略提供了一个很好的指导方针。此方法有助于简明地解释资源访问的谁、什么、什么、何时、何处、为什么和如何策略：
· 应该允许谁来访问一个资源？这本质上是允许启动流程的身份（可以是人或机器）。
· 允许哪些应用程序/API/服务访问该资源？
· 何时允许该身份访问该资源？这主要涉及到时间框架，如办公时间等。
· 资源位于哪里？这可以出现在任何地方，包括云、内部部署数据中心等。
· 为什么允许该身份访问该资源？这是访问的主要理由或理由，对合规和监管目的至关重要。
· 在访问资源时应该如何处理流量？
四、Trust Engine
信任引擎是在零信任网络中针对特定请求或操作执行风险分析的系统。该系统的责任是对允许特定请求/行动的风险进行数字评估，策略引擎使用该请求/行动来做出最终的授权决策。
信任引擎将经常从权威库存系统中包含的数据中提取，以在计算其分数时检查实体的属性。例如，设备清单可以向信任引擎提供诸如上次设备被审计或扫描时的信息，或者它是否具有特定的硬件安全特性。
创建一个风险的数字评估是一项困难的任务。一种简单的方法是定义一组临时规则，用来对实体的风险进行评分。例如，一个缺少最新软件补丁的设备的分数可能会降低。类似地，持续无法进行身份验证的用户的信任分数可能会降低。虽然特别的信任评分可能很简单地开始，但一组静态定义的规则将不足以达到抵御意外攻击的预期目标。因此，除了使用静态规则之外，成熟的信任引擎还使用机器学习技术来推导出一个评分函数。
机器学习通过从一个被称为训练数据的活动数据的子集中计算可观察到的事实来得到一个评分函数。训练数据是与可信或不可信实体相关联的原始观察结果。从这些数据中，特征被提取并用于推导一个计算机生成的评分函数。这个评分函数，或机器学习术语中的模型，然后对一组与训练数据格式相同的数据进行运行。将所得到的分数与人类定义的风险评估进行比较，然后可以根据模型正确预测与被分析数据相关的风险的能力来细化模型的质量。一个具有足够精度的模型可以说是预测网络中未看到的请求的风险。
机器学习模型可以从各种属性中学习，比如用户的IP地址、地理位置、设备等等，以评估当前用户请求在当前上下文中是异常的还是典型的。请记住，“假阳性”随时都可能发生。这是因为在一些合法的情况下，有问题的用户活动是正常的，但预测往往是异常的。
在现实生活中，当用户前往一个新的地点，可能是为了度假，并发出访问请求时，就可以看到一个假阳性的例子。在这种情况下，机器学习模型还没有针对这个新用户的位置进行训练，因此它很可能会将其识别为一种异常模式。处理假阳性是机器学习中的一个热门话题，它通常通过调整学习时间、精确度和召回率等因素来改进。
❗对于机器学习，你应该考虑哪些因素？
虽然不可能编制一个详尽的列表，但在研究机器学习模型和训练集时，请考虑以下因素作为起点：
①IP地址、 Autonomous System Number（自主系统号，ASN）和地理位置
这些是重要的属性，可以帮助用户/设备长期确定异常模式。
②User activity
这包括属于日常生产力范围的常规用户请求，比如访问不同的应用程序/API端点，等等。
③Privileged activity
这包括通常属于管理员角色的活动，但也包括几乎任何被归类为特权的活动，例如删除用户帐户等。
④休眠账户
长时间不活动的帐户必须这样标记。这有助于检测不寻常的活动。通过识别突然活跃的休眠帐户，可以检测欺诈帐户访问。
虽然机器学习越来越多地用于解决困难的计算问题，但它并不排除在信任引擎中需要更明确的规则。无论是由于派生的评分模型的限制，还是对定制评分功能的愿望，信任引擎通常都会使用临时的和机器学习评分方法的混合物。
4.1 哪些实体得分？
决定一个零信任网络的哪些组成部分应该被得分是一个有趣的考虑因素。是否应该为每个单独的实体（用户、设备和应用程序）、网络代理的一个整体或两者计算分数？让我们来看看一些场景。
想象一个用户的凭证被恶意的第三方强迫。一些系统将通过锁定用户的帐户来减轻这种威胁，这可能会对该特定用户发起拒绝服务攻击。如果我们根据该活动对用户进行负面评分，那么一个零信任网络也会遇到同样的问题。一个更好的方法是意识到我们正在对网络代理进行身份验证，这样攻击者的网络代理就会被抵消，从而使合法用户的网络代理不受伤害。此场景表明，网络代理是应该进行评分的实体。
但是仅仅对其他攻击向量打分是不够的。考虑一个与恶意活动关联的设备。该设备上的用户的网络代理可能没有显示出恶意行为的迹象，但该代理与可疑设备组成的事实显然会对来自该设备的所有请求的信任分数产生影响。这种情况强烈建议，应该对该设备进行评分。
最后，考虑一个恶意的人类用户（臭名昭著的内部威胁），他正在使用多个kiosk设备来泄露商业秘密。我们希望信任引擎在用户跨设备跳跃时识别这种行为，并反映其未来所有授权决策的信任分数的信任水平下降。
在这里，我们再次看到，仅对网络代理进行评分并不足以减轻常见的威胁。从整体上来看，似乎正确的解决方案是同时对网络代理本身和组成代理的底层实体进行评分。这些分数可以暴露给策略引擎，策略引擎可以根据正在写入的策略选择正确的组件来进行授权。
然而，在制定政策时，要考虑如此多的分数，会使制定政策的任务更加困难和容易出错。在理想的世界中，只有一个分数就足够了，但这种方法为信任引擎提供了额外的可用性需求。试图创建单个分数的系统可能需要移动到在线模型，在该模型中，在策略决策期间交互查询信任引擎。
引擎将得到一些关于被授权请求的上下文，以便它可以为该特定请求选择最佳评分函数。这种设计显然比建造和操作更加复杂。此外，对于系统管理员特别希望针对特定组件的策略（例如，只允许从分数大于X的设备上进行部署），它似乎相当迂回。
4.2 暴露得分被认为是有风险的
虽然分配给零信任网络中的实体的分数不被认为是机密的，但应该避免将这些分数暴露给系统的最终用户。看到一个人的分数可能是潜在攻击者的一个信号，表明他们正在增加或减少他们在系统中的可信度。这种隐瞒信息的愿望应该与终端用户无法理解他们的行为如何影响他们自己在系统中的可信度所引起的挫折感相平衡。欺诈行业的一个很好的妥协是很少向用户展示他们的分数，并突出影响他们决定分数的因素。
五、Data Stores
用于做出授权决策的数据存储，很简单，是系统当前和过去状态的真实来源。来自这些数据存储的信息通过控制平面系统流动，提供了做出授权决策的大部分基础，如图4-4所示。
我们之前讨论到了信任引擎利用这些数据存储来产生信任分数，而策略引擎又会考虑信任分数。通过这种方式，来自控制平面数据存储的信息已经通过授权系统流动，最终到达了做出决策的策略引擎。这些数据存储被策略引擎直接或间接地使用，但它们对于需要关于网络状态的权威数据的其他系统可能很有用。
图4-4.策略引擎通过信任引擎直接或间接地使用权威数据存储
零信任网络往往有许多数据存储，并按功能进行组织。它主要有两种类型：库存类型和历史类型。库存是一个单一的真实来源，记录它所代表的资源的当前状态。例如，存储所有用户信息的用户清单，或记录有关公司已知设备的信息的设备清单。
在库存中，存在一个唯一表示被跟踪实体的主键。对于用户，可能的选择是用户名；对于一个设备，它可能是一个序列号。当零信任代理进行身份验证时，它将根据库存中的这个主密钥来验证其身份。
你可以这样想：用户对给定的用户名进行身份验证。策略引擎将知道用户名，并且该用户已成功通过身份验证。然后，将将用户名用作查找用户库存的主键。记住这个流程和目的将帮助您选择正确的主键，这取决于您特定的实现和特定的身份验证选择。
历史数据存储区有点不同。保存历史数据存储主要是为了进行风险分析。它们可用于检查最近/过去的行为和模式，以评估与特定请求或行动相关的风险。信任引擎组件最有可能消耗这些数据，因为信任/风险决定是引擎的主要责任。
人们可以想象许多类型的历史数据存储，当涉及到风险分析时，天空是极限的。一些常见的例子包括用户会计记录和sFlow数据。无论存储的数据是什么，都必须使用其中一个库存系统的主键进行查询。在本书中，我们将介绍各种库存和历史数据存储。
从内部和外部第三方来源收集的威胁情报，如开源情报（OSINT），提供了信任引擎可以用来确定信任分数的有价值的见解。考虑这样一个场景，即由于最近的数据泄露，用户的凭证在暗网上被泄露。在这种情况下，信任引擎可以使用威胁智能来计算针对用户的信任分数，这可能会导致策略引擎拒绝该请求或授予其有限的访问权限。
合规和监管标准，如一般数据保护法规（GDPR）、联邦风险和授权管理计划（FedRAMP）等，在分析请求时会对政策引擎的决策过程产生影响。组织通常维护一个版本控制的系统，以维护法规遵从性和法规要求，可用于创建策略，理想情况下是完全自动化的，但很可能需要在发布之前进行最终的人工审查。最终的结果是一个健壮的系统，在这个系统中，策略引擎可以查询遵从性和法规存储，以确定请求是应该被授予还是被拒绝。
六、场景演练
在我们结束这一章之前，让我们考虑一个简单但真实的场景，它将帮助您理解本章和前面章节中讨论的各种组件，以及它们是如何相互交互的。后面的章节将扩展这个场景，并将深入研究零信任的各个方面，如用户、设备、应用程序和流量。让我们来看看一个名为Bob的用户的典型工作流，他是韦恩公司的业务经理，正试图访问一个资源，比如打印机。图4-5描述了此场景中零信任组件的高级分解。
图4-5.包含控制平面、数据平面、用户和资源的零信任安全模型的逻辑视图
首先，检查控制平面中的零部件，如图4-6所示。Bob的个人信息，如他的姓名、IP地址和位置，都存储在用户存储区中。设备数据包括操作系统以及Bob的设备是否收到了最近的安全补丁等细节。最后，活动日志记录了他所拥有的每一个交互，包括时间戳（以Unix格式）、IP地址和位置。
信任引擎使用了一个机器学习模型，通过查找Bob的活动日志中的异常行为来动态计算信任分数。它的主要职责是计算并将信任分数传达给策略引擎。策略引擎是控制平面的核心，它使用信任分数和遵从性策略来确定是否应该批准或拒绝Bob的请求。
图4-6.要针对访问请求做出授权决策，策略引擎将使用信任分数以及遵从性规则
现在，我们将仔细研究管理策略引擎行为的策略规则。前两个是与合规相关的，确保系统始终遵守法规和运营的业务要求。第三种方法将信任分数作为动态输入添加到策略中，以确保只有在分数超过某个阈值时才会授予请求。最后，如果没有应用其他策略规则，则将默认行为设置为拒绝授权请求，以确保访问必须被拒绝，除非策略规则显式地授予它：
- Compliance：合规性
只允许在周一办公时间、周一至周五上午9点到下午5点之间提出请求。东部时区（美国东部时间）。
2.vvv
仅允许来自已接收到最近的安全更新的设备的请求。其目标是确保设备打补丁，不容易受到攻击。
-
Trust Score
仅当信任分数大于7/10时，才允许进行请求。在这种情况下，较高的信任分数会激发更多的信心，因此使用的值为7。通常，策略中的信任分数值是可配置的，并随着时间的推移进行调整，以确保平衡；低分数的阈值允许恶意请求被遗漏，而高分数可能会对真正的访问请求产生负面影响。 -
Default
如果没有应用其他策略规则，则这是生效的覆盖（默认）规则。此规则很重要，因为建议在默认情况下拒绝，而不是在默认情况下允许。这很有用，因为在零信任系统中没有固有的信任，因此每个请求都会根据其自身的优点进行评估，并同样被视为恶意的请求。
接下来，考虑数据平面，其中包括强制执行、资源（打印机、文件共享等），以及请求访问资源的用户Bob（此处为文件共享）。图4-7描述了控制平面和数据平面。
图4-7.在策略引擎使用信任分数和其他策略规则评估请求后，Bob访问文件共享的请求被拒绝
以下是对Bob的要求的逐步分析：
1.周一上午9：30。美国东部时区（EST），Bob请求从他的笔记本电脑上访问文件共享。这款笔记本电脑已经打了补丁，运行MacOS。
2.强制组件拦截请求并将其发送到策略引擎进行授权。
3.策略引擎接收请求，并与信任引擎进行咨询，以确定请求的信任分数。
4.信任引擎使用机器学习模型来基于活动日志计算信任分数。可以检测到异常，因为Bob的IP地址为1.2.3.5和在芬兰的位置不寻常。此外，鉴于这些请求是来自纽约和芬兰提出的，而且相隔只有几秒钟，最后两种活动之间的时间戳似乎不可能匹配。机器学习模型决定为请求分配信任分数3，表示信任水平较低，并将分数发送给策略引擎。
5.策略引擎从信任引擎接收到的信任分数为3。
6.对于授权，策略引擎会将请求与所有策略规则进行比较：
7.策略引擎会向强制执行组件发送一个拒绝操作。它还发送了有关结果的额外信息，这有助于理解拒绝所请求的行动的原因。
8.强制执行组件接收策略引擎的结果，并拒绝Bob的请求，从而阻止他访问文件共享。它还向Bob发送了一个有用的信息，即如果他决定在未来的请求中这样做，则如何提高他获得访问资源的机会。
虽然本质上是基本的，但本节中的场景演练提供了控制平面和数据平面中的各种组件共同拒绝Bob访问文件共享的请求。关键的结论是，现有的系统不会根据特别的基础知识做出授权决策，而是在做出决策时考虑到访问请求的整体上下文。
Summary
本章重点讨论了负责对是否应该在零信任网络中授权一个特定请求作出最终决定的系统。这个决定是这样一个网络的一个关键组成部分，因此应该仔细设计和隔离，以确保它是值得信赖的。
我们将这个责任分解为四个关键系统：执行、策略引擎、信任引擎和数据存储。这些组件都是合乎逻辑的责任领域。虽然它们可以被分解成更少的物理系统，但作者更喜欢一个孤立的设计。
强制执行系统负责确保策略引擎的授权决策生效。该系统位于用户流量的数据路径中，最好以引用策略决策并强制执行的方式来执行。根据所选的体系结构，策略引擎可能会在请求发生之前或在处理同一请求的过程中得到通知。
策略引擎是基于系统引擎可用的数据和系统管理员所制定的策略定义来计算授权决策的关键系统。这个系统应该被严格隔离。理想情况下，所定义的策略应该与引擎分开存储，并应使用良好的软件开发实践，以确保在策略从提出到实施的过程中能够理解、审查更改，而不是丢失更改。此外，由于零信任网络期望拥有更细粒度的策略，成熟的组织选择将定义该策略的责任分配到组织中，并由安全团队审查所提议的更改。
信任引擎是安全系统中的一个新概念。该引擎负责使用来自过去行为的静态和推断算法来计算系统组件的信任分数。信任分数是对组件可信度的数字决定，允许策略作者关注访问某些资源所需的信任级别，而不是可能减少信任的特定细节。
该系统的这部分的最后一个组成部分是权威的数据源，它可以捕获可用于做出授权决策的当前和历史数据。这些数据存储应该关注于成为真理的来源。策略引擎、信任引擎，也许第三方系统可以利用这些数据，因此收集这些数据将在捕获它的投资上获得可观的回报。
场景演练演示了各种控制和数据平面组件如何交互以使系统工作。在我们的场景中，用户Bob访问文件共享的请求是基于请求的总体上下文进行评估的，其中包括动态信任分数计算和业务为做出最终授权决策而制定的各种策略。本场景演练将在后面的章节中进行扩展。
下一章将深入研究设备如何获得和保持信任。