2. 企业信息资产梳理与分类分级

资产梳理是风险评估的起点。如果连“有哪些资产、在哪里、由谁负责、承载什么业务”都说不清，后续的威胁识别、脆弱性分析和风险计算都会失去基准。本节围绕资产识别方法、资产清单模板、业务流与数据流映射、分类分级标准四个环节展开，并给出一套可直接套用的实操演练流程。

一、资产识别：从“看得见的设备”到“看不见的数据”

资产识别常见的误区是只盘点服务器、交换机、终端等硬件，而遗漏数据、账号、证书、API 接口、云资源、第三方服务等软资产。建议采用“自上而下 + 自下而上”双线并行的方法：

• 自上而下（业务驱动）：从业务流程出发，逐层拆解支撑该业务的系统、应用、数据库、接口、账号与数据，适合发现跨部门、跨系统的隐性依赖。
• 自下而上（工具驱动）：通过网络扫描、CMDB 导出、云平台资源清单、终端管理平台、代码仓库、域名与证书台账等自动采集，适合发现“影子资产”。

两条线交叉比对后形成的差异清单，往往就是资产管理的盲区。识别过程中建议同步记录资产的归属部门、责任人、物理/逻辑位置、对外暴露面、生命周期状态，这些字段直接决定后续风险赋值与处置优先级。

二、资产清单模板：字段设计决定可用性

资产清单不是越全越好，而是要让每个字段都能被后续的风险计算或运维动作消费。以下模板字段经过裁剪，兼顾识别、分级与责任落实：

字段填写时要注意两点：一是“数据敏感级”和“业务重要性”是两个独立维度，不能互相替代；二是“责任人”必须落到具体自然人，写部门名称在应急响应时无法闭环。

三、业务流与数据流映射：把资产串成链路

单点资产清单无法回答“这个数据库被谁调用、数据流向哪里”。业务流映射解决的是“资产之间如何协作”，数据流映射解决的是“数据在链路上如何流转、经过哪些边界”。

实操中建议先画业务流，再叠加数据流。以“用户下单”为例：用户终端 → 负载均衡 → 订单 API 网关 → 订单服务 → 订单数据库，同时订单服务还会向支付服务、库存服务发起调用，并把订单事件写入消息队列。把每个节点标注资产编号后，就能看出哪些资产处于关键路径、哪些资产跨越了信任边界。

四、分类分级标准：两个维度、四档粒度

分类解决“是什么类型”，分级解决“有多重要”。两者必须分开定义，否则会出现“财务系统里的公开宣传页”被整体拔高、或“核心数据库里的测试数据”被整体低估的问题。

分类维度建议按资产形态划分：硬件类、软件类、数据类、服务类、账号与凭证类、文档与知识类。每类下再设二级子类，例如数据类可分为客户数据、交易数据、运营数据、日志数据。

分级维度建议采用四档：

• 一级（核心）：泄露或中断会导致重大业务停摆、监管处罚或重大声誉损失，如订单数据库、支付密钥。
• 二级（重要）：影响局部业务或造成中等损失，如内部 OA、测试环境数据库。
• 三级（一般）：影响有限，可短时间恢复，如办公终端、打印服务。
• 四级（公开）：可对外公开，如官网静态页面、公开宣传材料。

分级判定建议用“影响对象 × 影响程度”矩阵：影响对象分为业务、财务、合规、声誉四类，影响程度分为严重、中等、轻微。取最高档作为最终级别，避免逐项加权导致核心资产被平均稀释。

五、实操演练：以“订单中心”为例走完一轮

假设某电商企业要对订单中心做一轮资产梳理，可按以下步骤推进：

1. 圈定范围：以“用户下单到订单完成”为主链路，纳入网关、订单服务、订单库、消息队列、支付服务、库存服务及其依赖的账号与证书。
2. 采集资产：从 CMDB 导出服务器与应用清单，从云平台导出 VPC、安全组、RDS 实例，从代码仓库导出服务依赖关系，从域名与证书台账导出对外暴露面。
3. 填写清单：按模板逐项填写，重点确认“网络暴露面”和“数据敏感级”。例如订单 API 网关暴露面为互联网、数据敏感级为秘密；订单数据库暴露面为内网、数据敏感级为机密。
4. 绘制映射：按上文示例画出业务流与数据流，标注每条链路跨越的信任边界。
5. 分级定档：订单数据库因承载交易数据且中断影响核心业务，定为一级；订单 API 网关因直接暴露互联网且承载鉴权逻辑，定为一级；消息队列定为二级；库存服务定为二级。
6. 复核与归档：由业务负责人和技术负责人双签确认，录入资产管理系统，并设定每季度复核一次、重大变更后即时更新。

完成上述步骤后，企业应得到一份可追溯、可更新、可支撑风险计算的资产清单，以及一张覆盖关键业务链路的业务流与数据流映射图。这两项成果将直接作为后续威胁识别与脆弱性分析的输入。