这篇文章已经超过一年了。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
将所有微服务视为易受攻击的 — 并监控它们的行为
这篇文章警告 Devops 不要抱有虚假的安全感。在开发和配置微服务时遵循安全最佳实践并不会产生无漏洞的微服务。这篇文章表明，尽管所有部署的微服务都存在漏洞，但仍有很多方法可以确保微服务不被利用。它解释了如何从安全角度分析客户端和服务的行为（此处称为“安全行为分析”）可以保护部署的假设存在漏洞的微服务。它指向 Guard，一个开源项目，提供对假设存在漏洞的 Kubernetes 微服务的安全行为监控和控制。
随着网络攻击的复杂性持续加剧，部署云服务的组织不断增加其网络投资，旨在生产安全且无漏洞的服务。然而，网络投资逐年增长并没有导致网络事件的相应减少。相反，网络事件的数量每年都在持续增长。显然，组织注定会在这场斗争中失败 - 无论付出多少努力来检测和消除已部署服务中的网络漏洞，攻击者似乎总是占上风。
考虑到当前攻击工具的普及、攻击者的复杂性以及攻击者不断增长的网络经济收益，任何依赖于在 2023 年构建无漏洞、无弱点服务的网络策略显然都太天真了。似乎唯一可行的策略是
➥ 承认您的服务存在漏洞！
换句话说，有意识地接受您永远不会创建完全无懈可击的服务。如果您的对手发现哪怕一个漏洞作为入口点，您就输了！承认尽管您尽了最大努力，您的所有服务仍然存在漏洞是重要的第一步。接下来，这篇文章将讨论您可以对此做些什么...
如何保护微服务免受利用
存在漏洞并不一定意味着您的服务会被利用。尽管您的服务在您不知道的某些方面存在漏洞，但攻击者仍然需要识别这些漏洞，然后才能利用它们。如果攻击者未能利用您的服务漏洞，您就赢了！换句话说，拥有一个无法被利用的漏洞，表示无法实现的风险。
图 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 “只做一件事并把它做好” 的哲学。每个微服务都有一个有界上下文和一个清晰的接口。换句话说，您可以预期微服务客户端发送相对规律的请求，并且微服务会呈现相对规律的行为以响应这些请求。因此，微服务架构非常适合进行安全行为监控。
图 2. 微服务非常适合安全行为监控
上图阐明了将单体服务划分为一组微服务如何提高我们执行安全行为监控和控制的能力。在单体服务方法中，不同的客户端请求相互交织，导致识别不规则客户端行为的能力下降。在没有预先了解的情况下，观察相互交织的客户端请求的人很难区分请求的类型及其相关特征。此外，内部客户端请求不会暴露给观察者。最后，单体服务的聚合行为是其组件许多不同内部行为的组合，使其难以识别不规则的服务行为。
在微服务环境中，每个微服务按设计应提供更明确的服务并为定义更明确的请求类型提供服务。这使得观察者更容易识别不规则的客户端行为和不规则的服务行为。此外，微服务设计暴露了内部请求和内部服务，这些内部请求和内部服务为观察者提供了更多安全行为数据以识别异常情况。总而言之，这使得微服务设计模式更适合安全行为监控和控制。
Kubernetes 上的安全行为监控
寻求添加安全行为的 Kubernetes 部署可以使用在 CNCF 项目 Knative 下开发的 Guard。Guard 集成到运行在 Kubernetes 之上的完整 Knative 自动化套件中。或者，您可以将 Guard 部署为独立工具，以保护 Kubernetes 上的任何基于 HTTP 的工作负载。
请参阅
- Github 上的 Guard，了解如何将 Guard 用作独立工具。
- Knative 自动化套件 - 在博客文章 有主见的 Kubernetes 中了解有关 Knative 的信息，该文章描述了 Knative 如何简化和统一 Web 服务在 Kubernetes 上的部署方式。
- 您可以在 SIG Security Slack 频道或 Knative 社区 安全 Slack 频道上联系 Guard 维护人员。Knative 社区频道将很快迁移到 CNCF Slack，名称为
#knative-security。
本文的目的是邀请 Kubernetes 社区采取行动，并引入安全行为监控和控制，以帮助保护基于 Kubernetes 的部署。希望社区后续能够：
- 分析针对不同 Kubernetes 用例提出的网络安全挑战
- 为用户添加有关如何引入安全行为监控和控制的适当安全文档。
- 考虑如何与可以帮助用户监控和控制其易受攻击的服务的工具集成。
参与其中
欢迎您参与并加入为 Kubernetes 开发安全行为监控和控制的工作；分享反馈并为代码或文档做出贡献；并提出任何形式的改进建议。