在 DevOps 周期中的哪个环节进行安全防护？

有时，标题会直接给出答案。 我是搞安全的，所以这个问题对我来说很容易： “在 DevOps 周期中的哪个环节进行安全防护？”的答案是“每个环节”。 但是，几句话写不出很有说服力的文章，所以我会更详细地说明。

这个问题真正意味着什么？

在瀑布项目的“美好旧时光”¹中，通常的做法是尝试在流程的最后，也就是部署或发布之前，将安全措施添加到项目中。 没有人认为这实际上是好的做法，但这种做法太常见了——对于那些至少关心安全性的项目来说。

问题是，当您进行 DevOps 时，没有“部署之前”。 您始终在部署，那么您需要在什么时候进行安全防护？ 正如我上面所建议的那样，答案是“每个环节”。 但是，我们只是绕了一圈，没有提供太多额外的信息，所以让我们把事情分解一下。

当我们想到 DevOps 时，我们会认为这是一个持续的过程——无论我们脑海中的图像是一个圆圈还是一个无限符号的数字 8——我认为，没有哪个部分我们不应该“进行安全防护”。

• 在设计时，安全性应该是您需求的一部分。
• 在编码时，您应确保遵循正确的编码准则。
• 在测试时，应该有单元测试来涵盖安全用例。
• 在部署时，您应该确保部署了正确的密钥并得到充分保护，并且您的工作负载在正确的主机上执行。
• 在运行时，您应该监视是否发生入侵。
• 等等...

请注意，在上面的列表中，我选择了来自 DevOps“堆栈”不同级别的示例。 编码准则与产品无关，而是与您如何制造产品有关，这与工作负载监控不同。 单元测试的操作级别与工作负载放置和调度不同。 这告诉我们，在 DevOps 世界中，需要在整个过程中的多个不同级别考虑安全性。

“在哪里”的问题还是“谁”的问题？

如果第一个问题的答案是“每个环节”，那么您的团队可能会意识到一个可怕的事实：如果安全无处不在，那么每个人都应该负责。 当然，这是事实，但这并不意味着您想象的那样：每个人都需要突然成为安全专家²。 相反，这意味着每个人都有责任遵循安全流程。 那么，谁来制定这些流程，它们看起来像什么？

首先，不要假装会有一个“安全大师”了解您正在运行的所有项目和产品的所有 DevOps 堆栈的所有部分。 会有不同的人：例如，一个人决定应该使用什么容器镜像，另一个人指定工作负载放置和调度规则，还有一个人了解神秘的安全监控世界。

我们需要做的第二件事是自动化。 当然，自动化是 DevOps 的关键，因此，如果我们不将我们专家的安全策略自动化为流程，那么这些策略将永远不会被遵循。 有些比其他的更容易自动化，有些——希望越来越少——需要 DevOps 团队其他成员的一些输入。 但是，如果我们能够将安全人员完全纳入团队，那么他们应该开始了解自动化的力量，并且说服他们与我们一起自动化的过程将变得越来越容易。

不仅是每个环节，而且是每次

最后一点回归到瀑布开发模型。 在该模型中，您“进行”一次⁴安全防护，但是在 DevOps 模型中，没有“一次”——一切都在每次迭代中循环往复。 现在，很可能——非常非常有可能——只是在前一两次迭代中让安全人员参与进来，然后，让他们离开去做他们的事情，无论那是什么⁵。

这将是一个巨大的错误。 我们都知道，随着迭代的进行，功能需求会发生变化——用户以意想不到的方式与事物互动，客户改变主意，管理层变得越来越无知⁶，主机配置得到更新。 但是，安全等非功能性需求也会发生变化。 如果用户以不同的方式与产品互动，您是否需要更改您的身份验证模型？ 自上次审查以来，是否有新的法规要求出现？ 您在其上运行工作负载的主机是否需要修补以缓解最近发现的漏洞？

所有这些的答案都可能是肯定的，因此，让您的安全人员在整个过程中以及每次迭代中都成为您团队的一员至关重要。 不要认为这是一件坏事； 他们的参与可以阻止您在发现一些重要的、您错过的安全要求时不得不重做整个项目，或者更糟糕的是，需要在整个过程中成为安全专家。

¹ 这是讽刺。

² 提示来自大约 97% 的开发人员、运维人员、测试人员、设计师以及所有人的集体松了一口气。³

³ 除了我们这些搞安全的； 我们喜欢它。

⁴ 如果你幸运的话。

⁵ a) 可能在酒吧，b) 你不想知道。

⁶ 通常是“更无知”，但你知道的。

[请参阅我们的相关文章，安全和隐私：您知道您的系统潜伏着什么吗？]