敏感信息加密

DiffDay2023-03-142024-06-28

敏感信息加密

敏感数据的加密存储无论从国家，行业及监管合规层面，亦或是单纯提高自身信息安全水平的层面看均是势在必行的一则工作。

业界实践中大批量数据的加解密一般选择对称加密算法，其计算效率远高于非对称算法。主流商用对称算法包括美国FIPS标准定义的AES算法，中国国标定义的SM4算法，国内肯定是用国密算法

国密可不是简单的算法设计的问题，它包含了: 物理和环境安全（如电子门禁和视频监控）、远程管理通道安全、日志文件加密安全、网络和通信安全、应用和数据安全，人员管理和制度建设等立体化多角度的要求。

密码学基础

柯克霍夫原则（Kerckhoffs‘s Principle）

有奥古斯特.柯克霍夫于19世纪提出：即使密码系统的任何细节已为人所知，只要密匙（key）未泄露，它应该也是安全的。通俗理解也即一个密码学算法的安全与否不应基于算法本身是否为外界所知，即通过让算法变成黑盒子无法提高算法本身的安全性。当前密码学基本都基于这一原则进行设计，即算法细节公开，通过密钥的安全性来实现加解密算法的安全性。

为何不能自行设计加解密算法

违反柯克霍夫原则。业界目前普遍使用的算法，基本都是由权力机关牵头，众多业界专家反复论证多年并达成共识才作为标准公开使用的，安全性有保障。

在应用层进行数据加解密

从发生层次大体可分为：前端，后端，数据库，文件IO层，硬盘加密五大类

前端加密发生在系统安全边界之外，其运行环境安全性无法保障，首先被排除
文件IO和硬盘，因为其发生层级低，能获取的元数据少，例如文件IO加密，系统仅能看到数据库底层映射的二进制文件，所以也只能对该文件进行加解密处理，无法再进一步区分哪些数据需加密，哪些不需要。这样对不同数据的管控能力基本为零，有悖于业界数据分类加密的安全思想。
对比后端加密即数据库加密两种方案，数据库种类，版本繁多。不同种类，版本数据库对国密的支持能力也千差万别。如此看，后端加密（应用层）加密就成为最合适的方案（对第三方软件侵入性低，兼容历史现状）。

敏感信息表改造

一列字段换两列密文

针对一个敏感字段，需新增两列密文字段

摘要索引：存储原始值+盐（不可逆哈希）计算后的密文字段
密文：存储密钥对称加密后的密文，密钥最好最小粒度到列级
- 业务需要明文时，可用封装提供的解密SDK提取明文

存储和计算资源估计要增加（每个明文字段要加上2个密文字段），密文是变长的（国密SM4算法分组对齐加密，二进制结果再转base64编码），摘要字段长度固定

密钥策略

摘要索引盐值整个公司统一
- 不可逆，窃取到数据也要通过数据碰撞的方式来对明文进行猜测
- 减少对称加密后数据无法关联的弊端（故需在可接受更广范围内使用相同颜值），关联计算比对值是否相等时直接使用
密钥每个应用都不一样，甚至每一列密钥都不同
- 考虑到密钥泄漏风险，更新密钥的代价，综合得出的策略。密钥应用范围越小，要更新数据的范围越小，要跟随更换密钥的应用越少。故范围越小越好
- 行业监管要求标准各异，不会有统一的密钥期，统一技术方案方不会主动发起密钥失效

密钥过期/泄漏如何更换

依赖我们在加密数据前增加的标识位信息

记录密钥版本，在切换密钥时知道如何解密
记录算法信息，让SDK可判断算法无需向服务端询问
包含一个MagicNumber，可快速排除非本系统加密的数据

看到待弃用密钥加密的数据，那么就在解密提取明文信息后使用新密钥更新加密

密文改造的挑战

模糊字段查询
- 密文索引有诸多方案，主要解决思路是将信息分片，如将11位手机号分成3/4/4三段，允许各自按约定规则达成模糊查询
手写SQL
- 这对彻底改造干净字段的处理逻辑带来不少的工作量，select * from也可能引入一定的逻辑风险
- 应借此机会构建数据服务层，利用AOP降低应用和数据对象操作的耦合度，以注解方式标注要加密处理的字段，收口进行处理
存储过程
- 无在存储过程上的加解密方案，在加解密改造过程中，存储过程逻辑需要被改造和去除
- 若存储过程仅为了搬运数据，可适当改造保留
加字段性能风险
- 老版本数据库在增加密文字段时的执行时间风险需要关注
- 历史数据清洗会引起同步机制大量更新延迟

催生的设计变革

设计变革

集中管理涉敏数据比分散在不同应用中好，相当于提供一个统一的数据服务，需涉敏信息原文时，都来这里取值
加密后无可避免会有特权人员要对原始明文进行查阅确认的需求，如生产排障，事件调查。需要一种功能来应对这种密文或脱敏信息的即席查询需求
授权长度可控，例如对人的授权通常为15天，30天，60天，365天不等。权限上也分脱敏查询权限，明文查询权限两类

闭环管控流程变革

flowchart LR
subgraph 增量
	A[新增应用\库\表\字段]
	subgraph 上线前-纳入安全开发流程
	B[需求评审
存储加密需求分析&架构评审]-->C[安全开发
安全策略申请&存储加密功能集成]-->D[安全测试/上线]
	end
	subgraph 上线后-定期扫描监测
	E[风险控制和监督管理
每月定期扫描，识别违规上线应用、字段]
	end
	A-->B
	D-->E
end
subgraph 存量
AA[存量应用\库\表\字段]-->BB[制定整改计划]
end
BB-->C
E--应加密未加密-->BB

架构组成模块关系

对于线条多的flowchart图，mermaid还真的胜任不佳

flowchart LR
	subgraph employee域
	A[(KMS加密机)]--秘钥管理-->B(((加解密服务)))
	C[/敏感数据扫描系统/]--敏感数据地图-->B
	B-..->|私钥加密策略|D((加解密SDK))
	B-..->|私钥加密策略|E[\历史数据加密清洗工具\]
	B-..->|私钥加密策略|F[[安全访问代理]]
	end
	G[员工]--查询加密数据-->F
	subgraph user域
	BB[/应用服务\]--数据保存-->CC[(应用数据库)]-->DD>ETL任务搬运数据]-->EE[(大数据平台)]<--衍生分析数据-->FFfalse
	end
	AA[用户]--应用采集用户敏感数据-->BB
	D -..-x |加密增量数据及提供解密|BB
	D -..-x |加密增量数据及提供解密|DD
	D -..-x |加密增量数据及提供解密|FF
	F-->|涉敏查询审批动态解密脱敏|EE
	F-->|涉敏查询审批动态解密脱敏|CC
	C-..->|全字段采样扫描识别敏感信息|CC
	C-..->|全字段采样扫描识别敏感信息|EE
	E -..-o |加密存量数据|CC
	E -..-o |加密存量数据|EE

改造步骤

stateDiagram
	direction LR
	A : 去扫描平台完成
库、表、列等元数据
信息扫描和确认
	B : 登录加解密服务平台配置策略等信息
	C : 策略文件下载
	D : SDK加解密功能集成
	E : 业务系统调用
	[*] --> A
	A --> B
	B --> C
	C --> D
	D --> E
	E --> [*]

明确数据加密范围，上下游和关键风险后，接下来就是开干

在涉敏数据表添加相应密文字段
申请加解密sdk
完成SDK完成增量加密
存量数据加密清洗
应用程序使用密文数据
应用程序停写明文且清理历史明文

最终目标：删除存量敏感明文

明文如何清理

DB不删除字段是例行做法

按不同数据库方案兼容，写入“0”清除原明文敏感信息是目前兼容性最广的方案

大数据环境怎么玩

大数据的特别点

大数据环境对数据的使用，更多是探索，挖掘等不确定性的使用。最具探索特质的带有主观能动性的数据工程师，而不是被设计出来完成固定任务的系统。理想化来说，大数据系统这使用数据的是分析师而不是系统

数据权属主体是组织，组织的工程师是使用数据的主体
几乎不存在数据生产者，因此数据资产主要来自于生产数据资产的使用权、使用权让渡
- 数据所有权是业务系统所有，当生产环境数据通过ETL传输到大数据环境后，使用权发生了变化。若在大数据环境降低多源数据密钥不同对数据分析工作效率带来的影响，应考虑变更数据所有权（按大数据自己的密钥加密）
  
  多元数据汇聚（不同部门密文不同，摘要也不同），必须以所有权让渡的方式进行
- 有无一种方法可允许数据属主保留数据资产所有权，同时允许大数据环境的分析师可对多源数据进行联合分析？众多技术路线中有一路隐私计算，对密文二次加密后密文结果相同（相同明文两次加密后密文结果相同）
  
  在深度模型训练这种数据向量化的场景适用，但对数据分析师这种人工参与的场景有些理想化了