Edit

Share via

Make your Azure DevOps secure

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

When you're handling information and data, especially in a cloud-based solution like Azure DevOps Services, security should be your top priority. While Microsoft ensures the security of the underlying cloud infrastructure, it's your responsibility to configure security within Azure DevOps. This article provides an overview of necessary security-related configurations to protect your Azure DevOps environment against threats and vulnerabilities.

Protect your network and data

Securing your network is crucial when you're working with Azure DevOps to protect your data and resources from unauthorized access and potential threats. Implement network security and data protection measures to help ensure that only trusted sources can access your Azure DevOps environment. To secure your network when you're working with Azure DevOps, do the following actions:

  • Set up IP allowlisting: Restrict access to specific IP addresses to allow traffic only from trusted sources, reducing the attack surface. If your organization is secured with a firewall or proxy server, add IPs and URLs to the allowlist.
  • Use data encryption: Protect your data by using encryption, backup, and recovery strategies. Always encrypt data in transit and at rest. Secure communication channels using protocols like HTTPS. Learn more about Azure Encryption.
  • Validate certificates: Ensure certificates are valid and issued by trusted authorities when establishing connections.
  • Implement Web Application Firewalls (WAFs): Filter, monitor, and block malicious web-based traffic with WAFs for an extra layer of protection against common attacks.
  • Network security groups (NSGs) overview: Use NSGs to control inbound and outbound traffic to Azure resources, ensuring only authorized traffic is allowed.
  • Use Azure Firewall: Deploy Azure Firewall to provide a centralized network security policy across multiple Azure subscriptions and virtual networks.
  • Monitor network traffic with Azure Network Watcher: Use Azure Network Watcher to monitor and diagnose network issues, ensuring the security and performance of your network.
  • Implement DDoS protection with Azure DDoS Protection: Enable Azure DDoS Protection to safeguard your applications from distributed denial-of-service (DDoS) attacks.

For more information, see Application management best practices.

Implement Zero Trust

Adopt Zero Trust principles across your DevOps processes to make sure every access request is thoroughly verified, regardless of its origin. Zero Trust operates on the principle of "never trust, always verify," meaning that no entity, whether inside or outside the network, is trusted by default. By implementing Zero Trust, you can significantly reduce the risk of security breaches and ensure that only authorized users and devices can access your resources.

Zero Trust helps to protect against lateral movement within the network, ensuring that even if there's a compromised part of the network, the threat is contained and can't spread. For more information, see the Zero Trust Assessment guide.

Comply with industry standards

Ensure your Azure DevOps environment complies with industry standards and regulations that protect your environment and maintain trust with your users.

  • Ensure compliance with industry standards: Azure DevOps complies with various industry standards and regulations, such as ISO/IEC 27001, SOC 1/2/3, and GDPR. Ensure your environment adheres to these standards.
  • Enforce compliance policies: Implement branch policies and compliance policies for your pipelines.
  • Onboard to Component Governance for CI/CDs, which offers the following benefits:
    • Security vulnerability detection: Alerts you to known vulnerabilities in open-source components.
    • License compliance: Ensures components comply with your organization's licensing policies.
    • Policy enforcement: Ensures only approved versions are used.
    • Visibility with tracking: Provides visibility into components across repositories for easier management.

Control and restrict access

Review through all the security policies available to administrators to restrict and control who has access to the organization. Maintain control of the organization by preventing unnecessary project creation.

Manage external guests

External guest access can introduce potential security risks if not managed properly. Minimize these risks and ensure that external guests have the appropriate level of access without compromising the security of your environment.

  • Block external guest access: Disable the "Allow invitations to be sent to any domain" policy to prevent external guest access if there's no business need for it.
  • Use distinct emails or UPNs: Use different email addresses or user principal names (UPNs) for personal and business accounts to eliminate ambiguity between personal and work-related accounts.
  • Group external guest users: Place all external guest users in a single Microsoft Entra group and manage permissions for this group appropriately. Remove direct assignments to ensure group rules apply to these users.
  • Reevaluate rules regularly: Regularly review rules on the Group rules tab of the Users page. Consider any group membership changes in Microsoft Entra ID that might affect your organization. Microsoft Entra ID can take up to 24 hours to update dynamic group membership, and rules are automatically reevaluated every 24 hours and whenever a group rule changes.

For more information, see B2B guests in the Microsoft Entra ID.

Remove unnecessary users

Removing inactive or unauthorized users from your organization helps maintain a secure environment and reduces the risk of potential security breaches.

  • Directly remove inactive Microsoft account users (MSAs): Directly remove inactive users from your organization if they're using MSAs. You can't create queries for work items assigned to removed MSA accounts.
  • Disable or delete Microsoft Entra user accounts: If connected to Microsoft Entra ID, disable or delete the Microsoft Entra user account while keeping the Azure DevOps user account active. You may continue querying work item history using their Azure DevOps user ID.
  • Revoke user PATs for administrators: Ensure secure management of these critical authentication tokens by regularly reviewing and revoking any existing user PATs.
  • Revoke special permissions granted to individual users: Audit and revoke any special permissions granted to individual users to ensure alignment with the principle of least privilege.
  • Reassign work from removed users: Before removing users, reassign their work items to current team members to distribute the load effectively.

Scope permissions

Provide the minimum necessary permissions and access levels to ensure that only authorized individuals and services can access sensitive information and perform critical actions. This practice helps to minimize the risk of unauthorized access and potential data breaches.

Regularly review and update these settings to adapt to changes in your organization, such as role changes, new hires, or departures. Implementing a periodic audit of permissions and access levels can help identify and rectify any discrepancies, ensuring that your security posture remains robust and aligned with best practices.

Learn more about permissions:

To ensure secure and efficient management of permissions, properly scope permissions within your Azure DevOps environment. Scoping permissions involves defining and assigning the appropriate level of access to users and groups based on their roles and responsibilities. This practice helps to minimize the risk of unauthorized access and potential data breaches by ensuring that only authorized individuals have access to sensitive information and critical actions.

To scope permissions effectively, do the following actions:

  • Disable inheritance: Avoid permissions inheritance and prevent unintended access. Inheritance can inadvertently grant permissions to users who shouldn't have them, due to its allow-by-default nature. Carefully manage and explicitly set permissions to ensure that only the intended users have access.
  • Segment environments: Use separate Azure accounts for different environments, such as Development, Testing, and Production, to enhance security and prevent conflicts. This approach minimizes the risk of resource conflicts and data contamination between environments and allows for better management and isolation of resources. For more information, see Azure Landing Zone.
  • Control access and ensure compliance: Use Azure Policy to restrict access to unused Azure regions and services, ensuring compliance with organizational standards. This action helps enforce best practices and maintain a secure environment by preventing unauthorized access and usage.
  • Implement Azure role-based control (ABAC): Use ABAC with properly tagged resources to limit unauthorized access. This action ensures that access permissions get granted based on specific attributes, enhancing security by preventing unauthorized resource creation and access.
  • Use security groups: Use security groups to efficiently manage permissions for multiple users. This method simplifies granting and revoking access compared to assigning permissions individually and ensures consistency and easier management across your organization.
    • Use Microsoft Entra ID, Active Directory, or Windows security groups when you're managing lots of users.
    • Reduce the risk of leaking sensitive information and deploying insecure code by limiting access to projects and repositories to built-in or custom security groups.
    • Take advantage of built-in roles and default to Contributor for developers. Admins get assigned to the Project Administrator security group for elevated permissions, allowing them to configure security permissions.
    • Keep groups as small as possible, restricting access.
    • Implement just-in-time access with a Microsoft Entra Privileged Identity Management (PIM) group. Grant elevated permissions only when needed, reducing the risk associated with permanent access.

Ditch service accounts

Historically, service accounts were used in conjunction with personal access tokens (PATs) to build tools that run automated processes and services. As a result, they often have elevated permissions. Before choosing to continue building with a service account, explore if it's still the right authentication approach for you.

  • Give up your PATs for Microsoft Entra tokens: Microsoft Entra tokens are short-lived (one-hour) tokens that can be used in place of most PATs. PATs are popular due to their ease of use, but they are also a popular vector of attack due to the ease in which they are leaked.
  • Read up on all the authentication mechanisms available before choosing one.
  • Use service principals instead: Service principals represent a Microsoft Entra application's identity and have their own permissions that define what the application can do in a given tenant. Service principals are the recommended choice to manage the permissions needed by the app. Replace any service accounts' PATs with Microsoft Entra tokens acquired for the service principal.
    • Take it one step further by authenticating using a managed identity if you're building on top of Azure resources. Managed identities take care of all credential management for you.
  • Use service connections: Service connections allow you to use service principals inside a pipeline. Use service connections whenever possible to securely connect to services without passing secret variables directly to builds. Restrict connections to specific use cases. for more information, see the Scope service connections section in this article.
    • Authenticate with Azure resources using workload identity federation with either an app registration or managed identity instead of using an app registration with a secret.

While a service account remains in use:

  • Create single-purpose service accounts: Each service should have its dedicated account to minimize risk. Avoid using regular user accounts as service accounts.
  • Identify and disable unused service accounts: Regularly review and identify accounts no longer in use. Disable unused accounts before considering deletion.
  • Restrict privileges: Limit service account privileges to the minimum necessary. Avoid interactive sign-in rights for service accounts.
  • Use separate identities for report readers: If using domain accounts for service accounts, use a different identity for report readers to isolate permissions and prevent unnecessary access.
  • Use local accounts for workgroup installations: When installing components in a workgroup, use local accounts for user accounts. Avoid domain accounts in this scenario.
  • Monitor service account activity: Implement auditing and create audit streams to monitor service account activity.

Scope service connections

To ensure secure and efficient access to Azure resources, properly scope service connections. Service connections allow Azure DevOps to connect to external services and resources, and by scoping these connections, you can limit access to only the necessary resources and reduce the risk of unauthorized access.

  • Limit access: Limit access by scoping your Azure Resource Manager service connections to specific resources and groups. Don't grant broad contributor rights across the entire Azure subscription.
  • Use Azure Resource Manager: Authenticate with Azure resources using workload identity federation with either an app registration or managed identity instead of using an app registration with a secret. For more information, see Create an Azure Resource Manager service connection that uses workload identity federation.
  • Scope resource groups: Ensure resource groups contain only the Virtual Machines (VMs) or resources needed for the build process.
  • Avoid classic service connections: Opt for modern Azure Resource Manager service connections instead of classic ones, which lack scoping options.
  • Use purpose-specific team service accounts: Authenticate service connections using purpose-specific team service accounts to maintain security and control.

For more information, see Common service connection types.

Review auditing events

Auditing can be used to track user actions, permissions changes, and usage patterns within your organization. Use these tools to identify and address potential security incidents promptly.

  • Enable auditing: Track and view events related to user actions, permissions, changes, and security incidents.
  • Review audit logs and streams regularly: Regularly review audit logs to monitor user activities and detect any suspicious behavior. Look for unexpected usage patterns, especially by administrators and other users. This action helps identify potential security breaches and takes corrective actions. Learn more about the auditing events we track.
  • Configure security alerts: Configure alerts to notify you of any security incidents or policy violations. This action ensures timely response to potential threats.

Secure your services

To ensure the security and integrity of your services in Azure DevOps, implement security measures for each service. These measures include setting permissions, managing access, and using security features specific to each service.

Automate security scanning

Monitor for code and secret vulnerabilities with the following automated security tools built by our partner teams:

  • Use code scanning and analysis: Utilize tools like Microsoft Defender to scan your code for vulnerabilities, secrets, and misconfigurations. This action helps identify and remediate security issues early in the development process.
  • Use Azure DevOps Credential Scanner (CredScan) for GitHub: When using a managed identity isn't an option, ensure that credentials get stored in secure locations such as Azure Key Vault, instead of embedding them into the code and configuration files. Implement Azure DevOps Credential Scanner to identify credentials within the code. For more information, see Getting started with CredScan.
  • Use native secret scanning for GitHub: When using a managed identity isn't an option, ensure that secrets get stored in secure locations such as Azure Key Vault, instead of embedding them into the code and configuration files. Use the native secret scanning feature to identify secrets within the code. For more information, see About secret scanning.

For more information, see the GitHub advanced security overview.