当企业在评估通过加密或者其他方法保护哪些东西时，一般来说数据共享的风险可分解为两个基本的类别：泄露（公开)、滥用，包括以下方面：

　　将数据迁移到云中失去了对处于公司安全边界外的数据的控制,将会增加数据保护的复杂度，因而欺诈的风险也会上升。

　　出于合规或公司隐私的需求，云中的机密数据必须要保护.随着由系统内部管理的机密信息不断的迁移到云中，与之相应，需要花同样的力气去保护这些机密信息。将数据迁移到云中对提高机密性和数据保护没有任何帮助。与之相反，由于失去了对处于公司安全边界外的数据的控制，将会增加数据保护的复杂度，因而欺诈的风险也会上升。

　　在多租户环境中保护数据的基本安全工具之一就是加密。当你对云计算环境不具有完全控制权时，如果实施得当，云计算加密可以让你保护数据。这一点对于私有云计算和公共云计算都是极具价值的,尤其是在你与其他用户共享一个保存有不同敏感等级数据的存储库时.

　　但是云计算加密并不与你具有完全控制权的单租户环境中所使用的加密技术相同。如果实施失当，加密技术可能无法实现你所期望达到的功能和效果。而且，那些在传统基础设施中常见的错误也有随着云计算迁移而产生更大的负面影响。

　　意外或恶意泄露,由于不恰当的数据保Байду номын сангаас使信息或数据被第三方利用的行为；

　　滥用用户或网络档案资料，通过分析和数据挖掘去从看似为交通数据中提取出敏感信息，以揭露用户行为、关系、偏好或兴趣；

　　理解在数据的整个生存周期中，如何管理加密或解密的密钥.只要有可能,都应避免依赖云服务提供商去保护，并且应该适当地使用密钥去保护企业的关键信息;

　　可以避免因为雇员失误造成的损失，或者区域法律造成的麻烦。除非需要委托别人访问你的加密文件。如果只有你自己有密钥,那么只有你有资格访问你的文件;

　　不要忘记保护那些经常被忽略的文件，因为它们经常包含敏感信息。登录文件和元数据可能是数据泄露的途径；

　　3.对于更为先进的加密技术，你可以在实例中把密钥与加密引擎分离开来。在这个三层架构中，你有一个卷标用于存放加密数据，一个实例用于运行加密引擎,而第三个密钥管理服务器则可按需提供加密密钥。如果你希望密钥不在实例中，这个方法就能够满足你的要求，因为如果密钥在实例中,那么能够得到这个实例副本的攻击者人也就自然得到了密钥的副本。使用实例中的密钥就能够攻击相同的一个新实例.而外部密钥管理服务器只有在满足一组基于规则的标准时才会返回密钥,例如人工批准一个新的运行实例或在实例中运行的加密客户端中进行一致性检查。这样，内存中的实例就可以使用密钥直至实例关闭。通常这个方法只适用于特殊的云计算加密产品。

　　1。当使用云计算进行数据存储时，通常会使用一个虚拟私有存储架构。在把数据发送至云计算之前对其进行加密处理，而当数据发送回来后对其进行解密。例如,使用一个云计算备份服务，在把数据存储在云计算中之前，该服务就在备份软件中使用一个本地密钥对数据在本地进行加密。由于是你自己在管理加密操作和密钥，因此以安全备份的方式保留密钥副本是其中的工具(这应当是你的备份解决方案中密钥管理部分的一个功能)。

　　这里介绍的用例只是众多云计算加密中的三个，但是他们代表了三种分布加密引擎、密钥管理以及数据的不同方法。例如，在SaaS供应商企业网络和代理流量商业产品的虚拟私有存储中，加密诸如社会安全号码这样的敏感数据。

　　由于有如此多的不同云计算服务供应商、内部云计算配置以及SaaS、PaaS、IaaS模式，因此我们不可能在这里一一列举。。但是只要你知道你是在防备谁，你的数据、加密引擎以及密钥在哪里，你就可以设计出非常安全的体系架构，甚至是在你控制之外的多租户环境也是如此.

　　在将数据迁移到云中时通过加密来保护数据，所需要做的多于仅仅确保使用安全转移通道(如TLS）。在数据传输过程中加密不能确保数据在云中能得到保护。一旦数据达到云中,这些数据无论在云中还是在使用仍然需要保护;

　　对于在云中存储或共享时必须保护的无结构文件.这些文件可能通过以数据为中心的加密进行保护，或者在能够直接对文件进行保护时将加密嵌入到文件格式之中；

　　当然，在云应用中加密给商业应用提出一些问题,企业在部署应用架构时需要考虑解决,具体问题如下：

　　如果需要查询记录或者对象，加密过的主键（primary key)将使查询过程很复杂;

　　如果云应用集包含一批工作或其他涉及敏感数据的处理过程,尤其是PII和SPI数据，这些处理过程迁移到云中时，云环境将会使密钥管理变得复杂；

　　从企业内部到云上时，加密过程可以不需要用户干预是保障数据安全的首选方式。如果软件能配置协议感知，内容感知软件能够促进公有云加密的改善；现今的数据防泄露（DLP）应用案例满足产品的需求，能增强对将要离开企业的数据（通常以email形式)的保护，并在数据离开企业之前加密。这种原理可用于云数据保护,不过数据防泄漏产品或许产生警告。一个内容感知服务需要探测、加密和记录而不是警告.

　　任何加密系统都有三个主要的组成部分：数据、加密引擎以及密钥管理。如同使用笔记本电脑进行加密一样，所有这三个组成部分都在相同的位置中运行或存储。在我们的应用程序架构中，任何单一部分的损坏都有可能会导致整个系统的崩溃，因此我们往往会尽可能分离这三部分以便于减少这一可能性.现在,让我们来看看在一些常见的云计算安全架构中这三部分是如何分布的：

　　一个应用需要在数据库中找到记录或对象时，可能采用另外一种方式去存储唯一的值，例如令牌。令牌常被用在信用卡环境中，以确保信用卡卡号在应用中最低程度的被访问。从数值中产生的唯一的令牌能被用于产生新的主键，这些主键可以在公有云上的应用中使用,而不会暴露敏感数据;

　　在云上,与其他应用程序和数据一同工作的过程，如果需要操作明文数据，为实现其功能，必须能访问密钥或服务.

　　保格式加密比内容感知更进一步，通过检测数据的敏感程度来决定加密及维持数据格式和类型。例如使用传统的加密，一个信用卡的卡号被加密后的结构是一个密文,再也不是一个16位的数字.保格式加密将会产生加密后的16位的密文数字。通过保持数据类型和格式，这一服务能在众多的协议上有秩序地轻易改变很多数值。保格式加密的关键挑战是加密大规模的明文数值，如存储在云中的email。大规模加密通常地是使用块加密算法,对文本数据进行。在保格式的应用中，需要花费一定的时间将每一个单词加密成相同长度的字符串.不过,加密后的密文结果能像原始明文一样存储在相同数据类型的文件中。

　　2。对于存储在IaaS应用程序中数据的基本加密操作，你可以在你的实例中使用卷标加密，并把数据保存在第二个加密卷标中。由于你的密钥和加密引擎都保存在你的实例中，因此这并不是最安全的一个方法,但是这个方法确实能够保护你的数据免受非法访问的入侵。例如，假定你已正确地创建了你的实例，因此云计算供应商的某人也就无法得到授权运行系统或应用程序（这是典型的默认设置）,他们也就没有办法获取密钥进而访问加密卷标。（唯一的例外是，他们从内存中找出了密钥，对于大多数威胁模式,这都是极为罕见的）.

　　内容感知加密:在数据防泄露中使用,内容感知软件理解数据或格式，并基于策略设置加密。例如在使用email将一个信用卡卡号发送给执法部门时会自动加密；

　　保格式加密:加密一个消息后产生的结果仍像一个输入的消息。例如一个16位信用卡卡号加密后仍是一个16位的数字，一个电话号码加密后仍像一个电话号码，一个英文单词加密后仍像一个英语单词；