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% 的记录包含手写身份证号,应追加为敏感字段。识别结果建议输出为:表名、字段名、敏感类型、匹配规则、采样命中率、置信度、确认人、确认时间。置信度低于阈值的字段必须进入人工复核队列,不能直接进入脱敏流程。
合规要求映射:把外部规则落到字段
合规映射的关键是“可追溯”:每一条合规要求都要能对应到具体的数据对象、迁移动作和控制措施。以《个人信息保护法》为例,处理敏感个人信息需取得单独同意,迁移前应确认源库中该字段的授权状态;《数据安全法》要求重要数据出境需做安全评估,若迁移目标在境外,必须提前识别是否触发评估条件。行业监管如金融行业的客户身份资料保存期限、医疗行业的病历数据留存要求,也会直接影响迁移后的存储位置和保留策略。
映射结果建议形成一张“合规约束表”,字段包括:合规来源、条款摘要、适用数据对象、约束类型(禁止出境/需脱敏/需审批/需留存)、迁移动作限制、验证方式。例如“个保法第 28 条—敏感个人信息—t_user.id_card—需单独同意—迁移前校验授权记录—抽样核对授权表”。这样在迁移执行阶段,每一条约束都能被检查,而不是停留在原则层面。
迁移风险清单编制:把评估结论变成行动
风险清单不是资产清单的复制,而是对“可能出问题的地方”做结构化描述。建议每条风险包含:风险编号、风险描述、影响对象、触发条件、可能性(高/中/低)、影响程度(高/中/低)、风险等级、缓解措施、责任人、验证方式。风险等级可由可能性与影响程度交叉判定,例如“核心表未脱敏直接迁移”可能性中、影响程度高,定为高风险;“日志表含少量手机号”可能性低、影响程度中,定为中风险。
以下是一份可直接参考的风险清单示例(数据为教学假设):
| 编号 | 风险描述 | 影响对象 | 可能性 | 影响程度 | 等级 | 缓解措施 |
|---|---|---|---|---|---|---|
| R-01 | 核心表未脱敏迁移 | t_user.id_card | 中 | 高 | 高 | 字段级加密 + 迁移窗口审批 |
| R-02 | 外键依赖断裂 | order_db 与 user_db | 高 | 中 | 高 | 同批次迁移 + 一致性校验 |
| R-03 | 跨境迁移未评估 | pay_db 全库 | 低 | 高 | 中 | 目标地域确认 + 安全评估 |
| R-04 | 账号权限未回收 | 源库 37 个账号 | 中 | 中 | 中 | 迁移后权限复核与回收 |
完成上述五步后,迁移团队应能回答:迁移哪些对象、哪些字段必须脱敏或加密、哪些数据不能出境、哪些操作需要审批、每条风险的负责人和验证方式是什么。这份评估结果将直接作为迁移方案设计、脱敏工具选型和验收测试用例的输入。评估不是一次性动作,在迁移窗口前应做一次复核,确认源库对象、敏感字段和合规要求没有发生变更。