企业官网建设流程全解析

数据分类分级这事，甲方安全岗做十次有九次落空。最常见的场景是：拉了三个月会、出了 60 页的分类分级管理办法、做了一张 800 行的数据资产清单，交上去评了个优——然后系统里一个字段都没打标，业务侧该导出的还在导出，该明文存手机号的还在明文存。

问题不在写文档的水平，在于大部分分类分级项目做的是"合规交付物"，不是"技术控制"。分类分级真正的价值只有一个：让"这条数据该怎么管"变成系统能执行的判断。做不到这一点，文档写得再漂亮也只是一份应付检查的材料。

这篇按"坐标系 → 盘点 → 定规则 → 自动识别 → 打标审批 → 管控落地"六段写，给可以直接套用的矩阵、判定树、识别脚本和管控对照表。

一、先认清三个根因：为什么分类分级一定落地失败

做了几轮之后，我发现失败原因高度集中在三个地方，而且跟技术水平关系不大：

根因一：字典是从法规抄的，不是从业务长的。拿着《数据安全法》和行业规范，照着抄了一张"数据分类目录"，里面写着"客户信息、经营数据、财务数据"。业务侧看了第一反应是"这跟我系统里的表对不上"——于是没法用。真正能用的字典，必须能落到具体的表名和字段名上。

根因二：只做分级，没做管控映射。分级的结果如果是"这个字段是 3 级"，运维拿着这句话什么也做不了。要的是"3 级字段：存储必须加密、查询必须脱敏、导出必须审批、留存不超过 3 年、禁止出境"。分级不是终点，是查表的索引。

根因三：没有 owner，只有项目组。项目组撤了，分类分级就停了。数据分级天然需要"业务 owner 定级、安全团队定规则、IT 执行"三方分工，缺了 owner 这一环，级别永远停留在文档里。

二、先立坐标系：数据分类分级里，分类和分级是两件不同的事

很多人把这两个词当一个词用，结果做出来的东西两头不靠。它们是两个正交的维度：

• 分类回答"这是什么业务的数据"，看的是业务属性，维度通常是：业务领域（客户/产品/财务/人力）、数据主体（个人/企业/设备）、处理活动（采集/传输/存储/使用/共享/销毁）、流通范围（内部/合作方/公开）。
• 分级回答"泄露或破坏后有多严重"，看的是影响程度，落到具体级别上。

分类决定"归谁管"，分级决定"管多严"。两者组合才能得到一条可执行的控制要求。

国家层面的分级口径是三层：核心数据、重要数据、一般数据（依据《数据安全法》第二十一条和 GB/T 43697-2024《数据安全技术 数据分类分级规则》）。企业内部管理通常把"一般数据"再细分，落成 1~4 级，便于和权限、加密、审批策略对齐：

这张表是整个项目的地基，建议在项目启动会上就和业务、法务、IT 三方确认，形成书面结论。后面所有的盘点、判定、管控，都以这张表为准，不再改口径。

有一个高频争议点值得提前说清："重要数据"不是"重要的数据"。它是有法定含义的，指一旦被篡改、破坏、泄露或者非法获取、非法利用，可能危害国家安全、经济运行、社会稳定、公共健康和安全的数据。企业内部觉得"很重要"的客户名单、报价单，绝大多数不属于重要数据，属于 2 级商业秘密。这个界线划错，会导致整套管控过度，项目推不动。

三、数据资产盘点：别一上来就盘全公司

盘全是分类分级项目里最典型的自杀式开局。一个中型企业全量盘下来，几十万个字段，项目周期拖到一年，业务早就失去耐心了。

建议按"三先"原则圈定首期范围：

1. 先核心系统——承载主营业务、有对外服务、有大量个人信息的系统，通常 3~5 套。
2. 先结构化数据——数据库表和字段先做，因为可枚举、可自动化、可验证。文件、图片、音视频放第二期。
3. 先出网数据——有对外接口、有数据共享、有第三方接入的先做，因为这是泄露风险最高的路径。

盘点表的字段建议就这九列，别贪多：

"流转路径"这一列是大多数人会漏的，但它比前八列都重要。因为数据的风险不在它存在哪，在它流到哪。同一个身份证号，在业务库里是 2 级、加密存储就够；一旦同步到测试环境、被导出成 Excel 发到工作群、被推送到第三方开票平台，风险等级完全不同。

盘点的产出不是一张表，是一张带血缘的表——顺着字段能回答"这个数据从哪来、经过哪些系统、最终落到谁手里"。

四、定规则：把数据分类分级写成可判定的判定树

规则不要写成"如果包含个人信息则为 2 级"这种模糊表述，要写成可判定的判定树。一个够用的判定顺序：

1. 是否属于法律明确列举的重要数据/核心数据目录？是 → 直接定 3/4 级，走行业主管部门确认。
2. 是否属于个人信息？否 → 走第 4 步。
3. 属于个人信息的话：是否含敏感个人信息（生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹，以及不满十四周岁未成年人的个人信息）？是 → 至少 2 级，量大或与其他数据结合可识别性强的上调到 3 级。
4. 是否为企业经营核心数据（成本、定价、供应链、未公开财务）？是 → 2 级。
5. 其余 → 1 级。

判定树的好处是：业务人员自己能判，不用每次都找安全团队。这直接决定了这套规则能不能规模化。

常见字段的默认映射表，可以直接当初始字典用（实际项目里按行业微调）：

注意"聚合升级"这一条：单条订单金额是 1 级，但整表订单金额加上成本字段，就是定价策略，属于 2 级甚至 3 级。所以分级不能只看字段，还要看字段组合。实操里通常给"表级级别"和"字段级级别"各定一个，取高者生效。

五、自动识别：三层手段，别指望一步到位

靠人工填 800 行表一定能填错。识别要做自动化，分三层，成本和准确率递增：

第一层：字段名规则匹配。命中率最高、成本最低。用正则匹配字段名和注释，覆盖 80% 的结构化数据。

第二层：数据内容采样识别。字段名叫f1、col2这种没法判断，就采样数据看格式。身份证、手机号、银行卡都有强格式特征。

第三层：模型/NER 识别。用于非结构化文本（合同、工单、客服记录），成本最高，通常只对高风险业务域做。

前两层用一段脚本就能跑，下面这个直接可用：

# -*- coding: utf-8 -*- """字段级敏感数据识别：先按字段名/注释匹配，再对未命中的字段做内容采样。""" import re # 字段名/注释规则：顺序即优先级，先命中先返回 NAME_RULES = [ (4, r"(secret|private_key|access_key|password|passwd|pwd|token)"), (3, r"(biometric|face|fingerprint|iris|dna|diagnosis|medical|health|track|gps)"), (2, r"(id_card|idcard|identity|mobile|phone|tel|bank_card|card_no|email|address|passport)"), ] # 内容格式规则 CONTENT_RULES = [ (2, "id_card", r"^[1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$"), (2, "bank_card", r"^\d{16,19}$"), (2, "mobile", r"^1[3-9]\d{9}$"), ] def by_name(name, comment=""): text = ("%s %s" % (name, comment or "")).lower() for level, pat in NAME_RULES: if re.search(pat, text): return level, "name-rule:%s" % pat[:18] return None, "" def by_content(samples): """samples: 采样到的字符串列表，命中率过半才认定。""" total = [s for s in samples if s] if not total: return None, "" for level, tag, pat in CONTENT_RULES: hit = sum(1 for s in total if re.match(pat, str(s).strip())) if hit / len(total) >= 0.6: return level, "content:%s(%d/%d)" % (tag, hit, len(total)) return None, "" def classify_field(name, comment, samples): lv, why = by_name(name, comment) if lv: return lv, why lv, why = by_content(samples) if lv: return lv, why return 1, "default" if __name__ == "__main__": demo = [ ("mobile", "手机号", ["13800138000", "13912345678"]), ("f7", "", ["110101199003074512", "310101198801011234"]), ("remark", "备注", ["客户要求周一送达"]), ] for n, c, s in demo: lv, why = classify_field(n, c, s) print("%-10s -> %d 级 (%s)" % (n, lv, why))

跑出来的效果是mobile -> 2 级 (name-rule)、f7 -> 2 级 (content:id_card)、remark -> 1 级 (default)。这套规则体系落地时有两件事必须做：规则表要版本化（每次调整留痕，否则级别漂移无法解释），识别结果要人工抽检（按 5% 比例抽，错误率超过 10% 就回去改规则）。

六、打标与审批：谁能改级别，多久复核一次

分级不是一次性动作，它会变。业务新增字段、上线新系统、数据出境、法规更新，都会触发重新判定。所以必须定义清楚"谁有权改"和"多久看一次"：

（A 负责、R 执行、C 咨询、I 知会）

三个实操建议：

• 级别只能升不能随意降。降级必须走审批并留书面理由，否则会出现"为了少做管控而调低级别"的逆向激励。
• 复核周期跟级别挂钩：3 级以上半年一次，2 级一年一次，1 级随系统变更触发。
• 打标要落到元数据里，不要另建一张 Excel。数据目录（比如 Hive Metastore、数据地图、业务系统的字段注释）是唯一真源，安全团队维护的是规则，不是表格。

七、管控要跟着级别走：一张对照表定生死

这一节是整篇文章最该打印出来贴墙上的部分。分级如果没落到这张表，前面五节全白做。

按这张表倒推技术动作，落地清单就很清楚了：数据库透明加密（TDE）、字段级加密、动态脱敏网关、静态脱敏用于测试环境、导出审批流、水印、审计日志、数据出境评估。每一项都能对应到具体产品和责任人。

一个容易漏的点：测试环境和备份。生产库做了脱敏，测试库直接 dump 了一份生产数据，等于所有管控归零。所以管控范围必须显式包含：测试环境、数据仓库、备份介质、日志系统、导出文件、第三方接口。日志里裸存身份证号和高频密码，是最常见的低级泄露点。

八、几个从项目里踩出来的坑

• 只做结构化数据。合同 PDF、客服录音、工单附件里全是个人信息，这些不盘，等于只做了三分之一。
• 把个人信息保护合规和分类分级做成两个项目。两者共用同一套资产清单和判定规则，分开做等于干两遍活，还会互相打架。
• 分级不落到接口。数据库管得再严，一个没鉴权的查询接口就能全量拉走。接口层的字段级权限要和分级对齐。
• 没有度量。项目验收时说不清"做完了没有"。建议定三个指标：核心系统字段打标覆盖率、2 级以上字段管控措施覆盖率、导出审批执行率。
• 忽视"数据出域"这一刻。数据在域内是可控的，一旦出了系统边界（导出、共享、上云、给第三方），控制力骤降。所有高风险场景都发生在出域那一刻。

九、分三期落地：一个可交付的节奏表

一个中型企业把上面这套跑完，实际是 3~4 个月，分三期，每期都有明确的可验收产出：

一期最容易拖，因为要开会拉齐口径。有个加速办法：先拿一套系统做样板，用两三天把它的字段全部打标并给出管控方案，拿着实物去开会，比拿方案去争论快十倍。业务看到"我这套系统的身份证字段确实被标成 2 级、确实加了脱敏"，讨论就从"要不要做"变成"下一个做哪个"。

三期结束后不要宣布"项目结束"，宣布"进入运营"。分类分级没有终点，只有复核周期。

十、写在最后

分类分级的本质，是给数据打上"该被怎么对待"的标签，然后让系统按标签自动执行。它的成功标准不是文档通过评审，而是：一个新上线的字段，能在一天内被自动识别、定级、套上管控、进入审计。

按这个标准倒推，项目该先做什么就很清楚了——先做规则和识别，再做表格和文档。顺序反过来，就是开头说的那种"60 页办法 + 零个打标字段"。

配套阅读：安全基线那套三层清单可以解决存储层和主机层的加固；等保2.0定级备案全流程里有数据完整性、保密性要求怎么对应到测评项的写法；数据一旦泄露，处置顺序看应急响应复盘。

你们做分类分级时，卡在"业务不认级别"这一步的多吗？我手上有一套把级别翻译成业务语言的沟通话术，评论区说下具体场景，我整理出来单发一篇。