开发具有有效安全性的软件的最佳方法

Casey 将于 10 月 4 日在 柏林 LinuxCon 大会上发表演讲。

无论您在哪个级别进行编程，安全性都会成为障碍。 无论采用多少应用程序抽象或现代开发流程，似乎都无法保护开发人员免受安全性设置的障碍。 当安全性似乎没有增加任何内在价值，并且经常妨碍提供令人愉悦的用户体验时，很难不讨厌安全性。 更糟糕的是，尽管您尽一切努力使您的产品安全，但产品仍然可能被黑客入侵。

12472 号行政命令

为了理解为什么安全性会对开发人员造成如此大的阻碍，我们需要回顾一下 1984 年 4 月美国政府发布的 12472 号行政命令。 该命令规定了美国政府购买的所有计算机的安全功能和流程标准。 特别是，它规定了基于 David Bell 和 Leonard LaPadula 工作的安全策略模型，他们受命创建美国国防部纸质标记方案的数学模型。 当时编写了 UNIX 系统的描述，以解释它们如何符合 Bell & LaPadula 术语。 这些描述已被沿用到当今 Linux 系统的基本安全模型中。

这意味着今天我们使用的安全模型最初旨在保护共享超级计算机上用户的数据不被该机器的其他用户访问，而我们现在使用相同的模型来保护从自动驾驶汽车到智能灯泡和基于云的数据中心的一切。

开发过程保证

12472 号命令包含的另一个安全方面是开发过程保证。 程序不仅必须证明它们可以完成它们应该完成的工作，而且还必须证明它们不会完成它们不应该完成的工作。 12472 号命令要求详细描述用于进行这些保证的步骤。 成熟的过程被认为是好的，而轻量级的过程被认为是危险的。 在 1984 年安全模型的框架内，现代开发实践被视为灾难的根源。 考虑到所有这些，大多数开发人员都想远离安全也就不足为奇了。

使安全性透明

当今许多安全机制背后的理论都涉及使安全性透明。 沙箱、容器和其他现代安全机制创建了一个抽象层，将所有人与安全策略的细节隔离开来。 虽然这实现了程序隔离的既定目标，但它使信息的合法共享变得更加复杂。 在适当的粒度级别控制共享是安全中最困难的部分，这也是我们问题的根源。

尽管为实现透明性做出了这些努力，但开发人员仍然经常发现安全要求将他们逼到了死角，没有简单的出路。 幸运的是，开发人员有一些思考和处理安全性的方法，这样安全性就不会破坏他们的产品、用户体验或计划。

开发团队可能犯的最大错误是将安全性与他们对待其他需求的方式区别对待。 正如期望在所有代码完成后才调整性能问题的产品团队将不可避免地创建充满性能问题的软件一样，期望在发布前才开启安全系统的产品团队将会得到一堆不再起作用的冒烟技术。 为了避免这种命运，开发团队必须将安全性视为软件规范、设计和实现不可或缺的一部分，并应在开发过程的早期就包含安全性。

同样重要的是要确定项目的安全问题最初出现在哪里。 有时，最大的安全问题是制度性的，当开发团队试图遵守其上级组织规定的接口或程序时，这些接口或程序可能对开发人员的特定情况没有意义。 其他时候，安全问题来自糟糕的技术选择，例如在 Web 浏览器上运行的 JavaScript 中实现复杂的安全协议。 问题经常来自于选择与代码将要运行的环境无关的安全机制。

采取哪种方法？

最终，开发人员在处理安全性时有一些基本选择。 您可以采取传统的宣泄方法，继续讨厌它并责怪它对您试图完成的工作产生任何影响。 您也可以采取一直流行的忽略安全性的方法，这种方法出奇地具有成本效益。 或者您可以将安全性作为您的首要任务来接受，但这很少是一种制胜策略，因为它成本高昂且对用户体验和性能有影响。

但是，完成安全流程的最佳方法是在产品规范、设计和实现中尽早地与其他基本要求一起包含安全性。 虽然这看起来可能不方便，并且在某些情况下可能需要一些再培训（特别是安全开发人员，他们可能不知道发生了什么），但这是开发具有有效安全性而又不会对开发过程造成不必要阻碍的软件的最佳方法。