考虑所有微服务易受攻击，并监控它们的行为
作者：David Hadas（IBM Research Labs）
这篇文章警告 Devops 不要有虚假的安全感。在开发和配置微服务时，遵循安全最佳实践不会产生不易受攻击的微服务。这篇文章表明，尽管所有部署的微服务都容易受到攻击，但仍有很多事情可以做，以确保微服务不被利用/开采（exploited）。它解释了如何从安全角度，分析客户端和服务的行为，这里称为“安全行为分析”，可以保护部署的易受攻击的微服务。它提到Guard[1]，这是一个开源项目，提供对 Kubernetes 被认为易受攻击的微服务的安全行为监控和控制。
随着网络攻击的复杂性不断增加，部署云服务的组织继续增加其网络投资，旨在提供安全且不易受攻击的服务。然而，网络投资的逐年增长，并没有导致网络事件的相应减少。相反，网络事件的数量每年都在增加。显然，组织注定要在这场斗争中失败——无论付出多少努力来检测和消除部署的服务中的网络弱点，罪犯似乎总是占上风。
考虑到目前攻击性工具的传播、攻击性玩家的复杂性，以及犯罪分子不断增长的网络经济收益，任何依赖于在 2023 年构建不脆弱、无弱点服务的网络战略显然都太天真了。似乎唯一可行的策略是：
承认你的服务易受攻击！
换句话说，有意识地接受，你永远不会创造出完全无懈可击的服务。如果你的对手，发现甚至只是一个弱点作为切入点，你就输了！承认尽管你尽了最大努力，你所有的服务仍然是易受攻击的是重要的第一步。接下来，这篇文章将讨论对此你能做些什么...
如何保护微服务不被利用
易受攻击并不一定意味着你的服务会被利用。尽管你的服务在某些方面存在你不知道的漏洞，但是攻击者仍然需要识别这些漏洞，然后利用它们。如果罪犯没有利用你的服务漏洞，你就赢了！换句话说，有一个不能被利用的漏洞，代表了一个不能被实现的风险。
图一：罪犯正在易受攻击的服务中获得立足点
上图显示了罪犯尚未在服务中立足的例子；也就是说，假设你的服务在第一天没有运行由违规者控制的代码。在我们的示例中，服务在暴露给客户端的 API 中存在漏洞。为了获得最初的立足点，攻击者使用恶意的客户端来尝试和利用服务 API 漏洞之一。恶意客户端发送一个漏洞，触发服务的一些计划外行为。
更具体地说，让我们假设服务容易受到 SQL 注入的攻击。开发人员未能正确清理用户输入，从而允许客户端发送会改变预期行为的值。在我们的例子中，如果一个客户机发送一个带有关键字“username”和值“tom or 1=1”的查询字符串，该客户机将接收所有用户的数据。利用此漏洞需要客户端发送不规则的字符串作为值。请注意，良性用户不会发送包含空格或等号字符的字符串作为用户名，相反，他们通常会发送合法的用户名，例如可以定义为字符 a-z 的短序列。没有合法使用的用户名会触发服务计划外行为。
在这个简单的例子中，已经可以识别出几个机会来检测和阻止利用开发者故意留下的漏洞的企图，使漏洞不可利用。首先，恶意客户端的行为不同于良性客户端的行为，因为它发送不规则的请求。如果这种行为变化被检测到并被阻止，该漏洞将永远不会到达服务。其次，响应利用漏洞的服务行为不同于响应常规请求的服务行为。这种行为可能，包括对诸如数据存储等其他服务进行后续的不规则调用、花费不规则的时间进行响应、和/或以不规则的响应来响应恶意客户端（例如，在良性客户端进行规则请求的情况下，包含比正常发送的数据多得多的数据）。如果检测到服务行为变化，还将允许在攻击尝试的不同阶段阻止攻击。
更一般地说：
- 监控客户端的行为，有助于检测和阻止针对服务 API 漏洞的攻击。事实上，部署高效的客户端行为监控，会使许多漏洞无法被利用，而其它漏洞则很难被实现。为了成功，攻击者需要创建一个常规请求无法检测到的漏洞。
- 监视服务的行为，有助于在服务被利用时检测服务，而不管使用的攻击媒介是什么。高效的服务行为监控限制了攻击者能够实现的目标，因为攻击者需要确保服务行为，无法从常规服务行为中检测出来。
结合使用这两种方法，可能会为部署的易受攻击的服务添加一个保护层，从而大大降低任何人成功利用任何已部署的易受攻击的服务的可能性。接下来，让我们确定你需要使用安全行为监控的 4 个用例。
用例
从安全角度来看，我们可以确定任何服务生命周期中的以下 4 个不同阶段。在每个阶段，都需要安全行为监控来应对不同的挑战：
服务状态 | 用例 | 为了处理这个用例，你需要什么？ |
|---|---|---|
正常 | 无已知漏洞：服务所有者通常不知道服务镜像或配置中的任何已知漏洞。然而，有理由认为这项服务存在弱点。 | 针对任何未知的零日服务漏洞提供一般保护——检测/阻止作为可能被利用的传入客户端请求的一部分发送的不规则模式。 |
易受攻击 | 适用的 CVE 已发布：要求服务所有者发布新的不易受攻击的服务版本。研究表明，在实践中，消除已知漏洞的过程可能需要数周时间才能完成（平均 2 个月）。 | 基于 CVE 分析添加保护——检测/阻止包含可能用于利用已发现漏洞的特定模式的传入请求。继续提供服务，尽管服务有一个已知的漏洞。 |
可开采 | 已知漏洞已发布：服务所有者需要一种方法来过滤包含已知利用的传入请求。 | 基于已知的漏洞特征添加保护——检测/阻止带有识别漏洞特征的传入客户端请求。继续提供服务，尽管存在漏洞。 |
被误用 | 入侵者误用支持服务的 pod：入侵者可以遵循使他/她能够误用 pod 的攻击模式。服务所有者需要重启任何受损的 pod，同时使用未受损的 pod 来继续提供服务。请注意，一旦 pod 重新启动，攻击者需要重复攻击模式才能再次误用它。 | 识别并重新启动被误用的组件实例——在任何给定的时间，一些后备 pod 可能被入侵并被误用，而其它的则按照设计运行。检测/移除被误用的 pod，同时允许其它 pod 继续服务客户端请求。 |
幸运的是，微服务架构非常适合安全行为监控。
微服务与单体服务的安全行为比较
Kubernetes 通常用于支持采用微服务架构设计的工作负载。从设计上来说，微服务旨在遵循“做一件事并把它做好”的 UNIX 哲学。每个微服务都有一个有界的上下文和清晰的接口。换句话说，你可以期望微服务客户端发送相对有规律的请求，微服务呈现相对有规律的行为作为对这些请求的响应。因此，微服务架构是安全行为监控的绝佳选择。
图二：微服务非常适合安全行为监控
上图阐明了将单体服务划分为一组微服务如何提高我们执行安全行为监控的能力。在单体服务方法中，不同的客户端请求交织在一起，导致识别不规则客户端行为的能力下降。如果没有先验知识，观察交织在一起的客户机请求的人，会发现很难区分请求的类型及其相关特征。此外，内部客户端请求不会向观察者暴露。最后，单体服务的聚合行为，是其组件的许多不同内部行为的复合，这使得很难识别不规则的服务行为。
在微服务环境中，每个微服务都被设计为提供更好定义的服务，并服务于更好定义的请求类型。这使得观察者更容易识别不规则的客户端行为和不规则的服务行为。此外，微服务设计暴露了提供更多安全行为数据的内部请求和内部服务，以便观察者识别违规行为。总的来说，这使得微服务设计模式更适合安全行为监控。
Kubernetes 上的安全行为监控
寻求在 Kubernetes 部署上增加安全行为，可以使用在 CNCF 项目 Knative 下开发的 Guard。Guard 集成到运行在 Kubernetes 之上的完整 Knative 自动化套件中。你也可以将 Guard 部署为一个独立的工具来保护 Kubernetes 上任何基于 HTTP 的工作负载。
参见：
- Guard 的Github[2]仓库，将 Guard 作为独立工具使用。
- Knative 自动化套件——在博客文章Opinionated Kubernetes[3]中了解 Knative，文章描述了 Knative 如何简化和统一 web 服务在 Kubernetes 上的部署方式。
- 你可以通过SIG Security[4] Slack 频道，或Knative 社区安全[5]Slack 频道联系安全维护人员。Knative 社区频道将很快以#knative-security 的名字转移到CNCF Slack[6]。
这篇文章的目的，是邀请 Kubernetes 社区行动起来，介绍安全行为监控和控制，以帮助保护基于 Kubernetes 的部署。希望社区能够采取后续措施：
- 分析不同 Kubernetes 使用案例面临的网络挑战
- 为用户添加适当的安全文档，说明如何引入安全行为监视和控制。
- 考虑如何与可以帮助用户监视和控制其易受攻击的服务的工具集成。
参与
欢迎你参与进来，为 Kubernetes 开发安全行为监控和控制；分享反馈，并为代码或文档做出贡献；并提出或建议任何形式的改进。
参考资料
[1]
Guard: http://knative.dev/security-guard
[2]
Github: https://github.com/knative-sandbox/security-guard
[3]
Opinionated Kubernetes: https://davidhadas.wordpress.com/2022/08/29/knative-an-opinionated-kubernetes
[4]
SIG Security: https://kubernetes.slack.com/archives/C019LFTGNQ3
[5]
Knative 社区安全: https://knative.slack.com/archives/CBYV1E0TG
[6]
CNCF Slack: https://communityinviter.com/apps/cloud-native/cncf