Skip to main content

数据加密网关黄皮书V2.3

· 12 min read

数据加密网关黄皮书V2.3

用户密钥管理系统

用户密钥管理系统与Y star/Bingoo 的K aaS相似,每个用户(用户指当前操作人员,客户指用户所在机构)根据身份认证方式的不同,分为多个Level(Level数量可配置,原则上该配置不可修改),每个Level可以解密出零个至多个角色私钥(即Y star/Bingoo 的Account私钥),在用户登录后将用户id、用户私钥、各角色id和对应的角色私钥发送给数据密钥管理系统。

每个用户的角色信息建议保存到区块链上,任何的改动都记录在案,修改痕迹不可篡改,便于安全审计。例如,每个用户一条记录,记录其有权限的所有角色和对应角色的密钥(用对应level的公钥加密的角色私钥),将角色id和对应密钥base64,各角色用分隔符分开。

对用户角色用类似拉群的方式进行维护。先按部门建立若干群,HR(或类似人员)在每个群里都是管理员之一,在新员工入职、员工离职或调岗时将该员工拉入相应群或从相应群中删掉。员工也可以自行建群,群管理员拉人入群或从群中删掉。

在技术实现上,一个群就对应一个角色,建群时自动为该角色创建一对随机公私钥,群管理员拉人入群就是将该角色的私钥用该用户的公钥加密后记录在该用户的名下,反之则是删除。

建群的人自动成为群主,群主自动成为群管理员,群主可以转让也可以指定其他群管理员。群管理员可以指定所有群员都可以拉人入群还是只有群管理员才能拉人入群。系统初始化时,HR创建各部门群,自动就成为各部门群的群管理员。

这样,每个用户可以看到自己的数据和他所在的所有群的数据。他被拉入一个群后,就有权限看到该群的所有历史数据。

每个entity都有一个特定的account(以tag标识)记录该entity的加密公私钥和签名公私钥。当前实现:每个群就是一个entity,每个分类分级也是一个entity,群管理和分类分级在管理后台做,只有特定管理员才能做,必要时可以用ukey来认证该管理员。

100以内的entity id保留系统用,其中id=1代表anyone,该Id的私钥是无需登录就永远在系统中的。

用户密钥管理系统对外提供的接口:

建立安全会话通道

对指定数据解密: 这是对数据密钥管理系统提供的主要接口,是一种安全度略低但性能和耦合度比较好的方式。

参数:

  • id(整型)
  • 待解密的数据

参数说明:id可能代表一个用户、代表一个群、代表一个分级分类、代表一个进程,根据id号可以区分。待解密的数据实际上是加密的密钥。100以内的id保留系统用,其中id=1代表anyone,该Id的私钥是无需登录就永远在系统中的。

返回值:解密后的数据。

业务流程:用户密钥管理系统检查当前是否有该id的私钥,如果有的话解密后通过安全会话通道返回,否则报错返回

取指定公钥

参数:id(含义同上)

返回值:该id的公钥,如果id非法报错

指定用户创建新群:

参数:创建者用户编号(即Y Entity)

返回值:群编号

业务流程:生成随机公私钥作为群密钥,用指定用户的entity中创建一个群account(有TypeGroup的tag),用该用户的公钥加密群密钥后保存到该群account中,将account名作为群id返回。创建者自动设为群管理员。另外有一个群管理的数据库表来记录每个群的管理员。

群增加新成员: 群管理员可以授权其他用户拥有群密钥,相当于导入账号

参数:群管理员编号,群编号,新成员的用户编号

返回值:成功或失败

业务流程:用群管理员的私钥解密出群密钥,新成员建立群account,用新成员的公钥加密群密钥后放到新account中

群减少成员: 群管理员可以删除其他用户的群账号,但不能删除最后一个群管理员的账号

参数:群管理员,被删的成员

返回值:成功或失败

业务流程:将被删用户的相应群account去掉

增加/减少群管理员: 群管理员可以授权其他群成员为群管理员,或取消其群管理员权限,但至少需要保留一个群管理员。群管理员是代码逻辑方式管理。

分级分类的管理类似群管理

数据密钥管理系统

数据密钥管理系统维护一个表,记录哪个ID对哪类数据有权限,并用该ID的公钥加密该类数据的密钥(对称密钥或私钥)。如果能获得该ID的私钥,即可解密出该类数据的密钥。

ID可以是用户ID,也可以是群ID、分类分级ID,都是其对应的entity的ID;对结构化数据,每个字段都有一个独有的密钥,对文件数据,每个文件都有一个独有的密钥。

数据库网关

数据库网关作为ShardingSphere的插件形式存在。

数据库网关配置

数据库网关的分组是在各网关配置,同一分组的网关配置的ShardingSphere的zk namespace是相同的。

ShardingSphere插件在启动时读shardingsphere的zk namespace,连同插件自己的配置文件中的网关ID(如有),一起发给后台注册/登录:

如果配置文件中没有网关ID,则后台视为新网关注册,会分配一个ID,插件将其写入配置文件,同时也写入filebeat配置文件中的elk索引配置,用于区分不同网关上传的日志;

如果配置文件中已经有网关ID了,就发给后台,后台视为已有网关上线。

数据类型转换和加密

布尔型: 转换为int8,生成随机数并调整最后1位,使得其奇偶等同于原bool值;但如果该字段需要做索引,则前7位为配置的固定数(配置时随机生成)

字符串型: 在加密后再base64,其最大长度是原始长度的4/3向上取整

文件字段的处理: 与数据中台相同

为实现密文索引,对于只需精确检索的字段,配置该字段只需列密钥加密;对需要模糊查询的字段,增加一个索引表,该索引表中该字段是明文(建索引),原表的主键字段是密文(不建索引)。将来索引表建立在内存数据库中,与原数据库有一致性机制(例如同时回滚)。

可配置一个字段是常规加密(行密钥和列密钥都用)、只做列密钥加密和不加密。

数据操作流程

创建/更新记录时: 从数据密钥管理系统获得相关字段的密钥,每个字段转换数据类型(如果需要的话)后加密,写入后端数据库。对于建立额外索引的字段,同步写入索引表。如果需要额外区块链备份,同步写入区块链数据库。

读记录时: 从数据密钥管理系统获得相关字段的密钥,从后端数据库读对应字段,解密后转换数据类型(如果需要的话),返回给应用系统。

对密文字段进行精确检索时: 对关键词用对应的列密钥加密后进行检索,检索出来的记录如上解密后返回给应用系统。

对密文字段进行模糊检索时: 在索引表中进行检索,对检索出来的记录的主键进行解密,用解密后的主键去原表调取相应记录,再解密后返回给应用系统。

总结

数据加密网关黄皮书V2.3定义了完整的数据安全解决方案,包括用户密钥管理系统、数据密钥管理系统和数据库网关等核心组件,为企业级数据安全提供了全面的技术支撑。