MySQL数据库安全权限控制管理思想

(1)	权限申请流程要设置严格点，主需求不明确者知难而退。
(2)	开发和测试环境可以放开一些权限，IDC测试和生产环境严格控制数据库的写权限，并且读权限和对外业务服务器分离。
(3)	开发人员线上数据库权限分配：给单独的不对外服务的正式从库只读权限，不能分配线上正式主库写权限。
(4)	特殊人员(如领导)，开通权限时问清楚做什么，发邮件回复，注明用户名、密码、权限范围，多提醒操作注意事项。
(5)	特殊账号，由DBA专人控制，禁止在任何客户端上执行特权账号操作(如只能localhost或其它策略)

2.2. web账户权限分配制度

(1)	写库账号默认权限为select,insert,update,delete。不要给建表改表(create alter)的权限，更不能给all权限。
(2)	读库账号默认权限为select(配合read-only参数用)。 一定要确保从库是只读的(对所有人员)。
(3)	根据需要，最好专库专账号，不要一个账号管理多个库。碎库特别多的小公司根据情况处理。
(4)	如果是lamp、lnmp一体的环境，db权限主机要设置为localhost，避免用root用户作为web连接用。
(5)	web和数据库分离的服务器的授权可以根据web服务数量多少按IP或网段来授权。
(6)	安全性和方便管理，是矛盾的，要尽量达到一个平衡的状态，如何是平衡就要根据具体公司和业务来衡量了。

2.3. web账户授权实战案例

生产环境访问主库授权：

grant select,insert,update,delete on blog.* to 'blog'@'10.0.0.%' identified by '123456';

生产环境访问从库授权：

grant select on blog.* to 'blog'@'10.0.0.%' identified by '123456';

2.4. 生产环境读写分离账户设置

主库(提供写)：blog 	passwd 	ip:192.168.65.133 	port:3306
从库(提供读)：blog 	passwd 	ip:192.168.65.134 	port:3306

两个账号的权限是不一样的。

除了IP之外，账号、密码、端口等看起来都是一样的。尽量为开发人员提供方便。

在数据库设计上，开发人员应该设计优先连接读库，如果读库连接超时，可以考虑读主库，从程序设计上来保证提升用户体验。当然也要根据主库的繁忙程序来综合考虑。具体情况具体分析。

3. 数据库客户端访问控制

(1)	更改默认mysql client端口，如phpadmin管理端口为9999，其它客户端也是一样。
(2)	数据库web client端统一部署在1-2台不对外服务server上限制ip及9999端口只能从内网访问。
(3)	不做公网域名解析，用hosts实现访问或用内部IP访问。
(4)	phpadmin站点目录独立于所有其它站点要目录外，只能由指定的域名或IP地址访问。
(5)	限制使用web连接的账号管理数据库，根据用户角色设置指定账号访问。
(6)	按开发及相关人员根据职位角色分配管理账号。
(7)	设置指定账号访问(apache/nginx验证+mysql用户登录限制)
(8)	统一所有数据库账号登录入口地址。禁止所有开发人员私自上传phpadmin等管理库管理的程序。
(9)	开通VPN，跳板机，内部管理数据库。

4. 系统层控制

(1)	限制或禁止开发人员SSH ROOT管理，通过SUDO细化权限，使用日志审计。
(2)	对phpadmin端config等配置文件进行读写权限控制。
(3)	取消非指定服务器的所有phpadmin web连接端。
(4)	禁止非管理人员管理有数据库web client端的服务器权限。

5. 读库分业务读写分离

对数据库的select等大量测试、统计、备份等操作，要在不对外提供select的单独从库执行。

不同的从服务器，可以按业务进行拆分：

--为外部用户提供查询
--用来备份
--提供公司内部后台、脚本、日志分析及开发人员服务的从服务器。

这样的拆分除了减轻主服务器的压力外，还使得对外用户浏览，对内处理公司内部用户业务，及DBA备份业务互不影响。

6. 数据库运维管理思想核心

(1)	未雨绸缪，不要停留在制度上，而是，实际做出来。
(2)	亡羊补牢，举一反三
(3)	完备的架构及备份恢复策略。
(4)	定期思考，并实战模拟以上策略演练。

linux学习笔记