云原生环境中的零信任

Posted 2021-04-06 网络与安全札记

在当今世界，组织机构仅仅按客户要求提供其客户和合作伙伴所需的应用程序和服务，已经不够了。现在，几乎所有组织都不仅是其自己的敏感数据的存储库，而且是那些相同的客户和合作伙伴的存储库。随着时间的流逝，对分析和大数据的使用，驱使组织在相同的合作伙伴和客户上收集不断扩展的数据仓库。

展望未来，这些敏感数据集的丢失不仅会伤害组织本身，还会对这些第三方造成长期（SSN等的丢失）和重大伤害。反过来，这将确保对受侵害的组织造成重大和长期的声誉，财务以及潜在的法律/法规破坏。

因此，对于组织来说，花费大量资源来保护此类数据集似乎是明智的，许多组织确实这样做，但是公开披露的破坏性违规行为的数量正在不断增加。显然，我们缺少了一些东西。我们必须信任不（或不能）被信任的事物或过程。也许是时候从另一个角度看待这个问题空间了。

介绍

看来当今的威胁环境几乎是难以解决的。每天都有另一个漏洞，另一个头版故事，另一个在政府询问前的高管。有什么变化？与昨天相比，我们今天真的没有那么安全吗？尽管普通对手社区可以使用的工具肯定更先进，更易于使用（部分原因是违反了各种国家通信安全机构本身），但是被利用的漏洞并不是什么新事物。实际上，自从我们首次启动计算机联网以来，我们就一直活着。这些漏洞基于“外部”是危险的假设，但是一旦您进入外围，一切都是可以信任的。我们天生就信任我们的基础设施。这种信任是非常错误的。如果要停止出血，我们必须停止盲目相信我们的基础设施和工作量。我们必须从无法假设信任级别的立场开始，相反，我们必须对工作负载及其支持基础架构建立信任级别，该信任级别应足以使我们保护我们的数据集和流程收费。

使这个问题复杂化的是，现代云本机应用程序环境一直在变化。各组成部分之间的相互关系也在不断变化。如果信任模型是基于静态基元构建的，则该信任模型将一直有效直到环境的下一次更改（即该信任模型的生命周期以秒为单位或最多为几分钟）。您不能在流沙中建立静态信任模型。

诸如Kubernetes之类的云原生系统利用基于元数据以及分布式决策和行动的模型，该模型不仅可以解决这种动态问题，而且可以将其包含在内。静态配置的数量仅限于引导环境所需的数量。

我们可以利用同一组概念来构建云本机信任模型，并避免静态模型的危害。

上下文中的零信任

Beyond Corp和零信任网络

就像该行业中的其他所有内容一样，零信任网络的概念并不是什么新鲜事物，实际上，至少从NSFNet成立以来，安全专业人员和学术界都在讨论零信任网络的概念。但是，有时需要推动将某些东西从esoterica迁移到主流。对于零信任而言，谷歌在Usenix中发表的《BeyondCorp》论文可谓是开创性的事件。他们不仅概述了问题陈述，而且指出他们将要解决问题，甚至告诉全世界他们将如何解决。可以说，这是对成熟的IT安全行业的一次猛烈抨击。

实际的Beyond Corp模型是一种主要针对最终用户和最终用户环境的模型。但是，即使实现可能不同，架构概念也同样适用于云本机应用程序连接世界。

零信任网络的作者对零信任网络的假设和/或要求有一个简明的定义。这本书是对零信任网络的相当深入的回顾的好读物。
●始终假定网络是敌对的
●网络上始终存在外部和内部威胁
●网络位置不足以决定信任度
●对每个设备，用户和网络流进行身份验证和授权
●策略必须是动态的，并从尽可能多的数据源中计算得出

许多人会告诉您，“微细分”足以在当今世界上加强安全性。但是，如果遵循“零信任”模型（如上所述），您会发现事实并非如此。

微细分可以而且应该是强制执行派生策略（尽可能接近端点）的机制，但不满足模型的许多其他假设或要求。简而言之，微细分是必要的，但还不够。

这是新的要求吗？

从网络的早期开始，就一直有一种理解，即必须保护端点（通常是主机），并且信任的分配需要由实际用户（或由代理，应用程序）来驱动。随着网络PC的爆炸式增长，最初是在公司环境中，并且由于无法可靠地标识其用户和/或保护自己，因此必须部署一种解决方法。答案是堡垒主机，我们现在通常将其称为防火墙。

好的，那有什么变化？

尽管防火墙肯定提供了一定程度的外围保护，但它们始终是真正的黄金标准（基于身份的端点保护）的代理。但是，随着威胁环境变得越来越多样化和更具挑战性，自动化的社会工程技术变得更加便宜和有效，并且外围环境变得更加动态，难以理解和复杂，外围安全的日子已经过去了，我们已经过了防火墙的巅峰。

这并不意味着在现代环境中就没有防火墙的必要，外围安全仍然是必需的，但是无疑它已不再足够。

在云原生世界中尤其如此。外围环境由不断变化，不断增长的可变需求组件集以及不断发展的数据流网格组成。

同时，随着云原生模式，元数据驱动的业务流程，分布式操作以及最终的一致性之类的工具而发展的工具，现在使我们可以回到原始模型，并接受现在所说的零信任。

云原生基础架构中的零信任

我们如何将零信任关系映射到Cloud Native？

那么，我们如何将那些“零信任”概念映射到云原生环境？实际上，这很简单。让我们接受所有这些假设或概念，并从云原生的角度考虑它们。

网络始终被认为是敌对的

Kubernetes及其亲属对底层网络的功能或信任程度几乎没有任何假设。用于Kubernetes的最常用的网络策略解决方案在Kubernetes的控制下在主机内执行该策略，并且不需要或依赖于底层网络基础结构来执行该策略。唯一需要的是网络将数据包传递到正确的目的地。

尽管不依赖底层网络基础结构来执行策略，但是敌对网络仍可以将数据包传递到敌对节点（例如，进行中间人攻击）或根本无法传递数据包。尽管“攻击”的第二种模式相当容易诊断，但是中间人攻击却更加困难。我们将在本文稍后部分解决这个问题。

网络上始终存在外部和内部威胁

云原生环境对这种概念的响应是可变的。它们中的大多数已经启用了许多解决方案，这些解决方案经常利用“最低特权''的概念来解决此问题。使用基于角色的访问控制（RBAC）和传输层安全性（TLS）之类的东西进行控制和管理功能以及启用名称空间和网络策略以控制实际工作负载的允许操作可以解决此问题。但是，在大多数情况下，这些是用户必须启用的功能。因此，原语在那里，但默认情况下通常不强制执行。

网络位置不足以决定信任度

每个设备，用户和网络流都经过身份验证和授权

这是上述主题始终存在于网络上的威胁的必然结果。

策略必须是动态的，并从尽可能多的数据源中计算得出

云原生环境中的所有内容都是动态的，整个平台基于多个元数据的合成做出实时操作决策。实际上，在Kubernetes中，非常网络策略模型是一种基于附加到工作负载，服务等的元数据的模型。

要记住的另一件事是，云原生环境中的应用程序，服务和工作负载充当其用户和系统用户的代理，因此，我们可以将应用程序和服务以零的方式映射到用户的概念信任模型。

真的需要零信任吗？

我认为《卫报》的一篇标题很好地总结了当前的状况-“网络安全状况：我们都被搞砸了。”

虽然写作是为了引起注意，但这是对我们当前位置的合理而简洁的指示。让我们在云原生环境的背景下对此语句进行一些整理。

随着云原生环境的发展，随着基数和变化率的不断提高，没有自动化的半透明环境将变得完全不透明。不仅不可能保护环境，您甚至能够告诉您发生了事件或违规的唯一方法是，如果对手认为合适，可以直接（勒索）或通过明显方式告知您该事实。以无法理解的方式将来源归功于您，从而发挥其劳动成果。如果我们已经如《卫报》所宣称的那样陷入困境，那么等待我们的将会变得更加糟糕。但是，如果我们实际上接受零信任模型，那么我们不仅应该能够避免致命的诊断，而且可以大大改善我们的姿势。如今，许多攻击之所以起作用，很大程度上是因为我们对信任的放错了太多.

我们需要做什么？

让我们再次回到同样的零信任概念。

网络始终被认为是敌对的

首先，我们必须将其内部化并设计我们的架构，运营和应用程序交付模型，并牢记这一理念。除非另有证明，否则所有事物都是可疑的。许多人仍然认为网络是受信任的组件，通过关联，允许在网络上通话的事物也受到信任。这是一个错误的假设。

要对抗启用网络的中间人攻击，请在信任边界内使用加密。这可以通过会话和/或网络级别的方法（例如TLS或IPSec）来完成。

网络上始终存在外部和内部威胁

启用平台所提供的功能，例如编排器，网络，存储等，这些功能支持"最低特权''概念以及可验证的身份验证和授权。您应该使用名称空间，默认情况下拒绝的策略以及RBAC。

确保基础结构中的任何事务，尤其是管理和控制事务，都是可审计且不可否认的。

使用加密时，请确保证书提供的身份有效，并且不仅代表证书的身份，还代表证书应启用的身份，并可以追溯到被授予证书的实体的来源。确保在需要时使用相互身份验证进行加密，例如相互TLS（mTLS），并确保对证书进行了严格的验证。

网络位置不足以决定信任度

每个设备，用户和网络流都经过身份验证和授权

请参阅上面有关始终存在的威胁的讨论。

策略必须是动态的，并从尽可能多的数据源中计算得出

如前所述，这已经是许多云原生平台的功能，而相同的平台（例如Kubernetes）提供了许多有趣的数据点，可以在制定策略决策时予以考虑。这里的一个示例是使用Kubernetes Service帐户。服务帐户允许自动访问Kubernetes API服务器。没有它们，就无法识别对Kubernetes API本身进行调用的不同自动化服务。通过将该服务帐户用作策略中可以引用的另一条元数据，您可以对可以允许哪些服务进行调用Kubernetes API的服务进行更精细的控制。类似的示例可以用于名称空间等。

一个有趣的推论是，应设计策略并确定其范围，以描述该策略应执行的操作，而不是该如何执行。例如，一项策略可能规定，给定应用程序的负载平衡器应该能够使用给定协议与该应用程序的工作进程进行通信。它不应指定应如何进行限制。这样一来，同一策略就可以在堆栈的不同位置和不同层呈现。跨多个实施点的一项策略，而不是必须手动保持同步的不同策略。

例如，假设您的政策目标是仅允许从给定的一组应用程序工作负载到给定的数据库组进行特定类型的API调用。可以在网络层（仅允许应用程序工作负载和数据库之间使用特定的协议）和应用程序层（通过在gRPC cal中仅允许使用特定的URI）呈现该策略目标。如果该策略必须写入两次（一次写入网络，一次写入应用程序层），那么这些策略必须手动保持同步。例如，您可能决定更改可以进行该API调用的应用程序工作负载的数量。这意味着您必须记住同时更新网络和应用程序策略。如果您不这样做，则会存在政策不匹配的情况，并且更改将失败。但是，如果该策略只能编写一次并在网络和应用程序层中自动呈现，则无需手动使其保持同步。在这种情况下，更改将自动在网络和应用程序空间中呈现。

在更大的环境中如何？

随着应用程序环境扩展到云原生边界之外，是否存在适用性？

可以肯定。零信任模型的整个概念是一种您必须与会话中的端点建立信任关系的模型，其中位置不仅不是唯一的考虑因素，而且通常甚至不是主要考虑因素。随着应用空间中越来越多的端点最终位于数据中心外部（例如，IoT），我们也必须找到一种与它们建立信任级别的方法。由于零信任模型特别减少了使用网络位置作为确定信任的机制，因此，如果您遵循该模型，并且正在采用构建零信任环境的机制，则可以很好地将应用安全地扩展到数据中心以外。

结论

您不仅可以说“零信任网络的时机已到，”还可以说“零信任网络的到来正当其时。” 强制功能和支持技术相同，即元数据驱动的分布式云原生应用交付环境。如果您尚未考虑将此架构作为云原生策略的一部分，则需要这样做。如果实施正确，它不仅会提供更安全的环境，而且会以简单，非常对开发人员，操作和组织友好的方式提供。