C语言基础学习PYTHON——基础学习D13
20180918内容纲要:
堡垒机运维开发
1、堡垒机的介绍
2、堡垒机的架构
3、小结
4、堡垒机的功能实现需求
1 堡垒机的介绍
百度百科
随着信息安全的快速发展,来自内部的安全威胁日益增多,综合防护、内部威胁防护等思想越来越受到重视,而各个层面的政策合规,如“萨班斯法案”、“信息系统等级保护”等等也纷纷对运维人员的操作行为审计提出明确要求。堡垒机作为运维安全审计产品将成为信息系统安全的最后一道防线,其作用也将越来越重要。其作用主要是将需要保护的信息系统资源与安全威胁的来源进行隔离,从而在被保护的资源前面形成一个坚固的“堡垒”,并且在抵御威胁的同时又不影响普通用户对资源的正常访问。
阿里云堡垒机百度百科:
基于协议正向代理实现,对SSH、Windows远程桌面、SFTP等常见运维协议的数据流进行全程记录,再通过协议数据流重组的方式进行录像回放,达到运维审计的目的。
基于其应用场景,堡垒机可分为两种类型:
1.1 网关型堡垒机
网关型的堡垒机被部署在外部网络和内部网络之间,其本身不再直接向外部提供服务,而是作为进入内部网络的一个检查点,用于提供对内部网络特定资源的安全访问控制。这类堡垒机不提供路由功能,将内 外网从网络层隔离开来,因此除非授权访问外,还可以过滤掉一些针对内网的来自应用层以下的攻击,为内部网络资源提供了一道安全屏障。但由于此类堡垒机需要处理应用 层的数据内容,性能消耗很大,所以随着网络进出口处流量越来越大,部署在网关位置的堡垒机逐渐成为了性能瓶颈,因此网关型的堡垒机逐渐被日趋成熟的防火墙、UTM、IPS、网闸等安全产品所取代。
1.2 运维审计型堡垒机
运维审计型堡垒机的原理与网关型堡垒机类似,但其部署位置与应用场景不同,且更为复杂。运维审计型堡垒机被部署在内网中的服务器和网络设备等核心资源的前面,对运维人员的操作权限进行控制和操作行为审计;运维审计型堡垒机既解决了运维人员权限难以控制的混乱局面,又可对违规操作行为进行控制和审计,而且由于运维操作本身不会产生大规模的流量,堡垒机不会成为性能的瓶颈,所以堡垒机作为运维操作审计的手段得到了快速发展。
堡垒机有什么用呢?
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
1 当你公司的服务器变的越来越多后,需要操作这些服务器的人就肯定不只是一个运维人员,同时也可能包括多个开发人员,那么这么多的人操作业务系统,如果权限分配不当就会存在很大的安全风险,举几个场景例子: 2 3 设想你们公司有300台Linux服务器,A开发人员需要登录其中5台WEB服务器查看日志或进行问题追踪等事务,同时对另外10台hadoop服务器有root权限,在有300台服务器规模的网络中,按常理来讲你是已经使用了ldap权限统一认证的,你如何使这个开发人员只能以普通用户的身份登录5台web服务器,并且同时允许他以管理员的身份登录另外10台hadoop服务器呢?并且同时他对其它剩下的200多台服务器没有访问权限 4 5 目前据我了解,很多公司的运维团队为了方面,整个运维团队的运维人员还是共享同一套root密码,这样内部信任机制虽然使大家的工作方便了,但同时存在着极大的安全隐患,很多情况下,一个运维人员只需要管理固定数量的服务器,毕竟公司分为不同的业务线,不同的运维人员管理的业务线也不同,但如果共享一套root密码,其实就等于无限放大了每个运维人员的权限,也就是说,如果某个运维人员想干坏事的话,他可以在几分钟内把整个公司的业务停转,甚至数据都给删除掉。为了降低风险,于是有人想到,把不同业务线的root密码改掉就ok了么,也就是每个业务线的运维人员只知道自己的密码,这当然是最简单有效的方式,但问题是如果你同时用了ldap,这样做又比较麻烦,即使你设置了root不通过ldap认证,那新问题就是,每次有运维人员离职,他所在的业务线的密码都需要重新改一次。 6 7 8 9 其实上面的问题,我觉得可以很简单的通过堡垒机来实现,收回所有人员的直接登录服务器的权限,所有的登录动作都通过堡垒机授权,运维人员或开发人员不知道远程服务器的密码,这些远程机器的用户信息都绑定在了堡垒机上,堡垒机用户只能看到他能用什么权限访问哪些远程服务器。 10 11 12 13 在回收了运维或开发人员直接登录远程服务器的权限后,其实就等于你们公司生产系统的所有认证过程都通过堡垒机来完成了,堡垒机等于成了你们生产系统的SSO(single sign on)模块了。你只需要在堡垒机上添加几条规则就能实现以下权限控制了: 14 15 允许A开发人员通过普通用户登录5台web服务器,通过root权限登录10台hadoop服务器,但对其余的服务器无任务访问权限 16 17 多个运维人员可以共享一个root账户,但是依然能分辨出分别是谁在哪些服务器上操作了哪些命令,因为堡垒机账户是每个人独有的,也就是说虽然所有运维人员共享了一同一个远程root账户,但由于他们用的堡垒账户都是自己独有的,因此依然可以通过堡垒机控制每个运维人员访问不同的机器。
![](https://i-blog.csdnimg.cn/blog_migrate/8f900a89c6347c561fdf2122f13be562.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/961ddebeb323a10fe0623af514929fc1.gif)
1 审计管理其实很简单,就是把用户的所有操作都纪录下来,以备日后的审计或者事故后的追责。在纪录用户操作的过程中有一个问题要注意,就是这个纪录对于操作用户来讲是不可见的,什么意思?就是指,无论用户愿不愿意,他的操作都会被纪录下来,并且,他自己如果不想操作被纪录下来,或想删除已纪录的内容,这些都是他做不到的,这就要求操作日志对用户来讲是不可见和不可访问的,通过堡垒机就可以很好的实现。
2 堡垒机的架构
堡垒机的主要作用权限控制和用户行为审计。堡垒要想成功完全记到他的作用,只靠堡垒机本身是不够的, 还需要一系列安全上对用户进行限制的配合,堡垒机部署上后,同时要确保你的网络达到以下条件:
- 所有人包括运维、开发等任何需要访问业务系统的人员,只能通过堡垒机访问业务系统
- 回收所有对业务系统的访问权限,做到除了堡垒机管理人员,没有人知道业务系统任何机器的登录密码
- 网络上限制所有人员只能通过堡垒机的跳转才能访问业务系统
- 确保除了堡垒机管理员之外,所有其它人对堡垒机本身无任何操作权限,只有一个登录跳转功能
- 确保用户的操作纪录不能被用户自己以任何方式获取到并篡改
3 小结
对于堡垒机看完一遍视频仍然是懵逼状态,但觉得这东西很有用。不明觉厉。
对于后续如果有需求再深入研究,目前就这样吧。等以后在慢慢丰富。
4 堡垒机功能实现需求
业务需求:
- 兼顾业务安全目标与用户体验,堡垒机部署后,不应使用户访问业务系统的访问变的复杂,否则工作将很难推进,因为没人喜欢改变现状,尤其是改变后生活变得更艰难
- 保证堡垒机稳定安全运行, 没有100%的把握,不要上线任何新系统,即使有100%把握,也要做好最坏的打算,想好故障预案
功能需求:
- 所有的用户操作日志要保留在数据库中
- 每个用户登录堡垒机后,只需要选择具体要访问的设置,就连接上了,不需要再输入目标机器的访问密码
- 允许用户对不同的目标设备有不同的访问权限,例:
- 对10.0.2.34 有mysql 用户的权限
- 对192.168.3.22 有root用户的权限
- 对172.33.24.55 没任何权限
- 分组管理,即可以对设置进行分组,允许用户访问某组机器,但对组里的不同机器依然有不同的访问权限
设计表结构:
ssh公钥登录过程
使用密码登录,每次都必须输入密码,非常麻烦。好在SSH还提供了公钥登录,可以省去输入密码的步骤。
所谓"公钥登录",原理很简单,就是用户将自己的公钥储存在远程主机上。登录的时候,远程主机会向用户发送一段随机字符串,用户用自己的私钥加密后,再发回来。远程主机用事先储存的公钥进行解密,如果成功,就证明用户是可信的,直接允许登录shell,不再要求密码。
这种方法要求用户必须提供自己的公钥。如果没有现成的,可以直接用ssh-keygen生成一个:
$ ssh-keygen
运行上面的命令以后,系统会出现一系列提示,可以一路回车。其中有一个问题是,要不要对私钥设置口令(passphrase),如果担心私钥的安全,这里可以设置一个。
运行结束以后,在$HOME/.ssh/目录下,会新生成两个文件:id_rsa.pub和id_rsa。前者是你的公钥,后者是你的私钥。
这时再输入下面的命令,将公钥传送到远程主机host上面:
$ ssh-copy-id user@host
好了,从此你再登录,就不需要输入密码了。
完整示例代码
https://github.com/triaquae/py3_training/tree/master/%E5%A0%A1%E5%9E%92%E6%9C%BA
我是尾巴~
这次推荐一个画流程图的好地方:https://www.processon.com/在线免费制作
虽不才,才要坚持。