背景
随着公司业务发展,用户量越来越多,数据的安全性也会提升到一个公司级别的问题。
特别是公司上市前,都有专门的机构评估系统的安全级别,其中有一项就是专门针对数据安全性的评估。
我们公司是垂直领域的电子商务公司,用户近400w,系统内的订单数据超过1亿,如此多的数据,我们都要根据数据安全级别改造,对数据进行加密保存。
确认需要加密的字段
不允许反向解密的字段:用户登录密码、支付密码等
允许方向解密的字段:用户手机,姓名,身份证号,地址,银行卡信息等
方案介绍
1、传输过程中字段可以按统一规范使用通用的加密算法;
2、在系统通过mybatis保存数据的时候,通过拦截器重写字段后,再进行保存;
3、查询的时候mybatis返回也需要进行拦截,进行解密;
4、存量数据需要进行初始化,通过定时任务,对指定表,指定字段,指定范围进行加密;
方案计划
密钥申请
根据公司情况,如果有KMS或本地密钥需求,可以接入并从这些系统里面获取加密数据需要的密钥。
表结构调整
因为加密会使原有字段的长度变长,根据自己所使用的加密算法对各种类型的字段做加密并评估扩容大小。
加密方式 | 字段类型 | 字段示例 | 加密结果 |
本地AES | 手机号/11 | 18576667676 | {secret}xxxxxxx |
KMS-AES | 手机号/11 | 18576667676 | {secret}xxxxxxx3343 |
历史表
历史表,通常是明文保存,此时我们会新增一个加密字段,先保证加密字段数据正常加密后,验证功能,如果可用,再通知上下游开始切换使用新的加密字段。
搜索字段
在确定好加密字段后,需要确认上下游使用方,并要求对该字段的整改,特别是确认是否还要使用该字段进行搜索,是否需要模糊搜索等。(建议,上线前通过与业务交流,下线模糊搜索功能,因为实现起来繁琐,需要加映射表)
数据转换
对象字段加密
@SenstiveEntity 在实体类上添加该注解,标明该实体有待加解密的字段
@SenstiveField 在字段上添加该注解,标明该字段是需要进行加解密的字段
实现方案可以参考 ,后面我可以单独写一篇分析mybatis插件原理的文章,讲解下实现原理。mybatis-plus-encrypt: mybatis-plus-encrypt 是一款针对mybatis 的数据加密工具,原理基于mybatis的拦截器实现 - Gitee.com
历史数据处理
利用动态sql来实现,
<update id="updateBizTable">
update ${tableName}
set ${columnName} = #{fileId}
where id = #{id}
</update>
<select id="selectVoFromBizTableById" resultType="FileVo">
select
id,
${columnName} as test,
"${columnName}" as columnName,
"${tableName}" as tableName
from ${tableName}
where id = #{id}
</select>
总结
该方案,主要问题在于:
1、梳理全量的敏感字段,通常可以通过2种方法,
技术手段:让dba或安全团队,通过技术手段查询生产环境中各个表对应的字段和数据,是否有满足条件的敏感字段;
管理手段:让项目经理或系统负责人,统一对系统进行一次大排查,整理出来所有敏感字段;
2、对应存量数据,要提供通用加密方案,并在更新过程中不能影响正常业务功能;
如果对方案有任何问题,欢迎留言区留言。