云工作负载安全实战：从资产清点到防勒索，一套CWPP落地全流程（2026版）

为什么我们要重搭服务器防线

先说两句大背景，不多展开。Verizon 刚发布的 DBIR2026里有两个数字值得记住:漏洞利用以31% 的占比首次超过凭据盗用，成为占比最高的初始入侵向量;勒索软件涉及了48% 的已确认数据泄露事件。再看修复侧，CISA KEV 目录里的在野利用漏洞，企业完全修复的中位时间是43天——攻击者按小时跑，防守方按月修，这个差距是大量事件背后共同的结构性原因。

我们团队管着多云环境里的几千台服务器（含虚机、容器和物理机），过去几年最大的教训是:边界防护并非万能，主机行为提供了另一层关键证据。WAF、防火墙、流量探针该上的都上了，但0day 绕过边界的那一次，是靠主机侧的数据把整条攻击链拼出来的(后面细讲)。所以2025年我们下决心把防线重心挪到工作负载上，用一套 CWPP(云工作负载保护平台)把资产、风险、基线、入侵检测、防勒索、取证串成一条流水线。我们用的平台是青藤深睿 CWPP，One Agent + One Platform 的架构，一个探针覆盖所有安全场景，这对我们这种多团队共用基础设施的环境很关键——不用为了不同功能在服务器上叠三四个 Agent。性能方面我们实测过，探针安装包只有11.4M，常态 CPU 占用压在2% 以下，在最抠资源的数据库服务器上也没被业务团队投诉过。这个平台已经覆盖1000万台服务器，大环境的验证比我们自己做 POC 更有说服力。

这篇文章不讲概念，按我们的实际落地顺序分六步写，每步都有具体做法和踩过的坑。

第一步:资产清点——先搞清楚自己有多少台机器

安全的第一性问题永远是“你到底有多少资产”。我们接手环境时，CMDB 和真实在线机器的差异率超过15%，最夸张的是一个测试集群里躺着200多台没人认领的虚机。

落地时我们做了三件事:

1. 未知资产发现。探针装上去之后，平台自动盘点出主机、容器、进程、端口、账号、Web 服务等十几类资产。部署本身没什么坑，几千台机器用 Ansible 批量推，一周装完。真正的工作量在后面:第一周就捞出了一批“影子资产”——业务部门自己开的云主机、项目结束后没人回收的测试机。这些机器没人打补丁、没人装监控，正是攻击者最喜欢的入口。我们的处置流程是:先确认归属，能下线的下线，必须保留的限期整改纳管，谁都不认领的直接断网，等有人跳出来再说。

2. Web 层资产细分。这是和很多只做主机清单的工具拉开差距的地方。平台把 Web 资产拆到站点、应用、框架、服务四个层级，能识别出“这台机器上跑着哪个站点、用的什么框架、框架是什么版本”。这个能力在应急时是救命的，看下面的真实场景。

3. 多云统一接入。我们的机器分散在阿里云、华为云和自建机房，通过统一接入把三个环境纳管到一个控制台，资产视图不再割裂。

真实场景:Struts2S2-066应急。2023年底 CVE-2023-50164（Struts2文件上传路径穿越，可致 RCE）爆出来那天是周末，当时我们还没有这套平台，流程是:群里发通知→各团队自查→填表汇总，一套下来至少两三天，还总有人漏报。2025年平台上线后再遇到同类组件漏洞应急，做法完全变了:直接在资产检索框输入“struts2”，一键查出所有装了 Struts2的系统和容器资产，再按版本筛选:2.x 低于2.5.33的、6.x 低于6.3.0.2的全部标红，受影响清单直接导出，按业务负责人派单。从漏洞披露到整改清单下发，分钟级完成。那一刻团队里没人再质疑“为什么要先花一个月做资产清点”。

踩坑心得:资产清点不是一次性工程。我们规定新资产纳管是上线流程的强制前置环节，否则几个月后影子资产又会长回来。

第二步:风险发现——“两高一弱”专项

资产清楚了，接下来回答“这些资产有什么毛病”。行业里的叫法是“两高一弱”:高危漏洞、高危端口、弱口令。我们重点做了漏洞和弱口令两块。

漏洞:白盒扫描 + POC 验证。我们以前用传统漏扫，最大的痛点是误报多、扫出来一堆“疑似”，业务团队根本不买账。平台走的是白盒扫描路线——探针在主机内部直接读取软件版本、补丁状态、配置信息，和漏洞库比对，不向目标发送探测流量，也就不会在业务系统里产生脏数据（扫崩过业务的同事都懂这意味着什么）。扫出来的漏洞再过一道 POC 验证，确认真实可利用才进入整改队列，确保每一条都是“真漏洞”。

优先级排序。漏洞数量永远修不完，排序比扫描更重要。第一轮全量扫描我们扫出四万多条漏洞，如果不排序直接丢给业务，结果就是谁都不修。我们的排序规则是平台给出的三个维度:

有无公开 exp（有 exp 的优先，攻击门槛已经降到脚本小子级别）;

能否远程利用（远程无认证的排最前）;

修复是否需要重启（需要重启核心业务的，排进变更窗口，不要硬上）。

执行层面我们设了 SLA:有 exp 且可远程利用的，高危7天内闭环;需要重启的挂到最近一次变更窗口;其余中低危按月滚动。每个月出一张各部门整改率排行，抄送 CTO，比任何安全宣讲都管用。

弱口令:无损哈希碰撞检测。传统弱口令检测是拿字典去暴力登录，会产生大量登录失败日志，触发账号锁定，甚至对老系统造成压力。平台用的是无损哈希碰撞方式:探针直接读取本机口令哈希，在本地和弱口令字典做碰撞，全程不发生网络登录行为，对业务零影响。另外它还做了多主机口令复用排查——同一个弱口令在多少台机器上通用，一张图就看出来。我们第一次跑的时候发现某运维通用口令复用在300多台机器上，冷汗都下来了，这等于拿到一台就等于拿到一片。

▲主机风险分级视图:危急/高危漏洞按存在EXP、远程利用等特征排序

第三步:基线与上线门禁——把标准卡在投产之前

风险和基线是两回事:漏洞是“没打补丁”，基线是“配置就不对”。我们按等保要求和 CIS 基准做配置核查，平台内置了100多条检查规则，覆盖从操作系统（密码策略、审计配置、权限设置）到中间件(Nginx、Tomcat、MySQL 等)的层面。

但基线检查最大的价值不在“查存量”，而在“卡增量”。我们把青藤深睿 CWPP 的基线能力做成了上线门禁，新业务投产前必须过四步体检:

1.等保模板扫描:按等保模板跑基线检查，自动生成报告，问题项派单到责任人限期整改;

2.脆弱性整改:漏洞、弱口令同步清零;

3.恶意代码清除:确认系统里没有 webshell、木马等遗留;

4.整改验证:复查通过后，才允许投产。

规则只有一句话:验证不过，不投产。刚开始业务团队有怨言，觉得拖慢了上线节奏。跑了两个季度后反过来了——上线后再出安全问题被回滚的成本，远比上线前多花半天整改高，业务团队自己开始主动提前送检。

踩坑心得:基线模板不要一刀切。我们按业务类型分了三四套模板，核心交易系统从严，内部工具从宽，否则整改量会把团队淹死。

▲合规基线核查:等保/CIS规则逐项检查并给出修复建议

第四步:入侵检测——先开平衡档，跑一个月再说

入侵检测是最考验运营功底的模块，也是最容易“开了又关”的模块——误报太多，分析师疲了，告警就形同虚设。我们团队两个人轮值看告警，每天能认真处置的上限大概三四十条，超过这个数就一定会有人开始批量点“已读”。

青藤深睿 CWPP 提供了严格、平衡、宽泛三档检测策略。我们的经验是:别一上来就开严格档。我们先开平衡档跑了整整一个月，摸清自己环境的误报水位，把业务正常行为（比如运维批处理脚本、备份软件的批量文件操作）加白，确认告警量降到团队每天能消化完的水平，再逐步往上调。

针对勒索场景，我们重点配置了行为锚点告警:删除备份（比如调 vssadmin 删卷影）、批量文件加密行为、批量修改文件后缀。这三个动作在正常业务里几乎不会出现，一旦出现就是高置信度事件。

真实案例:一次0day 入侵的主机侧全链条还原。这是我们最有说服力的一次实战。攻击过程是这样的:

1.攻击者通过钓鱼邮件控制了人事部门一台办公电脑;

2.利用一个0day 漏洞向内网服务器上传了一个 webshell——冰蝎的变种，流量做了 Unicode 混淆编码。事后复盘确认:所有流量侧安全产品，零告警。

3.但 webshell 落盘的瞬间，主机侧探针就检出并删除了它。攻击者不死心，继续操作;

4.攻击者在主机上做本地信息收集（查用户、查网络、查进程），触发主机侧信息收集行为告警，被抓;

5.随后改用白加黑手法做远控:用正常的 NotepadPlus.exe 加载恶意的 EndNote.dll，绕过白名单检查——这个动作又被主机侧的应用白名单/异常加载检测抓到;

6.最后攻击者用 netsh 做端口代理，把3389转发映射到18080端口准备长期维持通道，再次被检出。

这条链给我们的结论非常清楚:0day 防不住，这是事实;但攻击者拿下入口之后的每一步动作——落盘、信息收集、权限维持、横向通道——都会引起主机侧的指标变动。边界是可能被绕过的，但只要工作负载上有一双眼睛，攻击者的后续动作就无处遁形。这也是为什么我们把 CWPP 定义为“最后一道防线”而不是边界产品的补充。

另外一个运营细节:这次事件里的四条告警，每一条我们都做了处置记录并回填到检测策略里，比如把冰蝎变种的混淆特征加进了自定义规则。入侵检测不是装上就完事的产品，是越运营越准的系统。

第五步:防勒索与分级阻断——按资产等级开火

勒索是当前对工作负载威胁最直接的场景，我们单独做了专项。平台的勒索检测是三层结构:

静态检测:已知勒索家族的特征匹配;

行为检测:加密行为、删备份等异常操作识别;

诱饵文件:在关键目录放置诱饵，勒索软件一旦加密诱饵立即暴露。

三层叠加，官方口径覆盖90余个勒索家族及其变形。

比检测更重要的是阻断策略，这里有个真实的两难:阻断开太狠，误伤业务;不开阻断，检测等于看戏。平台的阻断是分级的，从轻到重依次是:进程内行为阻断 → 进程阻断 → 文件隔离 → 主机网络隔离。我们的做法是把阻断级别和资产等级挂钩:

核心生产系统:先只开前两级（进程内行为阻断 + 进程阻断），宁可事后人工处置，也不能让安全软件把交易进程杀了;

DMZ 区和测试区:直接开到主机网络隔离。这些区域暴露在攻击面最前面，真中了勒索，第一时间把它从网络里切出去，比保住这台机器重要得多。

踩坑心得:阻断策略上线前一定要用测试环境跑一遍回归，特别是文件隔离级别，某些业务软件的高频文件读写行为可能触发误判。我们还会在每季度做一次勒索演练:在隔离的测试机上投放模拟加密行为样本，验证三层检测是否都响、阻断是否按预期级别动作、告警是否在规定时间内到达值班手机。检测能力这种东西，不演练就等于没有。

第六步:取证与复盘——让溯源报告回答三个问题

出了事件之后怎么办，决定了团队能力是原地踏步还是螺旋上升。以前我们做溯源，靠人工登机器翻日志，一次中等规模的事件要两三个人搞一周，还经常因为日志被攻击者清掉而断链。

深睿 CWPP 的采集是主动式的，底层用了 eBPF、RASP、Netlink 等技术，覆盖30余大类、180余子类的主机行为数据，而且是单一 Agent 全场景采集——不需要出了事再临时装取证工具，数据平时就在沉淀。

现在我们的溯源报告固定回答三个问题:

1.怎么进来的?初始入口是什么，钓鱼、漏洞还是弱口令;

2.动了什么?攻击者执行过哪些命令、读过哪些文件、连过哪些外联地址、建了什么持久化;

3.根拔干净没有?所有持久化点（计划任务、自启动项、隐藏账号、残留 webshell）是否全部清除。

第三个问题最容易被忽视。我们吃过亏:一次事件处置完一个月后又复发，复盘发现攻击者留的一个计划任务没清干净。现在“根拔干净没有”是事件关闭的硬性检查项，清单一项项打勾才能归档。

收尾:一张落地自检清单

最后把我们这轮落地的自检清单留给大家，按顺序打勾就行:

一句话收束:边界会被绕过，漏洞修不完，但工作负载是攻击者无论走哪条路都最终要落脚的地方——把防线建在这里，才算把主动权拿回自己手里。

参考来源

Verizon， Data Breach Investigations Report （DBIR）2026

CISA Known Exploited Vulnerabilities （KEV） Catalog 修复时效统计

Apache Struts 安全公告 S2-066（CVE-2023-50164）