用于 SOX 合规性的 Azure DevOps 权限层次结构

Question

问题：作为 SOX 合规性审计的一部分，要求职责分离的审计员要求删除对源代码的贡献访问权限，即使是 Azure DevOps 服务中 Azure Repos 中的项目管理员和集合管理员等管理员，或任何能够通过发布管道部署到生产环境的人。

问题：MS 或任何其他使用 Azure DevOps 或类似服务的公司如何解决 DevOps 和 SRE 时代的这些权限冲突，其中有权访问生产部署的人需要进行代码更改（如果需要）以解决任何客户问题，同时让合规人员满意？

到目前为止尝试过的解决方案：- - 为项目集合管理员组添加了对存储库中贡献权限的明确拒绝，但它没有解决所有其他情况，如集合管理员，拒绝不允许。 来自 MS Docs - Azure DevOps Permission Settings

Answer 1

不确定这是否是一个可接受的答案，但您的问题是您的审核员。在这个时代，人们普遍认为，自动化和强大的审计日志相结合，就足以满足要求。

我推测您的问题来自审核员缺乏理解。实际部署由机器处理，而不是人。我同意开发人员不应该对产品进行未经检查的任意更改。

我的建议是，与您的 CTO 商量下一次组建新的审计团队。

Puppet 对此的评价如下：

“职责分离”的真正含义是什么？部分企业实施 控制以限制对 IT 系统的访问或需要手动批准， 相信法规——例如，《萨班斯-奥克斯利法案》或 SOC 2 — 强制职责分离。这通常被解释为 意味着可以提交代码存储库的人不得 允许将相同的代码部署到生产中。事实上，许多审计师 和安全专业人士相信，这就是 规定说。实际上，经常可以满足法规要求 结合： • 自动部署 • 要求代码作者以外的其他人必须审查和批准更改 • 支持强大的审计日志和访问控制等控制措施 如果 您的自动化工作受到诸如此类的控制的阻碍， 我们建议您专注于与 您的审计师和风险管理团队。真诚合作 以高效和安全的方式满足监管要求。 我们看到很少有人真正联系他们的风险团队 合作，但那些几乎总是成功的人。