货拉拉数据加密治理实践

2024-10-31

背景

在当前环境下数据安全、网络安全的重要性逐步提升。在网络安全法和个人信息保护法中也明确提出，企业需要针对敏感数据加强安全措施，敏感数据需要加密存储。针对数据加密已经有了非常成熟的技术，比如在应用侧加密，各个语言中也都有现成的加密函数，可以直接引用。

但在实施数据加密过程中，我们发现面临成百上千的服务以及过亿的数据，加密的事情不仅仅是调用加密函数这样简单，而需要考虑，安全性、稳定性，以及投入成本等等。货拉拉在推动数据加密落地过程中分为三个主要阶段，分别是数据调研、方案选型、加密改造。

数据调研

在确定需要做数据加密后，第一阶段是展开了针对服务语言、数据存储组件、敏感数据分布的摸底调研，便于确定初步做加密的范围。

关于服务语言，一般企业内开发语言相对较统一，或者某一种是主流语言如Java、PHP、Go、Python等等，后续技术方案优先考虑企业内主流服务语言。数据存储组件，同服务语言，企业内数据存储组件较统一，按照是否结构化数据、是否持久化存储来进行摸底。

敏感数据分布调研，这部分是数据资产识别范畴，依据公司数据分类分级制度，对公司资产进行识别。优先以个人信息和重要数据的识别为主。

方案选型

方案选型是比较重要阶段，需要安全、研发架构、CI、DBA全部参与方案的讨论和选型，能多角度多立场评估方案，充分识别风险。

从数据流动过程看，各个环节有相应的加密技术，各技术的特点如下

我们结合加密要实现的目标，选取了相对较符合公司场景的加密技术来展开评估，应用层加密和数据库代理层加密。

首先是应用层加密，我们扩展了两个方向，一是统一敏感信息服务加密，二是各服务应用层加密。

统一敏感信息服务加密，是需要将敏感数据收敛至中台，减少数据落盘。

优点：数据汇总统一处理加密，也更便于后续敏感数据的统一管理；

挑战：对敏感信息服务的可靠性要求较高，且需要满足不同的业务场景；

更多待解决问题：

1）比如用户在注册前没有UserID，不能用UserID进行关联，只能用手机号用来判断其为新用户或老用户，数据将无法完全收口；

2）比如数据统一存入中台，如何进行手机号和用户之间关联关系的维护，用户修改号码，需要更改关联关系，会成为服务难点；

3）其次，数据收敛的改造成本和应用侧各自加密，成本相差无异，所以非新业务的场景，统一敏感信息服务加密并不是最优解。

各服务应用层加密，是在应用系统层面开发改造，数据入库加密，出库按需解密。

优点：处理灵活对数据库没有依赖。

挑战：涉及应用系统开发改造，工程量大，研发成本高，时间周期长。

数据库代理层加密，是在数据入库和出库时候，通过解析SQL，对传入的数据进行加密/解密，从而获得保护数据安全的效果。

优点：中间组件做数据加解密改造，上下游改动少，可扩展性更好，一定程度减少研发在应用侧的改造成本。

挑战：在高并发场景下，性能消耗较高，对业务应用稳定性影响非常大。

综上三个方案中，相对符合的是各服务应用层加密，虽然会有较高研发成本，但没有瓶颈限制，对业务的性能影响也最小。

方案选型结论是在内部发起了多轮评估达成的一致结论，期间针对较大争议点通过上升决策来处理。除此之外也对行业内其他公司的加密方案做了调研，来为内部评估提供参考。

加密改造

前期的方案选型经历了较长时间，因为一旦选定方向，再做调整会有较高成本。而在推动加密改造阶段，初期也是更多聚焦在密钥管理、加密算法、加密技术三方面上。在中后期业务接入更加关注如何平滑做加密切换。

密钥管理

首先是密钥管理，现在已经有了很多厂商提供了密钥管理服务，并且都使用硬件安全模块来托管密钥，符合监管合规。使用KMS可以让业务避免直接接触密钥，规避将密钥硬编码在代码中或者写入配置文件中带来的风险。另外KMS也采用了多重密钥的方案，如DK和KEK，避免明文数据密钥的直接暴露。

DK（Data Key，数据密钥）,是直接对数据进行加密的密钥。KEK（Key Encryption Key，密钥加密密钥），是对DK进行加密的密钥。应用在本地加解密场景下的架构如下：

数据加密过程

1）生成数据明文DK和密文DK；（在KMS服务内使用KEK加密明文DK后生成的密文DK）

2）使用明文DK加密数据，产生密文数据；

3）持久化存储密文数据和密文DK；

数据解密过程

1）从持久化存储中获取密文数据密钥；

2）通过KMS对密文DK进行解密，获得明文DK；

3）使用明文DK对密文数据进行解密，获得明文数据；

KMS服务本身对密钥有生命周期的管理，包括密钥生成、轮转、禁用、删除等。除此之外在实际应用中，还需要对以下方面进行考虑：

1）密钥的分配维度

密钥的安全性和其加密的数据量成反相关，所以要尽量减少同一密钥所加密的数据量。密钥分配和加密方案相关，可以根据应用维度分配、或者数据库维度来分配。

2）密钥的轮转机制

在应用侧加解密的实践中，密钥轮转存在较高成本，所以前期可以通过合理分配密钥来降低风险，尽量规避频繁的做密钥轮转。但需要在方案设计时规划密钥轮转的能力，一方面应对因key泄漏导致的被动轮转；另一方面满足监管定期更换密钥的要求。

3）密文DK的持久化存储

数据解密时，需要从持久化存储中获取密文的数据密钥，密文的持久化存储根据加密对象的不同可以分为两类，在加密非结构化数据大文件时，采用“一话一密”模式，可以将加密后的大文件和密文DK打包一并存储；在加密结构化数据时，所加密的数据量巨大，不宜采用“一话一密”模式，需要将密文数据密钥单独存储。如果将数据密钥本身或者密钥的版本号和结构化数据的密文拼接存储，比如以下形式“b8a40b9cfa1975425f26e50fb64bc0e2&v1”，会破坏密文数据结构，给下游使用带来额外研发成本。所以针对结构化数据加密，需要分别单独存储密文和密钥。

加密算法

在选择加密算法时，需要使用更为安全的加密算法，如国密算法或者AES、RSA等；此外也需要结合业务场景，来选择更为合适的算法。

比如对称算法加解密速度较快适合大量数据的加密，而非对称算法比较慢，适合小数据量加解密或数据签名，此处根据实际业务场景选择即可。

加密技术

存量改造

推动业务做数据加密，最主要问题是针对存量数据的改造。新业务可以直接使用加解密工具实现，而存量数据加密改造，包括增量数据处理、历史数据清洗、切换过渡加密字段、以及对下游依赖和直接依赖库的影响评估等。以存量数据加密改造为例，改造步骤有下：

由此可见，在应用侧加密周期较长，且为复杂，所以需要保证尽可能提供统一技术方案，减少业务代码的改造。

一提供加解密SDK

对常用加密算法进行统一封装，业务改造时引入SDK包，使用所提供方法进行本地加解密处理。使用原生SDK改造工程量较多，每个需加密的数据的写入和读取都需要逐一修改代码。

二提供加解密组件

目前Java服务中大都使用Mybatis作为数据库持久层，可使用Mybatis Interceptor 拦截update、select、insert等命令，对参数和结果进行加密、解密处理。可简化代码改造，降低研发成本。仅需增加注解或配置即可。

虽然加解密组件可以简化代码改造，但也仅解决了增量数据的加、解密处理，即步骤二和步骤五的部分改造。步骤三、四、六以及五中的灰度读能力，都无法解决。所以在业务改造中对加解密组件进行了优化。

三加解密组件优化

在二中的加解密组件中，是用Mybatis Interceptor 拦截sql之后，仅对参数和结果进行加解密处理，而优化后的加解密组件中，对原始sql进行了修改，业务只需进行简单的配置，就能实现自动加解密功能，以及增量及存量数据加密、数据一致性校验、不一致数据修复、灰度读取加密字段、读数据双边对比等能力。

所以通过组件嵌入方式，就可以相对实现业务“免改造”，减少代码工程。

数据加密除了周期长外，还涉及研发、CI、DBA、大数据、安全等多部门配合，所以在实际改造过程中，需要统一汇总各发布环节中的检查项，业务在发布上线前需逐一check，避免因数据加密带来的风险，影响线上业务运行，这也就是在中后期更关注的平滑切换问题。在此我们分享出加解密流程中，一些共性的注意事项，希望能给大家带来一些参考意义。

增量管控

从风险管控角度考虑，越早发现风险，解决问题带来的成本将会更低，同样适用于数据加密改造。增量敏感数据的加密直接接入加解密组件即可实现，不涉及历史数据清洗、读取切换等，工程量较小。所以一定要把控好增量敏感数据监控。按照事前、事中、事后三个阶段来监控。

一产研设计阶段（事前）

此阶段无法通过自动化工具实现，主要以安全宣导为主，比如在研发手册中增加针对敏感数据加密的管控要求、或在SDL中增加安全规范。提高研发安全意识，及早规划数据加密。

二预发布阶段（事中）

在预发布环节的监控，依赖数据库安全审计的基础能力，可以针对STG和PRE环境下的“CREATE TABLE”以及“ALTER TABLE user ADD COLUM”等增加sql审计，进行敏感数据识别，联动告警触达加密规范。

三生产发布阶段（事后）

如因项目进度或告警触达遗漏等原因导致，增量服务中存在未加密的敏感数据。就需要依赖数据资产识别能力，定期针对数据库资产进行扫描，识别未加密数据，再推动业务整改。

衡量指标

当作为整体项目推动数据加密时，需要设计科学的定量指标来辅助推进，需要从表、字段、数据量多维度统计，多角度观测加密进度。

但是加密覆盖率指标的统计，有关联依赖，依赖数据库敏感数据的识别、加密数据的识别，以及识别的准确率和召回率。

另外在针对存量数据加密治理的最后一个步骤为数据清除，原明文字段将会成为空字段，所以也需要增加空字段的识别能力。以更准确的计算指标。