今天我们来好好聊一聊数据库安全。

数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或损坏。安全保护措施是否有效是数据库系统的主要技术指标，而数据安全如同一个木桶，整个防护体系是否坚固完全取决于短板。因此即使网络层、操作系统的安全防护已相对完善，如果存放核心信息的数据库得不到应有的保护，同样会造成较为严重的数据安全危机。

数据库安全事件时有发生，处理事故时稍有不慎将会酿成灾难性后果。近日，一次波及范围甚广的事故造成大量用户的数据库异常，导致业务停滞，大量网友在微博吐槽致使TOB类业务登上微博热搜榜实属罕见，短时间行业内外用户的朋友圈被事故文章霸屏。

这样的数据安全事故正在给高速发展的互联网服务发出一个"数据安全危机"的红色预警。接下来我们一起盘点"数据安全"的几大重灾区——"天灾"（自然灾害、IDC故障）和"人祸"（黑客攻击、数据信息泄露、人为操作失误）。

天灾和人祸

一、"天灾"

火灾、地震、雷击等自然灾害对数据中心造成的物理伤害会导致数据安全危机。比如雷击，轻微情况可引起设备短路故障，严重则会引发火灾。同时IDC也存在着断电、网络故障、设备老化等一系列影响数据安全的因素。

某商业银行核心系统数据库中心出现故障，导致存取款、网银、ATM等多项业务中断长达30多个小时，异地分支机构完全依靠手工办理业务。

二、"人祸"

人为导致的数据安全危机占数据安全故障总数的的70%。怎么样，这个数据是不是触目惊心。

其中也可以分为有意操作和误操作。有意操作是指明知道一些操作会造成数据中心故障，仍执意去做的，这些人往往希望通过造成数据库系统运行瘫痪，而达到不可告人的目的。常见的有黑客、情报人员、商业机密小偷等等，他们攻击的对象往往是数据库里的数据。

国内知名信息安全团队"雨袭团"发布报告称，在一年半的时间内，高达8.6亿条个人信息数据被明码标价售卖，个人信息泄露造成的总体经济损失达915亿元，在巨额损失背后是隐藏极深却又庞大的黑色产业链，即数据黑产。

误操作是指本意并不想破坏数据库系统，但是由于技术积累经验不够或疏忽引发了数据安全故障。这种故障占到了人为故障的80%以上。网上一直以来都个脍炙人口的段子"从删库到跑路"来调侃这一现象。

印度McDelivery（麦乐送）应用泄露了220多万麦当劳用户的个人数据。此次用户数据泄露的根源在于McDelivery公开可访问的API端点（用于获取用户详细信息）未受保护。黑客利用该问题枚举该应用的所有用户，并成功窃取了用户的数据。

某物流公司工程师在操作删库过程中，错选了RUSS数据库，打算删除执行的SQL。在选定删除时，因其操作不严谨，光标回跳到RUSS库的实例，在未看清所选内容的情况下，便通过执行删除，RUSS库被删去，导致物流系统故障，无法使用并持续约590分钟。该程序员也因为操作问题被"跑路"了。

关于数据库安全危机的预防与应对，数据君也走访了诸多初高阶DBA。

初级策略：

·重启系统，重启系统，重启系统，重要的事情说三遍；

·先冷备恢复，然后从增量log里面恢复实时数据；

·先策划好方案，没有出来方案之前，先按兵不动，防止二次事故发生；

·磁盘数据恢复；

·别自建数据库系统了，用云数据库。

不得不说最后一个老兄眼光很是长远~

..

高阶观点：

·数据库系统的监控手段和历史信息记录为系统的稳定运行提供了保障，通过对这些数据分析，不仅可以找到故障原因，还可以根据进行优化，避免发生二次故障；

·从初期的数据中心规划设计，到机房建成的验收测试，再到机房运营过程中对于机房的定期检测和对于突发状况的预案等，每一项都需要经过严格的审查；

·禁止使用存储进程，存储进程难以调试和扩展，更没有移植性；

·数据订正时，要先select，避免误删去，确认无误才能更新句子；

·重要数据永远不要直接删去，标记为"删去"状态。不能给程序的用户allprivileges、delete、drop等高危命令的权限；

·应用的网络进行分层规划（接入层、应用层、数据层）。数据层只对固定的应用服务器开放，数据库尽量只放在内网；

·周密的备份，即使管理员跑路也不怕。

不是办法的办法

如果前面的介绍的数据库安全方案，都没有具备。

那发生安全故障后，最后的方案就是：走操作系统级别的数据恢复。

这个方案是不推荐的，即使侥幸能恢复数据库，数据大概率也是不完整的。而且很看运气。

这个方案是以文件为对象进行恢复，也就是恢复文件系统上删除(或丢失)的某几个文件，不关心文件的内容，仅通过文件系统的元数据进行分析和恢复。元数据是一个文件系统的管理信息，一般不以用户文件为载体，通常只能通过底层块的二进制流进行获取和分析。

删除文件恢复的第一个有可能特别好用的方法是lsof。

Linux系统中使用rm-rf删除文件后，其实文件节点只是从目录树中移除，文件内容还是在系统后台等待回收，此时有机会使用系统进程号将文件拷贝出来。

lsof|

cp/proc/xxx/xxx/xx?/dir/

如果lsof找不出来，那就只能从文件系统角度进行恢复了。

这个已经超出了数据库安全机制的范畴，如果有兴趣可以直接参考：

以下内容属于上面链接的系统级恢复的转载

按恢复的方法，文件系统大致分为三类：

I类：

UFS（Solaris、BSD等使用），Ext2/3/4(Linux最通用的文件系统)，JFS(Aix最早使用)，OCFS1/2，HTFS（SCO）。

这类文件系统，使用固定的节点长度，和固定的节点区域。文件系统上的所有文件（或目录）都会在节点表中有唯一一个编录对应，用来做寻址文件的起点。这类文件系统在删除文件时，一般会将节点进行清0操作(因为节点编号和位置是物理上固定的，删除文件后必须可以重用，节点区操作也较为集中和频繁，一般设计时会在删除时顺手清0)，清0后，节点到数据块索引之间的纽带就断开了，原本一对一的映射关系，变成了N对N，N是文件总数。

所以，这类文件系统在删除文件后恢复时，往往名称和目录对应较为困难，像医院的PACS、OA、邮件系统、语音库、地质采样、多媒体素材，也包括数据库文件等的对应。

特殊地，一些linux上的开源数据恢复软件，ext3grep之类的，为何能恢复Ext3/4上删除的文件呢？

是因为，Ext3/4文件系统支持日志回滚，系统会在格式化时创立一个日志文件(用户不可见)，典型的大小有32M~128M之间，在删除文件时，节点会先行复制到日志文件中，再进行删除，以确保操作意外中断时，可回到上一个干净的稳定状态。

但缺点也显而易见，日志是不断循环回滚的，如果时间太久，或文件系统操作频繁，就没那么容易了。典型地，如果删除大量文件，靠这个方法，只能恢复一部分。

当然，可以再给一计了。重点2：删除后，如果lsof搞不定，有可能的话，第一时间dd文件系统进行归档保护。别以为不断地ls，find会有奇迹出现，会雪上加霜的。

II类：

XFS、ReiserFS、JFS2(forAIX)、ZFS、NetAppWALF、EMCIsilon、StorNext、NTFS。

这类文件系统，节点区域为可变区域，删除数据时很多时候不会清除数据。

原因大概是：

1、区域可变，节点大小就可以设大一些，清除太浪费性能；

2、区域可变，缓冲区就不一定很好命中，清除节点时只需在位图上做手脚就行了；

3、区域可变，可考虑区域重定向，原区域也就没必要理会了。

节点不做清除，意味着"节点-数据块索引-数据块"的链条不会被打断，自然也就容易恢复数据了。

其实也是有难度的，删除一个文件，必然要表现在文件系统层面释放，所以，可能"节点-数据块索引-数据块"整个链条会成为游离态，也可能象zfs一样，会出现非常多的副本，分拣也会有难度。不同的文件系统，会有很多信息之间存在关联，比如JFS2中索引块会记录上一项、下一项；ZFS会在节点中记录下一项数据的HASH等，根据这些匹配点，就可以匹配、择优找到最恰当的数据恢复起点。因不同的文件系统，有不同的针对性的方法。

III类：其他吧。

比如Vxfs、HFS+结构上像II类，但因为节点区域往往集中在前部，命中率较高，在设计上，删除文件就会做清0或重构树操作，数据恢复的难度又如同I类。

比如ASM，严格来说，也不太像文件系统了，反正结论是文件系统本身没有太好的算法，保证删除后可恢复(但依靠文件内部结构，恢复的可靠性非常高)

比如VMFS，基本是个大块分配的文件系统，恢复方法和方案和本文多有不同，一扯内容有点多，有空专门扯。

上述，是针对完整恢复文件的思路进行描述的，但也如上文所述，有时文件是无法恢复的，也可能文件部分被破坏、覆盖。

如果文件内容都还在，但文件系统元数据部分已经无法支撑对文件信息的还原，那就可以考虑从文件内容的关联性上做文章。

比如Oracle数据文件，多数情况下，按8K为页大小，可喜的是，每一页的头部都有页校验、页编号和可能的文件编号。按页校验从磁盘底层扫描出所有数据页后，统计文件编号和页编号，幸运的话，就可能把文件拼接起来。

Oracle的控制文件会记录数据文件逻辑、物理之间的关联，分析后，文件名称、路径就不难还原了。

同样的方法，可大致适应于SqlServer、MySQLInnoDB。思维稍做变通，可适应Sybase、DB2等。

如果是MySQLMyISAM引擎，也有办法。记录是一行一行依次压入文件中的，如果某个表有主键，或特殊的字段，或特殊的表结构，就能对所有磁盘上符合条件的块进行归类。MyISAM还会有行溢出、行迁移的情况，即存在A指向B的数据关联关系，根据这个关系，也可以进一步匹配块记录的排列逻辑，从而组合数据文件。对于MyISAM，这其实也是恢复表或恢复记录的方法。

这是根据文件内容，恢复完整文件的思路。如果文件内容不完整，或副本太多导致排重难度太大呢？---恢复表或表记录。

根据表与表之间的差异，一般情况下，可以容易对找出的所有可能是数据库的片断进行归类，归类的最直接方案是按表进行。

按表归纳为相同一组单元后，就可以从记录角度进行分拣和排错了，如果可以借助于索引、空间分配、其他关联表等信息，可以容易对恢复的表单元进行数据清洗，幸运的话，数据可能是完整的。

如果表归纳为同一单元后，与索引不对应、有错误记录等，导致数据库无法修复启动，就可以按表结构，对表单元，以记录的方式进行抽取-插入新库-数据定向清洗。虽然结果可能不是完美的，但很多情况下，总比没有强。

还有图1中方法C2，从日志中恢复记录。这个日志是广义的，包括归档、过程性语句表述等一切可能有记录痕迹的数据集。在主数据文件是破坏的情况下，这些任何可能包含记录的数据集，都应该是分析的对象。也如同数据库文件，按文件、结构块、记录的思路进行最大程度的恢复。结合C1、C2、C3，再做定向性的数据集合和数据清洗，数据恢复的手段也就到头了。

忘了聊一句Hadoop了，Hadoop,Hbase在删除时触发的是节点文件系统上的文件删除行为，以最常见的Linux为例，其实就是Ext3/4上删除文件的恢复问题，如果文件恢复不了，再参考Hadoop的HASH、fsimage之类的进行数据块关联。如同上述数据库的思路。