这两天 IT 圈的朋友应该都被微盟遭恶意数据破坏的事情刷屏了，损失真心不小，从公告上看第一批新用户的数据恢复要 50 小时，完整的数据恢复要 120 小时，影响股价下跌 5.23%，市值蒸发超过 12 亿港元。
讨论与回顾
事情发生之后在 Juicedata 的用户组里就发起了一波讨论。Juicedata 的好朋友成哥还写了一篇文章《从微盟 36 小时故障，谈谈数据安全和备份这个事》，我们对事故分析的意见一致，应该是所有数据库被删，估计备份也一起被删了，所以需要云厂商配合从磁盘层面恢复数据。
这样的事故也不是第一次发生，核心数据库的事故都不是小事故。即便不是人为的恶意，仅是系统故障、操作失误等带来的损失也不小。从美国 911 之后，企业业务连续性就被提到了一个更重要的位置上。2017 年，Gitlab 误删数据库，自信满满的查看自己的 N 重备份，发现没有一个能顺利恢复的，百般周折之后还是丢了一小部分数据。2018 年，Github 数据库故障造成 24 小时宕机。
安全体系的三个必要条件
在这里，我们也说说存储系统能提供哪些数据安全保障。数据安全体系之所以称为体系，代表它不是单一环节，而是需要全面构建，相互配合。有三个大方向作为必要条件：
- 备份，无论人还是系统都有出错的时候，一定要做好多级备份，下面会详细说说如何做。
- 日志，无论人还是系统的行为都详细记录，用来做问题诊断，事后复盘，甚至异动预警。
- 必要的权限隔离。在技术上做权限隔离，而非设计管理流程审核，因为流程复杂化带来的效率损失可能要远大于收益。对于如今快速变化的市场环境，并不适合。
展开说说三个必要条件如何达成。
首先说备份
拿 MySQL 来说，备份就包括同步的 relica，延迟的 replica，定时全量物理备份，binlog 做增量备份。不同的备份和冗余机制可以用来解决不同的事故类型，以达到尽可能高的业务可用性和连续性。备份完还不够，每一份备份都要做恢复验证，以保证备份数据确实是可用的、正确的。具体操作方式可以看看我们客户的《下厨房的 MySQL 运维实践》。
第二说日志
日志主要有两类。第一类是系统服务日志，通常会存 7~30 天，用于监控、故障诊断、问题复盘等。一般会收集到 Elastic 中方便搜索查询，原始日志可能会归档到一个存储服务中，方便做进一步的问题定位。第二类是人员操作日志，包括对自己内部系统的各种操作，对云平台的操作，还有堡垒机、跳板机、VPN 等关键访问节点的日志，应长期归档做审计使用，出了问题可以查到什么时间什么人做过什么操作，这部分有成熟方案，买服务就行了。
最后，重点说说权限隔离
在微盟的事故里提到是核心运维人员，一定有 root 权限吧，在传统物理机集群中，只要有 root 权限想删谁删谁，并没有万无一失的安全机制防范人员的恶意操作。但是到了云时代，在托管服务下我们有了更多的权限分层和隔离机制。
首先用自建分布式文件系统 HDFS 和全托管文件系统 JuiceFS 对比，对于自建 HDFS，管理人员有所有机器的权限，可以直接删掉 DataNode，破坏数据和服务。而对于全托管系统 JuiceFS，物理资源和管理权限不由客户团队管理，是完全隔离的，很自然的形成一道安全防护。
其次，对于自建系统，也可以利用全托管服务增强数据安全性。还用 MySQL 备份举例子，JuiceFS 是公有云上的全托管文件系统，用户可以在 MySQL 实例或者备份机上使用 write only 权限挂载 JuiceFS，这样 MySQL 的物理备份和 binlog 只能写入，不能删除。
公有云账户也要用好子账号和 IAM，用来隔离不同团队和成员的权限，并且要定期做好失效和更新。
存储，安全的最后一道墙
有了前面三个方面的建设，在数据安全上已经具备了不错的能力。但是这些系统仍在在人的管理范围内，仍然没有一个彻底的方法可以杜绝恶意破坏。
存储系统能不能成为数据安全的最后一道墙呢？
存储系统能不能不提供删除操作？或者，删除操作只是标记，必须经过规定的时间周期才会物理删除？
JuiceFS 已经提供了以下功能保护数据安全：
- 默认开启回收站功能，所有删除的文件都会进回收站，并且只能登陆 JuiceFS 的 Web 控制台，才能对回收站中的数据做永久删除或恢复。一方面可以防止手抖误删除，也能有效应对恶意删除并清空回收站，只需要确保文件系统使用者没有 Web 控制台登陆权限即可。
- 可以设定访问规则，提供删除和修改保护。通过访问规则的设定，可以让某些机器只允许写入和读取数据，不允许删除和覆盖。这对备份场景非常实用，无法从备份机器上删除备份数据。
如果再有一个类似 macOS 上 TimeMachine 的能力，可以数据恢复到任意时间点，那就可以彻底杜绝恶意操作，做好数据安全的守门人了。
JuiceFS 使用元数据和数据分离的架构，所有的操作都会以 changelog（类似 MySQL binlog）的形式记录下来，只要有完整的 changelog，系统可以回放到任意时间点的状态。再说数据部分，JuiceFS 在数据持久化上采用了 Copy on Write 方式，所有的数据操作不会覆盖已有数据，而是创建新的对象，只需要延迟对象存储上的数据删除操作（或者利用对象存储的多版本支持），系统就能回放到任意时刻。因为 JuiceFS 是全托管服务，客户系统的入侵者无法威胁到托管的元数据的安全。数据存在客户的对象存储中，建议做好秘钥的权限隔离。一些对象存储已经支持数据多版本，开启这个功能后，数据删除操作可以延迟指定的时间后，才被物理删除。
正是依托于 JuiceFS 的这种 Copy on Write 机制，我们最近帮客户成功恢复了被勒索病毒恶意加密数据的绝大部分数据，点击查看详细报道。
为了使得数据的备份和恢复更简单，JuiceFS 正在开发时间机器和快照功能，让你的数据可以穿梭时空，永远不用担心被删除或者破坏。
