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 总结
小王心想，全密态数据库的主要特点有：
- 在传统的密码、账户体系之上，将查看明文的权限用密钥和规则体系进一步细分，其中：
- 密钥安全可以由阿里云KMS或者是用户信赖的其他密钥服务提供。
- 规则权限可以由阿里云RAM体系控制。
- 企业不再需要担心由数据库管理引起的数据泄露问题，不再需要提防DBA、产研人员。
- 对数据库原本的数据处理能力没有任何限制。
- 支持所有原有的SQL。
- 业务侧几乎0改造接入。
他不禁感叹，全密态数据库或许就是解决企业数据安全问题的金钥匙。
