Skip to content

security best practices

Jump to bottom
github-actions edited this page Jan 20, 2024 · 2 revisions

title: Security best practices titleSuffix: Azure DevOps description: Best practices for managing security and keeping your data secure in Azure DevOps. ms.subservice: azure-devops-security ms.topic: best-practice ms.author: chcomley author: chcomley monikerRange: '<= azure-devops' ms.date: 09/18/2023

Security best practices

[!INCLUDE version-lt-eq-azure-devops]

This document is taken from https://learn.microsoft.com/en-us/azure/devops/organizations/security/security-best-practices?view=azure-devops and is updated to reflect how the rules from this repository indicated with ⭕ bold are related to the best practices in the original document.

When you're working with information and data, particularly in a cloud-based solution like Azure DevOps Services, prioritizing security should always be your primary concern. While Microsoft maintains the security of the underlying cloud infrastructure, it's your responsibility to configure security in Azure DevOps.

Although it's not mandatory, incorporating best practices while using Azure DevOps can enhance your experience and make it more secure. We've compiled the following best practices that aim to keep your Azure DevOps environment secure:

Secure Azure DevOps environment

Removing users

  • If your organization uses MSA accounts, then remove inactive users directly from the organization, as you have no other way to prevent access. When you do so, you can't create a query for work items assigned to the removed user account. For more information, see Delete users from Azure DevOps.
  • If your organization is connected to Azure AD, then you can disable or delete the Azure AD user account and leave your Azure DevOps user account active. In this way, you can continue to query work item history using your Azure DevOps user ID.
  • Revoke user PATs.
  • Revoke any special permissions that may have been granted to individual user accounts.
  • Reassign work from users you’re removing to current team members.

Use Azure AD

Integrate Azure DevOps with Azure AD to have a single plane for identity. Consistency and a single authoritative source increases clarity and reduces security risks from human errors and configuration complexity. The key to end governance is to have multiple role assignments (with different role definitions and different resource scopes to the same Azure AD groups). Without Azure AD, you're solely responsible for controlling organization access.

Using Azure AD also allows you to access other security features, like multi-factor authentication or other conditional access policies.

For more information, see the following articles:

Review auditing events

Once you have an Azure AD backed organization, you can turn on Auditing in your Security policies. Periodically review audit events to monitor and react to unexpected usage patterns by administrators and other users.

Secure your network

A few ways to do so might include:

  • Set up an allowlist to restrict specific IPs.
  • Always use encryption.
  • Validate certificates.
  • Implement Web application firewalls (WAFs), so they can filter, monitor, and block any malicious web-based traffic to and from Azure DevOps.
  • For more information, see this guidance on application management best practices

Scoped permissions

The system manages permissions at different levels - individual, collection, project, and object - and assigns them to one or more built-in groups by default.

Project-level permissions

  • Limit access to projects and repos to reduce the risk of leaking sensitive information and deploying insecure code to production.
  • Use either the built-in security groups or custom security groups to manage permissions. For more information, see Grant or restrict permissions to select tasks and project-scoped user groups.
  • Enable the Limit user visibility for projects preview feature for the organization, which restricts access to only those projects that you add users to.
  • Add users to the Project-scoped users group, so they can only see and select users and groups in the project that they're connected to from a people picker.
  • Disable "Allow public projects" in your organization's policy settings to prevent every organization user from creating a public project. Azure DevOps Services allows you to change the visibility of your projects from public to private, and vice-versa. If users haven't signed into your organization, they have read-only access to your public projects. If users have signed in, they can be granted access to private projects and make any permitted changes to them.
  • Don’t allow users to create new projects.

External guest access

  • Block external guest access entirely by disabling the "Allow invitations to be sent to any domain" policy. It's a good idea to do so if there's no business need for it.
  • Use a different email or user principal name (UPN) for your personal and business accounts, even though it's allowed. This action eliminates the challenge of disambiguating between your business and personal accounts when the email/UPN is the same.
  • Put all the external guest users in a single Azure AD group and manage the permissions of that group appropriately. You can easily manage and audit this way.
    • Remove direct assignments so the group rules apply to those users. For more information, see Add a group rule to assign access levels.
    • Reevaluate rules regularly on the Group rules tab of the Users page. Clarify whether any group membership changes in Azure AD might affect your organization. Azure AD can take up to 24 hours to update dynamic group membership. Every 24 hours and anytime a group rule changes, rules get automatically reevaluated in the system.
  • For more information, see B2B guests in the Azure AD.

Manage security groups

Security and user groups

See the following recommendations for assigning permissions to security groups and users groups.

Do :::image type="icon" source="../../media/icons/checkmark.png" border="false"::: Don't :::image type="icon" source="../../media/icons/delete-icon.png" border="false":::
Use Azure Active Directory, Active Directory, or Windows security groups when you're managing lots of users. Don’t change the default permissions for the Project Valid Users group. This group can access and view project information. ⭕ Azure.DevOps.`*.ProjectValidUsers
When you're adding teams, consider what permissions you want to assign to team members who need to create and modify area paths, iteration paths, and queries. Don't add users to multiple security groups that contain different permission levels. In certain cases, a Deny permission level may override an Allow permission level.
When you're adding many teams, consider creating a Team Administrators custom group where you allocate a subset of the permissions available to Project Administrators. Don't change the default assignments made to the Project Valid Users groups. If you remove or set View instance-level information to Deny for one of the Project Valid Users groups, no users in the group can access whatever project, collection, or deployment you set the permission on. ⭕ Azure.DevOps.`*.ProjectValidUsers
Consider granting the work item query folders Contribute permission to users or groups who require the ability to create and share work item queries for the project. Don't assign permissions that are noted as Assign only to service accounts to user accounts.
Keep groups as small as possible. Access should be restricted, and the groups should be frequently audited.
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.

For more information, see Valid user groups.

Just-in-time access for admin groups

You can change the configuration of your organization or project if you have Project Collection Administrator and Project Administrator access. To protect access to these built-in administrator groups, require just-in-time access using an Azure AD Privileged Identity Management (PIM) group.

Configure access

  1. Create a role-assignable group in Azure AD.
  2. Add your Azure AD group to the Azure DevOps group.

Note

Make sure any user with elevated access using a PIM group also has standard access to the organization, so they can view the page to refresh their permissions.

Use access

  1. Activate your access.
  2. Refresh your permissions in Azure DevOps.
  3. Take the action requiring administrator access.

Note

Users have elevated access in Azure DevOps for up to 1 hour after their PIM group access gets deactivated.

Scope service accounts

  • Ensure service accounts have zero interactive sign-in rights.
  • Restrict service account privileges to the bare minimum necessary.
  • Use a different identity for the report reader account, if you use domain accounts for your service accounts. For more information, see Service accounts and dependencies.
  • Use local accounts for user accounts, if you're installing a component in a workgroup. For more information, see Service account requirements.
  • Use service connections when possible. Service connections provide a secure mechanism to connect to assorted services without the need to pass in secret variables to the build directly. - Restrict these connections to the specific place they should be used and nothing more.
  • Monitor service account activity and create audit streaming. Auditing allows you to detect and react to suspicious sign-ins and activity.
  • For more information, see Common service connection types.

Scope service connections

Choose the right authentication method

Select your authentication methods from the following sources:

Consider service principals

Explore alternatives like service principals and managed identities that enable you to use Azure AD tokens to access Azure DevOps resources. Such tokens carry less risk when leaked compared to PATs and contain benefits like easy credential management.

Use PATs sparingly

If possible, we recommended to always use identity services for authentication instead of cryptographic keys since managing keys securely with application code is challenging and can lead to mistakes like accidentally publishing sensitive access keys to public code repositories like GitHub. However, if you must use personal access tokens (PATs), consider the following guidelines:

  • PATs should always be scoped to specific roles.

  • PATs shouldn't provide global access to multiple organizations.

  • PATs shouldn't grant write or manage permissions on builds or releases.

  • PATs should have an expiration date and be kept secret since they're as critical as passwords.

  • PATs should never be hardcoded in the application code, even if it's tempting to do so to simplify the code.

  • Administrators should regularly audit all PATs using the REST APIs and revoke any that doesn't meet the above criteria.

  • Keep your PATs a secret. Your tokens are as critical as passwords.

  • Store your tokens in a safe place.

  • Don’t hard code tokens in applications. It can be tempting to simplify code to obtain a token for a long period of time and store it in your application, but don’t do that.

  • Give tokens an expiration date.

  • For more information, check out the following articles:

Secure Azure Artifacts

Secure Azure Boards

Secure Azure Pipelines

Policies

Agents

  • Grant permissions to the smallest possible number of accounts.
  • Have the most restrictive firewall that leaves your agents usable.
  • Update pools regularly to ensure the build fleet isn’t running vulnerable code that a malicious actor can exploit.
  • Use a separate agent pool for build artifacts that get shipped or deployed to production.
  • Segment “sensitive” pool from nonsensitive pools, and only allow the use of credentials in build definitions that are locked to that pool.

Definitions

  • Manage pipeline definitions with YAML (Yet Another Markup Language). YAML is the preferred method for managing pipeline definitions, as it provides traceability for changes and can follow approval guidelines.

    ⭕ Azure.DevOps.Pipelines.Core.UseYamlDefinition

  • Secure the pipeline definition Edit access to the minimum number of accounts.

Input

Tasks

Repositories and branches

Secure Azure Repos

Secure Azure Test Plans

Secure GitHub Integrations

  • Disable Personal Access Token (PAT)-based authentication, so the OAuth flow gets used with the GitHub service connection.

    ⭕ Azure.DevOps.ServiceConnections.GitHubPAT

  • Never authenticate GitHub service connections as an identity that's an administrator or owner of any repositories.
  • Never use a full-scope GitHub PAT (Personal Access Token) to authenticate GitHub service connections.
  • Don't use a personal GitHub account as a service connection with Azure DevOps.
Clone this wiki locally