购买了云服务器实例

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

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

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

疑似45亿条个人信息泄露，电商物流行业数据安全警铃再响_澎湃号·政务_澎湃新闻-The Paper

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

数据库专家：全密态能力在阿里云瑶池数据库旗下的云数据库RDS MySQL版、云数据库RDS PostgreSQL版、云原生数据库PolarDB MySQL版、云原生数据库PolarDB PostgreSQL版上都有。你们使用的PolarDB MySQL，全密态能力可以看一看这里全密态PolarMySQL_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心。

云服务器恢复登录界面

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

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

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

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

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

如何管理加密规则_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

如何使用RAM权限控制配置加密规则的行为_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心

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

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

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

数据库专家微微一笑，说出让小王震惊的话。三行代码，就足以完成业务改造！请看下面这份全密态MySQL Java客户端的配置文档：如何使用EncJDBC_云原生数据库 PolarDB(PolarDB)-阿里云帮助中心。我们基于社区的标准MySQL JDBC，开发了满足Java JDBC标准接口的客户端，可以做到无改造接入Spring、druid、MyBatis等业务框架。

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

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

<dependency><groupId>com.aliyun