软件工程师需要知道的通用数据保护条例

本文要点

• 你不能忽视 GDPR，但也请不要为此感到困扰。
• 在软件开发当中，可以很容易地根据 GDPR 要求细则来扩充文档。
• 每一款软件都应该考虑到隐私问题。
• 需要小心对待用户的权利。
• 在软件开发当中需要重新审视日志数据。
• 软件设计师应该在不影响工作的情况下尽量避免接触数据。换句话说，如果没有必要就不要轻易访问个人隐私数据，除非你是处心积虑要这么做。

如果你打算在 2018 年推出软件解决方案，那么就很有必要阅读这篇文章。欧洲通用数据保护条例（GDPR）将在明年夏天正式实施，违反该条例有可能面临 2000 万欧元的处罚。除了条例中明确规定的处罚之外，泄露数据等行文可能面临牢狱之灾。

这是一件很严肃的事情。人们对 GDPR 的看法出现了两种极端：一种是假装它与自己无关，想忽略它的存在；一种认为天要踏下来了，以后在软件开发当中不能再使用任何个人数据了。其实这两种想法都是错误的。GDPR 并没有绝对禁止使用个人数据，实际上，它只是设置了一些规则，用于保护个人数据，并制裁那些滥用数据的人。

GDPR 强调风险思维，先假设风险的存在，然后采用一系列措施来降低风险，直到达到某种程度的安全。该条例的推出是有积极的一面的——太多的软件系统在设计阶段没有考虑到数据的安全问题，这类软件和数据泄露会导致用户的不信任，所以是时候改变这一状况了。

需要了解的关键点

这个话题涉及的范围太广了，所以我打算集中讲解在新开发软件项目时需要注意的问题。关于组织方面的支持和遗留系统有太多东西可以说了，不过这也要看从哪方面来讲。GDPR 不允许例外，所以不管是大大小小的公司、非营利组织，还是政府机构都需要清楚地了解这些条例。

新条例最关键的一点是数据对数据主体的透明度。假设你有一个数据库，数据库里保存了个人数据，那么 GDPR 规定，在使用这些数据时需要对数据主体保持透明。也就是说，你在收集用户数据时，需要让用户知道你在收集哪些数据、用途是什么、谁可以访问这些数据，以及数据会被保留多久。所以，你需要先搞清楚这些问题，并提供明确的文档说明。除了透明度之外，你还需要为用户提供访问数据的途径。数据主体有权验证、修正、导出、移动和删除他们的数据，而你需要为他们提供这些操作接口。

另一个是隐私问题，这个也很重要。从现在开始，隐私问题应该被集成到软件架构里。在推出该条例之前，这些都是应该被考虑到的，但人们总是要等到发生了问题以后才会接受教训。GDPR 应该足够引起我们的重视了，毕竟 2000 万欧元的处罚不是个小数目。隐私涉及到太多的内容，不过本质上是通过控制手段达到保护个人隐私数据的目的。这一般涉及到审计问题，比如谁在什么时候对数据做了什么操作。另外，在保存或传输数据时要注意使用加密手段，避免数据泄露。

你仍然可以处理个人数据，也就是说你仍然有权利收集和处理数据。你可以在指定的时间段内收集和保存个人信息，而处理个人数据可能需要获得授权。

你可以征求用户的同意来收集和处理他们的数据，但 GDPR 不会让你轻易乱来。比如，在向用户展示数据使用条款时，“我同意将我的信息用于营销目的”的复选框不能默认是勾选的。征求条款必须清晰、准确、易于理解，而且不能预先为用户做好选择。用户可以很方便地取消授权。软件设计师需要与软件所有者讨论好这些条款，不能自己随意决定使用哪些条款。

如果软件开发者拥有访问个人数据的权限，那么他们就变成了处理数据的人，也就适用相同的处罚条例。这对于运营团队来说也是一样的，如果他们有数据库的访问权限，他们就负有同等的法律责任。或许你会因此绞尽脑汁，但请注意，在不访问客户数据的情况下仍然是可以做好大部分运营工作的。

识别个人身份数据（PII）

GDPR 只关注个人身份信息（PII）数据，它并不适用于与个人无关的数据，比如产品数据或会计信息。尽管这些在你看来是敏感数据，仍然想保护好它们，但在 GDPR 看来，它们并不是 PII 数据。

GDPR 将 PII 数据分为两类。一种是可以用于识别个人身份的数据，如社会安全保障号、邮件地址以及直接与这些信息挂钩的数据，如订单历史。另一种是高度敏感的数据，比如健康医疗数据、宗教信仰、性别或者从未成年人那里收集到的信息。

要注意，根据 GDPR 条例，一些独立信息的组合也可以用于识别出个人身份，比如邮编、旅行记录、购买商品的地址等等，所以它们也属于 PII 数据。

因为隐私保护条例的出现，大部分数据库里的数据会变成 PII 数据，当然也有一些例外。我估计有 70% 到 80% 的系统数据属于 PII 数据，你要保护的数据不仅仅是社会安全保障号和信用卡号码。

关于包含了 IP 地址和秘钥的访问日志和审计日志已经有过很多的讨论。它们也属于个人数据吗？专家认为它们不算。不过，我们需要看看以后是否会发生变化。我个人建议应尽量避免在这种灰色地带滥用这些数据。这些数据应该得到一定程度的保护，取决于发生数据泄露将带来多大程度的伤害。但我很少看到有 Web 服务器会在这方面采取保护措施。

在设计中考虑隐私问题

只要在开发软件系统时考虑到 GDPR 的要求，就可以以最低的成本遵守 GDPR 条例。这也取决于系统的风险级别：

• 系统是否包含了敏感信息？
• 系统是否包含了一些东西，虽然它们对 GDPR 不敏感，但如果公开它们就会引来危险？
• 如果有人公开了数据库内容，会对你的业务造成多大影响？
• 你的用户数据库的规模是多大？

如果你的用户不多，你所收集的信息既不敏感也无害处，那么可以认为你的系统是低风险的，那么就可以采用一些低成本的方式保护它们。但如果你的系统包含了大量用户的敏感数据，那么就需要更严格的保护措施。

审计是最低限度的要求。审计不仅仅是表面功夫，在发生数据泄露时它可以将受损程度降到最低。在发生数据泄露之后，首先要取证哪些用户受到了影响以及哪些数据被访问过。你需要向数据保护机构上报这些信息。除此之外，你可能需要通知这些用户有关数据泄露的事情。如果没有这些取证，你只能假设所有用户都受到了影响。

审计铁证如山，即使是系统管理员也无法篡改它们。例如，你可以通过审计信息知道系统管理违反了哪些数据操作。这在之前发生过，在以后也会发生。审计信息本身也属于 PII 数据：它们包含了身份识别信息及相关数据。

除了审计之外，还需要限制数据的暴露范围。最好是限制可收集的数据范围和数据保留的时长。在一开始就要采取某种数据归档或清除机制，这些可以事先向用户说明。如果发生数据泄露，那么只有那个时间点的数据会受到影响。很多系统持续收集数据，但不进行清理，尽管数据已经过时。GDPR 建议我们清晰地定义数据的生命周期，并明文记录下来。另外，最好只访问必要的数据，特别是在访问那些敏感数据时就更应如此。

之前已经提到过，对于保存在数据库或文件系统中的数据以及那些在网络上传输的数据需要做好保护工作。加密是必需的，不过它也有自己的不足。加密是一个复杂的过程，实现起来相当麻烦。一般云服务供应商会为你提供一种简单的加密方案，用于加密整个数据库。这种方案很简单，但不牢靠。选择哪一种方式要根据风险程度和数据的敏感程度而定。

匿名和伪造机制可用于保护数据。匿名机制通过遮罩或删除字段从数据中移除身份识别信息，伪造机制则使用假数据替换身份识别信息。但要用好这两种方式都是不容易的，或许并不能完美地达到 GDPR 的要求。当然，除了这些还有其他方式。你可以重新审视你的日志标准和指南，如果日志里没有包含 PII 数据那就最好了，否则的话，就需要做好保护措施。有些日志已经包含了 PII 数据，比如访问日志和审计日志。不要往调试日志中写入用户 ID 和名字这类信息，并将包含敏感数据的日志和只包含一般性系统信息的日志分开保存。

文档化你的系统

GDPR 中提到了合规问题，你可以从文档层面开始，虽然文档化可能涉及众多因素，不过以下列出了一些额外的考虑点：

• 文档化系统的个人数据。
• 文档化数据的生命周期。
• 文档化处理数据的实体。
• 文档化收集数据的基本面。
• 向数据主体说明他们的权利并解释如何行使这些权利。

你要在文档中写明收集了哪些数据、你的目的是什么、数据将被保留多久以及如何处理这些数据。这些文档应该成为数据保护策略文档，并提供给用户。用户的第一项权利就是他们有权知道你的系统收集了他们那些数据。

通过网络传输数据和限定那些第三方实体可以访问数据也是一个很有意思的问题。你可以为此创建一个数据流图，指明数据访问实体、数据流经的层，甚至是数据传输协议。一旦发生数据泄露，这张图有助于你了解数据泄露范围并采取措施降低泄露程度。

或许你还可以把使用了哪些措施来保护数据并达到一定程度的数据隐私安全性记录到文档中。

为用户行使权利提供支持

GDPR 条例中已经列出了用户或数据主体所具有的权利。下面简单列出了这些权利：

• 数据访问权
• 数据纠正权
• 删除数据的权利
• 限制数据处理的权利
• 移动数据的权利
• 数据泄露知情权

但首先需要明白的是，GDPR 并没有要求这些操作是实时或自动化的。事实上，只需要在用户提出请求后的 30 天内给出响应就可以了。可以告诉用户你们不会毫无根据地删除或导出数据，而且要注意不要把其他用户的数据泄露给实际发起请求的用户。30 天时间足够你把数据处理干净，或者可以直接把它们留在一个废弃的系统里。

也就是说，如果你的公司已经具备识别客户、用户或数据主体的机制，并且提供了一些自助服务，那么完全可以把识别权利直接挂靠在自助服务的用户界面上。你的自动化流程能够提供越多的功能，你需要付出的成本就越低，用户的体验也就越好，他们可以进行实时的操作，而不是在发出请求后等上 30 天。

在开发新软件时，如果能够将数据擦除和导出功能都包含在其中就更好了。通过删除数据可以实现数据擦除，但通过覆盖的方式来处理数据会更容易一些。数据的导出格式在现在看来已经不是什么问题，但如果能够提前做好计划，就能事半功倍，即使你的领域没有提供与 GDPR 相关的用户界面。

对于数据主体来说，为他们提供一站式的服务是最为重要的。

要不要接触数据？

在 GDPR 的约束下开发软件时，需要问自己一个问题：你需要接触数据吗？或许你本来不想接触到数据，因为那样会让你承担法律风险。为了避免担上 GDPR 的罪责，只要确保在任何情况下都没有访问 PII 数据的权限就可以了。你还需要确保在各个合同中写明了这些。不过要完全避免处理 PII 数据并非易事，因为 PII 数据可能存在于日志文件、测试环境和生产环境的紧急补丁中。但如果你想避免卷入法律责任，就必须想办法处理上述的情况，把你自己与数据完全隔离开。

另一条路是坦然成为能够接触数据的人。这样你就可以自由访问个人数据，只要你把访问记录保存下来，并在允许的范围内处理数据。这样你就负上了法律责任，所以要注意不要触犯法律。当然，这是在不得不访问 PII 数据的情况下才需要这么做。

大部分软件项目不需要暴露实际的 PII 数据，或许这才是最好的选择，但可能需要借助新的技术和工具。

戳破 GDPR 迷思

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

数据主体要求导出数据时并不会得到与个人数据有关联的其他数据。

用户权利不会被自动行使，所以在操作数据前最好先检查一下用户身份并验证用户请求的合法性。如果数据库里没有唯一的安全保障号或许就难以实现这点，不过要拒绝一个请求可以有很多正当的理由。

GDPR 并没有要求你对所有东西都用 2048 位的秘钥进行加密。保护措施是用来降低风险的，而每一个系统所面临的风险都是不一样的。

GDPR 不会阻止你收集和处理用户数据。把握好透明度、做好数据安全，不要过分地收集超过实际需求的数据就不会有什么问题。

数据泄露并不意味着直接就会受到 2000 万欧元的处罚。虽然有这个可能性，但在阅读了这篇文章之后，如果你接受了这些建议，那么就可以做到降低处罚力度。做好现在能做的事，并为将来做好长远的计划。如果真的要面临处罚，GDPR 为此列出了一系列问题，用于决定处罚的力度。

保护好数据隐私并不只是为了逃避处罚。之所以推出这项条例，是因为每天都有越来越多的数据被收集，越来越多的数据泄露事件在发生。数据泄露所造成的损失比处罚本身要严重得多，客户会因此丧失对你的信任。不过，处罚可以成为敦促公司的一种方式，让他们在开发或购买软件或信息系统时，花更多经费在保护数据安全和隐私上。

云服务无法逃逸于 GDPR 之外，实际上，他们比传统数据中心更需要遵守 GDPR。不过，他们在将机密数据传输给第三方机构时，问题会变得非常复杂。

GDPR 并不要求你对所有的东西都进行审计或记录到日志当中，也没有要求你一定使用入侵检测工具。如果有这些工具当然是最好的，但问题的核心是要评估系统的风险，并做好适当的保护措施。

总结

离正式实施 GDPR 没有多少时间了，新开发的系统都应该遵守 GDPR。该条例并非尽善尽美，因为它还在演化，不过大部分都是有关数据泄露、审计和处罚的。我希望这篇文章可以帮助你避免付出惨重的代价。

我认为即将到来的数据保护条例雄心勃勃，有着它积极的一面。在你改进数据使用透明度和提升隐私安全性之后，用户会更加信任你，他们或许愿意让你将他们的数据应用在各种数据分析和市场营销活动中。或许在 2018 年会出现一阵骚乱，不过我相信从长远来看，GDPR 会让我们的数据世界变得更安全、更透明。

如果你处在灰色地带，不确定该做些什么，那么就根据常识来做。想想最糟糕的情况，比如数据泄露。如果你的数据库、数据快照或 Excel 文件落入了错误的人手中，并被公开，那么你如何知道究竟什么被泄露了、是谁造成的泄露以及需要通知哪些用户？向别人解释你是如何保护数据的会对你造成困扰吗？如果不会，那么你所做的将有助于减轻处罚。让我们一起构建一个更安全的信息世界。

关于作者

Arto Santala 是 Solita Oy 的软件架构师，他拥有 20 多年软件开发经验，擅长自动化改造，使用敏捷方法来完成工作。

查看英文原文： What Should Software Engineers Know about GDPR?