既然问到堡垒机,我仍是有必要回答一下的,这是由于堡垒机确实给个人运维工做履历带来了实际帮助,若是没有堡垒机我可能已经考虑转行了。我就从个人经历提及吧,说来话长,你们慢慢看。html
从事运维三年了,本身也曾遇到过各式各样的问题,诸如因认证方式过于简单形成服务器帐号被盗、权限划分不明形成的误删数据库文件等问题家常便饭,果不其然的印证了“70%的故障均来自内部人员的操做失误”的魔咒。数据库
很显然,问题出在平常运维工做不规范,若是不规范工做中的一举一动,就会不断的犯错,最后致使全部的功劳都变成徒劳。浏览器
俗话说的好:常在河边走, 哪能不湿鞋。身边例子不少,随便举一个朋友在群里的对话。安全
若一不当心执行命令 rm -rf / tmp,若是此时正好拥有root权限,那么后果将不堪设想。服务器
关于rm -rf / tmp 这种错误,对于手快的朋友或者在咱们网速比较慢时,出现的几率至关大,当你发现执行完以后,你的心至少是凉了半截。可能你们对本身拥有至关大的自信,老子每次都这样没出过错,唬谁呢。网络
当出现一次你就明白了,不要认为那些运维事故都是在别人身上,若是你不注意,下一个就是你。架构
众多运维工做的失误,时刻提醒咱们运维人员要创建明确、规范的标准化管理流程,以提升运维效率、下降综合成本,保障业务的连续性。运维
在这里跟你们分享几个关于rm防止误删除数据的小技巧:分布式
一、先备份,再操做,最好有异机备份,修改配置等先提交版本管理系统再发布到线上;性能
二、删除文件时使用mv命令替代rm命令,无用的文件先不删除,而是移动到/tmp里观察些许时间;
mv filename.txt /tmp/
三、若是非要使用rm删除,请尽可能先使用Tab补全目录,再切换目录再删目录下的数据,能不用通配符就不用通配符。
cd /tmp rm -f filename_1.txt filename_2.txt
四、若是删除的不是目录,就不要使用“rm -fr”,应采用最小化权限“rm -f”来进行对文件的删除。
至此以后,运维失误确实减小了,可是好景不长,时隔俩月问题又再次重演,而咱们还不知道是谁操做的(当时我立刻查看了系统日志,但苦于系统日志可读性差、零散、可删除、篡改、而且咱们帐号与运维人员没法一一对应)!!!
CTO完全爆发,此次必须从源头完全根除这个问题,不然你就给我滚蛋。此时的我,很是理解CTO的心情,因而当面立下军令状,杜绝此类事故的再次发生。
目前咱们的主机资源规模大概在数百台左右,上面跑着许多不一样的业务系统,对于这些资源来讲,都有各自独立的一套帐号体系,当时为了方便管理,咱们是经过一个Excel来维护这些帐号信息,使用时,也就存在了多人共用帐号的状况。
多人共用帐号给咱们带来方便的同时,帐号自己的安全性也就没法获得保证,致使操做者的身份没法肯定,当系统发生问题后,很难确认具体责任人。
为了保证密码的安全性,咱们也会制定严格的密码管理策略,诸如密码必须按期修改,密码需保证足够的强度等,但现实执行中,因为管理的资源规模太大和帐号数量太多,这一费时费力的操做,每每最终都流于形式,由此引出咱们的第一个问题:帐号密码管理体系不规范。
在访问控制这块,咱们对运维人员数据信息的访问能力和范围并无作严格的控制与限制,致使运维操做流程就像一个“黑盒”,咱们并不清楚运维人员:
由此,带来的后果除了本次失误操做致使关键应用服务异常、宕机以外,存在违规操做致使敏感信息泄露、丢失的状况也曾发生过。
那么咱们要解决的第二个问题:访问控制不严格。
该如何解决?维持现有的运维流程确定是不行,经过制度来约束运维人员实现安全合规的操做未免显得有些力不从心。
那么只能依靠经过其余手段来避免上述问题的发生,对于从事运维的朋友大概都清楚只要用堡垒机就能解决咱们如今全部面临的问题,由于堡垒机的做用就是让远程运维操做管理可以实现按用户/资源进行受权管理,除此以外经过事前访问控制、事中录像监控、过后指令审计,以保证企业数据的安全以及运维操做的安全合规。
咱们也调研了目前主流的堡垒机解决方案,这里我主要根据本身的经验,从几个要点进行分析和比较,分享给你们参考,至于如何选择,你们可根据自身的业务环境进行适配。
一开始咱们是想经过内部自研的方式进行堡垒机的开发,对于堡垒机来讲,它是由多种技术协调整合造成的。简单来讲至关于运维人员的一台代理服务器(Proxy Server),若是从主干技术原理的角度概述的话,堡垒机所应用的主要技术包括但不限于:逻辑命令自动识别技术、分布式架构处理技术、图形协议代理技术、多进程/线程与同步技术、数据加密技术等。能够说,堡垒机技术是一个看似简单,其实复杂而精细的分布式系统集群。
考虑到内部研发堡垒机在性能和稳定性上必定会有所欠缺,出问题后,运维人员不能登陆,影响不少团队干活,尤为在处理业务故障的时候,若是忽然发现某台服务器进不去,这就尴尬了,严重影响周围团队对咱们运维团队的满意度。
运维自己是个服务性质的工做,尽可能不要搞得周围部门不满意才好。
考虑再三决定调研测试开源堡垒机,目前的开源堡垒机方案有不少,目前作的较好的诸若有CrazyEye、Teleport、Jumpserver、GateOne、麒麟开源堡垒机等。
当咱们公司选择了使用开源堡垒机时,便拥有初始投入少、使用灵活等特色。不过在后来咱们的管理成本、学习曲线和安全性方面却很可贵到,可能咱们一开始未曾考虑开源堡垒机也需专人进行维护,并且大多开源堡垒机的功能相对简单,只可以知足咱们最最基本的安全需求。若是想更进一步的发挥堡垒机真正的价值或者说是有用的堡垒机,那么根据公司业务进而定制开发就是必经之路。
而对开源堡垒机的定制开发,又让咱们回到了内部自研的老路,开发堡垒机这我的必须很是熟悉Linux以及公司业务,并且还要会玩Python(大多与运维相关的应用使用Python开发的较多,具有这样能力的人薪资每每不低),除此以外也能够选择开源堡垒机的商业支持服务,不过需支付高昂的技术支持服务费用,这自己就是一个运维成本。从这个角度讲,开源堡垒机并不等同于免费堡垒机,后期成本可能远远高于商用堡垒机,对开源堡垒机厂商尚未任何责任约束。
行吧,是时候调研商业堡垒机了,咱们经过调研得知商业堡垒机目前可细分为:传统堡垒机和云堡垒机。
以传统堡垒机厂商为表明的供应商诸如:齐治、绿盟、碉堡、安畅等。 以云堡垒机厂商为表明的供应商诸如:行云管家、云安宝等。
对于传统堡垒机多为软硬件结合且价格昂贵,其管控能力十分强大,是银行、国营大型企业IT运维团队的首要选项。
但传统堡垒机的缺点是,价格很高动辄数十上百万(容易出现单点故障,因此一次要买俩进行高可用),因此部署起来相对来讲比较困难,须要专业的团队统筹部署,维护成本高。同时对现有网络结构侵入大,软件和硬件升级都不方便,并不怎么适合中小型企业、通常创业企业。
对于云堡垒机的调研来讲,了解到云堡垒机在功能上已很是成熟,同时借助了云计算的优点,使得云堡垒机在资源的交互性、易用性、性价比、维护成本、产品自身安全性等方面又获得了进一步提高,尤为解决了传统堡垒机的单点故障问题。
除此以外,云堡垒机还有许多特性,诸如免安装、免维护、开箱即用,支持Windows\Linux等主机运维审计、指令检索、监控预警、自动化运维等。
这里你们须要注意的是,堡垒机对于自动化运维的影响甚大,由于咱们使用了堡垒机实现了云环境下的统一运维管理,成为全部运维的惟一入口。那么堡垒机既会成为自动化运维的羁绊,那么可就得不偿失了,因此咱们选择使用堡垒机时,也需对配套功能进行考虑(是否具有其它运维相关功能,好比主机监控、远程协同、自动化运维等);
从身边已在使用堡垒机的朋友得知,他们的采购同事购买传统堡垒机的流程通常为:
一、须要乙方销售人员屡次上门介绍产品; 二、签定合约; 三、须要运输、安装、调试、配置……
整个流程通常长达数月。
但在云上,云堡垒机的交付则更为简单,对于云堡垒机厂商,云安宝提供了私有部署版本,而行云管家不只提供了私有部署版本,同时还拥有SaaS平台,SaaS的优点在于咱们无需在硬件和IT人员方面再进行任何额外的投资,便可得到堡垒机服务,这种区别就如同拎包租住一间精装房和聘请施工队 为本身修建一套住房的区别。废话少说,接下来就是对两家产品进行细粒度的测试。
云匣子:云匣子总的来讲与开源的JumpServer相差很少。
行云管家堡垒机在线体验-https://www.cloudbility.com/cj/baolei.html:前面提到,行云管家拥有SaaS平台,只须要经过浏览器便可体验,咱们经过Google搜索行云管家堡垒机,获得了在线体验的环境,经过注册、建立团队、导入资源三个步骤,咱们即可以经过行云管家来管理主机资源。
经过一番体验以后,无论是在UI、产品功能、产品体验方面都很满意,在咱们长时间的测试过程当中,工做人员始终保持与咱们进行良好沟通和解决产品问题,最终他们用坚持不懈赢得咱们领导的承认也促成订单落地。
从上线到目前一个季度,我对CTO的承诺也得以兑现,未雨绸缪永远比出了问题在处理要好的多,出了问题补救是不得已的事,但仍是有许多公司,没有亡羊补牢,而是好了伤疤忘了疼,没过多久问题又重演。
所以,在工做中要尽可能作到未雨绸缪,从源头上减小故障的发生。其次,要作到亡羊补牢、触类旁通,事情出现一次就不能再出现第二次。固然,完善的备份和恢复策略也是须要作的。只有把这些结合起来,才能把咱们运维的工做作的更好。
最后总结一下,对于选购堡垒机并不是越贵的就越好,而是要综合考量各项指标与运维团队自己的契合度,以及在实际应用中的真实需求。若是咱们所在的团队是金融、政府等对安全性要求极高的组织,建议考虑传统堡垒机。可是对于一些互联网企业、创业企业而言,我比较倾向于向你们推荐使用云堡垒机,不管是从价格仍是灵活性来讲他都具有优点。何况随着云计算市场的发展,上云成为主流,将来的堡垒机发展趋势也必然是偏向于云堡垒机。