普法律己
法治论坛

数据库结构优化:表结构里那些没写进需求文档的坑

上周三夜里十一点多,一个做后端的老同学给我发微信。就一句话:“我把手机号字段加密了,模糊查询全废,老板让我明天回滚。”

我说,那你今晚别睡了。

这事儿有意思的地方在于:他做的是技术优化,撞上的却是合规义务。这两样东西经常打架,而且打起来的时候,往往是技术先低头。可问题是,你回滚了,字段还是明文躺在那儿。哪天库被拖了,你回滚的不是代码,是责任。

表结构里藏的,不只是性能

大多数团队设计表的时候,脑子里想的是查询快不快、索引够不够、字段能不能再少一个。没人会想“这个字段将来会不会出现在法庭的证物清单上”。

但它会。

举个特别常见的例子。用户点“注销账号”,你后台执行的是 update user set is_deleted = 1。从代码角度看,这用户消失了。可《个人信息保护法》第四十七条讲的“删除”,指的是处理目的已实现、无法实现,或者为实现处理目的不再必要,处理者应当主动删除。置一个标志位,严格讲不叫删除。

当然,实践中真去物理 delete 的公司没几个,因为要留订单、留对账、留反洗钱记录。监管和法院看的通常是另一件事:这条数据还“能不能用”。能不能被检索到,能不能关联到具体的人,有没有做去标识化。

所以现在比较稳的做法是——主键留着做关联,敏感字段抽到单独的表,置空或者假名化。原始值最多在一个有权限、有审计、有留存期限的地方躺一阵,然后真删。

用户注销后敏感个人信息字段假名化数据库表结构设计
用户注销后敏感个人信息字段假名化数据库表结构设计

这套东西听起来像合规部门拍脑袋想出来的,其实反过来救了无数技术团队。因为一旦出事,你能不能证明“该做的都做了”,靠的就是表结构这一层。表里没留痕迹,嘴上说破天也没用。

那几个字段,写错一次就够呛

那几个字段,写错一次就够呛
那几个字段,写错一次就够呛

哪些字段算高危?先说法定的。《个人信息保护法》第二十八条列的那一串:生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹,还有不满十四周岁未成年人的个人信息。这一类,第五十一条直接点名,要求采取加密、去标识化等安全技术措施。

还有一类不在那个名单上,但一样要命。手机号、身份证号、家庭住址、设备号。它们属于一般个人信息,可一旦泄露,骚扰电话和精准诈骗就是从这里长出来的。丢这些,照样要跟监管部门解释。

怎么落?经验值:敏感字段不要跟业务主表挤在一起。单独一张表,加密列,密钥别跟数据放同一个库、同一台机器、同一个账号。

密钥这事儿,很多公司是挂在一台跳板机的配置文件里的。啧。这等于把家门钥匙插在门锁上,还贴了张条:钥匙不带走。

还有一类字段,平时没人看,出事时人人抢着要——审计字段。谁创建的,谁改的,什么时候改的,改之前长什么样。《网络安全法》第二十一条要求采取监测、记录网络运行状态的技术措施,留存相关的网络日志不少于六个月。

六个月是底线,不是标准答案。真出了安全事件,你要回溯的是半年前那条异常 SQL,日志表里却只有 updated_at,没有操作人,也没有变更前的值。那你这库,等于没有记忆。

顺带一句,审计日志表本身别做成能随手改的。只追加、哈希校验、权限隔离,这几样在真有争议的时候很值钱。

那些没人愿意写的“时间字段”

那些没人愿意写的“时间字段”
那些没人愿意写的“时间字段”

留多久?

《个人信息保护法》第十九条的意思是,保存期限应当是为实现处理目的所必要的最短时间。听起来很虚,落到表结构上就一句话:你得有个字段记着这条数据什么时候该走。

retention_expire_at,或者叫别的名字,随便。关键是有定时任务真的去执行,而不是写份文档说“我们一般留两年”。文档不算数,数据库才算数。

备份怎么办?这是我最常被问到的问题之一。备份里的数据,算不算“已删除”?我的回答通常是:你得能说清楚备份的轮转周期,并且确实按周期覆盖掉。全量备三年、从来不清的,那叫数据仓库,不叫备份。

还有个特别容易漏的。《个人信息保护法》第五十六条,个人信息保护影响评估报告和处理情况记录,至少保存三年。数据删干净了,评估报告还得留着。很多团队评估做完就往共享盘里一扔,三年后问起来,找不到人,也找不到文件。这算不算已保存,就得看你怎么解释了。

真到了法庭上,看的是这几点

真到了法庭上,看的是这几点
真到了法庭上,看的是这几点

电子数据在民事诉讼里是法定的证据种类。最高法关于民事诉讼证据的若干规定里,审查电子数据真实性,会看生成和存储所依赖的系统是不是可靠、保存和提取的过程是不是完整、有没有被篡改的痕迹。

翻译成人话:你的表,能不能对得上时间。有没有哈希,有没有时间戳,导出来是不是可校验的。

我见过太多公司,技术上确实清白,证据上却站不住。原因往往琐碎得让人无语——字段命名混乱,时区不统一,日志只留三十天,导出脚本还把 ID 对错了。

能落到手上的动作,其实不多,就这么几件:

一是把敏感字段列一张清单,标清楚类型、位置、加密方式、责任人。二是给每张表的留存期限找到依据,落成字段和定时任务。三是改结构时留迁移脚本和评审记录,别在测试库上手动改完就完事。四是审计日志只追加、可校验、权限收紧。五是密钥单独管,别跟数据睡一张床。

做到这些,你的优化才不只是“跑得快”。

回到开头那位老同学。他第二天没回滚,改成了加密列加哈希索引,前面套一层脱敏查询。慢了一点点。老板骂了两句。三个月后他们做等保测评,这一项直接过。

有时候就是这样。你多写的那个字段、多留的那张表,当时看着碍事,后来是它替你说话的。

本文为普法参考,不构成个案法律意见。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:数据库结构优化:表结构里那些没写进需求文档的坑
文章链接:https://www.zhoupulvshi.com/hunyin/5287.html