Azure DevOps Permissions Hierarchy for SOX Compliance

Question

Issue: As part of SOX Compliance Audit, the auditors who are demanding separation of duties, are asking to remove contribute access to the source code even for administrators like Project Admins and Collection Admins in the Azure Repos in the Azure DevOps Services or to any one who are able to deploy to production environments through release pipelines.

Question: How does MS or any other companies utilizing Azure DevOps or similar services address these permission conflicts in the Era of the DevOps and SRE where a person who has access to production deployment will need to make code changes (if required) to address any customer problems, all at the same time keeping compliance folks happy ?

Solution Tried so far:- - Added explicit denies for the project collection administrators group for the contributing permission in the repositories but it does not address all other scenarios as for Collection admin, deny does not trump allow. From MS Docs - Azure DevOps Permission Settings

Answer 1

Not sure if this is an acceptable answer but your problem is your auditors. In this era, it is generally understood that a combination of automation and robust audit logs, that is enough to comply.

I would speculate that your problem comes from the auditor’s lack of understanding. The actual deployment is handled by the machine, not a person. I’d agree that developers should not be making unchecked arbitrary changes in product.

My suggestion, speak to your CTO about getting a new audit team next time.

For reference here is what Puppet say on this:

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.