数字化新业态下数据安全创新——Token化

数据安全最大的挑战是高速扩张前提下，解决数据暴露性问题。Token化让安全成为数据默认属性，让安全性随数据自动扩展，从根本上解决效率和安全合规的矛盾，实现设计安全和默认安全。本文主要介绍了Token化方案、Token化安全性实现以及美团所做的一些工程实践和经验分享。

0. 引言

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

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

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

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

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

在数字化应用环境下，数据具有如下特征：

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

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

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

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

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

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

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

如上图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生成。

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

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

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

3.4 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化应用全景

组件说明：

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安全，数据安全和隐私合规专家。

阅读美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 安全 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者使用。任何商用行为，请发送邮件至[e-mail]申请授权。