数据销毁，对数据中心运营至关重要

人们常问，到底为什么要 销毁数据 呢？为什幺要 销毁文件 呢？销毁与数据中心运营有什么关系呢？

其原因听起来比较残酷。如果你是无名鼠辈，有一些人会关心你，他们把无数老百姓的数据凑成一个叫大数据的东西去兜售；如果你小有声望，会有一批人关心你的隐私生活和朋友圈，你的数据经贩卖后流入市场会成为人们茶余饭后的谈资；如果你是名人、知名公司或响当当的品牌，无数人都在盯着你，渴望你言行出轨，期待你被举报被陷害被曝光，你的这些不幸数据却是他们的自媒体的绝佳内容，是获得流量和粉丝的强大工具，是他们圈钱的秘密武器。

数据泄露的数量让人瞠目结舌

世界上每天产生多少数据呢？ 2.5P比特。1P是一百万的三次方，90%的数据是最近这两年产生的。大部分数据源于数据中心的服务器，为什么这么说呢？你兢兢业业地经营着自己的社交媒体，文章和图像需要上传到平台的服务器上别人才能欣赏到；你在电脑上编辑邮件和PPT，公司的云端亦有备份，方便了你在另一台电脑上办公；公司协调办公和ERP产生的数据都存储在远方的服务器上，这样才能实现随时随地办公的梦想。服务器承担了数据存储和计算的核心工作，而数据中心又是大规模存放服务器的地方。

数据中心拥有海量数据，必须进行数据销毁才能让业主放心

既然数据中心是数据存储和处理的集中场所，海量数据的安全防护就格外重要了。传统上，数据中心的信息安全有物理保护和访问控制二种机制。物理保护是指门禁控制和物理接触控制，对于哪些人在物理层面上可以接触某台服务器的存储介质做严格的权限分配。访问控制指在逻辑层面上对数据访问权限做出详细规定，防止数据被没有权限的人获取。当然，安全策略上还有网络安全、防火墙、冗余备份、逻辑隔离等手段。不难发现，对于数据的生命周期而言，传统的安全策略聚焦于数据生命周期的产生、传输和存储等前期和中期阶段，在数据生命周期的尾声却出现了弱管理甚至忽视。下图列出了数据生命周期的六大环节，第六个格子正是末期管理之销毁，实际上却常常被忽视。

数据生命周期管理，销毁环节常被忽视

你也许会辩解，我们的硬盘数据有加密，别人不知道密钥就无法读写数据。但是，总有一个人知道你的密钥，难道不是吗？这个人或许对你忠诚耿耿，绝对可靠，但是你能保证他/她会效忠致死吗？与其把宝压在一个人身上，不如把安全交给销毁处理，这是明智的做法。有的风险不值得冒！

Stellar公司的调研发现七成数据残留有风险

你也许会辩解，我们的硬盘是RAID5读写，信息分布在不同的硬盘上，一块硬盘的数据被读取了不会影响整个系统的信息安全。但是，当你的IT经理计划硬件资产淘汰时，谁会关心几百块硬盘下架后的摆放顺序呢？谁又会去安排人员特意把同一RAID5下的盘摆放在不同的仓库呢？实际操作中，我们从来没有遇到管理如此精致的IT主管。与其痴心渴望你的IT经理如此精致，不如请一家 销毁公司 及时销毁数据和文件。这样的风险不值得冒！

你也许会辩解，这批硬盘由实习生使用，没有接入公司的ERP等核心系统，数据都是无关紧要的。请看看 数据残留大揭秘 吧，你就明白了数据其实没有紧要次要之分，只有你的IT政策是合规还是不合规之分。IT治理不合规时，没有数据是保密的和隐私的；IT治理合规时，数据没有不含隐私的也没有不敏感的，所有数据都需要保密，否则你的数据资产极有可能变为你的负债。

你必须面对一个极其残酷的现实：你的数据不一定被泄漏，一旦泄露则 身败名裂 ，你觉得值得冒这个风险吗？下面这个视频讲述了 数据销毁的必要性。

为什么要销毁数据

海量数据需要海量存储空间。这些数据中大部分都是交易数据、过程数据、用户数据或者中间计算数据，数据中心永久存留这些数据并无益处，因为存储空间需要购买，空间维护需要费用。1G的存储通常需要0.3元，1T的存储量则需要300元，若加上数据维护和电力成本分担，1T的数据量每年约需要350元的成本。与其让这些数据在数据中心的存储设备里睡大觉，不如及时销毁和清理，节省出来宝贵的存储空间迎接崭新数据的到来。这样便大大节省了数据中心的运营支出，提升了生产效率。那么， 如何销毁数据 呢？ 数据销毁 和 文件销毁 ，这里也 大有学问 。

首先，数据质量远比数据的数量重要，数据中心为了不断增长的数据而在软硬件上连续投资的做法，实在是一个代价昂贵的错误。需要注重有效数据的处理。表面上看，数据中心的数据总量增长是非常迅猛的，全球数据量以每年58%的速度增长，不到两年就翻一倍，在未来这个速度会更快，其中大部分数据都是在数据中心里产生的。我们的数据中心是不可能每两年就扩容一倍的容量，所以任由数据量增长下去，数据中心会很快陷入不断扩容的怪圈，结果数据中心的规模越来越大，而数据中心业务并没有实质增长，数据中心的盈利水平却在下降。就好像是一个胖子，总是吃炸鸡可乐而缺少体育锻炼，将会越来越胖，但实际上身体的体质在不断下降，最后除了一身赘肉，什么也干不了。数据切不可成为数据中心的负担，该清理时就清理，该销毁时就销毁。

其次，我们要对数据进行销毁，就要对数据进行分门别类的管理，分清哪些数据是有用的，哪些数据是无用的。这就要从数据产生的源头做起。在数据中心产生增量数据时，要将这些数据进行分类、整理归档，存储到分好类别或有标签的空间里去，同时对这些数据进行明确标记名称，通过名称就可以知道数据的大概内容，以便作为数据是否有用的判断准则。如果在数据归档记录时类别不明确，那么后来就无法做到精准销毁。管理这些数据是非常复杂的，涉及到数据辨识、清理、优化等等，而这些工作又是周期性，需要花费大量的时间和人力，且不会带来明显的收益，因此数据精细管理常常被忽视。其实，数据的有效存储工作将帮助数据中心产生长期和正面的收益，且越早部署越早行动收益越明显。

硬盘销毁、数据销毁、文件销毁的行业标准

第三，数据的销毁绝不是简单的删除清空这样简单，需遵循 数据销毁的行业标准 。销毁的手段也有几种，这和你希望达到的效果有关。一般销毁分为软件销毁和硬件销毁两种。软件销毁指在磁盘轨道上写入大量垃圾字节，导致磁盘数据无法读取和恢复。绝大多数情况下，硬盘可以继续使用，无需外置工具，只要硬盘能读写就可以使用这个方法。销毁过程慢，通常要1到3个小时才能完成一个硬盘上的数据销毁，DOD/3Pass标准耗时1个小时以上； GUTMAN/7Pass标准需要3个小时以上。美国国防部的DOD 5220.22-M标准是应用最广的一套软体规范，许多人都把DOD 5220.22-M直接当作数据清除与销毁的标准。软件销毁常用的方法还有：格式化硬盘、硬盘分区、文件粉碎软件。格式化仅仅是为操作系统创建一个全新的空文件索引，将所有的扇区标记为“未使用”状态，让操作系统认为硬盘上没有文件，因此，若采用数据恢复工具软件是可以恢复格式化后数据区中的数据的，格式化也分高级格式化、低级格式化、快速格式化和分区格式化几种。低级格式化的销毁最为彻底，很难通过软件再将已经销毁的数据还原回来，硬盘存储空间得到充分释放。用硬盘分区的方式销毁数据，也只是修改了硬盘主引导记录和系统引导扇区，绝大部分的数据区并没有被修改，没有达到数据销毁数据擦除的目的。文件粉碎软件是专门用于彻底删除文件达到数据销毁目的的，在网上也出现了不少，一些反病毒软件也增加了数据销毁数的功能。他们用于处理一般的私人数据可以，但不能用于处理带密级的数据。软销毁一般只是将数据文件覆盖到无法识别，并不能真正将磁盘数据擦除。操作系统由于考虑到操作者操作习惯或者误操作，以及数据销毁后各种非常情况等诸多方面因素，特意安排了删除后可恢复的后门。用户所使用的删除命令，只是将文件目录项做了一个删除标记，把它们在文件分配表中所占用的簇标记为空簇，并没有对数据区进行任何改变，也就是没有对这些信息做任何数据擦除、数据销毁的操作，这样数据其实依然占用存储空间，并没有达到节省存储空间的目的。硬件销毁则通过采用物理、化学方法直接销毁存储介质，以达到彻底的 硬盘数据销毁 的目的，比如粉碎硬盘、高温焚烧硬盘或折弯硬盘。还有一种硬销毁是采用专用的 硬盘消磁机 来彻底销毁数据。不管是直接对硬盘进行消磁，还是对硬盘进行折弯，硬盘将被损坏，不仅数据不能被恢复，硬盘也无法二次使用。这种硬销毁往往用来对已经故障的硬盘进行处理，避免故障硬盘里存着的数据被坏人恢复出来。当然，在IDC大规模淘汰服务器时，通常采用这种方法 销毁硬盘数据 ，速度快且销毁彻底。

硬盘数据销毁的方法对比

数据可以是资产，也可能是负债。数据中心拥有海量数据，数据外泄会伤害品牌、损失声誉并引发诉讼，数据维护成本居高不下会拖累公司的财务业绩。如果不及时清除数据，数据资产就演变为你的负债。及时对数据中心的数据进行销毁，不仅可以节省存储空间，节约运营成本，还可以提升信息安全，避免数据泄露。所以， 彻底销毁数据 对于数据中心运营至关重要。

以前曾经介绍过关于 KMS的用法 ，其中，提到了它的优点和用处，我们使用的场景有如下几点:

如果脱离AWS，选择好像还真是不太多，Harshicorp的 Vault 是我仅知道的一个， RatticDB 算半个吧。

Vault提供了对token，密码，证书，API key等的安全存储(key/value)和控制，。它能处理key的续租、撤销、审计等功能。通过API访问可以获取到加密保存的密码、ssh key、X.509的certs等。它的特性包括:

因为使用Vault的目的是为了

Vault存储[backend( https://www.vaultproject.io/docs/secrets/index.html)] 可以是

我在用Docker启动Vault服务的时候使用的Production模式，为了简单使用了磁盘作为存储，但是为了persist，所以将valut的文件存在了docker volume上面。

docker-compose 文件如下:

创建volume，启动vault服务器，配置通过环境变量 VAULT_LOCAL_CONFIG 传入。

从本地的 8200 端口应该就可以访问到了:

下面的API请求可以对Vault进行初始化，两个参数的意思将master key分成几份以及还原，这里就用1吧。

返回结果:

第一个是master key的public key，第二个是unseal key,最后一个是root token。unseal vault之后才能验证进行具体的操作。

结果:

为了安全起见，我们可以用root token创建出有限权限的新token，来继续后面的操作。假设这个token可以读写的路径为 secret/* 。在这个之前我们先创建访问这个路径的policy:

对应的创建 user-policy :

然后我们分别创建两个token，admin token和 user token:

这样就有了对于 secrets/* 路径下进行读写的两个 token，可以尝试去admin的token去添加新的键值对:

这样就有了基本的权限管理。假设vault服务器和应用服务器或者CI的服务器部署在同一私有网络中，应用服务器和CI slave是不可以ssh的，那么通过应用服务器或者CI在启动的时候通过HTTP请求，利用读权限的 user-token 就可以拿到API-TOKEN，同时没有暴露给外部。

AWS的EC2 instance上可以绑定 instanceProfile , instanceProfile对应的是IAM的role，这个role可以设置对AWS资源的访问权限，比如对S3某个bucket的写权限，或者对Dynamodb的写权限等。Vault提供的AppRoles的功能比 instanceProfile 要差很多，不过确实可以将机器和一定权限的Role绑定起来，控制访问的范围。

允许使用approle的验证方式同时创建一个给CI slave使用的role:

下面的API请求可以拿到 role-id ，以及根据 role-id 生成 secret-id ，利用它们可以登录获得从vault读取数据的权限:

使用 secret_id 和 role_id 联合登录，拿到新的token:

然后利用 client_token 去读取前面写入到vault中的search api token:

AWS的EC2 instance的服务器，在启动时，可以绑定一对ssh keypair，以方便用户使用缺省的 ec2-user ssh到服务器上。从最佳实践的角度来说，应该把服务器当做immutable的设施，不允许ssh。但是现实比较嘲讽，这样的需求仍然存在，那么我们可以换种方式，尽量做好ssh key的管理。

比如，对于每个新启动的服务器，动态的生成一对ssh keypair，只应用在这台服务器上，服务器销毁后，吊销key pair。

Vault提供了ssh keypair的管理功能，利用这个功能我们可以对key的生命周期的管理。它支持两种方式:

要让vault发放keypair, 需要先注册一个private key，这个key必须有服务器的管理权限.之后，你需要创建一个role，包括一些限定条件，如admin用户的名字，缺省用户，目标服务器的IP地址应该匹配的CIDR地址，具体过程如下:

整个的过程大概是这样，vault利用注册的private key登陆到目标服务器上，然后将新生成的key pair中的public key写入到目标服务器的 authorized_keys 文件中。在你想登陆到服务器上的时候，用对应的client token验证，获取private key，ssh登陆。key有过期时间，过期之后就被revoke了。

我觉得全站https困难之一就在于PKI的管理，今年出现过几次certficate过期导致的产品环境的问题，还好及时的切换到了AWS Certificate Manager，免费而且到期自动续租，基本上不用担心管理的问题了。而我们原有的内部PKI管理要稍微麻烦些，需要用自己业务线的LOB Intermediate CA去签发新的certs，运行一些自动化的脚本，还得从RatticDB里面找到对应的private key。

但是如果基础设施不是基于AWS，好像就没有很合适的工具了，只能自己维护PKI，Vault也提供了PKI的管理，可以在这方面提供帮助。考虑环境的一致性，开发、测试以及staging也需要certificate，我觉得这个功能是有意义的。

Vault会安全的保存Root CA 的private key。 可以通过http请求拿到ca的pem文件。

需要给Vault配置访问CA和CRL(certificate revocation list)的地址。

创建intermediate CA.

把这个csr内容存在 example_lob.csr 文件中，请求root ca签发这个intermediate ca。

得到Root CA的签发过的intermediate CA certs后，保存为文件，导入。最后就是要设置CA/CRL，和上面相同。

在开始给server签发certs前，需要创建role，之后就可以签发了。

拿到private key和crt就可以放在服务器上测试了，感觉用这个 grunt-connect-proxy 测试起来可能会快点。

Vault还有一个我觉得很好的特性是可以将LDAP作为auth的backend，感觉维护的压力又小了很多:) 剩下的特性大家可以自己尝试，我们也正在考虑把替换RatticDB保存一些private key之类的credential，下次的security meetup上面我可以展示下spike的成果……。

---