数字化新业态下数据安全创新-token化

阅读量19667

发布时间 : 2022-09-20 10:30:14

 

// 文丨王志刚

美团安全架构师。密码学、云原生和DevOPS安全,数据安全和隐私合规专家。近几年推动用大数据算法解决网络安全和数据安全能力。曾先后在亚马逊、华为、阿里云、百度担任过重要安全技术岗位。曾获得CISSP 和 DevOPS Professional认证。

引言  

伴随科技创新引领数字化浪潮席卷全球,数据成为企业发展的核心生产要素。像Google、Facebook等高科技公司,通过提供免费、优秀的软件和服务,接入大量的用户,并基于数据资源驱动,获得了巨大的商业上的成功。然而,在高速发展的同时,公司对数据却疏于治理,引起了大量的数据泄漏、算法滥用以及隐私相关的问题。这种危机伴随着Facebook的“剑桥分析”丑闻,2020年美国大选等标志性事件,推向了高潮。基于对数据安全和隐私的担忧,欧盟的GDPR领衔的现代隐私合规出台,随后风靡全球,成为又一不可逆转的潮流。

摆在企业面前是两条路,既要通过数据科技创新保证生存发展,又要保证用户数据的安全。在这两条路的选择与平衡上,有些企业倒下了,有些企业存活下来,迸发出新的勃勃生机。

由此可见,唯有转变思路,勇于创新,才能化危为机,长远发展。我们要认清转折趋势:数字化时代从上半场粗放、低效,大水漫灌式碳增长,向基于高效数据管理、治理能力的高质量、高效率的数据碳中和转变。企业要在这个转变中生存并脱颖而出,科技创新是重要的抓手。重点把握两大核心思想:1.需要认清强大数据应用生产力特征,积极进行技术改造,充分利用先进的数据管理技术手段,提高数据使用效率和治理水平;2.深入学习、理解隐私合规的目的和本质,遵循“可用、不可见”的核心思想,实现效率与治理的统一。

一、数据科技对安全的挑战

数字化应用环境下,数据具有如下特征:

1.数据的流动性与开放性:按数字经济学理论,数据要想创造出商业价值,就必须做到低成本、大规模供应,高效流动。如果利用传统网络安全最小化、层层审批、层层设防,将严重限制数据生产活力。此外在数据流经的每一个节点都达到高级的防护基准,成本也是组织无法承受的。

2.数据的可复制性和失控性:数据作为流动资产,一旦被访问后其控制权将被转移,供应者将失去对它的管控。传统的信任边界在数据应用中也越来越模糊,这些都让集中安全策略在新型数据架构下落实起来成本巨大,收效甚微。

3.数据形态多变、应用复杂:数据将在几乎所有IT系统中传递、存储和处理,其复杂程度超乎想象。加之AI、机器学习以及各类创新型数据应用,让数据使用逻辑更难以琢磨,要想了解数据的全貌几乎是不可能的任务。

4.数据威胁复杂多变:数据的巨大商业价值让包括黑、灰产业链,内、外部人员乃至商业、国际间谍都趋之若鹜。攻击技术、动机层出不穷,防不胜防。

图1: 常规系统为中心防护模式下数据暴露性

传统模式下,数据以明文形式在系统中流通,数据暴露性巨大。攻击者通过应用程序、存储、主机系统入口,以及攻击系统的授权账户等多种渠道获取大量数据。

图2: 常规模式横向数据暴露性

数字化场景,数据将在数以万计的应用、任务中传递。每个应用都有自身逻辑,让所有应用合规成本巨大。在如此广泛、复杂的环境下要保护数据安全,如果采用传统以系统为中心的防御模式,必将造成防御战线过长,攻强守弱的格局,让数据安全治理长期处于不利地位。必须转变思路,创造出一种数据内生的安全机制,在数据业务高速扩张环境下,安全防护能力也随之增长,这就是以数据为中心的安全防御创新机制。

二、Token化-数字世界银行体系  

Token化方案参考现实世界的银行系统。银行体系出现前,市面上经济活动主要以现金交易为主。现金的过度暴露,产生了大量的盗窃、抢劫案件,虽然镖局生意盛行,但只有少数富豪才雇佣得起,因此社会资产大量流失。银行体系应运而生:用户获得现金后,第一时间去银行将现金兑换成存款(等价代替物),随后在整个社会中流通的都是这个代替物-电子现金,只有在极个别场景兑换成现金。随着银行系统的渗透,加上各类线上支付应用的普及,这种现金使用场景越来越少。要想抢钱,只能到银行去,而银行是经过重点防护。

同样,数据作为核心资产,可以通过方案在个人敏感数据数据(PII)刚进入组织业务系统时,就将明文数据(P)替换成与其一一对应的假名-token。在随后的整个组织应用环境中以token高效流通。因为token与明文是一一对应的,可以在生命周期绝大多数场景代替明文传输、交换、存储和使用,而Token只有通过安全可靠的token化服务,才能兑换成明文。黑客和内外部恶意攻击者即便拿到了也毫无用处(不可见)。由于token的自带安全属性,只要在组织内控制住主要数据源和数据枢纽只使用token流通。新的明文数据需主动换成token,实现数据默认安全,从根本上解决了个人敏感数据的治理难题。

图3: token化的数据暴露性

如图,通过推广Token化,可将实际可访问明文的服务压缩到2位数,数据服务暴露性降低到1%以内。

图4: token化后数据纵向暴露性

如图,Token化改造后,敏感数据做到0存储、0缓存,0接口,0数仓;只有在少量具有解密权限主机内存,以及UI才可能获取明文数据访问权。UI通过后续细粒度访问控制和审计风控等措施,实现风险可控。对于少量的内存数据,因其数量有限,可通过特定的加固和风控措施,进行强化。如果实现全面token化,敏感数据整体风险控制能力可大大增强。

三、Token化方案介绍

3.1什么是Token化

Token化(Tokenization)是通过不敏感的数据等价替代物token(token)替换个人敏感数据,在业务系统中流通来降低数据风险和满足隐私合规的方案。Token化属于去标识化技术的一种。最早出现在支付卡行业(PCI)场景替换银行卡(PANs),目前有趋势替换通用数字化场景中的个人敏感信息(PII)。

1.个人唯一标识信息(PII):任何可以直接、间接关联到具体的自然人的唯一标识信息如身份证件、手机号、银行卡、电子邮件、微信号或者地址。单独依赖PII信息,结合其他公开信息,就可以找到自然人。PII信息一旦泄漏,可能对个人造成如身份冒用、欺诈等生命财产伤害。因此在包括国内外各类法规中明确要求企业对PII全生命周期保护。

2.去标识化(De-identification):通过一定技术手段,对敏感数据进行替换、转换,临时或永久消除个人敏感数据与自然人的关联。具体的手段包括假名化、匿名化、数据加密等。

3.假名化(pseudonymization):通过将敏感数据替换成人工ID或假名,未经授权,任何人无法利用假名建立起与原自然人之间的关联。Token化就是一种假名化实现机制,广义上二者可以概念互换。假名化是包括GDPR在内认可的去标识化方案。注意,假名化与PII是一一对应,在特定场景是可以还原原始数据。

4.匿名化(Anonymization):对敏感数据部分,或全部进行遮盖、替换,让其完全失去与原数据或自然人的关联。匿名化是不可逆的,常用的匿名化技术包括数据遮盖(data masking)。

5.数据加密:采用数据加密算法,如国密对称算法SM4,普密算法AES,对敏感数据进行加密,生成密文(Cipher),除非获取如密钥管理系统(KMS)加密密钥授权,无法进行解密,获得明文。注意与假名化Token不同的是,密文只能解密出明文后才能使用,没有任何直接使用属性。因此密文只能用来存储和信息传递,大大限制了使用范围,例如搜索、关联、查询、匹配等数据分析场景。

3.2 Token化基本设计

3.2.1 可用、不可见

1.可用性实现:

a)大数据分析场景利用Token的唯一性,实现数据挖掘、加工、分析等场景的去重、统计、关联等功能;

b)信息传递,在其他所有场景,Token利用其唯一性,可以完全替代明文数据在整个体系中流通,解决交换、关联、查询、匹配等环节的数据使用;

c)敏感功能使用:在必须使用明文数据场景,可以通过Token化服务换回明文,实现可用性兜底。

2.不可见性实现:Token化本身的安全性是整个方案的安全基础。因此Token化从设计、到实现必须保证其安全,来防止非法者利用Token获得对应的原始明文,导致数据泄漏。详细请参考“四、Token化安全性实现”。

3.2.2 基本架构需求

为满足复杂场景下数据保护能力,要求Token化方案满足几个主要架构要求。

1.业务适配性: Token化需要满足所有数据应用场景的数据交换要求,包括线上交易、实时和离线数据应用,以及AI和机器学习算法等所有场景。

2.安全性:保证Token的脱敏属性是通过保证其与明文的关联关系的保护。这里需要通过算法和Token化服务的安全以及下游应用的多重安全来保障。

3.可用性和效率:Token化的引入,不应增加对业务系统的效率和稳定性的下降。

3.3 Token生成逻辑

Token化的逻辑是,在企业范围内,为敏感数据生成全局唯一的ID-Token。通常有3种方案实现ID生成。

图5: token化逻辑示意图

图6:token化生成方法1

1.随机化:Token完全随机生成,并通过保存一一映射关系表(这种是狭义的Token化生成方式)。因为token与明文没有算法关系,只能通过Token化服务才能进行正、反向关联,因此是最安全的方案。但这个方案的缺点是,为保证Token的高度一致性,新token生成逻辑不能并发,否则会出现一对多的一致性问题。为保证数据一致性,将牺牲一定的分布式能力、性能。无形增加了可用性风险,尤其是远程异地场景。

图7:token化生成方法2

2.MAC方式 :通过统一的加盐哈希HMAC算法,任何进程、任何位置都能生成相同的token,保证一致性。生成后的token与明文的映射关系落表,实现反token化能力。该方式优点是可以跨地域实现分布式,缺点是牺牲了一定的安全性。攻击者一旦获得了盐,就可以用算法批量计算token。我们可以通过对盐采取适当的保护机制(采用与加密密钥相同保护策略),可以获得安全与可用性的平衡。

图8:token化生成方法3

3.确定性加解密:通过确定性加密算法,如(AES-SIV),或者格式保留加密(FPE),将明文加密,生成可逆Token。该算法破坏了加密的安全技术-随机性,目前的算法普遍存在漏洞,不建议使用。此外,该算法还存在一个天然的漏洞,就是密钥无法轮换。

3.4 Token化方案逻辑架构

图9: Token化逻辑架构图

Token化服务需要满足全业务场景兼容性、安全性和可用性,主要通过多种接入集成方案。并集成必要的安全措施。token化服务按逻辑分为接入层、服务层和存储层。

1.接入层:主要用来对接业务应用和人员访问,完成Token与明文之间的转换即Token化和反Token化请求需求。分别提供人机接口(Portal)、服务接口(API)调用和大数据任务请求。由于Token化安全要求,接入层需要保证可靠的安全措施,如细粒度访问控制、IAM、服务鉴权和大数据作业鉴权能力。

2.服务层:实际执行Token化和反Token化的行为。主要是完成token的生成、存储以及查询。

3.存储层:存储层主要包含线上存储和数仓。由于安全性考虑,Token化映射表并不存储明文而是保存加密后的密文。同时,通过HMAC算法建立HASH >token >密文的关联关系实现明文换token(正查)和token换明文(反查)的业务逻辑。注意,应用并不能通过Token化直接获得明文,而是获得密文,通过KMS获得解密权限后本地解密获得明文。

3.5 Token化应用全景

图10:Token化数据流通全景

组件说明:

1.线上数据源:敏感数据的主要数据来源,一进入公司需要对接Token化服务API兑换成token,并落库存储。一定场景,数据也会接入数仓。数据源另外角色是向下游提供分享敏感数据,可通过API,MQ,或共享存储如S3等媒介。

2.数仓数据源:直接倒入或来自线上,敏感数据进入数仓,需要启用Token化任务,将明文转换成token,并随后向下游其他大数据应用提供。

3.Token化服务:

a)Token化线上服务通过API为线上交易、事实任务提供明文换token服务;

b)Token化离线hive,为大数据任务提供离线数据清洗服务,将明文转换成token。

4.KMS和加解密:

a)为Token化派发加密密钥,并将明文加密形成密文字段;

b)为所有具有解密权限应用派发解密密钥,进行解密。

5.数据应用:

a)常规中间应用:基于token就能完成业务功能的服务。从数据源获取token,并向下游传递;

b)解密应用:按业务需求,满足安全基线前提下,用token换取密文,并对接加解密模块进行解密,获取明文。

四、Token化安全性实现

4.1 Token化的安全精要

Token化安全性假定就是Token和明文的无关性,如果任何一个人或系统非法保存、构造了一份Token与明文的对照字典或者具有构造这个字典的能力,Token化的安全机制就彻底破坏了,因此Token化安全的核心就是防止这个表的生成。

4.2安全风险和安全性设计

1.Token化服务本身安全风险和控制:

a)Token生成逻辑安全:随机token生成的唯一ID是最安全方式,需要采用可信的随机数生成器,条件允许可采用基于硬件的密码机生成随机数。如通过软件实现,需要采用基于加密的伪随机数生成机制。如果采用HMAC方式生成,需要确保盐的安全。

i. 只能通过KMS等可信机制进行创建、分发和存储;

ii. 只能在Token化服务运行时内使用;

iii. 定期进行盐的轮换,建议每日,或每周,用过的盐进行安全删除;

iiii.确保采用安全的hash算法,如SHA-256或SM3。

b)Token化运行时安全:Token化服务采用专用系统,并且进行过特殊加固。

c)Token化存储安全:考虑到大数据场景以及多种存储需求,要求Token化存储本身不保存敏感信息,只包含索引、Token 和密文。同时,token化存储需要进行严格的访问控制。

d)Token化接入安全:

i. API需要进行可靠的服务鉴权,建议MTLS + Oauth2 票据,同时启用访问日志审计;

ii. Token 换明文逻辑只返回密文,由请求服务利用KMS本地进行解密,集中控制解密权限;

iii. UI提供用户人工进行token与明文,加解密的能力。要求必须经过IAM,并支持基于ABAC的细粒度、基于风控的访问控制。

2.生态上下游服务、应用产生的次生安全:不论数据源,还是下游的明文数据消费方,因具有token化接口访问授权, 技术上是可以远程调用接口,遍历出全量的token和明文的映射关系。因此安全措施需要延伸到这些系统和用户,保证不会因为这些错误行为或程序漏洞导致的数据泄漏。

a)构建数据应用安全基线,约束上下游数据使用行为;

b)严格禁止任何形式的非法明文,尤其是token与明文的映射关系数据转发转存行为;

c)禁止设置代理,必须由数据服务主体直接对接Token化服务;

d)所有生态系统必须进行完整的安全评审,包括后续的变更。确保基线合规;

e)对上下游所有的服务,纳入监控体系,包括其存储、数据接口以及应用代码逻辑、血缘;

f)全局监控、扫描,确保所有不合规的处理及时发现、处理。

五、工程实践经验  

Token化服务从设计上并不复杂,一旦实施,将彻底改变组织数据使用习惯,从根本上解决数据使用效率与安全合规间的矛盾。然而,其强大的防护效力是基于对数据使用逻辑的改造,打破旧有的明文数据使用习惯,落地过程面临在巨大的挑战。包括疏于维护应用代码,冗余的、混乱的历史数据、复杂混乱的访问逻辑,这些问题都会为系统改造带来障碍。需要所有涉及敏感数据的业务配合改造,这种规模项目,必须从流程规划、组织保障和技术支撑等多方面统筹,在美团推进公司的改造过程中也积累了大量经验可以进行参考。

1.一致性策略制定与传达:Token化作为公司级数据安全治理战略,需要全局统一认识。从策略要求、具体实现指南、工具方法等都需要清晰一致,并通过简洁的文档,有效的传递给所有相关方,以降低沟通和错误成本。其中解密策略、访问控制策略、API接口策略、大数据、AI等各种数据应用场景的安全基线,都需要完备。此外,通过有效的沟通渠道,包括培训、产品使用手册、接口文档等多种渠道触达到所有的用户、研发和业务人员。

2.化整为零,灵活推进:敏感数据访问链路长、关系复杂,加上治理水平的限制,无形增加了改造难度、心理和实际投入的压力。将改造逻辑单元进行横向、纵向切分,最低可细到服务级,实现碎片化灰度改造,让改造更敏捷。

3.DevOPS化改造:因为Token化改变的是数据使用逻辑,必须由所有业务、研发投入进行。其人力成本巨大,因此将改造的逻辑封装成简单、易用SDK,可以降低改造难度和人为失误导致的风险。此外包括测试、验收,都可以通过自动化扫描、数据清洗、验收和检测工具由业务自助闭环完成。

4.Token化服务能力:改造后Token化将成为部分相关应用的强依赖,Token化的故障和性能问题可直接影响业务应用。因此Token化服务的性能、可用性和稳定性很重要,需要由专业团队精心设计、并不断测试验证、优化,避免导致故障。同时,也需要在安全基础下,提供一定的降级、容错能力。

5.运营与治理:随着项目的推进,token将超过明文成为主流,通过控制住要数据入口,主要数据供应方,能保障token在组织内默认使用,实现默认安全;此外,企业的冷数据、静态数据或者相对独立的孤岛数据依然会形成遗漏和风险。因此需要针对所有数据支撑系统支持扫描,监控等多维度的感知能力。同时将异常数据对应到具体的业务,保证token的全覆盖。

6.学习、改进与迭代:随着数字化创新演进,会不断有新的数据形态、数据应用加入,项目需要应对这种变化,不断从工具、流程上改进,确保长期战略得到保障。

六、未尽事宜

后续,数据安全治理延伸。

数据层面,Token化没有解决类似图片、视频等非结构化数据。可能需要直接通过加密。

Token化没有解决跨企业信任边界的数据交换问题,这部分需要隐私计算、多方安全计算等新技术。

Token化主要对象是存在DB、Hive中的结构化PII信息。对于隐藏的在JSON中的半结构化数据和日志、文件中的非结构化PII数据并没有处理,需要配合强大的数据发现和数据治理工具完成。

在整个数据安全体系中,PII只是沧海一粟,Token化实际上也仅仅解决企业内部数据使用场景,但却开了一个默认安全和设计安全的先河。由于PII信息是个人敏感信息的核心数据,功过Token化,上可以溯源到数据采集、下可以延伸到三方数据交换。此外,通过Token去关联,可以实现无损数据删除等能力。数据安全是一个巨大的课题,尤其是在数字化变革的强大发展需求下,面对纷繁复杂的数据应用,网络安全需要更多的技术创新,我们希望通过Token化抛砖引玉,激发出数据安全的创新之路。

本文由美团安全应急响应中心原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/280321

安全客 - 有思想的安全新媒体

分享到:微信
+10赞
收藏
美团安全应急响应中心
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66