转自:程序通事 作者:楼下小黑哥 出于安全考虑,惊呆解决加解现需要将数据库的不改中敏感信息加密存储到数据库中,但是行J信息正常业务交互还是需要使用明文数据,所以查询返回我们还需要经过相应的码竟敏感密原解密才能返回给调用方。 ps:日常开发中,轻松我们要有一定的惊呆解决加解安全意识,对于密码,不改金融数据等敏感信息进行加密存储保护。行J信息 这个需求说起来不是码竟敏感密原很难,我们只需要在执行 sql 之前,轻松提前将指定数据进行加密。惊呆解决加解执行 sql 之后,不改获取返回结果,行J信息再进行的码竟敏感密原相应的解密。稍微改造下原有代码,轻松很快完成需求。 现有加密算法如 RSA2 ,AES 等,密文长度将会是明文好几倍。上线加解密方案一定要评估数据库现有字段长度是否满足加密之后长度。 如果这是一张新建的表,上面的亿华云计算实现方案并没有什么问题。但是这次我们改造是几张已有已有「千万级」的存量的数据的表,这些数据都未被加密存储。 如果使用上述代码,使用加密之后的密文信息查询历史数据,当然查询不到任何结果。另外当查询返回的结果是明文,解密明文数据库也可能会导致相应的解密错误。 所以为了兼容历史数据,需要进行如下改造: 代码改造如下: 上述代码虽然解决业务需求,但是这个解决方案不是很优雅,业务代码改动较大,加解密的代码不能通用,所有涉及到相关字段的源码下载方法都需要改动,且几乎都是重复代码,代码侵入性很强,不是很友好。 有经验的同学可能会想到使用 Spring AOP 解决上述问题。 在切面的前置方法「beforeMethod」统一拦截查询参数,配合自定义的注解,加密指定的字段。 然后在切面的后置方法「afterReturn」拦截返回值,配合自定义注解,解密指定的字段。 Spring AOP 代码实现比较复杂,这里就不贴出具体的代码。 但是 Spring AOP 方案也并不通用,如果其他的应用也有相同的需求,同样的代码,又需要重复实现,还是很费时费力。 最终我们参考一个 github 开源项目「typehandlers-encrypt」,源码库借助 mybatis 的 「TypeHandler」,实现通用的数据加解密解决方案。使用方只需要引入相关依赖,「无需改动一行业务代码」,仅需少量配置即可实现指定字段加解密操作,省时省力。 「typehandlers-encrypt」github 地址:https://github.com/drtrang/typehandlers-encrypt mybatis 利用内置类型转换器(「typeHandler」),实现 Java 类型与 JDBC 类型的相互转换,我们正好可以利用这个特性,在转换之前加入加解密步骤。 typeHandler 底层原理不是复杂,如果我们没有使用 Mybatis,而是直接使用最原始的 JDBC 执行查询语句,相关代码如下: 我们需要手动判断 Java 类型,然后调用 PreparedStatement设置合适类型参数。获取返回结果之后,又需要手动调用 ResultSet 结果集获取相应类型的数据,这个过程十分繁琐。 使用 mybatis 之后,上述步骤就无需我们再实现了。mybatis 可以通过识别 Java/JDBC 类型,调用相应typeHandler,自动实现转换逻辑。 下图为 mybatis 内置类型转换器,基本涵盖了所有 「Java/JDBC」数据类型。 下面我们来实现带有加解密功能的类型转换器,实现方式也比较简单,只要继承 org.apache.ibatis.type.BaseTypeHandler,重写相关方法。 简单起见,上述加解密仅使用了 Base64,大家可以替换成相应加解密算法即或者引入相应加解密服务。 其中加密转换将在 setNonNullParameter 中执行,解密转换将在 getNullableResult中执行。 CryptTypeHandler 使用一个 MappedTypes 注解,包含一个 CryptType 类,这个类使用 mybatis 别名功能,可以极大简化 sqlmap 相关配置。 使用方必须将 typeHandler 和 alias 注册到 mybatis 中,否则无法生效。 下面提供三种方式,可以根据项目情况选择其中一种即可: 「单独使用 mybatis」 这种场景需要在 「mybatis-config.xml」配置,mybatis 启动时将会加载该配置文件。 「使用 Spring 配置 Mybatis Bean」 配合 Spring 使用时需要将 typeHandler 注入 SqlSessionFactoryBean ,配置方式如下: 「SpringBoot」 SpringBoot 方式就最简单了,只要引入 mybatis-starter,配置文件加入如下配置即可: ## mybatis 配置 # 类型转换器包路径 mybatis.type-handlers-package=com.xx.xx.x mybatis.type-aliases-package=com.xx.xx 最后我们只要简单修改 mapper 中 resultMap 或 sql s配置就可以实现加解密。 假设我们对现有一张 「bank_card」表进行加解密,表结构如下: bank_card ( auto_increment, , , , , , ); 「insert 加密」 现需要对 card_no,phone,name,id_no 进行加密,「insert」语句加密示例: INSERT INTO bank_card (card_no, phone,name,id_no) VALUES (#{ card_no,javaType=crypt}, #{ phone,typeHandler=org.demo.type.CryptTypeHandler}, #{ name,javaType=crypt}, #{ id_no,javaType=crypt}) 我们只需要在 「#{ }」指定 typeHandler,传入参数最后将被加密。使用 typeHandler需要使用类的全路径,比较繁琐,我们可以使用 「javaType」属性,直接使用上面我们的定义别名 「crypt」。 数据库最终执行sql 如下: ); ps:推荐一款 IDEA 的插件 「mybatis-log-plugin」,可以自动将 mybatis sql 日志还原成真实执行 sql 「查询加解密」 普通查询解密示例如下: select * from bank_card where id=#{ id} 这里我们在 「select」配置中只能使用 resultMap 属性,指定 typeHandler 。 数据库明文、密文共存的情况,查询解密示例如下: select * from bank_card where phone in(#{ card_no,javaType=crypt},#{ card_no}) 最后我们可以将自定义的 typeHandler 单独打包发布,其他业务方只需要引用,改造相关配置文件,即可完成数据加解密。 上述代码示例已上传至 Github,地址:https://github.com/9526xu/mybatis-encrypt 借助于自定义的 typeHandler,我们实现了一个通用的加解密的方案,该方案对于使用方来说代码侵入性小,开箱即用,可以快速完成加解密的改造。 ps:你们是否也有遇到同样的需求,可以在下方留言写下你们的方案,互相学习,一起成长! 最后感谢一下**@辉哥**提供解决思路。前言
❝
实现原理
通用解决方案
自定义 typeHandler
注册 typeHandler
修改 mapper sql 配置
总结
Reference
https://github.com/9526xu/mybatis-encrypthttps://github.com/drtrang/typehandlers-encrypt