云堆栈安全：探究云VM风险场景

“云”通常是一个模糊的术语，不完全会打包到和企业级云计算工作相关的内容中;企业员工可能在云端存储文档，但是关于底层技术如何实现的这项工作，他们知之甚少，也不关心这样做是否安全。

本质上，所有的云计算服务由一个“堆栈”组成，可能包括硬件资产(服务器内存、CPU、磁盘)、运行在硬件上的虚拟化技术、网络组建(包含物理和虚拟的)、额外的计算和编制软件、大规模存储和虚拟机(VM)或者应用和软件实例。

尽管这个广泛的技术集在计算功能上打开了一个充满机遇的世界，但是企业必须知道因为这些技术进行交互的途径以及经常在云计算客户之间共享的特性，云堆栈中会出现漏洞。比如，多用户系统中，应用和数据托管在公有云或者商业云环境中(就像是在相同的物理平台上)，制定合适的隔离、分段以及虚拟系统和数据之间的访问控制都是最基本的。

在任何hypervisor中，都可以托管若干VM。在一个私有网络或者私有云中，内部分段(或者甚至是在不同物理主机上物理分离的)都可以轻松维护。然而，在云环境中，内部安全团队不具备基础架构(公有云和混合云部署)的控制权限，多个组织的VM和数据运行在同样的物理平台上就会存在风险。此外，管理和hypervisor中所有活动的监控都至关重要，尝试和追踪其他用户的VM需要被检测到(或者阻止)，迅速防止问题发生。

为了获取更好的云堆栈安全漏洞理解，我们来看一下可能在不同云模型中受到的各种威胁。

IaaS和PaaS威胁

在基础架构即服务(IaaS)模型中，整个VM可以在多租户环境中托管，这意味着攻击者可能在相同的环境中创建恶意的VM。MIT的研究员透露了定位亚马逊云中具体物理云服务器的方法，可能很多其他的提供商的环境也是如此。这是一种相当具有创新性的攻击，允许攻击者通过具体的受害VM行为属性，精确到其贮存的物理服务器。通过所获取的信息，攻击者能够上传和运行恶意的VM，随后可以用于执行数据盗窃攻击和其他的攻击。

2013年十一月，一群研究员在演示可行的“边信道”攻击对阵运行在相同的hypervisor平台上的VM时，曝光了另外一种IaaS模型中潜在共享技术漏洞。在这种攻击中，VM溢满本地硬件缓存，导致目标VM自己重写一些数据。基于这些写入的数据，以及其写入方式，攻击者可以识别出这个目标VM的各种信息，包括隔离使用的加密秘钥以及其他的加密功能。虽然这种类型的攻击可能难以在云端实现，但是演示显示了企业云计算多租户环境多么容易受到攻击。

平台即服务(PaaS)环境能够一起运行所有的VM，但是客户对于其配置也缺失了控制;导致他们没有能力创建单独的VM，攻击者可能不能在IaaS环境中创建恶意VM。这并意味着PaaS模型没有云堆栈漏洞，因为其他的共享组件会招致风险，比如存储和API。在API的情况中，数据可以以非加密的形式转换，或者在有缺陷的授权中实施。

至于存储(有些可以影响所有的云模型)，关键的风险在于缺少客户数据之间的隔离。2012年四月， Context信息安全的研究员表示他们能够从数个云提供商处下载自己的VM磁盘文件，在进行刑侦分析后，断定其他客户的数据也呈现在其中。原因何在?因为提供商没能在多租户环境中隔离和清洁存储空间。

如何管理云堆栈风险

那么企业如何能够对抗共享技术带来的威胁呢?首先，必须理解有多少种实际的风险，包括上面提到的这些以及其他的风险。比如，“VM逃脱”和hypervisor妥协场景类似于经常探讨的Blue Pill，但是实际生活中这些威胁的发生概率比较低。同样的，实施边信道攻击的协调、环境知识以及所需技能极为超凡，目的就是为了获取共享存储缓存的加密密钥，因此这样的威胁在大多数云环境中可能不会发生。

话虽如此，但是企业还是必须有合适的预防措施，确保云堆栈的安全。加密敏感数据和VM组件是很多这种威胁的有利威慑。从内在来看，虚拟化平台支持内置分段和隔离，很多更是芯片级的。此外，网络和托管的访问控制可以在物理和虚拟网络层实施，在VM本身中也可以。 Hypervisor的访问控制也必须考虑在内，攻击者获取了hypervisor的控制或者其管理平台的控制也是毁灭性的。

大多数企业的关键在于直接询问云提供商关于其安全实践的问题，尤其是如何锁定hypervisor或者堆栈中的其他层。此外，找出最适合的访问控制，阻止恶意访问，从而管理和编制应用。比如，应该包括用户账户和群组管理、密码和多因子认证策略和时间，以及更加健壮的身份识别管理工具和流程。