Openstack安全更新的流程和机制

VMT (Vulnerability Management Team)

这个团队主要负责处理openstack的安全漏洞，并负责制定相关的流程。我的理解是VMT其实是一个QA+ Release Management团队，主要从流程上确保安全漏洞能够被合理的处理。

OSSG (Openstack Security Group)

这个团队旨在完善Openstack的安全性，包括代码，架构，文档，第三方组件安全建议等。如果OSSG发现了安全漏洞，需要将该漏洞转交给VMT，而VMT需要从流程上保障该漏洞的处理和发布； 期间，VMT会要求OSSG帮组评估和解决漏洞。这个团队最近一个很瞩目的成果是发布了Openstack Security Guide. 我个人理解是这个团队主要负责技术执行，差不多是一个Development Team。

OSSA (Openstack Security Advisories)

OSSA负责为OSSG提供Openstack的Security Advisories, 即Openstack自身安全漏洞的解决办法，通常情况下，一旦OSSA的安全漏洞被确定，都需要发布一个跨版本的补丁。

一般来说，Openstack官方一般会维护两个稳定版本(当前是G和H)和一个开发版本(当前是I), 并同时为这些版本提供安全补丁, 为了提高系统安全性，一旦官方发布了OSSA, 维护人员应该及时应用这些补丁，确保这些安全漏洞不会被黑客利用。

OSSN (Openstack Secuirty Notes)

和OSSA不同, OSSN负责为Openstack所以来的常用第三方组件提供安全建议，因为这些组件不是Openstack维护，比如Mysql最近某个配置导致一个严重安全漏洞，那么OSSN可能会发布一个文档，指导维护者绕开或者不要使用这个配置。OSSN好像成立的时间不是很久，下面是到目前为止已经发布的OSSN:

https://wiki.openstack.org/wiki/Security_Notes

总结

1. Openstack官方一般会通过mailist和wiki不定期发布稳定版本的OSSA和OSSN，作为系统管理员需要及时更新系统，保证这些漏洞不被利用；
2. Openstack目前稳定版本的生命周期一般少于2年, 比如F版本，2012.2 - 2013.11, 和成熟的系统相比（Linux LTS一般5年以上），有较大差距。一旦版本EOL, 从安全性出发，需要考虑向第三方购买安全服务或者是升级到高版本。

参考资料

• Openstack Security Wiki
• Openstack Security Guide
• OSSA@Launchpad
  
• OSSN@Launchpad
• Openstack Releases

Openstack安全更新的流程和机制,布布扣,bubuko.com

Openstack安全更新的流程和机制

原文：http://blog.csdn.net/cloudresearch/article/details/22901985