堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

栏目: 服务器 · 发布时间: 5年前

内容简介:2005年,中国,我在某互联网公司的安全部门,面临3个问题。

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

一、缘起:堡垒机从哪里来? ——无风不起浪,从需求中来

2005年,中国,我在某互联网公司的安全部门,面临3个问题。

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

1. 运维部门的需求:

那时候,数据中心的运维管理人员的技术水平还处于“社会主义初级阶段“,经常会出现一些低级的误操作,导致网站突然无法正常访问,解决问题基本靠在人堆里吼一声”谁TM干的”。痛苦在于,误操作而导致的运维事故极大的降低了网站的可用性,而可用性(俗称几个9)又是运维部门永恒不变的关键考核指标。运维部门深知,误操作问题的出现是无法杜绝的。那么,何时出现?看风险概率。而风险概率=运维部门人数 x 服务器规模 x 业务复杂度。由于不能保证没有误操作,所以只能在出现误操作事故后,快速定位问题,快速恢复网站可用,也算是“曲线救国”。运维部门由此产生了一个需求:有没有一种技术手段在出现误操作后,第一时间知道是谁做的,怎么做的?

2. 安全部门的需求:

我们发现,“坏人”在连续跳转登录多台服务器的过程中,会隐匿他最初的身份。那么,有没有一种技术手段能解决:不管“他”连续跳转多少次,身份如何变化,都能知道他就是最初的那个“他”呢”?

3. 风控部门的需求:

当时公司准备去美国纳斯达克上市,面临萨班斯(SOX)法案的合规要求,审计事务所普华永道有一份针对数据中心的问题检查列表,虽然我们都应答满足,但却缺少一种有效的技术手段去应对账号、密码、操作等方面的审计要求。

三个部门尚未被解决的3个问题,对我来说是个巨大挑战,因为还年轻,因为无知者无畏,又因为无理由自信,我踏上了求解之路。

当时存在三个层面5种技术解决办法:

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

I、系统层面:在服务器上解决,国外运维厂商的最爱

实现:每台服务器上安装Agent + 独立的Agent Server

优点:可以文本解析并且实现指令控制,国外大厂都有这样的产品

缺点:

λ 买不起:当时1个Agent要1万元人民币

λ 怕麻烦:不同操作系统需要不同Agent适配,几千台服务器N多个 Linux 操作系统,同时升级很困难

λ 搞不定:系统管理员坚决反对安装Agent,担心会影响系统稳定性

II、系统层面:在服务器的系统日志里实现,系统管理员的最爱

实现:过滤+收集日志里的信息

优点:实现简单

缺点:

λ 看不懂:日志根本就不是给普通人看的,是给系统开发人员看的

λ 看不到:如果一个用户连续三次跳转和改变身份,日志无法关联

λ 看不真:用户登录系统后很容易篡改系统日志

III、系统层面:服务器上解决,修改登录脚本,系统管理员的最爱

实现:修改登录过程中的profile 文件

优点:实现简单,系统管理员就可以搞定

缺点:

λ 修改过的脚本文件很容易被用户改回去

λ 升级维护脚本很麻烦

λ 没法关联分析用户在多台设备跳转的日志

IV、终端层面:在终端上解决,终端管理厂商的最爱

实现:在桌面PC/笔记本上安装Agent

优点:可以录屏

缺点:

λ 终端更多时候是为了日常办公,很难在终端上区分出哪些是运维操作

λ 操作数据没办法文本化,简单的录屏对查找问题来说价值不大

V、网络层面:在网络中解决,网络安全厂商的最爱

实现:在交换机上通过流量镜像实现流量捕获+协议解析

优点:可以文本提取不加密协议(telnet/ftp等)的输入输出内容

缺点:

λ 大流量的情况下流量捕获会丢包,丢包意味着无法完整解析

λ 加密传输是大趋势(比如SSH、Https),加密后的协议难解析

λ 协议会持续升级,不停去解析协议是一场永无止境的噩梦

每种技术解法都有边界和优缺点,上述5个技术方案都没能彻底解决问题,这让我陷入沉思:

问题牛X到了无解么? ——不可能

已知的技术解法太烂? ——有可能

等着我发明新解法么? ——可能是

虽说人类一思考,上帝就发笑,但依然阻止不了我的思考,我坚信一定有一种将时间、空间、技术三者匹配的最优解(此处省略痛苦摸索的过程约20000字),最终的技术解法如下:

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

二、性空:堡垒机到哪里去? ——从需求中来,到需求中去

独乐乐,不如众乐乐。能够为更多用户解决从未被解决过的问题,不是一件很开心的事么?我离职去创业了。

客户做安全项目的3个驱动力,按照重要程度依次排序:

来自行业标准合规性驱动——那时候,等级保护条例还未发布;

来自行业内安全事件驱动——那时候,也没出过轰动的大事件;

来自用户自身的需求驱动——没有选择,只剩下这个了!

在那个年代,只能找高端大气要求高的大客户,因为一般的客户根本就没有需求。

堡垒机的发展史完全就是高端客户的需求推动史,高端客户的特点就是有钱,爱思考,爱提需求,而且是源源不断地提:

客户说:我们不是只有Linux系统,还有各种Unix系统哦?

——我们开始兼容各种访问AIX/HP-UX/Solaris/SUSE/AS400的操作;

客户说:我们除了Unix/Linux系统,还有很多Windows系统哦?

——我们开始兼容各种访问Windows的图形操作;

客户说:我们有很多是通过浏览器进行的操作哦?

——我们开始兼容各种浏览器的操作审计;

客户说:我们有很多通过客户端 工具 进行的操作哦?

——我们开始兼容各种C/S的操作审计;

客户说:我们还有各种网络设备哦?

——我们开始兼容各种网络设备的操作审计……

兼容性的问题解决好以后,还没喘口气,客户说:你们不能只做审计啊,还要加强控制。

——我们开始着手实现权限控制:动态授权、登录复核、双人复核、操作黑白名单 ……

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

和谁在一起,真的很重要。我们就像海绵一样,从各个行业顶尖客户中吸取独特的思路,融入到产品中去:

全国性股份制银行客户让我们学会了如何提高风险管控;

头部互联网客户让我们学会了什么才是领先的技术;

世界五百强客户让我们学会了如何做好项目管理;

……

黑夜给了我黑色的眼睛,我却用它寻找光明;

客户给了我难搞的问题,我却用它寻找谜底。

高端客户打磨了我们高端的能力,和他们在一起,根本不缺高质量的需求和高标准的要求,一路相伴,如履薄冰。

三、无我:堡垒机是什么?——近朱者赤,始终和运维在一起

人类并不偏爱风险,运维也是如此,运维偏爱效率,但是风险始终如影随形,好比硬币的正反面,风险和效率需要一个完美的平衡,堡垒机就是平衡效率的风险工具。

安全永远是业务的一个属性,国家安全是国家业务的属性,网络安全是网络业务的属性,运维安全是运维业务的属性,而对运维这个业务的深刻理解决定了堡垒机是什么。

什么是运维?简洁的理解,运维 = 运行 + 维护:

λ 运行(发现问题):通过监控这种手段发现问题,实时监控数据中心各层(应用、中间件、数据库、操作系统、硬件、机房)的当前运行状态是不是正常稳定,核心诉求是快速定位问题,并且能够自动找到是什么原因引起的,俗称“根因分析”,这也是当下各种智能运维(AIOps)产品要解决的核心问题;

λ 维护(解决问题): 监控并不解决问题,解决问题是通过“操作”这个动作,把不正常的状态恢复到正常状态,在解决问题的过程中往往会带来新问题,运行没有风险,维护才有风险,运维人员的高权限导致各种误操作、违规操作风险都是在这里出现,这就是2005年,堡垒机开始的地方。

世上本没有运维安全,直到堡垒机的出现,它开启了运维安全这个全新领域。

曾有某客户这样评价堡垒机:他买过很多安全产品,但是,他认为堡垒机是这10年里,唯一可以媲美防火墙的产品,真正帮他们解决了实际问题。

此话听得我泪流满面,作为产品的设计者,还有什么比得到客户的肯定更让人感动的呢?

2005年,我的预言是:

一、未来,中国所有的数据中心里都会用到堡垒机;

二、但是,不一定都是用齐治的。

堡垒机哲学史 l 三个问题:堡垒机从哪里来?到哪里去?是什么?

今天这个预言已经实现,看到有这么多的厂商在不遗余力地用各种方法推广自家的堡垒机产品,作为堡垒机的发明者,我很欣慰。竞争让产品充满活力和想象力,如果这些竞争能从无序到有序,从低质到高质,那就更好了。

子在川上曰,逝者如斯夫。

这十多年,我从未关注过所谓的对手,是因为我们是这个领域的创造者和领跑者。追随者喜欢东张西望和左顾右盼,领跑者从不回头看看身后会有多少跟随者,而是坚定地把目光聚焦于前方。

如今,客户的声音依稀在耳边回响:

你们为什么只做堡垒机呢?

你们除了做堡垒机,还能做什么呢?

俱往矣,数风流人物,还看今朝。

聚焦下一个十年里,数据中心客户面临着更大的问题,寻找时代的技术最优解,是今天我们的挑战。创造出下一个通用性的解决方案,让更多客户使用,解决未被满足的需求,依然是齐治不变的追求!


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

微服务设计

微服务设计

[英] Sam Newman / 崔力强、张 骏 / 人民邮电出版社 / 2016-5 / 69.00元

本书全面介绍了微服务的建模、集成、测试、部署和监控,通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性,学会把服务集成到已有系统中,采用递增手段拆分单块大型应用,通过持续集成部署微服务,等等。一起来看看 《微服务设计》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

SHA 加密
SHA 加密

SHA 加密工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具