近日，欧盟网络安全局（ENISA）发布《管理个人数据共享》通过研究与个人数据共享有关的具体用例（主要聚焦卫生部门）并讨论具体技术和实施方面的考虑如何支持满足具体的数据保护。报告展示通过设计具体的技术，以实现保护隐私的数据共享。进而支持政策制定者、监管者和数据保护从业者，并在ENISA根据《网络安全法》（CSA）的任务范围内进行，以支持成员国与数据保护和隐私有关的欧盟政策和法律的具体网络安全方面。
数据共享可以被认为是向组织外的第三方披露数据，以达到特定的目的。这种共享既可以作为处理操作的一部分，也可以在试图为现有数据提供额外效用时进行。最近欧盟促进数据共享的立法倡议是部门和跨部门的文书，旨在通过规范公共和私人持有的数据（包括个人数据）的再利用来提供数据。它们还通过创建新的中介机构和共享环境来促进数据共享，在这些环境中，相关各方可以以一种可信和安全的方式汇集数据和设施。
卫生部门的数据共享实践
对数据共享构成机遇的领域无疑是卫生部门。共享健康数据可以加强公共和私营医疗实体之间的协调和合作，以提供有效的个性化医疗援助和实现公共卫生目标，以及开展科学研究。卫生部门的数据共享也具有跨境性，这一点在《跨境医疗指令》和目前的《欧盟健康数据空间》提案中得到了确认。然而，由于GDPR第95条规定的健康数据的敏感性质，以及由于要确保数据的安全性而产生的若干个人数据保护风险。
健康数据包括生物医学数据、电子健康记录，以及个人产生的数据。在为各种目的共享健康数据的情况下，需要有效解决以下属性或要求：
用于诊断和治疗单个病人的数据可识别；
用于（可能是大规模的）医学研究的（相同的）数据应该被适当地假名化，以确保研究者不可能重新识别，以及有能力消除用于不同目的的两个不同数据集间的联系；
具备处理多来源的患者数据的能力，包括可穿戴设备和应用程序；
应强调的是，数据最小化的必要性在横向上跨越了这三项要求。其他需要到位的数据保护要求是对数据主体的透明度和数据安全。
01 用户控制的个人数据共享
确保用户透明度的基本方法是使用户能够管控数据访问者、访问时间和数据访问权限。因此，在这种由用户控制的数据共享方式中，用户的作用可以被认为是确保满足上述数据保护要求的"保障"。从法律角度看，这种方法是在用户明确同意的情况下，以无法克服的方式实现数据共享；除非用户明确同意访问，否则任何实体都不允许获得用户的健康数据。
示例场景：用户A使用可穿戴设备进行持续的葡萄糖监测（CGM），同时也监测血压、咖啡因及乳酸水平。设备将收集到的数据流上传到云端进行存储，并由用户或其他实体进一步处理，如下图1所示。从数据保护的角度来看，主要的挑战是用户如何有选择地与特定各方分享设备产生的特定数据流。
图1：用户控制的数据共享的通用模型
这种访问模式不仅可以基于请求访问的实体的身份，还可以基于额外的参数，如数据产生的时间段。实现上述目标的简单方法是使用非对称加密。用户A用相关接收者的公钥对数据进行加密，并按以下图2所示分享数据。换句话说，每段要被第三方读取的数据都被A的公钥加密（同样，如果数据要被用户自己访问，则用用户的公钥加密）。
图2：通过非对称加密实现用户控制的数据共享
然而，此方法在实用性和效率方面存在局限性。如需与多实体共享相同的数据，用户需要多次共享相同的数据，并使用相关实体的公钥进行加密。易导致了冗余。此外，潜在接收者不能提前预知，因此，对于每一个新的访问，都要进行新加密。
基于属性的加密技术
克服上述限制的加密技术是基于属性的加密（Attribute Based Encryption，ABE）2004年首次以基于身份的模糊加密这一术语被引入。ΑΒΕ是非对称加密的一个特例，数据可以用ABE公钥加密，但同时，与"经典"公钥加密相反，可能有一个以上的解密密钥，每个密钥都与数据相关的小块附加信息绑定，这些信息被称为属性。解密密钥实际上是由一个通用的ABE主秘钥产生的，它应该保持私有。
图3：将加密的对象存储到云端
用户数据是由其设备产生的，并被分配给相关的对象，描述与之相关的具体属性，如产生的日期、对象的类型等。这些属性随后将被用于定义这些数据的访问控制机制。然后用ABE主密钥对数据进行加密，再上传到云端。
图4：共享ABE解密密钥和加密的数据
当第三方要求访问用户的数据时，用户A为该方创建访问策略。策略指定了确切的属性，基于已经定义的属性，应该被其想授予访问权的数据所满足。然后，用户的设备"翻译"该策略，如fileType="bloodpressure" AND year>=2021 AND recipient="Doctor D"，转变为相应的ABE解密密钥，并将该密钥发送给该方。一旦医生D收到该解密密钥，将能够在本地只解密满足用户定义的访问策略的相应数据。
代理重新加密
另一个允许用户控制数据共享的先进加密技术是代理重新加密（PRE）。这是一种特殊类型的非对称加密，可以将已加密的数据集从一个公开密钥重新加密到另一个，代理机构无法访问未加密的数据集。进一步阐述前面描述的用例，用户A用私人公钥对数据进行加密并上传到云端。当第三方（医生D）要求访问数据时用户私钥和医生的D公钥生成一个再加密密钥。重新加密的密钥可以被发送给云提供商，云提供商现在能够将最初的加密数据集转化为一个新加密数据集，对应于通过医生D的公共密钥进行加密，如下图5所示。
图5：代理重新加密过程
PRE允许在一个用户控制的数据共享中进行加密的访问控制。模型。此外，它允许数据所有者在数据被加密后委托访问。这是非常重要的，因为在一个典型的共享场景中，它可能并不总是能够事先确定收件人的实体。
02 医疗服务提供者为医疗和研究目的共享健康数据
卫生部门另一个典型的数据共享情况是医疗机构对电子健康档案的管理。广义上讲，电子健康档案是病人病历的电子版本。EHRs通常在国家一级的中央储存库管理，用户可以授权治疗医生或医疗机构访问他们的数据。在大流行期间，对大规模数据收集项目的需求变得更加明显，试图不仅支持对病人的治疗，也支持科学研究和预后。
图6：大规模的数据收集实例
通常情况下，为了解决适用的数据保护问题，医疗中心部署适用于内部和外部用户的访问 控制机制，适用于内外部用户，以确定谁可以访问数据和/或对存储数据进行加密。其目的是为了确保只有授权的医疗服务提供者可以访问个性化的信息。当数据为研究目的与内部或外部研究人员共享时，应进一步部署适当的保障措施，在一个典型的情况下，包括假名伪装，以避免向接收者披露病人身份，如图6。
多态性加密和假名化
在多态性加密的优势基础上，多态加密和假名化(PEP)被提出来作为解决相关挑战的手段。多态加密的主要特性是，个人数据无需事先解密数据权限进行加密，通过对密码文本的转换再行决定，这使得解密可以通过不同的密码钥匙来进行。通过不同的密码钥匙进行解密。这种转换可以以盲目的方式进行，而进行这种转换的一方，即转密者，不能访问未加密的数据集。因此，转码器将加密数据集"转化"为另一版本，以便只有这个接收者能够解密。关于假名化，PEP利用转码器作为假名化实体，如图所示。要求访问个人数据的三方分配不同的假名，从而防止跨多个第三方的假名链接。由于每个接收者都会产生一个新的假名，用于同一病人的假名不能被链接，因此被认为是不可链接的，并保持病人数据的保密性。如下图7所示，当接收者是医生时，转码器对相关病人的健康数据进行重新加密，并将其传送给相关医生。
图7：在大规模的数据收集中使用PEP
需注意的是，对假名数据的处理总是要对个人进行重新识别，要么通过将假名逆转为原始标识符，要么通过剩余可用个人信息对个人重新识别。PEP构成了一种技术，目前被认为是数据保护工程的一种先进的加密技术，并且已经在大规模帕金森病研究中证明了其适用性，并作为荷兰电子身份证计划的一项建议。
使用第三方服务的数据共享
除数据共享的用例，也有二次、非直接数据共享的用例，可能也需要用户执行特定的操作。在这种类型的数据共享中，共享是作为另一个过程或服务的一部分进行的，数据在到达其主要接收者之前通过一些二级渠道或实体进行处理。通常，这种数据共享对用户来说是不透明的。需要由隐私工程师、架构师和开发者来解决。在软件工程的许多方面都存在二次数据共享的例子。表1概述了三个主要领域中的一些此类用例，并对每个用例进行了高层次的描述。
表1：第三方数据共享的部分用例
在研究范围内，重点关注前两个用例，即移动推送通知和认证，这两个用例将被更详细地讨论。
01 移动推送通知
移动推送通知是移动应用和其用户间重要沟通渠道。使用推送信息，移动应用提供商可以即时向其用户发送信息。推送通知可以为用户提供来自应用程序提供者的及时信息，并有可能促使后者做出反应。移动推送通知可以传输不同类型的内容，如文字、图片、外部和应用内链接等。除了营销目的之外，推送通知还可以用来触发用户的反应，或者向用户发出信号，让他们提供某种输入，继续进行某种程序或提供某种功能。
在个性化通知的情况下，传输的信息很可能包括个人数据或假名，如用户应用识别码。因此，需要整合额外的技术和组织措施，以解决下文所述的对隐私的威胁。目前，推送通知最广泛使用的平台之一是Firebase Cloud Messaging（FCM）跨平台信息传递，它支持两个主要的移动操作系统（iOS和Android）。从工程的角度来看，开发者通常在应用程序中整合第三方提供的代码。尽管对用户来说可能并不透明，但移动推送通知的基础设施至少涉及两个额外的实体，这在移动世界中是其架构的核心。因此，有以下实体见图8。
图8：参与移动推送通知的主要角色
应用服务器（发布者）：典型的应用服务器，它向移动应用用户发送通知给移动端的用户；
通知代理（第三方）：第三方提供推送通知的代理服务给终端用户；
设备平台/操作系统：从通知中介到应用程序的联系需要通过设备的操作系统提供的专用API运行，如Android；
用户代理（移动）：这通常由一个移动应用程序代表，它运行在 用户代理（移动）：这通常由一个移动应用程序代表，它运行在相应的设备平台上，并代表移动用户的软件界面。
图9：e-Health移动推送通知场景中涉及的实体
操作通知服务的第三方从应用服务器接收通知数据，并将这些数据传递给用户代理客户端。因此，与第三方的间接发生了数据共享，这给用户带来了隐私威胁，包括：
可链接性：观察两个实体之间的互动，包括互动的频率、交换的信息类型、以及其他方面；
可链接性：观察两个实体之间的互动，包括互动的频率、交换的信息类型等；
可识别性：识别用户消息；
披露：被推送的信息内容可能被披露，从而违反了保密性，因为在许多情况下，信息是通过第三方清晰地传送的。
匿名通知协议（使用代理机构）
解决上述隐私威胁的方法可以通过使用私人通知协议来完成。该协议通过使用多个匿名化层或代理来实现通知信息的传递。这种方法需要使用一连串的代理，通过这些代理，通知信息在到达终端用户之前可以被混合。这样的协议使移动推送通知服务能够在用户不知道原始发件人和代理节点的情况下向用户发送。代理节点既不知道原始发送者，也不知道最终接收者。
图10：代理机构架构概述
通知信息将被通过一个代理链发送。应用程序提供者将准备消息并选择随机的节点（代理）发送。在这种情况下，存在混合的通知代理服务器。每一个都只知道到下一个经纪服务器的地址，隐藏了两个终端实体的信息。此外，通知服务器（代理）间的通信本身是通过相应的公钥加密的，因此 保护其免受意外的泄露。AnNotify就是相关示例，支持解除对用户的推送通知的链接。无论选择哪种协议，都需考虑对使用该协议的服务的开发和运行的潜在影响，以便提供实际的可行性并被开发者采用。在这方面，有几个不同的标准可以用来评估不同的选择，包括在应用中整合的难易程度、维护的难易程度、可扩展性等。
端对端加密
对通知信息进行加密是最直接的措施，至少可以解决上面提到的一些隐私威胁。目前，推送通知的交付通常不使用端对端加密。要么根本不使用加密，要么只对通信的一部分进行加密。某些情况下，开发者可以决定在应用服务器和通知代理间使用传输层的加密（例如TLS）来传递信息。此外，通知代理可以选择对与用户（设备）的通信进行加密。然而，加密是部分的，并不能完全解决通过这些实体中的每一个实体进行披露的威胁，如图11。应用提供商使用用户的公钥，对正在推送的消息内容进行加密。虽然应用服务器仍然使用通知中介来发送消息，但它不能解密消息。
图11：端到端加密概述
这种方法，通知代理不能访问通知的内容，但能够观察元数据并了解其他两个实体间的相互作用。
03 认证期数据共享
认证是许多网络应用的关键构建模块。某些情况下，获得数据主体符合特定标准或具有特定属性的证据就足够。年龄验证一直是用来确保未成年人在物理世界中不受伤害的方法之一。规避之外，还有一个问题是，处理的数据超过了实现特定目的的需要（数据最小化原则）。
基于属性的凭证（ABC），隐私增强的ABC允许 通过有选择地披露和认证特定的属性来认证一个实体，而不披露通常使用的包括个人数据的额外身份信息。用户可以将这些属性传达给第三方，第三方可以通过包含数字签名的方式验证其真实性和完整性。可通过其数字签名来验证其真实性及完整性，如下图12所示。
图12：身份属性的创建
当用户访问汽车租赁在线服务的网站时，被要求提供相关的属性，以证明成年并持有有效的驾照。用户可通过其智能卡或相关的浏览器扩展向在线平台展示相关属性。随后，平台对属性进行验证，并继续进行租车预订过程。
图13：基于属性的认证
在该数据共享场景中，用户并未透露真实个人数据，仅透露了一个属性，该属性是第三方对某一特定属性的证明（或不满足）。
基于属性的在线平台访问的相关性
2022年，法国数据保护局（CNIL）强调，不能以在线年龄控制的绝对效率为目标，尤其是对未成年人。鉴于在线服务中对未成年人年龄验证的要求越来越高，CNIL建议使用可信赖的独立第三方，以促进数据最小化和服务提供商对个人数据的非必要收集。CNIL对现有的六种可能的年龄验证解决方案进行了概述，结论是并不存在可靠性、数据保护和安全性方面满足所有要求的特性的解决方案。除了这个分析，CNIL的数字创新实验室（LINC）已经开发了一个基于零知识证明的隐私友好型年龄验证系统。CNIL对可信第三方和基于属性的认证的建议，与零知识证明的概念密切相关。在讨论的受信任的第三方用例的基础上，未成年人的监护人或家长 可以支持使用这样的第三方为未成年人创建一个基于属性的身份。，未成年人可以浏览在线平台并使用基于属性的身份的功能。这种方法将满足未成年人数据的可靠性、数据保护和安全性的要求。
关于行使数据主体权利的考虑
GDPR的一个关键因素是，数据主体有权适当了解和控制有关个人数据的使用或其他类型的处理。数据主体的基本权利要求更仔细地考虑其在数据共享环境中的实施。前面的章节涵盖了数据最小化技术的多个例子，从数据中删除信息或将对信息的访问限制在较小的利益相关者子集，从而实现保护脱钩的目标，而其他两个保护目标需要不同的工程方法。
在医疗保健场景中，多个角色参与了数据的收集、存储、共享和处理，如：
在医院或医生办公室的病人；
在可穿戴设备的用户处；
在人口普查局或政府医疗机构；
在医疗保险公司；
在医疗设备制造商处；
在日间护理机构或养老院；
这些数据源中的每一个都可以提供相关的数据。尽管一些欧洲成员国促进了在政府托管机构中集中存储医疗数据的做法，但一些相关的数据集并未储存于中央存储库中。因此，当涉及到数据主体的权利工程时，可能会出现数据控制者、数据处理者和数据存储地点高度分离的情况。GDPR包含关于卫生部门个人数据的具体要求，并提供了一套广泛的数据主体权利。根据具体的情况，这可能会影响到存储在医院的个人数据，在这种情况下，必须适当考虑目的约束、声明或撤回同意、透明度要求和干预权利。
在数据共享讨论的另一面，数据处理组织有兴趣为其目的获取数据，并有足够的技术支持和明确的指导方针。为了避免与GDPR中的数据控制者和数据处理者的术语相混淆，并牢记甚至可能存在不受GDPR监管的基于匿名数据的利用，
第三，也是在可预见的未来最需要考虑的，是数据中介的作用。这些行为者以某种方式在数据提供者、数据主体、数据存储者和数据使用者间进行调解。这些行为者在数据提供者、数据主体、数据存储提供者和数据利用者之间起着某种中介作用。不同的新的和即将出台的欧洲法律定义了这些实体的类型，例如在欧洲数据治理法案中作为数据中介，或在欧盟健康数据空间提案中作为利益相关者。其作用通常是不使用分享的数据，或者即使使用，也只用于非常有限的主要目的。
图14：有数据中介的数据共享场景
01 数据主体和数据中介之间的互动
每种类型的个人数据处理的一个关键组成部分是有效的法律依据。多数情况下，这往往是由数据主体给予的明确同意。在这里，数据中介必须满足管理每个数据使用人的数据处理同意。下面的图15展示了数据主体可能会考虑的示例。
图15：数据处理偏好示例
很明显，在数据中介处宣布和执行这种数据处理政策的任务 显然，在数据中介处声明和执行这种数据处理政策的任务可能是具有挑战性的。它需要与数据主体进行广泛的互动，以收集和协商所有必要的处理权限，并与潜在的数据汇进行互动，以验证数据主体的要求与数据利用者的条件是否相符。
目的限制
在这一问题格局中的一个关键挑战是目的限制方面。由于数据主体可以任意选择限制为某些目的处理自己的数据，因此有必要仔细研究目的的兼容性问题。在目前的数据生产和数据使用环境中，有大量不同的目的，这些目的可能兼容也可能不兼容，可能重叠或包括彼此。另外，如果不同的行为者对这种许可的目的有不同的解释，就有很大的可能发生冲突。必须预见的是，将需要一些时间和努力来制定一个有点综合的、普遍接受的方法来处理数中介情况下的同意和约束性目的中的此类问题。
实施方面
在这些概念的工程技术方面，数据主体和数据中介之间的互动可以通过多种方式实现。在cookie政策横幅和类似的同意管理系统普遍存在的地方，提供和撤销同意是可行的，可以利用或多或少的功能技术接口。然而，这些系统通常是数据主体与之互动的网站的一部分，并且只涵盖通过该网站或其服务提供商提供的服务。
02 数据中介机构和数据利用者间的互动
一旦数据中介机构的存储库中出现了数据，就必须考虑不同的数据采购模式的细节。每当一个潜在的数据利用者对可用数据的特定子集表现出兴趣时，就必须在数据中介的一端执行多项任务。
数据请求和数据响应
最初，数据利用者需要能够转向数据中介，要求提供数据，这些数据可以是个人或非个人性质的。在对数据的请求中，数据利用者必须表达它所感兴趣的数据的具体标准。例如，这包括数据主体的属性，其数据被搜索的方面包括数据类型、领域、数量、质量或来源，有大量不同类型的过滤器和限制需要考虑。
图16：数据中介和数据利用者之间的互动关系
除了表达她感兴趣的数据的搜索标准外，数据利用者还需要精确定义数据的目的和预期处理范围。数据中介需要这些信息来过滤掉数据主体以某种方式反对这种类型或处理范围的数据集，或这种类型的数据接收者。因此，关于数据处理预定执行的国家或数据利用者一方的后续数据利用者的信息必须向数据中介披露一组属性，以允许数据中介以可靠的方式执行数据主体的意愿。基于这个初始数据请求，数据中介需要进行内部分析，以确定符合数据利用者所表达的要求的可用数据集。
03 数据中介机构的数据管理
为了遵守数据主体和数据利用者的需求和权利，数据中介需要跟踪所有的数据。为了遵守数据主体和数据利用者的需求和权利，数据中介机构需要同时跟踪所有的数据源和数据处理任务。它需要了解并根据需要与数据主体和数据利用者互动，它需要在整个数据处理的多个阶段评估和更新数据使用政策。如前所述，数据中介必须为与之互动的每个数据利用者，以及大多数数据主体存储通信手段。
同意范围和目的限制
在选择可能符合或不符合数据利用者设定的标准的数据主体的过程中，关键问题是是否符合数据处理的目的。根据具体条件，数据中介必须决定如何进行的几个不同选项中的一个。
包括这些数据，假设目的一致；
假设目的明显不相容，则排除该数据；
联系数据主体，以澄清这些目的是否兼容，或确定数据主体是否同意有关的特定处理目的；
咨询相关第三方，如数据保护机构，以获得关于目的是否兼容的指导；
中介间相互作用
有时会有一个以上的数据中介参与处理来自数据利用者的特定数据请求。该情况下，要么数据利用者单独询问每个数据中介，导致前面所讨论的情况，要么可能需要在几个不同的数据中介之间进行交互。
图17：与数据保管者的跨境数据交换
数据中介间这种类型的互动的具体场景是欧盟成员国之间的跨境数据交换。该情况下，数据是否能够跨境传递的决定，可能是由专门的国家数据保管组织或类似的数据中介类型作出的。该情况下，数据中介间的通信协议也必须满足特定的需求及其通信方面，如上文图17所示。
记录和报告
无论提出什么数据请求，无论什么数据进入数据中介机构的控制域，数据中介机构都需要对其进行跟踪并负责任。当数据响应被发送到数据利用者时，关于哪些数据被包含的决策过程的确切细节必须无限期地存储在数据中介机构，以便以后能够通知数据主体、数据利用者、执法部门或其他外部利益相关者。
保护隐私的数据选择
为了履行其对数据利用者提出的数据请求提供数据响应的职责，数据中介机构需要对其控制的任何数据集有深入的了解。这甚至可能涉及到向数据中介披露个别数据记录等细节。
04 数据利他主义
数据利他主义的概念也在《数据治理法》中被引入，指的是数据主体同意将其数据用于具有普遍意义的目的，如科学研究或改善公共服务。关于利他主义的有趣之处在于，通常不会给予数据主体任何补偿。在数据中介机构处理此类数据时，可以考虑将数据标记为在数据利他主义"许可"下发布，以便正确处理数据利用者对该数据的后续要求。通常情况下，此类数据的处理许可总是被授予的，但必须由数据中介机构进行记录，以便在数据主体向数据保护机构等提出关于数据主体权利的投诉时，能够证明数据发布背后的合理性。此情况下，数据中介必须能够证明数据的来源和数据主体当时给予的初始许可。
结论
当两方或多方决定共享其数据时，就成为了更大的数据生态系统的一部分，可以利用合并的数据集，通过计算的方式发现与个人、个人群体或整个社会有关的新信息或趋势。实现这一目标的最简单和最直接的方法是通过技术接口交换每个行为者所持有的原始数据，将它们放在单一的数据库里，但这个假设实际上并不可行。本报告试图更深入地研究与个人数据共享有关的具体使用案例，主要是在卫生部门，并讨论具体的技术和实施方面的考虑如何支持实际的个人数据共享工程。这些分析范围包括从用户控制的数据共享到大规模的个人数据收集和数据使用第三方服务共享。尽管数据共享概念和欧盟在该领域的相关政策和法律具有潜力，但对于哪些是适当的技术和组织措施以及如何将其付诸实践仍有考虑。除了与GDPR的规定保持一致外，重要的是消除关于角色和义务的任何法律不确定性，不仅是对个人而言，而且对参与数据共享的实体而言。为了发挥欧盟范围内数据共享的潜力，可以为从业人员提供指导，说明在哪些情况下可以考虑哪些技术和工艺，以及可以满足哪些数据保护原则。
声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
