F5安全专栏 | 什么是零信任架构（ZTA）？

Posted 2023-04-09 F5lnc

作者 | Malcolm Heath 、 Sander Vinberg

了解什么是零信任架构（ZTA）以及如何将其应用于你的环境

01 前言

在过去的几年中，“零信任”概念一直是网络和应用访问领域的主题之一。我们希望通过一组简单的观念来表述零信任的核心特征；同时，这些观念不仅适用于访问，还适用于更广泛的网络安全领域。

我们将从系列文章介绍一个涵盖了围绕零信任广泛概念的框架，并将其与激励当今应用安全业务领导者的现有业务背景联系起来。最后，我们还提出零信任观念系统的特征描述，即应对当前和新兴威胁的工具和安全实施背后的驱动力，这些内容将是后续文章的重点。

我们将从以下方面，和大家一起全方位了解“零信任”：

• 零信任概念
• 解决方案&案例
• F5 资源

*本文即为系列文章第一篇《什么是零信任架构》，开启 F5 “零信任”知识库之旅~

02 解读零信任这个概念

自从1994年 Stephen Paul Marsh 在他的博士论文中提出 "零信任 "这个术语以来，它已经经历了很多变化。事实上，由于变化太多，安全业从业人员经常发现自己被要求实施零信任，但却不知道如何去做。

值得庆幸的是，随着 NIST SP 800-207 在2020年8月的发布，我们有了一份文件，可以帮助 CISO、运营团队和架构师结合零信任理论和实际实施之间的差距。由于 "零信任 "一词可以适用于原则、架构设计、实施这些设计的举措和产品，我们将主要依靠 NIST 800-207 文件，因为它在区分这些方面和提供有用的指导方面是独一无二的。

03 我们以前有多少信任？

零信任架构（ZTA）是为了解决更传统的安全架构的一些缺点，所以从描述传统的安全架构开始是有意义的。

在传统的安全架构中，广义上讲，有一个硬边界，通常由一个或多个防火墙定义，还有一个用于远程访问的 VPN ，以及一些集中的认证管理，以识别用户并授予访问权。一般来说，一旦通过认证的用户进入安全边界，他们就很少受到控制，也就是他们处于一个 "受信任 "的区域，因此可以访问文件服务器，连接到网络中的其他节点，使用服务，诸如此类。

当然，一些企业在相当长的时间里已经意识到了这种一般方法的缺点，所以在一些架构中，可能会有一个边界包含着一个边界，或者控制点和重新认证点，但总的来说，对传统模式的一般调侃描述是 “外硬内软”。我们偶尔会听到有人把这描述为 “有墙的花园”。墙被认为是把坏人挡在外面，让免费的生产力在里面。

无论我们如何设计、实施，这样的设计都有几个缺点。主要的弊端有以下几点：
1弊端一
如果攻击者能够穿透边界，他们往往可以不受阻碍地进行探索，使用横向移动，攻击界限内的机器，并提升他们的权限，并且往往很难被发现。

2弊端二
人们很少关注单个认证实体的行为。一个被认证的用户可能会做一些非常出格的事情，并且不会被发现。

3弊端三
总体上缺乏细化的访问控制，允许用户（无论是否有恶意）访问，并且不严格要求数据和服务。

4弊端四
对外部威胁的明显关注并没有解决恶意的内部人员，也没有解决可能已经获得立足点的外部攻击者。

5弊端五
当企业从内部环境向云、多云或混合环境过渡时，这种安全架构难以整合、实施和维护。

6弊端六
鉴于自带设备（BYOD）的流行，以及需要授予外部供应商、承包商和远程工作人员的访问权，界限内的所有设备都可以被信任的假设往往很难得到证实。

04 什么是零信任架构？

ZTA 通过重新定义整体架构来解决这些挑战，取消了单一大边界内的信任区域的概念。

相反，ZTA 将任何特定资源周围的信任边界压缩到尽可能小的范围。它通过在用户每次想使用任何资源时要求重新认证和授权来做到这一点。这将个人实体的身份和访问控制置于架构概念的中心。

05 零信任架构的优势

这种新的架构范式解决了旧模式中的许多缺陷。首先，它可以防止攻击者的横向移动。如果一个攻击者（内部人员或外部人员）设法进入 “内部”，他们将不断面临获得进一步访问的障碍，他们不得不在每一步重新认证和证明他们的身份。

ZTA 还使用实体的行为分析，而传统的访问控制往往只使用一组凭证作为其标准。用户参数，如一天中的时间、访问模式、位置、数据传输大小和许多其他可观察到的现象都被评估，以确定试图访问资源的实体是否以可接受的方式进行。如果一个实体开始尝试访问他们通常不访问的资源，或者在一天中他们通常不工作的时间，这些行为会触发警报，并可能自动改变授权。

将边界缩小到单个资源层面，可以实现非常细化的访问控制。例如，一些用户可以使用一组特定的 API，而其他用户则可以使用不同的子集。或者一个承包商可能只被允许访问他们支持的系统，而不允许访问其他系统。虽然这在传统的架构中是可能的，而且经常尝试，但 ZTA 的架构所提供的极其精细的访问控制可以使其更容易管理和监控。

此外，BYOD 也变得更容易管理。非企业设备可以被限制为只能访问一个子集的资源，或者根本无法访问，除非它们在补丁级别或其他品质方面满足某些特定要求。

如果 ZTA 的实施足够广泛和完整，可以完全移除外部边界，远程工作人员和承包商就不再需要被授予 VPN 访问权。他们可以简单地只访问他们需要的资源，而不访问其他资源，这可以简化甚至完全消除对 VPN 的需求，尽管后者在云环境之外的实践中很少实现。同样，使用这种架构，为来访客户提供的访客网络也相当容易实现；他们只被允许访问出站连接。

06 ZTA 的劣势

然而，这种对传统架构的彻底背离是有一定代价的。鉴于这至少在某些方面是一个全新的范式，目前的安全管理员需要时间来适应它。这种架构的实际实施通常需要对额外的控制进行大量投资，并伴随着学习、培训和支持成本。

整合 ZTA 是复杂的，维护它也是复杂的，有一个完全不同的访问授权模式，以及更多必须进行强大监控的地方。负载均衡的访问控制的优势可能会被管理这种复杂性的困难所抵消。而且，到目前为止，行为访问控制还没有被广泛实施，也很少能轻易实现。

最后，任何大型的架构变化都需要在保持业务运行和过渡到新架构之间取得平衡。迁移到 ZTA 需要仔细的计划、变更控制以及大量的时间和精力。

07 零信任到底有多新？

这个问题看起来让人感到疑惑。从原则层面来说，ZTA 听起来不像是一个全新的架构，而更像是以前的原则的增量，如基于角色的访问控制（RBAC）、深度防御、最小特权和 “假设破坏”。

然而，一旦我们开始勾勒出对每个请求实施重新认证的选项，就会更清楚这到底是一个怎样的实质性变化。出于这个原因，NIST 在2020年发布的文件中最有力的方面之一是强调了完成真正的 ZTA 所必需的几个核心组件：政策决定点（PDP）和政策执行点（PEP）。

每个企业资产前都有 PDP 和 PEP，每个请求都必须通过它们，这是 ZTA 与以前试图实施类似的、但范围较窄的原则之间最重要的、具有指示性的区别。

PDPs 和 PEPs 是抽象的能力，可以根据企业的需要采取不同的形式（下面会有更多介绍）。但在所有情况下，政策决定点是评估请求主体和被请求对象的整体态势并产生访问控制决定的组件。

政策执行点是负责根据政策决策点的输出，打开和关闭与特定资源的连接的组件。PDP和PEP可以合并或分布，在某些情况下，PEP将在主体系统上的代理（如雇员的笔记本电脑）和资源上某种形式的网关之间分割。但在所有情况下，PDP和PEP都代表了完成重新认证和重新授权每个请求这一基本目标的能力。

08 方法、变化和情景

现在应该很清楚，零信任（作为一套抽象的原则）可以表现为许多不同的 ZTA（作为一个实际的设计）。这是零信任的一个优势，因为它把主动权交给了各个架构师和从业人员，让他们以适合每个团队的方式评估和优先考虑各种核心原则（图1）。

图一 nist 零信任体系结构的原则

同时，这种架构的多变性也是如何真正实现零信任的部分原因似乎并不明确。在所有情况下，将访问控制边界分开以分别包围每个资源的目标将至少使用一个而且很可能是许多 PDP 和 PEP，但技术组件的安排和它们的相互联系对大多数组织来说是独特的。

幸运的是，NIST 的文件还充实了三种不同的架构方法，四种不同的部署方式，以及五种不同的业务层面的场景，以显示如何将原则付诸实施。我们在这里只是简单地谈一谈，以说明不同的企业可以如何开始接近他们自己的零信任项目。

本文上篇介绍了零信任的概念、优势及劣势；在下周将会推出本文章的下半篇，着重介绍零信任整体战略、部署的变体和情景模拟。

译：零信任对 Kubernetes 意味着什么

这篇是 Buoyant 的创始人 William Morgan 文章《# What Does Zero Trust Mean for Kubernetes?》[1]的翻译，文章很好的解释了什么是零信任、为什么要实施零信任，以及服务网格如何以最小的代码实现零信任。

零信任是营销炒作，还是新的机会，各位看官你怎么看？

要点

• 零信任是一种被大量炒作的安全模型，但尽管存在营销噪音，但它对于具有安全意识的组织具有一些具体而直接的价值。

• 零信任的核心是，将授权从“在边界验证一次”转变为“随时随地验证”。

• 为此，零信任要求我们重新思考身份的概念，并摆脱基于位置的身份，例如 IP 地址。

• Kubernetes 采用者在网络层实现零信任时具有明显的优势，这要归功于基于 Sidecar 的服务网格，它提供无需更改应用程序就可实现的最细粒度的身份验证和授权。

• 虽然服务网格可以提供帮助，但 Kubernetes 安全性仍然是一个复杂而微妙的话题，需要从多个层次进行了解。

零信任[2]是一种位于现代安全实践前沿的强大的安全模型。这也是一个容易引起轰动和炒作的术语，因此很难消除噪音。那么，究竟什么是零信任，对于 Kubernetes，它究竟意味着什么？在本文中，我们将从工程的角度探讨什么是零信任，并构建一个基本框架来理解它对 Kubernetes 运维和安全团队等的影响。

介绍

如果你正在构建现代云软件，无论是采用 Kubernetes 还是其他软件，可能都听说过“零信任”一词。零信任的安全模式变得如此重要，以至于美国联邦政府已经注意到：白宫最近发布了一份联邦零信任战略的备忘录[3]，要求所有美国联邦机构在年底前满足特定的零信任安全标准。2024财年；国防部创建了[零信任参考架构](https://dodcio.defense.gov/Portals/0/Documents/Library/(U "零信任参考架构")ZT_RA_v1.1(U)_Mar21.pdf)；美国国家安全局发布了一份Kubernetes 强化指南[4]，专门描述了 Kubernetes 中零信任安全的最佳实践。

随着这种噪音，零信任无疑吸引了很多营销关注。但尽管有噪音，零信任不仅仅是一个空洞的术语——它代表了对未来安全的一些深刻和变革性的想法。那么具体来说，什么是零信任，为什么它突然变得如此重要？零信任对 Kubernetes 用户意味着什么？

什么是零信任？

正如所料，零信任从根本上讲是关于信任。它是解决安全核心问题之一的模型：是否允许 X 访问 Y？换句话说，我们是否相信 X 可以访问 Y？

当然，零信任中的“零”有点夸张。要使软件正常工作，显然某些东西需要信任其他东西。因此，零信任并不是完全消除信任，而是将信任降低到最低限度（众所周知的最小特权原则）并确保它在每一点都得到执行。

这听起来像是常识。但与技术中的许多新想法一样，理解零信任的最佳方法是了解它的反应。零信任摒弃了边界安全的观点。在边界安全模型中，在敏感组件周围实施“装甲”。例如，数据中心周围可能有一个防火墙，其任务是阻止问题流量和参与者进入。这种模型，有时被称为城堡策略，具有直观的意义：城堡的墙壁是为了将坏人拒之门外。如果你在城堡里，那么根据定义，你就是一个好人。

零信任模型表明，边界安全已经不足。根据零信任原则，即使在安全边界内，仍必须将用户、系统和网络流量视为不受信任。国防部的参考架构很好地总结了这一点：

“在安全边界之外或之内运行的任何参与者、系统、网络或服务都是不可信的。相反，我们必须验证任何试图建立访问权限的事物。从边界验证一次到对每个用户、设备、应用程序和交易的持续验证，这是我们如何保护基础设施、网络和数据的哲学的巨大范式转变。”

当然，零信任并不意味着抛弃防火墙——纵深防御是任何安全策略的重要组成部分。这也不意味着我们可以忽略所有其他重要的安全组件，例如事件记录和供应链管理。零信任只要求我们将信任检查从“一次在边界”转移到“每次，无处不在”。

然而，为了正确地做到这一点，我们需要重新考虑一些关于“信任”意味着什么以及我们如何捕捉它的基本假设。

身份

零信任最直接的影响之一是它改变了我们思考和分配身份的方式，尤其是系统身份。

在边界模型中，位置实际上就是身份。如果在防火墙内，那么是可信的；如果你在它之外，就不是。因此，基于边界的系统可以允许基于客户端 IP 地址等信息访问敏感系统。

在零信任世界中，这已经不够了。IP 地址仅用于指示位置，因此不再足以确定是否可以访问特定资源。相反，我们需要另一种形式的身份：以某种内在方式与工作负载、用户或系统相关联。而且这种身份需要以某种方式进行验证，而这种方式本身并不需要信任网络。

这是一个具有丰富含义的大要求。提供网络安全但依赖于 IP 地址等网络标识符（如 IPSec 或 Wireguard）的系统不足以实现零信任。

策略

有了新的身份模型，我们现在需要一种方法来捕获每个身份的访问类型。在上面的边界方案中，通常授予一系列 IP 地址对敏感资源的完全访问权限。例如，我们可能会设置 IP 地址过滤，以确保仅允许防火墙内的 IP 地址访问敏感服务。在零信任的情况下，我们反而需要执行必要的最低访问级别。基于身份以及任何其他相关因素，应尽可能限制对资源的访问。

虽然我们的应用程序代码可以自己做出这些授权决策，但我们通常会使用在应用程序之外指定的某种形式的策略来捕获它。拥有明确的策略允许我们在不修改应用程序代码的情况下审核和更改访问权限。

为了实现我们的零信任目标，这些策略可能非常复杂。我们可能有一个策略，它将对服务的访问限制为只有那些需要访问它的服务调用方（即，在双方都使用工作负载身份）。我们可能会进一步细化，只允许访问该服务上的某些接口（HTTP 路由、gRPC 方法）。更进一步，根据请求的用户身份限制访问。在所有情况下，目标都是最低权限——只有在非常必要时才能访问系统和数据。

执行

最后，零信任要求我们在最细粒度的级别上同时执行身份验证（确认身份）和授权（验证策略是否允许该操作）。每个授予数据或计算访问权限的系统都应该设置从外围到单个组件的安全边界。

与策略类似，这种执行理想情况下是在整个堆栈中统一完成的。不是每个组件都使用自己的自定义执行代码，而是使用统一的执行层，统一之后方便审计，并将应用程序开发人员的关注点与运营和安全团队的关注点分离。

Kubernetes 零信任

我们必须从第一原则重新思考身份，以任意表达性策略的形式来将信任具象化，并将新的执行机制渗透到基础设施的各个层面。面对这些的要求，我们不可避免地经历短暂的恐慌。前面是不是提到需要在 2024 财年之前实现？

好消息是，至少对于 Kubernetes 用户来说，采用零信任的某些方面要容易得多。尽管有缺陷和复杂性，Kubernetes 是一个具有明确范围、定义良好的安全模型和明确的扩展机制的平台。这使其成为零信任实施的成功领域。

在 Kubernetes 中解决零信任网络的最直接方法之一是使用服务网格。服务网格利用了 Kubernetes 强大的“sidecar”概念，其中平台容器（译者注：此处指 sidecar 代理容器）可以在部署时以后期绑定操作功能的形式，与应用程序容器动态注入到一起。

服务网格使用这种 sidecar 方法在运行时将代理添加到应用程序 pod 中，并连接这些代理以处理所有传入和传出流量。这允许服务网格以与应用程序代码解耦的方式交付功能。应用程序和平台之间的关注点分离是服务网格主张的核心价值：当然，这些功能可以直接在应用程序中实现，但是通过解耦，我们允许安全团队和开发人员相互独立地迭代，同时仍然努力实现安全但功能齐全的应用程序的共同目标。

由于服务网格处理进出应用程序之间的默认网络，因此它可以很好地处理零信任问题：

1. 工作负载身份可以从 Kubernetes 中的 pod 身份而不是其 IP 地址中获取。

2. 可以通过在双向 TLS 中包装连接来执行身份验证，这是 TLS 的一种变体，其使用加密信息在连接的两端进行验证。

3. 授权策略可以用 Kubernetes 术语表示，例如，通过自定义资源定义 (CRD)，明确策略并并与应用程序解耦。

4. 最重要的是，策略在跨技术栈的单个 pod 级别统一执行。每个 pod 都有自己的身份验证和授权，这意味着网络永远不受信任。

所有这些共同实现了我们的大部分零信任目标（至少对于 Kubernetes 集群而言！）。我们使用工作负载身份而不是网络身份；在最细粒度级别（pod）上执行，以及在技术栈中以一致且统一的方式应用身份验证和授权的，而无需更改应用程序。

在基本框架内，不同的服务网格实现提供了不同的权衡。例如， Linkerd[5]是一个开源、Cloud Native Computing Foundation[6] 毕业的服务网格项目，它提供了一个以简单性为目标和重点的实现，直接从 Kubernetes ServiceAccounts 提取工作负载标识来达到“零配置”，默认开启双向 TLS。同样，Linkerd 的基于 Rust 的微代理提供了一个极简的零信任实现。

当然，仅仅在集群中添加一个服务网格并不是万能的。安装后，必须完成定义、更新和评估授权策略的工作。集群运维人员必须小心确保所有新创建的 pod 都与它们的 sidecar 组件配对。当然，服务网格本身必须像集群上的任何软件一样进行维护、监控和迭代。然而，不管是不是灵丹妙药，服务网格确实提供了从集群中默认的未加密、未经身份验证的流量转变为具有强大工作负载身份和丰富授权系统的默认加密、经过身份验证的流量——这是朝着零信任迈出的一大步。

总结

零信任是一种强大的安全模型，处于现代安全实践的前沿。如果可以消除围绕它的营销噪音，那么采用零信任有一些深刻而重要的好处。虽然零信任需要对身份等核心理念进行一些根本性的改变，但如果 Kubernetes 用户能够采用服务网格并从纯粹基于边界的网络安全转变为“对每个用户、设备、应用程序和交易的持续验证”，那么他们至少有很大的优势。

关于作者

William Morgan

William Morgan是 Buoyant 的联合创始人兼首席执行官，Linkerd 的创建者。在加入 Buoyant 之前，他是 Twitter 的一名基础架构工程师，在那里他帮助将 Twitter 从单体架构转变为微服务。他是 Powerset、Microsoft 和 Adap.tv 的软件工程师，以及 MITRE 的研究科学家。

参考资料

[1] 《# What Does Zero Trust Mean for Kubernetes?》: https://www.infoq.com/articles/zero-trust-k8s/

[2] 零信任: https://en.wikipedia.org/wiki/Zero_trust_security_model

[3] 发布了一份联邦零信任战略的备忘录: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

[4]Kubernetes强化指南: https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/0/CTR_Kubernetes_Hardening_Guidance_1.1_20220315.PDF

[5] Linkerd: https://linkerd.io/

[6] Cloud Native Computing Foundation: https://www.cncf.io/