堡垒机的功能要求？？？？2

发布网友 发布时间：2023-09-11 03:14

我来回答

共2个回答

热心网友 时间：2024-11-13 21:21

热心网友 时间：2024-11-13 21:22

既然问到堡垒机，我还是有必要回答一下的，这是因为堡垒机确实给我的运维工作履历带来了实际帮助，如果没有堡垒机我可能已经考虑转行了。我就从我的经历说起吧，说来话长，大家慢慢看。

从事运维三年了，自己也曾遇到过各式各样的问题，诸如因认证方式过于简单造成服务器账号被盗、权限划分不明造成的误删数据库文件等问题屡见不鲜，果不其然的印证了“70%的故障均来自内部人员的操作失误”的魔咒。

很显然，问题出在日常运维工作不规范，如果不规范工作中的一举一动，就会不断的犯错，最后导致所有的功劳都变成徒劳。

俗话说的好：常在河边走， 哪能不湿鞋。身边例子很多，随便举一个朋友在群里的对话。

若一不小心执行命令 rm -rf / tmp，如果此时正好拥有root权限，那么后果将不堪设想。

关于rm -rf / tmp 这种错误，对于手快的朋友或者在我们网速比较慢时，出现的概率相当大，当你发现执行完之后，你的心至少是凉了半截。可能大家对自己拥有相当大的自信，老子每次都这样没出过错，唬谁呢。

当出现一次你就明白了，不要认为那些运维事故都是在别人身上，如果你不注意，下一个就是你。

众多运维工作的失误，时刻提醒我们运维人员要建立明确、规范的标准化管理流程，以提高运维效率、降低综合成本，保障业务的连续性。

在这里跟大家分享几个关于rm防止误删除数据的小技巧：

1、先备份，再操作，最好有异机备份，修改配置等先提交版本管理系统再发布到线上；

2、删除文件时使用mv命令替代rm命令，无用的文件先不删除，而是移动到/tmp里观察些许时间；

mv filename.txt /tmp/

3、如果非要使用rm删除，请尽量先使用Tab补全目录，再切换目录再删目录下的数据，能不用通配符就不用通配符。

cd /tmp
rm -f filename_1.txt filename_2.txt

4、如果删除的不是目录，就不要使用“rm -fr”，应采用最小化权限“rm -f”来进行对文件的删除。

至此之后，运维失误确实减少了，但是好景不长，时隔俩月问题又再次重演，而我们还不知道是谁操作的（当时我马上查看了系统日志，但苦于系统日志可读性差、零散、可删除、篡改、并且我们账号与运维人员无法一一对应）！！！

CTO彻底爆发，这次必须从源头彻底根除这个问题，否则你就给我滚蛋。此时的我，非常理解CTO的心情，于是当面立下军令状，杜绝此类事故的再次发生。

目前我们的主机资源规模大概在数百台左右，上面跑着许多不同的业务系统，对于这些资源来说，都有各自独立的一套账号体系，当时为了方便管理，我们是通过一个Excel来维护这些账号信息，使用时，也就存在了多人共用账号的情况。

多人共用账号给我们带来方便的同时，账号本身的安全性也就无法得到保证，导致操作者的身份无法确定，当系统发生问题后，很难确认具体责任人。

为了保证密码的安全性，我们也会制定严格的密码管理策略，诸如密码必须定期修改，密码需保证足够的强度等，但现实执行中，由于管理的资源规模太大和账号数量太多，这一费时费力的操作，往往最终都流于形式，由此引出我们的第一个问题：账号密码管理体系不规范。

在访问控制这块，我们对运维人员数据信息的访问能力和范围并没有做严格的控制与*，导致运维操作流程就像一个“黑盒”，我们并不清楚运维人员：

在哪台设备上执行操作？

操作是哪一位来执行？

正在进行哪些操作？

执行的操作是否合规？

由此，带来的后果除了本次失误操作导致关键应用服务异常、宕机之外，存在违规操作导致敏感信息泄露、丢失的情况也曾发生过。

那么我们要解决的第二个问题：访问控制不严格。

该如何解决？维持现有的运维流程肯定是不行，通过制度来约束运维人员实现安全合规的操作未免显得有些力不从心。

那么只能依靠通过其他手段来避免上述问题的发生，对于从事运维的朋友大概都清楚只要用堡垒机就能解决我们现在所有面临的问题，因为堡垒机的作用就是让远程运维操作管理能够实现按用户/资源进行授权管理，除此之外通过事前访问控制、事中录像监控、事后指令审计，以保证企业数据的安全以及运维操作的安全合规。

我们也调研了目前主流的堡垒机解决方案，这里我主要根据自己的经验，从几个要点进行分析和比较，分享给大家参考，至于如何选择，大家可根据自身的业务环境进行适配。

主流堡垒机解决方案

内部自研

开源堡垒机

商业堡垒机

一开始我们是想通过内部自研的方式进行堡垒机的开发，对于堡垒机来说，它是由多种技术协调整合形成的。简单来说相当于运维人员的一台代理服务器（Proxy Server），如果从主干技术原理的角度概述的话，堡垒机所应用的主要技术包括但不限于：逻辑命令自动识别技术、分布式架构处理技术、图形协议代理技术、多进程/线程与同步技术、数据加密技术等。可以说，堡垒机技术是一个看似简单，其实复杂而精细的分布式系统集群。

考虑到内部研发堡垒机在性能和稳定性上一定会有所欠缺，出问题后，运维人员不能登录，影响很多团队干活，尤其在处理业务故障的时候，如果突然发现某台服务器进不去，这就尴尬了，严重影响周围团队对我们运维团队的满意度。

运维本身是个服务性质的工作，尽量不要搞得周围部门不满意才好。

考虑再三决定调研测试开源堡垒机，目前的开源堡垒机方案有很多，目前做的较好的诸如有CrazyEye、Teleport、Jumpserver、GateOne、麒麟开源堡垒机等。

当我们公司选择了使用开源堡垒机时，便拥有初始投入少、使用灵活等特点。不过在后来我们的管理成本、学习曲线和安全性方面却很难得到，可能我们一开始不曾考虑开源堡垒机也需专人进行维护，而且大多开源堡垒机的功能相对简单，只能够满足我们最最基本的安全需求。如果想更进一步的发挥堡垒机真正的价值或者说是有用的堡垒机，那么根据公司业务进而定制开发就是必经之路。

而对开源堡垒机的定制开发，又让我们回到了内部自研的老路，开发堡垒机这个人必须非常熟悉Linux以及公司业务，而且还要会玩Python（大多与运维相关的应用使用Python开发的较多，具备这样能力的人薪资往往不低），除此之外也可以选择开源堡垒机的商业支持服务，不过需支付高昂的技术支持服务费用，这本身就是一个运维成本。从这个角度讲，开源堡垒机并不等同于免费堡垒机，后期成本可能远远高于商用堡垒机，对开源堡垒机厂商还没有任何责任约束。

行吧，是时候调研商业堡垒机了，我们通过调研得知商业堡垒机目前可细分为：传统堡垒机和云堡垒机。

以传统堡垒机厂商为代表的供应商诸如：齐治、绿盟、碉堡、安畅等。

以云堡垒机厂商为代表的供应商诸如：行云管家、云安宝等。


对于传统堡垒机多为软硬件结合且价格昂贵，其管控能力十分强大，是银行、国营大型企业IT运维团队的首要选项。

但传统堡垒机的缺点是，价格很高动辄数十上百万（容易出现单点故障，所以一次要买俩进行高可用），所以部署起来相对来说比较困难，需要专业的团队统筹部署，维护成本高。同时对现有网络结构侵入大，软件和硬件升级都不方便，并不怎么适合中小型企业、一般创业企业。

对于云堡垒机的调研来说，了解到云堡垒机在功能上已非常成熟，同时借助了云计算的优势，使得云堡垒机在资源的交互性、易用性、性价比、维护成本、产品自身安全性等方面又得到了进一步提升，尤其解决了传统堡垒机的单点故障问题。

除此之外，云堡垒机还有许多特性，诸如免安装、免维护、开箱即用，支持Windows\Linux等主机运维审计、指令检索、监控预警、自动化运维等。

这里大家需要注意的是，堡垒机对于自动化运维的影响甚大，因为我们使用了堡垒机实现了云环境下的统一运维管理，成为所有运维的唯一入口。那么堡垒机既会成为自动化运维的羁绊，那么可就得不偿失了，所以我们选择使用堡垒机时，也需对配套功能进行考虑（是否具备其它运维相关功能，比如主机监控、远程协同、自动化运维等）；

从身边已在使用堡垒机的朋友得知，他们的采购同事购买传统堡垒机的流程一般为：

1、需要乙方销售人员多次上门介绍产品；

2、签订合约；

3、需要运输、安装、调试、配置……


整个流程一般长达数月。

但在云上，云堡垒机的交付则更为简单，对于云堡垒机厂商，云安宝提供了私有部署版本，而行云管家不仅提供了私有部署版本，同时还拥有SaaS平台，SaaS的优势在于我们无需在硬件和IT人员方面再进行任何额外的投资，即可获得堡垒机服务，这种区别就如同拎包租住一间精装房和聘请施工队 为自己修建一套住房的区别。废话少说，接下来就是对两家产品进行细粒度的测试。

云匣子：云匣子总的来说与开源的JumpServer相差不多。

行云管家堡垒机在线体验：前面提到，行云管家拥有SaaS平台，只需要通过浏览器即可体验，我们通过Google搜索行云管家堡垒机，得到了在线体验的环境，通过注册、创建团队、导入资源三个步骤，我们便可以通过行云管家来管理主机资源。

通过一番体验之后，不管是在UI、产品功能、产品体验方面都很满意，在我们长时间的测试过程中，工作人员始终保持与我们进行良好沟通和解决产品问题，最终他们用坚持不懈赢得我们领导的认可也促成订单落地。

从上线到目前一个季度，我对CTO的承诺也得以兑现，未雨绸缪永远比出了问题在处理要好的多，出了问题补救是不得已的事，但还是有许多公司，没有亡羊补牢，而是好了伤疤忘了疼，没过多久问题又重演。

因此，在工作中要尽量做到未雨绸缪，从源头上减少故障的发生。其次，要做到亡羊补牢、举一反三，事情出现一次就不能再出现第二次。当然，完善的备份和恢复策略也是需要做的。只有把这些结合起来，才能把我们运维的工作做的更好。

最后总结一下，对于选购堡垒机并非越贵的就越好，而是要综合考量各项指标与运维团队本身的契合度，以及在实际应用中的真实需求。如果我们所在的团队是金融、*等对安全性要求极高的组织，建议考虑传统堡垒机。但是对于一些互联网企业、创业企业而言，我比较倾向于向大家推荐使用云堡垒机，无论是从价格还是灵活性来说他都具备优势。况且随着云计算市场的发展，上云成为主流，未来的堡垒机发展趋势也必然是偏向于云堡垒机。