GDPR实务

by

• Jon Topper

摘要：

按照GDPR的要求，处理个人数据变成了一项组织范围内的责任，但是在实际操作中，我们可以提供很多的支持工具，有助于在各个方面解决这个问题。

核心要点

• 从一开始就要将构建强身份识别的理念贯彻到基础设施中，除了人以外，还要考虑识别服务器和容器；
• 使用基于访问控制的角色，并遵守最少权限原则，只允许真正需要资源的实体才能访问这些资源；
• 考虑详尽、防篡改的审计日志并根据GDPR的需求思考数据保留策略；
• 在没有屏蔽个人数据的情况下，禁止从生产环境复制数据到开发环境中；
• 使用可信供应商的工具来监控和响应网络上的安全事件。

什么是GDPR，我为何要关心它？

GDPR（通用数据安全规约，General Data Protection Regulation）的目的在于帮助欧盟（EU）的公民更好地控制他们的个人数据。持有欧盟国民数据的所有组织（不管是在欧盟内部还是欧盟外部），该规约都适用，所以它的范围是非常广泛的，这给一些组织带来了恐慌的情绪。

造成恐慌的原因在于这项规约会引入超过2000万欧元或年度全球营业额4%的惩罚。这是比数据保护条令（Data Protection Directive）（GDPR取代了该条令）更沉重的惩罚，因此它强迫我们在董事会的会议上，更加严肃地讨论合规问题和责任问题。

尽管如此，实现GDPR的艰苦工作却遍布组织的各个角落。作为系统管理、ops、DevOps或SRE的实践者，我们都需要关心些什么呢？

阅读规则

如果你要遵守某种形式的约定，我推荐的做法是花些时间阅读约定的文本，以便于了解所使用的语言，这样的话，在与审计人员或顾问讨论细节的时候才能处于更有利的位置。但是，在GDPR规约中，不要指望能够获取任何有用的技术性答案。这是一个立法性的工具，是为律师设计的，而不是面向工程师的安全指南。使用过非常规范化的PCI-DSS标准检查列表的读者可能会非常失望，因为这里没有与之对等的内容。

这既是一个好消息也是一个坏消息。GDPR的很多条款与它替代的数据保护指令并没有什么差异。坏消息是很多的组织在支持这两者方面做得都不够好。

从根本上来说，大多数的合规机制都是关于数据安全的，它们的内容基本上可以归结为两个主要的关注点：“不要让数据流出”以及“不要让坏人进来”。GDPR扩展了这些基本的理念，它要求个人有权利了解他们的数据是如何使用的、索取个人相关数据的副本，并且允许个人要求删除与他们相关的数据。从技术的角度来看，这都会带来明显的影响。

特别是第25条规定了“设计中和默认的数据防护”。那么，我们应该将哪些设计的考虑因素构建到系统中呢？

身份标识与访问控制

从一个系统的角度来说，良好的安全首先需要强有力的身份识别（identity）管理。每个与系统交互的个体都应该有自己唯一的身份，这些信息在某种目录解决方案中统一进行管理。这可能是你们自己运行的某个服务，比如Active Directory或LDAP，也有可能是像Okta这样的公司所提供的SaaS解决方案。这个身份识别服务会管理凭证信息，比如密码以及用于其他认证因素的安全token。通过提供以该服务作为支撑的SAML或OAuth2 IdP（身份识别提供者），我们可以将这个身份识别用到任意数量的独立系统中，这样的话，就允许用户只使用一组凭证信息就能进行登录了。

尽管这种用户信息联合使用的更常见场景是外部的SaaS服务，但是它也可以用于内部的Web系统。使用Traefik或类似的软件（比如谷歌的IAP），我们能够在已有的Web应用前面实现一个身份感知的代理，这样的话，用户必须使用他们的单点登录凭证来进行登录，在此之后才能访问应用本身。

在Amazon Web Services中，IAM（他们的身份和访问管理服务，Identity and Access Management service）和Cognito都可以使用联合的身份识别源，这样的话，就允许用户使用单点登录凭证来登录服务了。

这其实并不局限于Web界面：Hashicorp Vault提供了一个安全API服务，它能够使用外部的IdP作为用户的身份识别源。在识别完之后，用户可以要求Vault颁发签名过的SSH证书，借助该证书就允许以shell的方式访问远程系统，或者提供对数据库或其他服务进行访问的临时凭证。

在将身份识别的事情做好之后，下一个要考虑的事情就是基于角色的访问控制（Role Based Access Control(RBAC)。为每个用户逐一管理权限是非常繁琐乏味的，伸缩性很差并且很难从审计的角度进行思考。在RBAC模型中，我们会创建角色，并将权限赋予这些角色。举例来说，某个角色可能是“数据库管理员”或“客户服务代理”。这些角色都有不同的权限，数据库管理员可能具有通过shell访问数据库集群的权限，但是没有访问客户服务Web前端的权限。通过为用户赋予角色，我们可以很容易地看到每个人具备哪一组权限。

身份识别并不局限于人，物理服务器、虚拟机、容器以及应用都可以进行识别。像AWS这样的云厂商以及像Kubernetes这样的编排平台对它们的组件都有很强的身份识别的概念。在AWS中，EC2实例可以访问它们的“实例身份识别文档（instance identity document）”以及一组签名，它们可以用来校验数据的真实性。身份识别文档可以用来向Hashicorp Vault证明实例的身份，这样的话就能根据实例所分配的角色，安全地向该实例提供秘密的数据。在Kubernetes调度的容器中，存在类似的工作流程建立身份识别。通过这样的强身份识别理念，我们没有必要将秘密数据，比如数据库凭证或API key直接放到应用配置中了，它们可以进行统一地管理。

现在，我们可以将角色赋予人以及系统中的组成部分。每个角色应该给予完成它的工作所需的最小的一组权限。在向合规审计人员阐述哪些人或系统能够访问哪些数据对象时，这种最小权限原则能够让我们的工作变得更加简单。

日志与审计

确定了哪些人和系统能够访问哪些数据条目之后，我们需要记录对数据的这些访问，这样的话，才能向审计人员展示我们的访问控制都按照正确的方式在运行。我们还需要能够证明，在日志数据写入之后，就再也不能篡改了。

在AWS中，我们可以使用CloudTrail日志，它可以记录所有针对资源的AWS API调用。这些日志应该写入并加密到S3存储中，专门的安全日志账号才具有该存储的拥有权。对这个日志账号的访问要进行严格控制，这个bucket的策略要确保一旦写入之后，日志就不能修改或删除。

其他的系统和应用日志应该按照类似的方式进行聚合，直接将它们从主机服务器发送至安全、防篡改的存储中。在这里所使用的日志传送器应该配置为逐字传输日志数据的副本，这样的话，我们就能向审计人员表明存储的日志跟它们的原始形式相比，并没有进行修改。

如果你还使用像Elastic的ELK技术栈来查看和搜索日志数据的话，那么可能会有很多原因导致我们在传送的时候要修改日志数据。在这种情况下，使用一个附加的日志传送器配置来传送这些不够安全的日志副本。

日志中有可能会包含GDPR术语所定义的个人数据，因此这些数据需要在合适的时间点上过期并删除。这个时间点要取决于你们特定的工作负载以及所要遵守的合规义务。GDPR的第17条涵盖了“数据擦除的权利（right to erasure）”，根据该条款，数据对象可以请求删除任何关于他们的个人数据。默认情况下，如果你持有尽可能少的数据，那么实现起来就会更简单一些。

第15条涵盖了“数据对象访问其数据的权利”，按照该条款，人们可以要求我们提供所有关于他们的数据。对于主存储中存在哪些个人数据以及这些数据如何互相关联，你可能有很好的掌握和理解，但是这些数据最终将会如何出现在日志中可能就不那么明显了。因此，如果用户具备请求访问个人数据的权利，这可能意味着我们需要能够搜索某个特定用户的日志条目。在这种场景下，结构化（而非自由文本）的日志数据会更加有用，像AWS Athena这样的搜索工具会更加便利。

为了更容易地实现，你可能想要软件开发人员在日志框架方面采取一些操作，将不必要的个人数据从日志事件中移除掉。但是需要记住的是，按照GDPR的规则，设备识别符、IP地址、邮编等都可以视为个人数据，因为根据这些数据都能识别出每个个体，所以也要将它们考虑进来。

备份

我们很可能会将个人数据保存到备份之中，因此，GDPR有可能会影响到我们的数据保留策略。按照数据移除的权利，数据对象可以要求我们删除掉与它们相关的数据。如果我们只在生产系统中删除了对象的数据，那么在备份中我们其实依然保有副本数据。

关于这个问题，你可能会想要咨询一位友好的律师，但是根据我的研究，在生产数据库中移除掉数据，然后告诉数据对象尽管他们的数据依然还在备份中存在，但是它们会在30天或者保留策略规定的时间之后过期，这样的解释应该是合理的。

如果你需要从备份中恢复数据的话，你需要再次清除掉那些数据对象的数据，所以删除的对象需要进行跟踪，至少在保留策略的时间范围内如此。

创建一个“备份管理员”的角色，阻止其他人访问备份，限制具有此角色的个体的数量，这样的话在备份保留的时间段内，就能减少访问已删除数据的个体的数量，这似乎是一项非常合理的举措。

开发/测试数据集

有些公司习惯于将生产环境中的数据恢复到staging或开发的环境中，以便于进行测试。在staging环境中这样做还有一定的道理，那就是允许按照与生产环境相同的方式来访问这些数据。但是，如果允许所有的开发人员访问完整的数据集就是GDPR所完全不允许的了。

现在，已经有商业的解决方案（比如RedGate软件的Data Masker）能够接受一个数据集并掩盖敏感数据，这可以作为ETL操作的一部分，将生成的数据放到另外一个数据库中。我曾经见过有的组织尝试自己构建这样的环境。

它还能够用来生成开发环境所需的虚拟数据集，有些工具的存在也让这种数据生成变得更加便利。你需要确保生成的数据具有和现实数据相同的规模和基数，否则的话，开发系统时的表现将会大相径庭。

至于哪种方式最合适则取决于工作负载。在这里与开发团队的紧密协作是非常重要的。

监控与告警

按照第33条和34条的规定，如果出现数据泄露的话，你需要通知受到影响的数据对象和监管机构，在欧盟的每个成员国中都将会有一个这样的机构。

显然，要做到这一点，你首先要知道自己已经被攻破了，所以在这里监控、安全扫描以及告警都会发挥作用。通常来讲，我是开源解决方案的拥护者，但是在安全监控领域，考虑供应商应该是更为明智的选择，因为它们有整个团队在从事这样的工作，能够保证它们的解决方案考虑到了最新的安全风险的细节。

Web应用防火墙（Web application firewall，WAF）能够帮助我们抵御Web应用和API的常见攻击模式，监视这些攻击的轨迹并在源头上屏蔽它们。例如，WAF可能会扫描每个HTTP请求的内容并对这些内容应用一组正则表达式，这些表达式能够匹配已知的SQL注入攻击。如果模式匹配的话，请求会被屏蔽掉，而不会将其转发到后面的应用集群中。

扫描出站的网络流量能够有助于识别数据泄露，一些现代的智能工具比如Darktrace会使用机器学习来构建一个正常的模型，以便基于此查找异常，同时还会对典型的“个人”数据进行模式匹配，比如信用卡、邮编以及电子邮件地址。如果看到大量这样的数据传出你的网络，这可能就是一个红色信号，值得进一步地探查。

在网络内部，入侵探测工具能够帮助我们识别系统是否正在被恶意的人所访问，这要么通过扫描网络流量要么通过观察日志数据来实现。AlertLogic和ThreatStack都在该领域都提供了方案，AWS GuardDuty也提供了一些这样的特性。

其他好的习惯

在这里，我们还有一些其他值得采用的安全实践。

你应该加密所有传输和静态的内容。现在，其实真的没有理由不这样做，云厂商甚至提供了基础的支持来简化我们的工作。从一开始就将它设计为基础设施要比以后再进行改造更加简单直接，所以请确保它是一项预先考虑的设计因素。

网络设计依然非常重要。保护你的周边环境，在网络中使用主机防火墙和安全分组，以限制对系统的访问。将管理工具与其他的系统分离开，并让每个环境互不相同，防止在它们之间泄露数据。在有些场景下，将不同类型的数据隔离到不同的数据库中是较为恰当的做法，这样能够进一步限制它们在网络上的访问。

另外还有一点无需多言，你需要有一个常规的软件补丁机制，这并不局限于你自己的基础设施组件。要确保你的应用程序依赖使用的是最新的版本，并在CI管道中使用像Snyk这样的工具，确保在将代码投入到生产环境之前，会收到依赖漏洞的告警。一些严重的事件，比如Experian数据泄露，通常是依旧使用不安全的库所导致的。

安全性对于开发团队的重要性并不亚于运维团队。像OWASP Zap和Gauntlt这样的工具能够帮助我们在应用上线和产生问题之前，在应用程序的代码中查找安全问题。

考虑你所使用的外部服务以及你传递给他们的数据。比如，如果你使用SaaS日志提供商的话，那就需要注意你可能会将个人数据传输到你自己的网络之外，它们也需要为你的数据对象承担相应的义务。

结论

对于任何使用欧盟公民数据的人来说，GDPR都是不可避免的现实。如何处理个人数据是整个组织层面的责任，但是在业务操作方面，我们可以提供一些支撑工具在多个方面来处理这个问题。

GDPR并没有对数据保护指令（Data Protection Directive）进行太多的扩展，所以我在这里提到的内容可能是你们已经遵循的良好实践。对违反GDPR的惩罚要高得多。我们现在要停止将安全视为一种义务，而是应该开始让客户的数据真正成为隐私。

关于作者

Jon Topper是The Scale Factory的CTO，这是一家位于英国的DevOps和云基础设施咨询公司。他从1999年就开始使用Linux Web主机基础设施，最初就职于ISP Designer Server，随后是移动技术创业公司Trutap。从2009年开始，Jon和The Scale Factory致力于为各种工作负载类型设计、构建、扩展和运维基础设施。Jon对系统架构和构建高效团队有着特别的兴趣。他经常在英国和国际上针对DevOps和云基础设施的话题发表演讲。

查看英文原文：GDPR for Operations