【论文阅读-PRIVGUARD】Day3：1-2节

PRIVGUARD: Privacy Regulation Compliance Made Easier（PRIVGUARD：更轻松地遵守隐私规定）

摘要

持续遵守如GDPR和CCPA等隐私法规已经成为从小型创业公司到商业巨头的公司的一项昂贵负担。罪魁祸首是当今合规过程中对人工审核的严重依赖，这既昂贵、缓慢又容易出错。为了解决这个问题，我们提出了PRIVGUARD，一个旨在减少所需人工参与并提高合规过程生产率的新型系统设计。**PRIVGUARD主要由两部分组成：（1）PRIVANALYZER，一个基于抽象解释的静态分析器，用于部分强制执行隐私法规，以及（2）一组在数据整个生命周期中提供强大安全保护的组件。**为了验证这种方法的有效性，我们原型化了PRIVGUARD并将其集成到一个工业级数据治理平台中。我们的案例研究和评估显示，PRIVGUARD能够在实际程序上正确执行编码的隐私政策，并且性能开销合理。

1 引言

随着欧盟的一般数据保护条例（GDPR）和加利福尼亚消费者隐私法案（CCPA）等隐私法规的出现，对用户数据保护的重视达到了前所未有的高度。这对数据主体来说是一个积极的发展，但也给合规带来了重大挑战。当今的合规范式严重依赖于人工审核，在两个方面存在问题。首先，雇佣和培训数据保护人员以及依赖手工努力监控合规是一个昂贵的过程。根据《福布斯》杂志的一份报告，截至2018年5月25日，GDPR已经让美国财富500强公司花费了78亿美元。DataGrail的另一份报告显示，74%的中小型组织为了持续遵守GDPR和CCPA的要求，花费了超过10万美元。其次，人工审核既慢又容易出错。合规的低效率阻碍了数据的有效使用并影响了生产力。合规官员的错误可能会伤害数据主体并导致法律责任。

理想的解决方案将使数据管理员能够轻松地确保细粒度的合规，最小化人工参与，并快速适应隐私法规的新变化。大量学术工作试图解决这一挑战。欧洲ICT PrimeLife项目提议使用Primelife政策语言（PPL）来编码法规，并通过将政策与用户指定的隐私偏好相匹配并在检测到特定行为时触发强制性动作来强制执行它们。A-PPL通过添加问责规则扩展了PPL语言。这两项开创性的工作在高效政策合规探索中发挥了重要作用。然而，由于它们专注于Web 2.0应用程序，它们对于复杂数据分析任务中的细粒度隐私要求合规提供了有限的支持。SPECIAL项目部分继承了PPL项目的设计，因此遭受了类似的限制。与我们的工作最接近的是Sen等人的研究，他们提出了一个隐私政策的正式语言（LEGALEASE）和一个执行这些政策的系统（GROK）。然而，GROK使用启发式方法帮助决定分析过程是否符合政策，需要人工审核来捕捉假阴性。因此，大规模有效地遵守隐私法规仍然是一个重要挑战。

PRIVGUARD-促进合规。本文描述了一个名为PRIVGUARD的原则性数据分析框架，旨在减少合规过程中的人工参与。PRIVGUARD在密码工具和**可信执行环境（TEEs）**的保护下，通过一个五步流程工作。

首先，数据保护官员（DPOs）、法律专家和领域专家协作将隐私法规翻译成机器可读的策略语言。翻译过程是特定于应用的，并且需要应用和隐私法规两方面的领域特定知识（例如，将法律概念映射到具体字段）。编码后的政策被称为基础政策。编码基础政策是PRIVGUARD工作流中人力投入最多的步骤。

其次，在数据被收集之前，数据主体通过客户端API的帮助来指定他们的隐私偏好。他们可以直接接受基础政策或添加自己的隐私要求。隐私偏好与数据一起被收集。

第三，数据分析师提交程序来分析收集的数据。分析师需要提交一个不弱于基础政策的相应守护政策以及他们的程序。只有政策不强于守护政策的数据才能被使用。

第四，我们提出的静态分析器PRIVANALYZER检查分析程序，以确认其是否符合守护政策。同时，将加载隐私偏好不强于守护政策的数据子集来进行真正的分析。

最后，根据PRIVANALYZER的输出，结果要么被解密给分析师，要么由剩余未满足的隐私要求（称为残余政策）保护。

LEGALEASE扩展：编码政策。PRIVGUARD旨在与多种机器可读的政策语言兼容。在这项工作中，我们使用LEGALEASE实例化我们的实现，因为它具有可读性和可扩展性。我们通过提供新的属性类型扩展了LEGALEASE，包括需要使用隐私增强技术（如差分隐私）的属性。

PRIVANALYZER：执行政策。PRIVGUARD的核心组件是PRIVANALYZER，一个静态分析器，检查分析程序与隐私政策的合规性。PRIVANALYZER通过静态分析分析师提交的程序，以检查它们与相应守护策略的合规性。与依赖访问控制或手动验证[的先前方法不同，PRIVANALYZER是一种基于抽象解释[49]的新颖政策执行机制。PRIVANALYZER不依赖于启发式方法来推断政策或程序语义，并且为某些属性提供可证明的健全性。PRIVANALYZER仅检查程序和政策（而不是数据），因此使用PRIVANALYZER不会泄露其保护的数据内容。我们的方法适用于通用编程语言，包括那些具有复杂控制流、循环和命令式特征的语言。因此，PRIVANALYZER能够分析分析师所编写的程序——这样分析师就不需要学习新的编程语言或改变他们的工作流程。我们使用Python实例化我们的实现，Python是用于数据分析的最广泛使用的编程语言之一。

我们用大约1400行Python代码实现了PRIVANALYZER，并将其集成到一个工业级数据治理平台中，以原型化PRIVGUARD。我们在23个开源Python程序上实验性地评估了原型，这些程序执行数据分析和机器学习任务。所选程序利用了像Pandas、PySpark、TensorFlow、PyTorch、Scikit-learn等流行库。我们的结果表明，PRIVGUARD是可扩展的，并且能够分析未修改的Python程序，包括广泛使用外部库的程序。

贡献。简而言之，本文做出了以下贡献。
• 我们提出了PRIVGUARD，一个新颖的框架，用于最小化人力努力以遵守隐私法规。
• 我们提出了PRIVANALYZER，一个基于抽象解释的静态分析器，用于在未修改的分析程序上执行隐私政策。
• 我们为LEGALEASE和Python实现了PRIVANALYZER，大约1400行Python代码。我们的实现支持常用的分析库，如Pandas、Scikit-learn等。
• 我们通过将PRIVANALYZER集成到PARCEL中，一个工业级数据治理平台，原型化了PRIVGUARD。我们模拟了PRIVGUARD执行，处理高达一百万客户端，结果显示PRIVGUARD在处理一百万客户端时大约产生两分钟的开销。

2 PRIVGUARD概览

在本节中，我们将概述PRIVGUARD的设计和实现。首先，我们通过一个简单的示例来介绍PRIVGUARD，然后介绍系统设计和实现。最后，讨论PRIVGUARD的威胁模型和安全性。

2.1 一个简单的示例

我们使用一个简单的示例来展示PRIVGUARD的工作流程，这也让我们能够介绍所使用的主要组件。一家公司推出了一款手机应用，并收集用户数据以帮助做出明智的商业决策。为了促进遵守隐私法规，公司部署了PRIVGUARD来保护收集到的数据。

首先，数据保护官（DPOs）、法律专家和领域专家在基础政策中编码了两个要求：（1）未成年人的数据不得用于任何分析；（2）对数据进行的任何统计都应该使用差分隐私来保护。

其次，隐私偏好从数据主体那里收集，同时收集数据。一些数据主体（第1组）信任公司并直接接受基础政策。一些（第2组）更加谨慎，希望在分析前对他们的邮政编码进行编辑。其他人（第3组）不信任公司，并且不希望他们的数据被用于除合法利益之外的目的。

第三，一位数据分析师想要调查用户年龄分布。它指定了一个守护政策，除了基础政策外，邮政编码也不应该在分析中使用。分析师提交了一个计算用户年龄直方图的程序给PRIVGUARD。她记得过滤掉所有未成年人的信息并编辑邮政编码字段，但忘记了用差分隐私保护程序。

第四，PRIVGUARD使用PRIVANALYZER来检查隐私偏好，并将第1组和第2组的数据加载到受信执行环境（TEE）中，因为他们的隐私偏好不比守护政策更严格。PRIVGUARD运行程序并保存结果直方图。然而，在检查程序和守护政策后，PRIVGUARD发现程序未能使用差分隐私保护直方图。因此，直方图被加密，转储到存储层，并由一个残留政策保护，该政策指出在结果可以解密之前必须应用差分隐私。

最后，PRIVGUARD将残留政策输出给分析师。分析师在检查残留政策后，提交了一个程序，该程序向直方图添加噪声以满足差分隐私。然后PRIVGUARD解密直方图，将其加载到TEE中，并执行程序对其添加噪声。这次，PRIVGUARD发现守护政策中的所有要求都得到了满足，因此它将直方图解密并提供给分析师。

2.2 系统设计

基础政策编码。编码基础政策是PRIVGUARD工作流中最需要人类参与的步骤。基础政策应由数据保护官（DPOs）、法律专家和领域专家协作设计，以准确反映隐私法规的最低要求。注意，每次数据收集只需要一个基础政策，并且可以在所有数据分析中重复使用。基础政策的目的有二。首先，基础政策的文本版本应在数据主体选择加入数据收集之前呈现给他们，作为最低隐私标准。其次，在进行分析之前，数据分析师需要理解基础政策。如果他们的分析满足更严格的隐私标准，他们可以指定自己的守护政策以利用更多用户数据。

ALLOW ROLE
     Physician
ALLOW SCHEMA
     HealthInformation
AND FILTER age < 90
AND REDACT zip
(a) General encoding.

ALLOW ROLE
    Physician
ALLOW SCHEMA
     SerumCholestoral
AND FILTER age < 90
(b) Concrete encoding.

我们使用HIPAA安全港方法的一个子集来演示编码过程。DPOs和法律专家首先以一种不考虑具体数据格式的通用方式编码法规。如图所示，第一条款（第1-2行）允许患者的医生查看其数据。第二条款（第3-7行）代表了一些安全港要求：如果主体年龄在90岁以下且移除了邮政编码，则可以释放健康信息。然后，DPOs和领域专家通过引入实际架构并移除不必要的要求，将编码映射到具体的数据收集上。例如，在图1b中，HealthInformation被替换为数据集中的一个具体列名SerumCholestoral，并且由于数据集不包含邮政编码，最后一个要求被移除。

数据与隐私偏好收集。除了基础政策外，数据主体还可以指定额外的隐私偏好来行使其限制处理的权利。这些隐私偏好与数据一起发送到数据管理者，它们将一起保存在存储层中。为了防止在传输和存储过程中的攻击，数据在发送到数据管理者之前被加密。解密密钥被委托给密钥管理器以供将来解密（参见第2.3节）。

一个自然的问题是：“在LEGALEASE中指定隐私偏好需要多少专业知识？”Sen等人针对DPOs进行了一项调查，并发现大多数经过培训后能够正确编码政策。为了补充他们的调查并更好地了解需要多少专业知识，我们进行了一项针对没有接受过培训的普通用户的在线调查。调查揭示了两个有趣的事实：（1）理解和编码LEGALEASE政策的难度与用户熟悉其他编程语言之间存在显著的正相关性；（2）大多数用户在没有接受培训的情况下无法正确理解诸如差分隐私等隐私技术。根据这些观察结果，我们强烈建议没有编程经验的用户直接接受基础政策，而不是编码自己的政策。虽然超出了范围，但我们认为未来简化隐私偏好规定的方向是非常重要的，可以通过开发更加用户友好的用户界面和翻译工具来实现。调查的详细信息推迟到附录B中。

分析初始化。要初始化分析任务，分析师需要提交（1）分析程序和（2）一个守护策略给PRIVANALYZER。守护策略不应弱于基础政策以满足最低隐私要求。守护策略越严格，可以用于分析的数据就越多。

PRIVANALYZER分析。在收到提交后，PRIVANALYZER将从存储层加载隐私偏好并将其与守护策略进行比较。只有符合守护策略要求不严格的数据才会被加载到TEE中，使用来自密钥管理器的密钥进行解密，并合并以准备进行实际分析。与此同时，PRIVANALYZER将（1）检查守护策略是否不弱于基础政策（2）检查守护策略和程序以生成剩余策略。为了确保静态分析正确运行，PRIVANALYZER被保护在一个受信任的执行环境（TEE）中。

合规性执行实际上依赖于三个检查：（1）守护策略>=基础策略；（2）隐私偏好<=守护策略；（3）在去标分类之前必须满足守护策略。对于（3），守护策略可以通过单个程序或通过顺序应用于数据的多个程序来满足。这种设计赋予了PRIVGUARD在多步骤分析中执行隐私政策的能力。

执行与去标分类。在PRIVANALYZER完成其分析后，提交的程序将在TEE内部使用解密后的数据执行。如果前一步生成的剩余政策为空，则结果可以向分析师去标分类。否则，输出将再次被加密并存储在受剩余政策保护的存储层中。

细心的读者可能会问：“为什么PRIVGUARD不直接拒绝不符合守护政策的程序？”这种设计选择是由两个考虑因素驱动的。首先，当守护策略包含ROLE或PURPOSE属性时，不总是可能得到一个空的剩余政策。这些属性将在真实数据分析后通过人工审计来满足。第二，PRIVGUARD旨在与多步骤分析兼容，这在现实世界的产品流水线中是一个常见的情况。在多步骤分析中，隐私要求可能在不同的步骤中得到满足。

2.3 系统安全

在本节中，我们将介绍威胁模型，并展示如何在该威胁模型下保护PRIVGUARD的安全。

威胁模型。我们的设置涉及四方 - （1）数据主体（例如，用户），（2）数据管理者（例如，网络服务提供商、银行或医院），（3）数据分析师（例如，数据管理者的雇员），和（4）不受信任的第三方（例如，外部攻击者）。

数据从数据主体那里收集，由数据管理者管理，并由数据分析师分析。数据主体和数据管理者都希望遵守隐私法规，以保护他们自己的数据或避免法律或声誉风险。然而，数据分析师虽然诚实但鲁莽，可能会无意中编写违反隐私法规的程序。数据分析师与数据互动的唯一方式是提交分析程序并检查输出。不受信任的第三方可能会积极发起攻击，以窃取数据或干扰合规过程。一个具体例子是托管小公司服务或数据的云提供商。我们在以下两个假设下保护数据的保密性和执行的完整性。首先，我们假设不受信任的第三方无法向PRIVANALYZER提交分析程序或让内部人士这样做。其次，我们假设不受信任的第三方符合所选择的TEE的威胁模型，因此他们不能破坏TEE的安全保证。

安全措施。PRIVGUARD采取以下措施，以防御不受信任的第三方并在上述威胁模型下建立安全的工作流程。

首先，数据在传输给数据管理者之前由数据主体本地加密。解密密钥委托给密钥管理器，因此没有人可以在不请求密钥管理器或数据主体的解密密钥的情况下有意或无意地接触数据。为了以不可变的方式绑定数据和策略，加密数据包含相应策略的哈希值。

其次，所有传输通道满足传输层安全标准（TLS 1.3）。

第三，PRIVANALYZER在TEE内运行，以保证静态分析的完整性。密钥管理器可以远程认证，以确认PRIVANALYZER在发放解密密钥之前正确检查了程序和策略。

第四，数据解密和分析程序执行也在TEE内受到保护。

PRIVGUARD针对不受信任第三方的安全性基于以下信任来源。首先，数据的保密性和完整性在TEE和TLS通道内得到保留。其次，代码执行的完整性在TEE内得到保留。远程认证可以正确且安全地报告执行输出。第三，密钥管理器完全可信，从而保留了解密密钥的保密性。信任的密钥管理器的设计与本文的重点正交。潜在的解决方案包括TEE内的密钥管理器或去中心化的密钥管理器。