谈谈 UCloud 保障数据安全的七种“武器”

当前，数据安全受到多方面的威胁。有来自系统软硬件的非人为故障，有运维工程师的误操作，甚至是黑客或内部人员的恶意删除。2017 年 1 月 31 日，全球最大的代码托管服务平台 Gitlab 由于工程师的误操作，删除了 5000 个项目和 700 个用户账号的数据，虽然多方补救，但部分数据最终没能恢复。近几年黑客入侵用户系统后加密磁盘，以此来勒索的事件也层出不穷。更有来自黑客或内部人员的恶意删除，导致业务的极大损失。

如何彻底杜绝此类风险，确保数据安全，需要全方位的技术保障措施：备份、反入侵、分权限管理、快速回档等技术手段都不可或缺，而且必须覆盖每一类存储产品。

UCloud 作为业界领先的云服务商，提供了全面的各类存储产品，开发了完整和成熟的数据安全机制。并且在为数万家用户提供可靠线上服务的过程中，积累了丰富的经验。下文提到的数个案例，其实就发生在 UCloud 平台上。通过我们的产品和专业及时的服务，这些用户最终得以恢复数据，避免由此造成的损失。

一般地说，用户搭建数据库有如下三种方式：使用公有云提供的 DB PaaS 托管服务，如 UCloud UDB，由云服务商来负责 DB 的搭建及运维；用户也可以使用公有云的云主机和云盘来自行搭建数据库；或者在私有云环境下搭建。在这三种情况下，UCloud 都提供了专业的数据安全机制，来切实有效的保证用户的数据安全。

接下来将介绍 UCloud 针对数据库数据安全的七种“武器”。具体而言，本文主要回答如下三个问题：

1. 数据库的备份容灾机制如何完善？

2. 数据被破坏丢失后如何快速恢复？

3. 数据库运维人员的权限如何有效控制？

UDB PaaS 托管服务

如果需要得到最专业的数据库安全服务，用户的首选就是云服务商提供的 DB PaaS 服务。譬如说，UDB 是 UCloud 提供的云数据库服务，支持各种主流的数据库产品。自 2013 年上线以来，运营了数以万计的 UDB 实例。

UDB 远远不只是帮用户搭建 DB 那么简单，事实上这部分功能只是 UDB 价值的冰山一角。UDB 提供了完备的数据库搭建、运维、性能调优、资源扩缩容等服务。其高可用、高性能、便捷易用等特性帮助用户大量减轻了运维负担。同时，数据库团队还自研了分布式架构、读写分离、存储计算分离等特性，进一步提高云数据库的性能和可用性。在数据的备份恢复机制上，UDB 提供自动备份、秒级恢复、监控告警、问题诊断等服务。

武器一：UDB 备份机制

面对不可预测的误操作或者人为恶意操作，数据库自身的备份机制就显得尤为重要。UDB 的备份机制具体如下：

（ 1 ） UDB 的备份模式

a、自动备份每天自动进行一次备份（默认备份时间为 00:00—06:00 的某一整点），备份可以保存 7 天。备份模式包括物理备份和逻辑备份两种。

b、用户可以对某些关键时间点的重要数据进行手动备份，允许保留个数为 3 个。

（ 2 ） UDB 备份文件存储

a、备份文件存储在 UCloud 独立的备份资源池中，安全性有保障。

b、备份文件的副本始终保持多份异地冗余。

（ 3 ）备份文件转存

针对用户个性化的备份文件存储需求，UDB 支持备份文件下载：

a、Web 控制台或 API 支持下载备份文件（包括自动备份和手动备份）。

b、Web 控制台或 API 支持下载二进制日志文件（ MySQL 的 binlog ） 用户在下载备份文件后，可转存到自有的存储系统或者 UCloud 平台上的存储类产品（ UDisk、UFS、UFile 等），理论上采用公有云存储产品更为安全可靠。

（ 4 ）备份成功率保障机制

a、UDB 的自动备份具备有效的告警机制，如果备份失败，则会自动触发告警

b、UDB 后台会定期进行备份成功率的巡检，通过 SPT 反馈备份情况给到用户。

武器二：数据恢复方案

针对误操作或者人为恶意造成的数据库删除，UDB 提供了一系列数据恢复方案。

a、对 UDB 实例中的库做删除，比如 drop/delete 操作，可以从源实例通过回档功能恢复到操作的前一刻，回档到一个全新的实例。

b、UDB 实例被删除后，它原先的备份将持续自动保留 7 天，7 天内仍然可从备份恢复为一个全新实例。

c、出现最极端的情况，实例被删、备份文件全部被删，那该怎么办呢？ UDB 后端在一定有效期内仍然保留有操作当天的最新备份，应对该极端情况。由于这份备份是系统内部维护，用户并不能直接访问。所以即便发生运维人员恶意删除，此份备份依然存在，仍然可以使用该备份来数据恢复。

武器三：从本地备份到跨云备份

为了确保数据的绝对安全，必须做到数据的多份备份，可以从本地磁盘的多份备份到跨区域备份，甚至实现跨云平台的多云备份。

数据库数据可靠性受底层有效的 RAID 保护，实例级的冗余则包括主实例采用高可用架构，后端主备双节点，保证数据双份冗余。控制台一键创建从实例，主实例可以一主带 N 从，包括可用区级（主从在同可用区）和地域级（主从跨可用区），保证实例级冗余。

UCloud 还提供数据传输产品 UDTS，在数据库可靠性更高要求的场景，主实例可以通过 UDTS 搭建异地或者两地三中心的 UDB 集群架构，进一步保障数据安全。此外，UDTS 也适用于多云部署的场景，其支持多种数据库类型、双向迁移的能力，可以帮助使用者将数据平滑地做跨云的迁移和备份。某电商便是借此实现了 UCloud 和 T 云之间的数据同步。

UDB 数据恢复案例

场景一：数据库误变更

游戏行业业务变更快、变更多，是比较容易造成数据库误操作或者不当变更的情况，此时如何快速恢复到变更前状态就成为了棘手的问题。某游戏用户在版本发布时造成数据库的 schema 变更字段出错，发现出错时，已经对游戏服造成了巨大影响。此时，管理人员对影响的 UDB 实例做了一个回档操作，恢复至变更前一刻，精确到秒级，挽回了损失。再对源实例进行必要数据的导出，补偿到回档的新实例，避免数据丢失。

场景二：数据库误删除

在运维权限管理混乱时，安全性就存在巨大的隐患，任何人都有可能对核心资源进行不正当操作。某互联网 App 用户的运维人员由于看错信息，造成核心 UDB 实例误删除。因 UDB 实例会每天自动备份，此时管理人员在控制台找到 UDB 实例当天的最新备份，做了恢复操作，恢复为一个全新 UDB 实例，减少了损失。

场景三：数据库误回收

在生产环境里，最为担心的是资源的回收未及时发现，例如（ 1 ）运维人员在资源整合时，删除了某个数据库实例；（ 2 ）过期资源未及时续费被自动回收，事后过了很长时间才反应过来，但为时已晚。针对该场景，UDB 实例后端在一定有效期内，仍然保留一份当天的最新备份，通过数据全量恢复的模式，帮助不少用户找回数据。

使用云主机自建 DB

如果用户出于各种原因考虑，不愿意使用公有云的 DB PaaS 托管服务，而是希望使用公有云 IaaS 产品来自行搭建 DB。UCloud 同样提供了专业的数据安全产品，那就是数据方舟。方舟是当前业界独一无二的数据备份产品。通过在虚拟化层的 I/O 路径改造，方舟可以把用户的原始块设备存储放在后端去存储，并且能实现按秒的回滚。

武器四：数据方舟持续保护

对于数据备份产品，有两个重要的能力评估指标——恢复点目标（ RPO ）和恢复时间目标（ RTO ），目前数据方舟的 RPO 已经达到秒级别，默认支持 12 小时内恢复任意一秒，24 小时内任意整点恢复，3 天内的任意零点恢复，用户甚至可以自由定制备份链秒级、小时级、天级的保护范围，并且是恢复到一块新的磁盘上；而数据方舟的 RTO 则能够达到最短 5 分钟内恢复，即使是 TB 级别的数据量，也可以做到半小时内恢复。

数据方舟是如何在技术上做到对用户数据的持续保护呢？数据方舟后端使用了分层混合存储设计，用户的实时 I/O 会通过旁路以 oplog 的方式记录到方舟的接入节点（ FRONT ）上，由于方舟接入节点采用了高速磁盘设备，能够扛住用户大量的 I/O 写操作。

流式计算节点 SHUFFLE 会拉取接入节点的 oplog 进行批量处理，主要是进行数据分片（ sharding ），并将数据分片推送到最终存储层（ ARKER ）进行存储。随着时间的流逝，ARKER 也会不断对数据进行合并，最终形成 base/天级 /小时 /秒 四个级别的数据备份链。

用户恢复时，会调动后端集群所有节点的能力进行并行计算，加快恢复速度。值得一提的是，用户恢复时当前的磁盘数据是保留的，数据会回滚到一块新的磁盘上，这样做的目的是如果用户回滚后后悔，也能够回到恢复前的数据状态。

数据方舟恢复数据案例

案例一：勒索病毒

2017 年 5 月“永恒之蓝”病毒爆发，全球大量 Windows 主机受到感染，企业重要文件被加密，只有支付高额赎金才能解密恢复文件。万户印刷公司的一台云服务器也遭受到了病毒攻击，用户的印刷文件被加密。

案例二：误操作导致文件系统异常

2017 年 12 月，某 AI 公司遭遇到了重大危机，其运维人员在对存放重要数据的云硬盘进行扩容时，违规操作，导致硬盘出现了文件系统故障，数据无法访问。问题磁盘有着多个分区，该公司缺乏对多分区磁盘进行文件系统修复的经验，不敢贸然修复，担忧会因此导致数据进一步损坏。

案例三：游戏回档

2019 年 3 月，某知名端游公司出现了严重的运营事故，一个道具的复制漏洞导致了游戏的平衡性失调，严重影响玩家体验，因此需要快速完成回档，保证对玩家的影响降低到最小。

这些案例中，用户最终都通过 UCloud 旗下的数据方舟产品进行恢复，迅速找回了所需要的数据。

私有云 DB 的数据安全备份

如果用户的 DB 搭建在私有云环境下，没关系，UCloud 的对象存储产品 UFile 是一个海量的通用存储产品。通过和第三方产品结合，即便是私有云的 DB 同样可以利用公有云海量及可靠的存储服务，实现数据的高可靠性。

武器五：UFile 对象存储帮助数据库备份

块存储上数据的保护不仅可以通过数据方舟解决，用户还可以使用基于 UFile 做数据持久化的 JuiceFS 存储数据库备份，JuiceFS 是为云端设计的 POSIX 共享文件系统，具有如下特点：

云端：采用云服务中的对象存储作为后端，综合性价比极高。

POSIX：兼容标准 POSIX 接口，可以像本地文件系统一样使用。

共享：上千台机器同时挂载，高性能并发读写，共享数据。

UFile 是 UCloud 自研的对象存储系统，兼容 s3 协议，具备高可用、高可靠和低成本的数据存储服务，提供多副本、跨地域等数据冗余机制，支持三地及以上的跨地域灾备功能。使用 UFile 用户可以实现高可靠、低成本的云上和跨云的数据备份，包括数据库备份、日志、大数据文件等。

基于 UFile+JuiceFS 搭建 MySQL 备份

UCloud 用户下厨房是国内最大的专注于家庭美食领域的社区，目前拥有超过四千万注册用户，海量的业务也让下厨房对数据库的冗余和备份格外的重视，并且总结出一套非常高效和可靠数据库灾备经验。

除建立了跨可用区的主从节点外，下厨房会进行定时的整库备份和实时的 binlog 备份。下厨房的数据库备份借助了 UFile、JuiceFS 和 Percona Xtrbackup。使用 JuiceFS 用户可以无需修改代码就可以替换之前的本地备份。并且可利用 JuiceFS 后端的对象存储来解决无限存储空间、跨区域复制以及低成本等问题。下厨房的策略是保留 7 天内的 Percona XtraBackup 整库备份、3 年内的 binlog 以及 1 年内的周级 mysqldump。

除此之外下厨房还想到了一个非常具备脑洞的备份验证方案。有了备份还无法做到高枕无忧，因为有时备份文件会出错，等到需要恢复时才发现备份出错就已经晚了。但是备份的验证是个非常耗时的工作，需要拷贝备份到本地进行恢复。下厨房利用 JuiceFS 的快照功能，克隆一份备份文件，在不影响原备份文件的情况下快速做验证，省下大量拷贝的时间。

详细实践可参考链接： https://juicefs.com/blog/cn/posts/xiachufang-mysql-backup-practice-on-juicefs/

账号和权限控制

在具备一定的备份和恢复机制下，数据库运维管理人员的权限控制问题仍然不可忽视，例如将数据库操作权限和备份权限进行分离、权限审批和操作执行分离、增加数据库命令隔离层等。

武器六：子账号

在权限管理控制方面，UCloud 支持用户为自己的账户开设子账号，并定义为相应的角色。角色是一组产品权限的集合。若某成员的角色被修改，则其相应的权限也随之变更。子账号的存在有助于贯彻“最小权限管理”原则，只赋予工作职责所需的权限。大部分成员或许只需云资源的只读权限，少量操作者可拥有修改的权限，而删除权限必须通过管理员的审核。

多级账号权限控制，可以有效的控制多级人员的操作权限，最大程度的降低来自内部人员恶意操作的可能。

武器七：安全锁

安全锁是云资源高危操作的二次验证服务。开启该服务后，每次进行删除资源等危险操作时，需要通过手机短信校验身份才可。

受安全锁保护的高危操作例如有：

产品 操作 主机 开机、关机、删除实例 物理机 关机、删除实例 云数据库 UDB 删除实例、关闭 云内存存储 UMem 释放内存 对象存储 UFile 删除 bucket、删除 ufile geo bucket 云硬盘 UDisk 删除实例

写在最后

黑格尔曾说：“人类从历史中学到的唯一教训，就是人类无法从历史中学到任何教训。”云服务发展到今天，已经实现了多种完备的数据安全方案。如本文提到的 UCloud 七种武器，无论用户使用哪一种方式部署数据库，必有一款适合你。企业在今后发生数据库机器故障、误操作、恶意删除等情形时，能否充分利用云服务商提供的数据备份、恢复机制以及账号权限控制等能力，是解决数据丢失问题的关键。