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

一、项目由来

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

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

二、系统架构图

三、流程详解

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

1、申请权限，Leader审批

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

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

2、Leader接收审批邮件

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

3、审核通过，登陆系统

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

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

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

四、Paramiko模块

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

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

写在最后

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

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