2. 迁移前安全评估

迁移前安全评估的目标,是在任何数据真正离开源库之前,先把“有什么、值多少、受什么约束、会怎么出事”这四件事说清楚。它不是一个单纯的扫描动作,而是一条从资产发现到风险定级的证据链:源库资产梳理回答“迁移对象边界”,数据分类分级回答“数据的重要程度”,敏感数据识别回答“哪些字段触碰了敏感定义”,合规要求映射回答“这些数据受哪些外部规则约束”,迁移风险清单则把前四步的结论收敛成可执行的风险条目。缺少任何一环,后续的迁移方案、脱敏策略和验收标准都会失去依据。

源库资产梳理:先确定迁移边界

资产梳理不是简单列出数据库实例,而是要把实例、库、模式、表、字段、账号、依赖对象和外部调用关系一起纳入。实践中建议从三个维度采集:实例层(数据库类型、版本、部署形态、字符集、时区、归档与备份策略)、对象层(库/模式/表/视图/存储过程/触发器/序列/作业)、访问层(账号、角色、权限、连接来源、应用归属)。

以某电商订单库为例,源端为 MySQL 8.0 单实例,包含 order_db、user_db、pay_db 三个库,共 412 张表、37 个存储过程、9 个定时事件。梳理时不能只看表名,还要记录对象间的依赖:order_db.t_order 通过外键关联 user_db.t_user,pay_db.t_payment 又通过应用层逻辑引用订单号。若只迁移 order_db,外键与业务一致性都会断裂。因此资产清单至少要包含:对象唯一标识、类型、所属应用、负责人、数据量级、是否含外键/触发器、是否被外部系统直接访问、迁移优先级。

资产梳理的完成标准不是“表数量对上了”,而是“每个对象都能回答:谁在用、迁移后谁继续用、不迁移会怎样”。

数据分类分级:给数据定“重量”

分类解决“是什么类型”,分级解决“有多重要”。分类可按业务域划分,如用户身份、交易支付、商品运营、日志行为;分级则依据泄露、篡改、丢失后的影响程度,通常分为公开、内部、敏感、核心四级。分级不能只凭字段名,要结合业务语义和组合关系。例如 user_db.t_user 中的 phone 单独看是敏感,若与 id_card、bank_card 同表且可关联,则整表应提升为核心级。

一个可操作的判定方法是“三问”:第一,数据是否可直接或间接识别自然人?第二,数据是否影响资金、交易或结算?第三,数据泄露是否触发监管报告或合同违约?三问中任一为“是”,至少定为敏感;第二、第三同时为“是”,定为核心。分级结果要落到表级和字段级,并标注分级依据,便于后续审计追溯。

敏感数据识别:从规则到验证

敏感数据识别通常采用“规则匹配 + 采样验证 + 人工确认”三步。规则匹配覆盖字段名、注释、数据类型和取值模式;采样验证用于降低误报和漏报;人工确认由数据 owner 对边界字段做最终判定。常见敏感类型包括身份证号、手机号、银行卡号、邮箱、地址、生物特征、健康信息、账号口令与密钥。

以 t_user 表为例,字段 mobile 命中手机号正则,采样 1000 行后发现 98.7% 符合 11 位手机号格式,判定为敏感;字段 remark 虽未命中规则,但采样发现其中 12% 的记录包含手写身份证号,应追加为敏感字段。识别结果建议输出为:表名、字段名、敏感类型、匹配规则、采样命中率、置信度、确认人、确认时间。置信度低于阈值的字段必须进入人工复核队列,不能直接进入脱敏流程。

迁移前安全评估:从源库资产到风险清单的证据链 源库资产梳理 实例 / 库 / 模式 / 表 账号 / 权限 / 依赖对象 外部调用与负责人 输出:资产清单 数据分类分级 业务域分类 公开 / 内部 / 敏感 / 核心 三问判定法 输出:分级结果 敏感数据识别 规则匹配 + 采样验证 身份证 / 手机 / 银行卡 置信度与人工复核 输出:敏感字段清单 合规要求映射 个保法 / 数安法 行业监管 / 合同 跨境与留存要求 输出:合规约束表 迁移风险清单编制 风险项 · 影响对象 · 可能性 · 影响程度 · 风险等级 · 缓解措施 · 责任人 示例:核心表未脱敏迁移 → 高 → 字段级加密 + 迁移窗口审批 示例:t_user 表敏感识别与分级结果 字段 敏感类型 匹配规则 采样命中率 分级 处置建议 mobile 手机号 11位数字正则 98.7% 敏感 掩码脱敏 id_card 身份证号 18位校验位 99.2% 核心 加密 + 审批

合规要求映射:把外部规则落到字段

合规映射的关键是“可追溯”:每一条合规要求都要能对应到具体的数据对象、迁移动作和控制措施。以《个人信息保护法》为例,处理敏感个人信息需取得单独同意,迁移前应确认源库中该字段的授权状态;《数据安全法》要求重要数据出境需做安全评估,若迁移目标在境外,必须提前识别是否触发评估条件。行业监管如金融行业的客户身份资料保存期限、医疗行业的病历数据留存要求,也会直接影响迁移后的存储位置和保留策略。

映射结果建议形成一张“合规约束表”,字段包括:合规来源、条款摘要、适用数据对象、约束类型(禁止出境/需脱敏/需审批/需留存)、迁移动作限制、验证方式。例如“个保法第 28 条—敏感个人信息—t_user.id_card—需单独同意—迁移前校验授权记录—抽样核对授权表”。这样在迁移执行阶段,每一条约束都能被检查,而不是停留在原则层面。

迁移风险清单编制:把评估结论变成行动

风险清单不是资产清单的复制,而是对“可能出问题的地方”做结构化描述。建议每条风险包含:风险编号、风险描述、影响对象、触发条件、可能性(高/中/低)、影响程度(高/中/低)、风险等级、缓解措施、责任人、验证方式。风险等级可由可能性与影响程度交叉判定,例如“核心表未脱敏直接迁移”可能性中、影响程度高,定为高风险;“日志表含少量手机号”可能性低、影响程度中,定为中风险。

以下是一份可直接参考的风险清单示例(数据为教学假设):

编号 风险描述 影响对象 可能性 影响程度 等级 缓解措施
R-01 核心表未脱敏迁移 t_user.id_card 中 高 高 字段级加密 + 迁移窗口审批
R-02 外键依赖断裂 order_db 与 user_db 高 中 高 同批次迁移 + 一致性校验
R-03 跨境迁移未评估 pay_db 全库 低 高 中 目标地域确认 + 安全评估
R-04 账号权限未回收 源库 37 个账号 中 中 中 迁移后权限复核与回收
风险清单必须在迁移启动前完成评审并冻结基线;迁移过程中若发现新风险,应走变更流程追加,而不是口头处理。

完成上述五步后,迁移团队应能回答:迁移哪些对象、哪些字段必须脱敏或加密、哪些数据不能出境、哪些操作需要审批、每条风险的负责人和验证方式是什么。这份评估结果将直接作为迁移方案设计、脱敏工具选型和验收测试用例的输入。评估不是一次性动作,在迁移窗口前应做一次复核,确认源库对象、敏感字段和合规要求没有发生变更。