上个月，我们探索了利弊开源的OpenStack，一个平台，我固然喜欢，但并不意味着每个人的（在那个岗位奠定了原因）。今天的话题转移到OpenStack的安全性。为什么安全？因为安全性不仅是热媒介话题，也是一个可以自动迫使CIO / CTO组织内的分析自己的安全局势。是您的开源OpenStack的网络安全吗？
OpenStack的是一个框架，有一个快速，自我服务的方式提供基础设施资源，以消费者（开发商，最终用户，业务单位）的一个崇高的目标。这一独特的，自我服务的方面是什么使这个平台如此受欢迎。对安全的需求与OpenStack的，但是，没有得到解决，直到很久以后，之后它已成为一个明显的问题在内部。这是一个典型的技术亡羊补牢 - 牺牲速度和效率的安全性。
虽然我在安全深通，我没有一天到一天专家对此事的。这就是为什么我决定在安防行业的意见领袖和主题专家的形式，一些援助使这个职位科瑞Nachreiner公司首席技术官在Watchguard的。因此，事不宜迟，这里是我Q＆A关于OpenStack的安全性Nachreiner：
哪些漏洞在开源的OpenStack目前存在吗？总之，OpenStack的是相对较新的代码。它肯定包含了很多软件的漏洞和执行问题，社区将继续发现随着时间的推移。好消息是OpenStack的社会似乎是采取安全重视，与门户及旨在解决安全问题迎面项目。另外作为一个开源的产品，任何人都可以跟踪开源软件漏洞这里的基础上，公共漏洞和暴露（CVE）。
在最高级别的，不过，各种普通和实施基于漏洞可能确实存在。例如，使用明文密码等一些认证文件，或明文RPC通信。你也可以推出基于OpenStack的组织的配置漏洞。此外，开栈依赖于其他组件。因此，举例来说，如果您的团队使用的是旧版本的OpenSSL从心脏出血漏洞，或其他类似的SSL漏洞遭罪，你的组织的OpenStack的实施可能会受到影响。
是否OpenStack的安防工程妥善应对威胁和准备及其用户群的？我相信它。最起码，这组解决安全头，并为社会共享程序的方式报告漏洞所以他们得到固定。我也认为，安全指南是一个伟大的工具，承认一些围绕实现OpenStack的安全问题，并帮助其用户以最安全的方式尝试部署。
OpenStack的用户应该如何跟上新出现的威胁？Security.openstack.com，社区的安全门户网站，可能是留了解最新的最好的地方漏洞笔记， 要么公告。这个页面将确保用户了解最新的安全补丁。这些开发类型真的想保持领先的曲线，实际上可以遵循一些CVE-相关的错误对发射台，或者干脆加入OpenStack的邮件列表。
是周期时间以备将来的OpenStack平台的改进移动速度不够快，以跟上新的安全问题？这很难说，因为它是一个相对较新的项目。然而，基于OpenStack的安全项目，并详细漏洞处理过程，甚至它的安全指南，我认为OpenStack的正在以确保平台尽可能快，因为它可以尽最大努力。这就是说，公共云和混合云计算的复杂性，它引入了交互技术的许多层，是对安全问题如此迅速发展的原因之一。这些复杂的技术，这往往弥合信任域之间的分离，引入许多难以解决的安全问题。
纵深防御：有多深（层，工具，技术）应在CTO / CIO考虑去？虽然OpenStack的是“云”计算平台，但它仍然可以帮助企业管理真实服务器实际存在的地方，并把在真实的网络流量。总之，一个技术主管还应该深入考虑充分辩护，全部采用正常的相关安全控制（防火墙，IPS，反恶意软件，WAD）。在某些情况下，甚至的OpenStack提供的API，可以帮助你申请传统的安全控制使用这种新的云模式（如网络通过网络API IPS）。您的图像和物理服务器仍然需要保护 - 现在用户还需要确保的OpenStack软件的更新和妥善保养。在我看来，OpenStack的不会删除任何攻击面（物理和虚拟机还是有自己的缺陷）;它只是引入了新的攻击面的潜力。
四个领域 - 云的OpenStack：公众，访客管理和数据网络 - 够了吗？These four domains are OpenStack’s way of discussing how its own modules interact, and sometimes bridge domains, but a CTO/CIO can’t forget there are many other systems interacting with the OpenStack platform as well — the physical machines, the virtual images, the hypervisor, the software running on individual machines, etc. The Cloud Security Alliance (CSA) has something called the Cloud Controls Matrix, which offers 16 domains that cloud providers need to consider to create a secure environment. Whether or not users are implementing OpenStack securely, they need to consider all these domains, and their full environment.
考虑哪些因素应该漏洞度量和跟踪被采用？总之，用户需要定期审核制度，设定的时间表，以查找漏洞。确保根据严重性优先考虑他们，但也现实世界的影响。例如，存在其中的漏洞可能有严重影响的案件，但在你的公司实施它不是很容易被利用。这些情况可能不支持高优先给你的团队。最后，跟踪时间关闭或减轻该漏洞。你的团队应该更快地在一段时间内关闭高优先级或严重的漏洞。
有你有它。开源的OpenStack是，在我看来，一个了不起的平台，在企业领域吨的潜力。如同所有的新技术平台，但是，第一个问题，每一个CTO / CIO应该问问自己之前实施的，“我如何安全可以使这个网络呢？”数据泄漏被以惊人的速度发生。保护这些数据应该是每一个技术主管的首要任务，但当时并不是所有的CTO / CIO类型安全专家。由于人们喜欢Nachreiner，他们并不需要的人。