数据库里那些关键字段到底怎么加密才靠谱，敏感信息保护方法聊一聊

说到数据库里那些关键字段的加密，比如用户的身份证号、手机号、银行卡号这些，可不能随便找个方法就往上套，用对了方法，即使数据库被拖库，黑客拿到手的也是一堆乱码，能有效保护用户数据，用错了方法，那加密可能就是形同虚设，今天我们就来聊几种靠谱的思路,尽量不用那些让人头疼的专业术语。

最直接了当的方法，就是整个数据库加密，你可以把它想象成一个保险箱，你有一整个房间的数据，但你把整个房间（也就是整个数据库文件）都锁进了一个大保险箱里，不开保险箱，谁也看不到里面的东西，这种方法通常在数据库系统层面或者操作系统层面实现（比如MySQL的透明数据加密TDE），它的好处是省心，你不用去操心具体哪个字段要加密，数据库自己会在把数据写入硬盘时加密，在读取时解密，对应用程序来说几乎是“透明”的，感觉不到加密的存在，但它的缺点是，如果黑客有能力直接登录到你的数据库服务器上，并且有权限访问数据库，那么数据在内存中时是明文的，他依然能看到所有信息，这就好比保险箱的门是开的，虽然东西从外面拿不走，但进来的人可以随便看，全盘加密主要防的是硬盘丢失或者被盗这种物理窃取的情况，对于来自网络的应用层攻击，防护力相对较弱。（参考来源：常见数据库安全实践指南）

既然全盘加密有短板，我们就得在更细的层面下功夫，也就是对关键字段单独加密，这就好比你不光把房间锁了，还把房间里最贵重的物品单独放进了一个小保险柜,这里面的门道就多了。

第一种常用的方法是可逆加密，也就是加密了还能解密回来，比如AES加密算法，这是目前公认非常安全的一种加密方式，你用一把密钥把用户的身份证号加密成一串乱码存进数据库，当你的应用程序需要显示或者使用这个身份证号时，再用同一把密钥解密回来，这种方法的安全性，几乎完全取决于密钥的管理，密钥放在哪里成了最关键的问题，你把密钥写在应用程序的代码里，或者放在和数据库同一台服务器上，那就相当于把保险箱的钥匙挂在保险箱旁边，非常危险，比较推荐的做法是使用专门的密钥管理服务（KMS），把密钥放在一个高度安全、隔离的系统里，应用程序每次需要加解密时，都要向KMS申请，并且有严格的权限控制和操作日志，这样即使数据库被攻破，黑客拿不到密钥，那堆乱码对他来说就毫无意义。（参考来源：OWASP密码存储备忘单）

但有时候，我们的业务并不需要知道明文信息，比如我们只想验证用户输入的密码是否正确，或者想对加密后的数据进行模糊查询（比如根据手机号前三位找用户），这时候可逆加密就显得有点笨重了，于是就有了第二种强大的方法：不可逆加密，也叫哈希（Hash），最典型的应用就是密码存储，靠谱的系统绝对不会用明文存密码，而是存密码的哈希值，哈希的特点是，同一串明文每次都会生成相同的、固定长度的乱码（哈希值），但这个过程是单向的，你几乎无法从哈希值反推出明文，验证密码时，系统只需把用户输入的密码用同样的算法计算一次哈希值，然后和数据库里存的哈希值对比，一样就说明密码正确，但单纯的哈希也不安全，因为黑客可以预先计算好大量常见密码的哈希值，做成一个“彩虹表”，然后直接查表破解，为了解决这个问题，必须“加盐”，所谓“盐”（Salt），就是一串随机的字符，在存储密码时，系统为每个用户生成一个独一无二的随机盐值，然后把这个盐值和密码拼接在一起，再计算哈希值，最后把哈希值和盐值一起存进数据库，这样，即使两个用户密码相同，因为盐值不同，最终的哈希值也完全不同，黑客必须为每个用户单独制作彩虹表，破解成本变得极高，从而大大提升了安全性。（参考来源：广泛接受的密码学最佳实践）

还有一种更巧妙的需求，比如我们想对加密的手机号进行模糊查询，比如查找所有以“138”开头的号码，用AES加密后，明文稍微一变，密文就会完全不同，根本无法实现模糊查询，这时候可以考虑一种叫“保留格式加密”（FPE）的技术，它加密后的密文看起来还是像手机号（比如还是11位数字），但本身是加密过的，这样你可以在数据库层面进行一些有限的模糊匹配，不过这种技术相对复杂,需要谨慎评估和使用。

最后总结一下，没有一种加密方法是万能的,你需要根据字段的敏感程度和业务使用场景来选择合适的策略：

• 核心机密，无需明文使用（如密码）：首选加盐哈希,坚决不用可逆加密。
• 高度敏感，需还原使用（如身份证、银行卡号）：使用强加密算法如AES，并配合安全的密钥管理服务（KMS）。
• 一般敏感，需部分匹配：可考虑保留格式加密或权衡后采用部分字段单独哈希等折中方案。
• 整体防护：在上述基础上，可以再启用数据库全盘加密,作为防御物理窃取的最后一道防线。

最关键的是，加密只是整个安全链条中的一环，严格的身份认证、精细的权限控制、及时的漏洞修补、安全的代码实践，这些环节任何一个出问题，再强的加密也可能白费功夫，保护敏感信息，需要一个立体的、纵深的安全体系。