理论上讲，基于云的解决方案至少应当向客户提供与传统IT模式相同的安全水平。在理想情况下，云服务供应商应当提供更高级的安全水平，迁移到云的根本原因之一就是从客户方面看安全控制的低成本。
与从云服务供应商处得到的安全相比，同样的安全控制在企业内部实现可能会更昂贵。不管云供应商提供了什么样的安全水平，理解这个问题很重要：安全并不是“一锤子买卖”，而是一个过程，因而企业需要在云服务的两端实施安全，即：为保障数据的安全性，终端用户(进一步称为云服务用户)仍需要采取同样的行动。
数据总在无休无止地创建过程，我们还必须考虑如何保护数据的机密性、完整性、可访问性。在创建数据时，我们需要假设一些可能发生的最糟糕的情况，其中包括但不限于数据泄露、未授权访问、完全丧失对数据的访问，等等。未授权的访问意味着丧失了对数据的控制。数据处理的一个副作用就是生成了额外的副本，例如在硬盘上的交换内存、临时文件，或者是我们用以处理数据过程的内存。在基于云的方案中，关于数据处理的另一个必须考虑到的副作用就是元数据的创建。即使简单的处理也能产生大量的元数据。如今，收集元数据成为一项艰巨的任务，这意味着元数据也要求某种形式的保护，特别是由于元数据包含敏感信息，所以对其保护显得尤为重要。其次，从安全的观点看，加密和解密的位置与时间极为重要。如果加密发生在云端，企业就必须提供安全措施，将未加密的数据发送到其中。
在谈到数据泄露或未授权的访问时，我们首先想到的是加密。由于加密是从军事领域进入企业的，所以加密往往被误解，并被描述为一种很有魔力的可以解决所有安全问题的方案。但这种方法从开始就是有瑕疵的。下面展开讨论其中的诸多因素。
1.不安全的过程
用复杂的方案解决复杂问题并不是简单任务，在我们试图通过加密解决安全问题时尤其如此。安全始于信息处理过程。如果设计过程不合理，加密会安全吗?例如，如果你要求用户使用过长的复杂口令，用户就会找到一种不安全的方法绕过去。此处的原则是终端用户的体验对安全来说至关重要：控制应当允许用户快速完成任务而不带来太多障碍。企业的业务人员也喜欢这种方法，因为它可以长久地使利润最大化。
口令策略与加密有什么关系呢?虽然从安全的观点看，口令已成“过去式”，但是口令仍在使用中，而且还很强健。用户如何登录到移动设备?难道不是用PIN?用户如何登录到社交账户或云中的电子邮件账户?问题的寓意在于：如果你使用口令来保护对数据的访问，就需要保障口令的安全，并且经常更换。云方案并不会使口令完全消失。
2.用户教育和安全意识
不管你是如何巧妙地设计过程和实施过程，都不能忽视人的因素。正如爱因斯坦所言，有两件事情是永恒的,就是宇宙和人类的愚蠢,对于前者我并不太了解。如果用户能够在恶意软件弹出的窗口中多次输入口令，就不要期望加密会阻止其这样做。如果再强调加密的作用就是在自欺欺人。用户们必须认识到威胁，并且理解如何处理控制才能保证安全。钓鱼攻击正被一些类似恶意软件的攻击所利用。在恶意软件防护问题上这尤其重要。除非云服务供应商在其云服务和客户系统上提供恶意软件的防护,否则，对于终端用户的恶意软件防护来说，可做的很少。当然，客户必须安装最新的安全方案。扫描上传到云服务的文件或数据并不能阻止终端系统受到恶意软件的感染。因而，恶意软件不但可以感染系统，还能够从云服务的客户端窃取未加密的数据，并且可以窃取需要云服务访问的信息，还能破坏云服务。
3.不安全的架构
再次谈到云服务供应商。整个系统的架构(其中包括密码系统)对于最终的安全水平都至关重要。在多数情况下，要保障数据一直处于加密状态并不可行，因而，解密过程在应对未授权的访问和数据泄露风险时就显得尤为重要。企业应遵循如下的最佳实践：
(1)部署多层防御，仅有加密这一层还远远不够。
(2)尽可能在一个地方加密和解密数据，例如，这样做会限制有些信息没有被正确加密的风险，而且还要以使安全审计更容易。
(3)要保护好加密密钥和IV(初始向量)。
(4)确保实施强健的随机数字生成器。
(5)如果可行的话，不要使公众使用全部功能，从而限制攻击面。
很明显，上述清单并没有包含所有的最佳实践。有些最佳实践与服务类型或云服务的经营模式有紧密联系。
4.脆弱协议和算法
从安全的观点看，如果实施和部署不当，即使最佳的架构仍有可能成为隐患。例如，一些不安全协议和算法的使用，如SSH的老版本等。幸运的是，有些厂商开始禁止对不安全协议的支持。
另一个问题是，由于密钥太短小或生成方式不强大，就有可能造成企业的协议很强健而其密钥很脆弱。总之，不要使用太短小的密钥，因为其容易被破解。如果攻击者自身缺乏计算能力，他完全可以购买云服务，从而可以使其快速地破解短密钥。
5.随机数的随机性不强
如果不使用基于硬件的方案，对计算机来说随机数的生成并不是容易的任务。多数编程语言都提供随机函数，但这类函数并不安全，因而不应用于密码系统中。简言之，脆弱的随机数生成器可以使整个密码系统不安全，并易于被破解，因为这可以使攻击者正确地猜测到生成器的结果和种子的初始向量，从而使密码分析攻击更容易，并且使攻击者可以破坏整个加密过程。
6.算法很强健，但实施过程有漏洞
即使从密码术的观点来看，所有已部署的协议和算法都很强健，也不意味着其实施就是安全的。在此存在着两个问题：1.不正确地实施安全算法或安全协议，从而弱化其加密性能。2.软件或硬件中的缺陷，导致可能被第三方利用其漏洞。
OpenSSL漏洞就是第二个问题的一个例子。第一类问题就需要更多解释。每种加密算法都有一套定义其强度的属性。前面提到的不正确实施安全算法或安全协议的一种原因就是，使用了不安全的随机数生成器。这种问题未必是程序员有意为之。例如，程序员使用的可能是提供不安全伪随机数生成器(被认为很安全)的外部库。在简单的代码检查过程中，这种漏洞是不可能被发现的。
7.临时文件和Swap内存
如果交换内存和临时文件在云服务的两端都没有加密，这必然成为一种泄露数据的方法。下面讨论两种情况：1.加密发生于云服务供应商，而数据是通过安全通道被传送到云的。2.加密发生于云服务客户端，加密的数据被发送给云服务供应商，使其可以用加密的形式存储。
在这两种情况下，交换内存和临时文件都可能包含未加密数据的副本。 即使攻击者只能访问不完整的未加密数据，并可以获取访问加密数据的副本，也会使密码分析攻击更可行。那么，上述两情况有什么区别呢?答案是交换内存和临时文件的位置：在第一种情况中，交换内存位于云服务供应商的架构中，而在第二种情况下，交换内存和临时文件位于云服务客户的工作站或移动设备上。很明显，对这些区域的访问应当受到限制，但其实施过程应有所区别。在第一种情况下，实施的责任属于云服务供应商，而且在多数情况下，云服务的客户对于如何实施的细节知之甚少。事实上，在多数情况下，只有客户和供应商之间的合同可以定义供应商必须采取的措施。在第二种情况下，保护交换内存和临时文件就属于云服务客户的责任。不过，如今的有些操作系统默认会加密交换内存，但对于移动设备，就有很大不同。临时文件的保护不同于此。多数操作系统通过限制文件的访问和移除文件来保障临时文件访问的安全。不幸的是，现代操作系统及其支持的存储设备，安全移除文件往往是不可能的。还有另外一种情况，其中的临时文件并没有被删除。例如，这种情况可能是应用程序崩溃的结果，也有可能是被另一个过程锁定的原因。这个问题的解决方案就是加密的文件系统，此时，即使临时文件并没有被完全删除，或者没有以一种安全的方式删除，对其访问仍受到限制。
为什么交换内存和临时文件成为如此严重的问题?不妨设想一下用户丢失移动设备的情况，或设想由于发生故障，云服务供应商更换存储媒体的情形。后一种情形会带来一个关键问题：云服务供应商安全地处置IT设备。这个过程应当准备好，并且在服务等级约定中进行明确定义。
8.事件处理、取证、数据发现
在考虑数据加密时，我们还必须考虑安全事件发生时出现的问题。对加密文件或文件系统或交换内存进行取证分析可能会很复杂，甚至是不可能的任务。对于云服务，问题会更复杂，因为你有可能无法访问文件系统。事实上，在有些服务中，甚至没有文件系统的概念，所以典型的取证分析过程从一开始就失败了。在考虑加密和计划事件处理过程时，也要考虑这个问题。
加密数据只有在保持其完整性时才能被解密。但是，如果由于安全事件或是由于硬件故障等随机事件，其完整性遭到了破坏，就有可能不能成功地解密数据。在这种情况下，数据发现方法就没有什么用处了。这就要求我们重点考虑备份策略，尤甚是在我们使用加密时。有些合规要求强制使用加密备份作为唯一的选择。所以在我们使用云服务时，检查云供应商的备份和加密策略是非常关键的。
9.依赖厂商加密
如果你的数据是由云服务供应商加密的，至少应当检查两方面：
(1)你有一份未加密数据的副本吗?
(2)加密数据如何传送给另一个云服务供应商或传回给企业?
如果你将未加密的数据副本上传到云中，就应考虑找一家可以提供安全通道的云服务供应商。事实上，这种情况很少发生，因为使系统和云的数据保持同步和更新是一个问题。事实上，这种方法会限制充分利用云服务的好处。
第二个问题更为典型，而且有些厂商为了自己的业务也不愿意放走客户。由此导致的结果是，加密成为一种很好的方法。如果加密数据不是简单地从一个云服务供应商传送给另一个供应商，你就必须解密、上传、加密数据。对于单个文件或小文件，这种操作不会有什么问题，但是，随着文件的数量和大小的增大，在云服务供应商之间进行切换的复杂性和时间都会增加。在极端情况下，这种复杂性和时间会导致高成本，从而使得在云服务供应商之间的切换不再是一种可行的选择。
如果你在本地加密数据，而仅仅将云用于存储加密文件，就不受上述问题的影响。
