数据泄露的补偿金额通常不足以覆盖真正实际的损失，尤其发生云端的泄露事故。专家Frank Siemons在这里对数据泄露的和解协议选项进行了讨论。
大多数公司在未来几年内都会经历一种或另一种形式的数据泄露。根据信息来源的不同，对于会受影响组织的估算也会有所不同，但通常每年有40%至60%的组织遭遇数据的泄露。当这种不可避免的泄露发生时，它可能对公司的财务和声誉造成毁灭性的后果。传统的风险管理策略会考虑财务的影响以及事件发生的概率以此来应对确定的风险。有四种选项来管理这些风险：
1.缓解风险：比如，该控制的成本低于可能造成的损失;
2.回避风险：这通常是针对那些会对财务影响重大并且发生概率高的风险;
3.接受风险：组织由于各种原因包括成本效益的原因，决定不实施风险控制;
4.转移风险：通常到第三方保险。
来自一个第三方服务提供商责任方的数据泄露补偿不常被列入考虑的范畴，但这种选项应该值得调研。如果云平台本身遭遇泄露，提供对客户数据的访问甚至是跨客户数据的访问会发生什么?
数据泄露索赔
大多数有记录的数据泄露补偿案例涉及个人信息泄露，例如2014年Sony Pictures和2015年TalkTalk的数据泄露。在这种情况下，个人信息遭到泄露，而对此负责的组织在法律诉讼之前或之后提供赔偿，以补偿用户在金钱或隐私上的损失。虽然复杂了一点，公司之间确实存在一个类似的系统。这通常涵盖在服务级别协议(SLA)中，其中包括广泛的服务指标和条款，如对宕机时间和数据泄露的补偿。标准SLA的主要问题是，在现实中，数据泄露赔偿的价值与一次标准的泄露或断电可能对组织造成的重大损失相去甚远。例如，一个组织的网站在黑色星期五销售期间崩溃，导致了5000万美元的收入损失。该组织却只是获得了6小时的服务积分，价值约300美元。
云环境的细微差别
要深入了解云客户的安全事件和数据泄露补偿的细节，了解这些传统选项之间的一些关键差异很重要。
这里最主要的区别是责任从客户转到了云服务提供商。这些责任不仅涵盖基础设施的可用性和性能，而且还涵盖了该服务的安全方面的一部分。这些责任会随着客户对于云使用程度的进一步加深而加重。例如，一个云服务提供商在基础设施及服务模式上的安全责任会比对软件即服务的模式更重，因为前者所提供的服务比后者又增加了泄露的可能性和风险。攻击者利用底层云系�������发动的攻击所带来的潜在损害会变得更大，原因很简单，因为云平台控制着更多的服务。
另一个重要的区别是多租户环境。云提供商是价值很高的攻击目标，因为可以一下子访问许多客户的系统。举个例子，假设攻击者获取了对Azure Web服务平台或者Rackspace内部基础架构的访问。如果这在云采纳初期听起来似乎有点遥不可及，还可以考虑来自内部攻击的可能。云服务提供商的员工有没有经过审查，以及该审查过程是否同他们的客户审查过程一样使用相同的标准?这仍然是个未知数。
历史云泄露
即便在云环境中发生的重大跨客户安全泄露案例在现实中很难找到，然而越来越多的安全专家正在对此巨大的风险提出警告。2015年，伍斯特理工学院的研究人员声称他们使用亚马逊网络服务实例获取了位于同一台机器上的另一个AWS实例的访问，此举在一个相当复杂的白皮书中记录在案。亚马逊立即淡化了这种风险，表示该攻击需要目标亚马逊弹性计算云实例上有“非常罕见的，不太可能预先存在的过时的第三方软件”。然而，这个例子表明，只是因为数据在云中以及可能被加密过，并不意味着该系统是无坚不摧的。第一个轰动媒体的以云为主题的大型安全漏洞的爆发仅仅是时间问题。
结论
调研并对云数据泄露赔偿政策达成一致至关重要。这是由于数据泄露所增加的暴露风险和影响，而这又会增加组织的风险。私人信息的泄露或大范围的服务宕机所带来的损失不能简单地用传统的SLA赔偿金额结算。损失可以高达百万美金。只是给于几个月的免费服务在这种情况下根本起不到什么作用。例如，Azure应用网关云服务对于小于99%的正常运行时间只给于客户25%的服务积����。假设你有一个大型的网店，然后遭遇两天的宕机时间。那些服务积分甚至都不值得我们花费几个小时的文书工作来获得，尤其当你需要处理最近的一次重大断电事故的善后工作时。
