关于美团:数字化新业态下数据安全创新Token化

203次阅读

共计 7808 个字符,预计需要花费 20 分钟才能阅读完成。

数据安全最大的挑战是高速扩张前提下,解决数据裸露性问题。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 年货】等关键词,可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品,著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容,敬请注明“内容转载自美团技术团队”。本文未经许可,不得进行商业性转载或者应用。任何商用行为,请发送邮件至 [email protected] 申请受权。

正文完
 0