0. 引言

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

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

由此可见,唯有转变思路,勇于创新,才能化危为机,长远发展。我们要认清转折趋势:数字化时代从上半场粗放、低效,大水漫灌式碳增长,向基于高效数据管理、治理能力的高质量、高效率的数据碳中和转变。企业要在这个转变中生存并脱颖而出,科技创新是重要的抓手,而重点是把握两大核心思想:

  1. 需要认清强大数据应用生产力特征,积极进行技术改造,充分利用先进的数据管理技术手段,提高数据使用效率和治理水平。
  2. 深入学习、理解隐私合规的目的和本质,遵循“可用、不可见”的核心思想,实现效率与治理的统一。

1. 数据科技对安全的挑战

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

  1. 数据的流动性与开放性:按数字经济学理论,数据要想创造出商业价值,就必须做到低成本、大规模供应,高效流动。如果利用传统网络安全最小化、层层审批、层层设防,将严重限制数据生产的活力。此外,在数据流经的每一个节点都达到高级的防护基准,起成本也是组织无法承受的。
  2. 数据的可复制性和失控性:数据作为流动资产,一旦被访问后其控制权将被转移,供应者将失去对它的管控。传统的信任边界在数据应用中也越来越模糊,这些都让集中安全策略在新型数据架构下落实起来成本巨大,收效甚微。
  3. 数据形态多变、应用复杂:数据将在几乎所有IT系统中传递、存储和处理,其复杂程度超乎想象。加之AI、机器学习以及各类创新型数据应用,让数据使用逻辑更难以琢磨,要想了解数据的全貌几乎是不可能的任务。
  4. 数据威胁复杂多变:数据的巨大商业价值让包括黑、灰产业链,内、外部人员乃至商业、国际间谍都趋之若鹜。攻击技术、动机层出不穷,防不胜防。

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

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

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

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

2. Token化-数字世界银行体系

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

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

图3 Token化的数据暴露性

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

图4 Token化后数据纵向暴露性

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

3. Token化方案介绍

3.1 什么是Token化

Token化(Tokenization)是通过不敏感的数据等价替代物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化逻辑示意图

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

图6 Token化生成方法1

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

图7 Token化生成方法2

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

图8 Token化生成方法3

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换取密文,并对接加解密模块进行解密,获取明文。

4. Token化安全性实现

4.1 Token化的安全精要

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

4.2 安全风险和安全性设计

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

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

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

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

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

④ 确保采用安全的Hash算法,如SHA-256或SM3。

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

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

d)Token化接入安全

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

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

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

2. 生态上下游服务、应用产生的次生安全

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

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

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

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

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

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

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

5. 工程实践经验

Token化服务从设计上并不复杂,一旦实施,将彻底改变组织数据使用习惯,从根本上解决数据使用效率与安全合规间的矛盾。

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

  1. 一致性策略制定与传达:Token化作为公司级数据安全治理战略,需要全局统一认识。从策略要求、具体实现指南、工具方法等都需要清晰一致,并通过简洁的文档,有效的传递给所有相关方,以降低沟通和错误成本。其中解密策略、访问控制策略、API接口策略、大数据、AI等各种数据应用场景的安全基线,都需要完备。此外,通过有效的沟通渠道,包括培训、产品使用手册、接口文档等多种渠道触达到所有的用户、研发和业务人员。
  2. 化整为零,灵活推进: 敏感数据访问链路长、关系复杂,加上治理水平的限制,无形增加了改造难度、心理和实际投入的压力。将改造逻辑单元进行横向、纵向切分,最低可细到服务级,实现碎片化灰度改造,让改造更敏捷。
  3. DevOPS化改造:因为Token化改变的是数据使用逻辑,必须由所有业务、研发投入进行。其人力成本巨大,因此将改造的逻辑封装成简单、易用SDK,可以降低改造难度和人为失误导致的风险。此外包括测试、验收,都可以通过自动化扫描、数据清洗、验收和检测工具由业务自助闭环完成。
  4. Token化服务能力:改造后Token化将成为部分相关应用的强依赖,Token化的故障和性能问题可直接影响业务应用。因此Token化服务的性能、可用性和稳定性很重要,需要由专业团队精心设计、并不断测试验证、优化,避免导致故障。同时,也需要在安全基础下,提供一定的降级、容错能力。
  5. 运营与治理:随着项目的推进,Token将超过明文成为主流,通过控制住要数据入口,主要数据供应方,能保障Token在组织内默认使用,实现默认安全;此外,企业的冷数据、静态数据或者相对独立的孤岛数据依然会形成遗漏和风险。因此,需要针对所有数据支撑系统支持扫描,监控等多维度的感知能力。同时将异常数据对应到具体的业务,保证Token的全覆盖。
  6. 学习、改进与迭代:随着数字化创新演进,会不断有新的数据形态、数据应用加入,项目需要应对这种变化,不断从工具、流程上改进,确保长期战略得到保障。

6. 未尽事宜

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

在数据层面,Token化没有解决类似图片、视频等非结构化数据。可能需要直接通过加密。Token化没有解决跨企业信任边界的数据交换问题,这部分需要隐私计算、多方安全计算等新技术。Token化主要对象是存在DB、Hive中的结构化PII信息。对于隐藏的在JSON中的半结构化数据和日志、文件中的非结构化PII数据并没有处理,需要配合强大的数据发现和数据治理工具完成。

在整个数据安全体系中,PII只是沧海一粟,Token化实际上也仅仅解决企业内部数据使用场景,但却开了一个默认安全和设计安全的先河。由于PII信息是个人敏感信息的核心数据,功过Token化,上可以溯源到数据采集、下可以延伸到三方数据交换。此外,通过Token去关联,可以实现无损数据删除等能力。

数据安全是一个巨大的课题,尤其是在数字化变革的强大发展需求下,面对纷繁复杂的数据应用,网络安全需要更多的技术创新,我们希望通过Token化“抛砖引玉”,激发出更多数据安全的创新之路。

7. 本文作者

志刚,美团安全架构师,密码学、云原生和DevOPS安全,数据安全和隐私合规专家。