Acerca de los permisos y los grupos de seguridad

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

En este artículo, obtenga información sobre los niveles de acceso y los permisos a través de herencia, grupos de seguridad, roles y mucho más en Azure DevOps.

Para información general sobre los permisos predeterminados, consulte Referencia rápida de los permisos predeterminados. Para obtener una descripción de cada grupo de seguridad predeterminado, consulte Grupos de seguridad, cuentas de servicio y referencia de permisos.

Niveles de acceso

A todos los usuarios agregados a Azure DevOps se les asigna un nivel de acceso, que concede o restringe el acceso para seleccionar las características del portal web.

Hay tres niveles de acceso principales: Partes interesadas, Basic y Basic + Test Plans. El acceso de las partes interesadas proporciona acceso gratuito a un número ilimitado de usuarios a un conjunto limitado de características. Para obtener más información, consulte Referencia rápida sobre el acceso de parte interesada.

Para conceder a un usuario acceso a las características de administración de carteras ágiles o de administración de casos de prueba, cambie los niveles de acceso, no los permisos. Para obtener más información, vea Acerca de los niveles de acceso.

Permisos

Todos los usuarios agregados a Azure DevOps se agregan a uno o varios grupos de seguridad predeterminados. A los grupos de seguridad se les asignan permisos, que permiteno deniegan el acceso a una característica o tarea.

• Los miembros de un grupo de seguridad heredan los permisos asignados al grupo.
• Los permisos se definen en distintos niveles: organización o colección, proyecto o objeto.
• Otros permisos se administran a través de asignaciones basadas en roles, como el administrador del equipo, la administración de extensiones y varios roles de recursos de canalización.
• Administración istrators pueden definir grupos de seguridad personalizados para administrar permisos para diferentes áreas funcionales.

Cuando se trata de administrar permisos en Azure DevOps, hay dos grupos clave implicados: Colección de proyectos Administración istrators y Project Administración istrators. Vamos a verlo:

Colección de proyectos Administración istrators:

• Estas personas tienen el nivel más alto de autoridad dentro de una organización o colección de proyectos.
• Pueden realizar todas las operaciones de toda la colección.
• Sus responsabilidades incluyen la administración de la configuración, las directivas y los procesos de la organización.
• Además, pueden crear y administrar todos los proyectos y extensiones dentro de la organización.

Project Administración istrators:

• Project Administración istrators funcionan en el nivel de proyecto.
• Administran los grupos de seguridad y los permisos principalmente desde la configuración del proyecto del portal web.
• Los colaboradores, por otro lado, controlan los permisos de objetos específicos que crean dentro del proyecto.

Estados de permisos

Puede asignar permisos de las siguientes maneras, conceder o restringir el acceso como se indica.

El usuario o grupo tiene permisos para realizar una tarea:

• Permitir
• Permitir (heredado)
• Permitir (sistema)

El usuario o grupo no tiene permiso para realizar una tarea:

• Deny
• Denegar (heredado)
• Denegar (sistema)
• Sin establecer

Estado del permiso	Descripción
Permitir	Concede explícitamente a los usuarios que realicen tareas específicas y no se heredan de la pertenencia a grupos.
Permitir (heredado)	Concede a los miembros del grupo que realicen tareas específicas.
Permitir (sistema)	Concede permiso que tiene prioridad antes de los permisos de usuario. No se puede editar y almacenar en una base de datos de configuración, invisible para los usuarios.
Deny	Restringe explícitamente a los usuarios la realización de tareas específicas y no se hereda de la pertenencia a grupos. En el caso de la mayoría de los grupos y de casi todos los permisos, Denegar invalida Permitir. Si un usuario pertenece a dos grupos y uno de ellos tiene un conjunto de permisos específico en Denegar, ese usuario no puede realizar tareas que requieran ese permiso aunque pertenezcan a un grupo que tenga ese permiso establecido en Permitir.
Denegar (heredado)	Impide que los miembros del grupo realicen tareas específicas. Invalida un permiso explícito.
Denegar (sistema)	Restringe el permiso que tiene prioridad antes de los permisos de usuario. No se puede editar y almacenar en una base de datos de configuración, invisible para los usuarios.
Sin establecer	Deniega implícitamente a los usuarios la capacidad de realizar tareas que requieran ese permiso, pero permite la pertenencia a un grupo que tiene ese permiso para tener prioridad, también conocido como Permitir (heredado) o Denegar (heredado) .

En algunos casos, los miembros de la colección de proyectos Administración istrators o los grupos de Team Foundation Administración istrators siempre pueden obtener el permiso aunque se les deniegue ese permiso en otro grupo. En otros casos, como la eliminación de elementos de trabajo o las canalizaciones, ser miembro de la colección de proyectos Administración grupoistrators no omite los permisos de denegación establecidos en otro lugar.

Advertencia

Al modificar un permiso para un grupo, afecta a todos los usuarios de ese grupo. Incluso un solo cambio de permiso puede afectar a cientos de usuarios, por lo que es fundamental tener en cuenta los posibles efectos antes de realizar cualquier ajuste.

Herencia de permisos

Los permisos siguen una jerarquía, lo que permite la herencia de un elemento primario o invalidando.

• Herencia de grupos: los usuarios heredan los permisos de los grupos a los que pertenecen. Si un usuario tiene un permiso Permitir directamente o a través de la pertenencia a grupos, pero también tiene un permiso Denegar a través de otro grupo, el permiso Denegar tiene prioridad. Sin embargo, los miembros de la colección de proyectos Administración istrators o Team Foundation Administración istrators conservan la mayoría de los permisos permitidos, incluso si pertenecen a otros grupos que deniegan esos permisos (excepto para las operaciones de elementos de trabajo).
• Herencia de nivel de objeto: los permisos de nivel de objeto (asignados a nodos como áreas, iteraciones, carpetas de control de versiones y carpetas de consulta de elementos de trabajo) se heredan de la jerarquía.

Por ejemplo, vamos a desglosar las reglas de herencia y especificidad de permisos y recordar, los permisos explícitos siempre tienen prioridad sobre los heredados:

• Cuando los permisos de un usuario se establecen en un nodo de nivel superior (área-1), esos permisos se heredan por todos los subnodos (área-1/sub-área-1), a menos que se invaliden explícitamente.
• Si no se permite o deniega explícitamente un permiso para un subnodo, hereda el permiso de su elemento primario.
• Sin embargo, si un permiso se establece explícitamente para un subnodo (area-1/sub-area-1), el permiso del elemento primario no se hereda, independientemente de si está permitido o denegado. Especificidad:
• En la jerarquía de objetos, la especificidad supera la herencia. Esto significa que si existen permisos en conflicto, el permiso más específico tiene prioridad.
• Por ejemplo, considere un usuario:
  • Denegar explícitamente en "area-1" (nodo primario).
  • Permitir explícitamente "area-1/sub-area-1" (nodo secundario).
• En este caso, el usuario recibe una opción Permitir en "area-1/sub-area-1", reemplazando la denegación heredada del nodo primario.

Para comprender por qué se hereda un permiso, puede pausar una configuración de permisos y, a continuación, elegir ¿Por qué? Para abrir una página Seguridad , consulte Ver permisos.

Nota:

Para habilitar la página de vista previa de la página de configuración de permisos de proyecto, consulte Habilitar características en versión preliminar.

Página de versión preliminar

Se abre un cuadro de diálogo que muestra la información de herencia de ese permiso.

Página actual

Una nueva ventana muestra la información de herencia de ese permiso.

Grupos de seguridad y pertenencia

Los grupos de seguridad asignan permisos específicos a sus miembros.

Al crear una organización, una colección o un proyecto, Azure DevOps crea un conjunto de grupos de seguridad predeterminados a los que se asignan automáticamente permisos predeterminados. Se definen más grupos de seguridad con las siguientes acciones:

• Al crear grupos de seguridad personalizados en los siguientes niveles:
  • Nivel del proyecto
  • Organización o colección.
  • Nivel de servidor (solo local)
• Al agregar un equipo, se crea un grupo de seguridad de equipo

No puede crear un grupo de seguridad de nivel de objeto, pero puede asignar un grupo personalizado a un nivel de objeto y asignar permisos a ese nivel. Para obtener más información, vea Establecer permisos de nivel de objeto.

Grupos de seguridad predeterminados

La mayoría de los usuarios de Azure DevOps se agregan al grupo de seguridad Colaboradores y se les concede el nivel de acceso Básico . El grupo Colaboradores proporciona acceso de lectura y escritura a repositorios , seguimiento de trabajos, canalizaciones, etc. El acceso básico proporciona acceso a todas las características y tareas para usar Azure Boards, Azure Repos, Azure Pipelines y Azure Artifacts. Los usuarios que requieren acceso para administrar los planes de pruebas de Azure deben concederse acceso básico y de prueba o avanzado .

Los siguientes grupos de seguridad se definen de forma predeterminada para cada proyecto y organización. Normalmente, se agregan usuarios o grupos a los grupos Lectores, Colaboradores o Project Administración istrators.

Proyecto

Organización o colección

- Compilación de Administración istrators -Colaboradores - Project Administración istrators - Usuarios válidos del proyecto -Lectores - Liberar Administración istrators - TeamName Team

- Colección de proyectos Administración istrators - Compilación de colecciones de proyectos Administración istrators - Cuentas de servicio de compilación de colecciones de proyectos - Cuentas de servicio de proxy de recopilación de proyectos - Cuentas de servicio de recopilación de proyectos - Cuentas de servicio de prueba de recopilación de proyectos - Usuarios válidos de la colección de proyectos - Usuarios con ámbito de proyecto - Grupo de servicios de seguridad

Para obtener una descripción de cada uno de estos grupos, consulte Grupos de seguridad, cuentas de servicio y permisos. Para ver las asignaciones de permisos predeterminadas realizadas en los grupos de seguridad predeterminados más comunes, consulte Permisos y acceso predeterminados.

Para los usuarios que se encargan de administrar características de nivel de proyecto, como, equipos, rutas de acceso de área e iteración, repositorios, enlaces de servicio y puntos de conexión de servicio, agréguelas al grupo Project Administración istrators.

Para los usuarios que se encargan de administrar características de nivel de colección o organización, como proyectos, directivas, procesos, directivas de retención, grupos de agente e implementación, y extensiones, agréguelas al grupo colección de proyectos Administración istrators. Para obtener más información, consulte Acerca de la configuración de usuario, equipo, proyecto y nivel de organización.

Administración de nivel de acceso, permisos y pertenencia

Azure DevOps controla el acceso a través de estas tres áreas funcionales interconectadas:

• La Administración de pertenencia es compatible con la adición de cuentas de usuario y grupos de Windows individuales a los grupos de seguridad predeterminados. Cada grupo predeterminado está asociado con un conjunto de permisos predeterminado. Todos los usuarios agregados a cualquier grupo de seguridad se agregan al grupo Usuarios válidos. Un usuario válido es aquel que puede conectarse a un proyecto, colección u organización.
• La Administración de permisos controla el acceso a tareas funcionales específicas en distintos niveles del sistema. Los permisos de nivel de objeto establecen permisos en un archivo, carpeta, canalización de compilación o una consulta compartida. La configuración de permisos se corresponde con Permitir, Denegar, Permitir heredado, Denegar heredado, Permitir sistema, Denegar sistema y No establecer.
• La administración de nivel de acceso controla el acceso a las características del portal web. En función de la compra de un usuario, los administradores establecen el nivel de acceso del usuario en Parte interesada, Básico, Básico + Prueba o Visual Studio Enterprise (anteriormente Avanzado).

Cada área funcional usa grupos de seguridad para simplificar la administración en la implementación. Puede agregar usuarios y grupos a través del contexto de la administración web. Los permisos se establecen automáticamente en función del grupo de seguridad al que se agregan usuarios. O los permisos se obtienen en función del nivel de objeto, proyecto, colección o servidor al que se agregan grupos.

La pertenencia a grupos de seguridad puede ser una combinación de usuarios, otros grupos y grupos de Microsoft Entra.

Grupos de seguridad de Active Directory y Microsoft Entra

Puede rellenar los grupos de seguridad agregando usuarios individuales. Pero, para facilitar la administración, es más eficaz rellenar estos grupos mediante el identificador de Microsoft Entra para Azure DevOps Services y Active Directory (AD) o grupos de usuarios de Windows para Azure DevOps Server. Este enfoque permite administrar la pertenencia a grupos y permisos de forma más eficaz en varios equipos.

Si solo necesita administrar un pequeño conjunto de usuarios, puede omitir este paso. Sin embargo, si prevé que su organización puede crecer, considere la posibilidad de configurar Active Directory o Microsoft Entra ID. Además, si planea usar servicios adicionales, es esencial configurar el identificador de Entra de Microsoft para su uso con Azure DevOps para admitir la facturación.

Nota:

Sin el identificador de Microsoft Entra, todos los usuarios de Azure DevOps deben iniciar sesión con cuentas de Microsoft y debe administrar el acceso a la cuenta mediante cuentas de usuario individuales. Incluso si administra el acceso a la cuenta mediante cuentas Microsoft, configure una suscripción de Azure para administrar la facturación.

Para configurar el identificador de Entra de Microsoft para su uso con Azure DevOps Services, consulte Conectar su organización a Microsoft Entra ID.

Cuando su organización está conectada a Microsoft Entra ID, puede definir y administrar varias directivas de la organización para mejorar la seguridad y simplificar el acceso a las aplicaciones. Para obtener más información, consulte Acerca de la seguridad y las directivas de seguridad.

Para administrar el acceso de la organización con microsoft Entra ID, consulte los artículos siguientes:

• Agregar o eliminar usuarios mediante Microsoft Entra ID
• Solución de problemas de acceso con el identificador de Entra de Microsoft

Azure DevOps registra los cambios realizados en un grupo de Microsoft Entra dentro de una hora a partir de ese cambio en el identificador de Microsoft Entra. Los permisos heredados a través de la pertenencia a grupos se actualizan. Para actualizar la pertenencia a Microsoft Entra y los permisos heredados en Azure DevOps, cierre la sesión y vuelva a iniciar sesión o desencadene una actualización para volver a evaluar el permiso.

Grupos de usuarios válidos

Al agregar cuentas de usuarios directamente a un grupo de seguridad, se agregan automáticamente a uno de los siguientes grupos de usuarios válidos.

• Colección de proyectos usuarios válidos: Todos los miembros agregados a un grupo de nivel de organización.
• Usuarios válidos del proyecto: Todos los miembros agregados a un grupo de nivel de proyecto.

Los permisos predeterminados asignados a estos grupos proporcionan principalmente acceso de lectura, como Ver recursos de compilación, Ver información de nivel de proyecto y Ver información de nivel de colección.

Todos los usuarios que agregue a un proyecto pueden ver los objetos de otros proyectos de una colección. Para restringir el acceso de vista, puede establecer restricciones a través del nodo de ruta de acceso del área.

Si quita o deniega el permiso Ver información de nivel de instancia para uno de los grupos Usuarios válidos, ningún miembro del grupo puede acceder al proyecto, la colección o la implementación, en función del grupo que establezca.

Grupo de usuarios con ámbito de proyecto

De forma predeterminada, los usuarios agregados a una organización pueden ver toda la información y la configuración del proyecto. Esta configuración incluye la lista de usuarios, la lista de proyectos, detalles de facturación, datos de uso, etc., a los que puede acceder a través de la configuración de la organización.

Importante

• Las características de visibilidad limitadas descritas en esta sección solo se aplican a las interacciones a través del portal web. Con las API REST o azure devops los comandos de la CLI, los miembros del proyecto pueden acceder a los datos restringidos.
• Los usuarios invitados que son miembros del grupo limitado con acceso predeterminado en microsoft Entra ID, no pueden buscar usuarios con el selector de personas. Cuando la característica de vista previa está desactivada para la organización o cuando los usuarios invitados no son miembros del grupo limitado, los usuarios invitados pueden buscar en todos los usuarios de Microsoft Entra, según lo previsto.

Para restringir usuarios específicos, como partes interesadas, usuarios invitados de Microsoft Entra o miembros de un grupo de seguridad determinado, puede habilitar la característica Limitar la visibilidad y la colaboración del usuario a proyectos específicos en versión preliminar para la organización. Una vez habilitado, cualquier usuario o grupo agregado al grupo Usuarios con ámbito de proyecto está restringido de acceder a las páginas de configuración de la organización, excepto información general y proyectos. Además, solo tienen acceso a los proyectos a los que se agregan.

Advertencia

Cuando la característica Limitar la visibilidad del usuario y la colaboración a proyectos específicos está habilitada para la organización, los usuarios con ámbito de proyecto no pueden buscar usuarios que se agregaron a la organización a través de la pertenencia a grupos de Microsoft Entra, en lugar de a través de una invitación de usuario explícita. Se trata de un comportamiento inesperado y se está trabajando en una resolución. Para resolver este problema de forma automática, deshabilite la característica Limitar la visibilidad del usuario y la colaboración a proyectos específicos en versión preliminar para la organización.

Para obtener más información, consulte Administración de características en versión preliminar.

Nota:

Los grupos de seguridad pertenecen al nivel de organización, incluso si solo acceden a un proyecto específico. Es posible que algunos grupos estén ocultos en el portal web en función de los permisos de usuario. Puede encontrar todos los nombres de grupo de una organización con la herramienta de la CLI de azure devops o nuestras API REST. Para obtener más información, consulte Incorporación y administración de grupos de seguridad.

Permisos basados en roles

Con los permisos basados en roles, se asignan cuentas de usuario o grupos de seguridad a un rol, con cada rol asignado uno o varios permisos. Estos son los roles principales y vínculos a más información.

• Roles de seguridad de artefacto o fuente de paquetes: los roles admiten varios niveles de permisos para editar y administrar fuentes de paquetes.
• Rol administrador de extensiones de Marketplace: los miembros del rol Administrador pueden instalar extensiones y responder a las solicitudes de instalación de extensiones.
• Roles de seguridad de canalización: se usan varios roles para administrar recursos de biblioteca, recursos de canalización de nivel de proyecto y de nivel de colección.
• Rol de administrador de equipo Los administradores del equipo pueden administrar todas las herramientas del equipo.

Para obtener más información, consulte Acerca de los roles de seguridad.

En la imagen siguiente se muestra cómo los grupos de seguridad definidos en el nivel de proyecto y colección pueden asignar permisos a objetos, proyectos y la organización.

Los miembros de los grupos project Administración istrators o Project Collection Administración istrators pueden administrar todas las herramientas de equipo para todos los equipos.

Procedimientos recomendados para los permisos

Sí:

• Use microsoft Entra ID, Active Directory o grupos de seguridad de Windows al administrar una gran cantidad de usuarios.
• Al agregar un equipo, tenga en cuenta los permisos que desea asignar a los clientes potenciales del equipo, los maestros de scrum y otros miembros del equipo. Tenga en cuenta quién crea y modifica las rutas de acceso de área, las rutas de acceso de iteración y las consultas.
• Al agregar muchos equipos, considere la posibilidad de crear un grupo personalizado de Administración istrators de equipo, donde puede asignar un subconjunto de los permisos disponibles para Project Administración istrators.
• Considere la posibilidad de conceder permisos de colaboración a los usuarios o grupos que requieren la capacidad de crear y compartir consultas de elementos de trabajo para el proyecto.

No:

• No agregue usuarios a varios grupos de seguridad, que contienen distintos niveles de permisos. En determinados casos, un nivel de permiso Denegar podría invalidar un nivel de permiso Permitir .
• No cambie las asignaciones predeterminadas realizadas a los grupos Usuarios válidos. Si quita el permiso Ver información de nivel de instancia o lo establece en Denegar para uno de los grupos de usuarios válidos, ninguno de los usuarios del grupo podrá acceder al proyecto, la colección o la implementación, según el grupo para el que lo establezca.
• No asigne a cuentas de usuario los permisos que estén marcados como "Asignar únicamente a cuentas de servicio".

Características de vista previa

Las marcas de características controlan el acceso para seleccionar y nuevas características. Periódicamente, Azure DevOps presenta nuevas características colocándolas detrás de una marca de característica. Los miembros del proyecto y los propietarios de la organización pueden habilitar o deshabilitar las características en versión preliminar. Para obtener más información, consulte Administración o habilitación de características.

Pasos siguientes

Permisos y acceso predeterminado

Artículos relacionados

• Solución de problemas de acceso y permisos
• Acerca de la seguridad, la autenticación y la autorización
• Referencia de permisos y grupos
• Herramientas de administración de permisos y seguridad
• Adición y administración de grupos de seguridad