微盟该负全责吗？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(高级持续性威胁)中，而攻击目标一般是国家的关键信息基础设施。所以一旦出现这种情况，责任、赔偿已经不是主要考虑的问题，安全厂商应和应用厂商联合，第一时间做好应急处置工作。

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

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!