本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已失效。

将所有微服务都视为易受攻击 — 并监控其行为

作者：David Hadas (IBM Research Labs) |

本文提醒 Devops 谨防虚假的安全感。在开发和配置微服务时遵循安全最佳实践并不能保证微服务是完全无漏洞的。文章指出，尽管所有已部署的微服务都存在漏洞，但仍有很多工作可以做，以确保微服务不会被利用。它解释了如何从安全角度分析客户端和服务的行为（本文中称为 “安全行为分析”），从而保护已部署的脆弱微服务。它指向 Guard，这是一个开源项目，提供针对被认为存在漏洞的 Kubernetes 微服务的安全行为监控和控制。

随着网络攻击复杂性不断升级，部署云服务的组织不断增加其网络安全投资，旨在生产安全且无漏洞的服务。然而，网络安全投资的逐年增长并未带来网络安全事件的相应减少。相反，网络安全事件的数量仍在逐年增长。显然，组织在这场斗争中注定要失败——无论投入多少精力检测和移除已部署服务中的网络漏洞，攻击者似乎总是占上风。

考虑到当前攻击工具的广泛传播、攻击者的老练程度以及网络攻击给攻击者带来的不断增长的经济利益，任何依赖于在 2023 年构建一个无漏洞、无弱点的服务的网络策略显然过于天真。似乎唯一可行的策略是

➥ 承认你的服务存在漏洞！

换句话说，有意识地接受你永远无法创建完全无懈可击的服务这一事实。如果你的对手找到哪怕一个作为入口点的弱点，你就输了！承认尽管你已尽最大努力，但你的所有服务仍然存在漏洞，这是重要的一步。接下来，本文将讨论你可以如何应对...

如何保护微服务不被利用

存在漏洞并不一定意味着你的服务会被利用。尽管你的服务在某些你不知道的方式上存在漏洞，但攻击者仍然需要识别这些漏洞并加以利用。如果攻击者未能利用你的服务漏洞，你就赢了！换句话说，拥有一个无法被利用的漏洞，代表着一个无法实现的风险。

Image of an example of offender gaining foothold in a service

图 1. 攻击者在脆弱服务中立足

上图展示了一个攻击者尚未在服务中立足的例子；也就是说，假设你的服务在第一天没有运行由攻击者控制的代码。在我们的例子中，服务在暴露给客户端的 API 中存在漏洞。为了获得初步立足点，攻击者使用恶意客户端试图利用一个服务 API 漏洞。恶意客户端发送一个利用代码，触发服务的某些计划外行为。

更具体地说，假设服务容易受到 SQL 注入攻击。开发者未能正确地清理用户输入，从而允许客户端发送会改变预期行为的值。在我们的例子中，如果客户端发送一个查询字符串，其键为“username”，值为 “tom or 1=1”，客户端将收到所有用户的数据。利用此漏洞需要客户端发送一个非规范字符串作为值。请注意，良性用户不会发送包含空格或等号字符的字符串作为用户名，相反，他们通常会发送合法的用户名，例如可能被定义为简短的字母 a-z 序列。任何合法的用户名都不会触发服务的计划外行为。

在这个简单的例子中，已经可以识别出几种机会来检测和阻止利用开发者（非）有意留下的漏洞的尝试，从而使该漏洞无法被利用。首先，恶意客户端的行为与良性客户端的行为不同，因为它发送非规范请求。如果检测并阻止了这种行为变化，利用代码将永远不会到达服务。其次，服务对利用代码的响应行为与对常规请求的响应行为不同。这种行为可能包括向数据存储等其他服务发出后续的非规范调用、花费非规范的时间响应、和/或向恶意客户端返回非规范响应（例如，包含比良性客户端发送常规请求时通常发送的数据多得多的数据）。服务的行为变化如果被检测到，也将允许在利用尝试的不同阶段阻止利用代码。

更普遍地来说

  • 监控客户端行为可以帮助检测和阻止针对服务 API 漏洞的利用。实际上，部署高效的客户端行为监控使得许多漏洞无法被利用，而其他漏洞则非常难以实现利用。为了成功，攻击者需要创建一种从常规请求中无法检测到的利用代码。

  • 监控服务行为可以帮助检测正在被利用的服务，无论使用何种攻击向量。高效的服务行为监控限制了攻击者可能实现的目标，因为攻击者需要确保服务行为与常规服务行为无异，无法被检测到。

结合这两种方法可以为已部署的脆弱服务增加一层保护，极大地降低任何人成功利用任何已部署的脆弱服务的可能性。接下来，让我们识别四种需要使用安全行为监控的用例。

用例

从安全角度看，可以将任何服务的生命周期分为以下四个不同阶段。在每个阶段，都需要安全行为监控来应对不同的挑战

服务状态用例为应对此用例，你需要什么？
正常无已知漏洞：服务所有者通常不知道服务镜像或配置中存在的任何已知漏洞。然而，合理假设服务存在弱点是合理的。提供针对任何未知、零日服务漏洞的通用保护 - 检测/阻止作为入站客户端请求一部分发送的、可能被用作利用代码的非规范模式。
存在漏洞适用 CVE 已发布：服务所有者需要发布该服务的一个新的、无漏洞的修订版本。研究表明，在实践中，移除已知漏洞的过程可能需要数周才能完成（平均 2 个月）。根据 CVE 分析增加保护 - 检测/阻止包含特定模式的入站请求，这些模式可能被用于利用已发现的漏洞。尽管服务存在已知漏洞，仍继续提供服务。
可利用已知利用代码已发布：服务所有者需要一种方法来过滤包含已知利用代码的入站请求。根据已知利用代码签名增加保护 - 检测/阻止带有识别利用代码的签名的入站客户端请求。尽管存在利用代码，仍继续提供服务。
被滥用攻击者滥用支持服务的 Pod：攻击者可以遵循某种攻击模式来滥用 Pod。服务所有者需要重启任何受感染的 Pod，同时使用未受感染的 Pod 继续提供服务。请注意，一旦 Pod 被重启，攻击者需要重复攻击模式才能再次滥用它。识别并重启正在被滥用的组件实例 - 在任何给定时间，某些支持服务的 Pod 可能被感染并滥用，而其他 Pod 则按设计正常运行。检测/移除被滥用的 Pod，同时允许其他 Pod 继续处理客户端请求。

幸运的是，微服务架构非常适合安全行为监控，如下文所述。

微服务与单体服务的安全行为

Kubernetes 常用于支持基于微服务架构设计的工作负载。从设计上看，微服务旨在遵循 UNIX 哲学：“只做一件事，并把它做好”。每个微服务都有一个有界上下文和清晰的接口。换句话说，你可以预期微服务客户端发送相对规范的请求，并且微服务对这些请求展现相对规范的行为作为响应。因此，微服务架构是安全行为监控的绝佳候选者。

Image showing why microservices are well suited for security-behavior monitoring

图 2. 微服务非常适合安全行为监控

上图阐明了将单体服务分解为一组微服务如何提高我们进行安全行为监控和控制的能力。在单体服务方法中，不同的客户端请求相互交织，导致识别非规范客户端行为的能力下降。在没有先验知识的情况下，观察交织在一起的客户端请求的人会发现很难区分请求类型及其相关特征。此外，内部客户端请求并未暴露给观察者。最后，单体服务的聚合行为是其许多不同内部组件行为的复合体，因此很难识别非规范服务行为。

在微服务环境中，从设计上看，每个微服务都应提供更明确的服务，并处理更明确类型的请求。这使得观察者更容易识别非规范客户端行为和非规范服务行为。此外，微服务设计暴露了内部请求和内部服务，为观察者提供了更多安全行为数据来识别非规范情况。总体而言，这使得微服务设计模式更适合进行安全行为监控和控制。

Kubernetes 上的安全行为监控

希望添加安全行为监控的 Kubernetes 部署可以使用 Guard，该项目在 CNCF 的 Knative 项目下开发。Guard 集成在运行于 Kubernetes 之上的完整 Knative 自动化套件中。或者，你可以将 Guard 作为独立工具部署，以保护 Kubernetes 上任何基于 HTTP 的工作负载。

参见

  • Guard 在 Github 上，可作为独立工具使用 Guard。
  • Knative 自动化套件 - 阅读关于 Knative 的博客文章 Opinionated Kubernetes，该文章描述了 Knative 如何简化和统一在 Kubernetes 上部署 Web 服务的方式。
  • 你可以在 SIG Security 的 Slack 频道或 Knative 社区的 security Slack 频道上联系 Guard 维护者。Knative 社区频道很快将迁移到 CNCF Slack，更名为 #knative-security。

本文的目标是邀请 Kubernetes 社区采取行动，并介绍安全行为监控和控制，以帮助保护基于 Kubernetes 的部署。希望社区能够跟进并

  1. 分析不同 Kubernetes 用例面临的网络安全挑战
  2. 为用户添加关于如何引入安全行为监控和控制的适当安全文档。
  3. 考虑如何与能够帮助用户监控和控制其脆弱服务的工具集成。

参与贡献

欢迎你参与进来，加入为 Kubernetes 开发安全行为监控和控制的努力；分享反馈并贡献代码或文档；以及提出或建议任何类型的改进。