云盘算是是一个很抽象的概念，一种难以名状的东西，尽管如此，我们仍然要应用到它，因为云盘算可以增加商业价值，而疏忽云盘算的企业也会失去竞争优势。所以，我们需要懂得如何安全地将这一新兴技巧融入到业务流程中。
云能给我们带来什么？
我们将云盘算定义为第三方供给的任意架构或服务，且它要支撑或传输业务流程。为了最大化商业价值，云盘算还应当供给点播可扩大性和改良的商业持续性。举例包含：
1. 供给商开发并托管Web服务，并将这些服务整合到内部开发的系统中，但是用户是通过Web进行访问。
2. 供给商通过内部人员对服务器托管的利用进行开发和管理。
3. 将完整的系统转移到供给商托管的网页。
随着云盘算技巧日趋成熟，供给商供给的服务也会随之得到改良。不过，最基础的前提是它能为大企业带来机动性，为中小企业带来机会。
重要问题在于风险
从安全角度来看，评估和管理与云服务相干的风险就是对现有的风险管理过程进行调剂。因此，并不需要花费大批的精力。
如果你手头没有风险管理架构，那么必需要先创立一个。保护企业的数据起始就是根据业务需求衡量风险。与企业管理者，审计员合作的时候，有必要应用那些旨在辨认，减轻和报告风险的正式流程来平衡风险。如果你手头有成文的架构，则可以直接对其进行扩大。
图一展现了许多企业的风险界限的简略模式。IT专业人员设计并安排了内部计划后，安全分析师会对其进行风险评估。不过，托管的风险界限止步于周边防火墙。非正式的流程用来模仿连接云服务供给商时产生的风险。
图一：内部风险界限
如图二所示，通往安全云一体化的路径风险界限的扩大。其目标并非是将云视为“外部之物”。相反，它是另一个附加于企业之上的增值型组件。扩大风险管理边界以便包围所有服务就一个能满足业务需求的整体计划。
图二：扩大的风险边界
差距
扩大风险边界并不是提出雷同的问题。整合云需要额外的考虑以应对供给商。以下是我们在评估一个云服务供给商时可能面临的挑衅：
1. 供给商是否具备一个外部实体可证实其有效应对安全问题的才能（SAS70,ISO 27001等）？拥有哪些内部控件？供给商如何比较我们的内部控件?差距在哪里，这种差距是否合理？
2. 涉及哪些数据？我们的企业供给的数据过剩实际所需吗？供给商所需的最小数据要素是什么，为什么是这些要素？
3. 供给商是否明白我们的安全期望?这些期望是否纳入了合同中？如果供给商没有遵照合同中的安全条款，将有什么制裁措施?合同是否容许我们履行自己的周期性审计（有关数据保护方面的评估审计）？这些都是要考虑的基础问题。我们是假设你已经在传输过程中保护好数据。如果没有，或许在扩大到云之前还有更大的问题需要解决。
结语
不要谈“云”色变，它并不是我们的敌人。问题并不是我们是否要整合云服务。真正的问题是如何管理好相干风险。是否每个供给商都值得信任？答案当然是否定的。但是，选择一个云服务供给商就如同选择一个内部软件，硬件或服务供给商。要懂得自己的需求，表达出自己对安全性能的期望，然后对供给商的产品进行评估。和服务商保持良好的沟通，共同改良控件。
相关阅读