企业应该做的第一件事情就是根据云回顾通知的途径：什么意思呢?如果发生泄露，(是否)CSP如何向你的企业机构报告数据泄露或者其他的安全事件。这些听起来相当直接，直到你真正开始操作，也就是说由于不同的用例和交付模型--以及不同的服务提供商--可能会改变通知客户的方式。

比如，考虑一种大规模的IaaS部署，比如虚拟化数据中心。在这个场景中，可能合约性的口述需求，泄露通知怎样和在什么时候会出现，可能通过合同规定的渠道来通知你具体的技术事件。相比之下，SaaS业务应用可能在合同中规定通知，但是不要求共享技术细节。其他的，比如面向消费者的服务，比如DropBox,可能没有一个合同，更不必说具体的泄露通知了。

问题在于，可能并没有一个针对所有云服务的跨面板的统一的通知位置。因此，“你怎么知道什么时候发生泄漏呢?”就像用例不能用同样的笔刷图画，通知也同样。相反，企业必须就事论事地评估CSP关系、用例和通知选项。(需要指出的是这也意味着企业知道什么用例在第一位。如果不知道，就应该从这里开始。)

在用这种方式评估每一个云用例时，确保考虑到CSP被要求做什么(或者对于内部提供商达成协议)，告知你事件的机制，以及你同其交互的选择是什么等。在评估期间尤其要注意三件事：你如何使用这个服务(比如，存储的数据类型、支持的业务类型等)、主要员工(你的员工和提供商的员工)以及你在查找泄露时的责任是什么(比如报告基于你的评估，比如入侵检测或者应用日志)。这个数据在随后的计划阶段很重要。

开始更大的部署很有帮助，比如集中化IaaS和PaaS,因为他们更易于处理。应用(比如SaaS)也很重要，但是记住追踪他们是重要的责任，比如来自Netskope的最近的数据，建议组织架构平均采用397个云应用。因此独立分析每一个很可能会花费一点时间和精力。

这里的关键点在于从容易的开始并构建它。文档时刻伴随是个好主意，因为随着时间的推移会变得越来越复杂。

为运营响应做计划

(责任编辑：)