BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

GDPR实务

| 作者 Jon Topper 关注 0 他的粉丝 ,译者 张卫滨 关注 11 他的粉丝 发布于 2018年4月9日. 估计阅读时间: 17 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

核心要点

  • 从一开始就要将构建强身份识别的理念贯彻到基础设施中,除了人以外,还要考虑识别服务器和容器;
  • 使用基于访问控制的角色,并遵守最少权限原则,只允许真正需要资源的实体才能访问这些资源;
  • 考虑详尽、防篡改的审计日志并根据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会使用机器学习来构建一个正常的模型,以便基于此查找异常,同时还会对典型的“个人”数据进行模式匹配,比如信用卡、邮编以及电子邮件地址。如果看到大量这样的数据传出你的网络,这可能就是一个红色信号,值得进一步地探查。

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

其他好的习惯

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

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

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

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

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

考虑你所使用的外部服务以及你传递给他们的数据。比如,如果你使用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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT