随着开发人员和组织认识到云感知应用程序不断增长的价值，它们的架构和设计正变得越来越流行。云感知应用程序可能十分灵活、容易扩展、能更快地进行开发，而且更加经济。尽管云感知应用程序拥有诸多好处，但是它们的架构也许给无意识的人带来诸多安全挑战。本文将介绍云感知应用程序所带来的一些安全挑战，及您怎样通过各种最佳实践来解决其中一些挑战。

　　云感知应用程序的特征

　　云感知应用程序是十分简单的应用程序，它们能感知正被利用的云(如阿里云)服务和基础架构，支持无缝且自动化地扩展、精减、故障转移等。部署在云中的简单 Web 应用程序实际上是一个部署在虚拟硬件堆栈上的多层软件堆栈，与此不同的是，云感知应用程序也许拥有一种更加分布式和无状态的模型来使用计算的服务和角色模型。要了解传统 n 层应用程序与云感知应用程序的特征的总体比较，请参阅 表 1 和 表 2。

　　表 1. N 层应用程序特征

　　表 2. 云感知应用程序特征

　　从表 1 和表 2 中可看到，云感知应用程序旨在利用众多的服务和端点，与在云(如阿里云)上运行的更传统的孤立应用程序不同。由于您的数据或应用程序的功能可能依赖于您无法掌控的第三方或合作伙伴服务，因此可能带来安全问题。尽管云服务存在内在风险，但它们在云感知应用程序中特别流行，您的数据也许被暴露处于静止、活动和使用状态。此外，在云感知应用程序中，您的数据最终也许由第三方管理或使用。合作伙伴也许拥有糟糕的安全性，可能疏忽地发布数据或者被攻击者利用，不幸的是，甚至对于一些最著名的云应用程序和服务，这些情况也经常发生。另一个问题是，即使您使用 SSL，您的数据也有可能遭到损坏，因为它是通过线路传输的。尤其在您的证书或合作伙伴的配置很差的时候，很可能出现这种情况。数据也有可能被利用，由于您的数据由云环境使用，云环境可能被损坏，泄漏您的加密密钥和重要数据。最后，由于云感知应用程序的自动化和连锁性质，它们的 API 端点通常很容易被利用，除非对它们采取了访问控制。

　　3 种加密状态和云的共享风险模型

　　大多数安全专家和加密专家将加密分为 3 种状态。第一种是静止数据，描述您的数据在未使用的文件系统上时的状态，比如文件和数据库中的数据。第二种是活动数据，比如当您将数据从一个服务器转移到另一个服务器时。所有流经网络的位(bit)都被视为活动数据。最后，我们还有使用中的数据，也就是正在您的 CPU 或 RAM 中使用的数据。理解这 3 种加密状态，才能更好地理解您在云中的脆弱性。

　　云感知应用程序创造了独特的安全威胁，因为基础架构即服务 (IaaS) 提供商和平台即服务 (PaaS) 提供商都在使用某种共享风险模型。这意味着，您的云合作伙伴通常会提供一个受保护的数据中心、一些网络安全保护、高可用性存储和硬件，以及其他服务，但您被要求自行满足一些安全考虑因素。这些因素包括身份访问管理和控制、入侵检测、监视、操作系统加固、系统修补，当然还有加密。此外，由于共享风险模型，因为您对您的机器和接触它们的人没有物理控制权，所以能够在物理上访问您系统的供应商员工或第三方进行攻击利用的风险更大。云系统中的其他租户也可能攻击您的系统或感染它们(尽管目前还未出现过)。因此，云安全联盟特意要求加密您的云系统上的所有敏感数据，保护您的所有活动数据。

　　云感知应用程序中的加密需求

　　除了极少的例外，任何公司最重要的资产之一就是其数据。您的数据可能包括财务信息、专用销售信息、市场营销信息、医疗信息、知识产权 (IP) 等形式。丢失数据可能给业务运营造成负面影响，甚至可能导致您的组织倒闭。该信息被盗或发布给公众，可能损坏您的声誉，导致法律问题，给您的品牌带来负面影响，在 Sony Pictures 最近受到的攻击 中就可以看到。所以，保护您的数据可能且应该是一项对业务非常重要的工作，无论您是只有两个人的创业公司还是跨国企业。要保护您在云中的数据，您需要采取许多操作——从控制访问到加固您的操作系统。无数的数据破坏表明了采取一些关键步骤的重要性，比如对数据的移动和访问方式创建策略，以及加固您的网络。无论您采取多少步骤来保护您的系统，总有人可能找到途径损坏您的数据。新威胁随时可能出现，从更常见的内部人员威胁到民族国家的攻击，甚至可能包括让安全专家惊讶和损坏整个系统的软件中的基本缺陷。因此，正如我已指出的，云感知应用程序应内置安全性，对静止和活动数据都进行加密。

　　静止数据

　　有两种保护静止数据的基本方法：全磁盘加密 (FDK) 包括一个驱动器上的所有信息，而文件级加密 (FLE) 仅加密敏感文件或数据。这些方法都非常简单易懂。使用 FDK，磁盘上的所有信息都会加密。它拥有许多优势，包括更简单的管理，因为所有信息都会自动加密。该方法的一些不足是，它可能需要大量计算资源，这会影响系统性能，有时会占用太多磁盘空间。尽管如此，大部分使用 FDK 的公司都表明这些开支是物有所值的。但一般来讲，大多数云服务提供商都通过各种服务或 API 简化了 FDK 的设置和部署。如果您的应用程序中或某个特定数据层上(比如数据库)有许多敏感数据，那么 FDK 就会很有用。如果只有小部分信息是敏感的，那么 FLE 可能更可取一些。大部分针对云感知应用程序的云服务和软件堆栈(比如 Cloudant)都可以使用 FLE 轻松地存储已加密的二进制数据。

　　对于静止数据，要考虑的另一点是反复制技术或数据权限管理 (DRM)，可以使用标签或集成工具(比如 Adobe 的 DRM)等各种技术。根据您对这些工具的需要，可以显著减少由于内部人员威胁而导致数据泄漏和公开的机会。这对于云感知应用程序十分重要，因为数据也许会不断地在不同的最终节点中移进移出。在许多情况下，您可能希望结合使用过反复制技术、FDK 和 FLE。例如，您可能有一个应用程序，它的数据已在数据库中加密。您的应用程序还会使用报告生成服务生成敏感的、需要加密的报告;这些报告存储在支持 FDK 的数据存储服务中(比如 Glacier 或 Nearline)。在这种情况下，加密的文件和二进制数据存储在经过整体加密的 PaaS 归档解决方案上。这种常见设置引出了下一个话题：对于一个共享和使用来自大量端点的数据的云感知应用程序，您应该在何处执行加密，您在何处存储您的密钥?

　　大多数云感知应用程序利用了大量的外部服务。例如，您的云感知应用程序可以利用消息队列服务、图像缓存服务、数据存储平台、归档服务和其他服务，所有服务都通过一个服务编排平台来协调。您的系统会通过您拥有很少控制权的服务来发送和使用大量包含重要数据的消息。出于这个原因，您的数据必须始终加密。不幸的是，太多的组织在服务间转移数据而没有加密其数据或文件，并且相信每个服务都会保护其数据的完整性。这些做法已导致大型公司通过第三方合作伙伴泄漏了用户数据，这些合作伙伴没有安全地存储数据，或者实现了糟糕的静止数据存储机制。因此，您应该加密所有敏感数据，在解密前一直保持加密状态。这可能很复杂，需要您自行管理加密密钥。幸运的是，许多公司(比如 KeyNexus 或 CloudCipher)提供了一些相关的产品和服务，允许您使用自己的密钥或 PKI 基础架构来始终保持对数据的控制。许多 IaaS 提供商还提供了 API，使您能够使用自己的加密密钥管理其服务中的加密。选择提供商时，您应该了解您的静止数据需求，您是否需要控制自己的密钥，以及您的云应用程序堆栈是否支持它。这通常是一个至关重要的决定。

　　策略先于技术：合规性和控制

　　在考虑采用哪些方式来保护您的云感知应用程序之前，应该考虑您组织的安全驱动因素，以便可以围绕您应用程序的保护提出清晰且定义明确的策略。这些策略还需要推进您的安全软件开发生命周期 (S-SDLC)，不仅要创建更安全的应用程序，还要在其整个生命周期对它进行管理。开发您的策略时，一些起点包括：

　　确保接触您系统的所有主要利益相关者都参与其中，这些利益相关者的范围是：从 HR 到业务运营，到财务，再到高级 IT 管理人员。组织常常忘记包含不同部门，这通常会导致一些问题，比如我们在 Sony Pictures 看到，包含高度敏感的数据的合同以明文形式存放在服务器上。设计一个策略来确定谁能够访问您的系统，并实现一个健全的身份管理解决方案，该方案不仅针对您的内部用户，还针对公开的服务和端点的使用者。您的解决方案必须支持生成访问日志的能力和基于策略的访问，以及加密和密钥管理。最后，尽早考虑多租户，因为即使是单租户应用程序，最终在某个时刻也需要支持多租户。

　　从总体上决定谁将能访问您的加密密钥，以及这些密钥将位于何处。具体的实现将规定您如何管理密钥，但您首先应对谁应能够访问它们有一个明确的认识。仔细考虑您必须遵守哪些法规，比如 PCI、FISMA、HIPPA 和 GLBA。大部分法规都要求提供特定的加密水平，或者规定如何管理加密密钥。其他法规要求自动加密员工信息或计算信用卡编号的哈希值等。与您的利益相关者紧密合作，确定哪些数据对您的公司很重要。这比听起来难得多。拥有敏感的知识产权或专用信息的公司肯定应加密其数据，但许多公司拥有可能在最初评估时看起来不敏感的信息。例如，许多公司认为客户电子邮件或个人信息对任何人都不重要。而犯罪分子非常重视这些信息，可以将它们转售给垃圾邮件发送者、网络钓鱼者或身份盗窃者。丢失这类数据可能会严重危害组织的品牌和其客户的信任。

　　尽早决定数据破坏策略。有时您可能会遇到数据破坏或泄漏。若执行了上述步骤，那么您即可很好地认识到哪些数据是关键的，哪些不是。您还会知道您必须遵守哪些法规，让用户了解数据(比如个人信息)是不是已经泄漏，并能依据约束您的应用程序的法规(比如 HIPPA 或 PCI)来进行响应。有了这些总体指南和对云的共享风险模型的理解，您现在已经很好地了解您需要保护什么了。接下来，我将介绍各种级别的加密方法和保护应用程序端点。

　　使用中的数据

　　通常我们很少对使用中的数据进行加密。这主要是因为，拥有或能够控制自己的数据中心的组织认为没有必要这样做，他们认为这些数据中心是安全的。因此，在服务器运行时，没有人能够轻松地访问它并检查其 RAM 中的未加密数据或实际的加密密钥。对于基于云(如阿里云)的应用程序，您无法确认您应用程序所在的系统的物理完整性。使用中的数据的加密迅速变得十分重要。的确如此，2012 年以来，云安全联盟就开始推荐将加密使用中的数据作为最佳实践。

　　目前，没有 IaaS 或者 PaaS 供应商提供对使用中的数据的加密，但 PrivateCore 和 Vaultive 等公司提供了支持您所选的云环境中正在使用的数据的系统。对于大多数云感知应用程序，使用中的数据很可能被过于重视，但是对于拥有受犯罪组织和国家行为者攻击的风险很高的组织而言，这应该是一个严肃的考虑因素。从某种程度上讲，这是因为一些攻击者专门使用为从 RAM 中提取加密密钥或数据流向而设计的技术。

　　活动数据

　　一般而言，在任何您的应用程序需要发送或接收敏感数据时，您都希望不仅加密发送的数据，比如文件，还要加密通信/数据传输。例如，若您的网站接受客户信息或者信用卡，您应确保这些通信是加密的，因为这些数据会通过用户的 Web 浏览器传输到您的云应用程序。在这种情况下，您需要使用 HTTP Secure 协议(HTTPS)，而不是 HTTP。HTTPS 使用了 SSL/TLS，后者是一个加密活动数据的协议。其他互联网协议可使用 SSL/TLS 来加密活动数据，而且在云感知应用程序中，最佳做法是尽可能地在每个服务之间及系统与应用程序之间创建虚拟专用网。这会减少攻击者损坏您系统的某部分并能够从剩余部分收集数据的风险。您应该使用信誉好的 SSL 证书来保护活动数据。若您不熟悉 SSL，请查阅来自开放 Web 应用程序安全项目 (Open Web Application Security Project) 的优秀的 SSL 介绍(参见 参考资料)。

　　最后，许多组织会犯只信任 SSL，而不使用静止加密的错误。这是一个巨大的错误。有许多利用 HTTPS 会话的途径(尽管可能很复杂)。这是由于软件及其 SSL 实现中糟糕的配置、设置或底层缺陷，比如我们在 Heart Bleed 错误中所看到的。出于这个原因，在网络上传输敏感数据之前以及在您传输敏感数据时，尽可能地加密它非常重要。

　　保护端点

　　云感知应用程序的另一个最主要特征是 API 的使用，无论是在内部和外部，都使用了 API 来设计灵活的、敏捷的应用程序。尽管许多开发人员忽视了这一步，但使用 API 时或将任何端点包装到一个高度抽象的 API 中时对端点加以保护，是一种最佳实践。原因在于，恶意的行为者通常采用拒绝服务攻击(DoS)的形式攻击没有安全保护的端点。更加机智的攻击者会利用端点上薄弱的授权来盗窃数据，或以难以预料的方式操作应用程序。因此，所有端点都应该采用某种形式的授权机制来加以保护，比如 OAuth 或者 SAML。您还应能够按地区或 IP 子网来限制访问，并记录系统或用户对您 API 的访问。

　　结束语

　　开发安全、云感知的应用程序是一个复杂的主题，会受到您的业务需求和监管环境的具体情况影响。尽管如此，我们提供了一些重要的建议，它们应该可帮助您开始生成策略来保护您的应用程序，部署加密，使用访问控制，及保护您的端点。我还展示了一些加密数据的最佳实践，提供了一些资源来帮助您创建一个实施云感知安全最佳实践的计划。参考资料部分提供了针对云感知应用程序的最佳实践的更多信息