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

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

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

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

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

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

    做好基础工作

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

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

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

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

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

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

    为运营响应做计划

    一旦你收集了要求的数据，是时候进入计划的第二阶段了：分类以及一个操作的响应蓝图。如果这个听起来非常像“传统的”泄露响应，其实的确如此。实际上，云泄露响应可以作为更为广泛的响应计划工作的扩展，从而更好地实现。的确，由于环境不同，比如优先次序不同，技术响应选项和警报/通知路径不同，但是记得大多数用例都会在云和传统IT元素之间有一个交互点。这意味着为云组件尝试隔离维护单独的响应流程不可避免的导向更加的复杂性，缺乏透明度（比如，运营责任）和事件中产生的额外开支。

    正如传统的灾难恢复和事故相应计划，优先级应该基于影响，反映了数据类型的功能以及业务危险程度。这两个因素也允许你了解是否或者什么时候或者其他的流程如何，比如外部公开的规程，都应该算在内。对比现有的事故响应流程额一个不同就在于，有助于基于关系自定制响应习惯，因为一些动作你可能系统包含在同CSP的交互中。比如，你可能要求你的CSP影响技术改变或者提供额外的信息。在这样的情况下，你可能会选择记录下来这些同CSP的经验。

    问题在于，收集足够的信息可以为实际的策略活动构建你要完成的“响应蓝图”.因为响应的细节因环境、用例和关系而多变，加上其他的一些变量，你可能希望更加具体的技术活动；比如，事件响应计划和技术清单。为什么？因为你可能希望给予提供商所做的以及技术上不允许你做的等内容自定制技术响应活动。

    需要牢记的是在做云端响应的时候并没有任何不同，首先要做的就是详细规划，在技术计划中为你的组织机构如何对这些不同做出说明是非常有用的第一步。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。