前言
堡垒机是一种运维安全审计系统。主要的功能是对运维人员的运维操作进行审计和权限控制,风险规避。同时堡垒机还有账号集中管理,单点登陆的功能。
堡垒机有以下两个至关重要的功能:
集中管理
安全审计
当公司的服务器变的越来越多后,需要操作这些服务器的人就肯定不只是一个运维人员,同时也可能包括多个开发人员,那么这么多的人操作业务系统,如果权限分配不当就会存在很大的安全风险,举几个场景例子:
设想你们公司有300台Linux服务器,A开发人员需要登录其中5台WEB服务器查看志或进行问题追踪等事务,同时对另外10台hadoop服务器有root权限,在有300台服务器规模的网络中,按常理来讲你是已经使用了ldap权限统一认证的,你如何使这个开发人员只能以普通用户的身份登录5台web服务器,并且同时允许他以管理员的身份登录另外10台hadoop服务器呢?并且同时他对其它剩下的200多台服务器没有访问权限
小型公司的运维团队为了方面,整个运维团队的运维人员还是共享同一套root密码,这样内部信任机制虽然使大家的工作方便了,但同时存在着极大的安全隐患,很多情况下,一个运维人员只需要管理固定数量的服务器,毕竟公司分为不同的业务线,不同的运维人员管理的业务线也不同,但如果共享一套root密码,其实就等于无限放大了每个运维人员的权限,也就是说,如果某个运维人员想干坏事的话,后果很严重。为了降低风险,于是有人想到,把不同业务线的root密码改掉就ok了么,也就是每个业务线的运维人员只知道自己的密码,这当然是最简单有效的方式,但问题是如果同时用了ldap,这样做又比较麻烦,即使设置了root不通过ldap认证,那新问题就是,每次有运维人员离职,他所在的业务线的密码都需要重新改一次。
因此,堡垒机的诞生就是为了规避这些高风险的问题,同时减少繁琐的重复性工作。
工作流程图:
一、需求分析
1.所有生产服务器配置iptables安全策略,只能通过堡垒机来登陆,用户首先登陆进堡垒机,再通过堡垒机跳转登陆target host.
2.各IT组,按职能划分一个统一的可以真实登陆target host的账户
3.组内的成员,使用自己的账号登陆堡垒机,再使用小组账号登陆target host.
4.审计。记录下各人员的操作记录,出现问题时可以溯源
二、表结构设计
本着最少的字段数据冗余的原则,设计了如下几张表,如果各路大神有更好的设计思路,请指点一二~
表创建代码:
1 | import os,sys |
三、项目代码
1.整体结构:
2.功能说明:
1.管理功能
——表结构初始化创建
——添加组
——添加主机
——添加用户
——添加组-主机绑定
doc目录下提供了几个添加元素的example文档,使用yaml模块解析这些文档,解析为dict数据类型,将解析出的数据添加进数据库内,例如:
对应实现添加user功能的函数:
2.用户视图
——查看属组
—查看属组有权限登陆的主机
——直接输入IP登陆主机
—查看该IP主机是否有可用的有权限的账户可供登陆
——开始会话连接,执行命令时向记录审计志表添加item
ssh会话实现:
使用了paramiko的demo模块,这个模块本身的交互功能是使用select模型来实现的,使用select监听会话句柄、sys.stdin(标准输入)的可读可写状态,实现字符在终端界面的输入输出。关于I/O多路复用几种模型的个人解读,可以翻看此前的博客:网络编程之I/O模型(以吃牛肉面为例)。
对paramiko交互模块进行修改添加记录功能:当标准输入触发回车键时(代表一个命令输入完毕开始执行),记录下执行人、登陆用户、时间、命令内容,写入数据库。修改后的交互模块代码如下:
1 | # Copyright (C) 2003-2007 Robey Pointer <robeypointer@gmail.com> |
四、运行效果:
在堡垒机上添加用户,在目标主机上添加一个对应登陆用户:
在堡垒机上该用户环境变量配置文件中加入:
1 | /usr/local/python3/bin/python3 /usr/local/packages/MyFortress/bin/user_interface.py |
使其打开shell后自动运行堡垒机程序,效果如下:
查看数据库审计志表,记录正常:
写了一个星期,终于能跑起来了,github链接:
https://github.com/yinwenqin/MyFortress-Server