其他分享
首页 > 其他分享> > 零信任架构

零信任架构

作者：互联网

零信任架构

目录

译自NIST Special Publication 800-207 Zero Trust Architecture

1 简介

传统的企业基础设施正在变得越来越复杂。一个企业可能维护多个内部网络、远程办公室的本地基础设施、远程以及/或移动人员、云服务等。这种复杂性已经超过了传统的基于外围的网络安全方式，因为这种情况下企业中已经不存在单一的、易于识别的外围网络，因此基于外围的网络安全已经无法满足企业的需求，因为一旦攻击者攻破外围防护，就可以畅通无阻地进行内网漫游。

上述复杂场景衍生除了新的安全模型，称为"零信任"(ZT)。一个ZT方式主要关注数据和服务安全，但可以(应该)扩展到所有企业资产(设备、基础设施组件、应用、虚拟和云组件等)和对象(终端用户、应用和其他请求资源信息的非人类实体)。在本文中，除非指定的是人类终端用户(此时会使用"用户"来代指)，否则一律使用"对象"。零信任安全模型假设环境中也可能会出现攻击者，即企业所有的环境和非企业所有的环境一样不可信任。在这种模型下，企业必须假设不存在隐式信任，并持续分析和评估资产和业务功能中存在的风险，并制定相应的方式措施来降低这些风险。在零信任中，这些防护通常涉及最小化资源(如数据和计算资源，以及应用/服务)访问，仅将资源授予需要访问的对象或资产，并持续对每个访问请求的身份进行认证和授权。

一个零信任架构(ZTA)是一个基于零信任原则的企业网络安全架构，用于防止数据违规以及限制内网漫游。本文讨论了ZTA，以及其逻辑组件、可能的部署场景和威胁等，并为期望迁移到零信任的组织提供了通用的线路图，以及讨论了可能会影响零信任架构的相关联邦政策。

ZT不是一个单一的架构，而是用于提升安全等级和敏感级别 [FIPS199]的一系列指导原则。向ZTA的转换涉及组织如何来评价其任务中存在的风险，且不能简单地通过批量技术替换来实现。组织应该根据使用场景来逐步实现零信任原则、处理变更以及技术方案来保护其数据资产和业务功能。大多数企业技术设施运行在零信任/基于周边的混合模型中。

为了高效地使用零信任，组织需要实现全面的信息安全和恢复实践(resiliency practices)。当与现有的网络安全策略和指导、身份和访问管理、持续监测和最佳实践相平衡时，ZTA可以防护常见的威胁并使用风险管理方式来改善组织的安全现状。

1.1 与联邦机构有关的零信任历史

零信任的概念早在"零信任"这个名词出现之前就出现在了网络安全中。 Defense Information Systems Agency(DISA) 和 Department of Defense 发布了一个更加安全的企业战略，称为"black core"[BCORE]。black core涉及从基于周边的安全模型转移到注重单独事务的安全模型。Jericho Forum在2004年传达了这种去边界的观点--限制基于网络位置的隐式信任，以及限制在大型网段中依赖单一的、静态防护。这种去边界的观点逐步演化为零信任(由Forrester的John Kindervag创造)，再后来，零信任成为一个用于描述各种网络安全方案的术语，移除基于网络位置的隐式信任，并在每个事务中评估信任等级。目前，私有企业和高等教育都在对从基于周边的安全向基于零信任原则的安全策略的演化进行评估。

联邦机构很早就期望迁移到基于零信任原则的安全，并以此构筑相关的能力和策略，如Federal Information Security Modernization Act (FISMA)，随后是 Risk Management Framework (RMF)；Federal Identity, Credential 和 Access Management (FICAM)；Trusted Internet Connections (TIC); 和 Continuous Diagnostics 和 Mitigation (CDM) 等程序，这些程序的目的都用于限制数据和资源访问授权方。由信息系统来管控这些程序。安全策略大部分是静态的，且在"咽喉处"强制执行，企业通过这种方式进行安全管控。随着技术的成熟，可以以动态和颗粒的方式来持续分析和评估"需要"访问的请求，以减轻由于账户泄露造成的数据曝光、攻击者对网络的监控以及其他威胁。

1.2 文档结构

后续文档的结构如下：

2 零信任基础

零信任是一个网络安全模型，主要注重资源防护，并禁止隐式授权，且需要持续对权限进行评估。零信任架构是一个端到端的方法，企业资源和数据安全包括身份(人和非人类实体)、凭证、访问管理、维护、后端、托管环境和内部连接的基础设施等。一开始主要关注限制需要访问的资源并授予最小权限(如读、写、删除等)。传统机构(和企业网络)通常关注外围防护，在内部网络中通过认证的对象可能会被授予大量资源的访问权限。最终，环境中未授权的内网漫游成了联邦机构最大的挑战。

Trusted Internet Connections (TIC)和机构外围防火墙提供了强大的互联网网关，可以帮助阻止来自互联网的攻击者，但TICs和外围防火墙缺乏探测和阻止来自内网的攻击，且无法防护企业外围以外(如远程工作者、基于云的服务、边缘设备等)的对象。

一个对零信任和零信任架构的操作性的定义如下：

零信任提供了一系列概念和想法，旨在当网络出现漏洞时，降低信息系统和服务执行的不确定性，以及最小化请求访问特权。零信任架构是一种利用了零信任概念、包含的组件关系、工作流计划以及访问策略的企业网络安全规划。因此，一个零信任企业可以看作是网络基础设施(物理和虚拟)和运营策略的结合体，将企业当成一个零信任架构产品。

当一个企业决定采用零信任作为其核心战略并做出零信任架构规划后，就需要依据零信任原则(2.1章节)进行开发。该规划最终会发布为一个零信任环境，以供企业使用。

上述定义关注的重点问题为：阻止对数据和服务的未授权访问，以及尽可能以粒度的方式执行访问控制。即，授权并允许对象(用户、应用或服务、设备等)访问数据，并排除其他对象(即攻击者)的访问请求。更进一步，可以使用"资源"来替换"数据"，这样ZT和ZTA就需要关注资源访问(如打印机、计算资源、IOT等)，而不仅仅是数据上的访问。

为了降低不确定性(不确定性是无法消除的)，需要关注认证、授权、在保持可用性的同时收缩隐形信任域、降低授权机制中的(时间)延迟。对于需要执行的请求动作，尽量以粒度的方式来执行访问规则，以此最小化特权。

图1展示了简单的访问模型，当一个对象需要访问企业资源时，通过决策节点(PDP)以及策略实施点(PEP)进行授权。

系统必须保证对象是可信的，且请求是有效的。PDP/PEP 会通过适当的判断来允许对象访问资源。这意味着零信任适用于两个基本的领域：认证和授权。对于一个特定的请求，对该对象的信任程度有多少？鉴于对象身份的可信程度，是否可以访问该资源？用于该请求的设备是否足够安全？在变更可信等级时(如时间、对象的位置、对象的安全态势等)是否需要考虑其他因素？总之，企业需要开发和维护基于风险的动态资源访问策略，并配置一个系统来保证这些策略能够正确且持续处理各个资源的访问请求。这意味着企业不能依赖隐式信任(如果一个对象满足基本的认证级别(如，登录到一个资产)，所有后续的资源请求都应该是同样有效的。)

"隐式信任域"表示在该域中的所有实体至少在上一个 PDP/PEP 网关级别上是可信的。例如，机场的旅客筛选模型，所有旅客都会通过机场的安全检查点(PDP/PEP)到达登机口。旅客、机场员工、机组人员等都处于机场区，所有的个体都被认为是可信的。在该模型中，隐式信任域就是登机区域。

PDP/PEP使用了一组访问控制，因此PEP之外的所有流量都具有相同的信任级别。PDP/PEP无法在流量的位置之外添加额外的策略。为了尽可能使PDP/PEP具体 ，应该尽可能减小隐式信任域。

零信任提供了一组原则和概念来让PDP/PEP更靠近资源。目的是为了明确地对构成企业的所有对象、资产和工作流进行认证和授权。

2.1 零信任原则

ZT的很多定义和讨论都强调去除广域外围防护(如企业防火墙)。然而，大部分定义仍然以某种外围方式(如微分段或微-外围，见3.1章节)来定义ZTA的部分功能。下面内容尝试定义了ZT和ZTA的基本原则(注重涉及到的内容，而非排除掉的内容)。这些原则是理想目标，但不得不承认，对于一个给定的战略，可能并不需要实现所有的原则。

一个零信任架构的设计和部署需要遵循如下零信任基本原则：

  1. 所有的数据源和计算服务都被认为是资源。一个网络可能包含多种类型的设备。一个网络也可能包含可以发送数据到聚合器/存储的小型设备、SaaS、可以向执行器发送指令的系统以及其他功能。当然，一个企业也可能将个人拥有的设备作为资源(如果这些设备可以访问企业的资源)
  2. 所有通信都必须是安全的，不受网络位置的限制。单独的网络位置并不意味着是可信的。同来其非企业网络的访问请求和通信一样，来自企业的网络基础设施(如外围代理网络中)中的资产的请求同样需要符合安全要求。换言之，不能根据企业网络基础设施的设备来动态授权。所有通信应该采用最安全的方式进行，保证机密性和完整性，并提供安全认证。
  3. 根据每个会话来授权访问单独的企业资源。在访问授权前需要对请求者进行评估。为了完成任务，也可使用所需的最低特权进行访问授权，这种情况可能意味着"最近有时"发生了该事务，且在发起会话之前可能不会直接发生或使用资源执行该事务。然而对一个资源的认证和授权并不会自动授权其对其他资源的访问。
  4. 使用动态策略(包含可观测的客户身份状态、应用/服务和请求的资产，也可能包含其他行为和环境属性)来决定对资源的访问。组织通过定义资源包含哪些内容、资源的成员有哪些(或能够从联合社区验证用户)以及这些成员需要访问资源的哪些内容来保护资源。对于零信任，客户身份可能包括用户账户(或服务身份)以及企业授予给该账户(用于认证自动任务)的相关属性。请求资产状态可以包含设备特征，如安装的软件版本、网络位置、请求的时间/日期、先前观察到的行为以及安装的凭证等。行为属性包括但不限于，自动对象分析、设备分析以及使用模式中的测量偏差。策略是基于属性的一组访问规则，组织将策略授予对象、数据资产或应用，环境数据可能包括请求者的网络位置、时间、报告的活动估计等因素。需要根据业务流程和可接受的风险级别来分配这些规则和属性。可以根据资源/数据的敏感程度来变更资源访问和动作策略。最小特权原则可以同时限制可见性和可访问性。
  5. 企业监控并权衡所拥有的(和相关的)资产的完整性和安全态势。资产不能继承信任属性。在评估一个资源请求时，企业需要对资产的安全态势进行评估。实现了ZTA的企业应该建立一套持续诊断和缓解(CDM)或类似的系统来监控设备和应用的状态，并在需要时打上补丁(或修复问题)。当发现资产遭到破坏(出现漏洞)，且资产不归企业管理时，对威胁的处理可能与资产归企业所属(这种情况下的资产被认为是最安全的)的情况不同。上述场景也适用于允许某些设备(如个人设备)访问某些资源，但拒绝其他设备对这些资源的访问的场景。即，需要一个健壮的监控和报告系统来提供关于企业资源当前状态的可操作数据。
  6. 所有资源的认证和授权都是动态的，且必须在访问前严格执行。这是一个恒定的循环，获取访问、扫描并评估威胁、适配并持续评估正在进行的通信的可信度。一个实现了ZTA的企业应该具有身份、凭证和访问管理(ICAM)以及资产管理系统。包括使用多因子认证来访问所有或一部分企业资源。根据策略(如基于时间的新的资源请求、资源修改、探测到异常对象活动等)的定义和实施，在整个用户事务中持续监控可能发生的重认证和重授权，力求实现安全性、可用性、可用性和成本效率的平衡。
  7. 企业应该尽可能多地采集当前资产、网络基础设施和通信的状态，并使用这些状态提升其安全态势。一个企业应该采集关于资产安全态势、网络流量和访问请求的数据，处理并使用这些数据来改善策略的创建和实施。这些数据也可以为对象的访问请求提供上下文(见3.3.1章节)。

上述原则与技术无关。例如"用户ID"可以包括如用户/密码、证书和一次性密码等因素。这些原则可以用于一个组织或一个或多个合伙组织，且不能用于匿名公开或面向消费者的业务流程。一个组织不能向外部参与者(如消费者或一般的互联网用户)暴露内部策略，但可能会为非企业用户实现一些基于ZT的策略，进而将其与企业进行关联(如注册的消费者、员工家属等)。

2.2 网络的零信任视角

对于任何在网络规划和部署中使用ZTA的企业来说，它们对网络连接都有一些基本的设想。一些设想会用于企业所有的网络基础设施，而其他则会用于在非企业所有的网络基础设施(如公共Wi-Fi或公有云供应商)上运作的企业所有的资源。这些设想构成了一个ZTA。实现了ZTA的企业应该使用上述ZTA原则和下面设想来开发网络：

  1. 整个企业私有网络都不应该认为是一个可信域。应该假设攻击者随时可能会出现在企业网络上，且应该采用最安全的方式进行通信(见上述原则2)。这些限制动作包括对所有连接进行认证，对所有流量进行加密。
  2. 网络上的设备不应该由企业所有或由企业进行配置。访客或承包服务可能包含非企业所有的资产，这些资产也需要接入网络。包括使用自己的设备(BYOD)策略来允许企业对象使用非企业所有的设备来访问企业资源。
  3. 资源不能继承信任。在授予一个请求访问企业所有的资源之前，必须通过PEP来评估每个资产的安全态势(类似上述原则6，适用于资源和对象)。只要会话存在，就应该持续进行评估。企业所有的设备可能具有支持认证的部件，由此可以提供比来自非企业所有的设备的请求更高的可信级别。仅仅凭对象凭据无法满足对设备(到企业资源)的认证。
  4. 不是所有的企业资源都在企业所有的基础设施中。资源包括远程企业对象以及云服务。企业所有或管理的资产可能需要使用本地(即非企业)网络进行基本的连接和网络服务(如DNS解析)。
  5. 远程企业对象和资产可能不会完全信任其本地网络连接。远程对象可能会假设本地(即非企业所有的)网络是不友善的。资产应该假设所有的流量都有可能被监控或修改。所有连接请求都应该通过认证和授权，且应该尽可能使用最安全的方式进行通信(即提供保密性、完整性保护和数据源验证)。参见上述ZTA原则。
  6. 在企业和非企业基础设施上转移的资产和工作流应该保持一致的安全策略和态势。在转移到(或转移自)企业所有的基础设施上时，资产和工作流应该维持其安全态势。这包括将设备从企业网络转移到非企业网络(即远端用户)。也包括将工作流从本地数据中心迁移到非企业的云实例上。

3 零信任架构的逻辑组件

在企业中，可以使用大量逻辑组件来构造ZTA。这些组件可能以一个本地服务或云服务的方式运行。图2展示了组件和组件间交互的框架概念模型。注意这是一个理想的模型。从图1的决策节点(PDP)可以拆分出两个逻辑组件：策略引擎和策略管理器(见下)。ZTA逻辑组件使用控制面进行通信，数据则使用数据面进行通信(见3.4章节)。

组件描述：

除了实现ZTA的核心组件，在作访问决策时，策略引擎还使用一些数据源来提供输入和策略规则。这些数据源包括本地数据源以及外部数据源(即非企业控制或创建的)。它们可以包括：

3.1 零信任架构方式的变种

企业有几种方式来制定ZTA工作流。不同的方法在使用的组件和主要的策略规则来源上有所不同。每种方式都实现了所有的ZT原则(见2.1章节)，但可能使用其中一种或两种(或一个组件)作为主要的策略驱动因素。一个完整的ZT会包含三种方式中的所有元素。这三种方式为：增强身份治理，逻辑微分段和基于网络的分段。

不同的方式有其特定的适用场景。一个企业在开发ZTA时，可能会发现某种方式更适用于其使用场景和现有的策略点。这并不意味着其他方式无法工作，仅意味着其他方式比较难以实现，且需要对企业现有的业务流程进行更多根本性的变更。

3.1.1 使用增强身份治理的ZTA

增强身份治理方式使用参与者的身份作为策略创建的主要组件来开发ZTA。如果对象的请求无法访问企业资源，则无需创建访问策略。使用这种方式时，企业资源访问策略会基于身份来分配属性。资源访问的主要需求基于授予对象的访问特权。其他因素，如使用的设备，资产状态和环境等可能会影响对最终的可信等级(以及最终访问授权)的计算或以某种方式来定制结果，如基于网络位置来授权一部分到特定数据源的访问。单独资源或保护资源的PEP组件必须能够使用某种方式来将请求转发到一个策略引擎服务，或在访问授予前对对象进行认证，并批准该请求。

使用增强身份治理方式的企业会使用一个开放网络模型或使用支持外部访问的企业网络或频繁在网络上使用非企业设备(见4.3章节)。一开始会授予所有资产网络访问的权限，但仅允许拥有访问特权身份的资产访问企业资源。这种方式有一个缺点，即对恶意参与者授予基础网络连接的权限，可能会导致攻击者通过内部网络或第三方发起网络探查，以及/或服务拒绝攻击(DOS)。在请求影响到工作流前，企业仍然需要监控并对这些行为作出响应。

由于设备身份和状态为访问决策提供了辅助支持数据，因此身份驱动方式非常适用于资源门户模型(见3.2.3章节)。身份驱动方式也适用于使用基于云应用/服务的企业，这种场景下无法使用企业所有或维护的ZT安全组件(如很多SaaS)。企业可以使用请求者的身份在这些平台上构造或执行策略。

3.1.2 使用微分段的ZTA

企业可能会基于受网关安全组件保护的特定网段上的资源或资源组来实现ZTA。这种方式下，企业可能会采用如智能交换机(或路由器)或下一代防火墙(NGFWs)或专用网关设备等基础设施作为PEP来保护每个资源或相关资源组。此外，企业可能会选择使用软件代理(见3.2.1章节)或终端资产上的防火墙来实现基于主机的微分段。这些网关设备会自动对来自客户端、资产或服务的请求授予访问权限。取决于具体的模型，网关可能是单独的PEP组件或包含网关和客户端代理(见3.2.1)的多PEP组件。

该方法适用于多种场景和部署模型，因为保护设备充当PEP，管理管理设备的组件充当PE/PA。这种方式需要一个身份治理程序(IGP)来发挥完整功能，同时需要依赖一个网关组件作为PEP来阻止未授权的资源访问。

这种方式关键是需要一个PEP组件，并且可以根据需要作出反应和重新配置来响应工作流中的威胁或更改。可以通过(不那么高级的)网关设备甚至无状态网络来实现微分段的部分特性，但管理成本和难以快速适应变化使之成为一个非常糟糕的选择。

3.1.3 使用网络基础设施和网络定义周边(SDP)的ZTA

最后一种方式是使用网络基础设施来实现ZTA。可以使用一个overlay网络(7层，但也可以低于OSI网络栈)来实现ZTA。这些方式有时候称为软件定义周边(SDP)，且经常会涉及软件定义网络(SDN)[SDNBOOK]和基于意图的网络(IBN) [IBNVN]的概念。在这种方式中，PA作为网络控制器，负责根据PE的决策来配置和重配置网络。客户端通过受PA组件管理的PEP(继续)进行请求访问。

当在应用网络层(即7层)实现这种方式时，最常见的部署模型是代理/网关(见3.2.1章节)。在这种实现中，代理和资源网络(作为由PA配置的单个PEP)之间会创建一条安全通道，用于客户端和资源的通信。此外还有其他变种模型，如云虚拟网络，基于非IP的网络等等。

3.2 部署变种的抽象架构

上述所有组件都是逻辑组件，它们不需要部署到独立的系统上。单个资产可以担任多个逻辑组件的职责，类似地，一个逻辑组件也由多个硬件或软件元素来执行此类任务。例如，一个企业管理的PKI可能由一个负责签发设备证书的组件和一个用于签发终端用户证书的组件构成，但这两个组件都使用了相同的企业根证书机颁发的中间证书。目前市场上可用的ZT产品中的PE和PA组件被包装在一个单独的服务中。

后续章节给出了选中的架构组件的一些部署方式。取决于企业网络的配置方式，在一个企业中，可能在不同的业务流程中使用不同的ZTA部署模型。

3.2.1 设备代理/基于网关的部署

在这种部署模型中，PEP被划分为两个组件，位于资源上或作为一个资源前面的组件。例如，每个企业颁发的资产都有一个用于协调连接的设备代理，且每个资源前面都有一个组件(即网关)，这样资源仅需要与网关进行交互即可，本质上它是资源的代理。代理是一个软件组件，为了对请求进行评估，需要将一些(或全部)流量定向到合适的PEP。网关负责与策略管理器进行通信，确保仅批准由策略管理者配置的通信路径(见图3)。

典型场景中，当一个使用企业颁发的便携式电脑的对象需要连接到企业资源(如人力资源应用/数据库)时，首先由本地代理处理请求，并将其转发给策略管理器。策略管理器和策略引擎可能是一个本地资产或云服务。策略管理器将请求转发给策略引擎进行评估。如果该请求被授权，则策略管理器会通过控制面，在设备代理和相关的资源网关之间建立一条通道。整个过程可能需要一些信息，如IP地址、端口信息、会话密钥或类似的安全部件等。然后，设备代理和网关会对应用/服务的数据进行加密。当流程结束或策略管理器触发了安全事件(如会话超时、重认证失败等)时，会断开设备代理和资源网关之间的连接。

该模型适用于具有健壮的设备管理程序以及可以通过网关来连接离散资源的企业。对于大量使用云服务的企业，它是Cloud Security Alliance (CSA) Software Defined Perimeter (SDP) [CSA-SDP]的客户端实现。这种模型也同样适用于哪些不想使用BYOD策略的企业。只能通过设备代理进行访问，设备代理可以置于企业所有的资产中。

3.2.2 基于飞地的部署(Enclave-Based Deployment)

该部署模型是上述代理/网关模型的变种。在这种模型中，网关组件可能不位于资产之上或单独的资源前面，而位于资源飞地(数据中心所属范围)的边缘(见图4)。通常这些资源会服务单个业务功能，有可能不会直接与网关进行通信(如，历史遗留的数据系统可能不存在与网关通信的接口)。这种部署模型比较适合在单个业务流程(如用户通知、数据库查找、薪资支付等)中使用云服务的企业。在这种模型中，整个私有云都放到了网关之后。

这种模型也可以与代理/网关模型混用，此时，企业资产中包含用于连接飞地网关的设备代理，但使用了相同的基本代理/网关模型来创建连接、

该模型适用于具有历史遗留应用或无法在本地数据中心中使用独立的网关的企业。这些企业需要健壮的资产和配置管理程序来安装/配置设备代理。缺点是网关可以防护一组资源，但无法防护每个资源，这可能会让对象看到他们无权限访问的资源。

3.2.3 基于门户的资源部署

在这种部署模型中，PEP是一个独立的组件，作为网关处理对象请求。网关门户可以用于一个单独的资源，也可以作为(用于一个业务功能的)资源集的安全飞地。例如，可以在私有云或包含历史遗留应用的数据中心中使用网关门户，见图5。

相比其他模型，这种模型的好处是，不需要在所有客户端设备上安装软件组件。同时在BYOD策略和内部组织协作项目中采用这种模型也更加灵活。企业管理员不需要事先保证每个设备都安装了合适的设备代理，但可以通过设备请求访问推断出有限的信息。这种模型仅可以在连接到PEP门户时对资产和设备进行扫描和分析，但无法对恶意软件、未打补丁的漏洞以及配置持续进行监控。

这种模型的最大不同点在于它没有本地代理来处理请求，因此企业可能无法具有全面的可见性以及对资产的整体把控(因为其只能在连接到门户时才能看到并对资产进行扫描)。由此，企业可能会采取一些措施来缓解或补偿该问题，如隔离浏览者。企业可能无法观察到会话涉及到的资产。该模型也允许攻击者发现并尝试访问门户，或对门户发起DoS攻击，因此门户系统应该具备一定的防DoS攻击或网络中断的功能。

3.2.4 设备应用沙盒

代理/网关部署模型的另一种变体是在资产之上分块运行经过审核的应用或流程。这些组件可能是虚拟机、容器或其他实现，但目的是相同的：防止应用或应用实例受到资产上易感染的主机或其他应用的威胁。

在图6中，对象设备在沙盒中运行着经过审批和审核的应用。应用可以通过PEP来请求访问资源，但PEP可能会拒绝来自该资产之上的其他应用的请求。在该模型中，PEP可能是一个企业本地服务或云服务。

该变种模型的主要好处是，其将单独应用与资产上的其他应用进行了分割。如果无法对资产漏洞进行扫描，那么沙盒应用也可能会抵御主机资产上潜在的恶意软件的影响。该模型的一个缺点是，企业必须维护所有资产上的沙盒应用，且可能无法对客户资产完全可见。此外，企业还需要保证每个沙盒应用是安全的，这可能要付出比简单监控设备更多的努力。

3.3 信任算法

对于一个部署了ZTA的企业，认为将策略引擎认为是其大脑，PE的信任算法是其主要的思维过程。策略引擎会使用信任算法(TA)来最终授予或拒绝对资源的访问。策略引擎会从多个源获取输入(见第3章节)：包含对象信息、对象属性和角色、历史对象行为模型、威胁情报来源以及其他元数据源的策略数据库。该过程可以分为图7展示的几类。

在上图中，可以根据提供给信任算法的内容，将输入分为如下几类：

每个数据源的重要性可能通过专有算法或企业进行配置。这些加权值可以用来反应数据源的对企业的重要性。

然后将最终决定提交给PA执行。PA的任务是配置必要的PEPs来保证授权通信。取决于ZTA的部署方式，该过程可能会涉及将认证结果和连接配置信息发送给网关和代理或资源门户。根据策略要求，PAs可能会通过保持或暂停一个连接会话来对连接进行重认证或重授权。PA也会根据策略(如超时、工作流结束以及安全告警等)来(发出命令)终止连接。

3.3.1 信任算法变种

有多种方式来实现一个TA。不同的实现可能根据因素的重要性进行权衡。有两种主要的特性来区分TA。第一种是如何对因素进行评估，是作为二元决策还是作为整体"得分"或置信级别的加权部分。第二种是如何根据同一对象、应用/服务或设备的其他请求来评估请求。

上述两种因素并不总是相互依赖的。有可能一个TA给每个对象和/或设备分配一个置信等级，但仍然会独立评估每个访问请求(即 单一的)。但上下文和基于得分的TA会提供更动态和颗粒度的访问控制(由于基于得分的TA为请求账户提供了当前的置信级别，相比人工配置的静态策略，可以会更快地适应不断变化的因素)。

理想情况下，一个ZTA信任算法应该是上下文的，但基础设施组件总是对企业可见。一个上下文TA可以缓解在攻击者对受损对象帐户或内部攻击保持接近“正常”访问请求集的状态下造成的威胁。在定义和实现一个信任算法时，需要在安全、可用性和成本效益之间作权衡。当对象的行为与历史趋势不一致时，持续提示对象进行重认证，并在组织中规范其任务功能和角色，但同时也可能会导致可用性问题。例如，如果一个HR部门的员工通常一天会访问20到30个员工的记录，但如果一天内的访问超过100条记录，一个上下文TA可能会发送告警。如果某个人在工作时间之外执行了访问请求，则上下文TA可能会认为攻击者在使用一个受损的HR账户侦察记录，并发出告警。这是上下文TA可以探测出攻击，但单一TA无法探测的例子。在其他例子中，一个会计师通常会在正常上班时间内访问金融系统，但现在半夜且在一个未知的位置尝试访问系统，上下文TA可能会触发告警并要求对象满足更严格的置信级别或其他NIST Special Publication 800-63A [SP800-63A]描述的准则。

需要对给每个资源设置的准则或权重/阈值进行规划和测试。企业管理员可能在一开始实现ZTA时遇到问题，如可能会因为错误配置导致拒绝本该被批准的访问请求。因此需要在部署时加入"优化"阶段，对准则或得分权重进行调整，来保证策略的执行不会影响企业的业务流程正常运作。此优化阶段的持续时长取决于企业定义的进度指标和对工作流中使用的资源的不正确访问的拒绝/批准的容忍度。

3.4 网络/环境组件

在一个ZT环境中，应该区分用来控制和配置网络和应用/访问的通信流和用来执行组织实际工作的通信流。通常会将其分为用于控制通信的控制面和用于应用/服务通信流的数据面。

各种基础设施组件(包括企业所有的和服务商提供的)会使用控制面来对资产进行维护和配置。通过判定、授权或拒绝资源访问，以及执行必要的操作来设置资源之间的通信路径。而数据面则用于实际软件的通信。在控制面创建通信路径之前，有可能无法使用数据面通信通道。例如，PA和PEP有可能使用控制面来配置对象和企业资源的通信路径，然后应用/访问负载就可以使用建立好的数据面路径。

3.4.1 ZTA的网络要求

  1. 企业资产使用基本的网络互联：局域网(LAN)提供了基本的路由和基础设施功能(如DNS)。远端企业资产可能不会使用所有的基础设施服务。
  2. 企业必须能够识别企业所有或由企业管理的资产，以及设备的当前安全态势：使用企业签发的凭据来识别资产，且不能使用无法认证的信息(如网络MAC地址)。
  3. 企业能够观察到所有的网络流量：企业应该记录看到的数据面的报文(即时无法在应用层上对所有数据包执行检查)。企业需要过滤关于连接(即目的、时间、设备身份等)的信息来动态更新策略并在PE评估访问请求时通知PE。
  4. 不能在未访问PEP的前提下允许访问企业资源：企业资源不能接收来自互联网的任意入站连接。只有在客户端经过认证和授权之后才能接收自定义配置的连接。由PEP来设置这些连接路径。如果没有访问PEP，则有可能无法发现资源。这样做可以防止攻击者通过扫描和/或对位于PEPs后面的资源发起DoS攻击。注意，并不是所有的资源都需要使用这种方式进行隐藏，有些网络基础设施组件(如DNS服务)必须是可访问的。
  5. 数据面和控制面是逻辑隔离：一个网络上的策略引擎、策略管理器和PEPs组件之间是逻辑隔离的，且不能被企业资产和资源直接访问。数据面用于应用/服务的数据流量。策略引擎、策略管理器和PEPs使用控制面来进行通信并管理资产之间的通信路径。PEPs必须能够同时发送到和接收来自数据面和控制面的消息。
  6. 企业资产需要能够访问PEP组件：企业对象必须要能够访问PEP组件来获取到资源的访问权限。可以通过企业资产上的前端门户、网络设备或软件代理来启用连接。
  7. PEP是作为业务流的一部分，可以访问策略管理器的唯一组件：企业网络上运作的每个PEP都有一条到策略管理器的连接，用于给客户端和资源建立连接。所有的企业业务流程必须通过一个或多个PEP来处理流量。
  8. 远程企业资产应该可以在不通过企业网络基础设施的前提下访问企业资源：例如，一个远程对象不应该使用一条到企业网络的连接来访问被企业使用、但由公有云供应商托管的服务(如email)。
  9. 用于支持ZTA访问决策流程的基础设施应具有可扩展性，并考虑到流程负载的变化：ZTA中使用的PE(s)、PA(s)和PEPs是所有业务流程的核心组件。无法连接到PEP(或PEP无法连接PA/PE)或到PEP的连接出现了延迟都会对业务流程的执行造成负面影响。实现ZTA的企业需要考虑到组件的过载以及在需要时对基础设置进行扩容来满足不断增长的使用场景。
  10. 由于策略或观察到的因素，企业资产可能无法连接到特定的PEPs：例如，可能有一条策略，其表明，如果当请求的设备来自非企业所在的国家时，拒绝来自移动设备的资源访问。这些因素可能基于位置(物理或网络位置)、设备类型或其他准则。

4 部署场景/使用场景

记住，在任何企业环境下都可以设计零信任准则。大多数组织已经在其企业基础设施或在实现信息安全和恢复策略以及最佳实践的过程中实现了零信任的一部分元素。一些部署场景和使用场景下更倾向于使用零信任架构。例如，ZTA源于地理上分布和/或劳动力流动性高的组织中。也就是说，任何组织都可以从零信任架构中获得好处。

在下面使用场景中，并没有明确指明ZTA，这是因为企业倾向于同时使用基于周边和ZTA的基础设施。正如在7.2章节中讨论的，企业很可能会在一段时间内同时存在ZTA组件和基于周边的网络基础设施。

4.1 使用"卫星设施"的企业

企业最常见的场景是其有一个总部，以及一个或多个地理上分散的分部，且无法通过企业所有的物理网络进行连接(见图8)。远程位置的员工可能无法使用完全由企业所有的本地网络，但仍然需要访问企业资源来完成任务。企业可能会使用到企业总部网络的多协议标签交换(MPLS)连接，但不保证为所有的流量分配足够的带宽，或可能不希望将发送给基于云的应用/服务的流量经过企业总部网络。

类似地，员工可能使用企业所有的或个人所有的设备在进行远程办公。这种场景下，企业可能会授予部分资源(如员工日程、email等)，并拒绝到或限制到更多敏感资源(如HR数据库)的访问。
在这种使用场景下，PE/PA(s)通常会作为云服务(通常会提供更高的可用性，且不会要求远程员工依赖企业基础设施来访问云资源)托管，终端资产具有已安装的代理(见3.2.1章节)或访问资源门户(见3.2.3章节)。将用于远程办公的PE/PA(s)部署在企业本地网络可能并不是响应最迅速的，且员工必须将流量发送回企业网络才能访问云服务托管的应用/服务。

4.2 多云和云到云的企业

越来越常见的场景是，企业使用多云供应商来部署ZTA。这种使用场景中，企业会使用一个本地网络，并使用一个或多个云服务供应商来托管应用/服务和数据。有时候，应用/服务被托管在域数据源分开的云服务上。为了性能和方便管理，在云供应商A上托管的应用应该能够直接连接到云供应商B上托管的数据源，而无需强制应用通过隧道进入企业网络。

这种使用场景是CSA的软件定义周边(SDP)规范[CSA-SDP]的服务到服务的实现。当企业转而使用更多的云托管应用和服务时，依赖企业周边来实现安全的方式将变成一种负担。正如在2.2章节中讨论的，ZT原则采用的观点是，企业所有或维护的网络基础设施和由其他服务供应商所有和维护的基础设施并没有什么不同。多云的零信任方法会将PEP放到每个应用/服务和数据源的入口位置。PE和PA可能位于云内或第三方云供应商之上。客户通过门户或本地安装的代理就可以直接访问PEPs。使用这种方式，在使用企业外部托管的情况下，企业仍然可以管理到资源的访问。同时存在的挑战是，不同的云供应商有其特定的方式来实现类似的功能，企业架构师需要了解如何在使用的云供应商之上来实现企业ZTA。

4.3 具有合同服务和/或非员工访问权限的企业

另一种常见的场景是，现场来访者和/或合同服务供应商需要有限地访问企业资源来完成其工作(见图10)。例如，企业有其内部的应用/服务、数据库和资产，它们与供应商之间有服务合同，供应商偶尔会在现场提供维护支持(如，由外部供应商所有和管理的智能加热和照明系统)。这些来访者和服务供应商需要连通网络来执行其任务。一个零信任企业可能会在因此企业资源的前提下，允许这些设备和上门服务技术人员访问互联网。

在上例中，企业有一个支持来访者与员工交互的会议中心，同样，使用SDP的ZTA方法，员工设备和对象是不同的，可以适当访问企业资源。来访者可以访问企业园区网络，但不能访问企业资源，甚至无法通过网络扫描发现企业服务(即防止网络探测/网络漫游)。

在这种使用场景中，可能将PE(s) 和PA(s) 托管到云服务或放到LAN上(假设很少或基本不会用到云托管服务)。企业资产可能安装代理(见3.2.1章节)或通过门户来访问资源(见3.2.3章节)。PA(s)保证所有的非企业资产(没有安装代理或没有连接到门户的资产)无法访问本地资源，但可能可以访问互联网。

4.4 跨企业边界的协作

第四种使用场景是跨企业进行协作。例如，有一个涉及企业A员工和企业B员工的项目(见图11)。这两个企业可能是不同的联邦机构(G2G)，甚至一个是联邦机构，另一个是私企(G2B)。企业A会操作项目的数据库，但必须允许其访问企业B的特定数据。企业A可能会设置特定的账户来让企业B的员工访问所需要的数据，并拒绝对其他资源的访问，但这种方式很快就会变得难以管理。将两个组织都注册到联邦ID管理系统可以更快地建立这些关系，前提是两个组织的PEP都可以在联合ID社区中对主题进行身份验证。

这种场景类似场景1(4.1章节)，两个企业的员工可能不位于其组织的网络基础设施之上，且他们需要访问的资源可能位于其中一个企业环境或托管的云上。这意味着，基于企业A 的访问策略，就不需要配置复杂的防火墙或企业范围内的访问控制列表(ACL)来允许企业B的特定IP地址访问企业A的资源。如何实现这种访问取决于使用的技术。类似场景1，作为云服务托管的PE和PA可能在不建立VPN或类似通道的前提下向各方提供可用性。企业B的员工可能被要求在其资产上安装软件代理，或通过网络网关(3.2.3章节)来访问需要的数据资源。

4.5 使用公共或面向客户服务的企业

很多企业的一个常用特性是具有面向公共的服务，这种服务可能会也可能不会要求用户进行注册(即，用户必须创建或获得一组登录凭据)。这类服务面向一般的公众、与现有业务关系有关的一组客户或特定的非企业用户组，如员工家属。在所有场景中，请求的资产可能不是企业所有的，且企业在内部网络安全政策的实施方面也会受到限制。

对于一个不需要凭据访问的面向公共的资源来说，不需要直接使用ZTA原则。企业不能严格控制请求资产的状态，且不需要凭据来访问匿名的公共资源(如公共网页)。

企业可能会为注册的公共用户(如具有业务关系的客户)和特定的用户(如员工家属)建立策略。如果用户需要生成或颁发凭据，企业可能会制定有关密码长度、生命周期和其他细节的策略，并提供可选或必要的MFA。但也限制了企业可以为这类用户实现的策略。入站请求的信息可能被用来确定公共服务的状态以及探测可能的来自伪装成合法用户的攻击。例如，当一个用户注册到一个用户门户后，就可以使用某个通用网络浏览器进行访问。当来自未知的浏览器类型或已知过时版本的访问请求突然增加时，就表示有可能出现了某种自动攻击，企业可以采取相应的动作来限制这些来自特定用户的请求。企业还应该了解关于可以收集和记录哪些请求用户和资产的信息的法规或条例。

5 与零信任有关的威胁

没有企业可以消除安全风险。在现有网络安全策略和指导、身份和访问管理、持续监控以及一般网络清洁（指通过使用特殊软件、选择难以破译的密码等保护网上电脑信息的做法）的补充下，合理实现和维护ZTA可以降低整体风险并抵御常见的攻击。然而，在实现ZTA时，一些威胁具有独特的能力。

5.1 对ZTA决策流程的破坏

在ZTA中，策略引擎和策略管理器是整个企业的核心组件。除非经过PE和PA的批准和配置，否则企业资源之间不应该建立通信。这意味着，这些组件必须进行合理的配置和维护。配置了可以访问PE规则的企业管理员有可能会执行不批准变更，或有可能因为失误而破坏企业的运营。同样，一个泄露的PA可能会允许访问某些未经批准的资源(如遭到破坏的个人所有设备)。对这类威胁的缓解意味着必须要合理配置和监控PE和PA组件，且所有配置变更都必须记录日志和接受审计。

5.2 DoS或网关中断

在ZTA中，PA是资源访问的核心组件。企业资源不能在没有PA允许和(可能的)配置的前提下进行互联。如果一个攻击者对PEP(s)或PE/PA进行了中断或拒绝访问(如DoS攻击或路由劫持)攻击，则有可能对企业的运营产生负面影响。企业可以通过在安全可靠的云环境中实施策略或按照网络弹性指南 [SP 800-160v2]将策略复制到多个位置来缓解这种威胁。

上述方式可以缓解风险，但无法消除风险。像Mirai这样的僵尸网络会针对主要的互联网服务供应商执行大量DoS攻击，中断给上百万互联网用户提供的服务。攻击者还有可能会拦截和阻塞企业中到PEP或PA的部分或所有用户账户(如分部或某个远程员工)的流量。这些场景下，只有一部分企业对象会受到影响(可能包括历史的远程访问VPN，不仅限于ZTA)。

一个托管的供应商偶然情况下可能会导致基于云的PE或PA下线。在过去，云服务的IaaS和SaaS都经历过中断事件。如果无法通过网络访问策略引擎或策略管理器组件，则一个操作错误就有可能导致企业无法正常运作。

还有一个风险，即PA可能无法访问企业资源，因此即使授予了对象访问权限，PA也无法通过网络来配置通信路径。这可能是由于DoS攻击或使用量过大导致的。这与其他网络中断类似，此时部分或所有企业对象由于某种原因而无法访问特定的资源。

5.3 凭据窃取/内部威胁

合理实现ZT、信息安全和恢复策略以及最佳实践可以降低攻击者通过窃取凭据或内部攻击造成的威胁。ZT中，不根据网络位置给予隐式信任的准则意味着攻击者需要通过泄露的账户或设备来在企业中找到立足点。合理部署和实现ZTA可以防止泄露的账户或资产访问超出其权限范围内或访问模式下的资源。这意味着攻击者的首要目标是与资源有关的，且具有相关访问策略的账户。

攻击者可能会通过钓鱼攻击、社交工程或组合攻击来获取有价值的账户的凭据。"有价值"的含义与攻击者的意图有关。例如，企业管理员账户可能是有价值的，但攻击者更关心财务收益，因此那些可以访问金融或支付资源的账户更具有价值。为访问请求实现MFA可能可以降低账户泄露造成的信息丢失的风险。然而，使用有效凭据的攻击者(或恶意的内部人员)可能可以使用授予该账户的权限进行访问。例如，一个具有有效人力资源员工的凭据或(企业所有)资产的攻击者或恶意员工可能仍然能够访问员工数据库。

ZTA降低了风险，并防止泄露的账户或资产在整个网络中漫游。如果没有授予某个泄露的账户访问特定资源的权限，则可以继续拒绝对该资源的访问。此外，相比发生在遗留的、基于周边的网络中的账户泄露，ZTA可以使用一种上下文信任算法(第3.3.1章节)来探测并快速响应该账户的请求。上下文TA可以检测到访问模式超出一般的行为，并拒绝该泄露的账户或来自内部的威胁对该资源的访问。

5.4 网络可见性

正如在3.4.1章节中提到的，需要检查并记录网络上的所有流量，然后通过分析来确定并对可能的企业攻击做出反应。然而，一些(有可能是大部分)企业网络上的流量对L3层网络分析工具是不透明的。流量可能来自于非企业所有的资产(如使用企业基础设施访问互联网的合同服务)或拒绝被动监控的应用/服务。无法执行深度报文分析或检查加密流量的企业必须使用其他方式评估网络上可能存在的攻击者。

这并不意味着企业无法分析其看到的加密流量。企业可以采集加密流量的元数据(如源和目的地址等)，并使用这些信息来探测网络上活动的攻击者或可能的恶意软件通信。可以使用机器学习技术来分析那些无法解密和检查的流量。企业可以引用机器学习来将流量分为有效的或恶意的流量，并对后者采取相应的补救措施。

5.5 系统存储和网络信息

与企业监控和网络流量分析有关的威胁就是分析组件本身。如果使用存储的监控器扫描的网络流量和元数据来构建上下文策略，进行预测或用于其他分析，这些数据就可能会变为攻击者的目标，因此需要保护网络图、配置文件和其他类型的网络架构文档等资源。如果一个攻击者可以成功访问到这些信息，他们可能会进一步洞察到企业架构，并识别出后续侦察和攻击的资产。

ZT企业中的攻击者可能会侦察的另一个信息是用于编码访问策略的管理工具。就像存储的流量一样，该组件包含了到资源的访问策略，攻击者借此可以了解到哪些账户最有价值(如，可以访问目标数据源的账户)。

对于所有有价值的企业数据，应该将防护重点放到阻止未授权的访问(和未授权的访问尝试)。由于这些资源的安全性很高，因此它们应该具有最严格的访问策略，且只能被指定的或专有的管理员账户访问。

5.6 依赖专有数据格式或解决方案

ZTA依赖多种不同的数据源来作决策，涉及到的信息包括请求对象、使用的资产、企业和外部情报以及威胁分析等。通常会使用资产来存储这些信息，且对信息的交互并没有一个通用的、开发的标准。这可能导致企业由于互操作性问题而被供应商锁定。如果一个供应商有一个安全问题或出现业务中断，则该企业有可能无法在不付出极端支出(例如，替换部分设备)或不经历漫长过渡过程(例如从一种特定格式的策略规则转换为另一种格式的策略格式)的前提下迁移到一个新的供应商。像DoS攻击，这类风险并不仅限于ZTA，只是因为ZTA严重依赖动态访问信息(企业和服务供应商)，中断的发生可能会影响到一个企业的核心业务功能。为了缓解相关的风险，企业应该对服务供应商进行全面评估，可考虑的因素除性能和可靠性外，还应该考虑供应商安全控制、企业转换成本和供应链风险管理等。

5.7 在ZTA管理中使用非个体实体(NPE)

可以在企业网络中部署人工智能和其他基于软件的代理来管理安全问题。这些组件需要与ZTA管理组件(如策略引擎、策略管理器)进行交互(有时候会代理人类管理员)。如何在一个实现ZTA的企业中对这些组件本身进行认证是一个开放性的问题。大多数自动化技术系统在使用API为组件提供资源时，会使用某种方式进行身份验证。

使用自动化技术进行配置和策略执行中存在的最大风险是，有可能将企业的安全态势误报为假阳性(将无害行为误认为是攻击的)和假阴性(将攻击误认为是正常活动的)，可以通过定期重新分析来纠正决策偏差并提升策略流程。

攻击者有可能会诱导或强迫一个NPE来执行一些攻击者无特权的任务。相比人类用户来说，在管理或与安全有关的任务层面，软件代理的认证标准(例如，API密钥与MFA)可能会比较低。攻击者可以与代理进行交互，理论上可以通过欺骗代理来获得更大的访问权限，或代表攻击者执行某些任务。攻击者还有可能获取到可以访问软件代理的凭据，并在执行任务时冒充代理。

6 零信任架构和与现有联邦指导的互动

略

7 迁移到零信任架构

相比于基础设施或流程的批量替换，实现ZTA更像一个旅程。一个组织应该寻求使用增量的方式来实现用于保护高价值数据资产的零信任原则、流程变更和技术解决方案。大多数企业会在一段不确定的时间内继续使用零信任/基于周边的混合模型，同时继续投资正在进行的IT现代化转型。如果IT现代化计划中囊括了转向基于ZT原则的架构，则可能帮助企业形成小规模工作流迁移的路线图。

企业如何迁移到一个战略取决于当前的安全态势和运作方式。在部署以ZT为中心的环境之前，企业应该达到ZT的能力基线[ACT-IAC]。该基线包括企业能够对资产、对象、企业流程、流量流以及相关依赖进行识别和分类。企业会在开发一系列候选的业务流程以及该流程中涉及的对象/资产前用到这些信息。

7.1 纯零信任架构

在绿地方式(指全新的环境)中时，可以从头开始构建零信任架构。假设企业知道其需要在流程中运作的应用/访问，就可以基于零信任原则来为这些流程生成架构。一旦确定了流程，企业就可以缩小所需要的组件，并确定各个组件如何进行交互。到此为止，后续就需要靠工程和组织经验来构建基础设施以及配置组件。取决于企业的当前配置和运作方式，可能会包含额外的组织变更。

实践中，对于联邦机构或其他组织来说，很难在现有的网络上行得通。但有时候会要求组织履行新的职责，这需要构建自己的基础设施。这些场景中，可以引入一定程度的ZT概念。例如，一个代理可能履行构建一个新的应用、服务或数据库的新职责。此时，可以围绕ZT原则和安全系统工程[SP8900-160v1]来为代理设计新的基础设施，如在授权访问和围绕新资源建立微边界前，需要评估对象的信任度。新基础设施的成功度取决于该设施对现有资源(如ID管理系统)的依赖程度。

7.2 混合ZT和基于边界的架构

并不是所有企业都可以在一轮技术刷新周期中迁移到零信任。当企业中的ZTA需要与非ZTA流程协作时，将无法确定其迁移周期。在迁移到ZTA方法的过程中，企业可能一次只迁移一个业务流程。企业需要确保通用的元素(如ID管理、设备管理、事件日志等)足够灵活，能够在ZTA和基于周边的混合安全架构中正常运作。企业架构师还有可能将ZTA候选方案限制为可使用现有组件接口的方案。

将现有流程迁移到ZTA很有可能需要对部分现状进行重新设计。企业可能会借此采用安全系统工程 [SP800-160v1] 实践(如果流程中还没有采用的话)。

7.3 将ZTA引入基于周边的架构网络的步骤

迁移到ZTA需要一个组织详细了解对其资产(物理和虚拟)、对象(包括用户特权)以及企业流程。PE会使用这部分信息来对资源访问进行评估。不完整的信息通常会因PE(缺少信息而)拒绝请求而导致业务处理失败。特别是在企业中部署了"影子IT"的情况下。

在将ZTA引入企业前，应该对现有的资产、对象、数据流和工作流进行调查。这种认知形成了ZTA部署之前必须达到的基本状态。如果无法了解当前的运作状态，则企业无法确定需要引入的新流程或系统。这些调查可以并行执行，但两者都与组织业务流程的检查有关。这些步骤可以对应RMF[SP800-37]中的步骤，任何采纳ZTA的目的都是一个降低机构业务职能风险的过程。图12展示了实现ZTA的路线。

在创建初始清单之后，需要定期进行维护和更新。更新可能会也可能不会影响也会流程，但需要对业务流程进行评估。例如，在对数字证书供应商进行并更后，可能不会造成重大影响，但会涉及证书根存储管理、证书透明性日志监控以及其他一开始并不明显的因素。

7.3.1 确定企业中的参与者

为了让零信任企业运作，PE必须要了解企业的对象。对象应该围绕人和可能的NPEs，如与资源交互的服务账户。

使用特殊特权的用户，如开发者或系统管理员，当给这些对象分配属性或对象时，需要进行额外的审查。在很多历史安全架构中，这些账户可能具有访问所有企业资源的完整权限。在使用日志和审计动作来确定访问行为模式的同时，ZTA应该允许开发者和管理员具有足够的灵活性来满足其业务需求。ZTA可能会要求管理员满足更严格的置信等级或NIST SP 800-63A(第5章节 [SP800-63A] )中描述的准则。

7.3.2 确定企业所有的资产

正如2.1章节提到的，实现ZTA的关键是能够确定和管理设备。ZTA可能还需要确定并监控非企业所有的设备(这些设备可能位于企业所有的网络技术设施上，或需要访问企业资源)。能够管理企业资产是部署ZTA的关键。这包括硬件组件(如笔记本电脑、手机、IoT设备等)和数字部件(如用户账户、应用、数字证书等)。有时可能无法对企业所有的资产进行全面普查，因此可以考虑在企业所有的基础设施上构建快速确认、分类和访问新发现的资产的能力。

这不仅仅是对企业资产数据库的分类和维护，还包括配置管理和监控。对一个资产当前状态的观察能力是评估访问请求流程的一部分(2.1章节)。这意味着企业必须能够配置、调查和更新企业资产，如虚拟资产和容器，也包括其物理和网络位置。在执行资源访问决策时应该将这些信息通知给PE。

应该尽可能地对非企业所有的资产和企业所有的"影子IT"进行分类。这可能包括所有企业可见的信息(如MAC地址。网络位置)以及管理员补充的数据表项。这些信息不仅仅用于访问决策(如协作者和BYOD资产可能需要联系PEPs)，也用于企业监控和取证记录等。影子IT带来了一个特殊的问题，因为这些资源是企业所有的，但不像其他资源那样进行管理。特定的ZTA方式(大部分是基于网络的)可能会导致影子IT组件无法使用(由于无法了解到影子IT，并将其加入到网络访问策略中)。

很多联邦架构已经开始确定企业资产。那些已经建立了CDM项目能力的机构，如HWAM[HWAM] 和软件资产管理(SWAM )[SWAM]，在制定ZTA时有丰富的数据进行参考。机构也可能包含一组涉及高价值资产(HVA)[M-19-03] 的候选流程，这些HVA对机构任务至关重要。在使用ZTA设计业务流程之前需要在现有的企业或机构范围内进行此项工作。这些项目应该是可扩展的且能够适应企业的变更(不仅仅体现在迁移到ZTA时，也包括考虑成为企业一部分的新资产、服务和业务流程时)

7.3.3 确定主要流程并评估与流程执行有关的风险

机构应清查的第三项是确定并对机构任务中的业务流程、数据流和关系进行排序。业务流程应该通知在哪些环境下资源访问请求是允许或拒绝的。一个企业可能希望在首次转向ZTA时使用低风业务流程，这样业务中断不会对整个组织造成负面影响。一旦获得足够的经验，就可以将更重要的流程作为候选。

使用基于云资源或被远程员工使用的业务流程通常是比较好的ZTA候选者，更可能获得可用性和安全方面的提升。相比于从企业周边进入云或通过VPN将客户带入企业网络，企业客户可以直接请求云服务。企业的PEPs保证在资源请求授予一个客户前能够遵循企业策略。规划者还应该在性能、用户体验和为特定企业流程实现ZTA而带来的工作流上的脆弱性等方面进行权衡。

7.3.4 制定ZTA候选人的政策

确定一个候选者服务或业务流程的过程取决于多种因素：流程对组织的重要性、影响的对象组和工作流使用的资源的当前状态。资产或工作流的风险数值可以通过NIST 风险管理框架[SP800-37]进行评估。

在确定资产或工作流之后，需要确定工作流使用或影响的所有上游资源(如ID管理系统、数据库、微服务等)、下游资源(如日志、安全监控)和视图(如对象、服务账户)。这可能会影响到对首次迁移到ZTA的候选者的选择。与对整个企业对象至关重要的应用程序/服务(如电子邮件)相比，确定的企业对象(如采购系统)子集使用的应用程序/服务可能更受欢迎。

企业管理员需要决定候选业务流程中使用的准则集(如果使用了基于准则的TA)或资源的置信比重(如果使用了基于得分的TA)。管理员可能需要在调优阶段对这些准则和数值进行调节。这些参数需要保证策略的有效性，但不能妨碍对资源的访问。

7.3.5 确定候选方案

一但完成了候选的业务流程列表，就可以有一系列的候选方案。一些开发模型(3.1章节)非常适合特定的工作流和当前企业生态系统。类似地，一些供应商方案(相比其他场景而言)更适用于某些场景。下面是需要考虑的因素：

一种解决方案是将现有业务流程建模作为试点项目，而不仅仅是替代项目。该试点项目可以用于多个业务流程或特定的某种场景。在将对象转换为ZTA部署并抛弃历史流程技术设施前，可以将试点当作"试验场"。

7.3.6 初始部署和监控

一旦选择了候选的工作流和ZTA组件，就可以开始初始化部署了。企业管理员必须使用选择的组件来实现开发好的策略，但一开始有可能会使用观察和监控模式。很少企业会在第一次迭代就完成所有的策略集：有可能会拒绝一些重要的用户账户(如管理员账户)来访问资源，而这些账户可能已经被授予了访问特权。

有时为了确保策略的有效性和可操作性，新的ZT业务流程可能运行在只-报告模式。企业可以同时了解到基线资产和资源访问请求、行为和通信模式等。只-报告意味着应该为大多数请求授予访问权限，并使用连接的日志和追踪与一开始开发的策略进行比较。应该执行基本的策略，如拒绝那些由于MFA失败或已知的、攻击者控制或破坏的IP地址，并记录此次访问请求。但在一开始部署时，访问策略应该更加宽松，以便从实际的ZT工作流交互中收集数据。一旦建立了工作流的基线活动模式，就可以更容易地识别异常行为。如果无法以更宽容的方式运作，企业维护者应该仔细地对日志进行监控，随时准备基于维护经验来修改访问策略。

7.3.7 扩展ZTA

当获得足够的信心，并正确设置了工作流策略之后，企业就进入了稳定维护阶段。此时仍然需要对网络和资产进行监控，对流量进行记录(2.1章节)，但应该以较低的节奏对策略进行修改(因为它们不应该很严重)。所涉及的资源和流程的对象和相关方也应该提供反馈，以便改进运作方式。至此，企业管理员可以开始计划ZT部署的下一个阶段。与之前的推出方式一样，需要确定候选工作流和解决方案集，并制定初始策略。

然而，如果工作流发生了变更，则需要重新评估正在运作的ZT架构。系统重大变更，如新设备，软件的重大更新(特别是ZT逻辑组件)，以及组织架构的变动等，可能会导致工作流或策略的变更。实际上，应该重新考虑整个过程，并假定已经完成了部分工作。例如，采购新设备之后，此时没有创建任何用户账户，只需要更新设备清单即可。

标签：架构,ZTA,网络,访问,组件,信任,企业,资源
来源： https://www.cnblogs.com/charlieroro/p/15721579.html