正如 O'Reilly 的书，DevOpsSec 在第 2 章中详述，职责分离 (SoD) 是信息安全标准的主要组成部分：ISO 27001、NIST SP 800-53、COBIT、ITIL 等——以及（至少）的监管要求：FFIEC、Sarbanes-Oxley Section 404、SSAE 16、GLBA、MiFID II 和 PCI DSS。

开发人员确实同意只读环境，如不可变基础设施（即“无 SSH 运动”）是最佳实践。您甚至会看到像 Martin Fowler 这样的开发人员英雄直接规定了 PhoenixServer 概念，即使不是完整的ImmutableServer模型。

但是，在灌输三道防线 (3LoD) 的组织中（例如，金融服务公司或具有内部和/或外部审计功能的任何地方），即使是只读功能也可能不足以满足要求（并通过审核）。

DevOpsSec 书在不可变基础设施和 SoD（它也推荐）之外提出了以下建议：

• 限制对非公开数据和配置的访问。
• 仔细检查日志记录代码以确保日志不包含机密数据。
• 审核和审查开发人员在生产中所做的一切：他们执行的每条命令，他们查看的每条数据。
• 您需要检测性更改控制来跟踪在持续交付管道之外对代码或配置所做的任何更改。
• 您可能还需要担心数据泄露：确保开发人员无法将数据带出系统。

另一种补偿控制是职责轮换 (RoD)，它通常与 SoD 一起使用。如果您经常轮换人员并避免串通的情况，那么这可以补偿和支持其他强大的控制。最后一点是两方完整性，其中完整的制衡系统包括通过“无暗角”范式阻止受信任的内部人员的能力。

这里还有来自 DevOps 和应用程序安全性行业专家 Ben Tomhave 的一些新观点——http: //www.newcontext.com/devops-and-separation-of-duties/

作为一名执业信息安全专业人士，我同意贵公司 IT 安全部门的评估。遵循安全最佳实践通常需要个人了解此类实践背后的意图，在这种情况下，适当的职责分离，SoD

由于贵公司的开发人员似乎没有足够的动力/不了解 SoD 的好处，我将向他们解释遵守 SoD 将如何使他们自己受益。看看在这种情况下 OP 发生了什么。理性的开发人员应该了解他们是否无法访问生产环境，并假设身份验证和问责制的安全 AAA 的其他 2 个要素正在发挥作用，如果在开发完成后他们的代码出现问题，他们不能受到指责。

开发者也应该明白，虽然他们可能有责任并且绝不会通过违反 CIA 原则对生产环境中的财务数据/信用卡信息造成恶意破坏，但其他开发者可能不负有责任。如果生产中的敏感财务数据发生事故，公司可能会面临巨额罚款以及声誉受损，从而导致未来收入损失，根据公司规模，这可能直接导致企业生存受到质疑影响开发人员的职业/生计。

最后，我想在@atdre 提供的出色答案中扩展一点，即您应该拥有纠正性事件响应控制来补充检测性变更管理控制。如果您从监控程序（例如：TripWire）中检测到对生产数据的未经授权的更改，您应该有适当的补偿控制以从造成的损害中恢复（例如：利用测试备份的恢复）。