软件开发安全性

Casey将于10月4日上 。

无论您进行编程的级别如何，安全性都将受到阻碍。 似乎没有多少应用程序抽象或现代开发过程能够使开发人员免受安全性带来的障碍。 当安全性似乎并没有增加任何内在价值时，很难不讨厌它，并且常常会妨碍提供令人愉悦的用户体验。 最重要的是，尽管您为确保产品安全所做的所有工作，产品仍然可能遭到黑客入侵。

行政命令12472

要了解为什么安全性会对开发人员造成如此大的阻碍，我们需要回到1984年4月开始的美国政府执行命令12472。该命令规定了美国政府购买的所有计算机的安全功能和处理标准。 尤其是，它基于David Bell和Leonard LaPadula的工作，要求建立一个安全策略模型，后者被特许创建了美国国防部纸质标记方案的数学模型。 编写了当天UNIX系统的说明，以解释它们如何与Bell＆LaPadula术语保持一致。 这些描述已被带入当今Linux系统的基本安全模型中。

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

开发过程保证

Order 12472包含的安全性的另一个方面是开发过程保证。 程序不仅必须证明自己做了应该做的事情，而且还必须证明自己没有做应该做的事情。 订单12472要求详细说明用于做出这些保证的步骤。 成熟的过程被认为是好的，而轻量级的过程被认为是危险的。 在1984年这种安全模型的框架内，现代发展实践被视为灾难的良方。 考虑到所有这些因素后，大多数开发人员都希望与安全性保持距离，这不足为奇。

使安全透明

当今许多安全机制背后的理论涉及使安全透明。 沙箱，容器和其他现代安全机制创建了一个抽象层，该抽象层使其他所有人免受安全策略细节的影响。 尽管这实现了程序隔离的既定目标，但使合法的信息共享变得更加复杂。 在适当的粒度级别上控制共享是安全性中最困难的部分，这就是我们出现问题的地方。

尽管为提高透明度做出了这些努力，但是开发人员经常发现，安全性要求已使它们陷入困境，没有轻松的出路。 幸运的是，开发人员有多种方法可以考虑和采用安全性，以使安全性不会破坏其产品，用户体验或时间表。

开发团队可能犯的最大错误是，与对待其他需求的方式不同。 正如一个产品团队希望在完成所有代码后解决性能问题一样，不可避免地会创建出充满性能问题的软件，就像一个产品团队希望在发布之前打开安全系统一样，将拥有大量的技术。不再起作用。 为避免这种命运，开发团队必须将安全性视为软件规范，设计和实施的组成部分，并应在开发过程中尽早包括安全性。

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

采取哪种方法？

最后，开发人员在处理安全性时有一些基本选择。 您可以采用传统的宣泄方法，并且继续讨厌它，并指责它对您要实现的目标产生的任何影响。 您也可以采用流行的方法，即忽略安全性，这出乎意料地具有成本效益。 或者，您可以将安全性作为第一要务，但是由于其高昂的成本以及对用户体验和性能的影响，这很少是一个成功的策略。

但是，完成安全性流程的最佳方法是在产品规格，设计和实施的早期阶段以及其他基本要求中包括安全性。 尽管这看起来很不方便，并且在某些情况下可能需要重新培训（尤其是对于安全开发人员，他们可能不知道会对他们造成什么打击），但这是开发具有有效安全性而又不会给开发过程造成不必要障碍的软件的最佳方法。 。

翻译自:

软件开发安全性