Lars Kurth 谈开源安全流程之三：开源安全实践 vs 云时代的挑战

【编者的话】随着云平台的日渐流行，其面对的安全问题也越来越严重。 Xen Project 的顾问委员会主席 Lars Kurth 近日分享了其对开源安全流程的理解和看法。作为该系列文章四部分的第三篇，本文介绍了若干开源项目以及它们利用云计算进行安全实践的方法，而且讨论了开源安全实践是否适合当今的云时代。读者可阅读《第一部分：云安全介绍》和《第 2 部分：容器 vs 虚拟机管理程序—保护您的受攻击面》来了解前两篇文章的内容。

当今绝大部分软件栈都包含了很多不同的层。而在一个层化的软件栈中，人只是其中最弱的一环。由于多个不同的开源项目中的安全漏洞进程并不完全兼容，处理安全问题时真的有可能出现错误。

在云计算中，开源项目处理安全问题一般有两个方法：“全公开”（Full Disclosure）和“负责任公开”（Responsible Disclosure）。这两种方法都是安全漏洞管理流程（Security Vulnerability Management Process）中能够帮助迅速解决安全漏洞的最佳实践。值得注意的是，有关这些流程的争论从来没有停过。本文就这些流程的历史、当今的开源技术是如何利用这些实践的以及他们是否适合云环境等问题进行了讨论。

首先，“全公开”和“负责任公开”这两种流程的区别主要体现在：

• “全公开”采用尽可能早的公布软件漏洞相关的分析的方式，使得任何人都可以自由的访问这些数据。广泛散播有关漏洞消息的初衷在于，漏洞的可能受害者与攻击者能够掌握同样的信息。
• “负责任公开”则对于掌握漏洞信息的人群进行了限制，也是目前云编排栈中绝大部分开源项目所采用的方式。该进程十分直接：谁发现问题就和项目的安全团队进行合作，评估并修复该问题。然后，那些开源项目的特权客户就测试并准备软件包来修复漏洞。一旦任何相关的安全问题被公开，这些软件包就被发布给广大用户，修复漏洞。“负责任公开”所采用的基本工作流和步骤如下图所示。

(点击放大图像)

尽管具体细节有些不同，这两种进程都非常鼓励安全问题的发现者能够将其发送到相关项目安全团队的邮箱，而不是出售或自己使用来获得非法利益。此外，他们的目的都是尽可能快的修复安全问题，并确保从发现问题到应用修复补丁中间的时间尽可能的短。最后，二者都是试图保证绝大部分用户能够尽可能快的应用补丁包。

在云中处理安全问题有何不同？

尽管绝大部分云项目的安全实践都准守上图中的基本架构，他们之间仍然有一些明显的不同之处：

• 是否所有的漏洞或一些漏洞采用“负责任公开”方式；
• 在一个漏洞被公开之间，优先收到通知的用户（特权用户）列表；
• 判断一个用户是否在优先通知的邮件列表中的标准；
• 决定一个用户是否在优先通知的邮件列表中的应用进程；
• 特权用户列表是否被公开？
• 在收到安全问题的通知后，特权用户所能采取的行动；
• 从发现安全问题到通知特权用户的典型时间间隔；
• 从发现安全问题到通知所有用户的典型时间间隔；
• 项目发布安全问题的方式；
• 是否 CVE 号应用于所有或者一些安全问题；
• 是否存在一个专门的地方展示以往的安全问题；
• 是否安全问题可以在代码提交或其他项目部门中被追踪。

绝大部分的不同都可以根据开源项目的操作执行效率、对于整个社区的公平性、信息的透明程度以及项目安全进程的操作等进行分类。尽管这些区别看起来有些脱离基本的流程，每一个不同都对云项目的用户有着巨大的影响。

“负责任公开”的 Distro 模型和云模型

首先，考虑两个典型的问题：哪些用户应该成为特权用户，特权用户在收到预先通知后能进行哪些操作。这两个问题和安全漏洞管理流程的目标紧密相关：

• 确保问题公开之前修复方案已经准备完毕；
• 确保下游的项目和产品能够在其环境中应用并测试修复方案。

在著名的负责任公开的 Distro 模型（“Distro Model of Responsible Disclosure”）中，只有创建上游项目版本的厂商才能成为特权用户。这些用户所提前收到的信息也只能被用来提出和测试修复方案。

由于该模型不允许使用开源软件的服务提供商马上开始计划升级方案，托管、云服务及其用户在安全问题公开后马上就会面临安全威胁。而且，在禁令结束前，该模型不允许使用软件的服务提供商部署升级。

为了使得安全流程能够更多的满足云计算的需求，Xen Project 首先采用了一种新的安全漏洞流程——负责任公开的云模型。在该模型中，共有云服务的提供商也成为了特权用户。而且，用户预先收到的信息可以被用于计划设计方案、通知客户或者部署升级。 OpenStack 也提出了类似的模型。

云项目安全实践概况

下表列出了不同开源项目所使用公开安全问题的方法。

尽管 Linux 的不同版本长期以来都遵守负责任公开的方式，一个超级复杂而又很难理解的网页负责处理 Kernel 和 Distro 安全的不同方面：

• Kernel 安全：处理 kernel 安全问题，目的在于尽可能快的修复并公开安全问题。
• OSS 安全：公开的列表，其初衷在于讨论和处理已经存在的弱危险性安全问题。
• OSS 安全 Distro ：私有邮件列表，其成员局限于操作系统版本的安全联系人。采用负责任公开的方式，初始用于处理中高危险性的安全问题。
• 此外，每一个 Linux 版本都拥有自己的安全团队，采用一个或多个上面的方式来处理安全问题的不同方面。所有软件包的安全问题会形成一个独立的版本。

结论

尽管云计算已经普遍存在，目前的绝大部分开源项目仍然遵循着负责任公开的 Distro 模型。此外，CoreOS、Kubernetes 以及 Cloud Foundry 等很多新的开源项目也只局限于让发现者报告安全漏洞问题。这反映出，很多开源软件项目的成员首先关注的代码开发，然后才会考虑到安全问题。

当今绝大部分软件栈都包含了很多不同的层。而在一个层化的软件栈中，人只是其中最弱的一环。由于多个不同的开源项目中的安全漏洞进程并不完全兼容，处理安全问题时真的有可能出现错误。解决该问题的唯一途径就是建立一个全兼容的、工业界普遍采用的、考虑到云和服务提供商需求的最佳实践。

编后语

《他山之石》是 InfoQ 中文站新推出的一个专栏，精选来自国内外技术社区和个人博客上的技术文章，让更多的读者朋友受益，本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。

感谢董志南对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。