阿里十年DBA经验产品经理：真的不要再有一起删库跑路事件了

最近网上又出一起删库跑路事件，本不想过多写此类事件文字，但从业13年，十年DBA工作经验，职业素养还是驱使自己写点内容，以期能够帮助广大企业客户。

本文主要以数据库产品从业者角度，介绍帮助企业减少意外或有意对数据库删数据的破坏行为，关于数据安全的其他内容如加密等不做过多描述。为了阐述方便，会引入一些RDS功能介绍。

###子账号体系

针对数据被删除的场景，从“大”到“小”都需要防护，包含实例、数据库、表、记录行。尤其是最大的数据单位，数据库实例，是需要特别保护的，否则删除一个实例破坏性实在太大了，而且就目前所知这个破坏性是比较彻底的，假设没有做任何额外备份保护，删除实例后再恢复是完全没有这种可能。

阿里云针对这种实例级保护，主要是通过主子账号体系来实现的，主账号创建数据库实例，然后通过子账号授权DBA等管理人员维护数据库实例。针对按量实例，在删除实例的时候会收到短信验证码，保障每次删除都是正确的；针对包年包月实例，在实例到期前就会有短信通知续费，到期后会锁定7天，期间可随时恢复，7天后实例释放但会将最新全备文件放入回收站保留8天，因此在实例到期后客户依旧有15天时间来恢复数据。此外由于本次疫情，阿里云针对所有RDS包月实例到期时间都做了延期锁定动作，保障在疫情期间因为延迟上班导致的延期交费实例不被锁定。

前面提到我们删除实例的破坏性是比较彻底的，因为目前大部分厂商的数据库的备份都是跟着数据库实例走的，即实例删除后备份文件也随之清空，此时就没有任何恢复手段了。在2019年底，我们针对此场景，特别设计了删除实例后保留备份文件的功能，已经上线，这样在实例删除后，依旧默认保留备份文件，以便随时恢复，并且暂时是0元优惠的，大家可免费使用。

DBA账号和研发账号分开

数据库实例能够保证安全后，并不能够保证数据库就是安全的，比方说最近这个案例，可以通过删除实例中的数据实现破坏。以MySQL为例，数据库中的数据以表和数据库形式组织起来，以记录行承载具体的数据，对数据库和表的保护尤其重要。

对数据保护的原则还是权限分离，最基本的权限分离还是要做到的，化繁为简在RDS MySQL中我们设计了两种权限类型用户，分别是“读写”权限用户和“只DML”权限用户，读写权限用户有DDL的权限，因此我建议给业务系统使用的数据库用户选择“只DML”权限，而不应该给予“读写”权限，以此避免通过编写一个恶意程序去删除数据库中的表或者整个数据库了。

据我所知，有不少企业业务系统中，会给应用系统以DDL权限，即在业务运行过程中系统会去自动创建表和删除表，比方说某些ERP系统是此类设计方案，这就无法避免要授予“读写”权限用户给应用系统。另外在MySQL的权限体系中，有一个drop权限，其特性非常有意思，拥有这个权限就具备的删除表和删除数据库的能力。因此这个场景，在一定程度上就加重了数据安全隐患。为了解决这种场景，我们专门在AliSQL内核层设计了一个回收站，这样纵然业务系统执行了drop table等操作，DBA依旧可用在内核回收站中快速的把数据找回。

如果要对表中数据行进行保护，就会相对比较复杂，除了通过binlog来反向更新找回数据外，我建议客户可以开通SQL洞察功能，SQL 洞察除了用于审计，也可以用于找回数据。当然于此，DMS企业版也是我强烈推荐的一款产品，这款产品是过去阿里DBA团队内部研发流程管理的结晶，发布与回滚、表级权限的精细粒度控制、单行数据的masking等，都是专门的数据保护特性。

备份和恢复体系

数据保护的最后法宝永远是备份，如果没有备份，能够保护数据的程度是很有限的，记得前两年有个公司自建数据库，认为云盘有很高的数据可靠性保障就可以安全无忧，但是凡是代码就有bug，最后的悲剧大家也比较清楚。无论是物理损坏、或人为损害，备份就是最后的救命稻草。

在阿里云RDS中，会强制要求备份文件至少保留7天，每周至少做两次全量备份，与AWS允许不备份的设计不同，我们这样做真的是为了保护客户，与国外环境不同，中国的DBA从业人员本来就少，有意识备份是少之又少，因此在这里我们做的和AWS不一样。同时为了降低成本，我们开发高压缩比的备份技术，一般压缩7到10倍，并且赠送50%实例存储空间的免费备份空间。

另外有一个特别的建议，希望大家都能够打开RDS的日志备份，这样在恢复的时候可以实现恢复到时间点，可以最大程度保护企业数据。若关闭日志备份，那么极端情况只能恢复到上次全量备份时间点，比方说一周两次则有可能是三天前，因此我们建议仅对如开发测试环境数据库关闭日志备份，所有的生产数据库都应该打开日志备份。

灾难发生时，数据库恢复技术就显得尤其重要，当然前提得有备份。我们过去只提供了克隆实例功能和覆盖性恢复功能，在灾难发生时，支持用户把数据恢复到一个新实例，或者恢复到老实例（覆盖恢复）。

在18年的时候，我们取消覆盖恢复的功能，因为这个功能其实是非常危险的，如果覆盖恢复过程出现异常，那么数据错乱将会更麻烦，这在当时是个痛苦的决定。数据库恢复（克隆实例）是挽救数据的法宝，但是恢复效率也是非常重要的，否则意外发生时，也许需要几天才能恢复（取决于数据库大小），因此在19年我们全面上线了库表级恢复能力，支持只恢复一个单表，这样如果某种表数据丢失或者错乱，可以快速的恢复，效率上是数量级的提升。另外针对一些更特殊场景，我们上线了RDS跨地域备份功能，其意义就不多说了。

关于备份恢复提最后一点，长期的定期的恢复演练是非常有必要的，否则你无法知道备份是否有效，相关版本是否匹配等，当然RDS已经在系统上实现这个机制，客户可以放心使用。

给自建和同行朋友的建议

上面谈到的几点都以RDS举例来说明的，对于在ECS自建或者IDC自建的朋友，我们也是希望能够和我们一样，加强对数据库的保护，一些切实可行的动作包括：

· 重新Review下数据库权限体系，最基本的权限分离还是要做到的，千万不要有grant all on . 的用户给到应用系统，因为凡是系统就会有bug，有些时候结果是超出想象的。

· 定期备份机制一定要做起来，虽然此举涉及成本投入，但这是我们DBA行业的职业素养，不可得过且过。

· 定期演练也要做起来，意外发生时，你就是公司所有人的希望，甚至是你一年中唯一的闪光点，千万不要手抖。

关于我们的同行，在这里我也呼吁尽快完善产品功能，库表级恢复、跨地域备份、备份独立存储（实例删除后依旧保留）、内核回收站、秒级恢复，这些功能都是我们走访调查大量客户后的研究总结，全力完善起来对所有客户都是有意义的。

给DBA和管理者的建议

虽然说RDS做了很多功能来保护客户数据，但是个人认为一切的核心还是在于人。对于这次事件，我认为是个遗憾也是悲剧，也许有种种原因，但是这样的操作是不理性的，不仅仅是对一家公司的破坏，也许甚者对背后多个家庭或者行业都有破坏性，另外也会加深外界对整个行业从业者的误解。

原文链接
本文为云栖社区原创内容，未经允许不得转载。