脱敏真正的困境
脱敏方式是各种文章讲得最多的一个话题,Tokenization、masking、加密,以及针特定类型数据应该采用什么脱敏形式的建议也不少,都很中肯,但是,对于一个企业安全人员来讲,当我们去推动产研部门进行合理脱敏的时候,遇到的困难显然并不是业务研发不知道应该用什么脱敏,而是类似安全要求带来的改造成本以及对用户的影响。比如,脱敏了这些问题该如何解决:
系统非常庞大复杂,有不知道多少个页面,不知道多少个接口涉及敏感数据,得改造到什么时候?
系统不停地在迭代上新功能,业务研发要增加安全研发内容,正常产品迭代周期加长了多少?
公司有几十个系统需要改造,全不改完得到什么时候去了?
系统是购买第三方的,自己没有源代码,想改也改不了怎么办?
系统用户正常情况下需要看到这些敏感数据,否则没法工作了,怎么办?
以上这些问题才是一个企业在面对脱敏时,真正头疼的问题。
现实中不同脱敏方案的应用现状
依照数据的流转路径,数据脱敏的节点在逻辑上可以有如下多种选择,很多方案在逻辑上成立,但面对现实的可操作性和落地性上来讲,各有优缺点。
1. 数据库脱敏
可以说这是在现实中应用最多的场景了,原因很简单,一来数据库涉及数据量大,脱敏价值高;二来技术上好实现和落地,对终端用户无影响,安全团队受到挑战和质疑少。一般的应用场景,就是在从生产数据库到测试数据库导数据的时候。
缺点:
不能应用于应用脱敏,应用不能依靠数据库因脱敏而带来的性能和稳定性消耗。
数据库层面无法满足应用对数据不同的业务场景需求,不能无差别的进行脱敏。
非固定格式的数据,需要依赖大量逻辑判断,无法在数据库层面集成。
2. 应用后端脱敏(依赖业务系统改造)
应用自身在后端服务实现脱敏,主要在于研发成本,不能一蹴而就,随着业务系统的变化要不断添加脱敏逻辑代码。后端脱敏逻辑难以抽象公共模块组件,进行统一的数据识别和脱敏,研发成本大。
缺点:
脱敏要依据用户权限和数据类型,以及业务系统要求,难以抽象出统一的脱敏模块,最后几乎是每个需要使用数据的代码块自己单独实现脱敏逻辑。
业务系统消费数据的接口和代码逻辑众多,要全盘梳理后改造,成本巨大。
业务系统在不停的更新迭代,脱敏变成一个需要长期内部运营的事物。
3. 网关脱敏
网关脱敏是指在应用前端(客户端或者浏览器)与后端服务之间,串联一个网关,在网关内过滤网络流量,进行流量内的数据识别和同步脱敏。网关脱敏面临和数据库类似的性能和稳定性障碍,同时还新引入了较大的业务风险,即破坏了业务系统本身的双向验证机制。
缺点:
网关脱敏面临和数据库脱敏同样的风险。
应用不能依靠网关因脱敏而带来的性能和稳定性消耗。
网关层面无法满足应用对数据不同的业务场景需求,不能无差别的进行脱敏。
非固定格式的数据,需要依赖大量逻辑判断,无法在网关层面集成。
网关脱敏会破坏正常的网络请求安全性校验(中间篡改),导致应用无法使用。
4. JS 脱敏
通过在业务系统前端插入脱敏 JavaScript SDK 实现数据自动识别与脱敏。最初的设想是由安全团队提供类似通用脱敏中间件的形式,给业务研发进行集成。但整体效果来看,由于本身的脆弱性,并未得到实际验证与落地。
缺点:
需要前端接入,有开发工作量。
只能处理固定格式数据,如手机号码,不能完美处理姓名等变化较多的文本。
可以在终端被轻易去除,导致脱敏不生效。
可能破坏某些业务系统安全性校验。
5. 专用浏览器脱敏
这是业界最新的一种形态,通过专用浏览器,在浏览器内核层面进行数据识别和脱敏。当然从其形式来看适用场景也是受限的,仅限于Web系统,以及仅适用于内部系统(总不可能要求公众客户安装指定浏览器)。
缺点:
只适用于Web系统。
只适用于内部系统,或者采购的第三方但是部署在企业内部的系统,用户是自身员工或者可管控的外包以及其它第三方机构。
浏览器研发成本高,一般企业没有能力去构建这样的解决方案,只能寻找第三方,目前宣称有这样安全能力的只有数影星球一家。