阻击黑客,你需要了解这些云安全"潜规则"

站长资源 2021-07-09 14:49www.dzhlxh.cnseo优化

7 月 22 日,就在云服务厂商青云第一届用户大会进行的同时,青云的云服务出现了中断。恰好国内的一些科技网站使用的都是青云,网站无法点击,也使得这次云故障被快速传播。

业界的第一反应是:这可能是一起蓄谋的 DDoS攻击,为的就是让青云在开用户大会的同时应接不暇。

媒体Bianews 第一时间爆出了青云故障的报道,随即有人拿着这篇报道质问阿里云的公关,因为当天也恰逢阿里云 6 周年大会。

后来的事实证明,青云的这次事故其实源自于其内部硬件故障,与友商并无关系。

突如其来的云服务中断,使得青云大会上宣布的技术创新、合作伙伴演讲甚至降价策略变得十分尴尬,因为云服务的稳定性比这一切都远远重要。

合作伙伴融云的首席架构师不得不赶到青云现场办公,解决用户问题。而据了解 OneAPM、快忘牛盾、绿盟、运智慧、听云等 10 多家企业级服务公司都在青云上,这些企业级服务公司间接会影响到更多的公司。

云安全的标准应该是机房被轰炸也应该毫无感觉。

「云服务要做就要做高容错,别说一台设备坏了,一个机房被轰成渣也要让客户毫无感觉才对。」一位用户在青云的微博下如此评价。

但在青云的事故中,直到第二天 7 月 23 日下午,青云对外发出第一条危机公关微博,说明是其所采用的H3C(华三)服务器出现故障。

青云官方微博错过了对外的最佳危机公关时间,迟到的说明反而加重了业界对故障的各种猜测。

首先,青云出现故障确实不仅仅是青云软件层面的问题。青云对故障的解释为:

「本次网络中断是完全因罕见的硬件故障导致,故障发生在汇聚层,我们将两台 H3C S5820V2 交换机为 IRF2 堆叠使用,在一台设备故障后,S5820V2 的 IRF2 分裂检测机制并未触发,导致设备堆叠的冗余能力失效。我们在故障发生后立即将汇聚层的两台交换机进行了切换,彻底杜绝了此类的事情的发生。」

青云内部人士对极客公园记者解释:“我们确实做了100%的冗余措施,但是因为H3C的硬件出现了软件故障,导致堆叠失效。并且是经过业界人士的鉴定。”

事故最后并没有确定的说法到底是否是H3C的硬件出现了软件层面的故障,但在H3C官微在青云更换交换机的微博下留言,承认这起事故确实是H3C的原因。

H3C及其低调地承认青云的故障是是因为自己的设备问题导致。

尽管青云向外界解释了这起事故并不全是自身的原因,但依然没有得到原谅。最主要的原因是因为:青云是直接面对客户的服务商,一旦云服务中断,客户的第一投诉人是青云,而不是其背后的硬件提供商。

其次,H3C和思科的硬件设备是云行业普遍采用的设备,出现这样的问题是首次,青云的运气实在差,赶上了低概率硬件问题。但甲方把乙方的交换机故障公布出来是业界首次,在云服务出现故障时揭露是合作伙伴原因导致,在某种程度被业界理解为是一种推卸责任。

而且,青云并没有做好即时的危机公关,22 号出现问题的当天,并没有在微博第一时间公布处理的情况,而是到 23 号才发出第一条解释的微博。而且遗憾的是,在关键解释硬件型号的地方—— S5820 被错写成 S5280。

最后,在技术上的处理,青云的措施依然是比较残暴而毫无解释的——“直接关闭北京 2 区的访问”,这再一次导致了很多用户的网站无法打开。用户的质疑是:“为什么不能选择用户晚上流量最少的时刻进行更换。”

用户对此次安全事故的最终评价是:“在正常危机过程中,青云处理故障的能力、方法,还有公关的介入和能力都不得人意。”

云安全三大隐患

「失望」、「准备迁移」、「赔钱」,这是用户在云服务中断后的普遍反应。每一家云厂商都可能面临像青云一样类似的技术隐患。提早发生安全事故对云厂商自身是一个非常好的提醒,对今后用户占据大量市场后是有利的。梳理近 1 年以来发生的云安全事故,我们发现:

去年 11 月,今年 3 月微软 Azure 出现过云故障。

苹果在3月和7月都出现过问题,3 月的瘫痪更是超过 11 个小时,App Store、Apple Music、Apple Radio、Apple TV 等,甚至是 OS X 软件更新都受到了影响。

黑色 5 月里,网易、支付宝、携程都连续出现问题。其中支付宝出现的问题和今年 7 月纽交所技术故障导致的交易暂停都是设计金融领域比较严重的事故。

支付宝解释自己故障的原因是运营商的光纤被挖断导致。

6 月阿里云香港机房瘫痪 12 个小时。

今年 3 月腾讯云也曾出现用户无法访问,回应是上海机房出现问题。

每一个事故都有自己独特的原因,那么如何系统地看待云事故,我请教了百度云安全部技术主席王宇。

王宇认为,涉及之前出现的云事故大体可以分为三类:

「首先是硬件故障。云环境下硬件故障是十分常见的情况,在设计支撑云服务的底层基础设施之初就应该充分考虑。如何避免单点,如何实现热备及自动故障恢复甚至「带伤运转」是每个云服务商在事前就必须考虑的问题,传统意义上简单的灾备并不能满足云服务的高可靠要求。

除了青云的此次事故,5 月网易出现的部分服务无法访问,业界也有观点认为是其网络设备板卡出现问题,这都属于硬件方面的准备和考虑不足所致。」

「其次人为误操作。对于云环境下的业务来说,单次误操作的影响力无疑被很大程度的放大了。虽然每个云服务商都应该有 SOP(Standard Operation Procedure,即标准作业程序,就是将某一事件的标准操作步骤和要求以统一的格式描述出来,用来指导和规范日常的工作)和 BCP(业务持续性计划、Business Continuity Plan),但在实际的制定和执行过程中经常会出现考虑不周或者执行不到位的情况。云服务提供商需要通过对外不断的学习评估业内之前出现过的案例,以及其处理方式的妥善与否来改进完善自己的 SOP 和 BCP,对内结合自己的业务场景不断进行演练改进,提升其执行力度和熟练程度。

简单来看,出现问题后的恢复时间长短其实成为衡量一个厂商服务能力的一个重要指标,之前国外云厂商能在完全中断服务的情况下,2 个小时内恢复云,属于相对成功的案例。」

「第三点不得不提到由于被攻击或人为恶意操作导致的问题。

Copyright © 2016-2025 www.dzhlxh.cn 金源码 版权所有 Power by

网站模板下载|网络推广|微博营销|seo优化|视频营销|网络营销|微信营销|网站建设|织梦模板|小程序模板