所有 excalidraws 均可在此处获取：https://link.excalidraw.com/l/6qFzFKIJXdd/9IF1yYlyRek

我从事云安全工作的时间越久，就越发厌恶云原生应用保护平台（CNAPP），因为它们试图成为 “无所不能” 的平台，从而混淆了云安全的目标。

尽管名称里有 “应用” 这个词，但云原生应用保护平台在保护运行于云环境中的应用方面几乎毫无作为。原因如下：

  1. 在安全态势方面，云原生应用保护平台（CNAPP）忽略了与应用最为相关的测试（静态应用安全测试（SAST）和动态应用安全测试（DAST））。它们普遍存在的最薄弱环节是代码分析、命令行界面（CLI）、集成开发环境（IDE）、软件成分分析（SCA）、容器扫描以及其他方面。对于云原生应用保护平台而言，这些只是表面应付的功能，它们实际上并非真正意义上的全面应用安全平台。

  2. 在运行时方面，云原生应用保护平台（CNAPP）一直以来就像是（某种程度上）可与容器配合使用的终端检测与响应（EDR）工具 —— 对待容器的方式，其复杂程度仅比扫描 Linux 服务器上的恶意软件略高一点。Twistlock 代理的水平跟十年前差不多，而且在这个领域的创新极其缓慢。从恶意软件扫描的基本警报，到进程启动时发出警报这类功能，大多数供应商仍在逐步推出。

这些早期工具将云计算的各个层次视为相互独立的实体，在出现问题时试图应用互不关联的检测手段。在本文中，我们将探讨为什么运行时安全的未来需要被设想为云应用检测与响应（CADR）—— 这是一种从头开始构建的工具，旨在阻止对云应用的运行时威胁，而不是把它当作事后才考虑的事情。云原生应用保护平台（CNAPP）让安全团队在最为重要的地方，即应用层面，获得的可见性最低。云原生应用保护平台使得检测和响应的效果往好了说是十分有限，往坏了说则完全是浪费时间

我很欣赏在我上一篇关于云应用检测与响应（CADR）的文章下的一条红迪网评论，评论说那篇文章读起来就像一个迷迷糊糊时做的梦，我也明白为什么听起来会是那样。但我们不妨用一些现实世界中的攻击案例来展示现代攻击是如何贯穿环境的每一个层面的，以及现有的工具又是如何在应对这些攻击方面发挥作用的。

全面检测 MoveIT 漏洞利用情况

MoveIT 是如何跨越应用层的 —— 值得一提的是，MoveIT 通常部署在 Windows 服务器上，所以对于这个特定的应用程序来说，容器层的关联性没那么大，但总体的攻击模式是相同的。

去年，MoveIT 漏洞成为了头条新闻，原因是它使得攻击者很容易就能接触到关键基础设施，让攻击者得以完全掌控相关环境。以下是这种攻击的大致运作方式：

  1. 发送 SQL 注入有效载荷（应用层）

  2. 访问远程系统（容器层）上的 shell

  3. 使用继承权限访问云数据（云层）

关于此次漏洞利用的更多细节，Miggo 安全公司撰写了一篇非常精彩的文章，探讨了检测攻击的应用层所面临的复杂性。简而言之，如果我们使用了 MoveIT，尤其是将其用于面向公众的场景中，那我们就完全陷入了困境，而且很可能正实时遭受攻击利用。。

全面覆盖 MITRE（知识库）为何需要对所有层面具备可见性

让我们坦率地讨论一下，使用当前的工具检测到这种情况的可能性有多大，检测需要花费多长时间，以及这些工具所具备的能力。

  1. 通过漏洞扫描发现（这是云安全的大多数检测方法）。安全工具可以通过软件成分分析（SCA）或容器扫描轻松检测出正在使用的 MoveIT 版本，具体取决于它的部署方式，并且会建议进行补丁修复。通常情况下，供应商会在 24 小时内部署针对此情况的检查，但这是安全领域里人人都讨厌的紧急补丁修复工作。据我估计，大约一周时间你会注意到这个检测结果，然后如果你正确地确定了优先级，还需要再花两周时间来进行紧急补丁修复。而且你永远都不会知道自己是否受到了影响。如果这不是一个成为新闻热点的关键漏洞，可能要过好几个月才会被发现。

  2. 在云层面进行检测（云存储的异常访问情况）。一旦 webshell（网页后门）已经建立，攻击者就几乎可以按照他们想要的任何方式访问云文件，这取决于工作负载所附带的权限。根据攻击者手段的复杂程度，完全有可能避免被检测到 —— 尤其是因为该工作负载或云角色通常是有权限访问这些文件的。据我所知，没有任何工具会监控一个容器（pod）来留意是否有新进程正在访问特定文件。即便真的触发了异常警报，安全运营中心（SOC）的响应也需要与开发团队协调，以确定这种访问是否属于正常预期情况。除非出现大量的数据外泄流量，否则你很可能永远无法检测到这种情况，而大量的数据外泄流量所触发的警报噪音很大，你可能已经将其忽略了。

  3. 在工作负载层面检测 webshell（云工作负载保护平台（CWPP））。这一步骤是大多数基于代理的云原生应用保护平台（CNAPP）有机会检测到问题的环节；不过，请在你们自己的环境中测试这些情况。在我去年的测试中，没有终端检测与响应（EDR）工具针对这种行为发出警报，而且如果 shell 不是作为一个单独进程启动的话，几乎所有的云原生应用保护平台都会漏检。不过，我们假设它检测到了 webshell 的存在，在大多数工具中，警报显示可能会是这样：“工作负荷 x 上启动了未知进程”。这并没有太大的帮助，也没有给安全运营中心（SOC）提供太多背景信息。他们需要与 DevOps 团队协调，以确定这一操作是否在预期之内，而这样的调查会花费大量时间。对于确定影响范围而言，只有少数几个工具能提供工作负载与云之间的关联关系，以便将 “这个工作负载访问了这些云文件” 联系起来。但这是在使用大多数工具时，你有机会进行检测的第一个层面。由于缺乏背景信息，这个警报很有可能被忽视或误解。

  4. 在应用层进行检测 ——SQL 注入负载（应用检测与响应（ADR）或网络层）。检测应用负载是一个复杂的过程，具体取决于你基础设施的细节，需要结合应用检测与响应（ADR）或 Web 应用防火墙（WAF）来进行。绕过 Web 应用防火墙的方法已经很成熟了，而且像 MoveIT 这样的第三方工具常常不在防火墙的保护范围内，或者设置了宽松的例外规则。仅靠应用检测与响应（ADR）本身能告诉我们负载已经出现了，有些 ADR 工具可以阻止它，但 ADR 自身并不能告诉我们 webshell 做了什么，或者它是否成功实施了攻击。与其他工具不同，ADR 至少可以首先阻止漏洞利用。而且这也是唯一一种安全运营中心（SOC）无需与其他团队核实的警报：因为 SQL 注入就是 SQL 注入，所以可以进行适当的调查。与 eBPF（扩展的 Berkeley 数据包过滤器）相结合的 ADR 最有可能检测到 “哇，这个负载创建了一个进程” 的情况。

梳理清楚要完整看到整个攻击链需要多少种检测能力，这显示出了安全团队所面临的复杂性，尤其是当他们被各种营销噪音所包围的时候。没错，几乎任何扫描工具或终端检测与响应（EDR）工具都有可能检测到类似 MoveIT 风格的漏洞利用情况，但在这种情况下，只有应用检测与响应（ADR）最有希望实现及时响应。然而，仅靠 ADR 本身会遗漏掉在漏洞被利用之后所采用的攻击手段。大多数严重的数据泄露事件并非是因为忽略了警报，而仅仅是根本就没有被检测到，这是有原因的。我们检测云攻击的能力已经过时到令人堪忧的地步了。

我不相信这很重要，还有其他例子吗？

没错！以下是一些从应用层开始发起，然后向下渗透到工作负载层和云层的攻击：

  • XZ Utils

  • Polykill

  • CUPS

  • Log4j

  • Spring4Shell

  • Confluence RCE

  • Apache Struts

  • tj-actions

  • ingress-nginx

以上所述都与 MoveIT 的模式相同：

  1. 在应用层的初始入侵：

    攻击者利用应用程序代码或核心库中的漏洞来执行恶意代码或命令。

  2. 向工作负载层转移（攻击方向）

    ：一旦攻击者实现了代码执行，他们就会植入网页后门，提升权限，或者访问环境变量，从而有效地 “掌控” 容器或虚拟机。

  3. 扩展到云层

    ：攻击者凭借服务账户凭证、API 密钥或特权角色，直接与云服务进行交互 —— 读取数据、启动加密货币挖矿程序，或者窃取敏感信息

没有任何孤立的解决方案能够妥善地检测并应对从漏洞利用到漏洞利用后所采用的攻击手段。为了让安全运营中心（SOC）能够有效应对云攻击，需要新的解决方案，这些方案能够将整个事件的来龙去脉串联起来 —— 从应用程序被攻击利用到数据从云端被窃取。

你说服我了，我满心都是恐惧、不确定和怀疑（FUD），我该买些什么呢！？我需要云应用检测与响应（CADR）工具！

一张显示不同供应商在向云应用检测与响应（CADR）所处市场地位的图

我也有同感，而且很遗憾目前还没有哪家供应商是十全十美的。不过，很多供应商都已经非常接近（理想状态）了！要解读这张图表的话，云应用检测与响应（CADR）整合了三个不同的层面 —— 云、工作负载和应用程序。处于图表上方的供应商专注于应用程序层或网络层来检测攻击。处于图表右侧的供应商构建了更多的容器安全解决方案。处于图表左侧的供应商则构建了更多以云为核心的解决方案。

咱们先来聊聊目前市面上都有哪些（安全工具），然后再谈谈你可以组合使用的潜在安全工具。

市场上有什么

以下是市面上存在的不同方法以及相应的缩写术语：

DIY

我不会在这上面花费太多时间，但万一你有兴趣尝试，下面大概讲一下你如何通过结合可观测性工具、扩展的伯克利数据包过滤器（eBPF）以及安全信息和事件管理系统（SIEM），自己动手搭建一个云应用检测与响应（CADR）系统。

  1. 可观测性 - OpenTelemtery 收集器和基线应用程序行为

  2. eBPF - 选择自己的开源 eBPF 代理（falco、tracee、calico、tetragon、kubearmor）进行冒险

  3. SIEM - 将 cloudtrail 和 cloudwatch 集成到您选择的 SIEM 中

  4. 祈祷你能够将这些要素关联起来，并设置足够多的检测规则，让这个（自建的云应用检测与响应系统）发挥出不错的效果。

CDR

无论好坏，既然无代理的云原生应用保护平台（CNAPP）已成为过去，如今真正的运行时类别只剩下两类：云检测与响应（CDR）和应用检测与响应（ADR）。CDR 是云工作负载保护平台（CWPP）与 “无代理 CDR” 的演进 —— 具体来说，它结合了来自容器和云资源的遥测数据。优秀的 CDR 会将这些遥测数据结合起来，形成对攻击的 “工作负载到云” 的可见性。以我们之前提到的 MoveIT 攻击为例，它们会发现。

如果供应商图表还不够让人眼花缭乱的话，这个领域的情况将会变得非常复杂。目前基本的云检测与响应（CDR）检测方法已广泛普及，但以下是几个需要重点关注的方向：

  1. 基于异常的检测：具备深度检测的潜力，但可能产生大量误报（或 “噪声”）

  2. 大型容器规则库：具备可靠的检测能力，但可能缺失云环境上下文

  3. 云检测：倾向于发现大规模攻击，但无法提供足够的工作负载上下文信息

  4. 网络可见性：具备强大的可见性，但在导航（分析）时容易因信息繁杂而难以处理

一些主要的 CDR 玩家包括 ARMO、Aqua、Rad、Sweet、Sysdig、Spyderbat、Upwind、Uptycs 和 Wiz。但与往常一样，完整的名单在网站上。

ADR

应用检测与响应（ADR）是一个非常新的领域，但该领域的所有参与者都带来了独特的优势。我喜欢 ADR 的一点在于，它能够直接贴近漏洞利用本身，而不仅仅是关注漏洞利用后的攻击手段。回到我们之前提到的 MoveIT 攻击案例，ADR 能够检测并阻止触发连锁反应的 SQL 注入攻击 —— 这正是一切后续影响的源头。此外，ADR 能提供与漏洞利用实际上下文最相关的信息，而这些信息正是安全运营中心（SOC）响应警报时所需要的。

在云应用检测与响应（CADR）类别中，应用检测与响应（ADR）是最重要的部分，因为没有它，你所知道的仅仅是某个进程似乎莫名其妙地启动了。如果缺乏应用上下文，响应云警报就会变得一片混乱 —— 安全团队不得不费力追查开发团队在容器内的操作行为。。

不过，应用检测与响应（ADR）比其他类别更难处理，因为它非常新。以下是供应商采用的一些通用方法

  1. 插桩方法。这些方法将测试和保护能力直接融入代码，但需要以修改代码为代价，且通常会对性能产生更大影响。

网络方法。这些方法在连接资源和数据流方面表现出色，但可能缺乏对工作负载库的深入洞察。

  1. 高级 eBPF 功夫。这些功能提供了关于应用程序如何连接到基础架构的重要功能见解，但往往缺乏应用程序的整体分布式上下文。

  2. 混合方法。这类供应商从任何数据源获取遥测数据，灵活性极高。

应用检测与响应（ADR）的核心区别存在于两类方案中：基于网络的 ADR和基于库的 ADR。基于网络的 ADR 能够发现许多 OWASP 类型的攻击（如 SQL 注入、服务器端请求伪造 SSRF），但无法检测异常的库行为、函数执行，也无法深入洞察底层代码库的细节。这类基于网络的 ADR 更为常见，而基于代理的库 ADR目前仅有四家供应商提供：Oligo、Raven、Miggo 和 Kodem。

主要 ADR 参与者有 Contrast、DataDog、Dynatrace、Kodem、Miggo、Oligo、Operant、Raven、Traceable。不过，完整的名单还是在网站上。

CADR - 关注对象

通过 kube-proxy 对我的容器进行 SQL 注入

在我看来，以下供应商最接近云应用检测与响应（CADR）的完整形态：ARMO、Sweet、Upwind、Oligo、Operant 和 Raven。在这些供应商中，我见过他们实现跨平面警报的实际案例，且通过亲身体验发现他们确实具备相关能力。

  • ARMO、Upwind 和 Sweet

    更多是从云检测与响应（CDR）方向切入 CADR，对应用层的支持取决于具体的语言和架构特性。

  • Raven、Oligo 和 Operant

    则更多从应用检测与响应（ADR）方向出发，逐步构建容器和云上下文的整合能力。

一旦其中任何一家能完整呈现类似 MoveIT 攻击的全链路上下文（比如从漏洞触发到云资源影响的完整轨迹），我就会制作视频好好展示一番！（甚至在撰写本文时，ARMO 已经通过上面的截图做到了这一点）

总结--保护云应用程序

归根结底，向云端迁移的核心在于利用容器化服务部署应用程序（当然，对于其他迁移上云的基础设施 —— 比如 Azure、大型企业架构等 —— 这里需要特别说明）。我感到非常兴奋，我们终于能够以一种让安全团队自主采取直接行动的方式，为这些应用提供运行时保护。尽管目前专注于 CADR 的公司数量仍然很少，但在我看来，这正是 CNAPP（云原生应用保护平台）发展的必然归宿。正如 “让 CSPM（云安全态势管理）警报具备可操作性” 需要额外补充攻击路径、影响范围、漏洞数据等上下文一样，“让 CDR（云检测与响应）警报具备可操作性” 也需要应用层的上下文信息。

这里的最终目标很简单：通过简化云事件的描述逻辑，让安全运营中心（SOC）能够真正高效处理云警报。

原文链接：

https://pulse.latio.tech/p/runtime-cloud-security-in-2025

声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。