微盟该负全责吗？SaaS安全责任该谁来背？

3月1日，微盟发布了公告，在公司内部揪出了三位高管，为这次删库事件负责。对于因此而受牵连的300万商户，微盟拿出了1.5亿和部分线上流量资源，用于赔偿。

说句实在话，微盟够意思。尽管数据恢复的过程和效率不尽如人意，但微盟在承担责任方面，一点都不含糊。

1

在微盟发布的公告中，有一条措施非常有意思，大致意思是微盟将逐渐放弃自建数据库，而是使用腾讯云数据库。由此笔者想到了一句话：“造不如买，买不如租。”

这句话本身并不是什么特别好的话，甚至略带负面色彩，但是我认为在商品经济尤其是在云计算经济的今天，这句话是非常贴切的。云计算把基础设施资源像水、电一样，让用户可以直接使用，那用户干嘛不直接选择租用或者购买专业的厂商的专业产品和服务呢？对于普通的政企机构而言，购买类似于微盟等现成的SaaS应用，同样要比自己组建团队开发或者外包要更加方便一些。

话说回来。微盟当然希望能通过采用腾讯云的云数据库，来尽量避免类似的安全事件，从而降低给自身也降低给微盟客户带来的损失。要注意的是，在购买或者租赁服务的同时，责任的主体同样发生了传递。原本微盟的数据库部署在本地，出了事情责任传递到微盟这里就已经基本结束了；但将来数据库会部署在腾讯云上，如果再发生类似的问题，责任会不会传递到腾讯云这里来呢？

2

我想答案是肯定的。《网络安全法》中明确规定了网络运营者的权利和义务，其中网络运营者是指网络的所有者、管理者和网络服务提供者。腾讯云作为服务提供商，如果出现类似的安全事故，将负有不可推卸的责任。

不过，这次微盟删库事件的整个经过非常简单，无非是一个工程师因为个人原因，删除了部分数据库，从而导致微盟出现了不可用的状况，责任认定非常清楚，微盟需要负全责。但很多时候事情不会这么简单。

举个栗子。

假设客户A购买了企业应用提供商B1的BPM软件，用于企业日常的工作流审批，而该软件部署在IaaS提供商C的服务器上。一般而言，如果是因为BPM软件本身的漏洞而遭受攻击，B1就应该为A的损失承担相应的责任；如果是因为C的服务器遭受攻击，那么C就应该为A的损失承担相应的责任。

但企业服务绝不会如此简单。随着客户A业务的发展，B1提供的标准化功能已经不能满足A的需求，A可能会基于B1提供的PaaS平台做二次开发。而二次开发极有可能产生新的漏洞，如果新的漏洞被攻击者利用，那么该如何界定责任问题？究竟是PaaS平台的问题，还是A自身开发的问题呢？

情况还可能更加复杂。A可能同时购买企业应用提供商B2的报销软件，并且引入了集成商D为自己做集成。可想而知，这其中的责任链条就更加复杂。

由此诞生了一条责任传递的链条，如下图。随着交易和利益的传递，网络安全责任同样在逆向传递。

3

这还是在没有考虑引入安全厂商的情况。

说到这里不得不提一个概念：云安全的保姆式和共建式。

从字面意思就很好理解，所谓保姆式即提供基础设施服务的IaaS厂商同样可以像“保姆”一样为客户提供一站式云安全服务，客户可以直接向其采购响应的安全服务，比较典型的是国内的阿里云；而共建式则使用了责任共担模型，即IaaS服务商提供底层的基础架构的安全，上层的应用安全和数据安全则引入第三方的生态伙伴为客户保驾护航，国际IaaS巨头AWS则主要采用共建式云安全。

来看一个简单的案例。假设企业应用提供商B1采购了安全厂商S1的DDoS云防御服务，S1声称该服务可以抵挡峰值最高为100Gbps的攻击。但B1发现，自己部署在IaaS厂商C上的SaaS应用仍然因DDoS攻击宕机了，导致客户A无法正常审批，原因是攻击流量峰值达到了150Gbps。通常在这种情况下，B1应当承担主要责任。B1对于可能到来的攻击缺乏预见性，因而采购的安全产品不能够抵挡此次攻击。至于如何处置，则一般是商议决定。当然，如果S1的销售夸大了产品的防护能力，或者存在主动诱导客户购买100Gbps防护能力的产品时，则需要另当别论。

再来看一个较为复杂的案例。企业应用提供商B2采购了安全厂商S2的WAF（Web应用防火墙），但攻击者利用B2软件漏洞或者云服务商C的漏洞，成功入侵到服务器内部，并且采用了免杀措施绕过了WAF的检测，从而导致使用B2软件的客户A数据丢失或者泄露。

点击此处添加图片说明文字

考虑到保姆式云安全和共建式云安全的问题，安全厂商S和IaaS提供商C可以是同一个。

在这个案例中，要分多种情况讨论责任问题：

第一，企业应用提供商B2或者云服务商C提前发布了补丁并及时同步给了客户A，但A出于各种原因，并没有及时更新相关补丁，则A应该承担主要责任；

第二，企业应用提供商B2或者云服务商C并没有及时发布补丁，则A通常情况下不承担主要责任，而B2或者C需要承担相应的责任；

第三，安全厂商S2没有及时更新WAF的规则库或者检测能力明显弱于行业平均水平，导致攻击行为成功逃逸，在这种情况下，S2同样需要承担相应的安全责任；

第四，在极端情况下，S2利用了0day漏洞，并且使用了一种全新的攻击手法足以绕过市场上主流安全产品的检测。笔者认为，通常情况下，0day漏洞作为一种战略性的资源（价值极高，通常作为网络军火使用），只会出现在APT（高级持续性威胁）中，而攻击目标一般是国家的关键信息基础设施。所以一旦出现这种情况，责任、赔偿已经不是主要考虑的问题，安全厂商应和应用厂商联合，第一时间做好应急处置工作。

同样的，对于政企客户而言，其网络安全供应商通常也不止一个。由此，在引入安全厂商后，又得出了一个责任传递关系链条如下：

要注意的是，安全厂商之间的责任关系传递更加复杂。假设安全厂商S2的反病毒网关杀掉了S3的DLP进程，这个责任该怎么算？（这种情况也常见于2C领域，比如一个公司的杀毒软件杀掉了另外一个杀毒软件。）S2的反病毒网关和S1的IPS的反病毒模块，在功能上可能存在着很大的相似性，一旦出现问题，这两者之间的责任关系又该如何说明白？

4

但在网络安全责任认定的过程中，由于溯源分析非常复杂，很多时候很难确定网络安全事件事故发生的真正原因。因此，很多时候都需要依靠合同约定或者事前协商来处理责任关系。

当然，不管责任关系如何复杂，最终都要落到行动上。行动也无非就两种选择，一种是推、一种是揽。2018年，时任永信至诚高级副总裁的潘柱廷谈了一个观点：不能单纯判断推或者揽孰好孰坏，要具体问题，具体分析。

这里假设一个场景：企业应用供应商B同时采购了安全厂商S1的IPS和S2的IPS（内置反病毒模块），某天，B受到了病毒攻击。如果S1和S2同时声称这不关自己产品的事情（即推脱责任），会引发一定程度上责任关系断裂；如果S1和S2同时将责任大包大揽，就会出现责任关系冲突。

所以，这个场景还应该存在第三种结果，B、S1、S2甚至和云服务商C达成协议后，共同把病毒攻击这件事情的责任承担起来。

不过，在责任传递关系链条中，除了承担责任外，还有一种责任转嫁的方法——网络安全险。从字面意思很好理解，出了网络安全事故，通过设计相应的保险产品，将责任转嫁到保险公司。但具体如何设计流程、如何赔付，这都还要业界不断去摸索。

需要强调的是，出现安全事故以后的第一要务并不是去追究责任或者寻求赔偿，而是多方配合，尽可能降低损失。除了在事前采购相应的安全产品和服务外，网络安全厂商提供的网络安全应急服务已经成为政府机构、大中型企业有效应对网络安全突发事件的重要手段。

来源：中国软件网