运维平台里的密码管理模块建设

运维管理中，我们总是会碰到各种各样的密码。其实对于密码的管理就是一个痛点。

从密码的安全性上来说，我们希望它的长度和加密算法足够复杂。

从使用效率上来说，我们希望密码的管理能够更加的透明，至少能够省事一些，如果使用密码带来了一系列的问题，那么密码反而成为了直接使用者的一个累赘。

如果是存储明文密码，显然不是个好主意。 而且从安全的角度来说，是会被喷的。这一点GitHub已经踩过坑了，国内的一些论坛也中过招，也就是以后来经常听说的撞库。

我来举一个流程，比如对于业务同学来说，他需要申请一个数据库账号，那么这个操作是技术范畴很简单的，但是密码如何管理。我们直接发给他，通过即时通讯工具还是通过邮件，如果里面都是明文密码，是很不规范的。

我们之前是这么做的。

DBA会生成一个随机密码，对于这个密码，DBA压根不去关心它的值，然后把密码交给加密专员，由专员加密，然后返回给DBA的就是一个加密串，然后这个加密串就可以发送给业务同学了，业务同学也压根不需要去了解真正的密码，直接使用即可，在配置文件里就是加密串，程序会有对应的解密方法去解密。

这种方法好处很明显，加解密是完全解耦的，而且密码其实是恢复的，而且加密可以使用多种加密算法，就算得到解密串，也不一定能够轻松得到真实密码。

但是这样有一个成本就是这个事情是不是需要专门的一个人来做，很多公司可能没有这样的专员，那么做这个事情就难有章法了。

至少从迭代的角度来说，我们可以做到的就是密码是部分发送。

这样一来这个密码就是相对安全的。

这是一种场景，还有一种是对于很多的账号信息，都有对应的密码，我们可能是用KeyPass或者KeePass来存储的。这种客户端密码管理软件有个好处是管理起来足够方便，不好的地方就是密码管理不够规范，你记录的密码信息只有你熟悉，别人没法直接参与进来。

所以对于第二个部分我做了初步的设计，就是把密码管理范围进行了限定：

目前密码管理的内容分为三个部分：

1.创建数据库权限时的用户名，密码信息

2.数据库的管理员密码

3.操作系统所需的部分账号信息，比如dba_mysql，dba_redis，dba_hadoop等

表结构设计

db_userpass_details  普通用户表

数据库类型：

IP地址：

端口号：

允许访问IP

权限

用户名

业务名

密码

密码是否过期

注释

db_adminpass_details  管理员用户表

IP地址：

端口号：

用户名

允许访问IP

业务名

密码

密码是否过期

注释

连接串名

sys_adminpass_details

IP地址：

端口号：

用户名

业务名

密码

注释

对于密码存储逻辑的一些基本需求是：

1. 密码在数据库中是加密存储

2. 读取时根据权限进行过滤，对指定用户开放密码查询权限

3. 加密算法是可逆的，但是算法细节不公开

4. 后期可以通过接口的方式来提供权限访问，而不是直接返回密码