新年第一篇文章,很久没有更新博客了,今天梳理一下近期开发的堡垒机系统设计思路,公司内部已经开始上线使用,由于细节部分不具备通用性,后续会做成开源版本,这里仅将系统设计思路做一个展示,与大家共同探讨。

一、项目由来

  由于公司是上市公司,所以对Linux系统权限部分要求非常严格,每半年都需要经过美国的SOX合规法案审计,因此公司采用了一套商用的堡垒机解决方案,个人账号通过动态key口令登陆系统,然后再选择需要登陆的服务器即可,流程非常简单,有完善的权限控制、日志审计等功能,由于公司审计、流程等原因,这套系统是不能被更换的,商用的优点当然不用说了,相对完善的功能、运行稳定等,更重要的是,它承担了系统权限的使用风险,如果因为堡垒机系统造成的系统损失,那么它一定是需要承担一定责任的,但是缺点也同样存在,例如某一个研发人员要申请系统只读权限,那么运维人员就需要登陆堡垒机后台,配置该研发的登陆名、登陆主机IP、分配相应的权限等等,如果个别需求还好,但是上千人的研发团队,每天都有那么一波人来申请权限的话,我相信没人愿意每天干这活,而且商业堡垒机为了赚钱,它也是会限制连接数的,比如仅允许一台堡垒机同时登陆2000人,如果不够了,就需要购买session,面对现在的不利因素,所以决定在该商用堡垒机下,再搭建一台内部堡垒机系统。

  并不是所有的IT人员都使用内部堡垒机,运维人员相对稳定,不需要频繁的配置权限,因此使用商用堡垒机即可,对于研发人员,权限变更频繁、新增申请频繁,因此使用内部堡垒机系统,下面来重点介绍一下系统的使用流程。

二、系统架构图

paramiko模块打造公司内部堡垒机系统_python

三、流程详解

  登陆内部堡垒机首先需要登陆商用堡垒机,虽然内部堡垒机也有命令审计功能,但是由于开始介绍的原因,因此必须要经过商用堡垒机,这样操作命令等信息也会被同步记录到商用堡垒机,供SOX审计使用,下面按步骤介绍内部堡垒机的使用流程。

1、申请权限,Leader审批

  研发Leader做为审批成员,这样就解决了运维人员枯燥的操作,同时每个研发人员仅能够申请自己负责的应用服务器权限,这部分信息通过公共接口获取,下图为系统查询结果。

paramiko模块打造公司内部堡垒机系统_运维开发_02  

  查询结果显示了自己可以申请的服务器,那么只需要勾选需要登陆的服务器,点击批量申请即可,这里权限最多仅为3天

2、Leader接收审批邮件

  研发所申请应用的Leader,会收到系统发送的邮件通知,询问是否审批通过,如下图所示。

paramiko模块打造公司内部堡垒机系统_运维开发_03

3、审核通过,登陆系统

  此处为重点,之前我们说过每个研发的登陆权限,需要运维人员来配置,那么这里就不需要了,商用堡垒机为所有研发人员开放一个公用的只读账号,并且登陆后跳转到我们的Linux主机,然后运行内部堡垒机系统,此时用户再输入自己内部的账号口令即可,系统会在数据库中查出他之前所申请的权限,通过输入相应的IP序号即可登陆系统。

paramiko模块打造公司内部堡垒机系统_paramiko_04

4、后台实时监控、日志审计

  用户登陆的情况均能够通过后台监控系统查询到,例如当前在线用户、执行命令、也同样可以踢出该用户等等,如下图所示。

paramiko模块打造公司内部堡垒机系统_运维开发_05

paramiko模块打造公司内部堡垒机系统_python_06

四、Paramiko模块

  系统开发采用 Python+Django 框架,SSH功能采用python的Paramiko模块,其中用户登陆、密码验证均使用该模块完成,使用该模块的最大作用也是他的命令读取功能,使用paramiko模块封装一个SSH工具后,即可登陆Linux系统,由于采用字符实时发送与读取,所以使得终端看起来非常像我们直接用系统的SSH命令直接连接到远程服务器,因为每个字符都可以抓取,所以我们做命令审计也就很简单了,这是一个强大的模块。

  但有优势就一定有劣势,虽然我们通过paramiko获取到了用户实时输入的数据,但这毕竟是一个中间层,数据在传输过程中难免会遇到问题,比如复制粘贴、上下左右键支持的就不够友好,导致在less命令查看日志时无法准确的翻页定位,这也是目前遇到的一些问题。

写在最后

  内部堡垒机释放了运维人员的频繁操作,申请、审批等流程全部由研发团队独立完成,而且自己的系统就没有session数量限制了,也为公司节省了费用成本,目前正在将之前在商用堡垒机的研发用户,逐渐迁移到内部堡垒机上。

  整个系统并没有采用复杂的架构,也没有很深入的技术,功能层仅通过python的paramiko模块来完成,申请、审计等等通过框架来实现,后续会将该系统开源出来,做一个相对具备通用性的版本。