“识、理、法”——动态脱敏能力的场景化建设实践 – 作者:观安信息

当今社会，正处在数据大爆炸的时代，数据信息正如潮水般席卷着人们的生活。人们在享受数据时代带来便利的同时，也在被数据泄露问题和风险的“潮水”所淹没。如某酒店集团数据泄露、某快递企业数据泄露、某社交平台用户数据泄露等事件层出不穷。国内外针对数据泄露和个人信息保护的法律法规也相继出台。比如：欧洲GDPR法案，国内的《个人信息保护法》（草案）以及各行业行规。

企业为了规避数据泄露带来的损失通常会采用一些防护措施，比如：终端防泄漏、数据加密、文件加密、数据库访问管控等。而上述措施虽然一定程度上可以防范数据泄露风险，但同时也降低了数据的流通效率，增加了业务系统的运行成本。

我们认为信息安全的本质是数据安全，解决数据安全问题是一个系统化工程。我们不妨像“大禹”治理水患那样采用变”堵“为”疏“的策略。数据脱敏是其中非常重要的一项技术能力，其中面向测试场景、统计分析和数据外发场景使用的静态脱敏方案，目前已较为成熟。但针对业务、运维操作人员数据实时访问的动态脱敏技术目前仍处于摸索阶段，而大部分数据泄露都来自于内部威胁。本文将重点介绍从业务场景化出发的动态脱敏解决方案。

识：识需求、察痛点

满足合规要求

※ 国内相关法律法规：

2020年10月-《中华人民共和国个人信息保护法》（草案）出台；2021年4月草案二次修订补充；

2020年2月-《个人金融信息保护技术规范》实施；

2017年6月-《中华人民共和国网络安全法》实施；

※ 国际相关法律法规：

美国：《儿童在线隐私保护法》、《电子通信隐私法》、《网络安全信息共享法案》等；

欧盟：《通用数据保护条例》（GDPR）

日本：《网络安全基本法》、《个人信息保护法》

新加坡：《个人数据保护法案》（PDPA）

以上法律法规强制性规定了敏感数据信息的保护要求，处罚措施严厉，经营影响大；比如facebook用户数据泄露将面临50亿美元的巨额罚款。更有甚者或将面临停业整顿、撤销业务许可或吊销营业执照的处罚。

防“内鬼”，降低数据资产泄露风险

据Forrester Research Survey的研究报告显示，超过60%的安全问题是由内部引起；FortScale的调查报告则显示，85%的数据泄露是来于内部威胁。

由于业务运营需要，用户敏感数据的流转很难不被暴露，公司内部人员是敏感数据的直接接触者，更容易发生敏感数据泄露风险。所以控制好内部人员的敏感数据访问权限就可以降低了绝大部分的数据泄露事件的发生概率。

动态脱敏的痛点

※ 业务应用系统改造成本大：

动态脱敏是解决敏感数据泄露的一个技术手段，所以业务应用系统在开发初期是可以在一定规范要求的前提下处理好敏感数据在业务系统中流转的防护的。甚至在系统已经上线后，也可以通过系统改造完成对敏感数据的脱敏使用。快递企业顺丰就是自行建设数据安全解决方案，耗时两年多将其三个数据中心，超过500个业务系统，投入了很多技术人员对每个库、每个表的数据进行数据梳理。由此可见，在像顺丰这种业务体量较为庞大的业务体系下，敏感数据合规改造成本非常大。业务系统改造考虑不充分还有可能影响业务系统的运行稳定性，增加系统故障率，可能造成不必要的业务经营损失。

※ 动态脱敏策略制定难：

从总体来看，我国各行业信息精细化管理程度不足，对数据的分类、分级和敏感信息的定义比较模糊。动态脱敏的效果好坏很大程度取决于前期系统业务的梳理以及摸清数据家底和流转路径，沟通并确认好数据分类分级标准，这个过程需要耗费大量的精力和沟通成本，需要反复验证。否则，即使配置了具体的脱敏策略，但是发现最终导致业务系统正常流程受到影响。

理：理场景、明诉求

运维场景下的动态脱敏需求

系统管理员和数据管理员（DBA）是有权限接触到大量生产环境的真实数据的。某快递公司数据售卖事件就是运维账号恶意泄露所导致的。所以动态脱敏的需求最为迫切的一个场景就是针对数据库的运维人员。应根据不同运维人员进行细粒度权限管控和针对性脱敏策略的制定，确保在运维域业务应用人员的职责分立基础上，针对数据库访问做好审计管理，作为事后追溯。对于重要敏感信息在运维访问操作前做脱敏处理后返回运维工具页面展示，做到事前控制与事后追溯相结合，有效控制敏感数据泄露风险。

业务使用场景下的动态脱敏需求

业务访问人员也会接触大量用户的业务信息和隐私信息，甚至有的用户还可以批量下载或导出重要资产数据，业务人员的敏感数据泄露问题也非常严峻。虽然当前业务系统在开发时会根据用户身份标识和权限进行身份验证，不同的用户进行限制数据的访问，但对于遗留系统，比如旧系统改造升级较为困难，以及开发时为考虑《网络安全法》中的要求，重新更改代码过于复杂的话，就需要依赖外部技术产品实现敏感数据细粒度的访问脱敏控制。

数据交换场景下的动态脱敏需求

随着信息化系统建设的不断推进，基于业务合作和生态共享，不同业务系统之间也会存在数据交换的实时共享。这个过程中很容易造成敏感数据在多个系统之前“裸奔”，数据暴露面扩大，泄露风险上升。比如：政府大数据中心会对外共享某些社会类信息给对应管局使用，共享时需要对个人标识信息脱敏处理。银行交易数据和存款数据共享至征信部门需要把账户标识信息脱敏处理后再提供等。以上说的数据交换更多的事接口间的数据不落地处理，所以只能考虑动态脱敏技术去解决。

法：选方案、定策略

代理网关

通过“逻辑旁路，物理串行”的方式部署数据动态脱敏的代理网关，让原来是由应用务器连接数据库,替换为应用服务器连接动态脱敏的代理网关，通过对SQL语句的转发与解析，实现在数据库层面对数据进行屏蔽、加密、隐藏、审计或封锁访问途径。

这种方式不需要在数据库服务器和应用服务器上安装任何软件，独立部署就可以实现相对较粗粒度的脱敏，还可以对一些高危操作指令进行阻断和改写，比如“drop”、”delete”、限制查询返回行数等策略的配置与应用。该方案也存在一些缺点，比如：无法实现用户级的不同脱敏算法和效果，同时存在运维脱敏被绕过的风险，还需要考虑如何很好的如4A系统的对接。

Agent代理方式

agent方式的核心技术是java动态字节码技术，通过该技术可将脱敏逻辑嵌入到业务系统中，业务系统无需任何改造，只需在启动时在启动参数里将agent加载进去即可。

agnet组件可以监控应用对数据的访问请求，当请求中包含敏感数据时，根据预置的脱敏策略进行脱敏处理。这种方式无需对应用系统做任何改造，同时可以针对业务应用的用户和菜单做细粒度化的脱敏权限控制。

这种方式目前存在的问题是，应用系统必须是JAVA系语言开发，而且对于单条数据进缓存的极少数情况下，由于web页面请求直接读取的缓存数据会导致脱敏操作被绕过，但这种情况很少见，也可以忽略。

接口能力化方式

接口方式比较适合不同业务系统之间的数据交换的动态脱敏处理，用户不希望脱敏处理会改变原有的业务交换流程，增加沟通成本和操作负担。在这种情况下，脱敏系统可进行能力化改造，通过提供标准的API或SDK给业务系统，业务系统进行对接集成的轻微改造联调即可实现动态脱敏效果。

常见的对接方式主要有应用接口网关（如下图）和接口对接。应用接口网关适合比较大型的业务系统架构，各业务能力和安全能力服务化，所有的API服务统一注册至API网关，脱敏SDK可由API网关统一部署，作为API网关服务管理的一个子功能，用于执行敏感数据的脱敏处理。脱敏服务则进行个性化脱敏策略的下发和管理。这种方式比较适合系统平台集中改造或新建的时候，对于运行中的业务还是建议梳理清楚业务数据流转路径后再关键节点部分调用脱敏的API/SDK进行既定规则的脱敏处理。接口对接需要考虑业务并发和脱敏处理异常的情况，并发可根据实际业务量进行上线前评估和测试，对于脱敏处理异常的问题可由客户制定具体的策略，比如：1.返回真实数据不影响业务；2.对于机密级数据进行脱敏重试后告警处理，确保原始数据流出。

接口化对接虽然有一定的联调工作量，不过对于业务系统的流程化管理是比较有益的。脱敏能力和策略管控可以分离，对基于数据级别和用户角色权限也可以较为全面的实现细粒度脱敏。

动态脱敏只是一项技术，具体能否解决用户的需求和痛点，在于是否能够从需求的本质出发，找到最合适的解决方案。方案没有好坏之分，只有适合和不适合。

来源：freebuf.com 2021-07-28 15:48:11 by: 观安信息