📚 课程目录第3章资产信息建模

资产信息建模：资产清单构建、软件版本管理、资产关键度分级、资产依赖关系梳理

各位同学，咱们今天聊一个特别实在的话题——资产信息建模。

你可能觉得这名字听着有点抽象。说白了，就是搞清楚你手里到底有什么东西需要保护。我见过太多团队，CVE 爆出来之后手忙脚乱，连哪个服务器跑着什么软件都说不清楚。嗯，这种状态下谈风险优先级，基本就是瞎蒙。

所以这一章，咱们把资产建模拆成四个核心动作：建清单、管版本、定关键度、理依赖。每一步我都会结合实战经验来讲。

3.1 资产清单构建：别让任何一台机器「隐身」

资产清单是所有安全工作的地基。地基不稳，后面全是空中楼阁。

我个人习惯把资产清单分成三层：

硬件层：物理服务器、虚拟机、容器、云实例
软件层：操作系统、中间件、数据库、应用框架
数据层：数据库表、文件存储、API 端点

每一层都要有唯一的标识符。我建议用 资产 ID 来关联，格式可以这样：

# 资产 ID 示例
HOST-2024-00123  →  物理服务器
VM-2024-00456    →  虚拟机
CTN-2024-00789   →  容器
API-2024-00111   →  API 端点

为什么要这么细？

我曾经遇到过一个案例：某团队只记录了服务器 IP，没记录容器实例。结果一个容器里的 Log4j 漏洞被忽略了整整三个月。你想想看，攻击者最喜欢的就是这种「隐身资产」。

我的小技巧： 资产清单里一定要加一个「发现时间」字段。这样你能知道哪些资产是最近上线的，哪些是历史遗留的。历史遗留资产往往是漏洞重灾区。

3.2 软件版本管理：版本号里藏着生死线

软件版本管理，说白了就是回答三个问题：

这个软件当前是什么版本？
它有没有打过补丁？
它还能不能升级？

我建议用 版本矩阵 来管理。举个例子：

资产 ID	软件名称	当前版本	最新版本	补丁状态	生命周期
HOST-001	OpenSSL	1.1.1k	3.0.12	未打补丁	已停止维护
VM-002	Nginx	1.24.0	1.25.3	已打补丁	活跃支持
CTN-003	Log4j	2.17.1	2.20.0	部分补丁	活跃支持

这里有个坑，我必须提醒你：版本号不能只看主版本。比如 OpenSSL 1.1.1k 和 1.1.1l，就差一个小字母，但后者修复了高危漏洞。我见过有人觉得「差不多」就不升级，结果被 CVE-2022-0778 打了个措手不及。

避坑指南： 我曾经接手过一个项目，资产清单里只写了「Nginx 1.x」。这等于没写。版本号必须精确到 patch 级别，否则 CVE 匹配就是纸上谈兵。

3.3 资产关键度分级：把好钢用在刀刃上

不是所有资产都值得你花同样的精力去保护。关键度分级，就是帮你决定「先救谁」。

我常用的分级模型是 三因素法：

业务影响：这个资产挂了，公司能不能正常运转？
数据敏感度：它存了什么数据？用户密码？信用卡号？还是公开信息？
暴露面：它是不是直接暴露在公网上？有没有 WAF 保护？

每个因素打分 1-5，然后加权求和。举个例子：

# 关键度评分公式
关键度 = 业务影响 × 0.4 + 数据敏感度 × 0.35 + 暴露面 × 0.25

# 示例：核心数据库服务器
业务影响 = 5
数据敏感度 = 5
暴露面 = 3
关键度 = 5×0.4 + 5×0.35 + 3×0.25 = 2.0 + 1.75 + 0.75 = 4.5（高关键度）

分级结果我一般分成三档：

关键度等级	评分范围	响应策略
高（Critical）	4.0 - 5.0	发现漏洞后 24 小时内必须修复
中（High）	2.5 - 3.9	72 小时内评估并制定修复计划
低（Medium）	1.0 - 2.4	纳入常规补丁周期

  我的经验： 关键度分级不是一成不变的。业务调整、数据迁移、架构变化都会影响评分。我建议每季度重新评估一次，至少也要半年一次。否则你会发现，半年前的低关键度资产，现在可能已经变成了核心系统。

3.4 资产依赖关系梳理：牵一发而动全身

这是最容易被忽略的一步，也是实战中最容易出问题的地方。

你想想看，一个 API 网关挂了，后面可能连着十几个微服务。你只修网关没用，还得看它依赖的服务有没有漏洞。这就是依赖关系的重要性。

我习惯用 依赖图 来梳理。下面这张 SVG 图展示了一个典型的资产依赖关系：

从这张图你能看出什么？

如果 API 网关有个 CVE，那它下面的用户服务、订单服务、支付服务全都会暴露。你只修网关是不够的，还得检查下游服务有没有因为网关漏洞而被间接攻击。

我建议用 依赖矩阵 来记录这种关系：

上游资产	下游资产	依赖类型	影响范围
API 网关	用户服务	HTTP 调用	用户数据泄露
API 网关	订单服务	HTTP 调用	订单数据篡改
订单服务	主数据库	数据库连接	数据被删除
用户服务	缓存集群	Redis 连接	缓存投毒

避坑指南： 我曾经遇到过一个案例，团队只记录了直接依赖，忽略了间接依赖。比如 A 依赖 B，B 依赖 C。结果 C 出了漏洞，团队只修了 B，没修 C。攻击者绕过了 B，直接打穿了 C。记住：依赖关系要递归梳理，至少到第三层。

3.5 把四件事串起来：资产建模的实战流程

好了，四个核心动作都讲完了。怎么把它们串起来？

我个人的实战流程是这样的：

第一步：全量扫描。用工具（比如 Nmap、Nessus、或云厂商的资产发现工具）跑一遍，拿到原始资产列表。
第二步：人工核对。工具扫出来的不一定准。我习惯让运维团队过一遍，把测试环境、废弃实例标记出来。
第三步：版本对齐。把每个软件的版本号补全，和 CVE 数据库做一次初步匹配。
第四步：关键度打分。按三因素法给每个资产打分，分出高中低三档。
第五步：依赖分析。画出依赖图，记录依赖矩阵。
第六步：持续更新。资产是活的，清单也得是活的。我建议每周增量更新一次。

  我的经验： 这六步走下来，你手里就有了一份「活」的资产模型。后面做 CVE 匹配和风险优先级，就有了可靠的依据。没有这个基础，后面所有的分析都是空中楼阁。

嗯，这一章的内容就到这里。资产建模听起来繁琐，但它是整个安全运营的基石。你花在建模上的每一分钟，都会在后续的漏洞响应中十倍百倍地赚回来。