如何仅用3行代码，搞定业务敏感数据加解密？

01 引子：一个数据安全的故事

一个风和日丽的早上，某家快递物流公司内。

张老板看着电脑屏幕，眉头紧锁。电脑屏幕上赫然写着，“疑似45亿条个人信息泄露，电商物流行业数据安全警铃再响”。据传，45 亿条物流行业的数据遭到泄露，Telegram 上已经出现了付费个人隐私数据查询链接，黑灰产大行其道。一夜之间，网络舆论甚嚣尘上，各大快递公司股价闪崩，其中，某物流行业头部公司股价跌幅达到 7%。

张老板一边庆幸着这次事件和自己公司无关，一面又落下了冷汗。万一这样子的事件发生在自己公司，损失不堪设想，甚至自己可能会面临被用户、监管机构、国家法律追责的风险。想到这里，他赶紧喊来了技术负责人小王。

张老板啪的一下把这条新闻甩到小王面前。“小王，为什么这些公司会出现数据泄漏问题？”

小王定睛一看，哦，数据泄露。他赶忙解释：“数据泄露有几个常见的出口，比如说公司业务系统有查询接口，遭到黑客的恶意爬虫攻击。这个您不用担心，我们的网站有丰富的反爬措施。”

老板冷哼一声。“还有呢？我经常听说别的公司被什么，脱裤子？然后丢了数据，这是怎么回事？”

小王继续解释。“咱们的数据都是存在数据库里的。拖库，就是数据库因为账号密码泄漏等问题，导致数据库内存储的数据直接被人拖走。”

老板瞪大了眼睛。“哦？那数据库的账号密码为什么会泄漏？我们会不会有这个情况？”

小王想了想，开始流汗。“额......正常情况下咱们是不会有这个问题的。账号密码只有少量的人持有，比如咱们 DBA、研发。咱们的数据库也有网络隔离机制，只有在内网环境里可以访问数据库。”

老板点点头，但又摇摇头。“这么说，只要咱们的 DBA、研发想干坏事，随时可以从库里拖走我们的数据？”

小王的汗越流越多。“额......理论上确实是这样的。”

老板勃然大怒，一拍桌子。“胡闹！我们的数据库安全，怎么能依靠员工的自觉性！几十亿的数据安全，就掌握在员工手里，绝对不行！限你三天时间，给我整改这个问题！就算账号密码泄漏，也不可以让数据裸奔！”

小王叫苦不迭。“这个问题是普遍存在的安全问题，咱们的业务系统完全没办法三天完成改造......”

老板横眉冷对。“这事儿必须得做，安全问题刻不容缓。你要是做不了，技术负责人的位置就给别人吧！”

小王愁眉苦脸地离开了办公室。

小王回到工位，开始思考。DBA、研发是必然会拿到数据库账号密码的，他们登录数据库、访问数据这件事无法避免。要预防 DBA、开发者有意或无意泄露数据，必须确保数据到他们手上时看不到真实内容。那么说，或许直接对数据进行加密就是最好的手段。

如果要做到数据库内的数据都是密文的，那么就需要在客户端就对数据库进行加密，然后存入数据库。但是这样一来，数据库侧将无法再进行数据的计算操作（例如：模糊查询、排序）。即使是牺牲一定的安全性和易用性，采用具有安全隐患的确定性加密算法，数据库侧最多也只能提供受限的等值查询功能。并且，这样一来业务系统必然需要进行大量开发改造。自己现在用的业务框架 MyBatis-Spring 将无法直接使用，必须得想办法自己接入加解密的能力。

或许自己公司内部可以开发一套加解密的中间件支持业务。但是，盘算下来这样一套方案前后需要研发、系统集成、测试，各个系统再灰度上线。这样子一套方案走下来，工作量繁多，流程复杂，没有个一年半载恐怕难以完成。这和老板要求的三天完成改造，差距是够大的。

苦恼之中，小王找到了阿里云数据库团队。数据库团队专家在听完小王的困境后，微微一笑。“我们阿里云瑶池数据库的全密态能力，可以完美解决你说的这些问题。”

02 全密态数据库：让数据只落入正确的人手里

小王听到这话，大喜过望。

数据库专家继续介绍：“全密态能力指的是数据全生命周期以密态存在。数据一旦流出可信环境，就总是处于密文状态下的。只有当数据落入正确的人手里，例如数据到达咱们的业务系统客户侧，才会被解密。任何账号通过直连数据库的形式，都是无法读取数据明文的。”

小王问：“我们现在用的是阿里云的 PolarDB MySQL 产品。这个产品，支持全密态功能吗？”

数据库专家：“全密态能力在阿里云瑶池数据库旗下的云数据库 RDS MySQL 版、云数据库 RDS PostgreSQL 版、云原生数据库 PolarDB MySQL 版、云原生数据库 PolarDB PostgreSQL 版上都有。你们使用的 PolarDB MySQL，全密态能力可以看一看这里全密态PolarMySQL。”

小王问：“我们之前这边考虑过，如果加密数据再存入数据库的话，是会对数据库本身功能有影响的。你们这个方案，支持的 SQL 有什么限制呢？”

数据库专家：“完全没有限制！我们支持所有的 MySQL 语法。我们的秘诀是，数据库内部数据是以明文形式存在的，我们在输出结果时针对计算结果进行加密，MySQL 的引擎本身没有受到任何的影响，所以在稳定性上、性能上的影响也微乎其微。”

小王问：“那么什么叫做让数据落入正确的人手中呢？产研、运维人员是不是正确的人呢？”

数据库专家：“请看图。对于应用终端用户来说，他们是数据的真正所有者，可以看到明文或者是脱敏后的敏感数据。对于应用研发、运维人员以及数据库研发、运维人员来说，他们都只能看到加密后的数据，监守自盗的问题不复存在。”

数据库专家继续说：“并且，咱们的数据库通过用户自定义敏感规则的方式，来标记需要加密的数据。在业务侧，您可以根据自己的业务需求，将数据库内比较敏感的身份证号、地址、用户手机号等数据进行加密。同时，考虑到企业用户往往会给 DBA、产研人员一定的阿里云控制台权限，定义规则这个行为本身可以通过阿里云的RAM体系来约束。企业可以根据最小授信原则给 DBA、产研人员授权，避免他们恶意篡改规则，以明文形式导出数据。”

“您看，在配置加密规则之后，咱们直接用 MySQL 客户端连接数据库查询，看到的敏感数据全都是密文，而非敏感数据仍然是明文。”

小王感叹道：“厉害了，这么看来，安全性确实可以满足咱们的要求。但是这么安全的方案，业务侧要接入的话，改动一定不小吧？”

03 全密态数据库业务接入：三行代码改造！

数据库专家微微一笑，说出让小王震惊的话。“三行代码，就足以完成业务改造！请看下面这份全密态 MySQL Java 客户端的配置文档：EncJDBC。我们基于社区的标准 MySQL JDBC，开发了满足 Java JDBC 标准接口的客户端，可以做到无改造接入 Spring、druid、MyBatis 等业务框架。”

“在执行任意一条 SQL 时，我们都会在 JDBC 侧预先获取 ResultSet，解密后再返回给业务侧，数据加解密完全做到对业务应用透明。”

“使用客户端，需要提前在 maven 项目中引入如下依赖。”

<dependency>
  <groupId>com.aliyun</groupId>
  <artifactId>aliyun-encdb-mysql-jdbc</artifactId>
  <version>1.0.8</version>
</dependency>

“在改造一个 Spring 应用程序的时候，您只需要在配置文件里将原先设置的 MySQL Driver 改为我们的客户端（一行），将链接 url 从社区格式改成符合我们标准的格式（两行），最后再在配置文件中配置一个密钥就行啦（三行）！如果您觉得密钥管理是个令人头疼的问题，也可以使用阿里云 KMS 管理密钥，不过那样的话您就需要额外配置阿里云 AK、SK 等信息。

# 第一行需要改造的代码
# driver 原先配置
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
# driver 新配置
spring.datasource.driver-class-name=com.aliyun.encdb.mysql.jdbc.EncDriver

# 第二行需要改造的代码
# url 原先配置
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/xxx
# url 新配置
spring.datasource.url=jdbc:mysql:encdb://127.0.0.1:3306/xxx

# 第三行需要改造的代码
MEK=00112233445566778899aabbccddeeff

“即使您的业务系统不是 Java 语言，我们也支持GoLang、Python等语言，都可以做到三行代码完成改造。”

小王听完这些话，内心久久不能平静。令他头疼不已的问题就这么解决了。他深刻感受到，阿里云数据库的技术实力真是深不可测。

04 总结

小王心想，全密态数据库的主要特点有：

1. 在传统的密码、账户体系之上，将查看明文的权限用密钥和规则体系进一步细分，其中：

• 密钥安全可以由阿里云 KMS 或者是用户信赖的其他密钥服务提供。
• 规则权限可以由阿里云 RAM 体系控制。

1. 企业不再需要担心由数据库管理引起的数据泄露问题，不再需要提防 DBA、产研人员。
2. 对数据库原本的数据处理能力没有任何限制。
3. 支持所有原有的 SQL。
4. 业务侧几乎 0 改造接入。

他不禁感叹，全密态数据库或许就是解决企业数据安全问题的金钥匙。