从密码的安全性上来说,我们希望它的长度和加密算法足够复杂。
从使用效率上来说,我们希望密码的管理能够更加的透明,至少能够省事一些,如果使用密码带来了一系列的问题,那么密码反而成为了直接使用者的一个累赘。
如果是存储明文密码,显然不是个好主意。 而且从安全的角度来说,是会被喷的。这一点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地址:
端口号:
用户名
业务名
密码
注释
对于密码存储逻辑的一些基本需求是: