MySQL数据库安全权限控制管理思想
- 制度与流程控制
1.1 项目开发制度流程
开发环境à功能测试à压力测试à阿里云主机上线，通过较为完善的项目开发流程控制，防止很多潜在的问题隐患发生(目前公司只有开发测试直接到生产环境)。
1.2 数据库更新流程
开发人员提交需求à开发主管审核 àDBA审核à执行开发流程的数据库更新测试步骤。
最后在阿里云上线执行。需要说明的是在一开始提交需求，就会同时抄给以上人等。
通过较为完善的数据库更新流程控制，可以防止很多潜在的数据丢失破坏问题发生。
1.3 DBA参与项目数据库设计
在开发环节上，DBA最好可以参与数据库的设计与审核，从源头上减少降低不良设计及语句的发生，如果有可能可以做所有语句的审核工作，包括select，这个需要评估工作量是否允许。
1.4 各种操作申请流程
1) 开发测试等人员权限申请流程
需要权限直接发邮件并create task到DBA，协商后予以申请权限。
2) 数据库更新执行流程
A． 涉及到生产数据库重大更新，比如订单取消等，发邮件到技术总监以及DBA，判断业务是否允许，完成上述数据库更改。
B． 涉及到生产数据库小规模变更，比如产品要求做刷单操作，直接发邮件给DBA，抄送技术总监和开发负责人等。
3) DBA定期巡检数据库SQL语句，该优化的SQL提出建议，发邮件给相关开发责任人， 并抄送技术总监。一般提出优化SQL事宜需要1-3个工作日完善，需和开发等协商。
1.5 定期对内部人员培训
定期给开发及相关人员培训，还是从源头上减少降低不良设计及SQL语句的发生，并通过培训告诉大家数据库性能的重要性，让大家提升性能意识。
1) 数据库设计规范及制度。
2) SQL语句执行优化，性能优化技巧等。
3) 数据库架构设计等内容。
- 账户权限控制
2.1 内部开发等人员权限分配
1) 权限申请流程要设置严格点，让需求不明确者知难而退。
2) 开发和功能测试环境可以开放一些权限，阿里云正式环境严格控制数据库写权限，并且读权限和对外业务服务器分离。
3) 开发人员线上数据库权限分配，给单独的不对外服务的正式从库只读权限，不能分配线上正式主从库写权限。程序账号授权该库的SELECT，DML操作。
4) 如公司领导，开通权限时问清楚做什么，发邮件回复，注明主机IP、用户名、密码、权限范围，多提醒操作注意事项。
5) 特殊账号，由DBA专人控制，禁止在任何客户端上执行特殊账号操作(如只能localhost或其他策略)。
6) 临时在生产库申请账号，需要发邮件注明事项，发邮件给DBA。
2.2 Web账户权限分配制度
1) 写库账号默认权限为select，insert，update，delete，不要给建表改表(create，alter)的权限，更不能给all权限。
2) 读库账号默认权限为select(配合read-only参数用)。一定要确保从库是只读的(对所有人员)。
3) 根据需要，最好专库专账号，不要一账号管理多个库。碎库特别多的，根据情况处理。
4) web和数据库分离的服务器的授权可以根据web服务器数量多少按IP或网段来授权。
5) 安全性和方便管理，是矛盾的，要尽量达到一个平衡的状态，如何使平衡就要根据具体公司和业务来衡量了。
2.3 web账户授权实战案例
- 生产环境主库用户的账号授权：
GRANT SELECT,INSERT,UPDATE,DELETE ON blog.*TO ‘blog‘@10.0.0.%‘ identified by ‘TonyS1$521‘;
说明：这里表示给10.0.0/24的用户blog管理blog数据库的所有表(*表示所有库)只读权限和DML权限。密码为TonyS1$521。
- 生产环境从库用户的授权：
GRANT SELECT ON blog.*TO ‘blog‘@‘10.0.0.%‘identified by ‘ TonyS1$521‘;
当然从库除了做SELECT 的授权外，还可以加read-only等只读参数。
2.4 生产环境读写分离账户设置
给开发人员的读写分离用户设置，除了IP必须要不同外，我们尽量为开发人员使用提供方便。因此，读写分离的地址，除了IP不同外，账号，密码，端口等看起来都是一样的，这才是人性化的设计，体现了DBA人员的专业。
主库（尽量提供写服务）：blog TonyS1$521 ip:10.0.0.179 port 3306
从库（今提供读服务）： blog TonyS1$521 ip:10.0.0.180 port 3306
提示： 两个账号的权限是不一样的
提示：从数据库的设计上，对于读库，开发人员应该设计优先连接读库，如果读库没有，超时后，可以考虑主库，从程序设计上来保证提升用也要根据主库的繁忙程度来综合体验，具体情况都是根据业务项目需求来抉择。
- 数据库客户端访问控制
3.1 只允许特定IP和账号使用，要登记清楚。
3.2 限制使用web连接的账号管理数据库，根据用户角色设置指定账号访问。
3.3 按开发及相关人员根据职位角色分配管理账号。
3.4 统一所有数据库账号登录入口地址。禁止所有开发私自上传等数据库管理等。
3.5 远程维护主机和数据库：开通vpn，跳板机，内部IP等管理数据库。
- 系统层控制
4.1 开发环境、生产环境限制或禁止开发人员ssh root 管理，通过sudo细化权限，使用日志审计。
4.2 禁止非管理人员管理有数据库web client端的服务器的权限。
- 读库分业务读写分离
细则补充：对数据库的select 等大量测试，统计，备份等操作，要在不对外提供select的单独从库执行。因为在主库上执行有表锁(如果访问数据表很大时)。
主从使用规则
5.1 在master上主要操作为DML、DDL和部分SELECT操作‘
5.2 在slave上主要是SELECT查询操作。
- 定期巡检
6.1 慢查询日志分析；白名单机制à上线前审核所有SQL；
6.2 定期检查数据库内存使用命中率；
6.3 定期检查主从复制是否一致；
6.4 定期做好备份恢复测试à检查数据库备份文件的有效性；
6.5 定期检查主从数据库中数据表设计是否有多余索引；
6.6 定期检查数据库锁情况；
6.7 分析数据库TPS和QPS情况；
6.8 分析数据库主机资源使用比率à内存、CPU、磁盘I/O阻塞、网络等。