运维平台里的密码管理模块建设
从密码的安全性上来说，我们希望它的长度和加密算法足够复杂。
从使用效率上来说，我们希望密码的管理能够更加的透明，至少能够省事一些，如果使用密码带来了一系列的问题，那么密码反而成为了直接使用者的一个累赘。
如果是存储明文密码，显然不是个好主意。 而且从安全的角度来说，是会被喷的。这一点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地址：
端口号：
用户名
业务名
密码
注释
对于密码存储逻辑的一些基本需求是：
- 密码在数据库中是加密存储
- 读取时根据权限进行过滤，对指定用户开放密码查询权限
- 加密算法是可逆的，但是算法细节不公开
- 后期可以通过接口的方式来提供权限访问，而不是直接返回密码