1. 企业数据资产盘点与分类分级清单编制

场景与盘点边界

某企业有三类数据载体：业务数据库（MySQL，订单/客户/支付）、文件共享（SMB，合同/报表/人事）、对象存储（S3 兼容，日志/备份/影像）。盘点目标不是"列出所有表"，而是形成可审计的字段级清单：每个字段都要有业务归属、分类分级、规则依据和责任人。

先固定盘点边界，避免范围蔓延：

• 纳入：生产库、共享目录、对象存储桶中承载业务数据的结构化字段与文件集合。
• 排除：纯系统表、临时缓存、无业务语义的中间表（需在清单中标注"排除原因"）。
• 粒度：数据库到字段级；文件共享到目录+文件类型；对象存储到桶+对象前缀。

分类分级规则与业务属性映射

分类回答"这是什么数据"，分级回答"泄露后影响多大"。本例采用四级：L1 公开、L2 内部、L3 敏感、L4 核心。规则必须能回溯到业务属性，否则审计时无法解释"为什么这个字段是 L3"。

字段级标注流程

对每个数据源执行四步：发现（枚举表/目录/桶）→ 采样（读取字段名、类型、前 N 行样例）→ 匹配（对照规则表打分类分级标签）→ 登记（写入清单并指定 Owner）。采样只读，不修改生产数据；样例需脱敏后留存。

下面这张图展示三类数据源如何汇入统一清单，以及规则匹配与人工复核的分支关系：

清单字段与审计要求

清单不是一次性表格，而是可追溯的台账。每个字段至少包含以下列，缺一列即视为审计不通过：

验证分类分级与业务属性的对应关系

盘点完成后必须做一致性验证，否则清单只是"填过的表"。验证方法：从清单中随机抽取 10 个字段，反向检查其业务属性是否与分类分级匹配。例如：

• customer.id_card → 业务属性"客户身份" → 分类"个人信息" → 分级 L4，规则 R-01 命中，通过。
• orders.amount → 业务属性"交易金额" → 分类"经营数据" → 分级 L3，规则 R-03 命中，通过。
• logs/access.log → 业务属性"系统日志" → 分类"运维数据" → 分级 L2，规则 R-06 命中，通过。

可执行清单模板（CSV 结构）

asset_path,business_attr,category,level,rule_id,owner,sample_time,review_status,exclude_reason
mysql://prod/customer.id_card,客户身份,个人信息,L4,R-01,客户域-张工,2025-06-01 10:00,已复核,
mysql://prod/customer.phone,联系方式,个人信息,L3,R-02,客户域-张工,2025-06-01 10:00,已复核,
mysql://prod/orders.amount,交易金额,经营数据,L3,R-03,交易域-李工,2025-06-01 10:05,已复核,
smb://share/合同/2025-001.pdf,合同文本,商业机密,L4,R-04,法务-王工,2025-06-01 10:10,已复核,
smb://share/报表/月度.xlsx,内部报表,经营数据,L2,R-05,财务-赵工,2025-06-01 10:12,已复核,
s3://logs/access/,系统日志,运维数据,L2,R-06,运维-陈工,2025-06-01 10:15,已复核,
s3://backup/db-snapshot/,备份影像,运维数据,L3,R-07,运维-陈工,2025-06-01 10:18,待复核,
mysql://prod/tmp_session,临时会话,排除,-,-,-,2025-06-01 10:20,已排除,无业务语义且7天自动清理

该 CSV 可直接导入资产管理系统或作为审计底稿。注意最后一行展示了"排除"的处理方式：仍保留记录，但标注排除原因，避免审计时被质疑"为什么没盘到"。

常见问题与处理

• 字段名无业务含义（如 col_12）：必须采样数据内容或询问开发，不能直接标 L1。
• 同一字段多业务属性：按最高级别标注，并在备注中列出所有属性。
• 对象存储无法逐字段：按前缀+文件类型聚合，但需抽样确认内容级别。
• Owner 缺失：挂起该字段，不进入正式清单，直到指定责任人。