神刀安全网

读云:云安全责任共担模式解读

自从大雄供职阿尔法星球某云计算厂商安全岗位后,入驻他公司公共云的朋友越来越多,但是随之而来大雄的困扰也在增加。

一些朋友经常因为自身业务安全问题遭到攻击而埋怨大雄,而大伙的腔调基本保持一致:我的业务放在你们云上,上了云我们自己没法部署安全设备,出了安全问题自然是你们厂商的责任。

就这样,大雄每次都要耐心地跟朋友们解释,公共云安全由大雄公司和朋友公司共同保障,云计算厂商负责云平台本身的安全,而云内部应用系统本身安全,云计算厂商没有权限鞭长莫及,需要朋友公司自己负责。

就这样,远在地球的无牙师傅听到大雄的抱怨后,给大雄寄了一个包裹。

一.大雄的时间胶囊

早上快递小哥送来一个包裹,大雄拆开后发现是一个精致的铁皮盒,盒子里放着一枚胶囊。胶囊上贴着标签,上写时间:2010年8月5日,坐标:南美洲智利科皮亚波市圣何塞矿场。

没忍住好奇心拧开了胶囊,轰的一声,大雄经历一阵眩晕后,醒来发现周围满是哭泣和奔跑的人群,不远处黑森森的矿洞像怪兽一样正往外喷着沙尘。没错,大雄不小心打开了一枚可亲身经历智利圣何塞矿难的时间胶囊。

读云:云安全责任共担模式解读

当智利矿业部长找到矿场主实施救援时,矿场主说他一生经历过五次矿难,但救出的人一个都没有。全世界每年大概有1万多名矿工死于矿难,但被找到的可能性不到1%,而存活人数更是微乎其微,地下622米深处,33条生命生死未卜,即使如此智利政府还是决定实施营救。

奇迹总是出现在绝望之后,第17天,被困矿工通过探测仪器向地面传递了一张纸条:33人全都活着!第69天,33位被困矿工全部救出。

目送最后一位矿工登上救生舱,大雄在622米深处的避难所中环顾四周,岩壁上写满了矿工的遗言,与地面连线的DV里播放着矿工与家属们欣喜对话,巨大的反差让大雄情绪激动,一阵彷佛,他醒来发现自己已在家中,手里多了一张残缺的小纸条,上面写着“Shared Responsibility”。

读云:云安全责任共担模式解读

责任共担,简简单单四个字,但是却是圣何塞矿难救援奇迹的全部总结。

一方面是智利政府充分承担起公民生命保障角色的责任。

规定矿场必须设置紧急避难所,并储备大量的救生物质以备不时之需,这是制度保障的先决条件。而灾难发生后又不遗余力地组织全世界各方力量进行人性化施救,利用高科技手段攻破救援攻关,在最短的时间里营救所有人员。

云计算厂商就如同智利政府一样,充分承担起云平台本身的安全保障责任,全力维护云上客户的安全。

另一方面是被困矿工自发承担起井下自救的责任,在生死关头33人并没有发生内讧,团结互助,有序地分配有限的食物和水,并且一直抱有被营救的希望和信心。

而云上客户则如同自救的被困矿工,不把安全保障完全寄希望于云计算厂商,放任自身安全工作不管不顾。一方面依托于云计算厂商的安全基础,另一方面自己使用云产品安全功能,SaaS服务和各安全厂商的虚拟化安全产品等等,通过这些手段来加强自身业务安全保障建设。

大雄在接到无牙师傅的电话后,才明白师傅的良苦用心,心里想着下次再碰到这些朋友就可以用时间胶囊对付他们了。

二、打更人的故事

责任共担这个模式自古有之,打更除了给居民进行北京时间报时的功能之外,还兼顾了发布警报、驱逐贼盗和警示村民等服务。

深夜时分,老胖头员外从邻村撸串回来,发现村东头王寡妇家的厢房窗户开着,借着酒胆凑近窗户想占点便宜,正好被村里头打更人老张撞见,老张梆子一敲,扯着嗓子吆喝:亥时二更,关门关窗,防偷防盗。

读云:云安全责任共担模式解读

昏昏入睡的王寡妇被梆子吵醒,不经意往窗外一瞥,发现一猥琐老头正色迷迷地盯着自己,吓出一身冷汗,翻身下床顺便抄起夜壶就往窗外砸去,老胖头员外慌不择路,连滚带爬消失在夜幕里。

时过境迁,打更人这个职业慢慢消失,小区保安则开始担负起公共安全的职责,安排专人进行三班巡逻,而各家各户则负责自己家的防火防盗。

老李中午躺在客厅沙发上打呼噜睡觉忘记关门,被送外卖的小哥把玄关上的钱包和手机给顺走了,老李一脸懊恼,保安巡逻时已经提醒过好几次,但是老李这臭毛病一直没改,再把责任赖给保安也不好意思,只好打110报警,并联系保安调取监控视频。

小区公共治安维护依靠保安和片警,而各家各户防火防盗业主自己也要承担起相应的责任,这也是典型的责任共担模式。

正如保安和片警不会知道业主小刘家钥匙被朋友复制,从而发生大白天的被盗事件一样。云计算厂商也不会知道客户在中马终端上登陆业务系统,结果被黑客窃取了管理员用户和口令,这也是云安全责任共担的缘由之一。

三、历史的必然

云安全是一个复杂的体系,这个体系覆盖云计算基础设施、操作系统、应用和数据多个维度,而云安全责任共担这个模式在业界也已经达成了共识。

中央网信办在出台的《关于加强党政部门云计算服务网络安全管理的意见》明确,党政部门在采购使用云计算服务过程中应遵守的4项大的原则规定:安全管理责任不变,数据归属关系不变,安全管理标准不变,敏感信息不出境。

从上面这段引文可以看出,安全管理责任不会因为计算环境变化而发生转移,之前在传统计算环境用户需要面对的安全威胁,在云计算环境同样存在。

因此无论是IaaS、PaaS、还是SaaS模式,安全责任总是分为两部分,一部分由云计算提供商承担,另一部分则由云上客户来承担,像亚马逊AWS、微软Azure、阿里云均采用这类模式。

有人会问,为什么公共云会出现责任共担模式?把所有的安全保障都交给CSP不是更好么?笔者本人也认同,把安全依托给CSP专业的安全团队来运营无疑是最理想的方法,这样可以避免云上客户安全能力参差不齐的被动局面。

但由于云服务模式的局限性,对CSP而言,操作系统、应用和数据在预设场景下是无法管控的,因此CSP在XaaS模式下注定是无法接管所有的安全职责的,所以云上客户需要与SaaS服务商和安全厂商虚拟化产品协同作战。

最终,安全责任共担就成了公共云安全最合适的解决之道。

对IaaS服务来说,CSP需保障物理、网络和虚拟化层面的安全,而用户需要保障操作系统、应用程序和数据的安全;

对PaaS服务来说,操作系统安全也归CSP负责,用户只需要负责应用程序和数据安全;

对SaaS服务来说, 用户要负责的就是数据安全,而其他所有的部分都是CSP的保障范围。

安全责任共担模式对于公共云而言,是它赖以生存的基石,同时也是抵抗黑客攻击的最有效策略。攻击者从不考虑安全漏洞的归属,但防御方却需要有这个能力识别和处置。

读云:云安全责任共担模式解读

对于CSP而言,数以万计的云上客户安全保障需求变化,驱使着其安全团队将底层安全能力进行持续提升,像AWS、阿里云云盾团队就正朝着这个方向努力。那云上客户自身参差不齐的安全能力现状怎么解决,这恰恰是公共云安全生态建设要解决的核心问题,一朵鲜花盛开不代表冬天已走远,只有百花齐放才预示着春天的到来。

归根结底,安全是我们的,也是你们的。

* 作者:s3curity,本文属FreeBuf原创奖励计划文章,未经许可禁止转载

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » 读云:云安全责任共担模式解读

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址