编辑手记：对于资深的老DBA们，他们在漫长的职业生涯中养成了很多稀奇古怪的守则，以在复杂多变的环境中“幸存”，这源于无数血泪的教训，我曾经在《数据安全警示录》一书收录了大量现实案例，现在整理分享给大家，共为警示。
在数据库日常管理过程中，有些威胁来自数据库外部，而有些威胁则来自数据库内部，对于数据库外部，破坏性的操作有rm，而在数据库内部，同样有破坏性操作，如Truncate。
案例分享
误删除数据表
原来接手一个部门的所有数据库，结果漏了一个，也没人告诉我，所以我不知道这个数据库存在。一天一个程序人员误按了一个按钮，把大量的数据全部删除，找到我后，发现数据库没有归档，也没有任何备份。结果是程序人员补了几天的数据，我的奖金也直接泡汤。
误删除用户
刚从事DBA不久，可已经犯了个让我终生难忘的错误。原本是要将测试环境的一个user给删掉，由于桌面上开了多个窗口，结果drop user XXX cascade，直接将正式环境的一个user给drop了，刚按下enter，就感觉怪怪的，心想不会吧！！已经来不急了，还好这个user的信息是从另外一台服务器上同步过来的，要不然死定了。以后做什么动作我都习惯先看看是在哪个DB上那个服务器上，千万别搞错了。
误删除表数据
以前公司，有一个程序员写好的脚本，一个实施人员去执行，脚本里面带了 delete * from xxx; commit; 啥备份，归档都没有。结果我们公司全部人员出动，抱着笔记本，台式机，去北京某区县所有的机关单位上门录了一星期人员信息。至今记忆犹新。
误删除数据表
测试环境导出的腳本中包含drop語句，結果看都沒看就直接在生產環境中做了，一下子物料表就沒了，整个生产停线，后来做了恢复，丢了半天的数据。教训：执行的脚本一定要认真检查。
防范建议
1.通过触发器约束或禁用特定的DDL操作
对于TRUNCATE等高风险的数据库DDL操作，可以考虑通过触发器进行禁用，防止未授权的操作损害数据。 很多轻忽的数据灾难都来自于Truncate，这个类似于系统级别的rm命令极具破坏性，而且DDL不可以回退，即便发现已经为时过晚。所以我们建议用户可以考虑使用DDL触发器来禁用Truncate之类的危险操作，以达到安全防范的目的。
2.以最小权限原则进行授权
过度授权即是为数据库埋下安全隐患，在进行用户授权时一定要遵循最小权限授予原则，避免因为过度授权而带来的安全风险。
3.明确用户职责
应当明确不同的数据库用户能够用于的工作范围，应当使用普通用户身份的，就绝对不应该使用DBA的用户身份，只有职权相称，才能够避免错误。 即便是拥有管理员职责的用户，也应当遵循以不同身份执行不同任务的习惯，比如SYS和SYSTEM用户的使用就应当进行区分和界定。
4.在任何数据破坏之前进行备份
在进行数据表的截断、删除之前，进行备份，将备份养成一种习惯，这样才能够避免误操作之后的措手不及。
5.以重命名代替删除操作
不论操作系统级别还是数据库级别的删除操作，尽量以重命名替代删除，如重命名数据表，重命名数据文件，然后通过一段时间的观察和确认后再彻底删除。 Oracle10g中引入的回收站功能，就是将我们执行的DROP操作变更为重命名进行保护，当我们发现了失误之后，可以通过回收站找回，但是注意回收站保存对象的时间和空间有关，如果存储空间不足，对象会被自动释放。 我们在管理中借鉴这个回收站思想是很有帮助的。
6.尽量争取充足的时间
不要低估任何一次简单的维护操作，因为一个意外就可能大幅延长你的维护时间。所以，应当尽量争取充足的时间，包括做好充足的准备工作，加快无关紧要步骤的执行，减少不必要的时间消耗，时间越充裕，你用来应对可能出现的故障的时间就越多。
7.审核你的剪贴板
很多错误是由于粘贴剪贴板的内容引起的，所以，当你准备向一个窗口或者命令行粘贴你看不到的内容时，提高你的警惕性。在Windows上，有很多剪贴板增强工具，可以帮助我们记录和展现剪贴板的内容，可以考虑选用。 审核你的剪贴板，确保其中的内容是你期望的。
8.没有认真看过的脚本就绝不要执行
对于DBA来说，如果一个脚本你从来没有认真读取了解过，就不要去执行，脚本中的一个错误就可能导致严重的数据灾难。我们遇到过案例，由于脚本中的一个变量错误，导致所有数据文件被删除，教训惨痛。 如果实在无法审核脚本的内容，那么在进行重要操作之前，备份你的数据。
以上内容摘录自盖国强《OracleDBA手记4数据安全警示录》。
文章转自数据和云公众号，原文链接