正如目前大多数安全专业人士所知道的那样，确保企业云计算应用的安全性可是一个相当大的挑战。因为云计算数据安全事件会出人意料地出现，安全团队往往只能在事后了解云计算服务实施。虽然安全管理员们一直在呼吁，但是业务压力让额外安全控制的实施变得极具挑战性，因为企业高管们非常讨厌看到预估的成本节省被逐渐的蚕食掉，这一点也是可以理解的。

当谈及在云计算环境中确保数据安全性的具体问题时，这一挑战也变得更加复杂了。这是因为云计算的主要优势之一就是数据的可用性，尤其是云计算能够承诺用户可通过多个设备和在不同的地理位置实现对数据的访问。对于可用性的担忧是源于云计算数据安全性的措施（例如那些失效的控制），这种意想不到的担忧往往会引起企业的警惕。因此，看到诸如佐治亚理工学院的近期报告、2014新兴网络威胁报告中的相关数据也就不会感到惊讶了，这些报告均指出企业过于依赖云计算服务供应商（CSP）所实施的安全措施，而不是建设他们自己的安全团队。

事实上，“自管理”的数据保护机制可以是相当有益的。根据定义看，自管理意味着是由云计算客户自己实施、维护和控制针对数据本身直接运行的控制措施。在实际情况下，这一机制通常是指数据加密（假设客户拥有密钥），但是在这样的环境中，它也可以指标记化的场景或者甚至是某些访问控制措施（虽然，这当然是受到实施方法限制的）。通过使用这些机制，客户不仅能够在CSP发生安全故障时把他们的数据与CSP隔离开来，而且当有数据表明云计算环境中某种风险的威胁有所降低时还能进一步加大云计算化，从而实现两全其美的便利。它有助于增加针对某些攻击的抵抗力（由于CSP的规模经济而成为可能）而无需牺牲对于不需要的数据扩散的“点控制”。

那并不是说每一个企业环境都需要这些自管理的控制措施。但是，就目前这种情况而言，企业也不是一定需要它们，真正了解应何时使用自管理控制措施才是合适的将能够帮助企业在未来确保即将出现的使用场景的安全性。

额外云计算数据安全措施的价值

要研究为什么可能需要额外的数据保护这样一个命题，首先就会要求使用者理解问题中CSP的安全环境基线，以及在企业中是如何使用服务的更多详细信息。不管你信不信，这两方面的知识并不总是已知的；由于在部署前缺乏审批所需的时间或资源，因而也就限制了CSP们对适宜安全机制知识的掌握，而影子IT的实施和部署后扩散的使用将使继续使用服务变得更为困难。

首先，了解CSP趋向于开发一个满足他们用户大部分需求的安全环境是非常重要的。众所周知，对一个对象（即便可能是大多数）有用的东西并不会是解决所有问题的万能钥匙，这很可能就意味着对于特定组织（但并不为大多数组织所需要）有重大意义的安全措施并没有被囊括在产品中。不过，请务必与CSP确认，因为你所需要的服务有可能是需要支付额外费用的。

其次，了解CSP的支持经济性也是很重要的。CSP们并不是都可以以一个经济的方式来支持每一个好的安全措施。虽然CSP们事实上是能够高效地为一个特定客户提供一些遥不可及的服务（再一次是因为规模经济），但还是有一个必然的限制的。具体而言，如果一个功能无法实现规模缩放，那么服务供应商就无法较为经济地维持包括这个功能的默认服务了。再次重申，这并不排除一个客户自行实施该功能的情况或者一家CSP以额外的费用提供这一功能的情形。

最后，还有一个关于使用的注意事项：一个云计算客户也应承担某种责任以确保服务被安全地使用和运行。例如，在Facebook上使用管理员密码将远胜于一个供应商所能够添加的任何安全措施。

问题的关键在于，企业可能会有一万个好理由来决定实施超过他们供应商所提供默认产品的额外控制措施。但是，并不是每一种情况都需要这样做的。这就是企业使用知识的用武之地了。就如同一个内部技术部署一样，一家企业必须对其实施方法和风险进行综合评估。这种做法听上去很熟悉？它确实是相同的。这就是安全专业人士几十年以来一直都在做的工作：风险管理。
在云计算数据安全的情况中，风险管理没有太大的不同。使用决定着可能存在有哪些威胁以及对一个开发的各种影响。在供应商的协助下检查这些项就能够突显产品与客户需求之间的差距。为了弥补这些差距，企业可能会希望对额外的保护措施和控制策略进行评估。

例如可以考虑这样一个情况，即使用云计算爆发以支持企业月底业务高峰期的额外容量或者计算资源需求。在这种情况下，使用率（处理重要财务记录或会计应用程序的额外资源）可能会决定是否需要额外的保护（即超出一定需要的额外访问控制，而在一些低敏感度的用例中这样的访问控制就已经很合适了）。

实施方案选项

如果在进行应用评估之后，用户会很明显地发现必须实施额外的安全措施，那么企业就必须弄明白应在何处添加这些安全措施。虽然这是一个必须回答的复杂问题，但是企业还应当在把数据迁入云计算之前确定数据的位置。这样做有几个好处。其中一点就是，这个方法是可行，但是一旦数据到达供应商处用户就失去这样做的机会。

回想一下，从客户的角度出发，云计算中底层技术的实施是不透明的。毕竟，应用程序堆栈是位于客户直接控制的范围之外的，而如果你正在使用软件即服务（SaaS）、平台即服务（PaaS）或基础设施即服务（IaaS），那么应用程序堆栈正是你或多或少的依靠。例如，在数据于首选位置进入应用程序堆栈之前通过加密技术运行数据本身就意味着无论之后会发生些什么（即使用率变化，而数据保持加密状态）数据都已处于受保护状态。将这种方法与在操作系统级别（例如在IaaS中）或者应用程序中（在PaaS中）实施的数据加密进行比较。在这些应用场景中，如果之后的使用率发生了变化，那么企业将需要重新执行这些实施。但是，如果事先数据是被加密的或者经过标计化处理的，那么就可能不必这么做了。

需要注意，这一实施将根据云计算部署类型的不同而有所区别。例如，一个SaaS的云计算部署可能要使用代理技术以便于把安全措施“注入”应用程序流（如以一种应用程序无关的方式对数据进行加密或者标记处理）。此外 ，如果它们可用，你就可以充分利用“回调”SaaS供应商提供的应用程序编程接口以便于通过网络服务队数据进行加密操作（请注意，这要求SaaS服务供应商提供积极的支持）。

问题的关键在于，云计算客户是有多种选择的。虽然并不是每一个云计算用例都要求（或者每一个客户都需要或希望）额外的自管理数据保护管理措施，但是它对于某些云计算实例还是非常有用的。相关数据表明，自管理控制措施既没有得到较好的实施，也没有得到充分地运用，这一事实说明这一领域仍是大多数云计算客户希望认真思考的范畴。