隐私是事后的想法。以下是开发人员可以轻松改进它的方法。

当您构建计算器时，“快速移动并打破常规”在 T 恤上听起来很棒，而最大的风险是轻微的计算错误。考虑一位在桥梁和隧道上工作的土木工程师——如果他们穿着标有“已知可运输”座右铭的 T 恤，我们会觉得舒服吗？不，因为我们希望得到保证，那些受我们委托来构建这些关键系统的工程师的设计目的是为了结构完整性、用户安全以及为一代人服务的寿命。我们软件工程师现在在同一条船上。我们社区构建的东西令人敬畏和美妙，世界渴望参与我们的发明。但是随之而来的是对那些不了解软件或数据处理内部工作原理的人的注意义务，以构建尊重这些人的系统，并确保我们为社会提供的系统的完整性和安全性。这种考虑的艺术术语是“数据隐私”，但在实践中，“尊重”概念可能更贴切。尊重系统是将选择透明地呈现给用户的系统，并且用户选择与系统共享的信息始终处于他们的控制之下。似乎没有太多要求，对吧？在我们的领域，它正在成为赌注。好消息是，这并不意味着我们不能快速行动。引用深思熟虑的 DJ Patil 的话，我们可以“有目的地行动并解决问题”。将隐私与创新相结合，而不是让它们相互对抗，关键是将隐私融入到 SDLC 中。类似于应用安全 (AppSec) 上游转移到开发周期，隐私属于开发之初，而不是事后考虑。有两种方法可以看待我们领域最近出现的监管兴趣：对我们行业的敏捷性（合规性）征收沉重的税，或者有机会构建更好的软件，首先尊重其用户。我是一个乐观主义者，所以我选择后者，但这需要实施基本的工程原理和工具。对此的一个很好的参考是 Ann Cavoukian 博士的隐私设计七原则，它们是： 今天，大多数工程团队的数据隐私是在软件交付生产后解决的问题。这有点像十年前的应用程序安全性，在那里你完成实施，然后通过渗透测试和修复发现的问题，在事后实现安全性。然而，在过去几年中，AppSec 已经“左移”成为 SDLC 的一部分。构建良好的软件在离开您工作的存储库之前是安全的，安全性是通过改变工程思维方式和一套用于静态代码分析、应用程序安全测试和威胁建模的出色工具来实现的，以确保您交付的代码尽可能安全。工程师们越来越自豪地拥有安全思维并了解防御设计和零信任原则。

但同样，今天的隐私是事后的。例如，如果你在一个早期阶段的团队中，你会迭代 MVP，直到找到适合市场的产品。这种精益方法具有商业意义，但是一旦您获得牵引力和客户，您就在收集数据。因为您没有为这部分做计划，所以您立即将您的用户暴露在风险中，并积累了一种几乎无法摆脱的数据计划债务。你的轨迹越成功，你的成长就越快，你积累的数据就越多，这个问题就变得越尖锐。你不能倒退并解开债务，所以现在你正在建造不可扩展的机械土耳其人来降低风险，但无法解决潜在的问题。在大型科技公司中，“孤立数据集”是指存在于其基础架构中且仍在使用中的数据集，但对其中的内容、数据来自何处以及如何使用没有明确的了解。我们都熟悉这个故事：您快速构建您的第一个产品，因此您的文档可能并不完美，或者您的数据模型有机地发展。您找到了成功并开始成长，因此更多的工程师加入了团队。团队层次结构非常扁平，可以启动数据库并开始工作——太棒了，我们是敏捷的精髓！然后您会关心系统可用性和扩展性，因此您开始将事物组合成一个更优雅的面向服务的架构：当您添加功能以满足客户需求时，不同的工程师会挑选一些部分。你的一些早期工程师离开了公司，新的加入，循环重复，不久你就有了一个包含 500 多个微服务和数百个数据库的平台，没有任何统一的注释或元数据。您不确定什么用于哪个目的，并且有很多灰色区域。今天怎么解决的？一组专门的数据工程师筛选这些系统，从数据集开始，然后通过服务层进行取证工作，以了解正在存储哪些数据、正在执行哪些服务以及正在执行哪些业务功能。而且因为你没有改变你的工程实践——你仍然以你原来的方式交付代码——这是一个 Sisyphean 问题。您的数据工程师不断理清系统，以尝试了解数据的位置以及如何代表您的用户安全地管理数据。为了尊重您的用户，您必须尊重他们的权利，而且这些权利越来越受到法律要求的支持，例如欧洲的 GDPR、加利福尼亚的 CCPA 和巴西的 LGPD。

这些权利因地点而异，但基本原则是，当您的系统用户想要访问时，他们可以访问您拥有的所有关于他们的信息，他们可以更新这些信息，或者他们可以完全删除自己。除此之外，用户有权决定您如何使用他们的数据。这就产生了要求，如果他们不同意某个用户的数据，就可以禁止在系统中的特定进程中使用这些数据。想象一下，您有一个非常优雅的面向服务的架构，其中包含 400 个服务，每个服务负责不同的业务逻辑。如果您平台中的用户 A 选择不处理您所做的 27 件事，您需要能够识别该个人，您数据集中的单个实体，并强制执行可能仅适用于其实体记录集的特定属性的约束在单个进程上——只有一个服务请求。在 10,000 英尺的视野中，如果您设计的架构和数据模型从一开始就在 SDLC 中支持这种级别的粒度和策略实施，那么这一切都是可能的。但这不是通常发生的事情。在生产现实中，您需要手动执行策略，新的策略表在运行时以特殊方式连接到实体记录以开始执行特定约束。它变成了您的用户提交他们的同意偏好和复选框的 Rube Goldberg 机器。至少在 UX 中看起来不错，但在后端，它是一堆不可扩展的手动流程、工作流程和运行手册，用于更新用户的偏好并确保他们被排除在某些管道工作之外。它还为法律团队生成报告，以确保当用户对某事说“不”时，他们的同意偏好会在您的复杂数据平面上强制执行。对于一个成功的企业，他们有可能必须这样做数千次，甚至数百万次。正如我之前写的，隐私不能在系统建成后真正用创可贴来解决。早在我们大多数人想到隐私之前，数据隐私失败的原因就发生在 SDLC 的上游。与应用程序安全一样，问题的根源和最佳预防的位置是设计、实施和测试软件的地方。这就是制定设计决策、实施实践和隐私开发工具可以减轻我们常见的隐私风险的地方。简而言之：如果隐私是软件开发过程的一部分，那么尝试解包孤立数据集的示例永远不会实现，因为合并到以隐私为中心的 SDLC 中的代码将描述其目的、使用的数据类型以及数据 I/O，以便您可以轻松地跨数据平面观察。您将拥有通过每段代码的数据的完整地图——因为在代码级别进行彻底注释等步骤，您可以明确了解系统中数据的实质、来源和用途；每个数据集都有一个家。

带有隐私的 SDLC 会导致系统在没有创可贴或手动流程的情况下开箱即用地尊重其用户的权利。该系统清楚地识别数据流，从而使数据发现和映射工作变得多余；您的产品堆栈在部署后立即自我描述其数据操作。将隐私视为事后的想法会导致与生产相关的隐私和数据合规性操作中的工程资源的大量浪费，而在 CI/CD 管道中使用更好的工具可以避免这种情况。我们这个时代的核心隐私问题是系统不是自下而上构建的。其中一些原因当然是文化上的，但有些原因与工程团队可以使用的工具有关。简而言之，到目前为止，他们还不能胜任这项任务。我一直在仔细考虑这个问题，并对如何解决这个问题有一些想法。第一步是确保工程师有一种“隐私语法”形式或一种速记、低摩擦的方式来描述他们的代码做什么以及它使用什么类型的数据，并使这成为他们的编辑器和 CI 过程的一部分。代码注释和文档是一个良好的开端，但全面的工具解决方案是人类和计算机可读的，并集成到手动和自动工作流中。当使用集成工具在他们的项目中实现给定的功能时，开发人员可以很容易地描述他们的代码正在做什么以及它在做什么类型的数据的上下文。此外，以同样的方式，安全/SAST 工具现在是构建良好的 CI/CD 流程的公认组件，提供 CI 挂钩的工具可以在每次提交和 MR 时评估隐私语法和数据分类，提供简单的推动开发人员如何确保他们的工作尊重隐私。至少在可预见的未来，我认为我们不能或应该将人类从循环中移除。然而，对于大多数公司来说，当前的流程在试图发布代码的工程师和手动隐私审查流程之间产生了很多摩擦，同时也占用了宝贵的带宽。

提交和合并阶段的自动化可以更好地为人工监督处理高风险和低风险问题，并消除工程师完全异步隐私审查表单的需要。隐私风险评估可以是 CI 管道的一个优雅部分。如此多的隐私始于了解您的软件使用的数据。健康隐私最常见的问题之一是同意系统中数据类型的标准。数据类型经常是由使用它们的团队创建的，导致格式大杂烩。不同地区的法律要求使标准化成为一项挑战，但这可以通过采用 ISO27701 PIMS 标准（特别是 ISO/IEC DIS 19944-1）并构建可由每个工程团队建模的个人数据分类单一视图来实现。使用单一标准对系统中的数据进行分类，我们可以简化系统在隐私操作和用户权限请求方面的互操作性，并实现统一的系统间治理。如今，策略和治理实施需要扩展现有的基于角色的访问控制 (RBAC) 或访问控制列表 (ACL) 类型系统，以推出您自己的细粒度治理解决方案，并且它通常仍然在抽象数据集或系统级别起作用。细粒度的数据策略模型应该从第一天开始设计，以根据在实体级别管理的策略在每个实体的单个字段级别强制执行数据访问。这种粒度是确保隐私权真正可执行的唯一方法。然而，要实现这一点，它需要一定程度的互操作性，因此与 Open Policy Agent 等标准策略实施模型的集成是关键步骤。今天，同意通常​​是通过 cookie 横幅或在表单流中在运行时设置的单个标志来处理的。同意可以而且应该成为所有前端框架的验证模块的一部分。如果我们在运行时已经知道正在收集哪些数据（因为我们正在对其进行验证），则可以使用这些相同的验证器来检查上下文。像上面描述的细粒度数据策略模型这样的工具将允许任何工程师扩展这些验证以明智地检查数据类型和同意。我们已经使用针对字段类型的验证来生成数据类型、结构等的业务逻辑检查。这必须扩展以确保字段标签确定是否应自动收集同意，并在应用程序运行时提供中央同意跟踪服务，以便用户同意在整个应用程序使用过程中是统一的。这些步骤使系统更难意外地未能注册同意选择或传达用户的权利。

每个应用程序都应该保留隐私相关操作的散列记录。这样的日志将使工程师能够在应用程序和用户生命周期中可靠地跟踪用户权利和隐私活动，并展示在隐私 CI 管道中做出的决策。透明度和隐私可能看起来很奇怪，但它们实际上是密切相关的。回想一下 Cavoukian 博士的第六项隐私设计原则：可见性和透明度。构建可信赖系统的承诺适用于构建这些系统的工具。然后，即使没有经过深入培训，每位工程师也可以更好地将隐私融入他们的代码，同时减少工程和法律团队之间的摩擦。作为软件工程师，我们构建了数十亿人依赖其财务、安全、健康和福祉的系统。我们的工具和流程必须反映我们尊重用户数据的责任的严肃性。隐私的事后处理方法是劳动密集型的，而且有风险。它从根本上是被动的，无法随着为我们世界提供动力的系统的快速增长而扩展。通过为工程师配备在 SDLC 中通过设计实现隐私的工具，我们构建了更好、更安全和更受尊重的系统。在运营层面，我们减少了在生产中解决问题的痛苦，使我们的团队能够专注于创新，而不是争先恐后地实现事后合规。在文化层面上，我们提供真正赢得用户信任的系统，这是 2020 年代唯一值得构建的系统。多年来，工程师们事后才离开 AppSec。今天，几乎不可能想到没有嵌入 AppSec 的典型 SDLC。我们可以而且必须遵循隐私的平行方法。标签：隐私，sdlc，软件开发