Hi !欢迎阅读《爱彼迎数据隐私与安全工程》系列文章。我们会分为上中下三篇,介绍如何构建功能强大、自动化且可拓展的数据安全技术保障。
随着有关数据泄露的新闻报道日益增多,加上国际监管和安全要求的出台,数据监管与保护已成为备受关注且亟待解决的重要议题。
我们的房东和房客社区相信:爱彼迎会保障用户数据安全,同时尊重用户的隐私权利。
在爱彼迎,数据的收集、存储和传输会通过不同的数据存储和基础设施来完成。工程师很难通过手动跟踪来了解用户及敏感数据在技术环境中的流转过程。其实,这反而会让我们的数据保护难上加难。虽然我们现在有从不同维度保障数据安全的供应商,但我们更希望设计一套理想的数据安全工具,既能支持我们生态系统中的数据存储器,又能满足我们在数据开发和自动化数据保护方面的所有需求。
在《爱彼迎数据隐私与安全工程》系列分享中,我们会和各位展开聊聊:如何通过创建和维护数据安全平台来化解上述挑战。
第一篇文章,我们会快速回顾构建数据保护平台(Data Protection Platform, 以下简称 DPP)的背景和技术架构,并深入解读我们的数据清单组件——Madoka。
数据保护平台DPP
为了打造一个能满足我们实际需求的工具,我们决定构建一个符合国际法律和安全需求的数据保护平台。为了实现数据保护的目标,我们首先需要了解数据相关的安全和隐私风险。
了解爱彼迎的数据
在爱彼迎,我们通过不同的文件格式和数据存储来存储 PB 级别的数据,例如 MySQL,Hive 和 S3。我们的整个生态系统每天都产生、复制和传输数据。为了监控和了解不断变化的数据,我们创建了一个中心化的清单系统(inventory system)持续追踪已有的数据资产。这个清单系统也会收集和存储每个资产的安全和隐私属性相关的元数据,以便爱彼迎的相关人员了解相关风险。
由于某些数据资产可能包含敏感的商业机密或公共信息,了解数据资产中所存储的数据类型对于确定保护需求级别至关重要。此外,诸如欧盟通用数据保护条例(GDPR)、中国的个人信息保护法及配套规定(PIPL)和加州消费者隐私法(CCPA)之类的隐私法也赋予了用户访问和删除他们的个人数据的权利。然而,个人数据的定义并不精确,它包含了很多不同的数据元素,比如电子邮箱地址、在平台上发送的消息、位置信息等。为了符合这些法律法规的要求,我们需要找到这些个人数据的具体位置。因此我们建立了一个可扩展的数据分类系统,用以对我们的数据资产持续地进行扫描和分类,来判断其中所存储的数据类型。
启用自动化数据保护
基于对数据的理解,DPP 努力实现自动化数据保护,或协同各团队来完成数据保护。这种自动化侧重于几个关键领域:数据发现、敏感数据泄漏的防护和数据加密。
发现个人数据是隐私合规的第一步。当用户要求删除或者返还其个人数据的时候尤为重要。当平台在数据处理者的存储中检测到新的个人数据时,能够自动发送通知,并且将此数据与我们的隐私编排服务集成,以确保在用户需要时将其删除或返还给用户。
数据泄露的一个常见原因是敏感信息(例如 API 密钥或登录凭据)在内部泄露,然后落入攻击者之手。这可能源于工程师在服务中将敏感信息记录到日志或提交至代码中。我们的数据保护平台可以识别出各种终端的潜在泄露风险,并通知工程师从代码或日志中删除或者替换敏感信息,然后使用我们的加密工具集隐藏新的机密信息。
最常用且关键的数据保护方法之一就是数据加密,因为即使发生泄漏,攻击者也无法获得敏感数据。然而不幸的是,未加密的敏感数据造成的泄露事件在业内很常见。
为什么会发生数据泄漏呢?因为使用适当的密钥管理进行加密在技术上具有一定的挑战性,并且组织不会一直清楚敏感数据的存储位置。DPP 旨在通过向工程师提供可使用的数据加密服务和客户端库来应对这些挑战。它会自动发现敏感数据,无需手动识别。
平台架构
图1:DPP总览
DPP旨在发现、理解和保护我们的数据。它集成了我们为多维度处理数据保护而构建的服务和工具。这种端到端的解决方案包括:
Inspekt 是我们的数据分类服务。它持续扫描爱彼迎的数据存储来判断里面存储了什么类型的敏感数据和个人一般数据。
Angmar 是我们的密钥检测管道,用来发现我们的代码库中的密钥。
Cipher 是我们的数据加密服务。它为爱彼迎的开发人员提供了一个简单透明的框架,可以很容易地加解密敏感信息。
Obliviate 是我们的编排服务,它处理所有隐私合规请求。例如,当用户请求从爱彼迎删除用户个人数据时,Obliviate 会将此请求转发至所有必要的服务,以从其数据存储中删除用户的个人数据。
Minister 是我们的第三方风险和隐私合规服务,负责处理所有隐私数据主体权利相关的请求,并将其转发至我们的外部供应商。
Madoka 是我们的元数据服务,它会从不同来源收集数据资产的安全和隐私属性。
最后,我们有数据保护服务 Data Protection Service,一个借助来自 Madoka 的信息启用自动化数据保护操作和通知的表示层。(例如,与我们的隐私框架自动集成)。
Madoka:一个元数据系统
Madoka 是一个数据保护的元数据系统,用于维护爱彼迎平台上所有数据资产的安全和隐私相关元数据。它提供了一个集中式的仓库,允许爱彼迎工程师和其他内部相关人员轻松地跟踪和管理其数据资产的元数据。Madoka 在公司的安全和隐私自动化方面发挥了重要作用。由此,我们能够全面了解爱彼迎的数据安全和隐私状况。
图2:Madoka的架构
Madoka 由爬虫和后端两个不同的服务实现,主要承担三大职责:收集元数据、存储元数据和向其他服务提供元数据。Madoka 爬虫是一个每日运行的爬虫服务,它从其他内部数据源获取元数据,包括 Github、MySQL 数据库、S3存储桶、Inspekt(数据分类服务)等,然后将元数据发布到 AWS 简单队列服务(SQS)的队列中。Madoka 后端是一个数据服务,它从 SQS 队列中提取元数据,协调任何冲突信息,并将元数据存储在其数据库中。它能通过为其他服务提供API来查询元数据的结果。
Madoka 收集的主要元数据包括:
数据资产列表
所有权
数据级别
对于上面的每一项,我们都能处理 MySQL 和 S3 的格式。
数据资产列表
需要收集的第一类元数据是爱彼迎所有数据资产的列表及它们的基本元数据,例如 schema 、资产位置和资产类型。
对于 MySQL ,爬虫收集我们的生产 AWS 账户中存在的所有列的列表。它调用 AWS API 以获取我们环境中所有集群的列表及其 Reader 端点。然后,爬虫使用 JDBI 连接到该集群并列出所有数据库、表和列,以及列的数据类型。
爬虫保留以下元数据信息并将其传递给 Madoka 后端进行存储:
集群名称
数据库名称
表名
列名
列的数据类型
对于 S3,爬虫收集我们所有 AWS 账户中存在的所有对象的列表。
在爱彼迎,我们使用 Terraform 在代码中配置 AWS 资源,包括 S3 存储桶。爬虫能够通过解析 Terraform 文件获取 S3 元数据。
爬虫首先获取所有 AWS 账号和名称的列表,这些列表存储在我们 Terraform 代码库的配置文件中。然后它能获取所有存储桶名称的列表,因为每个存储桶配置都是相应账户的子代码库下的一个文件。
为了获取存储桶中的对象列表,爬虫使用了 AWS 提供的工具 S3 清单报告。这个工具可以生成并储存存储桶中包含的所有对象的每日或每周 CSV 文件及其元数据。与调用 List AWS API 相比,这是一种更快、成本更低的列表获取方式。我们在 Terraform 中的所有生产环境的 S3 存储桶上启用了清单报告,并在存储桶配置中指定了清单报告的位置。
爬虫保留以下信息并将其传递给 Madoka 后端进行存储:
帐号
用户名
代入角色名称
存储桶名称
清单存储桶账号
清单代入角色名称
清单存储桶前缀
清单存储桶名称
对象键
所有权
所有权是描述谁拥有特定数据资产的元数据属性。
我们决定收集服务所有权信息,这使我们能够将数据资产链接到特定的代码库,从而自动执行任何需要更改代码的数据保护操作。
我们还决定收集团队成员信息,这对于执行任何需要工程师工作或需要批准变更请求的数据保护行动至关重要。我们选择收集团队所有权而不是用户/员工所有权,因为团队成员会不断变化,但数据资产一直属于团队。
在爱彼迎,由于我们迁移到了面向服务的架构(SOA),大多数 MySQL 集群属于单独某个服务和单独某个团队。为了确定服务所有权,爬虫会获取连接到 MySQL 集群的服务列表,并将过去 60 天内连接数最多的服务设置为该集群中所有表的所有者。为了实现监控、观察或其他常见目的,许多服务都会连接到所有集群来,因此在确定所有权时,我们创建了一个可筛选的角色列表。
仍有一些历史遗留的集群在许多服务之间共享使用,其中每个服务在集群内拥有特定的表。这些集群不能保证所有表都分配到正确的服务所有者,不过我们可以手动纠正这些错误。
在爱彼迎,团队所有权是在 Git 上的服务代码库中定义的。因此爬虫使用服务所有权来确定团队所有权。
在爱彼迎,所有 S3 存储桶在其 Terraform 配置文件中都有一个项目标签,用于定义哪个服务拥有该存储桶。如上文针对 MySQL 所述,爬虫从该文件中获取服务所有权并使用它来确定团队所有权。
数据分类
数据分类是一种元数据属性,用于描述资产中存储的数据元素类型——例如,存储电子邮件地址或电话号码的 MySQL 列将被归类为个人数据。收集数据分类信息使我们能够了解每个数据集的风险,从而确定所需的保护级别。
爬虫会从两个不同的来源获取数据分类。首先,它从我们的 Git 代码仓库中获取数据分类,因为数据所有者可以在他们的数据的 schema 中手动设置分类。然而,仅仅依靠手动分类是不够的。数据所有者可能不太清楚资产包含什么,或者他们可能会在存储新数据元素,更新数据资产时忘记更改分类。
然后,爬虫会从我们的自动化数据分类工具 Inspekt 中获取数据分类,我们会在后面的文章中详细介绍。Inspekt 会持续扫描和分类我们所有的主要数据存储,例如 MySQL 和 S3 。它可以输出从每个数据资产中找到的数据元素。这将确保我们的数据受到持续监控,并且会随着数据的变化而更新分类。与任何自动检测工具一样,准确率和召回率从来都不会是100%,因此可能也会出现误报和漏报。
图3:分类核对
由于爬虫从两个不同的来源获取数据分类,可能会导致一些差异,其中手动分类中会包含 Inspekt 找不到的数据元素,反之亦然。爬虫将所有发现转发到 Madoka 后端,后者将解决一切冲突。手动分类的状态默认标记为“new”,而 Inspekt 分类的状态标记为“suggested”。如果手动分类与 Inspekt 结果一致,则自动确认分类。如果有任何差异,我们会通过数据保护服务向数据所有者开工单。如果 Inspekt 分类正确,所有者可以更新 Git 代码仓库中的数据 schema ,为了解决冲突,他们也可将 Inspekt 分类标记为不正确。
其他安全和隐私相关的属性
Madoka 还会记录数据资产与安全隐私工具的集成情况。例如,对于数据主体权利的请求,我们可能会存储数据资产是否使用 Cipher 加密或是否与我们的隐私合规服务 Obliviate 集成。我们将 Madoka 构建为易于扩展的平台,并不断收集和存储更多与安全和隐私相关的属性。
总结
在《爱彼迎数据隐私与安全工程》系列文章的上篇中,我们概述了构建 DPP 的原因,描述了平台的架构,并深入解读了数据清单组件 Madoka 。我们的中篇文章,将重点介绍我们大规模检测个人和敏感数据的分类系统。在最后一篇文章中,我们将深入探讨如何使用 DPP 来实现各种安全和隐私用例。
作者:Elizabeth Nammour,Wendy Jin,Shengpu Liu,译者:Yang Li,校对:Ting Jiao, Yiqi Jia, Wei Ji
DPP 的实现和顺利应用要感谢爱彼迎数据安全团队、数据治理团队以及所有参与到项目中的成员。
如果你想了解关于爱彼迎技术的更多进展,欢迎关注我们的 Github 账号(https://github.com/airbnb/) 以及微信公众号(爱彼迎技术团队)