Azure DevOps: Access, Roles and Permissions

Author: Jacob Young, CISA, Information Technology Auditor, Protective Life
Date Published: 21 January 2021
Related: Certificate of Cloud Auditing Knowledge | Azure Audit Program | Digital | English

As IT auditors, we are well aware that the change management process is a critical component of IT controls testing in risk-based and compliance audits. Change management processes and workflows are typically managed through various IT service management solutions and are the record-keeper for ensuring changes are approved, implemented and reviewed by appropriate personnel. Auditors must recognize that there are additional application development processes that should be considered within the scope of the engagement. 

This post calls attention to how source code management tools may allow for users to bypass workflow controls and invalidate the change management processes that organizations have put in place. Specifically, elevated access within source code management tools lends the opportunity to initiate unauthorized code deployments to production. 

For the purposes of this post, our discussion will be specific to Azure DevOps access, roles, and permissions. This analysis begins with a high-level overview of Azure DevOps and then flows into a detail of its roles and permissions that the auditor should assess at the collection, project, and agent pool level to mitigate the risk that workflow controls may be bypassed through administrator permissions within the application. 

Azure DevOps Background

Agile development methodology has gained popularity with organizations over the years. It provides development teams the opportunity to continuously deploy code, which is meant to enhance the user experience and correct security issues. There are various source code management tools that have workflows built in to aid in agile development processes. Azure DevOps (formerly Team Foundation Server) is a source code management tool that utilizes the Git flow process to manage source code changes. 

Azure DevOps is primarily broken down into two components: Collections and Projects. Depending on the size of your organization and the complexity of your environment, you may have multiple collections, and each collection may have multiple projects, whereby each project is utilized by a separate application development team. 

Azure DevOps enables pipelines to be managed that provide continuous delivery through automated build and code deployments. Deployments are initiated through agent pools. Access to pipelines and agent pools must be restricted to the appropriate personnel to prevent unapproved changes to the production environment.

Collection & Project Level Security

Collections can contain an array of projects owned by different development teams. Access must be limited at the collection level and should only consist of service accounts that are owned by a production control business unit. Project level security can be assigned to individual user accounts into the appropriate role.

Built-In Roles and Permissions to the Application

As stated in Microsoft documentation, Azure DevOps contains prebuilt roles that have been incorporated into the application that support segregation of duties:

  • Collection Administrators have administrative rights to all projects within the collection. 
  • Project Administrators have administrative permissions to the project.
  • Collection & Project Build Administrators permit users to administer build resources and permissions, including to manage test environments, create test runs, and manage builds at the collection or project level.
  • Release Administrators permit users to manage release operations at the collection or project level.
  • Contributors include developers that permit modification of code repositories and work item tracking.
  • Readers have read access to projects.

Administrator roles are high-risk. Auditors should pull user listings for these roles and ensure that access is appropriate based on personnel responsibilities, paying increased attention to developer access outside of the Contributors group. 

Built-In Roles and Permissions to Agent Pool Security

Roles are assigned to Agent Pools that include reader, service account and administrator. The reader role is self-explanatory, as this role only permits members to view the agent pool and agents. The Service Account role and Administrator role are the high-risk roles that need to be monitored as these roles can create project agent pools. Additionally, the Administrator role can register and unregister agents and manage access for all roles of the agent pool. Any of the roles mentioned in Collection and Project-level security can be assigned to one of these three roles. Auditors should ensure at minimum the Contributors are not included in the Agent Pool Administrator role, as this gives them access to deploy code into production.

Conclusion: Integrating Agile Methodology

Agile methodology is being integrated into organizational processes to aid in continuous maintenance of systems. Auditors must confirm that there are adequate controls within development teams’ agile methodology to ensure secure development work that is implemented to production by appropriate personnel. A good starting place is to ensure that job responsibilities are appropriate and that access is assigned based on those responsibilities.

Editor’s note:
For related resources from ISACA, download our Azure audit program and find out about the new Certificate of Cloud Auditing and Knowledge (CCAK), a credential from ISACA and Cloud Security Alliance.