Zero Trust Networks【9】
一、迈向零信任网络的第一步：了解你当前的网络
二、实施阶段：应用程序身份验证和授权
三、案例研究
四、案例研究：谷歌Beyond公司
五、案例研究：PagerDuty的云-不可知论网络
Chapter 9. Realizing a Zero Trust Network
本章将帮助读者制定一个策略，以获取前几章中的知识，并将其应用到他们的系统中。零信任网络很可能是围绕现有系统建立的，所以本章将重点讨论如何成功地实现过渡。
重要的是要记住，零信任不是一种产品，甚至不是一种可以连接到网络上的单一服务。它是一套基于网络的需求和约束而应用的架构原则。因此，本章不能提供一个要进行的更改的清单，而是提供一个如何在您自己的系统中实现零信任网络的框架。
一、迈向零信任网络的第一步：了解你当前的网络
彻底评估您的网络基础设施是一个稳健的零信任策略的基础。首先绘制出所有网络元素，包括设备、软件和数据流，以确定安全差距和适合增强的领域。对网络当前状态的全面了解是至关重要的，它提供了对潜在漏洞的见解，并告知在哪里以及如何有效地应用零信任原则。这种基本的理解对于任何安全措施与您的组织的特定需求和漏洞相一致都是必要的，这些需求和漏洞可能导致无效的防御和容易安全漏洞。最终目标是您现有网络的一个清晰的蓝图，它将指导环境中零信任的无缝集成。
1.1 选择范围
在开始建立一个零信任网络之前，选择适当的工作范围是很重要的。一个非常成熟的零信任网络将会有许多相互作用的系统。对于一个大型组织来说，构建这些系统可能是可行的，但对于一个较小的组织来说，这些系统的数量和复杂性可能会使一个零信任网络似乎遥不可及。重要的是要记住，零信任架构是一个理想的工作方向，而不是从第一天起就必须完全满足的需求列表。
这与基于周边的网络没有什么不同。不太成熟的网络最初可以选择一个简单的网络设计来减少管理的复杂性。随着网络的成熟和漏洞风险的增加，网络将需要重新设计，以进一步隔离系统。虽然零信任网络设计是一种理想的设计，但并非所有的设计特征都具有相同的价值。确定哪些组件是必需的，哪些组件是好的，这将大大帮助您确保零信任实现的成功。
1.2 评估和规划
建立一个零信任网络首先有一个坚实的基础，所以一旦你了解了范围，下一步将是评估和规划阶段。把这个阶段看作是为“永远不要信任，永远验证”的原则奠定基础。在此阶段，对当前的网络设置进行评估，确定资产，并进行差距分析，以确定过渡到零信任架构所需的步骤。网络评估有助于评估现有的网络结构，并确定与零信任原则相一致的优点、缺点和安全措施。接下来是资产识别和差距分析。资产标识包括枚举和分类网络中的所有资产，如设备、应用程序、数据存储库和云资源。最后，差距分析揭示了当前网络结构和零信任体系结构之间的差异，突出了必要的技术和政策变化。
❗拥抱零信任的本质
拥抱零信任的本质需要在您处理安全的方法上进行一个基本的范式转变。它是关于理解零信任不是一种你可以插入网络的有形产品，而是一种渗透到组织安全态势的各个方面的全面的思维方式。首先，从策略创建到日常操作，在各级灌输“永远不要信任，始终验证”原则。教育利益相关者了解持续验证和最少特权访问的重要性。其目标是培养一种积极主动的安全文化，在这种文化中，人们可以赢得信任，而不是假设信任，从而显著增强对不断演变的网络威胁的防御。记住，零信任是一种心态，而不是一种产品。其结果应该是组织文化向持续警惕和安全意识的转变。
1.3 要求：实际上需要什么？
限制零信任网络的范围必然需要对本书前面介绍的属性集进行优先级排序。这个rfc风格的优先级列表是作者对该工作应该如何被优先级的意见：
· 所有的网络流在处理前都必须经过身份验证。
· 所有的网络流在传输前都应进行加密。
· 身份验证和加密必须由网络中的端点来执行。
· 应该通过枚举所有网络流来实现系统访问。
· 在网络中应使用最强的身份验证和加密套件。
· 身份验证不应依赖于公共PKI提供商。应该使用私有的PKI系统来代替。
· 设备应定期扫描、修补和旋转
❗rfc样式优先级列表
征求意见（RFC）文件是互联网基础设施建议改革的通用语。在这些文档中，语言和结构被明确定义，以便读者更快地理解建议的更改。该语言在优先级讨论中非常有用的一个方面是RFC 2119中定义的标准术语。本RFC定义了一组术语（必须/必须不，应该/应该不应该，可能/可能不），这些术语比普通文献中的正常用法更有分量。这本书的优先级列表使用这些术语的意图与它们在RFC 2119中的定义相似。虽然体系结构特征与协议设计没有完全相同的要求，但这些标准术语的使用是为了呼应该RFC中所呈现的用法。为了完整起见，以下是在本书中使用的这些标准术语的预期定义：
此术语用于要求实现的系统与零信任设计兼容的要求。
这是必须相反的。一个打算实现零信任设计的系统需要不具有这个特性。
这个术语表示在零信任网络中所期望的架构特性，但是给定的成本约束可以被剥夺优先级。当取消此特性的优先级时，系统管理员应该意识到，他们正在用系统的安全性来降低实现它们的成本。在所有可能的情况下，系统管理员应该避免在这些特性上进行妥协，因为不妥协于这些特性的好处被认为值得付出实现它们的前期成本。
这个术语用于零信任网络的体系结构特征，它带来价值，但被认为是好的。一旦系统管理员已经构建了一个满足必须和应该满足定义的系统，他们就应该计划实现这些方面。需要注意的是，这些附加特性通过加固网络给网络带来了额外的价值，因此它们不应该被视为净损失。
有了构建零信任网络的设计需求的优先级列表，让我们深入研究为什么特定需求的分类方式。
1.4 所有的网络流在处理前都必须经过身份验证
在零信任网络中，系统接收到的所有数据包都会立即出现可疑问题。因此，在允许处理其中的数据之前，必须严格检查它们。强身份验证是我们实现这一目标的主要机制。为了获得对网络数据来源的信心，身份验证是绝对必要的。它也许是零信任网络中最重要的一个组成部分。没有它，我们就一无所有，我们被迫信任这个网络。
这本书的一个关键教训是，一个网络链接不能可靠可靠地将数据或信号从一个系统传输到另一个系统。到不安全参与者的网络链接的物理可访问性使得该网络被破坏微不足道。此外，即使在物理安全的网络中，坏人也可以通过数字方式渗透系统，被动地探测网络中寻找有价值的数据。通过在在网络上传输数据之前对设备上的数据进行加密，我们将该通信的攻击面降低到设备本身的可信度，即应用程序和物理设备的安全性。
由于零信任网络认识到信任网络链路对系统安全构成的威胁，因此在应用层端点之间建立安全通信是很重要的。添加处理这些责任的中间件组件（如VPN集中器或tls终止的负载均衡器）可能会使上游网络通信面临物理和虚拟威胁。因此，需要一个声称为零信任的系统来在网络上的每个应用层端点上实现加密和身份验证。
零信任网络依赖于定义网络预期特征的数据。因此，定义每一个预期的网络流对于保护网络至关重要的。我们应该注意地指出，枚举流并不需要繁重的变更管理控制来提供价值。定义预期流的简单流程在网络执行和变更审计方面带来了巨大的价值。如果没有预期的网络流列表，零信任系统就无法突出显示需要管理员注意或应该被拒绝的意外通信。
作者强烈认为，推迟枚举流的努力最终将导致一个被认为不可行的任务列表。作者认为，保持预期流数据库最新的最佳方法是在整个组织中分配定义这些流的责任。在分配这一责任时，组织应谨慎地教育团队关于变更管理的最佳实践，以防止对系统的内部威胁。其中一种威胁是，如果允许一个人在没有任何监督的情况下更新流数据库。一个简单的审查系统就可以减轻这种威胁。
❗流数据作为真理的来源
构建预期流的数据库最好是使流数据库成为允许该访问的数据源。通过设置此依赖关系（并不允许外部修改），流数据库将与实际允许的访问保持一致。
在捕获流时，遵循这些规则将提高数据的质量：
捕获流的预期用途以及策略详细信息（例如，负载平衡器访问——从负载平衡主机到web应用程序）。
我更喜欢狭窄定义的流，而不是广泛的访问。
零信任网络假定了一个敌对的网络环境，因此强身份验证和加密套件是零信任网络安全的一个重要组成部分。不幸的是，哪些套件提供了强大的安全性，但却发生了变化，所以这本书不能提供能够经得起时间考验的具体选择。
读者应该参考像NIST加密指南这样的安全标准来选择强密码套件。系统管理员应该始终瞄准尽可能强的套件，但设备和应用程序功能可能会限制可用套件的类型。在这些情况下，管理员应该意识到，通过降低这些套件的强度，其网络中的安全性正在受到损害。
公共PKI系统为安全通信中的非托管端点提供信任保证。证书颁发机构（CA）签署用于建立安全通信的证书。接收该已签名证书的端点能够通过将已签名的材料与系统上已经存在的受信任证书颁发机构的列表进行比较来验证其真实性。通过为系统播种受信任的公共证书颁发机构列表，端点可以与它们以前没有通信过的系统建立安全的通信通道。
考虑到公共PKI系统为建立安全通信信道提供的好处，为什么零信任网络更喜欢私有PKI系统？考虑到零信任专注于管理信任，之所以是信任第三方会增加系统的风险，这也许是不令人意外的。公共PKI系统给零信任网络带来了几个风险。
一个问题是被认为是受信任的公共ca的数量。随着互联网流量的增长，值得信任的公共ca的数量也随之增加。每一个受信任的ca都有能力签署欺诈性证书，该证书错误地断言恶意系统的可信性。证书固定可以通过告知端点对给定端点的预期证书来帮助解决这个风险，但是证书固定要求端点具有预期证书的先验知识，这提出了一个新的挑战。
使用公共CA也会带来另一个威胁。国家行动者在利用司法权迫使组织反对其向客户提供的信托保证方面变得更加积极。这些要求越来越多地使用法律，禁止相关各方披露他们的行为。
鉴于这种激进的立场，允许国家行为者进入零信任网络的信任机制应该会让系统管理员暂停。基于这些担忧，零信任网络应该优先选择私人持有的PKI系统。端点应配置为只允许由专用PKI系统签名的证书。我们在第2章中更详细地讨论了PKI。
我们在第5章中了解到，设备的安全性对于建立一个零信任网络是至关重要的。管理员需要假设网络上受信任的设备会受到损害，从而在设备管理中构建防御功能，以减轻这种威胁。为此，应该定期扫描设备，以捕获在给定的时间点在设备上运行或安装的软件。
扫描可以用来发现和防止已知的恶意软件在设备上运行，但是管理员应该在假设恶意软件预防软件（如防病毒软件）总是不完善的情况下进行操作。管理员不应该集中精力阻止恶意软件的运行，而应该集中精力构建取证功能，以便他们能够分析不可避免的恶意软件攻击的影响.
保持设备的新鲜感也非常重要。系统管理员应该计划定期安装最新的安全补丁。此外，定期的设备旋转策略将有助于确保设备不会出现故障，因为这会危及系统的安全性。
❗比起长期的扫描和修补，我更喜欢重成像
随着时间的推移，设备的可信度会降低，因为设备可能受到损害的风险会增加。定期重新成像设备，虽然破坏性，确保对舰队的信任仍然很高。目标是每季度重新成像一次服务器，每两年重新成像一次个人设备。
1.5 构建系统图
构建系统图是实现零信任网络的另一个重要步骤。在设计系统通信通道时，清楚地了解内部和外部网络通信将是有用的。系统图，如图9-1中所示的图，经常被指责为严重过时。这些图表通常是手工制作的，这需要大量的人力努力。考虑到这些图表过时的速度，人们普遍认为系统图根本不值得投资。
然而，这种观点忽略了对应该如何构建系统的以人为本的观点的好处。虽然工程师可以读取代码或询问现有的系统来确定系统是如何构建的，但这并不能洞察到这种状态是想要的还是意外的。
图9-1.像这样的图是建立零信任网络的良好起点。方向性很重要。
因此，如果系统图是有用的，但经常过时，那么自然的问题是应该在创建中投入多少时间和精力。对于现有网络来说，一个好的路径是首先观察通过网络的通信。您可以使用记录流的工具来捕获此通信。一旦捕获了流信息，生成一个系统图将是对通信类别进行分类的一个练习。
在下一节中，我们将讨论捕获和分类网络流的工具，以及将这一大量工作分解为更小的工作块的策略。
1.6 了解你的流动
网络流是源系统和目标之间的有限制的通信。当使用双向传输协议（例如，TCP）时，单个流可以直接映射到整个会话。对于单向传输协议（例如，UDP），单个流可能只捕获一个网络对话的一半。这是因为，虽然两个UDP流可能在逻辑上相关联，但网络上的观察者在没有深入了解应用程序数据的情况下可能无法进行关联。对于想要转移到零信任模型的系统来说，捕获现有生产网络中的所有流活动是合乎逻辑的第一步。
长时间记录网络中的日志流是一种非侵入性的发现网络连接存在的方法，应该在新的安全模型中加以考虑。如果没有这种预先的信息收集，转向零信任模式的努力将导致频繁的网络通信问题，导致项目被认为过于具有侵入性和破坏性。
❗发现流的方法
要进行日志记录和分析网络流，有许多不同的机制。使用哪些系统将在很大程度上取决于正在运行的网络类型（物理的或虚拟的）以及管理员对端点的访问级别。在这本书的写作中，这里有一些流行的和被广泛认为的捕获流的工具：
线鲨仍然是一个强大的和广泛使用的网络协议分析器。它允许您捕获并交互式地浏览在计算机网络上运行的流量。
这以其网络遥测技术和复杂的分析技术而闻名。它利用从现有的网络基础设施中获得的企业遥测技术来进行高级的威胁检测、行为建模和安全的网络可见性。
这是一个实时带宽监控工具，它依赖于NetFlow、sFlow和Cflow等流技术来创建全面的系统图和流量分析。
这为增强对网络流量的可见性提供了流分析。它通过分析来自各种流协议的数据来帮助创建详细的系统图。
Datadog的解决方案允许您实时可视化网络流，使其更容易地绘制系统图和理解各种网络组件之间的交互。
太阳风公司提供全面的网络流量监测和分析。它可以通过使用NetFlow、Jflow、sFlow等工具跟踪流数据，从而帮助创建系统图。
这些工具可以用于记录流和创建系统图，这对于实现和管理零信任网络至关重要。它们提供了必要的可见性和分析功能，以理解网络行为，并确保安全操作。物理网络具有访问通过网络流动的原始数据包的丰富能力。业务类交换机通常能够将数据包镜像到交换机上的第二个端口（称为空间交换机端口分析器—或镜像端口）。这种方法在轻负载的交换机上启用是相对安全的，但它会掩盖网络中某些类型的错误。TAP（测试接入点）设备，将保证所有数据被传输到监控设备。为了发现网络中的逻辑流，任何一种方法都可以工作。
虚拟化网络可能有能力检查网络流量，但它们通常在较粗的级别上运行。例如，Amazon Web服务有一个记录网络中的每个流的特性，可以用来分析其系统上的流量（图9-2）。虽然通过网络结构发现流可以对正在流动的流量提供完美的可见性，但如果没有端点监控系统，将分析绑定回单个应用程序是很困难的。在对端点的控制是可行的情况下，发现端点本身上的网络流可以提供关于系统中流量源的更详细的视图。
以仅日志模式运行的软件防火墙可以成为在不影响通信的情况下发现系统中的流的有用工具。在Linux端点上，有几种方法可以发现和编目网络流，HaraldWelte的论文《基于流的网络核算》捕获了这些方法。
图9-2.一些云提供商内置了流日志记录功能；这是AWS流日志功能的屏幕截图
在记录了所有的网络流后，下一个目标是基于更高级别的系统连接对流进行分类。这些连接应该在逻辑系统级别上定义，而不是在单个的IP/端口级别上定义。本练习所定义的连接是非常有价值的数据。有了这些定义，人们就能够更好地加强已知的连接，并了解网络内通信模式的变化。由于一个安全网络的许多操作都可以从这个连接的数据库中派生出来，所以很明显，捕获这个映射是非常有用的。对于一个非常大的网络来说，捕获和分类所有的网络流可能是一项巨大的任务。一个自然的问题是，捕获所有网络连接是否是过渡到零信任网络的要求。
幸运的是，一个零信任网络可以在现有的基于周长的系统中逐步实现。人们可以利用现有的边界或网络边界在边界的两侧构建一个零信任网络。零信任模型可以从图9-3所示的一个区域扩展到另一个区域，增强现有系统的网络安全，同时保持已经到位的操作安全措施。
图9-3.零信任采用可以逐区域移动，提供远离传统周边体系结构的简单迁移路径
1.7 微分割
微分割是实现零信任网络的基本基石，它涉及到将网络划分为更小、更易于管理和安全的区域，允许组织对网络不同部门之间的交互和数据流进行精确控制。这种控制水平的控制是体现零信任原则的关键，零信任原则强调验证而不是盲目信任。
它确保每个网络段都遵循严格的访问和安全策略，而不管整个网络环境如何。
根据美国国家标准与技术研究所（NIST）的规定，微分割的能力包括：
· 由于路段被隔离且相对较小，可以密切监控交通。
· 上述功能的结果是，通过定义相关的策略，可以实现粒度访问控制。
在当今日益增长的威胁环境中，微分割是降低威胁在网络内传播的风险的关键。通过将漏洞隔离到特定的部分，可以防止它们传播并造成更广泛的妥协。随着组织越来越多地采用混合和多云架构，微分割提供了一种结构化的方法来在一个统一的框架内管理和保护不同的网络环境。
1.8 软件定义的周边
软件定义的周长（SDP）架构的目标是提供逻辑上有空气间隙的、动态供应的、按需的网络，这些网络与不安全的网络隔离，并抵抗常见的基于网络的攻击。通过在默认情况下启用全删除防火墙，SDP在允许用户或设备访问SDP系统隐藏的资产之前，需要进行身份验证和授权，从而增强了安全性。此外，通过强制连接预审查，SDP将限制所有连接到可信区域的连接，这取决于谁可以连接、从哪些设备、哪些服务和基础设施，以及考虑其他因素。SDP是实现零信任体系结构的有用技术，是近年来研究的热点。有关该主题的更全面的指导，请参阅云安全联盟发布的“集成SDP和DNS：增强的零信任策略执行”。
一个完全成熟的零信任网络的核心将是几个提供关键安全服务的控制飞机系统。虽然拥有这些系统是理想的，但在最初使用公共基础设施系统时，可以迭代到理想的部署。我们现在将探索其中的一些系统。
许多操作上成熟的组织使用配置管理工具来管理他们的基础设施。当使用这些系统时，将捕获所需的配置状态并控制版本。在检查了系统的当前状态之后，配置管理系统使用此所需的配置来计算将使系统达到所需状态的修改。使用配置管理工具比人类执行的计划更改带来许多好处：
· 对系统的更改将在整个车队中一致地应用。
· 配置数据可以存储在版本控制系统中，该系统提供了有关所进行的更改及其原因的有用记录。
· 配置漂移不太可能发生，因为它的状态是由配置管理系统来管理的。
通常部署配置管理的第一种方法是管理各个计算机的配置。系统从一个已知的空白板机（通常只是操作系统的初始安装）开始，然后根据该机器在基础设施中的角色重新配置到所需的状态。通过使这个过程自动化，可以很容易地替换基础设施。
虽然为此任务使用配置管理带来很多价值，但这些工具也可以用作通用自动化框架。例如，它们可以用于在基础设施主机之间配置加密原语，或者在基于主机的防火墙中打开范围紧密的孔。通过这种方式，配置管理（或CM）系统可以用来驱动通常由成熟的零信任控制平面提供的功能的子集。
类似地，CM系统也可以用来在网络中建立有用的抽象。大多数CM工具都支持扩展一组可用资源或操作的机制。使用这个扩展点，就可以在系统中构建更复杂的资源。例如，可以定义服务资源的概念，该资源将捕获用于使服务在网络上可用的所有标准基础设施。
❗CM 是一个临时的垫脚石
配置管理系统最好以使系统达到稳定配置的方式进行部署。考虑到这一理想，使用配置管理系统来对系统进行频繁的更改似乎会适得其反。我们不应该忽视这种担忧，因为它有一定的有效性。相反，我们应该注意，利用一个配置管理系统来构建一个零信任网络只是理想解决方案的垫脚板，这将把这些责任转移到一个专用的控制器上。
二、实施阶段：应用程序身份验证和授权
一个典型的组织使用了许多服务，这些服务的客户端交付越来越基于浏览器。由于零信任网络不会根据连接的网络地址来推断信任，因此每个服务都需要处理身份验证和授权。
一个简单的解决方案是在每个应用程序中存储用户名和密码。然而，这种方法，主要是由于管理的复杂性。与其让每个应用程序实现自己的身份验证系统，最好让应用程序与能够提供集中身份验证和授权检查的身份提供者系统集成。SAML（安全断言标记语言）是一种可用于将应用程序与身份提供程序集成的技术。OAuth2是另一个。
这并不是说应用程序根本没有授权责任。相反，预计会存在一些应用程序级别的授权，特别是在考虑诸如不同的用户权限等情况时。可以卸载帐户管理、用户身份验证和高级授权/访问方面的开销，同时仍然允许为以应用程序为中心的授权提供空间。在使用身份提供程序进行身份验证时，必须使用多因素身份验证，以确保用户凭据不会轻易被盗。我们将在第6章中讨论多因素身份验证。
2.1 身份验证负载均衡器和代理
许多服务体系结构调用使用负载平衡器来将请求分发到一组后端主机。通常，这些负载平衡器表示面向客户端的系统和数据中心系统之间的边界。这可能会造成如何在这样的系统中正确应用零信任控制造成混乱，因为面向客户端的零信任语义可能与服务器端系统有相当大的不同。
在第7章中，我们将介绍如何管理应用程序的身份验证和授权，作为一个模拟的用户身份验证和授权。在后端系统中，授权应用程序的最佳方式是在运行时注入短暂凭据，无论是API密钥、短命证书还是其他证书。每个凭据都唯一地代表一个正在运行的应用程序实例。
在一个负载平衡的系统中，负载平衡软件本身可以被视为一个服务器端应用程序。每个软件实例都使用标识上游主机实例的临时凭据启动。这是除了设备身份验证，它发生在负载平衡器和上游系统之间，使用在第5章中讨论的技术。
使用这种体系结构，负载平衡器可以处理用户和客户端设备身份验证和授权责任，如果需要，利用身份提供者。然后，来自结果身份验证和授权过程的信息（如用户名）的信息可以与原始请求一起发送到后端主机。这样，当数据跨越客户机/服务器边界并进入数据中心时，可以保留零信任架构。
❗您更喜欢安全令牌，而不是TOTP
当多因素身份验证首次部署在组织中时，用户可以使用简单的设备来连续生成基于时间的令牌。随着当今智能手机的普及，大多数用户更喜欢在智能手机上使用多因素应用程序来生成代码。使用安全令牌如U2F的协议，它们的协议比基于时间的令牌系统更受青睐，因为它们可以防止钓鱼攻击。这是一个好处，这些系统通常也更容易让用户使用。如果可能的话，你更喜欢安全令牌，而不是TOTP系统。我们在第6章中讨论了这些技术。
2.2 面向关系的策略
零信任提倡一个控制平面，将授权决策的结果注入网络，以允许受信任的通信发生。在该模型中，每个网络流都分别经过身份验证和授权。强制执行是通过重新配置或信令网络结构以允许经授权的通信来获得的。在一个缺乏这些控制平面系统的规模缩小的零信任网络中，我们被迫缩减了这一雄心。我们可以构建一个在关系级别上定义策略的系统，而不是构建一个使用动态注入和信令的网络。
在面向关系的网络策略中，两个设备之间的通信是通过防火墙和传统的网络过滤机制所必需的TLS连接来定义和控制的。这些策略执行机制可能看起来非常类似于基于边界的模型。面向关系的模型的关键区别在于，策略紧密地指向通信设备，而不是通信网络段。这种方法有时被称为微周化。通过捕获和强制执行哪些设备应该相互通信，我们建立了一个预期通信的数据库，在未来，当动态策略系统决定是否允许一个网络流时，这将具有很大的价值。
2.3 策略分布
在整个网络中分发策略（而不仅仅是强制执行）是零信任的缩小版本的一个共同特征。考虑到我们在网络中所期望的细粒度策略决策，自动化对于使网络具有可操作性至关重要。在一个成熟的零信任网络中，策略解释完全由控制平面系统处理，该系统可以动态地重新配置网络基础设施和设备，或对信令执行组件提供授权响应。然而，在无控制器的部署中，我们必须使用不同的机制。配置管理系统可用于填补网络控制平面上的这个空白。设备可以动态配置以实现自己对预期网络通信的执行。配置从关系策略数据库计算出的主机上软件防火墙可以提供每个主机的强制，这比集中的物理防火墙更不易操作。同样，主机也可以通过相互认证的TLS等机制来授权通信，这同样由配置管理软件控制。
这里的关键实现是，通过使用现有的配置管理系统，我们能够构建一个虚拟控制平面，它可以将执行责任分配到网络结构中。虽然这种方法很务实，但它也并非没有缺点：
· 要求主机强制执行策略，如果主机被破坏，将会有删除或更改该策略的风险。在兼容的环境中，将此责任跨越隔离边界（例如，系统管理程序、容器化系统中的主机操作系统或网络安全组）可以提供更好的保护。
· 当策略推出到系统时，通过配置管理系统进行的更改通常有较长的不一致时间。
2.4 定义和实施安全策略
安全策略需要以一种与用于实现这些策略的单个设备独立的格式被捕获。在实现系统之外存储这些数据的原因有几个：
· 单独捕获策略可以根据所需的策略来审计实现。
· 在切换底层的强制执行系统时，可以重用这些策略定义。例如，如果策略以非供应商特定的格式捕获，则配置新供应商的系统将变得更加容易。
一个捕获预期策略的单独数据库可能很快过时，除非建立机制以确保它与实现一致。确保发生这种情况的最佳方法是使用配置管理系统从此策略数据库中生成实现配置。
一些系统管理员可以选择在配置管理代码中直接捕获策略。在不太成熟的网络中，这种方法被认为就足够了，因为配置管理系统将一致地应用在目标设备上定义的策略。随着网络的成熟，管理员可能会发现，将定义移到数据中，允许在更多的位置使用它们。例如，如果从配置管理代码中提取了该数据，则可以从共享策略数据库中配置基于主机的和受管理的网络防火墙。在不太成熟的网络中，定义变量信任策略太难了。系统管理员应该专注于定义和捕获已知的策略。
在构建策略时，特别是在现有网络中，有测试拟议策略的机制是有帮助的。黄金标准是一个系统，它可以接受拟议的政策变化，并报告因执行这些政策变化而被拒绝的流量。构建这个策略预览系统需要相当多的组件：已记录的生产流数据库、策略模拟器和用于识别当前生产策略和建议策略中的差异的系统。对于许多组织来说，这种复杂的策略模拟水平简直是无法实现的。
可以使用以下推出过程实现安全引入策略更改的更简单方法：
1.取所需策略的一个子集，我们将称之为所提议的策略。
2.以仅进行日志记录的方式部署建议的策略。
3.在足够的时间内收集生产流量。
4.调查如果执行提议的策略，将被拒绝的流量。
5.强制执行所建议的政策。
6.重复此过程，直到部署了所有所需的策略为止。
7.当所有所需的策略都到位时，启用默认情况下拒绝流量的策略。
这个“日志然后强制”过程将提供足够的时间来发现生产环境中不可预见的问题。除了这种方法之外，分阶段推出，其中在生产足迹的一个子集上执行策略，还可以帮助在不影响整个生产系统的情况下识别问题。
2.5 零信任代理
零信任代理是可用于保护零信任网络的应用程序级代理服务器。代理被部署为处理身份验证、授权和加密职责的基础设施。部署这些代理的方式对于确保零信任网络的安全性至关重要。零信任代理可以在两种不同的模式下操作：反向代理或转发代理。根据具体情况，可以使用其中一种或两种代理模式，如图9-4所示。
在反向代理模式下，代理正在接收来自零启用信任的客户端的连接请求。代理接收到初始连接，验证是否应该允许该连接，然后将该请求传递给应用程序进行处理。在前向代理模式下，非零信任感知组件需要向网络上的另一个零信任系统发出网络请求。由于非零信任感知组件无法与控制平面一起工作以正确地启动请求，因此它通过身份验证代理进行通信以处理该责任。
图9-4.共同定位的正向代理可以用来连接到来自遗留系统的零信任资源，而共同定位或集中的反向代理可以允许零信任客户端访问遗留服务
代理可以用于构建零信任网络，但是代理应该部署在与工作负载运行相同的同一设备上。当以这种方式构建零信任网络时，所有工作负载通信在网络上发出之前通过代理强制路由。在代理中隔离此责任比在单独的应用程序中合并它带来优势，我们将在第8章中介绍。不建议在专用设备上放置代理来建立零信任网络。试图隔离外部代理中的零信任责任与该模型相反，该模型旨在保护所有流量，包括代理/负载均衡器和后端服务之间的流量。
对于无法完全控制网络上所有设备或服务的系统管理员来说，建立一个零信任网络尤其困难。例如，网络可能有供应商提供的组件，需要保护，而不更改设备本身。
在这种情况下，零信任代理可以帮助弥补差距。在不可修改的组件和零信任网络之间放置这样的代理可以允许该组件参与网络，尽管对其安全性的保证较少。对非零信任感知组件进行完全隔离是至关重要的。这种隔离必须确保与该组件之间的所有网络通信只能通过其身份验证代理进行。如果可能，应首选直接机械连接。
2.6 客户端端与服务器端之间的迁移
在实现零信任网络时，决定首先应该进行客户机到服务器交互还是服务器到服务器交互，最终取决于组织的需求和实现目标所需的工作水平。客户端到服务器的交互通常是首先关注的。通常，客户在物理上可以移动，并从不受控制的网络访问服务。此外，由于这些设备是可移动的，该设备的物理安全性受到了合理的质疑。因此，在此访问点上建立零信任功能会带来很多价值。然而，在客户机/服务器层建立零信任还存在着真正的障碍。组织不一定要在客户端机器上安装现有的自动化系统，以允许建立零信任网络。此外，在客户端使用的设备类型可以更加多样化，这意味着所需的自动化必须与更多的系统兼容。
服务器到服务器之间的交互可以成为零信任网络的一个更容易的初始目标。这些系统经常安装了现有的自动化工具。它们在使用中也往往有一套不那么多样化的提供商。最后，它们通常是存储敏感数据的系统，因此也是潜在攻击者的一个有吸引力的目标。最终，从哪里开始应该关注哪个目标是系统网络防御中最薄弱的环节。构建一个威胁模型可以帮助确定哪些系统的暴露程度最大。有了这些知识，选择投入时间和资源就更容易了。鉴于这些考虑，以下步骤概述了一种结构化的方法，以确定向零信任网络过渡的初步努力的重点，以确保有效地利用组织资源，以减轻已确定的风险：
评估与客户端和服务器端交互相关的风险，以确定初始工作将最有益。
进行威胁建模练习，以评估客户机到服务器和服务器到服务器之间的交互所面临的潜在威胁，以帮助做出明智的决策。
基于评估和威胁建模，战略性地分配资源，以解决已确定的优先事项。
从优先级层开始，应用零信任原则，评估其有效性，并逐步将实现扩展到其他层。
建立一个持续的监测机制，以评估零信任控制的有效性，并根据不断变化的威胁环境和组织需求调整战略。
通过有条不紊地评估与每一层相关的风险和收益，组织可以对最初的工作集中在哪里做出明智的决定。上面概述的结构化方法提供了导航这一复杂地形的路线图，确保向零信任网络的过渡是战略性的、可管理的，并与组织目标相一致。走向零信任的旅程可能从关注客户端或服务器端交互开始；然而，在所有网络交互中实现和细化零信任原则的整体和持续的方法是长期实现健壮的安全态势的基础。
2.7 端点安全
在实现零信任网络的情况下，端点安全是最重要的。它涉及保护连接到网络的每个设备，因为每个端点都可能作为威胁的入口点。要加强端点的安全性，请确保所有端点都符合组织的安全策略。这包括实现强身份验证、定期打补丁以及端点检测和响应（EDR）解决方案。
此外，强制执行最小特权原则，以最小化每个端点的访问和权限。执行最小特权原则的一个例子可能是公司的政策，即员工在其公司发行的笔记本电脑上没有获得本地管理权利。相反，他们有用于处理日常任务的标准用户帐户。如果他们需要安装软件或执行需要管理权限的操作，他们必须通过一个受控的过程，例如向IT部门提交请求。
对此过程进行审查，如果合理，IT团队执行行动或授予临时管理权限。这最大限度地减少了对系统进行未经授权的更改的风险，并减少了潜在漏洞的攻击面。预期的结果是一个不断获得和验证信任的网络，大幅减少攻击表面，增强整体安全态势。
三、案例研究
由于零信任网络的确切架构依赖于特定组织网络的细节，因此很难看到所有的部分是如何组合在一起的。为了帮助可视化这些原则如何在不同的情况下表现出来，我们将探索一些已经成功过渡到零信任模型的组织的经验。谷歌的BeyondCorp致力于将零信任架构引入其高度分布式和移动的工作人员每天使用的客户端到服务器的交互中。PagerDuty的云无关网络专注于服务器到服务器和交叉云交互，这些交互需要同时保护来自外部和内部威胁。
四、案例研究：谷歌Beyond公司
Betsy Beyer
从2014年11月开始，谷歌发表了一系列文章；登录：描述一种新的、开创性的安全模型。以下案例研究是基于这三篇文章的摘录，经谷歌许可和：登录；。我们鼓励您阅读原始原始资料，以了解更多细节：
“BeyondCorp: A New Approach to Enterprise Security” by Rory Ward and Betsy (Adrienne Elizabeth) Beyer
“BeyondCorp: Design to Deployment at Google” by Barclay Osborn, Justin McWilliams, Betsy Beyer, and Max Saltonstall
“Beyond Corp: The Access Proxy” by Batz Spear, Betsy Beyer, Luca Cittadini, and Max Saltonstall
到了21世纪10年代初，谷歌对网络防御的周长模式越来越不舒服。当我们成千上万的员工在办公室外完成大部分工作，而在任何一天我们都邀请成千上万的人进来时，建造高高的、坚不可摧的“城堡墙”不会保护我们。与此同时，随着谷歌在数十亿用户的生活中所扮演的关键角色不断增加，我们对委托给我们的用户数据所赋予的几乎不可估量的价值也在不断增加。
根据我们的员工基础和我们的企业网络的范围和规模，以及我们的员工与企业资源互动的各种方式（作为一个移动劳动力使用云服务和各种客户端设备），很明显，城堡墙的隐喻是不可持续的。我们需要一个更类似于现代城市而不是中世纪的城堡的策略：一个根据你的谁来调节访问应用程序、数据和服务的系统，而不是你使用哪个网络。
考虑到这一安全需求，谷歌用一套全新的眼光重新审视了企业的状态。我们知道，我们可以比整个行业部署的任何传统网络安全模型做得更好，所以我们采取了激进的步骤，重新设计我们的整个方法。
从重新设想内部网络安全的角度开始，我们投入了四年的设计和迭代，创建了一个零信任模型的鲁棒实现。虽然大多数企业认为内部网络是一个安全的环境，可以在其中暴露企业应用程序，但我们认为内部网络和公共互联网一样充满了危险。这种新模式完全摒弃了一个享有特权的企业网络。相反，访问完全取决于设备和用户凭据，而不管用户的网络位置如何——无论是企业位置、家庭网络，还是酒店或咖啡店。所有对企业资源的访问都根据设备状态和用户凭据进行完全身份验证、完全授权和完全加密。我们可以强制执行对企业资源的不同部分的细粒度访问。
因此，所有谷歌的员工都可以在任何网络上成功地工作，而不需要一个传统的VPN连接到特权网络。除了潜在的潜在差异外，对企业资源的本地和远程访问之间的用户体验实际上是相同的。
当阅读下面的案例研究时，请记住，我们很清楚谷歌在其规模和我们能够用于这个问题空间的资源数量方面都是独一无二的。因为我们不受资源的限制，所以我们可以或多或少地纯粹是出于雄心勃勃的目标，从而废除了传统的网络安全范式。
从BeyondCorp公司的成立一直持续到2017年：黑客工具已经非常先进，成本也大幅下降。曾经只有在反对谷歌规模的目标时才可能值得的恶意努力，现在适用于规模小得多的企业。虽然中小型组织的风险状况增加了，但他们保护自己的选择也增加了；商业网络安全行业也同样成熟了。
虽然谷歌必须从头开始构建其安全基础设施，但现在实际上可以使用企业网络安全产品来摆脱周边模型。无论您在这个领域中考虑哪个组件，在开发策略时，都要记住激励谷歌的核心设计原则和目标。
虽然BeyondCorp的技术和实施细节可能对您的企业或组织有不同程度的直接适用性，但我们设计用来防范的许多风险因素都是广泛相关的，我们所采用的基本设计原则应该与所有人直接相关。
4.1 该公司的主要组成部分
如图9-5所示，BeyondCorp由许多协作组件组成，以确保只有经过适当身份验证的设备和用户才被授权访问必要的企业应用程序。以下部分描述了BeyondCorp的各个组成部分。
图9-5. BeyondCorp组件和访问流程
BeyondCorp使用主设备清单数据库和设备证书安全地识别和跟踪所有托管设备。
BeyondCorp使用了“托管设备”的概念，这是一种由企业采购和主动管理的设备。只有托管设备才能访问企业应用程序。围绕我们的设备库存数据库的设备跟踪和采购过程是这个模型的基石之一。
随着设备生命周期的进展，谷歌会跟踪对设备所做的更改。这些信息将被监控、分析，并提供给该公司的其他部分。由于谷歌有多个库存数据库，我们使用一个元库存数据库来合并和规范化来自这些多个来源的设备信息，并使这些信息对BeyondCorp的下游组件可用。有了这个元库存，我们就了解了需要访问我们企业的所有设备。
所有托管设备都需要以引用设备清单数据库中的记录的方式进行唯一标识。实现这种唯一标识的一种方法是使用特定于每个设备的设备证书。要接收证书，设备必须在设备清单数据库中同时存在且正确。我们将证书存储在硬件或软件受信任的平台模块（TPM）或合格的证书存储区中。设备确认过程将验证该证书存储区的有效性，并且只有被认为足够安全的设备才能被归类为托管设备。这些检查也作为证书强制执行，并定期更新。安装后，该证书将用于到企业服务的所有通信。虽然证书唯一地标识设备，但它不会单独授予访问权限。相反，它被用作有关该设备的一组信息的关键字。
BeyondCorp还跟踪和管理用户数据库和组数据库中的所有用户。该数据库系统与谷歌的人力资源流程紧密集成，谷歌负责管理所有用户的作业分类、用户名和组成员关系。外部化的单点登录（SSO）系统是一个集中的用户身份验证门户，它为请求访问我们的企业资源的用户验证主要和第二因素凭据。在对用户数据库和组数据库进行验证后，SSO系统将生成短暂的令牌，可用作特定资源的授权过程的一部分。
谷歌中的所有企业应用程序都通过一个面向互联网的访问代理（AP）公开给外部和内部客户端，该代理强制执行客户端和应用程序之间的加密。AP为每个应用程序配置，并提供了公共特性，如全局可达性、负载平衡、访问控制检查、应用程序运行状况检查和拒绝服务保护。在访问控制检查（下一节所述）完成后，此代理将请求委托给后端应用程序。有关AP特性的更多细节，请参见“利用和扩展GFE”。
提供给单个用户和/或单个设备的访问级别可以随时间而变化。通过查询多个数据源，我们能够动态地推断出要分配给设备或用户的信任级别。访问控制引擎（下面将详细描述）可以将此信任级别作为其决策过程的一部分，如下示例所示：
· 没有使用最近的操作系统补丁进行更新的设备可能会降低信任度。
· 特定类别的设备，如特定型号的手机或平板电脑，可能被分配特定的信任级别。
· 从一个新的位置访问应用程序的用户可能会被分配一个不同的信任级别。
我们同时使用静态规则和启发式方法来确定这些信任级别。访问代理中的访问控制引擎根据每个请求为企业应用程序提供服务级别的授权。授权决定考虑了以下几个因素：
· 由设备清单数据库报告的关于用户、用户所属的组、设备证书和设备的工件的信息
· 对用户和设备的推断的信任级别
· 如果有必要，访问控制引擎还可以强制执行基于位置的访问控制
例如，访问控制引擎可以使用以下策略
· 限制使用工程设备的全职工程师使用谷歌的错误跟踪系统。
· 使用受管理的非工程设备，限制财务运营组中的全职和兼职员工访问财务应用程序。
访问控制引擎还可以以不同的方式限制应用程序的某些部分。例如，在我们的错误跟踪系统中查看一个条目可能比更新或搜索相同的错误跟踪系统需要更不严格的访问控制。
传统的方法可能是将每个后端与设备信任推理服务集成，以评估适用的策略；然而，这种方法将显著降低我们发布和更改产品的速度。相反，谷歌实现了一个集中的策略执行，前端AP来处理粗粒度的公司策略。
BeyondCorp利用现有的谷歌前端（GFE）基础设施作为策略执行的逻辑集中访问点。以这种方式汇集请求使我们自然地扩展GFE以提供其他功能，包括自助服务提供、身份验证、授权和集中日志记录。所得到的扩展的GFE被称为AP。下一节详细介绍了与本案例研究特别相关的AP的特征。有关其其他功能的详细信息，请参见 “Beyond Corp: The Access Proxy”.
GFE提供了一些内置的好处，如后端负载平衡和TLS管理，这并不是专门为BeyondCorp.设计的。AP通过引入身份验证和授权策略来扩展GFE。
为了正确地授权一个请求，AP需要识别发出请求的用户和设备。在多平台环境中，身份验证设备带来了许多挑战，我们在“多平台身份验证的挑战”中解决了这些问题。AP通过与谷歌的身份提供程序（IdP）集成来验证用户身份。因为需要后端服务更改其身份验证机制以使用AP机制是不可扩展的，所以AP需要支持一系列身份验证选项： OpenID连接、OAuth和一些自定义协议。AP还需要处理没有用户凭据的请求，例如，一个试图下载最新安全更新的软件管理系统。在这些情况下，AP可以禁用用户身份验证。
当AP对用户进行身份验证时，它会在将请求发送到后端之前删除该凭据。必须这样做，因为必须有两个原因：
· 后端无法通过访问代理来重放请求（或凭据）。
· 该代理对后端是透明的。因此，后端可以在访问代理流上实现自己的身份验证流，并且不会观察到任何意外的Cookie或凭据。
两个设计选择推动了我们的授权机制的实现：
· 一种集中式访问控制列表（ACL）引擎，可通过远程过程调用（RPCs）进行查询
· 一种特定于领域的语言，用来表示可读和可扩展的ACL
将ACL评估作为一种服务提供，使我们能够保证多个前端网关（例如，AP或半径网络访问控制基础设施、远程身份验证拨入用户服务、SSH或安全Shell、代理）之间的一致性。我们选择将AP上的粗粒度集中式授权与后端上的细粒度授权结合起来。
因为后端将访问控制委托给前端，因此后端必须相信它所接收到的流量已被前端进行了身份验证和授权。这一点尤其重要，因为AP终止了TLS握手，并且后端通过一个加密的通道接收到一个HTTP请求。满足此条件需要一个能够建立加密通道的相互身份验证方案——例如，您可以实现相互身份验证的TLS身份验证和公司公钥基础设施。我们的解决方案是一个内部开发的身份验证和加密框架，称为LOAS（低开销身份验证系统），它可以双向身份验证和加密从代理到后端的所有通信。
前端和后端之间的相互身份验证和加密的一个好处是，后端可以信任AP插入的任何额外元数据（通常以额外的HTTP头的形式）。虽然添加元数据和在反向代理和后端之间使用自定义协议并不是一种新颖的方法（例如，请参阅Apache JServ协议），但AP的相互身份验证方案确保了元数据不会被欺骗。作为一个额外的好处，我们还可以在AP上逐步部署新的特性，这意味着同意的后端可以通过简单地解析相应的报头来选择加入。我们使用此功能将设备信任级别传播到后端，然后它可以调整响应中提供的细节级别。
4.2 多平台身份验证所面临的挑战
至少，执行正确的设备识别需要两个组件：
· 某种形式的设备标识符
· 一个库存数据库，跟踪任何给定设备的最新已知状态
由于BeyondCorp用对设备的适当信任级别取代了对网络的信任，因此每个设备必须具有一致的、不可克隆的标识符，而有关软件、用户和设备位置的信息必须集成到库存数据库中。
台式机和笔记本电脑使用X.509机器证书和存储在系统证书存储区中的相应私钥。密钥存储是现代操作系统的一个标准特性，它确保通过AP与服务器通信的命令行工具（和守护进程）能够与正确的设备标识符一致匹配。由于TLS要求客户端提供私钥占有的加密证明，此实现使得标识符不可欺骗和不可克隆，假设它存储在安全的硬件中，如可信平台模块（TPM）。
我们不依赖证书，而是使用由强设备标识符提供的。对于iOS设备，我们使用标识为供应商，而Android设备使用企业移动管理应用程序报告的设备ID。
4.3 Migrating to BeyondCorp
与世界上几乎所有其他企业一样，谷歌多年来为其客户和应用程序维护了一个特权网络。这种模式产生了重要的基础设施，这对公司的日常工作至关重要。虽然公司的所有组件都将迁移到BeyondCorp，但将每个网络用户和每个应用程序一次性转移到碧ondcorp环境对业务连续性将面临巨大的风险。因此，由于这个原因，谷歌在分阶段迁移上投入了大量资金，成功地将大量网络用户转移到BeyondCorp，但对他们的生产力没有任何影响。
为了将本地访问和远程访问等同起来，BeyondCorp定义并部署了一个与外部网络非常相似的非特权网络，尽管是在一个私有地址空间内。非特权网络只连接到因特网、有限的基础设施服务（如DNS、域名服务、DHCP、动态主机配置协议、NTP、网络时间协议），以及Puppet等配置管理系统。所有的客户端设备都被分配给这个网络，而物理位置位于谷歌建筑中。在这个网络和谷歌网络的其他部分之间有一个严格管理的访问控制列表。
在谷歌中使用的所有应用程序都需要通过AP进行工作。BeyondCorp计划检查并限定了所有的应用程序，这些应用程序完成的任务从简单（如支持HTTPS流量）到更困难（如SSO集成）。每个应用程序都需要一个AP配置，在许多情况下，还需要访问控制引擎中的一个特定节。每个应用程序都经历了以下几阶段：
1.可直接从特权网络和通过VPN连接。
2.可直接从特权网络和通过AP从外部网络和非特权网络获得。在这种情况下，我们使用了分裂的DNS。内部名称服务器直接指向应用程序，而外部名称则指向AP。
3.可通过AP从外部网络、特权网络和非特权网络获得。
随着越来越多的应用程序通过访问代理可用，我们开始积极地阻止用户使用VPN，并采用以下策略：
1.我们限制了VPN对有特定需求的用户的访问。
2.我们监控了VPN的使用，并删除了在明确定义的时间内没有使用VPN的用户的访问权限。
3.我们监控了活跃的VPN用户的VPN使用情况。如果他们所有的工作流都可以通过AP使用，我们强烈鼓励用户放弃他们的VPN访问权限。
只有当我们确定（或非常接近确定）用户的所有工作流都从这个网络可用时，我们才将用户转移到非特权网络是非常重要的。为了建立一个相对程度的确定性，我们建立了一个交通分析管道。我们的分析过程如下：
1、作为这个管道的输入，我们从公司的每个交换机中捕获采样的网络流数据。
2、我们根据非特权网络和公司其他网络之间的规范ACL分析了这些数据。该分析允许我们识别将通过ACL的总流量，以及将没有通过ACL的有序流量列表。
3.我们现在可以将非传递的流量附加到特定的工作流和/或特定的用户和/或特定的设备上。
我们逐步通过非通过流量列表，使其在BeyondCorp环境中发挥作用。
为了增强流量分析管道，我们还通过安装在谷歌网络连接的所有用户设备上的流量监视器，模拟了整个公司的非特权网络行为。流量监控器检查每个设备的所有传入和传出流量，根据非特权网络和公司其他网络之间的规范ACL验证该流量，并记录未通过验证的流量。
该显示器有两种模式：
①Logging mode:捕获了不合格的流量，但仍然允许上述车辆离开设备
②Enforcement mode:捕获并丢弃了不合格的车辆
有了流量分析管道和非特权模拟，我们定义并开始实现一个阶段性迁移策略，其中包括：
1。根据工作职能和/或工作流和/或位置确定潜在的候选人集。
2.在日志记录模式下操作模拟器，识别在连续30天的时间段内具有>99.9%合格流量的用户和设备。
3.为具有>99.99%合格流量的用户和设备激活模拟器强制模式。如有必要，用户可以将模拟器恢复到日志记录模式。
4.在强制模式下成功操作模拟器30天后，将这一事实记录在设备清单中。
5.除了包含在候选集中，在模拟器的执行模式中成功操作30天提供了一个非常强的信号，表明该设备应该被分配给非特权网络。
除了自动迁移用户和设备从我们的特权尽可能新的无特权网络，我们还实现了一个简单的过程为用户请求临时豁免这个迁移：
①我们维护一个已知的工作流列表尚未符合BeyondCorp。用户可以搜索这些工作流，并使用正确的批准级别，将他们自己和他们的设备标记为某个工作流的活动用户。
②当工作流最终合格时，其用户将被通知，并再次有资格被选择进行迁移。
4.4 经验教训
BeyondCorp 公司的迁移带来了一系列的挑战和问题。希望以下的经验教训可以为其他寻求实现类似模式的组织节省一些时间和麻烦。
对安全基础设施的根本性变化可能会对整个公司员工的生产力产生不利影响。向用户传达影响、症状和可用的补救选项是很重要的，但是很难在过度沟通和沟通不足之间找到平衡。
沟通不足会导致以下问题：
· 惊讶和困惑的用户
· 效率低下的补救
· IT支持人员的运行负荷不足
过度沟通也是个问题：
· 抗变更的用户往往会高估了变更的影响，并试图寻求不必要的豁免
· 用户可能会习惯于发生具有潜在影响的变化。
随着谷歌的企业基础设施正在以许多不相关的方式发展，用户很容易将访问问题与其他正在进行的工作混为一谈，这也减缓了补救工作，并增加了支持人员的操作负荷。
过渡到一个新的网络安全模式并不是一夜之间发生的，而是需要多个团队之间的协调和交互。在大型企业规模中，不可能将整个过渡过程委托给单个团队。迁移可能会涉及一些需要足够的管理支持的向后不兼容的更改。
根据我们的经验，转换的成功在很大程度上取决于团队在访问代理背后成功设置其服务的容易程度。让开发人员的生活更轻松应该是一个首要目标，所以要把惊喜的数量保持在最低限度。提供健全的默认值，为最常见的用例创建演练指南，并投资于文档。为更高级和更复杂的更改提供沙箱——例如，您可以设置访问代理的单独实例，负载均衡器有意忽略，但开发人员可以访问（例如，暂时覆盖他们的DNS配置）。沙箱在许多情况下都被证明是非常有用的，比如当我们需要确保客户端在对X.509证书或底层TLS库进行重大更改后能够处理TLS连接时。
资产管理中的数据质量差可能导致设备无意中失去对公司资源的访问。拼写错误、转置标识符和缺失信息是常见的。当采购团队收到资产装运并将资产添加到我们的系统时，可能会出现此类错误，也可能是由于制造商工作流程中的错误。在设备维修期间，当设备的物理部件被替换或移动设备时，数据质量问题也经常出现。这些问题可能会以如果不手动检查设备就难以修复的方式损坏设备记录。
在这个领域，最有效的解决方案是找到本地工作流改进和自动输入验证，可以在输入时间捕获或减少人为错误。复式会计法有帮助，但不能涵盖所有的案例。然而，为了进行正确的信任评估，需要有高度准确的库存数据，这迫使人们重新关注库存数据的质量。我们的数据的准确性处于以前未见的水平，这种精度具有次要的安全优势。例如，使用最新安全补丁更新的舰队百分比增加了。
上游数据源不一定共享重叠的设备标识符。列举一些潜在的场景：
· 新设备可能有资产标记，但没有主机名。
· 硬盘驱动器序列号可能与设备生命周期中不同阶段的不同主板序列号相关联。
· MAC地址可能发生冲突。
一组相当小的启发式方法可以将来自数据源子集的大多数增量关联起来。然而，为了使精度接近100%，您需要一组极其复杂的启发式方法来解释似乎无穷无尽的边缘情况。只有一小部分数据不匹配的设备可能会将数百甚至数千名员工锁定在他们需要高效使用的应用程序之外。
4.5 Conclusion
幸运的是，一个寻求实现零信任网络策略的组织确实手头有资源来引导这个过程。虽然这段旅程绝不是微不足道的，但在这个领域有许多企业和商业解决方案，我们希望在您考虑潜在的方法时，本案例研究中概述的粗略蓝图会有所帮助。在权衡您的选择和为您的需求选择最佳的安全策略时，请记住这里概述的核心动机和设计原则。
五、案例研究：PagerDuty的云-不可知论网络
Evan Gilman and Doug Barth
PagerDuty从2013年开始建立一个零信托网络，并于2014年完成。它一直在继续发展，并在撰写本文时仍在制作过程中。作者要感谢PagerDuty允许它使用它的名称，并描述其零信任实现背后的一些细节。所有的意见都是作者的意见，并且PagerDuty不是在这里所包含的错误或不准确的过错。PagerDuty是一个组织用来增强其事件响应的平台。用户可以使用PagerDuty的API集成他们现有的工具，如监控、票务和报告系统。大多数用户首先配置他们的监控系统，通过PagerDuty路由警报，以便PagerDuty可以管理随叫随到的旋转和升级。鉴于所提供的服务的关键性质，零信任网络是同时满足该系统的可靠性和数据隐私要求的理想网络。
PagerDuty的零信任网络主要处理纯粹在多提供商公共云环境中的服务器与服务器之间的交互。云服务提供商具有不同的网络控制平面能力。一些提供程序不提供传统外围系统通常需要的控制，如有状态防火墙、私有寻址和网络acl。在最极端的情况下，主机被放置在公共互联网上，主机需要保护自身的安全。在使用传统的周边概念时，提供者能力上的这种差异使得运行与提供者无关的网络异常困难。
PagerDuty的系统在其正常运行中也大量使用了广域网（广域网）通信。业务关键系统部署在三个独立的区域，目标是在不影响整个区域的情况下生存。依靠WAN进行正常的应用程序操作，给系统带来了一些沉重的要求。互联网通常是一个具有挑战性的网络环境，可能出现意外的高延迟和包丢失。此外，通信还需要进行加密和身份验证，以确保数据的隐私和完整性。通过部署一个无周长的零信任网络，就实现了故障隔离，因为集群中的每个节点都只负责它自己的通信。
5.1 配置管理作为一个自动化平台
用于构建PagerDuty的零信任网络的关键资产是它的配置管理工具Chef。Chef已经被用于配置系统中的每个虚拟机，因此它是一个现成的自动化层，可以用来构建一个零信任网络。通过配置管理，策略可以以代码进行集中管理，同时将强制执行分发到整个舰队中。
这种方法有许多好处：
· 网络计算功率规模随着实例数量的增加而增加。随着网络的增长，这种扩展属性无需购买更大的共享硬件。
· 失败往往更加孤立。该系统没有“防火墙”，而是有许多更小的防火墙。单个防火墙的故障会影响更小的流量集，通常可以进行路由。
整个网络的分发策略并非没有缺点：
· 需要不断验证预期的策略状态，以确保所有节点都能正确地执行预期的策略。
· 确保整个车队的政策变化是一致的。如果系统管理员希望能够做出更改并看到其立即生效，那么这可能会有点不和谐。
虽然配置管理是快速迭代零信任想法的理想场所，但它并不是一个理想的长期解决方案。随着这些系统变得更加成熟，它们已经从Chef开始发展到它们自己的系统中，这些系统可以被部署和调整以获得最佳的性能。
5.2 动态计算出的本地防火墙
由于没有一致的提供者提供的防火墙解决方案，PagerDuty发现需要确保每个主机在不依赖提供程序的情况下安全系统。为了满足这一需求，Chef被教导了如何基于其现有的系统知识生成iPtable配置。系统中的服务器按其角色进行分类，该角色捕获了该角色应该存在的服务集和预期的通信模式。给定角色的每个服务器在其配置中都是相同的。
IPtable链构建在每个单独的主机上，它枚举具有特定角色的服务器的IP地址。然后，将使用这些链来定义允许按角色进行预期访问的规则。如果一个流与白名单规则不匹配，则会删除其数据包。下面是一个表示此安排的iptable配置的示例：
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
target prot in out source destination
ACCEPT all lo * 0.0.0.0/0 0.0.0.0/0
ACCEPT all * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
bastion tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
lb tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
lb tcp * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
LOG all * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5...
DROP all * * 0.0.0.0/0 0.0.0.0/0
Chain bastion (1 references)
target prot in out source destination
ACCEPT all * * 192.168.0.55 0.0.0.0/0
ACCEPT all * * 192.168.5.4 0.0.0.0/0
ACCEPT all * * 10.0.2.78 0.0.0.0/0
ACCEPT all * * 172.16.0.132 0.0.0.0/0
Chain lb (2 references)
target prot in out source destination
ACCEPT all * * 192.168.1.221 0.0.0.0/0
ACCEPT all * * 192.688.1.222 0.0.0.0/0=
5.3 分布式流量加密
对于网络加密和身份验证，PagerDuty决定实现一个IPsec主机到主机的网状网络。
这种网络架构有许多好处：
· 所有数据包都由系统中的每个节点进行加密和身份验证。
· 由于加密和身份验证分布在整个系统中，因此随着主机数量的增加，提供这些关键功能的能力也在增加。
网络加密和身份验证通常被视为应用程序级别的问题，但要求每个应用程序提供这些安全控制会导致更不安全或更不可操作的系统。应用程序加密可能在正确实现加密规范方面存在问题，缺乏响应安全漏洞的配置控制，或者在系统中引入性能回归。由于这些原因，PagerDuty决定依赖内核的IPsec堆栈来提供这一点关键的基础设施。
使用相互身份验证的TLS的系统可以为基于ipsec的网络提供类似的好处。为了提供同样的保证，系统管理员应该将TLS基础设施与应用程序分开。
❗进程外加密正日益成为一种标准
在许多系统中，加密和身份验证被认为是一个应用程序问题，而应用程序通常使用标准库提供这种功能。随着系统中应用程序数量的增加，系统越来越多地使用进程外机制来保护网络通信。通过将加密逻辑移到单独的过程中，管理员获得一组用于响应安全漏洞的标准控件。此外，有一个单独的过程来控制敏感的加密过程，从而减少了可能暴露秘密数据的攻击的表面积。
PagerDuty的网络在传输模式下使用IPsec。阶段1和阶段2密码套件使用最强的配置。在选择密码套件时，引用了RFC 6379，以确保所选择的算法被建议一起使用。IPsec通信通常使用ESP数据包进行传输。由于一些云提供商的网络不路由ESP数据包，因此所有的IPsec流量都被封装在UDP数据包中。
PagerDuty在生产中操作IPsec网状网络的经验有点复杂。该网络已经处理了生产吞吐量，并随着车队的增加而增长。在最初推出期间，确实发生了通信故障，通常是由于IPsec关系两边的状态不一致。使用度量标准和日志记录来解决这些问题对网络的运行至关重要。虽然出现这些故障确实令人沮丧，但对于网状网络，这些故障被隔离到主机对中，这通常会减少故障的影响。
PagerDuty最初推出的IPsec网络利用了Chef和一些简单的脚本来配置已存在的IPsec软件包。随着网络的发展，系统的配置已经从Chef转移到一个专门的服务中，它可以单独负责配置系统这方面的工作。将逻辑移到自己的系统中是为了减少在网络中部署更改的收敛时间。基于Chef的系统需要运行整个Chef收敛运行来更新网络中的所有相关主机——一个重量级的操作，处理的不仅仅是网络配置。
5.4 分散的用户管理
PagerDuty的用户访问控制以集中的方式部署，很像前面讨论的网络系统。本地用户和组不依赖于集中的LDAP系统，而是基于编程方式构建的LDAP系统。这种方法消除了对网络的依赖，这有助于系统甚至在充满挑战的时期继续运行。
虽然用户访问控制的执行分布到网络中，但应该创建哪些用户和组的定义是集中化的。此信息可以在LDAP服务器或其他数据库中捕获。在PagerDuty的案例中，它使用Chef数据包来定义用户和组。服务器角色被标记为应该在该角色上创建的组集。Chef使用此数据仅创建特定服务器上需要访问该基础设施的用户和组。
5.5 Rollout
PagerDuty的网络，就像大多数网络一样，是一个不断发展的系统。随着时间的推移，随着生产流量流动，网络从传统设计转变为零信任网络。
在关键的生产流量流动的时候更改网络架构可能是困难的，因此计划推出以降低风险是很重要的。PagerDuty遵循了一个缓慢的推出模式：
1.已定义了新的策略。
2.策略的部署方式不影响生产系统，而是收集有用的度量标准或日志。
3.系统会长时间检查度量/日志，以确保需要这些行为。
4.该政策在整个舰队中缓慢启用，覆盖率从一个小的比例增长到100%。
这个简单的程序可用于减少大多数生产变化的风险。它比使用预定维护窗口的常用方法要好得多。缓慢的推出模式用于部署PagerDuty系统中的大部分更改。
对于分布式防火墙项目，所有主机最初都被配置为记录数据包，这将在以后被删除。创建防火墙规则是为了对流量进行分类，它可以部署而不会有阻塞任何生产流量的风险。部署了规则后，记录的流量减少了；一旦经过了足够的时间，系统将被重新配置为删除所有非白名单的流量。
分布式流量加密遵循相同的卷展栏过程。IPsec策略首先以无操作配置部署到舰队中。这些策略控制一个特定的流量是否应该使用IPsec进行通信。IPsec支持三种不同的状态：
将不使用IPsec。
如果一段关系可以协商，IPsec将被乐观地使用。
必须将IPsec用于要处理的流量。
最初的策略集被部署在无状态中。最终的目标是通过逐步通过使用状态，使整个系统达到所需的状态。基于对使用状态的故障模式的测试，确定了如果IPsec关系被破坏，中间状态防火墙将阻塞通信，因为数据包将返回到无策略。这些数据包不会与预期的流相关联（请记住，它们之前已经被加密并封装在一个UDP封装的数据包中），因此会被丢弃。
不是将整个网络配置为使用状态，而是将网络的较小部分转换为使用状态，然后重新配置为必需状态。这种分阶段的方法最小化了网络处于潜在风险使用状态的时间，同时仍然允许主机在重新配置自己时进行通信。厨师根据一对主机所喜欢的状态计算了一对主机之间的最低策略。
5.6 一个与提供者无关的系统的价值
不用说，构建一个与提供者无关的系统需要大量的工程努力。对于许多系统来说，这种努力可能是不合理的。在PagerDuty的案例中，业务要求确定了这种努力是合理的。当PagerDuty决定离开其其中一个云提供商时，拥有这个与提供商无关的网络提供了显著的投资回报。通常，这样的工作需要几个月的工作，需要有许多高风险的更改窗口。
在PagerDuty的例子中，这种变化相对简单。从做出决定到转移所有的生产流量，我们花了大约六周的时间。大部分时间都花在研究新的供应商，测试新供应商的系统，以及改造Chef自动化上。实际的更改在正常工作时间的一周内部署到生产中，对客户没有任何影响。
Summary
本章重点讨论了一个想要移动到零信任网络的组织需要决定的问题。在可能的情况下，它给出了现实世界的建议，以帮助读者做出这些决定。我们花了一些时间讨论了使用系统图来理解系统的状态和从实际生产流量中捕获网络流的重要性。将所有的零信任控制飞机系统作为独立的服务可以是一项巨大的前期投资，因此探索了实际的替代方案。
需要记住的最重要的细节是，零信任是架构上的理想，因此本章讨论了如何通过以一种以后可以重用的方式定义和捕获策略来开始工作。它探索了建立可以合并与零信任不直接兼容的系统的身份验证代理。它还探讨了组织是否应该从客户机/服务器交互或服务器/服务器交互开始。最后，为了帮助读者了解这种类型的努力是如何在其他组织的系统中发挥作用的，本章探讨了两个具体的案例研究。这些案例研究探讨了旨在使现有生产网络中的零信任成为现实的特殊方法和权衡。下一章将重点关注一个假设的攻击者可能如何试图阻止一个零信任网络