示例架构:使用 DLP 代理查询包含敏感数据的数据库

此文档介绍使用 Cloud Data Loss Prevention (Cloud DLP) 减轻存储在 Google Cloud 数据库中的敏感数据泄露给用户的风险,同时仍保证用户能够查询有意义的数据。

敏感数据可能存在于整个企业中。企业收集、处理和共享的数据可能包含需要遵守内外部政策或法规的信息,例如个人身份信息 (PII)。除了采用适当的安全控制措施来限制对敏感数据的访问之外,您还可以使用这些技术来帮助保护使用中的数据。去标识化通过使用数据遮盖分桶令牌化等技术,在数据的使用和隐私之间达到平衡。

令牌化将敏感数据替换为称为“令牌”的代理值,当用户查询或查看原始(最初)敏感数据时,令牌将代表这些数据。此过程有时也称为“假名化”(pseudonymization)或“代理替换”(surrogate replacement)。令牌化的概念广泛用于金融和医疗保健等行业,以帮助降低使用数据的风险、缩小合规工作范围,并最大程度地避免敏感数据暴露给无关的人或系统。

使用 Cloud DLP,您可以批量和实时地对敏感数据进行分类和去标识化。“分类”是指找出敏感信息并确定其类型的过程。本文档介绍您在什么情况下可以采用这些去标识化技术,并展示如何使用代理来完成这些任务。

下图展示了本文档中概述的场景。

存储在 Cloud Storage 中的数据的架构,这些数据通过 ETL 过程提取,然后被用户查询。

  • 数据静态存储在 Cloud Storage 中。例如,从合作伙伴处接收的数据。
  • 数据通过提取、转换和加载 (ETL) 过程提取到一个 SQL 数据库中。
  • 用户查询此数据库中的数据以执行分析。

在此场景中,从查询中返回的数据是原始数据,因此会显示敏感数据,有可能会向运行此查询的用户显示 PII 数据。您应为应用采用适当设计,审核和阻止对敏感数据的未经授权的查询。

DLP 代理架构

保护 PII 数据的一种方法是通过一种服务传递所有查询和结果,此服务使用 Cloud DLP 解析、检查数据,然后记录发现结果或对查询结果去标识化,然后再将请求的数据返回给用户。在本文档中,此服务称为“DLP 代理”

DLP 代理应用接受 SQL 查询作为输入,在数据库上运行查询,对查询结果运行 Cloud DLP,然后再将结果返回给请求数据的用户。

下图展示了 DLP 代理应用的架构。

使用数据转换命令的 DLP 代理应用的构架。

Cloud DLP 允许详细地配置要检查什么类型的数据,以及如何根据检查的发现结果或数据结构(例如字段名称)对数据进行转换。为了简化配置的创建和管理,可以使用 Cloud DLP 模板。DLP 代理应用会同时用到检查去标识模板。

利用 Cloud DLP,您可以通过模板创建和持久保存配置信息。模板可用于将配置信息(例如检查什么内容和和如何去标识化)与请求的实现分离。如需详细了解模板信息,请参见 Cloud DLP 模板

Cloud Audit Logs 是 Google Cloud 提供的用于这一架构的集成式日志记录服务。首先,Cloud Audit Logs 提供对 DLP API 的调用的审核跟踪。审核跟踪日志条件包括的信息有:谁发出了此 API 调用、调用针对哪个 Cloud 项目运行以及关于请求的详细信息,包括请求中是否使用了模板。其次,如果使用应用的配置文件来开启审核,Cloud Audit Logs 会记录检查发现结果的汇总信息。

Cloud Key Management Service (Cloud KMS) 是 Google Cloud 提供的云托管密钥管理服务,可管理云服务的加密密钥。

Cloud DLP 用于令牌化日期偏移的方法使用加密来生成替换值。这些加密方法使用密钥以一致的方式对值进行加密以保持引用完整性,或对可逆向方法进行去令牌化。您可以在发出调用时直接向 Cloud DLP 提供此密钥,或者可以使用 Cloud KMS 封装此密钥。在 Cloud KMS 中封装密钥提供了额外一层的访问控制和审核,因此是生产环境部署的首选方法。

在生产配置中,您应采用最小权限原则来分配权限。以下图表展示了此原则的示例。

带有三个职能角色及其权限的生产配置。

上图显示了在典型的生产配置中,三个具有不同权限角色的职能角色如何访问原始数据:

  • 基础架构管理员:安装和配置代理,使它们能够访问安装了 Cloud DLP 代理的计算环境。
  • 数据分析师:访问连接到 DLP 代理的客户端。

  • 安全管理员:将数据分类、创建 Cloud DLP 模板,以及配置 Cloud KMS。

如需详细了解如何使用 Cloud KMS 加密和解密数据,请参阅加密和解密数据。如需详细了解如何使用封装的密钥,请参阅 deindentification.java 代码示例

对于本文档中使用的 DLP 代理,此信息全部配置在 Cloud DLP 去标识化模板中。

利用审核、遮盖和令牌化保护 PII

有两种策略可以减轻这种场景下暴露 PII 的风险。

原始数据存储在数据库中

如果应用在数据库中存储原始数据,则可以使用 DLP 代理自动检查数据并生成任何敏感发现结果的审核,来处理向用户返回的结果。或者您可以实时遮盖查询结果,如下图所示。

对查询结果进行实时遮盖的架构。

此配置要求您使用连接到 DLP 代理的 SQL 客户端。如果在应用上启用审核,则 Cloud Audit Logs 中会创建一个日志,其中包含检查结果的摘要信息。此摘要指出查询中返回了哪种类型的敏感信息。

以去标识化的形式存储的数据

如果您不想存储原始数据,则可以通过去标识化或遮盖形式存储应用的数据,具体方法是在数据进入到数据库的 ETL 过程中执行去标识转换,如下图所示。

在 ETL 过程中遮盖查询结果的架构。

上图展示了基本流程,在这种架构中,数据先接受检查和遮盖,然后才提取到数据库。如果用户查询此数据,即使他们对数据库拥有原始访问权限,也只能看到遮盖后的版本。

如果您允许用户看到未经遮盖的数据,则需要使用一个可以连接到 DLP 代理(此代理有权限将数据去除遮盖)实例的客户端,如下图所示。

使用客户端连接到 DLP 代理来查看去除遮盖的数据的架构。

上图展示了如何使用客户端来连接到 DLP 代理,以实现向客户端显示去除了遮盖的数据。

后续步骤