云舒:给小白的租户隔离科普文

2017-02-28 11:34:11 +08:00
 19zero
非常关注这次的经典内网安全事件
云舒刚刚发文回应了:
http://weibo.com/ttarticle/p/show?id=2309404080084758708032

原文如下:

给小白的租户隔离科普文

我现在搞一个小创业公司,没多少时间可以浪费。然而没有办法,很多事情我不出来说明,就会有错误在流传——而且是耗子等在程序员圈子里面有较大影响力的人。感觉也很有意思,许多技术人员跟街头巷尾的大爷大妈没啥区别,交头接耳议论纷纷。类似的事情,比如美国大选、收容难民等,微博上议论也颇多,让我思考了好一阵子,就在想这都是为啥啊(当然,我已经想明白了)?

且说正题。

先说结论:阿里云不同租户默认是隔离的,而且从 2009 年到现在一直如此。​

我 2009 年开始负责弹性计算安全,属于开拓领土,业务逐渐起来后,镇守一方。当时,在网络层面,我定下了数条基本法则。这些基本法则凌驾于所有的网络访问规则之上,用户不可见、不可修改、不可覆盖,是类似宪法存在的根本大法。其中第一条就是不同租户处于不同的安全组,默认互相隔离。第二条是每一个 VM 发出去的报文宣称的源 MAC 地址和源 IP 地址必须与控制平台分发给它的一致。还有几条我就不一一透露了,不然要泄露机密——这也是我的痛苦所在,写这篇文章是在刀尖上跳舞,要把事情说清楚但是又不能透露机密,我个人浅见,耗子写得东西偏多了。

我的安全哲学是在安全这个专业领域用户是 sb (这里的 sb 用户也包括资深的开发人员在内,区别在于小白知道自己不懂,资深的开发人员则以为自己懂),安全得由我这种专业人士保护。所以可以看见,我设置的策略是不人性化的,是死规矩是一刀切。在安全领域,用户的资产也得由我说了算。

这是我的道。

不知道大家看过魔兽电影没有?麦迪文设置一个魔法屏障,保护国王莱恩和洛萨撤退,但是洛萨的儿子没有及时进入屏障而被杀掉——我做的规则就是这样的。就算你们是一个公司同一个部门不同员工,只要你们买的云主机是用各自自己的账户买的,那么你们内网就不可互访,就算是一家人也不行,就算是亲儿子和亲爹的也不行。​

2014 年,我从镇守云安全任上调离,去搞安全实验室,到西域开疆辟土,做了 IOT 安全研究、黑客溯源以及风控安全产品——淘宝的无验证码就是我们当时做的。

2015 年,我当初给云计算定下的几条基本法则做了一些改动。按说,这个改动应该是考虑了用户的因素,更柔和,更得耗子等技术方面人员喜欢的——那就是不同安全组默认拒绝,但是允许用户增加白名单,允许一些安全的访问,麦迪文的那个屏障,可以临时允许洛萨的儿子进来。这是 linux 的理念,信任用户,让用户自己决定自己的东西。比如说 root 去 rm -rf /,系统照样执行。

现在问题是,有一些用户为了方便,设置了允许一切 IP 访问自己的安全组,也就是有些吃瓜群众纷纷表示自己懂安全了发现漏洞了的原因。

我做的法则,铁血专制,剥夺用户的权利,即使用户想自杀也自杀不了,绝对安全,但是用户被我关在了笼子里——这部分,我也经历过不少投诉。 2015 年之后的法则,默认安全,但是用户有自主权,如果要自杀真的能死掉。

随着时间的推移,云计算的成熟,我觉得现在的策略是合适的。默认安全,但是高级用户可以自己掌控自己,不是很美妙么?所有的好的系统,都应该是这样子的吧。如果想自己有完全的掌控权,但是又绝对安全,抱歉,做不到。

我相信到这里,事情应该明确了吧?那么接下来,我要开始批驳耗子了——你说你一个程序员,好好写程序,发发编码方面的鸡汤文多好,为什么为什么为什么要一次一次的凑到我面前来呢?嗯?

耗子第一篇文章,这一段话“一台个人机器还好设置,如果你是企业用户,你的机器多了,那么,安全组这种设置可能就会是一个恶梦。比如你有 100 台机器,新增的这一台你就需要让那 100 台都知道。或是,你这 100 台中有一台的 IP 变了,你需要让另外 99 台的安全组都知道。…………省略许多文字…………所以,在这样的经典网络下,对于你的机器的安全组的管理,完全是没法管的,因为是静态的,而还是非常复杂的,所以配置错误这种事么,基本上是高概率的。”这一段简直就是放屁。配置安全组,不需要你​去了解那么多细节,你只需要在 web 界面上把一个 vm 拉倒一个组里面去就好了,组增加、减少 vm ,所有相关组的策略会自动适配。即使你的 vm 发生迁移了,组策略也会自动跟随,部署到新的宿主机上面去。这是一个纯自动化的过程。

“一般来说, VPC 是通过 hack 底层的虚拟化系统完成的,也就是说,在 Hypervisor 层虚拟交换机中实现了一个类似路由器的东西——通过一个用户自定义的虚拟 IP 和实际 IP 的关系做 packet forwarding 或是 overlay 的机制等。 Anyway ,实现细节不重要。”这一段,你 tm 一个知名技术博主,写技术科普文章,你跟我说“ anyway 实现细节不重要”?就算不提细节,你跟我说“ VPC 是通过 hack 底层的虚拟化系统完成的”,逗我?不懂就去学啊。

我们首先看看为什么需要 VPC 。

首先云计算 VM 是讲究漂移的,有因为故障发生的漂移,也有因为用户主动发起的跨区域的漂移。漂移过程中要求保证业务尽量不中断,则需要保证 vm 的 ip 地址、 mac 地址不变,这就意味着需要一个巨大的二层网络,甚至是跨区域的。而二层网络越大,交换设备的 cam 表压力也越大,甚至爆掉, arp 之类的广播风暴也越严重,所以要把 vm 层面的一些东西对物理交换机屏蔽掉,分层处理。

其次, VPC 给用户一种很好的体验,延续传统网络时代自己组网自己规划的那种感觉,当然也可以更灵活的设计自己想要的东西,甚至形成 service chain 。

现在的 VPC 一般都是基于 VXLAN 实现的, VLAN 的 VLAN ID 字段只有 12 bit ,最多支持 4094 个 VLAN ,这对于海量租户而言肯定是不够的, VXLAN 则扩展成 24bit ,能够支持 1600 万个 VPC 区域,基本够用了。 VXLAN 是将原始报文封装成 UDP 包,可以很方便的跨域三层网络传输二层的内容,能够让用户组建跨地区的 VPC 。​并且, VXLAN 将内部 VM 的 MAC 地址等信息屏蔽掉了,由 VTEP 处理,让交换机专注物理机方面的事情,减轻压力。

VXLAN 数据流程图(不是我画的,谷歌搜索的) VXLAN 数据流程图(不是我画的,谷歌搜索的)

对我而言,最喜欢的是 VTEP 可以形成 service chain 。其实现在 VXLAN 和 SDN 已经不太能去分得开了,至少我不太能分得开,也许可以基于 openflow 协议来控制 VTEP 的行为吧。

在阿里期间,我一直对现有割裂的安全厂商和产品耿耿于怀,大约是 2011 年我在 owasp 讲过我的安全产品虚拟化思路​,将不同厂商的硬件盒子抽象成统一的 VM ,不同的功能就是不同的 image ,然后基于 SDN 或者 VXLAN 的能力,软件的方式定义网络结构,将平面的 vm 变成具有立体结构。这样,用户就可以绘制自己的网络拓扑图,在对应的地方,选择对应的产品,可能是安全,也可能是负载均衡,然后再选择供应商,点生成,整个网络就生成好了。这也许就是云计算安全最后的终局,但是不知道要多少年才能发展得到。

我本来想,国内就由我自己来完成这个壮举,可惜未能实现,我已离职。人生如梦啊。

不提这些,来说耗子的第二篇文章。

“ 2013 年,我在阿里商家业务部做聚石塔,聚石塔的底层是阿里云。当时,聚石塔的安全问题很严重,有很多商家和买家的业务数据外泄,所以,成立了一个专门负责安全的小组。阿里安全部门也专门派人来强力支持。

当时有一个很大的安全问题是——阿里云的内网多个租户居然是通的。”

​不知道耗子知道不知道,因为一些我不方便说的原因,聚石塔是由淘宝维护负责的电商云,其实是属于同一个租户的!同一个租户,当然是互通的啊。我不知道耗子是知道那个原因不说,因为知道我不可能说,还是真不知道——按说你当时也 P9 ,应该知道吧。不说这个,但是至少,聚石塔所有的 vm 是属于同一个租户的,你也不知道么?那你负责聚石塔是怎么负责的?也是“ anyway ,细节不重要”?​

更多的东西,我就不说了,所有这些,对我现在而言,都没有意义。如果不离职,我已经 P10 了,也许不久就要做到 P11 也就是所谓 VP 了。

但是那又如何?我现在是默安科技的联合创始人兼 CTO ,我他妈已经 P14 了啊。

​因为这么些鸟事情,浪费了朕一上午的时间。这几年我基本已经不跟人交流云计算安全方面的东西了,因为我不知道找谁跟我交流。懂云的不懂安全,懂安全的不懂云,都懂的嘛,除了我以及了了数人之外,也就是一些搞跨界的了。

大道难借他人之手,唯有自成,且吃个黄焖鸡压压惊。
11429 次点击
所在节点    云计算
59 条回复
panzhc
2017-02-28 18:09:41 +08:00
没用过聚石塔,但个人认为聚石塔不应该是一个租户,而是类似一个代理商,代理商可以创建多个安全组,安全组之间默认是隔离的,这样就和阿里云公有云一样了。至于后面用户设置了不合理的规则,虽然用户也有责任,但云平台面对的很多都不是专业人员,更不是安全专业的,建议云平台可以做好提醒和记录,降低用户的安全风险。
cobola
2017-02-28 18:47:15 +08:00
惊讶的发现 我也是 P14 啊!
huson
2017-02-28 18:51:32 +08:00
耗子:阿里云租户互通的
云舒:我们用安全组隔离 所以不通
carterdang
2017-02-28 19:16:33 +08:00
为了节约 IP 和 租户频繁变更带来的运维困难,在一个大内网没问题。租户间的二层隔离从网络层面就是 vlan 隔离,用到 vxlan 解决租户 vlan 的数量限制是公有云的方向
G900
2017-02-28 19:23:13 +08:00
问题是这种隔离策略,为什么身为 P9 的耗子都不知道,聚石塔作为阿里云这样大的一个租户,也没有被告知,公司抽调来的安全人员,也没人知道,这不是阿里云或者策略设计者的失职吗?
你设计的策略,用户都不知道,你就有脸出来喷用户了?
lance26
2017-02-28 20:54:16 +08:00
中二的气息扑面而来,“镇守一方”,“基本法则”...给我来瓶青岛纯生,吹到你怀疑人生:-)
hitsmaxft
2017-02-28 20:56:02 +08:00
安全是好的, 可是开发团队根本不喜欢“额外”花时间在这些束手束脚的东西上, 不到出事是不会重视的。说到底, 是管理问题。
工程团队不懂工程。
snnn
2017-02-28 21:00:39 +08:00
一句话:经典网络没做 overlay 呗。从来没见过哪个云计算提供商这么搞的。你不如说 CentOS 默认所有 incoming connection 都是 drop 的,所以只要用户不改,有天大的漏洞也不存在安全问题。
stevele
2017-02-28 21:42:34 +08:00
云舒的文章其实是为了专门驳斥耗子的,但是不能说明阿里云的 VPC 做的好。就我个人的观点来说,阿里就是一种家长式的做法,一种很强权的态度:安全问题因为用户不懂,所以由阿里云接管并设置规则,用户都是小白,不用成长,听我的就行。这种思路云舒非得说没错的话,我也没办法。
lynx
2017-02-28 22:19:39 +08:00
阿里云很多规则都很那啥,还总以为自己最牛逼,用户你就得听爸爸的话。服务质量又差。
最近几个月阿里云三天两头的说网络设备出现异常
ryd994
2017-02-28 22:29:43 +08:00
这逻辑………强盗逻辑
找这么说我也可以说公网很安全,有事的都是小白不会配防火墙而已。数据库限好了只允许相应的服务器访问不就好了?
说什么加机器拖进安全组的也是笑了。动态伸缩几百几千台都可以做到,你拖安全组么?
阿里的内网,安全性和公网有什么区别?
不论怎么洗,阿里云的经典网络和 AWS 的有本质上都是不同,而且 AWS 的套路有自己的优势,这是无法否认的。
mechgouki
2017-02-28 22:47:25 +08:00
为什么一定要说脏话?
hk24v2
2017-03-01 01:08:27 +08:00
网络和开发的矛盾
xifangczy
2017-03-01 02:49:51 +08:00
一半都是人身攻击看不下去。。。
timothyye
2017-03-01 08:28:15 +08:00
感觉他跟耗子讨论没在一个点上,口气和用词倒是挺狂
doubleflower
2017-03-01 10:06:11 +08:00
小白用户默认隔离就行,是不是内网有什么关系吗?

而且高级用户可以自由定制,这不是挺好的,喷点在哪?
suikatw
2017-03-01 14:39:21 +08:00
@ryd994 要看默认行为
公网默认是要你死的,你不保护好自己,你就要死
安全组按照云舒的说法,默认是保护你,你要先作死,才给让你死

加机器拖进安全组这个我理解也是正常的行为,只是拖进安全组这个动作并不一定是用户自己完成甚至令用户感知的,比如动态伸缩这个功能也是默认伸缩到原有安全组不就可以了嘛
ryd994
2017-03-02 02:33:29 +08:00
@suikatw 所谓安全组,本质上和早期网络一样,点对点拓扑设置规则
大多数服务器系统都是默认防火墙全挡的,可小白呢?第一句就 accept all 。阿里云也是一样,默认全挡有什么用?配置起来不方便的话小白用户一样全 accept 。这该怪小白不懂事么?别人打你你怎么不保护自己,这就叫强盗逻辑。
好的平台能指导用户正确使用,因为根本没有 maluse 的动机和条件。平台好不好不是看上限,是看下限。不然的话互联网也超安全的,运维水平够的话,什么网络不能用?无米之炊也能做出来啊。可复杂度呢?可靠性呢?可维护性呢?

你要认识到安全组这个东西本来就是阿里云早期没有中间层自己挖的坑,各种安全组各种策略都是后期补锅。像 AWS 那样布局好的,从根本上就不需要考虑这个问题。
ryd994
2017-03-02 02:35:43 +08:00
@suikatw 不能说现在他们都能满足用户需求,就说他们一样好。因为一个是从一开始的设计就实现,另一个是不停掉坑不停 duct tape 的产物。 duct tape 毕竟不是 pipeline

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/343762

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX