摘要: 对于数据库而言，首先要求我们拥有一个完整的备份，有了备份你才能做很多事，同时也会省了很多事。其次是安全，无论是数据备份的安全还是数据本身或者研发使用中的安全，都值得关注。然后是数据库本身的使用，合情合理的使用。最后对于你所维护的数据库你需要拥有详细的规划，无论...
对于数据库而言，首先要求我们拥有一个完整的备份，有了备份你才能做很多事，同时也会省了很多事。其次是安全，无论是数据备份的安全还是数据本身或者研发使用中的安全，都值得关注。然后是数据库本身的使用，合情合理的使用。最后对于你所维护的数据库你需要拥有详细的规划，无论是管理角度还是使用角度都需要。
一、MySQL之备份
之所以开头就提这个，主要原因是最近的事故略多，删主机、删库、删表、删字段还有勒索病毒等，太多的不可控因素了，从“删XX到跑路”你缺少的只是一个“机会”。本来是你好、我好、大家好，但是万一呢?所以要未雨绸缪，当然备份的意义不仅仅在于此。
1、可恢复性
首先谈谈备份的可恢复性，或者说是有效性。无论你的备份是在本地、异地、存储、磁带、云上、或者其它不知名处，如果不知道出啥问题丢失了，而且还必须要用这份文件恢复，不能有效的恢复，后果会很严重，所以在系统设计之初就需要规划好。
一般而言我们同一份文件需要存放多个位置，三份是个不错的选择。常规的做法是本地一份，其它地方两份，具体的可以根据实际条件酌情处理，通常一份的效验很难有说服力，而且也并不可靠，一定要确保多份副本，从技术的角度而言，奇数是常用的仲裁配置，而三是最小的单位。
接下来就是需要经常验证，我这边说的是经常，日常不是很现实，如果资源足够，那就完全可以实施了，这样可以做到心里有底，避免真正在生产执行恢复的时候手忙脚乱，而且主要是可以通过预先准备的脚本或者命令，快速恢复。之所以一定要通过实践去检验，因为通过实际的行为去排雷、排坑、排问题，尽可能地摸清楚将来可能会遇到的可能性问题。虽然可能性为零，不过平时多演练，这样在真正需要的时候才能少掉坑里去。
如果说因为各方面的原因你没法去验证，只能通过系统自带的验证或者采取其他的诸如文件效验的方式，这样回到之前说的多副本情况，如果你拥有多分副本，起码验证起来还是比较简单的，但是也并不是说多份副本就一定是有效的，还有时效性等问题。
2、时效性
这是建立在前面备份可恢复性基础上，首先你的备份是可以支持恢复的，这个接下来需要关注备份的有效性，恢复的效率性。这里面会涉及到RPO、RTO，两者是相互耦合的，RTO要求你越少的时间，RPO要求你恢复到最近时间点的数据，无论哪个方面，有效的解决方案都是更新的备份，更快的恢复效率，最好乃至于瞬间恢复到上一个事务，当前事务。不同的业务级别，需要不同的级别，当然灾备另说。
时效性，说实话是属于比较难界定的。那具体需要恢复到什么时间节点的数据呢?根据相应的RPO级别，需要指定相应的计划，而且这其中还需要考虑RTO，如何缩短时间。如果说真的发生了需要从备份恢复的场景，首先需要确定你的数据库拥有完整的备份，但是往往这个时候可能没有最新的，要么就是最近的备份是不成功或者失败，不要觉得我在危言耸听。
事实往往比这个更复杂、更加严重，如果幸运的是，你不仅仅拥有多份可靠的而且是最新的备份，还有完美得是到宕机前一刻的增量或者日志，接下来就是跟时间赛跑，稳稳地减少宕机时间。
3、安全性
安全性放在最后，并不是说不重要，相反，主要高度依赖以上两点，如果脱离了，就片面而言，没有备份，那就是安全的，这是在没有的情况下，不存在其它的情况。
然后就轮到有备份了，当你有了备份，你不仅仅需要保证备份的多副本，还要保证其安全性，这里面的安全性包括内部安全，外部安全。很多时候外部反而是安全的，一个有效的备份经历加密、访问控制，别人无论是获取还是解密都需要花费大量时间的，而内部往往更容易出问题，千里之堤，毁于蚁穴。
提一下泄密，这个还是比较尴尬的，不论等级划分，笼统来讲，被权限以外的人接触都算，那具体怎么界定，而且权限也是比较难划分的，所以该有的预防措施必须要有。
安全无小事，相应的规定章程制定下来就需要严格的执行，剩下的这就需要看从业者的职业操守。
PS：如果需要了解备份恢复可以关注下社群文章《解锁MySQL备份恢复的4种正确姿势》，相信可以帮到你。
二、MySQL之安全
在生产中，安全是相当重要的，毕竟你的核心数据都在里面，MySQL因为其开源的流行性，大量个人、企业、政府单位都采用，但是很多在部署的时候采用都是默认的配置，这就导致了安全的相对欠缺，你需要针对你的安全有所加强。
总的来说，数据库一般划分为生产库、压测库、准生产库、测试库、开发库。下面部分主要说的是生产库，但其它库也适用。
1、mysql_secure_installation
这是数据库基础的安全设置脚本：
设置root密码
移除匿名用户
禁止远程root登录
移除test数据库
以上是5.6版本，5.7有所加强但也仅此而已，看看你的环境是否存在上述问题，这个算是最基本的安全吧。
2、连接访问安全
常见创建用户时你需要指定你的IP访问地址范围或者固定IP，一般而言，只有特定唯一的几个IP才会访问，或者说你可以采用代理访问的方式，减少应用直接访问你的数据库，而且现在很多中间件也都有白名单机制，原则上是把非法请求防止在数据库以外的地方。
规范数据库管理软件，实现管理软件的标准、统一化，还有严禁杜绝开启外网访问，如果客户端在远程，就根本不应该直接访问数据库，而应该使用中间件堡垒机或其它替代方案。
为了防止连入数据库的应用程序存在后门，造成数据库安全隐患，检查所有连接数据库程序的安全性。通过使用堡垒机或者其它监控登录数据库，禁止对数据库的直接操作。
对已经连接的IP网段进行规范化、统一化的管理，定期进行权限复核操作，对系统所属IP、用户进行权限梳理工作。
对员工进行安全培训，增强员工的系统安全观念，做到细心操作，安全操作。确保访问数据库的主机为已知用户或者主机，使用专门主机与数据库进行连接。
对重要业务表的所有行为全部审计，审计同时所有包括即使是DBA的DDL操作行为。
最后是报表系统，利用审计的相关日志，出具系统化的审计报告。
3、权限安全
权限这块无可厚非，在建立之初遵循最小权限原则，坚持最小权限原则，是数据库安全的重要步骤。
以上说的是白话，下面说说正题。
很多时候我们不知道具体的最小权限是什么，你说一个账号到底需要什么样权限才合适，才不会影响业务?这个不是很好界定。我们需要知道在设置权限时的信息，要授予的权限级别、库级别、表级别、列级别，或者其它超级权限、要授予的权限类型，增删改查等。
从mysql.user表来看
用户名、IP地址，是否需要连接数控制、SSL、过期时间等，不要怕麻烦，可能前期设置的时候比较繁琐，但是一个好的基础设置，才是安全地保障，做到需要什么给什么。
4、账户安全
用户账户划分原则：
超级管理员账号
系统应用账号(比如备份，监控，审计等)
应用业务账号
业务人员账号
开发人员账号
测试人员账号
其它专用账号
主要是防止泄漏，非必要人员不需要知道账号的名称，同时需要制定相应的命名规则，还有就是合理使用自己的账号密码，保护好你的账号密码，对于绝无必要的用户，先禁用，后期删除，要做到无匿名账户和无废弃账户。
5、目录文件安全
提高本地安全性，主要是防止MySQL对本地文件的存取，会对系统构成威胁，还有Load DATA LOCAL INFILE，禁用该功能。
这个主要是防止误删除，非权限用户禁止访问目录，还有就是数据文件禁止访问，或者采用更改常用的目录路径，或者通过chroot，要保证该目录不能让未经授权的用户访问后把数据库打包拷贝走了，所以要限制对该目录的访问。
6、密码安全
密码强度复杂性
尽量并且不要使用固定密码，实行每个用户单独密码，长度在16位以上 0-9a-zA-Z~!@#$%^&*()-+ 随机组合。
密码过期机制
根据公司的情况设定密码过期时间，定期更改，同时不可使用重复密码。
密码保存机制
为了方便管理，可能会采用一个密码表，要加强对于密码表的维护更新，最重要的是保证不泄漏。
7、漏洞安全
常规的方式是安装补丁，不过这个往往比较麻烦，主要是版本升级，还有就是防护策略。
8、被忽视的SSL
由于性能或者其它方面原因，很多生产环境并没有使用，不过从5.7+开始，已经好很多了，有需要的加强安全防范其实可以尝试下了。
9、防火墙安全
一般化数据库前面都会有主备的墙，不过从成本上考虑，很多企业都是单个或者裸奔的，有自己的硬件防火墙最好，没有的话也可以使用系统自带的防火墙，然后在加上其它白名单和中间件白名单过滤辅助措施，也能防止一部分问题。
10、端口安全
默认端口是3306，这个最好修改下，为了方便记忆，你可以根据的IP地址来加密动态调整，不过如果生产网络允许，也可以定期修改，最好不要影响研发进度。
11、记录安全
删除操作系统记录的敏感数据，比如.mysql_history、.bash_history 等，及时清理，移除和禁用.mysql_history文件。
人是安全的主导，管理的对象要从两个角度来看，从信息角度来说就是MySQL本身的安全，要防止数据的丢失和免遭破坏;从技术角度来说就是整个系统的安全，要防止系统的瘫痪和免遭破坏。
最后说句题外话，监控和审计，安全主要是防患于未然，没有谁希望一天到晚接到各种警报，最好根据公司的实际情况订个详细的规章制度，不要觉得这个麻烦，有些你可能并不觉得有用，但是呢?我希望是没有但是。
更多数据库安全干货，关注昂楷科技官网！
