可移植性和互操作性概述-云安全VIP

? ? ? ? ? 可移植性和互操作性-云安全 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 必须要事先考虑到未来可能需要更换云提供商的情况发生，可移植性和互操作性必须被作为云项目风险管理和安全保证的一部分而提前考虑。 大型的云提供商可以在云中提供异地灾备，这使得一个云提供商为客户提供高可用性的服务成为可能。然而，用户部署基本的业务连续性计划还是明智的，以把最坏情况造成的影响降至最低。在未来，企业可能会突然发现必须立刻更换其云提供商，主要的原因包括以下几点： · 无法接受续约带来的费用增加 · 提供商停止了业务运营 · 提供商在没有给出合理的数据迁移计划之前，关停了企业正在使用的服务 · 无法接受服务质量的下降，比如无法完成关键业绩要求或服务级别协议(SLA) · 发生在云用户和提供商之间的分歧 一些简单的架构级设计可以帮助将上述问题发生的损害降至最低。然而，解决这些问题的办法取决于云服务的类型。 使用SaaS的客户可以使用新软件应用替代旧的。因此，关注的重点不在于应用的可移植性，而是保持或增强旧应用程序的安全功能，以成功的完成数据迁移。 在PaaS情况下，为达到可移植性，一定程度上对应用的修改是需要的。关注的重点在于当保存或增加安全控制时，最大限度的降低应用重写的数量，同时成功的完成数据迁移。 在IaaS情况下，关注的重点和期望是应用和数据都能够迁移到新的云提供商并顺利运行。由于缺乏可操作性方面的标准，也缺乏对此类标准的市场压力，在云提供商之间的转换可能会是一个痛苦的手工过程。从安全的角度看，我们主要的关注点(concerns)是在环境变更时维护安全控制的一致性。 建议 针对所有的云解决方案: ? 更换云提供商，至少对于一方来说，实际上是一种消极的商业业务，可能会导致来自于上一家云提供商的无法预计的消极反应。这必须在合同过程中、业务连续性规划和全局治理中加以计划。 ? 理解托管在云提供商处的数据集合的规模。数据规模的偏差可能导致在传输中的服务中断，或者是超出预期的传输周期。很多用户发现在传输大量数据时，使用人工快递硬盘比电子传输的速度要快。 ? 用文档记录安全架构和每一个安全组件的配置，这些文档可以用以内部审计，同时也有利于未来向新提供商的迁移。 针对IaaS 云解决方案: ? 理解新的云提供商是如何采集和移植虚拟机镜像的，因为其可能使用不同的虚拟化技术。 ? 识别和去除(至少记录)虚拟机环境中特殊的提供商扩展。 ? 理解在应用已经完成从云提供商的移植后，是否有措施到位来保证恰当地删除(decommission)虚拟机镜像。 ? 理解硬盘和存储设备“退役”的实践做法。 ? 理解以硬件/平台为基础的依赖关系，并在应用/数据迁移之前识别出来。 ? 向之前的云提供商索取系统日志、线索(traces)的访问权限，以及访问和账单记录。 ? 如果新提供商的服务质量不能令人满意，选择与前云提供商重新开始或延续一部分或整体服务。 ? 确定现有系统中是否存在任何与新提供商不兼容的、或者是新提供商尚未实现的管理功能、接口或者应用程序接口(API)。 针对PaaS云解决方案: ? 尽可能的使用那些采用标准语法、开放应用程序接口和开放标准的平台组件。 ? 理解哪些工具可以用来做安全的数据传输、备份和恢复。 ? 理解并文档记录PaaS提供商特殊的应用组件和模块，并开发包含抽象层次的应用架构以减少对私有模块的直接访问。 ? 理解类似监控、日志记录和审计等基础服务在新提供商的系统中如何传送。 ? 理解前云提供商提供的控制功能，以及如何将其过渡到新提供商的系统中。 ? 当迁移到一个新平台时，理解其对应用的性能和可用性的影响，以及这些影响的衡量办法。 ? 理解如何在迁移之前和之后完成测试，以确保服务和应用运行正常。保证提供商和客户都清楚自己的测试责任并进行文档记录。 针对SaaS云解决方案: ? 执行常规的数据提取和备份，以保证其在非SaaS模式下可用。 ? 理解元数据是否可以被保存和迁移。 ? 理解现有系统中是否存在任何定制工具，在将来需要被重新开发或者新的提供商必须提供这些工具。 ? 保证在不同云提供商之间控制的一致性。 ? 保证以下数据或文件的可移植性，包括备份和日志、访问记录的其余拷贝，以及其他任何可能因法律和合规原因被要求的信息。 ? 理解管理、监控和报表接口，及其在不同环境之间的整合方式。 ? 对于新的提供商，是否有条款规定在移植前去测试和评估应用程序。 ? -全文完-