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

Question

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

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

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

标签： azureazure-devopsdevopscontinuous-deliverysarbanes-oxley

Answer 1

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

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

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

供参考的是 Puppet 对此的看法：

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