## ******核心摘要 / 阅读指南******

-   ****三个判断****：指南第 2 章认为主机安全能力的演进方向是——持续检测是基础、快速响应是动力、架构适配是未来；
-   ****时间窗口****：攻击者从入侵到横向移动平均仅 29 分钟，以特征库为核心的静态检测已经防不住新威胁；
-   ****落地路线****：检测能力对照 ATT&CK 矩阵查空白；响应能力把「告警到处置的时长」当核心指标；架构选型向容器、Serverless 等云原生工作负载对齐；
-   ****阅读路线****：赶时间的读者可直接看文末「三个判断如何落到建设路线图」一节。

## ******入侵到横向移动平均 29 分钟，防守方的时间窗口还剩多少？******

CrowdStrike 在《2026 年全球威胁报告》中给出了一组值得反复咀嚼的数字：攻击者从入侵得手到开始横向移动的平均时间已经缩短至 29 分钟，最快纪录仅 27 秒。需要特别说明的是，这里的 29 分钟和 27 秒指的是「从突破边界、拿到第一台主机的立足点，到开始向内部其他主机横向移动」的速度，而不是加密完成时间或者数据外传时间——但即便如此，它传递的信号也足够刺眼：防守方可用的响应窗口，正在被压缩到以分钟、甚至以秒计。

窗口被压缩之后，一个更根本的问题浮出水面：主机安全能力到底该向哪里演进？是继续堆叠单点产品，还是换一种思路重建体系？

由信通院云大所与青藤云安全联合发布的《主机安全能力建设指南》（以下简称「指南」），据其前言表述是国内首个主机安全能力建设指南，目的是帮助企业梳理主机安全能力需求与产品评估流程，为选择主机安全产品、建设自适应的主机安全能力提供策略指导。文中涉及市场与现状的描述，均以指南记载为准。

时隔多年再读这份指南，其第 2 章对主机安全能力发展态势做出的三个判断，放到 2026 年的攻防节奏下重新检验，依然具有很强的解释力：

-   持续检测是基础——没有全天候的「看见」，一切响应都是空谈；
-   快速响应是动力——入侵无法被彻底杜绝，响应速度决定损失边界；
-   架构适配是未来——工作负载形态剧变，安全能力必须跟着架构走。

下面逐一拆解。

## ******签名检测为什么防不住新威胁？——持续检测是基础******

指南的第一个判断，建立在攻击者与防守者地位不对等这一前提之上。传统基于报警或已有威胁特征的检测技术，包括防火墙、IPS、杀毒、沙箱等被动防御手段，在应对未知威胁时存在三点不足（指南原文口径）：

****其一，检测技术单一。**** 基于签名的检测技术无法检测未知威胁，更无法定位失陷主机。签名库天然是「事后知识」，攻击者只需做简单的变形、加壳或者干脆采用无文件攻击，就能让一大批依赖特征匹配的设备失效。

****其二，缺乏持续检测。**** 传统手段往往仅支持阶段性检测，扫一次出一个报告，无法覆盖威胁入侵的全生命周期。而真实的攻击是连续发生的——从初始入侵、权限提升、横向移动到目标达成，中间任何一个环节的检测空窗，都可能成为攻击者的绿色通道。

****其三，无法进行联动。**** 各安全检测产品单兵作战，攻击告警信息割裂。防火墙看到流量异常，杀毒看到可疑文件，但两者之间没有关联，安全人员面对的是一堆彼此孤立的告警碎片，拼不出完整的攻击图景。

要补上这三块短板，指南给出的方向是：防守方需要对攻击有深入的理解，并采用更加细粒度的安全模型。这里引入了一个关键工具——MITRE ATT&CK。

![](https://developer.qcloudimg.com/http-save/yehe-12748360/10897f66a130bdf87232e7d916c4c37f.png)

::: center  
*图1：**ATT&CK 矩阵*
:::

按照指南引用时的版本规模，MITRE ATT&CK 覆盖了攻击者在攻击过程中使用的 14 项战术、190 多项技术和 380 多项子技术，其中既包括特定技术和通用技术，也包含知名攻击组织及其攻击活动的背景信息。简单来说，ATT&CK 是一个对抗行为知识库：它把「攻击者会做什么」拆解成一张可以逐项对照的矩阵，每一个战术类别都包含一系列攻击技术，并提供每项技术的细节描述、检测方法、分析思路以及可能的缓解措施。

这份知识库对安全从业者的价值，指南总结为三点：帮助安全人员构建检测措施、验证防御措施，并分析策略的有效性。更具体地说，企业可以按照 ATT&CK 模型的覆盖度和检测点，逐项盘查自身的检测能力落在矩阵的哪些格子、哪些格子还是空白，从而找到改进方向。如何根据 ATT&CK 框架检查安全产品的整体覆盖度、做全面的差异分析，以及如何将其涵盖的技术点融入产品，指南认为这些都是值得安全从业者深入思考的问题。

把视角拉回 2026 年：当横向移动的平均耗时只有 29 分钟，「阶段性扫描加人工研判」的模式显然追不上攻击者的节奏。持续检测之所以是「基础」，原因就在于它决定了防守方能不能在攻击链的早期环节就看见异常——看见得越早，后面响应环节的余地才越大。

## ******响应为什么比阻断更重要？——快速响应是动力******

指南的第二个判断颇为坦诚：从攻防实战演习可以看出，无法保证系统不被入侵，入侵后的快速响应能力才是关键。

这句话背后是一个务实的前提假设——安全攻防对抗日趋激烈，单纯的防范和阻止策略作用有限，企业必须假定已遭受攻击，构建集防御、检测、响应和预防于一体的全新防护体系。阻断当然重要，但把全部赌注押在「挡在门外」上，等于承认一旦有人进来就束手无策。相比之下，入侵发生后的响应速度，直接决定了攻击者能在内网走多远、造成多大损失。

那么，一套完善的响应流程应该长什么样？指南建议建立包含六个阶段的工作流程，根据网络安全应急响应总体策略对每个阶段定义适当的目标，明确响应顺序和过程：

1.  ****查询****：提供快速、实时、支持自然语言的查询工具，帮助调查人员快速发现攻击的 IOC 类型。这是响应的起点——数据已经有了，关键是能不能用最短路径把可疑线索捞出来。
2.  ****排序****：根据时间严重性以及受影响资产的业务价值，对风险进行优先级排序。告警永远比人力多，先处理什么，必须由业务影响说了算。
3.  ****可视化****：借助攻击链可视化工具，使调查人员可以从数据中获取或钻取更多信息，把碎片线索还原成完整攻击路径。
4.  ****获取****：可以自动获取可疑文件，或内存和磁盘转储，把取证所需的关键证据第一时间固定下来。
5.  ****分析****：自动集成分析云或沙箱，对可疑进程、文件进行深度分析，确认威胁性质。
6.  ****工作流****：提供警报管理工作流的调查工具，让响应动作有序流转、可追溯、可复盘。

![](https://developer.qcloudimg.com/http-save/yehe-12748360/6456e57b822450b3ee8ecc3761c7ea8c.png)

::: center  
*图 2：网络安全应急响应流程*
:::

流程建立之后，还有一个绕不开的现实问题：人不够。指南指出，当前企业内部应急响应人员数量有限，人员超负荷处理安全事件将会产生懈怠情绪，并可能忽视真正需要处理的事件。因此，通过相应工具自动或半自动地对安全事件进行处理，是进行安全响应的必要手段。

这正是 SOAR（安全编排自动化与响应，Security Orchestration, Automation and Response）要解决的问题。指南对其机制做了清晰的拆解：SOAR 聚焦安全运维领域，重点解决安全自动化响应问题。它通过剧本（Playbook）进行表述，以工作流引擎支撑剧本执行；为了方便管理人员维护剧本，SOAR 通常提供一套可视化的剧本编辑器，让编排管理员聚焦于编排安全操作的逻辑本身，而隐藏具体连接各个系统的编程接口及指令实现；在落地层，SOAR 通常通过应用（App）和动作（Action）机制，实现可编排指令与实际系统的对接。

用一句话概括这一节的逻辑：响应流程回答「怎么处置才科学」，SOAR 回答「人少事多怎么扛得住」。两者结合，快速响应才从口号变成可运行的机制。

## ******工作负载生命周期从年缩到秒，检测怎么跟？——架构适配是未来******

指南的第三个判断着眼于更长远的变化：随着云计算市场快速发展，多云和云原生成为主流，主机安全产品必须不断发展以适配新架构。

观察这一趋势，指南援引了 Gartner 对云工作负载保护平台（CWPP）定义的演进过程，这条时间线本身就很有说服力：

-   ****2017 年****，CWPP 的保护对象是由物理机和虚拟机（VM）、私有云以及多个公共云基础设施即服务（IaaS）环境构成的现代混合数据中心中的主机工作负载——核心还是「机器」；
-   ****2019 年****，Gartner 对工作负载的外延和内涵做了细粒度解释，根据抽象度的不同分为物理机、虚拟机、容器和 Serverless——保护对象开始分层；
-   ****2022 年****，CWPP 的保护对象演进为混合云和多云环境中的各类云原生工作负载——抽象度更高的形态成为主角。

注意这条演进线的方向：从传统主机走向云原生，而不是相反。理解这个方向，再看「主机安全」这个词，就会发现它的内涵早已被重新定义——今天的主机安全，实际上是在保护各种抽象层级的工作负载。

![](https://developer.qcloudimg.com/http-save/yehe-12748360/264d255578b5f36de180c622f36ab047.png)

::: center  
*图 3：工作负载抽象度的演变*
:::

图 3 展示的抽象度演变值得细看，因为它直接解释了「检测节奏为什么必须跟上」：

-   ****物理机****时代，应用形态是单体应用，扩容单位是物理服务器，生命周期以年计；
-   ****虚拟机****时代，Hypervisor 虚拟化了硬件，扩容单位变成 VM，生命周期缩短到几个月到几年；
-   ****容器****时代，虚拟化发生在操作系统层，扩容单位是应用或服务，生命周期只有几分钟到几天；
-   ****无服务器（Serverless）****时代，虚拟化上升到应用运行时层，扩容单位是资源，生命周期以几秒到几分钟计。

生命周期从「以年计」压缩到「以秒计」，对安全检测意味着什么？指南给出了几个观察：Linux 容器被广泛应用，基于 Serverless 函数的 PaaS 平台采用率不断攀升，CI/CD 管道中工作负载部署频率增加、生命周期非常短暂。一个只存活几十秒的 Serverless 函数，传统的「装 Agent、跑扫描、出报告」模式根本来不及展开。为此，指南指出，CWPP 解决方案利用主动技术和流程，在开发管道的早期集成基础设施即代码（IaC）或策略即代码（PaC），把安全能力前置到工作负载诞生之前。

与 CWPP 并行出现的还有 CNAPP（云原生安全防护平台）。指南指出，CNAPP 可以解决运行时保护、云配置和工件扫描问题，与 CWPP 具有一致性——许多增加了 CSPM（云安全态势管理）和 DevSecOps 功能的 CWPP 供应商，也被认为是 CNAPP 供应商。换句话说，CWPP 和 CNAPP 并非替代关系，而是同一演进方向上的汇合：保护对象一致，能力边界在相互靠拢。

架构变了，安全体系该怎么搭？指南倡导的答案是：围绕 DevOps 流程打造全生命周期的云原生安全体系，把安全性和合规性视为从开发阶段到运营阶段的连续统一体，而不是用一组单点工具各自为战。

![](https://developer.qcloudimg.com/http-save/yehe-12748360/9c415f80cd334f416bb5d0fbf6342970.png)

::: center  
*图 4：全生命周期的云原生安全体系*
:::

这套体系分为两个阶段：

****在开发阶段（Dev），遵循「安全左移」原则，做到「上线即安全」。**** 通过早期定位和解决安全问题，减少攻击面和潜在的运行问题，而不是把安全问题留到线上环境中去解决——具体包括镜像层安全检查、应用层风险检查、基础设施层安全检查。指南同时提醒，将传统安全理念、管理思路及产品技术照搬到云上，并不能真正建立有效的云原生安全运营体系，动态资产盘点、配置风险检测、合规自动化评估、新型威胁检测、自动化响应处置、调查溯源等方面的缺失，都是照搬模式下的典型风险。

****在运行阶段（Ops），遵循「持续监控&响应」原则，做到自适应安全。**** 在整体安全落地时进行云原生安全的全生命周期管理，包括工作负载清点与可视化、微隔离、入侵检测、安全响应、溯源分析等。

可以看到，第三个判断和前两个判断在这里完成了闭环：云原生环境下的「自适应安全」，本质上就是持续检测与快速响应在新架构上的延续。

## ******三个判断，如何落到甲方的建设路线图上？******

回到开头的问题：29 分钟的横向移动速度面前，主机安全能力向哪里演进？指南给出的三个判断，其实暗含了一条清晰的路线图。

****第一步，先把持续检测的数据底座建起来。**** 检测是一切的前提。企业需要对照 ATT&CK 之类的对抗行为知识库盘点自身覆盖度，识别检测空白，把阶段性扫描升级为覆盖威胁全生命周期的持续监测。没有这一步，响应再快也只是「看不见敌人的快」。

****第二步，用流程和自动化补齐响应。**** 参照查询、排序、可视化、获取、分析、工作流六个阶段梳理内部响应流程，再通过 SOAR 之类的编排自动化手段，把有限的安全人力从重复性处置中解放出来，优先投入真正需要研判的事件。

****第三步，架构选型向云原生对齐。**** 工作负载抽象度仍在提升，生命周期仍在缩短，安全能力的评估标准也应随之更新：是否支持从物理机、虚拟机到容器、Serverless 的统一保护？是否能把安全检查前置到开发管道？是否具备开发到运行的全生命周期视角？这些问题的答案，比单个功能点的强弱更能决定三五年后的安全水位。

作为这份指南的联合发布方，青藤云安全长期聚焦主机安全与云原生安全领域，其在云工作负载保护方向的产品实践，也是指南能够把「持续检测、快速响应、架构适配」讲得言之有物的底气之一。

攻防的速度竞赛不会停下。29 分钟也好，27 秒也罢，数字本身会被不断刷新，但「看见得更快、响应得更快、适配得更快」这三个方向，值得每一个甲方安全团队在未来的路线图上一再对照、反复校准。


##  ******FAQ：主机安全能力演进的常见疑问******

****Q1：已经装了 EDR，还要关心「持续检测」吗？**** 

A：要看检测覆盖面而非产品名称。可以按 ATT&CK 矩阵逐项盘查自家检测能力落在哪些格子、哪些格子还是空白——装了工具不等于覆盖了攻击手法，空白格就是持续检测要补的方向。

****Q2：「快速响应」有没有可量化的标准？**** 

A：可以用攻击者的时间窗口做参照：从入侵到横向移动平均 29 分钟，那么「告警产生到完成处置」的时长就应当成为核心运营指标。响应慢于这个窗口，检测再准也只是事后取证。

****Q3：容器和 Serverless 场景下，传统主机安全产品还能用吗？**** 

A：这正是「架构适配」要回答的问题。工作负载的生命周期已从年缩到秒，选型时应验证产品能否统一保护物理机、虚拟机、容器与 Serverless，能否把安全检查前置到开发管道，而不是在旧架构上打补丁。

三个判断：指南第 2 章认为主机安全能力的演进方向是——持续检测是基础、快速响应是动力、架构适配是未来；

主机安全能力向哪里演进？《主机安全能力建设指南》三大发展态势拆解

攻击者横向移动平均仅29分钟，还在依赖特征库和阶段性扫描？《主机安全能力建设指南》三大演进方向给你答案：持续检测是基础、快速响应是动力、架构适配是未来。从对标ATT&CK找出检测盲区，到SOAR自动化提速，再到应对以秒计的容器与Serverless生命周期。附甲方建设路线图，带你告别单点堆砌，重塑自适应安全体系。

安全

云计算

运维

持续检测是基础，快速响应是动力，架构适配是未来。攻击者横向移动平均仅需29分钟，静态签名检测已失效。企业需对照ATT&CK矩阵查检测空白，将告警到处置时长作为核心指标，并向容器、Serverless云原生架构对齐。

主机安全

网络安全

虚拟化

虚拟机

服务器

私有云

混合云

防火墙

DevSecOps

云安全

云原生

多云

容器

DevOps

PaaS

IaaS

腾讯云双十一大促

serverless-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

主机安全能力向哪里演进？《主机安全能力建设指南》三大发展态势拆解-腾讯云开发者社区-腾讯云

主机安全能力向哪里演进？《主机安全能力建设指南》三大发展态势拆解

主机安全能力向哪里演进？《主机安全能力建设指南》三大发展态势拆解

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐