不能忽视 GDPR，但也不需要恐慌。

开发软件的时候，很容易将 GDPR 需要的细节加入文档。

默认情况下，隐私应该存在于你开发的所有软件中。

需要考虑和支持扩展用户权限。

应该重新考虑软件构建方面的实践，比如记录日志。

软件设计师应该在保证完成工作的同时独力避免成为数据处理者。也就是说，在确实准备完备之前，不要去访问不需要的个人识别数据。

GDPR 强调风险思维；您需要采取一切措施来缓解隐私风险，直到风险化解到您可以接受的程度。我很欣赏这个规定 - 有很多的软件在设计中完全没有考虑到安全或隐私的问题。这种软件及其违规行为会导致用户不信任他们的个人数据是如何被使用。现在是时候改变这一点了。

要理解的要点

GDPR 不允许有很多例外情况，所以大小企业，非营利组织和政府组织都需要知道要点。

新法规的一个重点是数据主体的透明度。当您拥有包含个人身份识别数据的注册管理机构（例如数据库）时，GDPR 认为其使用对数据主体应该是透明的。这意味着你正在收集的数据的人应该能够找出你正在收集什么，你的目的，谁有权访问数据，以及数据在系统中存在多长时间。要应对这个要求，你自然应该知道所有这些事情，并将它们记录下来。除了透明度，你还需要提供更好的访问数据的能力。您的数据应该能够像最初向您提供的那样容易地验证，修正，导出，移动和清除数据。

另一个重要的话题是设计/默认的隐私，这实际上应该被集成到所有的体系结构中。在这个规定之前，它应该是一个自动化的设计元素，但是人们通常不愿意为安全或隐私买单。GDPR 给出了一个强有力的动机来处理这一问题 - 一个价值高达 2000 万欧元的奖励。默认情况下，隐私意味着很多事情，但其本质上是为了保护个人身份信息和隐私，并采取适当的控制措施。例如，这通常要求明确的审计跟踪形式，谁在什么时候做了什么，包括特别是读取个人身份信息。此外，在存储和传输不同层次数据时，您应该注意这些数据，并应用适当的加密措施以避免系统中的数据泄漏。

您还应该拥有处理个人数据的有效基础，这意味着您有权收集和处理这些信息。例如，根据这一项法律，要求您在一段时间内收集和存储个人信息。处理个人数据的基础可能是合同，协议或交易。

您可以要求同意收集和处理个人数据，但 GDPR 不会让您在这里感觉轻松。用“我接受我的信息可能用于营销目的”这样的陈述来检查复选框是让人不可接受的。同意必须是明确的，准确的和可以理解的，并且不能被预先设定。它应该是和首先取得同意一样简单的取消选项。软件设计人员可以自己决定，但是需要与拥有软件的人讨论。

这是一个有趣的观点。如果构建软件的团队成员在构建软件的过程中可以访问实际的个人数据，他们将成为数据处理者，并承担相同的处罚和责任。运营团队也是如此。如果他们有权访问数据库和数据，他们必须可靠并对此负责任。你可能需要好好想一想。毕竟，无需访问实际的客户数据就可以构建和运行大多数系统，这种方式是可能的。

识别个人身份信息

GDPR 只关注个人身份信息(PII)，它不适用于与个人无关的数据，例如产品或会计信息。你仍然可以将其归类为敏感信息，并可能仍然希望保护它，但 GDPR 将其视为非 PII 数据并忽略这些情况。

GDPR 识别了两类 PII 数据。有一些数据可以用来唯一标识一个人，比如社会安全号码、电子邮件地址，或者与这些标识符直接相关的东西，比如购买历史。那么就有一些非常敏感的数据，比如医疗/健康信息、宗教信仰、性取向，或者从未成年人收集到的任何信息。

请注意，根据GDPR，信息的组合可能不是独立的，可以识别出潜在的个人。 因此，PII 还包括可以从诸如邮政编码，旅行或购买地点等多个位置的值推断的身份。 微小的数据集和罕见的值组合使得对个人的识别更容易。

由于任何附加到个人所收集的信息都受到隐私规则的保护，因此，大多数数据库将包含PII，但有一些例外情况。 我估计70％-80％的典型系统数据是PII。 所以，你应该保护的就不仅仅是社会安全号码和信用卡号码。

有很多关于访问日志，审计日志等含有IP地址或代理键的讨论。 这些个人资料是否注册？ 所有的个人权利都被能通知到他们吗？ 他们应该受到多大的保护？ 专家的答案也是不一致的。 我们必须等待，看看这是如何演变的。 但是，我会建议避免歇斯底里，并在灰色地带使用它们。 这种信息可以而且应该在一定程度上受到保护，具体取决于数据泄露会造成多大的伤害。 不过我没有看到网络服务器被管理起来，以最苛刻的定义来看，每一台网络服务器都应该被纳入一个PII注册管理机构。

设计隐私

让您的软件符合 GDPR 规定的最划算的方式是正确地建立需求。您要做到这一点的程度取决于具体系统的风险水平：

您的系统是否包含额外的敏感信息?

您的系统是否包含一些对于 GDPR 而言不敏感但有其他尴尬/危险的内容会发布？

如果有人发布了您的数据库内容，那么您的业务将面临多大的风险？

你的用户数据库有多大？

如果您的用户少，且您收集的信息既不敏感也不有害，您可能会认为您的系统处于低风险环境，并使用更具成本效益的控制措施来保护它。另一方面，如果您的系统包含许多用户的敏感数据，则需要应用更强大的保护机制。

良好的审计跟踪是最低要求。审计跟踪不仅表明您已经应用到控制中去，还可以帮助您在数据泄露的情况下限制损害。在任何数据泄露之后，无论是内部还是外部，首先要做的是找到可以显示哪些用户受到影响以及哪些数据被访问的取证。这是您需要向数据保护机构报告的信息。此外，这些用户是您可能需要通知有关数据泄露事项的用户。如果您没有取证，则需要假定违规可能影响了所有用户和所有记录。

一个良好的审计跟踪系统还具有不可抵赖性的特点 — 换句话说，即使系统管理员也不能更改/损坏它。例如，您可能希望使用审计追踪来查看系统管理员所违反的数据情况。这之前已经发生，并且还会再发生。审计跟踪也被归类为 PII：它们具有与其直接相关的唯一身份和数据。

审计跟踪之后，下一个任务是限制数据的暴露。最好的办法是限制你收集的数据和存储的时间。通过从一开始就在您的软件中引入某种类型的存档/删除机制，您可以将其记录给用户。如果发生数据泄露，那么只会影响到目标系统中的实际数据。许多系统继续收集所有数据，但从不清理，即使数据已经过时。GDPR 鼓励您清楚地定义数据生命周期并记录它们。你也应该将访问数据的内容限制为真正必要的内容。对于敏感数据尤其如此。

我已经提到过，对数据库或文件系统中的数据有足够的保护机制，这些数据或文件系统通过网络，尤其是其他各方的数据移动。加密是有效的，但它有其弱点。最强大的加密技术在早期进行加密，保护您的密钥，并延迟解密。不幸的是，这是一个复杂而昂贵的解决方案。另一方面，云服务经常让您用便宜的方式简单地对整个数据库进行加密，或者为您提供管理密钥和加密服务。虽然方便，但这些机制也有薄弱点。根据数据的风险和敏感性，您需要找到适合您的服务。

值得一提的是，匿名和假名机制可以帮助您处理测试数据或分析数据。 匿名化基本上通过删除或屏蔽字段来删除所有可识别的信息。 假名化可以用假名替代可识别的信息，这通常使数据中的身份保持分离。 然而，这两种做法还是很难做到的，而且可能无法提供完美的手段来帮助您的GDPR兼容性。 不过，这些在你的工具包中是很有价值的工具。

您可能想要重新审视您的日志记录的标准和准则。 如果您能确保您的日志不包含个人身份信息，那么最简单的办法就是 - 让他们也会成为个人身份信息的管理注册中心。 有些日志已经附加到个人：例如访问日志和审计日志。 但是不要通过编写用户ID，名称或类似的值来污染操作调试日志。它尽管不能用来链接，但一般系统信息的日志可以被清楚地分离出来。

GDPR 喜欢文档。该法规的重要一点是能够证明合规性。您可以通过显示证书来做到这一点，而证书又有益于记录您的系统。如有必要，您可以根据您提供的文档级别来进行构建，这些文档可能因许多因素而异。但是从现在开始，还有一些额的文档是有用的。这是一个简短的清单：

记录系统中的个人资料

记录已收集数据的生命周期

记录处理数据的所有各方

记录收集数据的基础

告知数据主体的权利，并解释他们如何行使权利

你应该记录你收集的数据，你的目的，存储的时间以及处理这些数据的基础。您最好使用文档类型的组合来执行。你可能（也应该）已经有一个解释规则的通用策略文件，但是我看到过许多软件设计者开始创建一个数据列的网格，他们可以在其中指定 GDPR 分类。基本上，您可以使用通常用作域模型的任何文档，然后将其扩展为隐私信息。这些文件将作为您提供给用户提供的数据保护策略文档的基础。保证用户权利的第一步是了解系统收集的信息。

另一个有趣的方面是数据如何在网络上移动，哪些人可以访问/处理数据。为此，您可以创建一个记录参与方，层次甚至协议的数据流图。如果发生数据泄露，您也可以使用它来快速了解和限制数据暴露程度大小。

此外，如果您愿意，您可能需要记录用于保护数据的控制，并获得足够的隐私级别。

支持扩展的用户权限

用户/数据主体的大部分权利已经存在于欧盟既定的数据保护指令中。下面是他们在 GDPR 下的简单列表：

访问权，

纠正权，

擦除权，

有权限制/反对处理

数据可移植性的权利

有权收到数据泄露的通知。

在开始设计各种疯狂的 API 和系统来支持这些之前，值得注意的是 GDPR 并不要求这些是自动化的、实时的操作。事实上，你只需要在 30 天内响应请求。作为响应，没有依据来清除或导出数据（由于法律和正在进行的合同等）可能是一个合法的响应 - 当一个人提出请求时，正确识别这些数据是非常重要的，这样你就不会通过操纵或导出其他人的数据来创建新的数据缺口。30 天的响应窗口允许您以多种方式除去或清除数据，甚至在无法集成的系统中处理数据。

这就是说，如果你的组织已经有了一个客户/用户/数据主体的数字标识概念，并且你提供了一些自助服务，那么把这些身份权限附加到这个自助服务的用户界面上是一个好主意。您可以使用的自动化进程覆盖的文档越多，成本越低。而且，用户更乐意进行实时访问，而不是提出需要 30 天才能处理的请求。

在设计任何新的软件时准备数据擦除和导出功能是明智的。你可以通过删除信息来实现擦除功能，但更简单的方法是部分覆写该信息，并将其有效地匿名。目前，数据导出的格式似乎并不重要，但即使你的域不包含任何 GDPR 用户接口，你也可以对其进行规划。

最重要的正确做法是让数据主体行使以下权利的一站式服务：触发用于识别和验证请求的流程，然后是清除或导出数据的机制。

是否成为数据处理器？

当你在一个处在 GDPR 负责的软件项目上工作时，你需要回答一个重要的问题是：你打算成为一个数据处理器吗？默认情况下，你不希望成为一个数据处理器，因为你可能会为此承担任何处罚。为了避免 GDPR 的责任，只要确保你在任何情况下都不会也不能访问任何个人身份数据。你还需要确保在任何合同中都明确说明了这一点。避免处理 PII 可能很困难，因为个人信息可能隐藏在写得很糟糕的日志文件、测试环境以及生产环境的任何紧急补丁中。但是如果你想避免此类责任，你需要解决这一切。保护自己远离数据；避免你直接接触数据。

另一条途径是接受数据处理器的状态。这样，您可以自由访问个人数据，只要您记录活动，有有效的处理基础，访问发生在定义的范围内发生。这会使你明确的承担责任并负责，所以你必须注意任何制裁。但是，如果您绝对需要访问PII数据库，则需要采取这一途径。

大多数软件项目不需要暴露在实际的 PII 数据中，这绝对是推荐的路径，但可能需要新的技能和工具。

GDPR 破除的“神话”

不，数据主体不得通过行使用户权利来消除债务或犯罪记录。

不，数据主体在请求导出数据时不应将所有内容与其身份相关联。只包括直接收集的信息。该条例的精神是透明度和改变服务提供者的选择。

用户权限不会自动行使。在操作数据之前首先检查用户身份和请求的有效性是非常重要的。如果数据库不带有唯一的安全标识符，这可能会很困难。拒绝请求可能有很多正当理由。

不，GDPR 不需要你用 2048 位密钥在停止和运输中加密所有的东西。保护这些数据的控制措施只能用于缓解风险，直到它们变得易于获取，并且风险对于每个系统和情况都是不同的。

不，GDPR 不会阻止您收集和处理用户数据。但是要注意数据透明度，数据安全性和法律依据，只要不要收集超过您需要的数据，应该没事。

不，数据泄露不会使您受到 2000 万欧元的罚款。它可能会 - 但如果你已经阅读了这篇文章，并遵循了建议，那么你应该已经很好地降低了潜在处罚的风险。从一开始就确定你现在可以做什么，并为其余的计划做好准备。GDPR 列出了十几个问题，如果时间到了，将用来决定惩罚的规模。

不，制裁不是开始处理数据隐私的主要原因。这一规定已经就位，因为每天都收集越来越多的数据，越来越多的数据泄露情况正在发生。在您的系统中发生数据泄露可能会比收费和制裁花费更多，这会降低您的客户信任度。但是制裁是一个用来激励公司在建立和购买软件和信息系统时花费几欧元来保证安全和隐私的很好的方式。

不，云服务对于GDPR来说不是一个大的禁忌。事实上，与许多传统的数据中心相比，他们可能实际上更多地与默认隐私保护的要求所同步。当然，当涉及到合同和文档时，将机密数据转移给第三方变得更为复杂。

不，GDPR不要求你审核和记录所有事情，并且拥有入侵检测和测试数据管理的工具。 这些工具在成功使用时可能会使生活更轻松，但你的方法的核心应该是基于风险评估和适当的控制之上的。

软件工程师如何了解隐私结构的整体数据构建？CIPT认证！

CIPT认证涉及对科技产品隐私结构的整体数据构建&组织方面知识掌握。 随着全球监管机构针对互联网以及科技公司将数据隐私纳入其产品和服务中的监管要求日渐严格，市场对受过专业隐私保护培训的IT人员需求越来越大。

CIPT证书在2014年由IAPP协会推出以来，是为数不多的一个世界级并且符合国际标准认证（ANSI/ISO）的证书。培训专业的IT人员从产品设计到产品服务的各个生命周期/发展阶段均能够掌握对用户数据的隐私保护。

在信息经济时代，IAPP旨在培养各行各业在隐私和数据保护法律&实践管理方面的专业人才，让专业的技术专家可以通过对隐私知识的了解提升其职业高度&专业度以适应行业发展。

宏景提供的注册信息隐私专家、技术及管理等方面的课程培训,教师团队由持有IAPP证书且具备丰富海外学习和教育经验的担当,让你轻松拿到IAPP认证的CIPM/CIPP/CIPT证书。

内容整理于oschina，版权归原作者所有，如有侵权，请联系删除！