取消
显示结果 
搜索替代 
您的意思是: 
cancel
3927
查看次数
62
有帮助
1
评论
julianchen
Spotlight
Spotlight
服务运营vs. 资源池化


容量/资源池


清晰的容量和性能需求对于云服务的空间与资源的预估和购买是相当重要的,同时也能够在云业务的上线之初和交付之后的一段时间内,有效地杜绝潜在的中断和性能瓶颈。当然,我们也应该与云服务商事先制定好按需订阅或扩容条款。如果购置的是IaaS的话,我们则可以在实际需求或业务模式发生变化时,及时地根据CMDB里的模板产生新出的虚拟机、动态地增配CPU和内存的数量、以及临时将某个host迁移到他处等。

高可用性/连续性


凭借着虚拟化主机和网络设备的镜像和数量的优势,我们的云业务可以充分发挥其服务的自愈和扩展能力,从而实现HA、业务连续性、和灾难恢复的效率。我们平时的各种重复单调的维护工作量也能相应地大幅减少。当然,对于那些和我们的系统有关,但由云服务商所负责的部分,我们不能只是被动地接受其例行的测试成功报告,而应当主动要求,真正地参到测试环节之中。

事件/故障响应


在云业务环境中,由于突破了以往的一套系统仅能提供单一服务的限制,所以造成了应用种类、数据混杂、和设备资源相互交错的状态。我们所面对的早就不再是能否扑捉截取到事件发生的问题了,而是各种被自动采集的海量事件集中性地扑面而来,所导致的筛选、分析和去除误报的局面。

具体来说,对于采用SaaS模式的企业,可能会更多地需要依赖云服务商的来采取各种的应急响应措施。而对于使用IaaS的企业,其IT部门则有能力和责任按照我们在《安全事件响应之五步进阶》里提到的“识别和分类->调查和取证->抑制、根除和恢复”的流程进行应对。我们逆推着来看:


  • 抑制是关键,我们可以通过暂停被攻破的虚机镜像,隔离它与其他系统的逻辑联系,从而既不会破坏它上面的证据,又能够阻止形式的恶化。

  • 现如今,我们到了云端,取证的环境变得高度动态且不定,这就对我们取证的各种要素,包括确定范围、收集方式、保留语义完整、和维持证据稳定等都带来了挑战。与此同时,隐私也是不可忽略的要素,同样需要服务商的合作与支持。

  • 而在各种事件的识别和响应上,我们需要考虑到由于业务系统不再孤立的存在于我们可控的环境中,所导致的那些针对云服务商的攻击也可能会给咱们系统带来的“殃及池鱼”的影响。例如:针对您所在的云环境本身或是其它租户的DDOS攻击,就算并非是攻击的目标,您的业务可用性也会有所波及。因此我们同样要做好信息的收集和事件的分析等工作。


可见,我们需要建立的是一套更全面和有互动性的日常管理流程,而非针对某个产品或项目的特定应对模式。与此同时,我们可以采用当前比较流行的大数据分析的一些工具,在实现快速综合性的智能分析的前提下,获取本企业不同应用中的云业务的全网视图,综合分析各种安全状况、安全事件和安全趋势,做到防范于未然。

评论
SMG-SH
Level 7
Level 7
高可用性/连续性,关键业务不掉链子
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接