尽管企业消费技术的途径不断在发展，但是相比之下最近两种趋势引人注目。首先是云用例持续激增。其次是新数据外泄不断占据头条。

可以理解，这两个事实让很多组织机构担心与其云部署相关的可能的泄露。这种恐惧是复合的，因为很多时候，在提及安全操作时，使用云计算就假设放弃了部分控制。换句话说，采用云计算--无论是通过内网还是外网云服务提供商交付--意味着有目的的“抽取”应用堆栈的基础部分。

需要指出的是我并非暗指云必然要比替代交付模型更加充满风险、缺少安全或者更易于产生数据泄露。相反，一些数据显示了截然相反的事实。但是事实上，云用户在提及安全时仍会感到一机灵。部分原因是缺少控制：就像一个飞机上的乘客可能(根据统计)要比开车的乘客更安全，缺少直接的操作控制也更让人感到恐惧。

这也就是说云服务提供商(CSP)的数据泄露可能且会发生。当数据泄露发生时，如果企业的事件响应计划由于云的功效做出不适合的响应，那这就是一次不幸的意外了。比如，当你对技术基础只有很少或者没有操作控制时，整个计划包含具体的技术活动(比如禁用一个网络端口来压制恶意软件主机)可能不可行。

在很多企业的云环境中这是可能发生的，不管是基础架构即服务(IaaS)、平台即服务(PaaS)还是软件即服务(SaaS)。除非你已经为这个做好了一些计划，有可能很好地响应云端的事件，可能你的遗留应急响应计划并不包含在内。比如，你如何获得通知?谁来授权实现来自提供商技术服务请求(他们是否在IR环中)?这个请求的机制是什么?是一个特定的服务控制面板还是电话?响应团队的曾远知道如何获得工具吗?他们能否分配来进行访问?

就像是一个传统的IT环境，找出这些问题是如何回答的并不是一蹴而就的事情;现在开始准备就已经晚了。在这篇技巧中，我们将回顾如何为一次涉及云服务提供商的事件计划数据泄露应急响应。

做好基础工作

(责任编辑：)