You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/security-best-practices.md
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,9 +71,13 @@ The system manages permissions at different levels - individual, collection, pro
71
71
72
72
- Only give users and services the minimum amount of access needed to perform their business functions.
73
73
- Disable inheritance where possible. Due to the allow-by-default nature of inheritance, unexpected users can get access or permissions. For more information, read about [inheritance](https://learn.microsoft.com/en-us/azure/devops/organizations/security/about-permissions.md#permission-inheritance-and-security-groups).
|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. |
115
+
|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. :o:[**Azure.DevOps.`*.ProjectValidUsers**](src/PSRule.Rules.AzureDevOps/en/Azure.DevOps.ServiceConnections.ProjectValidUsers.md)|
112
116
|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. |
113
-
|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. |
117
+
|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. :o:[**Azure.DevOps.`*.ProjectValidUsers**](src/PSRule.Rules.AzureDevOps/en/Azure.DevOps.ServiceConnections.ProjectValidUsers.md)|
114
118
|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. |
115
119
|Keep groups as small as possible. Access should be restricted, and the groups should be frequently audited. ||
116
120
|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.||
0 commit comments