敏感数据加密存储的基本做法

拖库这种事，防住是运气，防不住是概率。真正决定损失大小的是数据落库前的那道加工：密码怎么哈希，证件号怎么加密，密钥放在哪。三步做扎实，库被拖走也只是拿到一堆算不动的密文。 一、密码只存哈希，还要加盐 密码验证类数据用单向哈希存储，即使拿到库也还原不出原文。裸 MD5 早就不顶用，彩虹表几分钟就能反查常见组合。现在的做法是 bcrypt、scrypt 或 argon2 这类专为密码设计的慢哈希：自带盐值，成本因子可以调到单次计算几十毫秒。以 Python 的 bcrypt 库为例，hashpw 传入 cost 12 加密，checkpw 验证，两行代码完成。判断标准很朴素：单台机器一秒能算几十万次的方案，都不适合存密码。 二、可还原的数据用对称加密 身份证号、银行卡号这类业务上要读原文的字段，用对称加密，推荐 AES-256-GCM——它除加密外还带完整性校验，密文被改过一个字节解密就会失败，能防篡改。openssl 命令行可以快速验证算法行为，生产环境则在应用层调用成熟的加密库，不要自己拼算法细节。存之前想清楚一个问题：这个字段真的需要还原原文吗？能只存哈希或掩码的，就不要存全量明文。 三、密钥保管比加密本身更要紧 密钥和数据放同一个库、同一台机器，等于锁和钥匙挂在同一颗钉子上。基本要求三条：密钥独立存放，走环境变量或独立的密钥管理服务，绝不进代码仓库；按版本轮换，旧密钥只解密不加密，新数据一律用新版本；密钥的操作权限单独设账号设人，与数据库管理员分权。密文泄露还有补救余地，密钥和密文一起丢才是真丢。 加密存储没有高深的部分，难的是每张表都执行到位。先盘点一遍库里到底存了什么，按上面三步逐表处理，比事后解释为什么是明文体面得多。