事件响应、通告和补救

由于云计算的本质，所以当发生安全事件、数据破坏、或其他需要调查和采取行动该找谁时显得更难以确定。为了满足相同汇报责任的需求的变化，需要修改标准安全事件响应机制。

对于客户来说，部署到云的应用程序并不总是把数据完整性和安全性设计放在第一位的。这可能导致脆弱的应用部署进云环境，进而引发安全事故。此外，基础设施架构的缺陷、加固规程中的错误、以及简单的操作疏忽都会对云服务的运营构成重大的威胁。当然，类似的漏洞同样也会危及传统的数据中心的运营。

很明显，事件处理过程需要专业技术知识，但隐私和法律专家对云安全同样可以作出重大贡献。在事件响应中，他们还会在通知、补救、以及随后可能采取的法律行动中发挥关键作用。如果一个组织考虑使用云服务，那么他需要审视有关未被用户协议和隐私政策制约的员工对数据的访问的机制是否已经实施。在IaaS和PaaS架构中，云服务提供商自己的应用程序不管理应用程序数据，这和SaaS提供商的应用程序控制数据有所不同。

大型云服务提供商交付SaaS、PaaS和IaaS服务的复杂性造成重大事件响应过程中的隐患，潜在客户必须评估相应SLA的可接受水平。在评估云服务提供商时，很重要的一点事要意识到供应商可能托管了成百上千的应用程序实例。从事件监测的角度讲，任何外部应用程序都会拓宽安全运行中心(SOC)的责任。通常，SOC监测那些由入侵检测系统和防火墙中产生预警和其他事件的指标，但是，在开放的云环境中这些必须监测的消息来源和通告的数量将会以指数方式增长，例如，SOC可能需要监测消费者之间的活动，还有外部事件。

一个组织需要了解他们所选择的云服务提供商的事件响应策略。这一策略必须解决识别和通知，以及针对应用程序数据的未经授权访问的补救选项。更为复杂的是，在不同的数据存放位置，应用数据的管理和访问有不同的含义和监管要求。例如，如果涉及到的数据在德国，有事件发生，可是如何数据在美国，可能就不认为是“事件”。这使得事件识别充满挑战性。

建议

• 在服务部署前，云客户要明确界定，并且和云服务提供商沟通什么是他们认为的事故(incident)(如数据破坏)，什么仅仅是事件(event)。

• 云客户参与云服务提供商的事件响应活动可能非常有限。因此，客户了解与云服务提供商的事件响应小组的既定沟通路径非常关键。

• 云客户应该调查云服务提供商使用哪些事件检测和分析工具，以确保他们对自己的系统兼容。在联合调查，特别是那些涉及法律调查(discovery)或政府干预(intervention)时，云服务提供商的某个私有的或者非常规格式的日志往往会成为主要障碍。

• 设计和保护不当的应用程序和系统可以很容易地“淹没”每个人的事件响应能力。对系统进行适当的风险管理，并且利用纵深防御的做法在第一时间减少发生安全事件的机会是很关键的。

• 安全运行中心(SOC)经常假定对事件响应上只有一个单一的管控模型，但是这对多租户的云服务提供商来说并不恰当。一个强劲而良好维护的安全信息和事件管理(SIEM)流程用以识别可用数据源(应用程序日志、防火墙日志、以及IDS日志等等)，并且将这些日志合并进可以协助SOC检测云计算环境事件的通用分析告警平台。

• 为了极大地方便的进行详尽的离线分析，可以考察能够提供整个客户虚拟环境快照的能力的云服务提供商，这些快照包括防火墙、网络(交换机)、系统应用程序和数据。

• 遏制(containment)是破坏控制和搜集证据之间的一场赛跑。基于机密性-完整性-可用性(CIA)这样三位一体的遏制做法才是有效的。

• 补救突出了能够将系统恢复到某个先前状态的重要性，甚至需要回到6个月或12个月前的已知可用配置。将法律选择和要求牢记在心，补救可能还需要支持事件数据的“事后分析”(forensics)记录。

• 所有因为数据泄漏监管而被分类为“私有”的数据都应该加密，以减少泄漏事件带来的后果。客户应在合同中规定相关的加密要求。

• 有些云服务提供商可能拥有一大批拥有独特应用的客户。为了能够给每一个特定客户提供细颗粒度的事件，这些云服务提供商应该考虑应用层日志框架。这些云服务提供商还应该构建一个注册表，按照应用程序接口(URL、SOA服务、等)来记录应用程序所有者。

• 在多租户环境下，应用级防火墙、代理服务器，以及其它的应用日志工具是当前可用的协助事件响应的关键能力。