用云存储审查、日志系统可以找到云数据泄漏的原因吗

做好基础工作
企业应该做的第一件事情就是根据云回顾通知的途径：什么意思呢？如果发生泄露，(是否)CSP如何向你的企业机构报告数据泄露或者其他的安全事件。这些听起来相当直接，直到你真正开始操作，也就是说由于不同的用例和交付模型–以及不同的服务提供商–可能会改变通知客户的方式。
比如，考虑一种大规模的IaaS部署，比如虚拟化数据中心。在这个场景中，可能合约性的口述需求，泄露通知怎样和在什么时候会出现，可能通过合同规定的渠道来通知你具体的技术事件。相比之下，SaaS业务应用可能在合同中规定通知，但是不要求共享技术细节。其他的，比如面向消费者的服务，比如DropBox,可能没有一个合同，更不必说具体的泄露通知了。
问题在于，可能并没有一个针对所有云服务的跨面板的统一的通知位置。因此，“你怎么知道什么时候发生泄漏呢？”就像用例不能用同样的笔刷图画，通知也同样。相反，企业必须就事论事地评估CSP关系、用例和通知选项。(需要指出的是这也意味着企业知道什么用例在第一位。如果不知道，就应该从这里开始。)
在用这种方式评估每一个云用例时，确保考虑到CSP被要求做什么(或者对于内部提供商达成协议)，告知你事件的机制，以及你同其交互的选择是什么等。在评估期间尤其要注意三件事：你如何使用这个服务(比如，存储的数据类型、支持的业务类型等)、主要员工(你的员工和提供商的员工)以及你在查找泄露时的责任是什么(比如报告基于你的评估，比如入侵检测或者应用日志)。这个数据在随后的计划阶段很重要。
开始更大的部署很有帮助，比如集中化IaaS和PaaS,因为他们更易于处理。应用(比如SaaS)也很重要，但是记住追踪他们是重要的责任，比如来自Netskope的最近的数据，建议组织架构平均采用397个云应用。因此独立分析每一个很可能会花费一点时间和精力。
这里的关键点在于从容易的开始并构建它。文档时刻伴随是个好主意，因为随着时间的推移会变得越来越复杂。
为运营响应做计划
一旦你收集了要求的数据，是时候进入计划的第二阶段了：分类以及一个操作的响应蓝图。如果这个听起来非常像“传统的”泄露响应，其实的确如此。实际上，云泄露响应可以作为更为广泛的响应计划工作的扩展，从而更好地实现。的确，由于环境不同，比如优先次序不同，技术响应选项和警报/通知路径不同，但是记得大多数用例都会在云和传统IT元素之间有一个交互点。这意味着为云组件尝试隔离维护单独的响应流程不可避免的导向更加的复杂性，缺乏透明度(比如，运营责任)和事件中产生的额外开支。
正如传统的灾难恢复和事故相应计划，优先级应该基于影响，反映了数据类型的功能以及业务危险程度。这两个因素也允许你了解是否或者什么时候或者其他的流程如何，比如外部公开的规程，都应该算在内。对比现有的事故响应流程额一个不同就在于，有助于基于关系自定制响应习惯，因为一些动作你可能系统包含在同CSP的交互中。比如，你可能要求你的CSP影响技术改变或者提供额外的信息。在这样的情况下，你可能会选择记录下来这些同CSP的经验。
问题在于，收集足够的信息可以为实际的策略活动构建你要完成的“响应蓝图”.因为响应的细节因环境、用例和关系而多变，加上其他的一些变量，你可能希望更加具体的技术活动；比如，事件响应计划和技术清单。为什么？因为你可能希望给予提供商所做的以及技术上不允许你做的等内容自定制技术响应活动。
需要牢记的是在做云端响应的时候并没有任何不同，首先要做的就是详细规划，在技术计划中为你的组织机构如何对这些不同做出说明是非常有用的第一步。