前言
首先要声明的是本文只针对人员和资源有限的小型公司或组织而言，只是探讨一些能够在有限的资源内实现的数据库加固手段。相信删库跑路是任何组织或老板都害怕的事，要是管理不规范，开发人员的删库跑路可能直接把公司搞垮，所以一些基本的数据层面的安全策略还是需要启动的。下面就介绍一些简单好用的加固方法。
常见不安全点
为所欲为的管理员
大部分小型组织都是一个管理员打天下，操作系统的管理员完全可以直接将数据库以不安全模式启动，然后登录数据库修改数据，乃至清除数据。这里面有几个维度的问题，首先是系统管理员不应该具有操作数据库的权限。其次，数据库的管理员不应该有操作业务数据的权限。
随时可能损坏的硬盘和随时可能松动的网线
在小公司或组织内，硬件条件往往跟不上，特别是一些政企项目中无法使用云服务，那么要是没有可靠的备份机制的话，可能一次硬盘损坏就导致业务全面停止，公司又不得不付出高昂的成本来回复数据。网络则是一个不可控因素，所以一台热备的机器能够更好的完成服务的切换。
随时可能被破窗而入的客户端连接策略
有不少安全意识不足的组织，账号密码的强度不够，这是一个很大的隐患。一旦被人破解，把所有数据加密然后勒索比特币就只能哭了。
老旧过时的版本
不少的老版本的数据库有一些风险或漏洞，所以即使升级也是很有必要的。
加固方案
- 系统级权限加固，给操作系统添加单独的数据库管理员账号，在这个账号下安装数据库，特别的指定用户为数据库管理员账号
- 开启设置数据库的二进制日志mysql为binlog，format设置为Row
- 使用脚本或工具定时在业务低峰期进行全量数据备份至外部存储介质（云存储或盘阵）
- 至少启动一个主从的热备机制，至少支持一键式切换。（将单次MTTR降低到分钟级）
- 开启数据库的审计日志，mysql可以用connect-init机制或是插件实现
- 设置管理账号体系，至少要分为管理员，审计人员和业务人员。管理员角色只是对数据库本身进行管理，比如账号啊，权限啊，但不能对业务和审计日志操作。审计人员角色只是对审计日志进行查询单不能编辑。业务人员角色一般是程序使用智能对业务进行操作不能对于服务器本身进行操作。
- 限制不同用户的登录端，尽量减少%登录的账号
- 每个账号的密码至少要做到12位，大小写特殊字符都要用上，能够做到定期更换更好。
- 及时升级软件版本。
什么是好的
当你不怕别人删库跑路或是盗用管理员账户，就算有人敢做也能在几分钟内自动的恢复服务，同时追查到操作的人的时候就是数据库安全基本到位的时候。
