如何仅用 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 项目中引入如下依赖。”
“在改造一个 Spring 应用程序的时候,您只需要在配置文件里将原先设置的 MySQL Driver 改为我们的客户端(一行),将链接 url 从社区格式改成符合我们标准的格式(两行),最后再在配置文件中配置一个密钥就行啦(三行)!如果您觉得密钥管理是个令人头疼的问题,也可以使用阿里云 KMS 管理密钥,不过那样的话您就需要额外配置阿里云 AK、SK 等信息。
“即使您的业务系统不是 Java 语言,我们也支持GoLang、Python等语言,都可以做到三行代码完成改造。”
小王听完这些话,内心久久不能平静。令他头疼不已的问题就这么解决了。他深刻感受到,阿里云数据库的技术实力真是深不可测。
04 总结
小王心想,全密态数据库的主要特点有:
在传统的密码、账户体系之上,将查看明文的权限用密钥和规则体系进一步细分,其中:
密钥安全可以由阿里云 KMS 或者是用户信赖的其他密钥服务提供。
规则权限可以由阿里云 RAM 体系控制。
企业不再需要担心由数据库管理引起的数据泄露问题,不再需要提防 DBA、产研人员。
对数据库原本的数据处理能力没有任何限制。
支持所有原有的 SQL。
业务侧几乎 0 改造接入。
他不禁感叹,全密态数据库或许就是解决企业数据安全问题的金钥匙。
评论