推广堡垒机要点

原创 赤水  2016年3月16日 01:40 阅读 260 次

不搞定这几点,互联网公司推堡垒机没门

『名词定义』
       堡垒机:也叫运维审计系统,主要用来解决IT运维过程风险,可以实现运维人员实名制管理,运维权限最小化控制,运维过程审计等功能。
『导读』
      互联网企业是一个高度依赖IT信息系统的行业,一般互联网企业IT信息系统少则拥有三五百台服务器,多则有几千几万,甚至几十万台服务器。所以如何保障IT系统的稳定、安全运行是所有互联网企业非常关注的课题。堡垒机作为一个IT运维过程风险控制的解决方案在互联网行业是非常刚性的需求,很多互联网企业早就部署了堡垒机,但是近几年随着企业规模增大、运维自动化技术的发展,传统堡垒机逐步成为了IT运维的一个障碍,很多互联网企业不得不重新进行选型,甚至将老的堡垒机下线。本文将总结某大型互联网公司所碰到的问题,并分享堡垒机的实施经验,供大家参考。

背景简介
     本文经验阐述是一个大型互联网企业的真实经验,由于某些原因,不方便直接表明企业名称。该公司目前的服务器数量已经超过30000台,开发和运维人员超过2000人。IT运维也已经经历了好几个阶段,目前已经全面进入了自动化运维阶段,大部分的部署、上线、更新、备份、监控等都实现了自动化作业。
      堡垒机作为目前IT运维安全控制最重要的解决方案,公司也在2012年就引入了堡垒机方案。在推行堡垒机的三年时间里,确实遇到了不少的挑战和困难,但最终还是在两家企业的紧密合作中解决了。目前30000多台服务器已经全面纳入堡垒机的管理,所有IT运维人员和开发人员的操作都必须经过堡垒机的控制和审计,做到了所有IT操作过程可见、可控、更安全。

 本文总结了公司三年多堡垒机的实施改进经验,与大家一起分享。
      挑战一:自动化运维和堡垒机的冲突
因为业务的需要,公司经常是一次性采购几百台服务器上线,以前靠手工安装和配置的方法肯定行不通了,所以目前都是采用puppet等自动化工具安装。但发现堡垒机成为了自动化运维的障碍,puppet等自动化运维工具没法通过堡垒机连接服务器。下面简单说明一下原因:

                                                                                         (如图1)

 

无堡垒机情况:自动化服务器都是通过内置的脚本或者程序直接连接响应的目标服务器,一般都是自动化服务器和目标服务器直接建立SSH会话连接,如图1,服务器端的认证可以是用户密码和SSH密钥,由服务器来完成认证。

部署堡垒机后:自动化服务器连接服务器前必须得经过堡垒机了,整个连接过程就变成了自动化服务器需先和堡垒机建立SSH会话,然后由堡垒机和目标服务器建立SSH会话,整个过程如图2。这个过程的变化会导致自动化服务器脚本登录失效,而且还带来了几个难题:

  • 自动化服务器如何完成和堡垒机的身份认证,如果堡垒机登录有双因子认证怎么办?
  • 堡垒机怎么选择目标服务器?因为堡垒机并不知道自动化脚本想推给哪台目标服务器,只有自动化服务器自己知道。
通过和工程师进行沟通,SSH网关模式可以让自动化运维执行起来,具体原理如图3。

      堡垒机自动化运维解决方案:首先说明,部署堡垒机后期望完全没有影响习惯是不可能,只能将影响降低。堡垒机针对自动化运维的解决方案是需要在自动化运维服务器上启用SSH网关,负责将自动化服务器端的SSH连接转发到堡垒机,这样做的目的是帮助堡垒机完成选择目标主机IP的问题。换句话说自动化服务器连接服务器的方式还是SSHhostname@X.X.X.X ,那以前做好的自动化运维脚本都无需修改,可以直接使用。

     挑战二:运维习惯的改变
堡垒机是个逻辑串联设备,所有的SSH、RDP连接都需要通过堡垒机进行代理转发,堡垒机才能够实现审计和控制。那这个过程的变化,就给运维的习惯带来了很大的影响。因为有运维、开发人员2000多人,一个小小的习惯变更,意味着要有2000多次的配置。这对推广堡垒机的安全部门来说,压力相当大。
部署堡垒机后,一次普通的SSH连接过程就会变成如下图样子:

 

  也就是说不管连接任何设备,都必须先连接堡垒机进行认证,然后在堡垒机里面选择目标服务器。这个变化意味着,运维人员secureCRT/xshell里面的主机登录配置全部失效,运维人员得重新配置。


通过双方的深入沟通,确定了三种运维方案,并行推广:
  •     跳板机登录(运维人员优先推荐):运维人员在没有堡垒机之前,基本都是通过一台跳板机进行登录服务器。跳板机通过AD域的方式建立了所有运维人员的帐号,每个运维人员通过自己的帐号先登录到跳板机,然后在跳板机里面再登录目标服务器运维。部署堡垒机后,只需要在原跳板机上进行一次SSH的代理网关设置,所有的运维习惯都能够保留下来。具体的代理网关原理和设置方法和上文自动化运维一致,请参考上文理解。
  •     web界面B/S登录(开发人员优先推荐):开发人员SSH登录技能水平参差不齐,所以主推WEB方式运维,通过堡垒机的web界面认证,在堡垒机里面选择一台服务器进行登录即可。这种方式方便易用,开发人员还是比较容易接受。

 

运维脚本导入CRT/putty:SecureCRT/Xshell/putty等运维工具应用还是非常广泛,很多运维人员已经将自己经常要登录的服务器信息添加到工具会话信息中了。但是部署了堡垒机后,这些配置好的会话信息都无法登录了。堡垒机的运维脚本导出功能可以缓解这个问题,每个运维人员只需要从堡垒机web界面下载一个自己的脚本导入到SecureCRT中,又可以直接登录相应目标服务器了。而且运维人员一次性打开多个主机,并在多个主机批量执行命令等高级功能都可以支持。

 

挑战三:性能负载均衡和异地灾备

堡垒机推广也是一个循序渐进的过程,在2012年的时候也是买了一台堡垒机进行尝试,后面随着应用的成熟,才逐步扩展到10台。因为目前主机已经超过30000,并发的SSH会话数常规都会在3000左右,最高峰超过6000条,所以必须组建集群来扩展性能。而且随着堡垒机全面普及,堡垒机自身的稳定性也越来越重要,所以又衍生了异地灾备的需求。

经过多方论证,最后采用的方案是:

该方案的几个核心点是:

  • 三地机房所有堡垒机配置进行自动同步,使其具备同样的能力,登录任意堡垒机都可以进行配置和运维;
  • 每个机房的HAproxy将自己辖区多台堡垒机做成集群,并执行负载均衡任务;
  • 三地机房的HAproxy的IP地址都注册到一个域名下;
  • DNS实现智能解析,根据源IP地址选择离自己最近的HAproxy集群IP;


挑战四:堡垒机配置工作量巨大,如何自动化
堡垒机自身的配置工作量这么大是最开始大家都没有想到的坑,但是现在回想起来,其实也很正常。30000多台主机,2000多个人,要想做权限的严格控制,也就是说要将2000多个运维人员和30000多台主机的对应关系建立起来,想想就理解了。总结下来堡垒机配置工作最复杂的地方是:

  • 人员配置:AD域包含了全公司的人员,可以采用AD域来进行同步,但是公司部门划分并不等同于授权分组划分,那如何将人员合理分组,并快速分组,工作量很大。
  • 资产配置:公司已经拥有了CMDB固资管理系统,堡垒机怎么和CMDB进行同步更新、删除。
  • 授权规则配置:公司的配置规则已经上万条,在堡垒机自身web界面维护这么大量规则是个非常困难的。
  • 人员调动、资产故障变更报废、新增人员等非常普遍,如何快速完成配置。


为了解决堡垒机配置的问题,和厂商合作做了定制开发,堡垒机将自身的用户管理、资产管理、权限管理做成标准的API,公司根据API实现CMDB固资系统、帐号管理系统、自动化运维系统的对接。现在基本实现了:

  • CMDB固资系统的资产增删改,都会主动推动到堡垒机;
  • 可以根据资产的分组属性变更,自动完成堡垒机的授权规则变更;
  • 人员帐号的增删改也都可以主动推送到堡垒机,可以自动调整堡垒机的授权规则;

换句话说,现在公司的堡垒机配置基本实现自动化,以下是某厂商堡垒机API调用实现逻辑的说明

  挑战五:堡垒机双因子认证困难重重
堡垒机自身安全是大家都能够意识到的一个问题,其中尤其以用户认证环节最重要,一般大家很自然就会想到双因子认证。但是实际推行堡垒机过程中,双因子认证也是一个非常大的坑。主要有几个点:

  •     启用双因子认证后,自动化运维基本瘫痪,自动化服务器无法登录了;
  •     采用哪种可靠、安全、高效的双因子认证手段;
  •     经过多种方案论证,目前采用『手机APP认证+多种认证并存』来解决,具体是:
  •     对于自动化运维服务器、跳板机等还是采用单因子认证,对于运维人员采用双因子认证。这得益于堡垒机支持按照用户、用户组设置不同的认证模式。
  •     双因子认证采用手机APP模式,安装使用也方便,还可以避免usbkey、动态口令分发、丢失、损坏等麻烦事情。

  堡垒机目前可以支持的手机OTP认证APP比较多,主流的谷歌认证、FreeOTP、洋葱、阿里身份宝都可以支持。而且这些OTP认证手机APP都有IOS、安卓、windowsphone等不同平台,适应性非常广。

 总体来说,堡垒机的推广应用过程还是挺复杂的,大家在选择堡垒机的时候千万别仅仅关注厂家说的功能有无,更多还是要基于实际运维环境做出适配性的选择。对于这样规模的互联网企业来说,选择堡垒机的几个关注点是:

  • 堡垒机对运维习惯、自动化运维的影响情况评估;
  • 堡垒机的开放性评估,因为互联网企业基本都有自己的运维开发团队;
  • 堡垒机的扩展性评估;

另外不仅仅是互联网行业,金融、运营商、能源、省部级政府等只要服务器超过500台以上,这些关键点都可能会成为推广堡垒机的障碍。

本文转自  运维帮

本文地址: http://blog.lssin.com/readblog/74.html
版权声明:本文为原创文章,版权归  赤水 所有,欢迎分享本文,转载请保留出处!

发表评论


表情