隐私工程（Privacy Engineering）是近些年涌起的一个概念，随着与Privacy by Design和隐私增强型技术（PETs）的关系进一步厘清，成为监管机构与实践专家充分认可的解决法律到隐私工程实践的方法论。本文将阐述隐私工程的含义与价值、在监管机构指南与国际标准中的落地路径。
1 隐私工程能解决什么问题
自从欧盟《通用数据保护规定》（以下简称GDPR）引发了全球的隐私数据保护立法，进而有美国、巴西等多国的法律演进，更有国内《个人信息保护法》等顶层设计的完善，立法侧达到了一个峰值。然而从实践层面，一直对于如何才能实现将隐私数据保护法律要求落地实施到系统组成中有困惑，法律规定与研发工程之间仍然有很大的距离。随着技术的进一步发展，互联网产业的变革，多端互融，数字化经济转型等，同时诞生了可能的新物种元宇宙等，导致法律的演化速度距离技术的发展差距越来越大。该差距引发了监管侧的担忧，正如ENISA所指出的“事实上，欧盟各国数据监管机构缺乏有效和系统的能力去监管数据处理活动或者处罚违规行为【1】”。
该差距也引发了企业实践侧对于是否可以有效地实施隐私数据保护的法律要求的困惑。有学者提出归责原则（Accountability）有三个层面：制度文件的归责，流程的归责以及实践的归责。前两个层次更多的要求是应当良好的文档记录通过系统落地实施的隐私制度以及内部的隐私流程，而第三个层次需要证明所有数据处理活动完全遵守隐私数据保护要求【2】。然而要实现第三个层次，有各种各样的问题，比如法律概念到工程实践概念理解是否一致，模糊的法律要求与精确参数的研发工程存在了矛盾，系统工程是不断迭代的，如何保证持续的合规。
关于该顾虑，研究流派中有坚持使用隐私增强型技术（PETs，包括隐私计算）可实现保护隐私，但是随着隐私数据保护的法律原则和要求的发展，发现隐私计算更多实现了数据最小化等，无法完全支撑落地所有法律要求到系统上。于是就诞生了加拿大学者提出的Privacy by Design的概念，应当从系统设计之初就考虑到隐私，直到软件开发的全生命周期。
在GDPR把Privacy by Design纳入到法律规定后，可以说比隐私增强型技术有了更全面地实现隐私落地于实践的交融概念。其后有了更多学者对Privacy by Design提供了较多的指南和探讨，然而设计和指南更多涉及功能性，而监管也还是很难判断软件系统有多少程度上落实了Privacy by Design。在Privacy by Design的框架下，又进一步引入了隐私工程的概念。
ENISA持续研究Privacy by Design，完成了从2014年提出的从制度到工程，到2022年提出的从理论到实践，在今年发布的《Data Protection Engineering：From Theory to Practice》中给出了清晰的路径“隐私工程可以被认为是Data Protection by Design and by Default的一部分，目标在于支持选择、运用和配置恰当的技术和组织措施，以实现具体的数据保护原则”。
简而言之，要引入隐私工程的价值在于弥合隐私数据保护法律要求落实于各种不同的且不断迭代的系统中，实现accountability to practice。
2 欧盟数据保护监管指南中的隐私工程
为了实现隐私工程的价值，首先需要解决的问题是如何保证隐私工程是可用于保证具体的隐私保护原则？
安全工程的目标保密性、完整性和可用性是被广泛接受的，开发者对该三个目标了准确的认识以及运用，被用于识别风险以及选择恰当的缓解措施，因此研究学者也提出了隐私工程的三个目标，即不可关联性（unlinkability）、透明性（transparency）和可干预性（intervenability）。其后被德国数据保护监管机构纳入到了标准数据保护模型（SDM）并推广到了欧盟其他的监管机构。
不可关联性的核心是实现个人信息不会实现跨域的关联或者将付出不对等的代价，以最小化未经授权的使用个人信息以及不恰当的关联不同域内的数据来创建画像，从而保证了目的限制、数据最小化以及存储限制。
透明性的核心在于让所涉的相关方（包括数据主体、数据控制者、数据处理者、数据保护机构）了解数据收集处理等活动、相关风险、所采取的防控措施以及如何应用、这些措施的局限性。透明性应当包括对全生命周期，不仅仅是正在进行的处理活动，也包括正在规划中的以及已经处理的数据处理活动。进而来保证合法性、公平性和透明性以及目的限制原则。
可干预性的核心是让所涉的相关方，尤其是数据主体，可以干预到数据处理活动，但是可以具有法定的限制条件。该目标可以保障用户权利实现，以及相关的准确性和归责原则。
隐私工程的三个目标经论证，是符合GDPR规定的基本原则，具体如下图所示，因此监管机构认为可以将隐私工程的目标作为承接数据保护基本原则到隐私工程实践的支柱。
图1 通过隐私保护目标保证GDPR原则的实现【3】
在确保了隐私工程可以保证符合隐私数据保护要求时，应当要有更为符合系统工程的方法。如下图所示【4】，将软件系统开发周期可以区分为如下几个环节：概念形成阶段、需求分析阶段、设计阶段、开发阶段、运营阶段、维护阶段以及销毁阶段。隐私工程通过在概念形成与分析阶段、设计阶段与开发阶段对应引入相应的活动类型：隐私设计策略、隐私设计模型以及隐私增强型技术来嵌入隐私到软件系统工程中。
在概念形成与需求分析阶段，可以引入隐私设计策略。隐私设计策略将为研发工程师提供相应的模型可以选择使用以满足隐私保护目标和隐私数据保护原则。在设计阶段，可以引入隐私设计模型，可以用于解决高频且通用的隐私风险的设计方式。比如隐私设计策略“最小化”，即将数据处理活动的数据限定到最小范围，其和隐私设计模型是在选择（select），即在收集前确定选择必须要收集的范围，或者剥离，在删除不必要的信息点再进行收集。
在开发阶段，研发工程师应当考虑采用可行的隐私增强型技术，将隐私设计模型转化为实际落地的技术。隐私增强型技术具体是指一系列可以限制或减少个人信息或者阻止不必要的访问和处理个人信息，同时也可以保证系统功能性的技术方式。
隐私设计策略、隐私设计模型与隐私增强型技术，三者之间不一定会形成一一映射，而且现在隐私设计模型与隐私增强型技术也不是完全列举，将随着场景变化以及技术变革，会有各种不同的选择、实施和迭代。所以，隐私工程通过将三者作为隐私纳入到系统工程的方法论，既保证了固定思维模式便于运用，也保证了其场景和未来发展的延展性。
3 国际标准中的隐私工程
ISO/IEC TR 27550《信息技术 安全技术 系统生命周期流程中的隐私工程》（以下简称ISO 27550）在考虑了各国有关机构关于隐私工程的原则、概念以及ISO关于隐私、安全以及系统软件工程的标准后所制定，指导企业在系统工程实践中引入隐私工程。ISO27550是建立在ISO/IEC/IEEE 15288《系统和软件工程：系统软件生命周期》之上的，从流程管理上来说提供了更为细致的隐私工程嵌入到开发流程中的阐释，具体如下所示。
首先，在协议流程中，采购和供应链流程的隐私工程产出：在采购方与供应方之间对所建立的具体隐私义务达成一致，比如交付一项符合隐私义务和要求的产品或服务。
其次，在组织相关流程，包括人力资源以及知识管理流程中，应当识别项目所需的隐私工程能力并投入为隐私工程能力发展项目，并进一步将实践中积累的隐私工程知识记录并结构化，保证进一步被运用。
再次，是在风险管理流程中引入隐私风险评估，该评估也会是后续技术流程中设计、开发的输入，同时会被技术流程中各个环节所不断更新。
最后，是与欧盟监管机构所关注的视角类似，在需求定义、架构设计、需求设计阶段的隐私工程嵌入。ISO 27550提供了LINDDUN模型、隐私服务能力、隐私缓解措施等行业内的多项工具和方法论，便于企业选择使用。
4 小结
隐私数据保护与其他法律合规要求相比更为细致，与软件系统具有更强的关联性，需要更多的跨学科视角引入，以推进隐私数据保护从法律到研发工程的慢慢长路。笔者期望通过本文将该跨学科视角引入到实务界，通过成熟的方法论，以及我们的实践，可以找到真正实现Privacy by Design的关键路径、方法库以及衡量方式。
ENISA: Privacy and Data Protection by Design: From Policy to Engineering
Colin J. Benett.: Managing Privacy Through Accountability.
AEPD: A Guide to Privacy by Design.
AEPD: A Guide to Privacy by Design.
声明：本文仅代表作者个人观点，不代表本公众号及其运营单位意见或立场。
声明：本文来自数据安全推进计划，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
