前言
关于GDPR是什么，可能许多同学之前并不太了解，至少笔者在之前也是不清楚的。GDPR全称为通用数据保护条例，General Data Protection Regulation。它是一项来自欧盟的关于计算机数据保护相关的条约，旨在规范系统如何收集，管控用户私人数据的种种行为。但是当前的一些存储系统并没有完全符合里面的原则规范定义，比如典型的一点关于数据的清除。
GDPR条例中规定个人用户有绝对的权利发送请求让系统清除其数据并且这些数据在被删除会不能被访问到。当前的HDFS/Ozone系统其实也并未完全做到这点，为什么这么说呢？本文笔者来聊聊分布式存储系统内关于GDPR中的数据清除原则的内容。
HDFS存储系统数据的完全删除
我们平时在使用一些分布式系统做数据存储的时候，也经常会涉及到数据删除的操作，从用户角度来说，这些数据也确实是被删除了。因为他们从原先的目录下看不到他们之前存在的文件数据了，不过这里笔者想说的是：这是否意味着数据的完全删除了呢？数据真的彻彻底底地从系统中被物理清除了吗？
按照GDPR数据保护条例的说法，当用户发出明确的删除数据的之类后，系统应立即使其数据在系统中被彻底“遗忘”，无法被访问到。注意这里的关键词是“遗忘”和”无法被访问“，换句话，GDPR关于数据清除的一个核心准则在于数据的不再可见，物理删不删除倒不是必须的。
那么按照上述规则定义，当前一些成熟的分布式存储(比如HDFS)系统是否符合这个规则呢？答案是否定的。
HDFS的删除块行为是异步延迟执行的，它通过一个额外的Replica Monitor线程进行周期性的块处理操作，让后将待删除块信息通过心跳的方式传达到下面的节点内。所以说这个过程是有延时的。假设我们做一个极端情况的模拟，我们将Monitor线程的扫描周期调成1周，那么最早被HDFS用户删除的块需要等1周的时间才会被最终物理删除掉。而在这1周时间内，这个块数据对于其它用户通过非系统方式访问还是可见的，比如访问实际存储节点的物理文件访问。因此我们说HDFS的这种数据删除行为违背了GDPR中的数据清除原则。
在许多分布式存储系统中，出于性能的考虑，许多采用的都是这种延迟删除的设计思路，那么有什么解决方案能够兼顾系统性能的考虑，同时遵守了GDPR中的数据清除原则呢？
基于加解密的输入输出流的数据保护方案
在上文提到的关于数据的清除原则中，里面比较核心的一点是：当用户明确发出数据删除请求后，此数据将马上从系统中被”遗忘“，也就是无法被访问。通过系统元数据简单的更改并没有改变数据还是能被物理访问的现实，于是按照我们的惯性思维，那我们只能通过物理同步删除的方式来做吗？这种方式可是会带来性能问题的。
其实这里还是有别的办法的，以下是其中的关键点所在：
数据的物理删除可以达到数据的不可见的效果，但是后者并不完全等同于前者，比如通过数据加密保存的方式也可以达到不可见的效果。
通过加密的方式，我们可以在保留异步删除行为之下，保持其数据的不可见性。在加解密数据过程中，需要构造一个新的密钥key，用于做加解密算法的计算，然后会有以下过程：
1)数据写入时，用密钥key进行加密写入操作
2)数据读取时，用密钥key进行解密读取操作
这里的密钥key是一个对称key的角色。这个信息它需要额外被保存到文件数据的元信息内。
有了密钥key后，我们可以利用这个key来做用户数据可见性的完全控制了，当用户发出删除数据请求后，我们第一时间将此密钥key进行同步删除。这可以解决之前非加密模式的两种corner case：
- 用户通过了解用户路径的删除文件名称规则，在物理文件被删除之前，还是可以进行异常访问，因为有些系统在删除发生之后，会先在原文件名称下带上删除标记，相当于只是做了一个rename操作。
- 用户数据的物理访问在加密模式下彻底起不了作用了。
加解密实现我们可以采用常用的CipherInputStream/CipherOutputStream类的使用。
加解密模式下的数据读取过程的流程图如下所示：
数据删除操作前过程，正常读写过程：
注意这里元数据管理服务只是保留了密钥key的属性信息，然后客户端得到这些属性信息重新构建出密钥key，然后进行后续操作。
数据删除操作后，用户读取数据的行为将会失败：
另外要说明的一点，以上的加解密行为在本质上并不是一个涉及Security的功能，区别点在于以下2点：
- 它出于的目的不是数据安全
- 它不需要额外的密钥Key管理服务
以上就本文所要阐述的所有内容了，部分思路借鉴于HDDS-2012的实现设计。
引用
[1].https://issues.apache.org/jira/browse/HDDS-2012 . Support GDPR-Right to Erasure feature on Ozone