今天在帮一位开发同学处理一个权限问题的时候，无意中想起来在2年前一位DBA同事的抱怨，问题的大概背景是：有一位开发同学发来了一些IP,让DBA帮忙看看这些IP有没有权限访问数据库，当时这位同事有些无奈，因为常理来看，要连哪个数据库应该是件很清晰确定的事情，而且就算防火墙没问题，最起码得知道是哪些用户，而这些对于业务同学来说，我们应该知道，连猜带蒙也应该知道。
我想了想这里折射出几个问题：
1）业务侧对于权限的管理很多都是粗放型的，很多密码都是明文，基于excel等方式管理，可能会有小范围的文件方式分发
2）服务配置或权限发生变更，这些信息在业务侧没有统一的配置平台去解决，在本地的配置管理中也难以统一更新
3）对于业务侧来说，权限使用也是两级化，要么是清一色共享账号的习惯，要么是个人化账户，其中个人化账户随着人员流动很多权限管理难以追溯。
4）业务侧对于数据库的权限体系了解较少，沟通交流中会有代沟
5）因为密码是加密模式而且不可逆，很多DBA也没有统一的平台维护现有环境的账号密码信息，简单来说，他们很可能也不知道明文密码是什么
6)权限边界不清晰，DBA认为业务侧应该管理好自己的密码，而业务侧认为DBA就需要管理好这些密码（明文密码）
看完这些问题，真是让人心灰意冷，看起来就是一个账号的事情，这么简单的事情竟然大家都做不好。
通常在MySQL中，账户管理的规则也不尽相同，我试着举一个例子来说明下其中的有趣之处。
比如我们对数据库用户dev_test_ro分配了mytest数据库的只读权限。
create user dev_test_ro@'192.168.100.%' identified by 'mypassword';grant select on mytest.* to dev_test_ro@'192.168.100.%' ;
这里会和开发规范紧密结合起来，大概有这些门路。
1） 用户名，按照多级划分的方式，可有按照“环境_服务名_权限标示”的格式进行命名：
2） 环境
“环境”一般分为生产环境和测试环境，生产环境的用户名以“srv_”开头，测试环境的用户名以“dev_”开头；
3） 服务名
用以标示这个数据库用户所连接的服务；
4） 权限标示
用于进行用户权限类型的标示，可以分为三种权限：只读，基本读写，高级读写，分别用 ro， rwl， rwh 来表示，一般来说这三种权限的分类如下：
只读用户 ro，只有 select 权限；
基本读写用户 rwl，除 ro 的权限外，还有 insert,update,delete,exec 等权限；
高级读写用户 rwh，除 rwl 的权限外，还有 create， drop， alter 等权限。"
如果有两个IP 192.168.100.101,192.168.200.101,对于数据库用户dev_test_ro来说，在如上的权限体系中就会创建两个数据库用户，分别是
dev_test_ro@'192.168.100.%'和dev_test_ro@'192.168.200.%'
我们来说下今天开发同学提的问题，他需要开通一个新的网段的权限，也就意味着需要在数据库中创建一个新的账号，在数据库操作中，我们无须知道明文密码，一般都会使用加密串的模式克隆权限，如下图所示：
这种情况下，账号权限和加密串都是可以完全复制统一的。
这里有一个问题是如果业务侧也不记得密码了，或者密码管理不善，导致明文密码无法确认，数据库侧是否有相应的机制可以支撑。
也就是说，业务侧可以提供用户名，明文密码，想让我们验证下数据库的权限是否正常？
这里的重点就是host的部分，如下:
我们可以通过克隆账号复制一套127.0.0.1的同名账号，而且也可以避免业务侧误连接，可以快速实现服务后端的自检测。
而如果再退一步，如果业务侧的密码也忘记了，而且没有相应的明文密码信息可以提供，那么我们可以通过如下的方式关联：
这里就是建设密码管理模块的重中之重了，密码管理模块是一个相对独立的模块，可以对于密码加解密使用独立的算法逻辑，也就加密串和数据库层面的加密串可以没有关系，但是这两个加密串却可以无缝的衔接起来，可以通过密码管理中的加解密，通过额外的秘钥实现解密，而解密后的密码可以通过127.0.0.1的账号克隆进行加密串验证和权限快速测试。
按照这种思路，我们就可以提供一系列的服务可以来支持业务的这几类大问题，而且可以直接对标自助化服务。
网友评论