加密算法
国秘算法。主要有SM1,SM2,SM3,SM4。密钥长度和分组长度均为128位。
SM1 为对称加密。其加密强度与AES相当。该算法不公开,调用该算法时,需要通过加密芯片的接口进行调用。
SM2为非对称加密,基于ECC。该算法已公开。由于该算法基于ECC,故其签名速度与秘钥生成速度都快于RSA。ECC 256位(SM2采用的就是ECC 256位的一种)安全强度比RSA 2048位高,但运算速度快于RSA。
SM3 消息摘要。可以用MD5作为对比理解。该算法已公开。校验结果为256位。
SM4 无线局域网标准的分组数据算法。对称加密,密钥长度和分组长度均为128位。
由于SM1、SM4加解密的分组大小为128bit,故对消息进行加解密时,若消息长度过长,需要进行分组,要消息长度不足,则要进行填充。
DES(对称加密): 密钥较短,加密处理简单,加解密速度快,适用于加密大量数据的场合
RAS(非对称加密): 加密密钥和解密密钥不一样,一般加密密钥称为私钥,解密密钥称为公钥。密钥尺寸大,加解密速度慢,一般用来加密少量数据
国内国际对比:
1. 分组密码算法(DES和SM4)、将明文数据按固定长度进行分组,然后在同一密钥控制下逐组进行加密,
2. 公钥密码算法(RSA和SM2)、公开加密算法本身和公开公钥,保存私钥
3. 摘要算法(SM3 md5) 这个都比较熟悉,用于数字签名,消息认证,数据完整性,但是sm3安全度比md5高
加解密方案
整体数据加解密使用DES,用RAS加密 DRS的密钥
后端存储层可直接使用DES,因为不需要直接对外提供,密钥不必暴露
1. 前端暴露层、或提供层,使用DES + RAS 组合方案,将RAS的公钥暴露使其解密DES的密钥用于提取数据
加密数据检索:
1. 需求:
对加密后的数据进行等职或区域检索 如 =、like
2. 现状:
此需求场景上有限制。较难实现 大厂也没有好的方案
阿里、京东、淘宝、拼多多采用的均是分词加密检索方式,在使用场景上并不能完美达到 常规的 = like 检索。
3. 一种实现的可能 (类似 ES分词检索)
密文检索的功能实现是根据4位英文字符(半角),2个中文字符(全角)为一个检索条件。将一个字段拆分为多个
比如明文数据 “张三多” 加密存储后实际为 “DQ21aTz/oe9qT2Xje1tTcddQ”
将“张三多” 分词为 “张三多”,“张三”、“三多”后分别加密后存储(可以是多一列、也可以是原始加密字段列以分割符隔开存储)
用户输入 “张三” 进入 like查询时,对“张三”进行一致的加密后去like 匹配 三个分词后的加密串,则可达到like 的效果
代价:
支持模糊查询加密方式,产出的密文比较长;
支持的模糊查询子句长度必须大于等于4个英文/数字,或者2个汉字。不支持过短的查询(出于安全考虑);
返回的结果列表中有可能有多余的结果,需要增加筛选的逻辑:对记录先解密,再筛选;
数据仓库代理
考虑切换不同的数据仓库类型,因此需要屏蔽中台对数仓操作的数据库细节(即中台对数仓的操作不应该是具体的技术框架或sql语句)
代理层需要实现的功能
数据库类型的连接配置
DDL DMl 这个两种差异的屏蔽(单表where and or 构造设计)
TCL 事务的支持?
简单数据查询细节的屏蔽(单表查询、分页等)
复杂大SQL的处理(比如开放一个复杂SQL的数据共享接口)(或者提供执行原生SQL的能力)
统计数据库信息,如表数、数据量统计(不同数据库指标可能差异)
一种方案:
基于实体模型(与元数据贴合)的类JPA思想
即: 中台对数仓的操作不在是 常规的 select form、update、drop等,而是以面向对象的方式操作数据库,代理层通过一种标准的模型封装(如属性名称、类型、长度、转化类型、格式化等等),来解析中台需要实现的操作并转化为具体数据库的执行脚本完成业务操作
如需对一种业务实体 学生(学生: {学号,姓名,身份证号})进行数据库操作
则中台需要将学生封装层代理所需的标准模型 ,以标准模型为参数执行代理的方法执行逻辑
评论区