Zero Trust Networks【8】
一、加密与身份验证
二、不加密的真实性？
三、引导信任：第一个数据包
四、网络模型中的零信任应该在哪里？
五、The Protocols
六、信任云流量：面临的挑战和注意事项
七、云访问安全代理（CASB）和身份联盟
八、Filtering
九、场景演练
Chapter 8. Trusting the Traffic
认证和授权网络流是零信任网络的一个关键方面。在本章中，我们将讨论加密如何融入其中，如何通过安全介绍来引导流信任，以及这些安全协议在您的网络中最适合的位置。零信任并不是完全背离了我们所知道的一切。传统的网络滤波虽然应用非传统，但在零信任网络中仍然起着重要的作用。在本章的结尾，我们将探讨过滤在这些网络中所扮演的角色。
一、加密与身份验证
加密和真实性往往是携手并进的，但却有明显不同的目的。加密确保了机密性——承诺只有接收方才能读取您发送的数据。身份验证使接收方能够验证消息是由它声称是的东西发送的。身份验证还有另一个有趣的特性。
要确保邮件实际上是真实的，您必须能够验证发件人，并且该邮件没有被更改。这被称为完整性，这是消息身份验证的一个基本属性。
在不需要身份验证的情况下也可以进行加密，尽管这被认为是一种糟糕的安全做法。在没有发件人的验证下，攻击者可以自由伪造消息，可能会重播以前的“好”消息。攻击者可以改变密文，而接收者将无法知道。
忽略身份验证打开了许多向量，因此整个建议都是完全相同的：使用它。此外，在讨论零信任网络上下文中的加密和身份验证时，必须考虑以下几个方面：
在现代加密实践中，安全的密钥管理起着至关重要的作用。它涉及到加密密钥的安全生成、存储和分发。诸如使用硬件安全模块（HSMs）或密钥管理服务（KMSs）等技术可以确保保护加密密钥免受未经授权的访问或泄露。
前向保密是加密协议的一个关键属性，如TLS。它确保单个加密密钥的妥协不会损害过去或未来通信的机密性。前向保密依赖于使用在单个会话后丢弃的短暂密钥，这使得攻击者更难解密之前记录的加密流量。
在零信任网络中信任流量的上下文中，合并多因素身份验证增加了一层安全性，因为MFA要求用户在获得访问资源或传输数据之前提供多种形式的身份验证，如密码、指纹扫描或安全令牌。在身份验证级别实现MFA可以加强对网络的信任。
随着量子计算机的兴起，目前被认为是安全的传统密码算法可能会变得容易受到攻击。后量子密码学专注于开发能够抵御量子计算机攻击的加密算法。研究和标准化工作正在进行中，以识别和部署后量子密码算法，可以取代或增加现有的算法，以确保在面对量子计算的进步时的长期安全。
二、不加密的真实性？
消息真实性是零信任网络的既定要求，没有它就不可能构建零信任网络。但是加密呢？加密带来了机密性，但偶尔也会造成麻烦。如果您不能在没有复杂的解密过程的情况下读取数据包捕获，那么故障排除就会变得更加困难。如果无法检测网络流量，入侵检测就变得难以到不可能。事实上，有一些合理的理由可以避免加密。也就是说，如果你选择不使用加密技术，你绝对要确定你并不关心数据的机密性。虽然保持数据不加密对管理员来说很方便，但如果数据确实需要机密性，这永远都是合法的。例如，请考虑到图8-1中所示的场景。
图8-1.数据中心内的保密性与数据中心外部同样重要
这是一个非常常见的架构。请注意，它只加密某些区域的流量，保留其余部分（可能是为了系统管理员）。然而，显然，这些数据需要机密性，因为它在站点之间的传输中是加密的。这是与零信任体系结构的直接矛盾，因为它在网络中创建了特权区域。
因此，引用充分的理由不加密流量是一个非常棘手的问题。在实践中，真正不需要保密的系统是罕见的。
除此之外，仍然需要进行身份验证。很少有网络协议提供较强的身份验证，但不提供加密，而且我们在本书中讨论的所有传输协议都提供了身份验证和加密。如果你这样看，加密是“免费”实现的，几乎没有什么好的理由来排除它。
三、引导信任：第一个数据包
流中的第一个数据包通常是繁重的。根据连接类型或设备生命周期中的点，这个数据包可以携带很少的信任。我们通常知道在数据中心内部会发生什么数据流，但在面向客户的系统中，这是任何人的猜测。
这些系统必须广泛可访问，这大大增加了风险。我们可以在允许设备访问服务之前使用相互身份验证的TLS等协议对设备进行身份验证；然而，这种情况下的攻击表面仍然相当大，而且资源也是可以公开发现的。
那么，如何只允许受信任的连接，无声地删除所有其他连接，而不回答一个未经身份验证的数据包呢？这称为第一包问题，通过一种称为预身份验证的方法来缓解（图8-2)。预身份验证可以看作是通过设置期望来实现对身份验证请求的授权。
它通常是通过加密和/或签名一小块数据，并将其作为UDP（用户数据报协议）数据包发送到资源来完成的。使用UDP进行预身份验证很重要，因为UDP数据包在默认情况下不会收到响应。这个属性允许我们“隐藏”，只有在我们被动地收到使用正确密钥加密的数据包时才会暴露自己。
在被动收到正确加密的预身份验证包后，我们知道我们可以期望发送方开始与我们进行身份验证，我们可以戳粒状防火墙漏洞，只允许发送方能够与我们的TLS服务器交谈。这种预身份验证操作模式也被称为单数据包授权（SPA）。
SPA并不是一个完全适合的设备认证协议。它仅仅有助于减轻第一个数据包的问题。在不淡化我们通过使用预身份验证所获得的属性的重要性的情况下，它不能替代更健壮的相互身份验证协议，如TLS或IKE（互联网密钥交换）。
图8-2.拥有预授权密钥的客户端可以发送一个已签名的数据包，以设置对TCP连接的期望。如果没有它，就不会发送任何确认信息。
3.1 FireWall KNockOPerator（fwnop）
fwknop是一个开源工具，代表“防火墙KNock操作器”，并使用SPA进行授权。它与多个操作系统兼容，并直接与主机防火墙集成，以创建严格针对特定需求的临时异常。
3.2 Short-Lived Exceptions
当fwknop接收到一个有效的SPA数据包时，其内容将被解密和检查。已解密的有效负载包括发送方正在请求访问的协议和端口号。fwknop使用此方法来创建防火墙规则，允许从发送者到那些特定端口的流量——这些规则在可配置的一段时间后就会被删除。默认值是30秒，但在实践中，您可能只需要几秒钟。
如前所述，fwknop创建的规则是作用域很严格的。它只允许发件人的IP地址和发件人请求的目标端口。可以通过策略限制可能请求的目标端口。此外，发送方还可以指定一个源端口，从而进一步限制了规则的范围。
3.3 SPA Payload
fwknop SPA实现有7个强制性字段和3个可选字段。其中包括用户名、访问请求本身（是哪个端口等），一个时间戳，和一个校验和：
· 16 bytes of random data
· Local username
· Local timestamp
· fwknop version
· SPA message type
· Access request
· SPA message digest (SHA-256 by default)
一旦客户端生成了有效负载，它就会被加密，然后添加一个可选的HMAC（散列消息身份验证码），并形成并传输SPA数据包。
3.4 Payload Encryption：有效载荷加密
支持两种加密模式：AES（高级加密标准）和GnuPG (Gnu隐私保护）。前者是对称的，后者是不对称的，为了满足多种用例和多种首选项。个人应用程序或小型安装可能更喜欢AES，因为它不需要任何GnuPG工具。AES在数据量和计算开销方面也更为出色。但它确实有一些缺点，几乎所有的缺点都源于它是一个对称算法。
对称加密带来困难的密钥分发问题，超过一定规模，这些挑战可能会变得站不住脚。利用GnuPG加密模式解决了这些问题中的大多数，并且是推荐的操作模式，尽管它的性能不如其他同类模式。
3.5 HMAC
fwknop可以配置为在其有效负载的末端添加一个HMAC。HMAC通过保证消息是真实的来防止篡改。这一点很重要，因为否则攻击者可以任意修改密文，而接收者将被迫处理它。您可能已经注意到，有一个消息摘要与纯文本一起计算和存储。这个摘要有助于减轻密文被修改的攻击，但它也不理想，因为这种方法（称为身份验证然后加密或AtE）容易受到一些小类的攻击。向加密的有效负载中添加一个HMAC可以防止这些攻击的有效。
此外，解密例程通常比HMAC例程复杂得多，这意味着它们更有可能遭受漏洞。对密文应用一个HMAC允许接收方执行一个轻量级的完整性检查，帮助确保我们只向解密例程发送可信的数据。强烈建议将fwknop配置为使用HMAC。
四、网络模型中的零信任应该在哪里？
通过更好地理解网络层模型，我们现在可以看看在网络堆栈中最好地应用零信任控制。有两个主要的网络安全套件： TLS和IPsec。TLS（SSL是其前身）是这两者中最常见的一种。许多应用层协议都支持TLS来保护流量。IPsec，或互联网协议安全，是一种替代协议，更常用于保护像vpn之类的东西。
尽管TLS的名称中有“传输”，但TLS并不存在于TCP/IP（互联网协议套件）模型的传输层中。它存在于应用层（在OSI或开放系统互连模型的第5层和第6层之间），因此在很大程度上是一个应用问题。
❗TLS作为一个基础设施问题
外围网络经常将TLS从应用程序中抽象出来，将责任从应用程序转移到基础设施中。在这种模式下，TLS被外围的一个专用设备“终止”，将解密后的流量转发到后端服务。虽然这种操作模式在零信任网络中是不可能的，但仍有少数策略可以将TLS部署为基础设施问题，同时仍然符合零信任模型。稍后会有更多报道。
相比之下，IPsec通常被认为是TCP/IP模型中inter层的一部分（OSI模型中的第3层或第4层，取决于解释）。在堆栈的后面，IPsec通常在主机的内核中实现。IPsec是为IPv6规范开发的。它最初是对IPv6的要求，但最终被降级为推荐状态。有两种安全网络传输的替代方案，问题变成了，一种比另一种吗？零信任的目标是为所有流量进行安全的通信。实现这一目标的最佳方法是构建默认提供安全通信的系统。IPsec是一种低级别的服务，它可以提供这种服务。
使用IPsec，可以确定主机到主机的通信。IPsec集成在网络栈中，可以配置为仅在建立安全通信信道后才允许包传输。此外，接收侧可以配置为仅处理已安全发送的数据包。在这个系统中，我们基本上在两个主机之间创建了一个“安全虚拟线”，只有安全的流量才能通过流动。与一次添加一个应用程序的安全通信的传统安全计划相比，这是一个巨大的好处。仅仅是保护两个设备之间的通信并不足以建立一个零信任的网络。我们需要确保每个单独的网络流都得到授权。有几个选择可以满足这个需求：
· IPsec可以在每个应用程序中使用唯一的安全关联（SA）（参见RFC 4301，第4.4.1.1节）。然后，只允许经过授权的流来构建这些安全策略。
· 过滤系统（软件防火墙）可以在IPsec之上进行分层。我们将在本章的后面讨论在零信任中进行过滤的作用。
· 应该使用应用程序级的授权来确保通信得到授权。这可能涉及到标准的授权技术，如访问令牌或X.509证书，同时将强加密和认证责任委托给IPsec堆栈。
· 对于一个真正的“皮带和吊带”系统，相互认证的TLS可以分层在现有的IPsec层之上。这种防御深度方法提供了两层加密（mTLS，或相互TLS，和IPsec），如果其中一个受到损害，则保护通信，以牺牲复杂性和增加的开销为代价。
4.1 客户端和服务器拆分
虽然IPsec有许多有益的特性，但它的缺乏普及给它在当今系统中的使用带来了现实世界的障碍。人们将看到的问题可以分为三个方面：
· Network support
· Device support
· Application support
4.2 网络支持问题
网络支持可能会阻碍IPsec在野外的使用。IPsec引入了几个新的协议，其中两个协议（ESP，或封装安全有效负载和AH，或身份验证头）是新的IP协议。虽然这些协议在简单的局域网（局域网）中得到了完全的支持，但在某些网络上，传输这些数据包可能是一个相当大的挑战。这可能是由于错误配置的防火墙，NAT（网络地址转换）遍历，或路由器被故意配置为不允许流量流动。例如，亚马逊网络服务（AWS），一个大型的公共云提供商，不允许在其网络上传输ESP或AH流量。像企业或图书馆这样的公共热点对IPsec流量的支持也不稳定。为了缓解这些问题，IPsec还支持在UDP帧中封装流量（如图8-3所示）。这种封装允许不适宜使用的网络传输流量，但它增加了系统的额外复杂性。
图8-3. IPsec支持将ESP数据包封装在UDP数据包中，使其看起来像正常的UDP流量
4.3 设备支持问题
设备支持也可能是推出受ipsec保护的网络的一个主要因素。IPsec标准很复杂，有许多配置选项和密码套件。关系中的两个主机都需要同意一个共同的协议和密码套件。密码套件尤其经常需要调整，因为妥协被披露。在IPsec系统中，发现更强的密码套件是一个真正的问题。公平地说，TLS需要处理这些相同的问题，但是由于在系统的内核中实现IPsec的性质，在较新的协议和密码套件上的进展自然会变慢。IPsec还需要在此关系中进行设备的主动配置。在具有不同设备功能的客户端/服务器系统中，配置客户端设备可能是相当具有挑战性的。桌面操作系统通常可以配置为支持不太流行的协议。然而，移动操作系统不太可能以一种符合零信任模型的方式完全支持IPsec。
4.4 应用程序支持问题
与基于tls的典型安全性相比，IPsec对系统配置提出了额外的要求。一个希望使用IPsec的系统需要配置IPsec策略，启用对所需的密码套件的内核支持，并运行一个IKE守护进程，以促进IPsec安全关联的协商。与基于库的TLS方法相比，这种额外的复杂性可能会令人生畏。当许多应用程序已经内置TLS支持时，这就加倍了，这似乎为网络安全提供了交钥匙解决方案。
需要注意的是，虽然库方法乍一看似乎更有吸引力，但在实践中它呈现了相当多的隐藏复杂性。应用程序经常支持更常见的服务器TLS，但忽略了公开配置，以提供创建经过相互身份验证的TLS连接所需的客户端证书。此外，系统管理员可能需要调整配置，以应对最近暴露的漏洞。对于大量的应用程序，找到需要调整的特定于应用程序的配置可能会阻碍关键修复程序的推出。
web浏览器通常是进入组织系统的公共访问点。它对现代TLS的支持通常是非常好的（假设组织保持最新的浏览器版本的更新）。这个通用访问点减轻了配置的问题，因为有一小部分目标应用程序需要调整。在服务器端，许多组织正在转向通过本地守护进程保护网络通信的模式。这种方法将配置集中在单个应用程序中，并允许系统管理员提供网络安全的基底层。在某种程度上，它看起来非常类似于IPsec模型，但却使用TLS实现了它。
考虑到这两种方法的优点和缺点，系统管理员似乎可以找到一个实用的解决方案.
4.5 实用的方法
对于客户机/服务器交互，相互身份验证的TLS似乎是实现网络安全最合理的方法。这种方法通常涉及配置浏览器，以向服务器端访问代理显示客户端证书，这将确保连接经过身份验证和授权。当然，这就限制了对基于浏览器的应用程序使用零信任。
对于服务器/服务器交互，IPsec似乎更容易接近。服务器机组通常处于更受控的配置下，网络环境也更为知名。对于不支持IPsec的网络，可以使用UDP封装来避免网络传输问题。
4.6 微软服务器隔离
对于完全使用带有活动目录的微软Windows的环境，一个称为服务器隔离的特性特别吸引吸引力。通过利用Windows防火墙、网络策略和组策略，服务器隔离提供了一个框架，通过该框架可以使IPsec配置实现自动化。
此外，服务器隔离可以绑定到活动目录安全组，从而提供细粒度的由强IPsec身份验证支持的访问控制。虽然围绕公共网络上的IPsec传输的复杂问题仍然存在，但服务器隔离可能是在基于windows的环境中获得零信任语义的最实用的方法。
由于IPv6标准包括IPsec，作者希望随着网络采用的进展，它将成为这两种类型的网络通信的一个更可行的解决方案。
五、The Protocols
在本节中，我们将更详细地介绍相互验证的TLS（mTLS），并简要讨论IPsec，因为两者都是重要的协议。
5.1 IKE和IPsec
互联网密钥交换（IKE）是一种执行IPsec的身份验证和密钥交换组件的协议。它通常被实现为守护进程，并使用预共享密钥或X.509证书对对等点进行身份验证并创建安全会话。在这个安全会话中，将进行另一个密钥交换。然后使用第二个密钥交换的结果来建立IPsec安全关联，该关联的参数用于批量数据传输。让我们仔细看看。
❗IKEV1 vc IKEV2
IKE有两个版本，而且大多数软件套件都支持这两种版本。对于所有的新部署，强烈建议使用IKEv2。它比它的前身更灵活，也更可靠，后者过于复杂，性能更差。为了达到这本书的目的，我们将专门讨论IKEv2。
关于IKE和IPsec之间的关系，经常存在混淆。现实情况是，IPsec并不是一个单一的协议；它是一个协议的集合。IKE通常被认为是IPsec协议套件的一部分，尽管它的设计让它感觉自己是免费的，而不是一个核心组件。IKE可以看作是IPsec的控制平面。它处理会话协商和身份验证，使用协商的结果使用会话密钥和加密算法配置端点。
由于核心的IPsec协议被嵌入在IP堆栈中，所以IPsec的实现通常可以在内核中找到。由于密钥交换是一个相对复杂的机制，IKE被实现为一个用户空间守护进程。内核拥有有状态定义的活动IPsec安全关联，以及定义IPsec策略应该应用于哪个数据包的流量选择器。IKE守护进程处理其他所有事情，包括IPsec安全关联（SA）本身的协商（随后安装到内核中供使用）。
有关IKE和IPSec的更详细了解，请查看RFC 6071： IP安全（IPsec）和因特网密钥交换（IKE）文档路线图。
5.2 Mutually Authenticated TLS (mTLS)
TLS通常被称为其前身SSL，它是最常用于保护web流量的协议。它是一个成熟和易于理解的协议，被广泛部署和支持，并且已经被信任执行一些最敏感的任务，比如银行交易。它是HTTPS中的“S”。
当TLS用于保护web会话时，客户端会验证服务器证书是否有效，但服务器很少会验证客户端。事实上，客户端很少提供证书！TLS（mTLS）的“相互”前缀表示需要客户端证书验证（因此需要对TLS配置进行相互验证）。虽然对于正在发布给一般公众的服务，缺乏客户端身份验证可能是可以接受的，但对于任何其他用例都是不可接受的。互认证是符合零信任模型的安全协议的要求，TLS也不例外。
TLS握手的基础知识相当简单，如图8-4所示。客户端通过发送到服务器的客户端-hello消息启动会话，其中包括密码套件和压缩方法的兼容性列表。服务器从兼容性列表中选择参数，并使用服务器-Hello来定义它所做的选择，然后是服务器的X.509证书。此时，它还会请求客户端的证书。
图8-4：使用RSA密钥交换显示相互认证的TLS握手的简化图(RSA代表Rivest-Shamir-Adleman，基于开发密码系统的人的姓氏）
然后，客户端生成一个密钥，并使用服务器的公钥对其进行加密。它向服务器发送这个加密的密钥以及它的客户端证书，并提供少量证明它实际上是该证书的所有者。由客户端生成的密钥最终用于派生几个附加密钥，包括一个作为对称会话密钥的密钥。因此，一旦客户端发送了这些详细信息，它就有足够的信息来设置加密会话。它向服务器发出信号，表明它正在切换到会话加密；然后服务器验证客户端并发送类似的消息，会话完全升级。
对于零信任网络，将加密职责与应用程序本身分离是个好主意（图8-5)。在这种情况下，我们所保护的资源是设备，因此，它独立于工作负载本身是很有意义的。这样做还还减轻了许多痛点，包括零日缓解、性能惩罚和审计。
对于像IPsec这样的协议，这种职责分离是设计的一部分，但TLS并非如此。历史上，应用程序直接说TLS，加载和配置共享的TLS库以进行远程通信。我们一次又一次地看到了这种模式的粗糙斑点。共享库在整个基础设施中随处可见，被许多项目消耗，所有这些项目都具有独立的版本和配置。有些语言比其他语言有更灵活的库，这限制了您执行最新和最佳库的能力。最重要的是，很难确保所有这些应用程序都确实以正确的方式使用TLS，并对已知的漏洞保持最新状态。
图8-5.传统的应用程序包括TLS库，并自行执行这些职责。使用本地TLS守护进程意味着更好的控制和一致的性能。
为了解决这个问题，将TLS配置的处理移动到控制平面是很有用的。到服务的连接由TLS守护进程代理，然后在本地转发到应用程序。TLS守护进程配置了系统证书、信任权限和端点信息——这样。通过这种方式，我们可以确保所有软件通过TLS接收设备身份验证和安全性，而不管其支持如何。此外，由于存在零信任网络白名单流，因此我们可以通过将白名单流限制为已知的TLS端点来确保应用程序流量得到保护。
到目前为止所讨论的所有TLS的复杂性和组件主要适用于最初的TLS握手。TLS握手有两个主要目的：身份验证和创建会话密钥。TLS握手在计算上很昂贵，因为制作和验证它们需要进行数学操作。
这是安全性和性能之间的一种明显的权衡。虽然我们强烈希望有这种级别的安全性，但如果我们将这些操作应用于所有通信，那么对性能的影响是非常昂贵的。非对称密码学在安全引入和身份验证过程中非常重要，但只要身份或身份验证，它的强度可以与对称密码学相匹配。
对称加密使用单一密钥而不是公钥/私钥对，并且在计算上比非对称密码学少一个数量级。这就是TLS握手和会话密钥的概念所在。
一些非常聪明的数学家和密码学家意识到，我们可以使用强大而昂贵的操作来安全地生成一个单一的秘密——一个可以在双方之间共享的秘密（图8-6）。TLS的密钥交换组件生成这个共享密钥，并确保双方都知道它。
图8-6. TLS握手生成用于批量传输的对称加密密钥。IPsec也使用了类似的机制。
然后将此共享密钥用作对称加密算法的输入，该算法应用于握手后的所有会话流量。这种方法确保了整个会话从非对称加密的优势中获益，而不会继承与非对称加密方案相关的任何性能影响。
当涉及到批量加密算法的选择时，TLS支持许多算法，但建议是非常一致：只需使用AES。它检查了所有理想的方框，包括它没有专利，在硬件中广泛实现，以及实际上在软件中普遍实现的事实。它的表现非常好，严格审查/审查，据公众所知仍没有破坏。许多人说“AES已经足够好了”，虽然在安全协议方面这可能是一个难以接受的丸，但这样的声明从未如此接近事实。
在安全通信时，消息的真实性是一个重要的非必需属性。加密提供了机密性，但如果没有消息的真实性，您如何确保消息的完整性？在解密过程中没有错误，很难或不可能区分被篡改的消息和真实的消息。一些加密模式（如AES-GCM；GCM代表伽罗瓦/计数器模式）同时提供了消息的机密性和真实性保证。但是，这些保证仅适用于批量加密；有几个TLS交换不受批量传输规范的保护，而消息真实性方案也保护了它们。
❗有时需要明确的真实性
由于一些批量加密算法提供了消息的完整性保证，因此并不总是需要对每个数据包执行显式的真实性检查。相反，TLS将更倾向于对批量传输的内置保证，并依赖于对与批量传输无关的所有数据包的显式真实性检查（例如，TLS控制消息）。
就选择而言，选项仅限于MD5（消息摘要5）和SHA（安全哈希算法）系列的散列。前者已经被加密方式破解了很长一段时间，这使得SHA家族成为在TLS下确保消息完整性的唯一合理选择。当使用较弱的SHA变体，SHA-1时，甚至还存在一些担忧，因为面对不断增长的计算能力，它现在被认为是脆弱的。因此，建议在硬件和软件约束条件下选择可以合理部署的最强SHA散列。此外，还建议尽可能使用具有内置真实性的批量加密，因为它通常比依赖于脱节的真实性机制更具有性能和安全。TLS版本1.3要求使用经过身份验证的加密。
就像任何其他用于设备身份验证的协议一样，TLS也有其起伏现象。首先，由于TLS在网络堆栈中的位置，所以它是依赖于协议的。它通常是作为一种基于tcp的协议实现的，尽管也有一种基于udp的变体DTLS（D是数据报的意思）。DTLS的存在突出了TLS在堆栈中的位置的不足。因此，当TLS被用于保护IP协议而不是其本地支持的IP协议时，如TCP或UDP时，其回报就会下降。
另一件需要考虑的事情是对自动化的要求。TLS通常作为外围网络中的基础设施服务部署，这些中介通常位于外围。但是，只要中间端点和上游端点被计算机网络分隔，这种操作模式就不适合用于零信任网络。
在零信任网络中，利用说tls的中介的应用程序必须与中介本身在同一主机上。因此，使用TLS保护数据中心零信任网络需要额外的自动化来配置应用程序，以通过这一外部安全层说话。它不像IPsec等其他协议那样“免费”出现。
尽管如此，它仍然是当今保护面向客户的零信任网络的最佳选择。TLS在软件和传输（即全球的中介网络）中得到了广泛的支持，可以进行直接和可靠的操作。大多数web浏览器本机支持相互身份验证的TLS，这意味着可以使用零信任原则来保护资源，而不需要立即需要专门的客户端软件。有关mTLS的更详细技术讨论，请参阅RFC8120：HTTP的相互身份验证协议。
六、信任云流量：面临的挑战和注意事项
云为组织打开了一个可能性的世界，允许企业快速扩大规模并访问无限的资源。然而，这种新发现的自由也带来了挑战，特别是在信任来自云环境的流量方面。在过渡到云系统时，有几个挑战，包括维护遵从性和安全标准，保护抵御网络威胁，确保网络可见性，导航各种可用的云提供商，以及保持成本合理：
信任云流量的主要问题之一是确保遵从法规和安全最佳实践。将其基础设施转移到云的组织必须确保其数据是安全的，并且不会与未经授权的各方共享，这在多租户公共云环境中可能是一个挑战，因为多个组织的数据通常存储在同一个物理服务器上。跟上最新的法规和安全协议，对于避免数据泄漏、法规遵从性违规和其他严重后果至关重要。
云环境很容易受到一系列网络威胁，包括针对平台本身的恶意行为者（例如，分布式拒绝服务攻击），以及针对个人用户及其数据的威胁（例如，网络钓鱼诈骗或勒索软件）。此外，由于在这些环境中存储了大量的数据，云提供商已经成为对国家支持的参与者越来越有吸引力的目标，这使得具有强大的安全措施至关重要。
传统的本地解决方案往往受到物理约束的限制，而云网络往往更加灵活和扩展。组织必须知道，他们将失去对其基于云的网络的一些可见性，并且必须注意网络监控能力，以确保对他们的系统有足够的可见性。
目前有各种各样的云服务提供商，每个公司都有其独特的产品和安全协议。理解云提供商之间的差异很重要，因为它允许组织对信任哪些人做出明智的决定。不同的提供商提供不同级别的安全和服务，而理解这些差异是为组织的特定需求做出正确决策的关键。在供应商之间的切换可能既昂贵又耗时，所以从一开始就选择正确的供应商是很重要的。
成本通常是一个重要的因素，因为组织必须愿意投资于适当的安全控制和监控工具，以确保数据安全。在提供商之间的切换也可能是一个昂贵和耗时的过程。那些选择多云或混合云解决方案的人必须考虑到管理多个提供商的额外成本，考虑到管理多云或混合环境的复杂性，以及数据跨不同地区和提供商传输可能增加的延迟。
尽管存在这些挑战，组织仍然可以采取各种措施来确保其流量的可信度，无论是在云计算中还是在其他方面。这些内容可以包括但不限于以下内容：
· 确保遵守法规遵从性和安全标准。
· 监控基于云的网络是否有可疑活动，保持网络可见性，并确保数据在静止和传输中被加密。
· 使用最新的安全协议，如相互TLS（mTLS）
· 使用多因素身份验证（MFA）来增加安全性
· 定期进行漏洞扫描和渗透测试
· 使用入侵检测/预防系统（IDS/IPS）；对工作人员进行最佳安全措施的培训
· 实施访问控制策略
· 定期修补和更新系统
· 监视是否未经授权的云访问
· 实施安全事件管理计划
零信任网络范式对于确定来自云环境的流量的可信度特别有用。通过利用对所有入站/出站流量的相互身份验证、访问控制、日志记录和监控，组织可以确保只有经过验证的端点才能跨系统发送和接收数据。此外，TLS和IPsec等加密技术可以在数据穿越外部网络时保护其完整性，进一步有助于确保安全的传输介质。
七、云访问安全代理（CASB）和身份联盟
云访问安全代理（CASB）在访问云资源时提供了额外的安全层。casb通常作为组织网络和提供商之间的基于云的代理部署，提供进出云的所有流量的可见性和监控。云访问安全代理的一些功能包括但不限于以下内容：
通过检测和屏蔽敏感信息，防止数据通过云泄漏
监控恶意软件、勒索软件、网络钓鱼攻击等恶意活动，并采取措施防止威胁传播
确保内部数据在传输过程中和静止状态下被加密，并保持数据的完整性
例如多因素身份验证（MFA）和基于角色的访问控制（RBAC），这使得攻击者更难获得对组织资源的未经授权的访问
除了所讨论的功能之外，casb还可以应用和维护网络安全策略，如访问控制列表（acl）和网络分割。它们还提供了监控和日志记录功能，使组织能够检测到可疑的或潜在的有害活动。身份联合是建立云流量信任的另一个关键组成部分。像SAML和OAuth这样的联邦身份服务是建立信任的重要工具，因为它们允许组织跨多个云应用程序建立单点登录（SSO）功能。通过将资源限制给已验证的用户，可以显著降低未经授权访问的风险。
八、Filtering
过滤是指网络上的系统允许或拒绝数据包的过程。当大多数人考虑过滤时，他们通常会设想一个防火墙，一个位于网络和应用程序之间的服务或设备，来过滤进入或来自该设备的流量。防火墙确实可以提供过滤，但它们也可以提供其他服务，如网络地址转换（NAT）、流量塑造和VPN隧道服务。过滤可以由传统上不考虑的其他系统提供，如路由器或托管交换机。重要的是要记住，过滤是一个简单的服务，可以在网络系统中的许多点上应用。对于没有安全思维方式的用户来说，过滤可能会相当令人沮丧，因为它会阻止所需的网络通信。摆脱这些麻烦，并假设用户知道他们想要什么不是更好吗？不幸的是，善意的用户可以简单地公开他们在进一步检查时不愿公开的服务。在始终保持互联网连接的早期，用户的电脑经常会意外地公开公共互联网上的文件共享和聊天服务。
过滤为网络通信提供了一种制衡的类型，迫使用户考虑一个特定的连接是否真的应该跨越一个敏感的边界。到目前为止，许多零信任的概念都集中在高级加密和认证系统上。这是因为网络安全的这些方面在网络设计中并不像它们应该做的那么普遍。然而，我们不应该淡化网络过滤的重要性。它仍然是零信任体系结构的一个关键组成部分，因此我们将从三个部分来探讨它：
过滤主机上的流量
通过网络中的对等主机筛选流量
通过两台主机之间的设备过滤流量
8.1 Host Filtering
主机过滤将网络端点代理为其自身安全中的主动参与者。其目标是确保每个主机都被配置为过滤其自己的网络流量。这与传统的网络设计不同，后者的过滤被委托给一个远离主机的集中式系统。
集中式过滤通常是使用硬件防火墙来实现。这些防火墙利用特定于应用程序的集成电路（asic）来有效地处理流经设备的数据包。由于该设备通常是许多后端系统的共享资源，因此这些asic对于它完成过滤所有这些系统的聚合流量的任务至关重要。使用asic会以牺牲灵活性为代价，从而带来原始的性能.
软件防火墙和现代操作系统中的防火墙一样，比硬件防火墙要灵活得多。它们提供了一套丰富的服务，比如基于时间和任意偏移值定义策略。许多这些软件防火墙可以通过新的模块进行进一步扩展，以提供额外的服务。与早期的互联网不同，所有的现代桌面和服务器操作系统现在都通过基于主机的防火墙提供某种形式的网络过滤：
IPtables
Berkeley Packet Filter (BPF)
应用程序防火墙和其他主机防火墙
Windows Firewall service
也许令人惊讶的是，无论是iOS还是Android都没有配备基于主机的防火墙。苹果的iOS安全指南，苹果平台安全，指出，它认为防火墙是不必要的，因为iOS上的攻击面积“通过限制侦听端口，删除不必要的网络工具，如网络，shell，或网络服务器。”谷歌并没有发布官方的安全指南。Android，可能是因为它能够运行非播放商店批准的软件，如果用户选择这样做，它确实可以安装第三方防火墙。
零信任系统假定该网络是敌对的。因此，它们在每个可能的点上过滤网络流量，经常使用主机上的防火墙。添加主机上的防火墙可以通过过滤出不需要的网络流量来减少主机的攻击面。虽然基于软件的防火墙没有与基于硬件的系统相同的吞吐量能力，但过滤分布在整个系统中（因此只能看到总流量的一部分）这一事实在实践中通常不会导致性能下降。
开始使用主机上的过滤很简单。配置管理系统对管理主机上的防火墙有很好的支持。在编写安装服务的逻辑时，最容易捕获允许的安装和配置例程旁边的连接。相反，在远程系统中进行过滤更加困难，因为异常与需要它们的应用程序分离。
主机上的防火墙也为可编程过滤的新用途提供了机会。我们在本章前面讨论过的单包授权（SPA）就是这一想法的一个很好的例子。SPA以编程方式管理主机上的防火墙，以减少主机上的服务的攻击面。这是有利的，因为有时，精心设计的恶意数据包可以用来利用网络服务中的一个弱点。例如，服务在处理请求之前可能需要身份验证和授权，但身份验证逻辑可能有一个缓冲区溢出错误，攻击者可以使用它来实现远程代码执行漏洞。通过引入过滤层，我们可以将更复杂的服务接口隐藏在一个管理防火墙规则的更简单的系统后面。
当然，在使用主机上的防火墙专门用于网络过滤时，也存在一些问题。其中一个问题是，如果主机受到破坏，位于位置的防火墙将变得毫无意义。能够访问主机并提升其权限的攻击者可以删除主机上的防火墙或调整其配置。不用说，这是一件大事，因为它消除了系统中的一层防御能力。这就是为什么过滤传统上是由一个单独的设备来处理的，而不是有潜在风险的主机。
这种方法突出了安全设计中隔离的好处，主机上的过滤可以从中受益。随着该行业向虚拟化和容器化等隔离技术的方向发展，很明显，这些技术为进一步隔离主机上的过滤提供了机会。如果没有这些技术，唯一可用的隔离形式是本地用户特权。例如，在基于unix的系统上，只有根用户能够对防火墙配置进行调整。然而，在一个虚拟化系统中，人们可以在虚拟机之外实现过滤，这为防止对过滤系统的攻击提供了强有力的保证。事实上，这就是Amazon的安全组特性的实现方式，如图8-7所示。
图8-7. Amazon EC2安全组将过滤移到虚拟机之外，以改善隔离
主机上过滤的另一个问题是与将过滤深入推进网络相关的成本。想象这样一个场景，很大比例的流量被主机过滤过滤。通过应用最接近目标系统的过滤，网络传输这些数据包需要额外的成本，只有它们最终被丢弃。这种情况还增加了拒绝服务攻击的可能性，迫使内部网络基础设施路由大量无用的流量，以及淹没相对较弱的软件防火墙。因此，虽然主机上的防火墙是开始考虑进行过滤的最佳地点，但如果它们是进行过滤发生的唯一位置，那么它们就会产生风险。我们将讨论如何在“中介过滤”中推动过滤输出到网络中。
8.2 Bookended Filtering
Bookended过滤不仅是在收到数据包时应用策略，而且在发送它们时应用策略。这种过滤模式在传统网络中并不常见。它给网络设计带来了一些有趣的优势，我们现在将进行探索。
出口（与入口相反）是一个术语，用来描述正在离开主机的网络流量。这种类型的过滤通常用于管理从专用网络到公共网络的通信，但很少在专用网络中使用。出现这种情况有几个原因：
· 入口过滤更容易推理，因为在构建防火墙规则时可以枚举侦听服务。出口过滤需要更多的簿记来捕获主机打算如何进行通信。
· 入口过滤通常被认为足够好，足以停止网络中不需要的通信。
· 出口滤波需要对每一个预期流的知识，这在传统网络中是不常见的。
Bookended过滤使用零信任网络中的出口过滤来进一步强化系统。通过图8-8中所示的示例，我们可以看到这种硬化是如何有益的。让我们考虑一个系统，其中数据库服务器设置了入口过滤规则，以允许从应用程序服务器访问。一位善意的管理员正在研究一些网络连接问题。在他们的调查过程中，管理员放松了数据库的进入过滤，以排除它导致了这个问题的可能性。至关重要的是，该管理员在反驳该理论后忘记了恢复更改。这个错误在一段时间内删除系统中的防御层。更糟糕的是，发现这种失去的防御可能是困难的，因为预期的通信（从应用程序服务器到数据库服务器）继续工作。
图8-8.书签过滤可在意外情况下提供保护
在这种情况下，即使在系统中存在这种严重的错误配置，具有普遍的图书结束过滤的网络也会受到保护。在某种程度上，它类似于群体免疫——当绝大多数成员接种了一种疾病的疫苗时，一个社区为未接种疫苗的成员提供的集体利益。书末端过滤不是预防疾病，而是保护配置错误的系统免受错误配置的潜在影响。
在合适的条件下，在一个系统中构建图书过滤并不像看起来那么困难。需要以一种可以以编程方式消耗的方式来捕获通信流。捕获这些流的最佳方法是通过定义细粒度的进入规则。这些进入规则应该允许基于每个客户机的服务器角色来访问服务，而不是广泛地开放对服务的访问。通过捕获这个细节，我们构建了一个依赖图，从中可以计算和应用整个系统的出口规则。
就像我们在主机过滤中讨论的那样，出口过滤与系统中运行的应用程序隔离时最好应用。同样的见解也适用于这里：最好在虚拟化或容器化环境的另一边实现过滤，以具有最健壮的过滤机制。除了过滤实现之外，考虑用于构建出口过滤规则的数据的隔离是很重要的。从服务发现系统等动态数据源计算数据似乎很有吸引力，但当流数据库与正在运行的系统隔离时，书末端过滤是最有效的。相反，请使用一个缓慢变化的数据库，特别是一个需要人类来审查更改的数据库。
❗PROJECT CALICO
Calico项目是一个用于动态调度工作负载的虚拟网络系统。工作负载是一个通用术语，适用于任何需要在数据中心中运行的应用程序。此应用程序可以在容器内或虚拟机内。Calico从运营互联网的过程中吸取了教训，并将其带入数据中心，创建一个更简单的网络，可以随着网络规模的增长而有效地扩展。Calico并不是一个完全的零信任解决方案，但它确实呼应了零信任网络的一些想法。Calico将在整个网络中分发过滤，这将在主机上强制执行。这些主机是根据描述整个网络的数据库中的更改动态地重新配置的。这个设计看起来与我们前面讨论过的主机过滤非常相似。
Calico还包括我们所讨论的书端过滤概念。这意味着连接两端的主机正在根据它们对应该允许哪些连接的知识来过滤流量。这种网络通信的双重执行被视为网络结构中的二次防御。
8.3 Intermediary Filtering
中介过滤是指发送方或接收方以外的设备可以而且应该参与一个零信任网络中的流量过滤。这至少意味着周边过滤可以在零信任网络中发挥作用，而最多可以在网络结构中的中间设备中发挥作用。正如我们在“主机过滤”中所讨论的，当不良流量的比例非常高时，只过滤仅在目的地的流量就会给网络带来额外的成本。高通量过滤流量通常来自互联网进入流量。
理想情况下，我们希望尽快过滤流量，以减少过滤的影响和成本。对于这个应用程序，在位于零信任网络和互联网之间的外围系统上进行过滤是理想的。这些设备通常需要基于硬件，以有效地过滤进入系统的数据包。
在零信任网络中，周边过滤器也可以是一个重要的检查和平衡。周长过滤器应该是全局规则和粗粒度主机策略的组合。通过保持全局规则与主机策略分开，就定义了关于外部网络配置的不变量。
此策略的异常应该可以追溯到依赖于这些异常的主机基础设施，以及为实例化它们所采取的操作。最佳实现从主机策略本身获得这些异常。通过将主机策略与异常策略绑定，系统将在主机进出网络时更加一致。
但是，必须核实这些例外情况是否具有尽可能狭窄的范围。应对所有政策变化进行审查，以防止过于宽泛的例外情况，从而危及系统的安全。
❗UPNP被认为有害
从主机策略派生的外围策略不应该与UPnP（通用即插即用）合并，UPnP是一种用于重新配置消费者防火墙的技术。UP即插即用程序受到了正确的批评，因为网络上的任何应用程序都可以重新配置周边区域。在零信任模型中，在主机策略和在外围创建的异常之间存在一个信任链。
考虑到周界模型的缺陷，我们在这样一个积极的光线下讨论周界滤波似乎很奇怪。这里需要理解的关键细节是，零信任网络不会抛出所有的周界概念。相反，它们鼓励管理员从主机上开始，然后向外工作。外围设备最终以这种方式发挥作用，拒绝-服务缓解是迄今为止最显著的应用程序。在零信任网络中，一个令人兴奋的想法是使用主机策略数据库来动态地编程网络结构本身。这将导致一个软件定义的网络（SDN），它不会盲目地将数据包路由到目的地，而是积极地基于预期和允许的流来管理交换和路由策略。这就带来了一些好处：
· 潜在的恶意流量被阻止远离主机，减少了攻击表面。
· 主机上的软件防火墙由网络本身进行了增强，在网络中增加了额外的防御层。
与前面讨论的周长过滤一样，网络结构中的过滤应该被视为对基于主机的过滤的基底层的增强。它不能作为它的替代品。
❗转发和路由授权
当我们讨论过滤时，出现了一个主题——零信任网络利用相对缓慢变化的网络细节来分发执行，从而产生一个更安全的网络。这一观察结果打开了一个有趣的机会：我们能否将强制执行传播到网络基础设施中，有效地将这些管道从一个简单的数据包传输系统提升到一个智能网络结构中？想象一下，有一个SDN控制器，它只根据一个强大的身份验证和授权过程的结果来安装流指令。希望访问网络资源的客户端可以向控制平面发出信号，提供网络访问请求以及适当的凭据。请求授权成功后，网络将安装并可用，但仅适用于已授权的特定流。
九、场景演练
在这种情况下，Bob在连接到一个公共匿名网络（例如，Tor或I2P）时，正在使用他的浏览器访问电子邮件。在这种情况下，确保Bob在不减少安全姿态的情况下保持生产力是至关重要的。这是通过授予Bob只读访问电子邮件来实现的。同样，零信任的一个基本要素是要记住，像这样的策略不是静态的，而是动态的，应该经常进行审查。
例如，可以专门生成一个报告，以评估有多少用户实际上正在使用公共匿名网络及其跨应用程序的访问模式。这将有助于政策的持续改进。请查看图8-9，它显示了控制平面组件：用户数据、活动日志和监控日志。信任引擎和策略引擎的详细信息如图8-10所示。
图8-9.用户数据、活动日志和监控日志
图8-10.策略引擎和信任引擎规则
9.1 用例： Bob请求通过匿名代理网络访问电子邮件服务
以下是我们对Bob的请求的了解：
· Bob在机场使用匿名代理网络时，通过web应用程序发送访问电子邮件服务的请求。
· Bob的请求是在使用浏览器访问电子邮件时使用最新版本的TLS。
· Bob正在使用他的工作笔记本电脑，设备标识为“ABC”，这完全符合组织策略。
· Bob使用了一种强大的抗钓鱼MFA方法进行身份验证。
· Bob是在办公时间提出这个要求的。
以下是我们对电子邮件服务的了解：
· 电子邮件由公共云供应商托管，并作为SaaS服务提供。
· 所有访问电子邮件的权限都需要一个加密的TLS通道。
· 持续监测定期从全球不同地区运行运行状况调查，以确保电子邮件服务是在线的。
请求分析
1.Bob的访问请求(action: access-email, app-id: Browser, 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。
第四条规则适用于当前请求，因为请求是电子邮件服务，是通过公共匿名代理网络进行的。只允许只读访问电子邮件。
第五条规则不适用，因为请求使用了强大的抗钓鱼MFA机制。
第六条规则不适用，因为该请求不适用于帮助台支持服务中心门户。
第七条规则不适用，因为它是默认的，并且只适用于任何其他先前的规则不适用。在这种情况下，第五条规则被适用于允许该请求。
7.策略引擎会向强制执行组件发送一个允许允许的操作请求。
8.强制执行组件从策略引擎接收结果，并将对电子邮件服务的只读访问权授予给Bob。
Summary
本章主要讨论了流量如何在零信任网络中获得信任。我们梳理了加密和真实性之间的区别——这两个概念相关但截然不同。零信任网络在通信中需要真实性，而且大多数网络在进行加密其流量方面也获得了价值。
我们探讨了网络通信中的第一数据包问题。现代的认证系统相当复杂，这导致了很大的攻击表面积。我们讨论了将这些服务隐藏在单包授权系统后面，这是一个相对简单的服务，可以用于隐藏更复杂的身份验证系统，如TLS。
然后，我们讨论了两种进行网络流量加密和认证的协议： TLS和IPsec。我们提供了指导，表明相互身份验证的TLS（mTLS）最适合于客户机/服务器交互或异构环境，而IPsec似乎非常适合于数据中心内部（特别是在不存在网络地址翻译的情况下）。
我们还讨论了云流量以及基于云的服务对确定流量的可信度提出了额外挑战的事实。我们讨论了一些挑战，利用基于云的流的身份验证和授权机制，以及云本地安全工具来应用访问控制策略和执行最小特权原则。
零信任网络仍然需要数据包过滤功能，它们将其部署在整个网络中。我们描述了可以部署在这样的网络中的三种类型的过滤：主机过滤、书签过滤和中间过滤。每种类型的过滤都为网络增加了额外的鲁棒性，并且可以使用系统自动化和预期网络通信的共享数据库部署在网络中。
最后，本章以用户场景演练结束，其中流量通过公共匿名代理进行路由，这将影响用户访问电子邮件系统的方式。这是一个现实世界的场景，必须在生产率和保持一个安全的姿态之间取得平衡。
下一章介绍了我们迄今为止所学到的所有概念，并制定了创建您自己的零信任网络的计划。