这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。
考虑所有微服务的脆弱性并对其行为进行监控
作者：David Hadas (IBM Research Labs)
译者：Wilson Wu (DaoCloud)
本文对 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 自动化套件 - 在博客文章 Opinionated Kubernetes 中了解 Knative， 其中描述了 Knative 如何简化和统一 Web 服务在 Kubernetes 上的部署方式。
- 你可以在 SIG Security
或 Knative 社区 Security Slack 频道上联系 Guard 维护人员。
Knative 社区频道将很快转移到 CNCF Slack，其名称为
#knative-security。
本文的目标是邀请 Kubernetes 社区采取行动，并引入安全行为监测和控制， 以帮助保护基于 Kubernetes 的部署。希望社区后续能够：
- 分析不同 Kubernetes 使用场景带来的网络挑战
- 为用户添加适当的安全文档，介绍如何引入安全行为监控。
- 考虑如何与帮助用户监测和控制其易被攻击服务的工具进行集成。
欢迎参与
欢迎你参与到对 Kubernetes 的开发安全行为监控的工作中；以代码或文档的形式分享反馈或做出贡献；并以任何形式完成或提议相关改进。