问题:作为 SOX 合规性审计的一部分，要求职责分离的审计员要求删除对源代码的贡献访问权限，即使是 Azure DevOps 服务或 Azure 存储库中的项目管理员和集合管理员等管理员也是如此。任何能够通过发布管道部署到生产环境的人。
问题:在 DevOps 和 SRE 时代，微软或任何其他使用 Azure DevOps 或类似服务的公司如何解决这些权限冲突，在这个时代，有权访问生产部署的人需要进行代码更改(如果需要)以解决任何客户问题，同时让合规人员满意？
到目前为止尝试过的解决方案:- - 添加了对项目集合管理员组在存储库中贡献权限的显式拒绝，但它没有解决所有其他场景，对于集合管理员来说，拒绝不会胜过允许。 来自 MS 文档 - Azure DevOps Permission Settings
最佳答案
不确定这是否是可接受的答案，但您的问题在于您的审核员。在这个时代，人们普遍认为自动化和强大的审计日志的结合就足以满足要求。
我推测您的问题源于审计师缺乏了解。实际部署是由机器而不是人来处理的。我同意开发人员不应在产品中进行未经检查的任意更改。
我的建议是，下次与您的 CTO 讨论组建新的审核团队的事宜。
Puppet 对此的说法仅供引用:
What does “separation of duties” really mean? Some companies implement controls to limit access to IT systems or require manual approvals, believing that regulations — for example, the Sarbanes-Oxley Act or SOC 2 — mandate separation of duties. This is often interpreted to mean that people who can commit to a code repository must not be allowed to deploy that same code to production. Indeed, many auditors and security professionals are convinced that this is what the regulations say. In reality, regulations can frequently be satisfied with the combination of: • Automated deployment • A requirement that someone other than the code author must review and approve the change • Supporting controls such as strong audit logs and access control If your automation efforts are being hamstrung by controls such as these, we suggest you focus on building a collaborative relationship with your auditors and risk management teams. Work together on genuinely satisfying regulatory requirements in an efficient and secure manner. We’ve seen very few people actually reach out to their risk teams to collaborate, but the ones that do nearly always succeed.
关于SOX 合规性的 Azure DevOps 权限层次结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59684337/