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