2024 年 10 月 18 日-19 日，GOPS 全球运维大会上海站顺利召开，基调听云安云产品线总经理卢中阳在 AIOps 最佳实践及解决方案专场为与会嘉宾带来了演讲“可观测性领域的应用安全探索与实践”，从 AIOps 的现状和未来、应用安全观测痛点、应用安全观测方案等多个方面，展开讨论了可观测领域的应用安全探索与实践。
由于演讲内容广受好评，经过参会者和组委会一致评定，卢中阳被评为此次大会金牌讲师。
以下为演讲实录，enjoy：
![]()
感谢 GOPS 举办 AIOps 专场，作为今天第一个 AIOps 和可观测性的议题，基调听云在 AIOps 领域有比较特别的观点，我们观察到目前国内 90% 的 AIOps 项目落地未达预期，行业内的 AIOps 平台这个概念已然失败。从 Gartner 的报告也可以佐证这一点，根据 2024 年 Gartner 监控和可观测性炒作曲线（Hype Cycle for Monitoring and Observability, 2024）， “AIOps”并未进入 Plateau of Productivity 就夭折了，已经改名为“事件智能解决方案”。在近几年的 APM 及可观测性魔力象限报告中， AIOps 在 2020 年后，被关注度就逐年下降。在 2020 年炒作高峰期的时候提到过 30 多次，但是在 2024 年仅提到了三次，而且这三次出现在 Gartner 似乎在摆脱 AIOps 和自己的关联关系的描述中。与之对应，可观测性（Observability）被提及的次数越来越多，逐步成为大家关注的方向。基调听云作为行业的领导者，我们现在除了做系统稳定性、应用性能监控和用户体验监控之外，从去年开始，也开始在应用安全观测领域做一些深度的研究，今天由我为大家分享一下我们在应用安全观测领域的进展和实践案例。应用安全中，比较大的问题目前我们总结了三个维度，一是监管逐步趋严，且出现了一些新的监管方向；第二是应用安全、供应链风险一直居高不下；三是随着攻防的演进出现了更多现有防护体系无法覆盖的新的攻击手法。其实从等保 1.0 到 2.0、从 2011 年开始到现在，法律法规出台的频率越来越快，特别是一些央国企对安全的要求越来越严格。今年的时候，某监管单位发了一个红头文件，明确提出来要做安全运行管理。我们也看到了一些监管的文件，发现监管第一次对业务的连续性以及运行时的安全，以及在业务连续过程中的漏洞修复提出了一些非常明确的监管要求。我们汇总了 CNVD 在 2014 年至 2024 年间的漏洞趋势数据，发现与应用相关的漏洞占比始终接近 80%。此外，外采和自研的系统会引入大量的组件，这些组件可能会引入新的漏洞。因此，应用安全在整个安全防护体系中占据了重要地位，且相对容易出现问题。另外一个是软件供应链安全事件近年来频繁发生，而且影响范围巨大。我们一般将客观存在但是还未被公开的漏洞称为 0-day漏洞，如果商业系统中的 0-day 漏洞在修复前被攻击者找到并加以利用，将极大威胁到企业的信息安全。基于传统的安全设备和有限的规则，很难对 0-day 攻击进行有效的识别和拦截，这就造成了软件供应链安全攻击的潜伏性强、危害性非常高的情况。
一个安全产品能够实现的安全能力，很大程度上取决于它能够获取的数据类型。
在流量层面，我们能够监控用户发起的请求，从而识别出扫描行为、撞库尝试以及密码破解行为等。然而，这一层面也存在一些问题，例如对于加密流量的识别能力有限，通常只能依赖特征匹配，这可能导致误报率较高。在流量层的防护产品中，Web 应用防火墙（WAF）的使用率很高，其在擅长的领域内能够发挥更大的作用。在主机层面，我们能够检测到主机上的进程变化、文件的创建和删除等行为。若黑客从应用层渗透并获取主机层权限，此时告警通常为时已晚。其实黑客通过应用层发起攻击时，我们能够在整个过程中发现多种行为。例如，攻击者可能发送了 10 万个请求，WAF 能够告诉我们遭受了10万次攻击，但 WAF 无法识别其中哪些真正触发了应用层的危险行为，10 万次攻击中哪几次是入侵成功的，如确实执行了命令或 执行了 SQL 注入。国内外最初都期待通过运行时应用自我保护（RASP）产品来解决这类问题，但是经过调研，我们发现这类产品在国外要么已经消失，要么被可观测性厂商收购。国内情况也类似，除了互联网大厂自研的 RASP 能够部署到线上外，我们到现在也没有找到一个批量的落地案例。
我们尚未发现有企业敢于在核心业务系统中大批量部署此类 RASP 产品，尽管可以在外围部署一些点，但核心系统的应用仍然受限。总结来说，在应用层内部，我们可以发现更多的问题，但目前尚无标准化方案来应对这些挑战。我们认为存在几个主要原因导致国内 RASP 产品未能广泛应用。首先是成本问题。可观测性已经采集了一轮数据，如果专门为安全再采集一轮数据，将产生高昂的采集和传输成本。高成本的同时也将带来稳定性问题，包括 Agent 本身的稳定性以及 Agent 之间的兼容性问题。此外，部署难度也是一个关键问题。由于 Agent 有比较高的入侵性，它仅能为安全部门带来效益，却需要运维和研发测试部门的配合。我们认为在国内这种做法并不可行，一旦部署后出现问题，Agent 将被迅速移除，且未来也难以再次部署。另一个重要问题是技术支持能力。在基调听云，我们有数百人围绕 Agent 开展工作，技术支持团队也投入了大量人力以确保 Agent 的稳定运行。然而，对于安全 RASP 厂商而言，可能只有个位数的人员负责 Agent 的开发和支持，这与所需的技术支持能力完全不成比例。这可能是国内 RASP 产品一直未能发展起来的重要原因之一。
尽管如此，对于安全检测的需求依然存在，我们仍然需要收集大量信息以进行后续的安全检测。因此，我们正在探索如何在成本和技术支持能力的限制下，有效地实现这一目标。
我们的最终目标是将应用安全态势管理与流量层及主机层的产品进行整合，共同构建一个多层次的纵深防御体系。经过长时间的尝试，我们发现，复用可观测性产品的 Agent，可以达到很好的效果。为此，安云与观云整合推出了一套整体的可观测性解决方案。在该方案中，启用安云 ASPM 的能力仅需在系统配置中开启应用安全观测的开关即可。相较之下若采用传统的 RASP 或单独部署 Agent，除了沟通成本外还需额外部署 Agent，并考虑由此带来的潜在事故和影响。包括何时需要移除安全 Agent 以避免运营和研发部门的困扰，这涉及到诸多需要考虑的问题。我们的 ASPM 方案与 APM、RUM 以及整个可观测性平台共享一个 Agent 基础，此 Agent 不仅安全部门需要，也是运维和研发部门所必需的。
ASPM 在威胁感知方面，相较传统的安全产品，具有独特的优势。黑客入侵时，通常涉及多个阶段：
首先，黑客会识别目标资产，并通过发送大量恶意请求来探测系统。随后，他们分析这些请求中哪些得到了响应，以此作为进一步行动的依据。一旦发现漏洞，黑客便会尝试植入木马或利用内存马获取系统权限，进行数据窃取或其他恶意行为，并在完成后清理痕迹以掩盖入侵证据。听云 ASPM 方案能够识别这类扫描行为，并识别出这些攻击的类型。通过分析堆栈数据，我们还能确定哪些攻击实际上是成功的。在内存马控制阶段，我们甚至能够识别出黑客使用了哪种 Webshell 工具进行连接，以及是否发生了数据泄露。整个基调听云 ASPM 方案的数据是异步存储在另一个设备上的，即使黑客删除了当前攻击产生的日志，我们也能够保留入侵的痕迹，确保证据不会被销毁。一起看一个内存马识别的案例。目前，我们已能够识别绝大多数常见的内存马。我们不仅能够确定攻击是否涉及内存马，还能具体识别出攻击者利用了哪一个控制点、哪一个函数，以及使用了哪种工具。这些详细信息的获取得益于我们部署的统一 Agent，它能够捕获运行时堆栈中的所有数据。在分析过程中，我们能够查看到请求的具体地址，这不仅包括外部的网络地址，而且深入到代码层面，关联到最外层的控制点，这对于研发团队和安全团队而言是极为有益的。我们可以追踪到攻击者发出的请求次数、每次请求中包含的恶意参数、发起请求的 IP 地址，以及相关联的用户身份。得益于我们全面的可观测性能力，安全分析得以建立在坚实的数据基础之上。我们拥有丰富的业务数据，能够识别出用户的身份，以及他们背后执行的 SQL 语句。我们能够判断这些 SQL 语句是否具有恶意性质，以及它们对应的攻击链路。在过去，对攻击行为的研判工作相当繁琐。我们需要联系运维团队获取各类日志，有时甚至需要数据库管理员提供更多日志信息。现在，我们通过先进的可观测性平台，能够将所有相关信息自动化地汇总整合，并直接呈现给安全团队。这样，我们就能够一次性定位问题的来源，并准确识别出具体的问题所在。在进行 API 资产管理时，我们面临两个主要的挑战。首先，基于网关的 API 梳理只能提供被访问 API 的信息，但存在两个问题。其一，如果外部系统预留了后门 API，这些 API 不被访问，或者从内部访问不走网关难以察觉；其二，对于已经废弃但未被移除的 API，由于没有流量，我们同样无法通过网关检测到它们的存在。为了解决这些问题，我们通过 Servlet在应用初始化时自动获取所有 API ，不再依赖于请求的发生。结合运行过程中的流量数据，我们可以清晰地了解 API 的活跃状态并为它们打上标签，区分活跃 API 和长时间未被访问的 API，筛选出自上线以来从未被访问过的 API。这种方法极大地方便了我们的 API 管理，提供了一种完整的 API 资产测绘方案。此外，我们还对 API 进行了风险事件关联分析，以了解每个 API 背后可能发生的安全事件。由于 API 信息是从代码层面获取的，不存在从流量层聚合 API 的技术难题。入侵实时阻断功能依托于 Agent 实现。当检测到严重攻击时，我们能够及时中断这一行为。然而，在传统安全领域，安全人员通常对阻断操作持谨慎态度，因为即便是万分之一的错误率，在访问量巨大的生产环境也是不可接受的。目前，基于我们先前讨论的 API 能力，我们能够精确地针对单个 API 开启针对特定风险的拦截，而非对整个系统进行阻断。具体场景如下：在生产环节中，一旦发现某个应用的特定 API 存在未修复的漏洞，我们可以仅对该 API 实施拦截措施。这一方案经我们调研后认为具备一定的防护能力，因为它从最底层的命令执行或 SQL 操作层面提供保护，从而天然具备 0-day 漏洞防护的能力。无论入侵流程如何变化，其最终目的无非是执行命令、SQL 注入或数据泄露。这些行为在底层通常归结为几个关键的函数问题。因此，我们在这些关键函数上部署了防护措施，以增强对 0-day 事件的天然处理能力。一旦识别出攻击行为，系统可进行阻断。接下来看两个实际落地的应用场景和案例。在今年的大型攻防演练之前，我们利用大约一个月的时间，在客户的生产环境中部署了一万个安全 Agent，这在以往是难以想象的。我们在边缘业务系统和核心业务系统中全面启用了安全 Agent。企业通常通过防火墙和 WAF 来进行攻击防护，一旦攻击者利用其他漏洞绕过 WAF，可以直接攻击应用。现在，我们能够通过可观测性平台发现这些已经进入内部的入侵行为。我们的可观测性 Agent 部署在应用内部，因此具备深度的发现能力，能够发现这些隐蔽的安全威胁。另一个案例涉及上海的一家证券公司。该公司在完成整个安全防护体系的建设后，进行了深度的安全测试。测试结束后，发现系统中被植入了两个木马，但所有安全产品均未发出警报。我们通过复盘发现，测试人员通过内存马技术入侵，这种攻击在流量层和主机层均未被察觉。但是在 ASPM 的视野中，攻击者的行动无所遁形。在攻击发生前，我们可以通过 API 资产梳理，使资产整理更完整。在实际攻击过程中，我们能够更精准地发现攻击行为，并进行实时阻断。在攻击发生后，我们可以更方便地为研发团队提供修补建议。相比于传统的 RASP 能力，ASPM 的核心优势在于可观测性领域内的安全可控能力。其中最大的优势是降低成本和提高效率，我们通过一个 Agent 实现了更多的功能。基调听云的 Agent 已经得到了广泛的部署，技术积累丰富，且在性能上具有优势，因为它采用统一的方案来采集和存储所有数据，符合降本增效的总体趋势。以上便是 ASPM 在可观测性领域中应用安全的实践和经验分享，谢谢大家。
东北已经供暖了，而南方还在吹空调
留言区点赞数第2
可获得基调听云暖心保温杯1个
留言区点赞数第3
可获得基调听云定制折叠扇1把
![]()
![]()
![]()
![]()
