读「云」 | 云安全责任共担模式解读

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

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

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

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

一、大雄的时间胶囊

早上快递小哥送来一个包裹，大雄拆开后发现是一个精致的铁皮盒，盒子里放着一枚胶囊。胶囊上贴着标签，上写时间：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而言，数以万计的云上客户安全保障需求变化，驱使着其安全团队将底层安全能力进行持续提升。

那云上客户自身参差不齐的安全能力现状怎么解决，这恰恰是公共云安全生态建设要解决的核心问题，一朵鲜花盛开不代表冬天已走远，只有百花齐放才预示着春天的到来。

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

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

漏洞盒子 VulBox

国内领先的互联网安全服务商

 MAKE SECURITY ENTRENCHED STILL

 

原文始发于微信公众号（漏洞盒子VulBox）：读「云」 | 云安全责任共担模式解读