电话:023-68429836

传真:023-68037655

邮箱:sz@cqsztech.com

地址:重庆市科园三路南方花园
B区银杉楼二单元10-1#

中小企业如何优雅的管理多机房服务器账号

发布时间:2017-04-05 10:23:30

 

前言

本文内容大致分成四部分:

  1. 选择,我们初步选择的时候会考虑哪些问题。

  2. 需求分析,分析我们的主要需求是什么,如何与服务进行紧密结合。

  3. 如何实施,因为运维人员比较关注工具的落地过程,所以我也重点讲讲这块,但是不会像很多文章一样讲详细部署过程,我会着重分享部署过程中容易出错的地方。

  4. 演变历程,以我在这家公司的经历为例,从一个最简单的需求发展到能够满足不同业务的需求,并最终满足比较苛刻安全的一个过程。

1、选择

  • 整个故事要从一台老旧的服务器开始

那年,我们的集群规模有400多台服务器,部分是很稳定地,大家慢慢就忽略掉它了。突然有一天监控系统上发现一台边缘很老的服务器负载太高,影响了主站的稳定性。

我的第一反应就是让业务运维登陆上去处理,结果过了5分钟业务运维反馈说“密码错误”。因为我们有业务运维和系统运维区分,所以我让系统工程师去登录一下。

结果不幸的是,系统管理员反馈“这个服务器比我们所有的工程师都早出现在这个公司,大家都不知道他的密码”。这个时候就非常着急了,我们收到大量的用户投诉。一个本来五分钟就可以解决的问题,但是我们却花了两个小时。

最后我们开总结会的时候,大家都认定这个问题得必须重视了,业务的扩展非常快,我们不可能每一个服务器都记录一个帐号,我们需要有一套统一的身份认证。

2、最初的需求诞生了

当我们还在使用 SSH 跟 SCP 的时候,每个员工只需要一个密码,不管是登陆生产环境还是测试环境。我更改密码的时候也立即生效,而且我不想让 SA 知道我的密码,这就是我们最初的需求。

明确了需求之后,我们就开始考虑选择什么工具合适。有一种方案很简单就是我们用一个配置管理工具把这个服务器上面的 shadow/passwd 文件管理起来。

但是这样很被动,我所有的操作都依赖于它,我很多的操作生效期都会受到影响。还有另一个解决方案就是身份认证系统,我们知道这个是人人一直在用的  Kerberos,还有 OpenLDAP 也是一个比较热门的,最后就是商业产品堡垒机。

而创业公司的我们认为成本是第一要素,毋庸置疑首选就是开源。究竟是选择 kerberos 还是 OpenLDAP 呢?

我们请教了一个以前用过这方面的大拿,他推荐使用 OpenLDAP,因为使用起来很简单,就是用账户密码登陆。而 Kerberos 他可能会比较复杂一些,因为它有 Ticket 的认证过程。

所以我们就初步选择 OpenLDAP 了。同时我们发现国外的大厂 Facebook 和 谷歌都要使用 OpenLDAP,这就给了我们很大的信心。

同时,我们与商业产品进行对比,主要是价格和功能上有大的差异。

  • 价格方面: 一个机房我只要一台服务器,甚至是半台就可以搭建 OpenLDAP 服务,大约成本不到2万,而这个商业的堡垒机需要将近20万的成本。

  • 架构模式: 差不多,一个 CS 一个 BS。

  • 授权模式: 就是我们在对用户的权限管理方式,商业会比较有优势,这方面考虑的还是不错。还有操作回放是商业比较好的一个特征,因为他们支持这种审计功能,他们知道每一个用户登陆上去都在做什么。

     但是后面这个开源也有,我们是通过 script 命令,就是可以把一个用户所有的操作包括回显都可以记录。这个还是挺不错的。

最主要的就是价格,老板说 OK 就可以了,毕竟老板对钱都是非常敏感的。

3、如何实施 OpenLDAP

我介绍一下 OpenLDAP,它是轻量级目录访问协议,它特别适用于查询多但写入少的场景,可以做到毫秒级响应,但是如果是变更多的场景就不合适了。

然而它是怎么工作的呢?我们需要在需要认证的服务器上安装一个 OpenLDAP 的客户端,这个客户端其实是系统级别就已经是绑定了,我们就从这个图来看,我们是首先处于左下角。

用户登陆的时候,先登陆第一台跳板机,登陆上去的时候,其实访问的是本地的 PAM 模块,他通过 nsswitch 模块访问调用两个文件 passwd & shadow,但是里面还有一个是可以支持多源的权限访问方式。

可以调动 OpenLDAP 的客户端,把帐号和密码发送给 OpenLDAP 服务器端(右下角的那台服务器),如果再 OpenLDAP 服务器端匹配正确,就返回给所登陆的服务器【OK】,这时我们就可以顺利的登陆服务器,这个是和使用正常登陆方式一模一样的。

OpenLDAP 记哪些信息,包括用户ID用户帐号,用户密码,包括权限的定义。这里涉及到提权的过程,因为我们每个人在有了 LDAP 账号之后,登陆到服务器上都是个人账号,而大部分的时候我们是有切换到其他账号需求的。

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 安全考虑

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

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

非常庆幸的是 OpenLDAP 支持 TLS 的证书认证方式。这里有一个建议,就是大家做证书的时候一定要使用泛域名证书。为什么?

因为你可能涉及到每一个组机房都使用唯一的一个域名。你所有的机房都可以使用同一个证书,因为你不用管哪一个机房都可以使用泛域名证书。

同时我们还做了限制登录的方案,这个跟 OpenLDAP 没有关系。只是我们使用 PAM 模块对登录失败用户进行限制而已。