中交兴路运维总监：中小企业如何优雅的管理多机房服务器账号(2)

OpenLDAP 的提权管理做的比较强,它是 Sudoers schema 里面去定义每一组的具体权限,而每个人又对应到某个具体组内.这就能轻松做到我和这个组里的人权限一致,同时权限的变更是全局性的,所有服务器生效.

回顾最初需求

我们回顾当时最初的需求,并不是要做精细化管理,即只需要所有的人登录到服务器上,完成人员的账号认证,研发人员、运维都是个人用户,登陆上服务器之后使用 sudo 切换到 root 的 账号.

当时是用这种非常粗放的管理方式,当然我们数据库不在这个管理范围之内,因为这种OpenLDAP登陆数据库太危险了,不建议使用它们来管理数据库.

接下来是安装过程,(在这里就不细写了我着重讲客户端的配置过程)

我使用 authconfig-tui 命令就可以进入到这个模式,这个配置很简单,只要前面勾选五个选项,然后下一步把 URI 和 Base 配置完成就 OK 了.

但是运维关注的是,这些操作的背后究竟是做了什么事情.如果我操作完还不生效就需要去查看配置文件.其中包括这么几个配置文件：

1. /etc/ldap.conf

2. /etc/nsswitch.conf

3. /etc/sysconfig/authconfig

4. /etc/pam.d/system-auth

只要保证这些配置文件按要求进行修改,不用使用交互式工具也可以完成配置过程.

完成配置之后我们就会经常收到其他同事的抱怨,误操作删除掉系统文件,压力好大.接下来我们就开始了权限的精细化管理演变.

4、演变历程

4.1 精细化管理

上面就是权限的精细化管理的成员类别逻辑图：

• 第一级为系统管理员；
• 第二级就是应用运维,他能够做服务的变更；
• 第三级就是网络管理员,他能做执行一些命令操作,因为我们最担心是网络管理员以“权限不够”为名,让系统工程师干活.因此我们就给他增加了一些权限；
• 第四级就是 observer 这个角色,这个就是给研发用的,研发有需求看日志但是不能有操作权限的；
• 最后一个就是 Personal,这个就是个人,用于证明你就是你.

还有一个图非常重要,就是要跟大家讲一个普遍新手都会误会的地方,大部分人认为在 OpenLDAP 管理内,首先就是组,然后下面的分支是人,再下面的分支是权限.其实不是这样的,如下图：

其实人、组、权限都是并列的,具体而言,在这个人属性里面包含了一个元素 UID,如果五个人对应同一个 UID,那这五个人就是一个组.

权限分支内定义很多的权限组,权限组又有属性和组对应,因此人跟组、权限就对应起来了,所以大家看书的时候不要被误导了,这个就是落地的基本形式.

4.2 分布式管理

接下来问题来了,我们是一个车联网的公司,全国有将近十个机房,我们需要考虑这么多个机房的部署和维护工作.

最简单是我们所有的服务器都到一个地方认证,看似很棒的一个方案,但其实你想,这是不行的.因为我们很多时候有登陆服务器的紧急需求就是网络故障或者是普通服务故障.

如果是集中式管理,可能会导致网络有故障的时候服务器认证也有问题.所以解决方案是分布式管理,分布式认证.

这个跟 MysqlCluster 集群的管理方式是一样的,有 Master 节点负责写入,通过日志推到各个机房的 Slave 上面,然后在本地进行 redo 到 Slave 上.

同时所有的用户都是在本机房内的节点进行认证,所有的修改会被 rewrite 到 Master 节点上.下图就是具体日志,我们可以看看里面的描述：

这个就是在几点几分的日志,就是他把这个用户的密码改了.目前我们能做到七百台服务器同时并发登陆及更改密码,基本上公司大部分的需求我们都可以满足.

4.3 安全考虑

本以为完成全部的需求,这时候安全部门找到我们,质疑我们“你们这个东西安全吗?你们目前的安全状况确实是太糟糕了,所有用户的登陆过程密码我全部都看见了”……

这确实是太糟糕了,在我的经验里面,上线不到几小时就发现从马来西亚不断的有尝试暴力破解我们的服务器的情况,一旦尝试暴力破解成功所造成的影响是超过我们预期的.这样,我们就开始了安全方面的需求改造.

（编辑：ASP站长网）