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 más información, consulta Procedimientos recomendados sobre seguridad.
Niveles de acceso
Todos los usuarios de Azure DevOps tienen un nivel de acceso, que concede o restringe el acceso a características específicas 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 de Azure DevOps pertenecen a uno o varios grupos de seguridad predeterminados. Los grupos de seguridad obtienen permisos asignados que permiten o deniegan el acceso a características o tareas.
- Los miembros heredan los permisos asignados a su grupo de seguridad.
- Los permisos se definen en distintos niveles: organización o colección, proyecto o objeto.
- Algunos permisos se administran mediante asignaciones basadas en roles (por ejemplo, administrador de equipo, administración de extensiones o roles de recursos de canalización).
- Los administradores pueden definir grupos de seguridad personalizados para administrar permisos para diferentes áreas funcionales.
Para obtener más información, consulte Procedimientos recomendados de seguridad, Seguridad y grupos de usuarios.
La administración de permisos en Azure DevOps implica dos grupos clave: Administradores de colecciones de proyectos y Administradores de proyectos.
Administradores de colecciones de proyectos:
- Mantenga la autoridad más alta dentro de una organización o colección de proyectos.
- Realice todas las operaciones de toda la colección.
- Administrar la configuración, las directivas y los procesos de la organización.
- Cree y administre todos los proyectos y extensiones.
Administradores de proyectos:
- Operar en el nivel de proyecto.
- Administrar grupos de seguridad y permisos desde la configuración del proyecto en el portal web.
- Los colaboradores controlan los permisos de objetos específicos que crean dentro del proyecto.
Estados del permiso
Asigne permisos para conceder o restringir el acceso:
El usuario o grupo tiene permiso:
- Permitir
- Permitir (heredado)
- Permitir (sistema)
El usuario o grupo no tiene permiso:
- Denegar
- 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) . |
Los miembros de los grupos Administradores de colecciones de proyectos o Administradores de Team Foundation siempre pueden recibir permisos aunque se denieguen en otro grupo. En los ejemplos siguientes se explica aún más este escenario:
- Un usuario puede seguir accediendo a la configuración del proyecto o administrar usuarios. Sin embargo, para tareas como la eliminación de elementos de trabajo o la administración de canalizaciones, ser miembro del grupo Administradores de colecciones de proyectos no invalida los permisos denegar establecidos en otro lugar.
- Si se deniega el permiso de un usuario para eliminar elementos de trabajo en un proyecto específico, no podrá eliminar elementos de trabajo aunque formen parte del grupo Administradores de colecciones de proyectos. De forma similar, si se deniegan los permisos de canalización, no pueden administrar ni ejecutar canalizaciones a pesar de su rol administrativo.
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 nodo primario o la invalida.
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.
- Los miembros de los administradores de colecciones de proyectos o los administradores de Team Foundation 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.
Reglas de herencia y especificidad de permisos:
- Los permisos explícitos siempre tienen prioridad sobre los heredados.
- Todos los subnodos heredan los permisos establecidos en un nodo de nivel superior 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.
- Si un permiso se establece explícitamente para un subnodo, el permiso del elemento primario no se hereda, independientemente de si se permite o se deniega.
Especificidad:
En la jerarquía de objetos, la especificidad supera la herencia. El permiso más específico tiene prioridad si existen permisos en conflicto.
Ejemplo:
- 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, seleccionar ¿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.
Se abre un cuadro de diálogo que muestra la información de herencia de ese permiso.
La interfaz de usuario en versión preliminar de la página de configuración permisos de proyecto no está disponible para Azure DevOps Server 2020 y versiones anteriores.
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 Administradores de proyectos.
| Proyecto | Organización o colección |
|---|---|
| - Administradores de compilación -Colaboradores - Administradores de proyectos - Usuarios válidos del proyecto -Lectores - Administradores de versiones - TeamName Team |
- Administradores de colecciones de proyectos - Administradores de compilación de colecciones de proyectos - 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.
Los siguientes grupos de seguridad se definen de forma predeterminada para cada proyecto y colección de proyectos. Normalmente, se agregan usuarios o grupos a los grupos Lectores, Colaboradores o Administradores de proyectos.
Agregue solo cuentas de servicio a grupos de cuentas de servicio de Azure DevOps. Para comprender los grupos de usuarios válidos, consulte Grupos de usuarios válidos más adelante en este artículo.
| En el nivel de proyecto | Nivel de colección |
|---|---|
| - Administradores de compilación -Colaboradores - Administradores de proyectos - Usuarios válidos del proyecto -Lectores - Administradores de versiones - TeamName Team |
- Administradores de colecciones de proyectos - Administradores de compilación de colecciones de proyectos - 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 - Grupo de servicios de seguridad |
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 Administradores de proyectos .
Para los usuarios que se encargan de administrar características de nivel de colección o de organización, como proyectos, directivas, procesos, directivas de retención, grupos de agentes e implementaciones, y extensiones, agréguelas al grupo Administradores de colecciones de proyectos. 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.
Los miembros del grupo de seguridad pueden ser una combinación de usuarios, otros grupos y grupos de Active Directory o un grupo de trabajo.
Puede crear grupos locales o grupos de Active Directory (AD) para administrar los usuarios.
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 Conexión de 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.
Para configurar Active Directory para su uso con Azure DevOps Server, consulte los artículos siguientes:
- Instalar Active Directory Domain Services (Nivel 100)
- Servicios de dominio de Active Directory Introducción.
Instale Active Directory antes de instalar Azure DevOps Server.
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.
- Server\Azure DevOps Usuarios válidos: todos los miembros agregados a grupos de nivel de servidor.
- ProjectCollectionName\Project Collection Usuarios válidos: todos los miembros agregados a grupos de nivel de colección.
- ProjectName\Project Valid Users( Usuarios válidos del proyecto): todos los miembros agregados a grupos 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 devopslos 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
La habilitación de la característica Limitar la visibilidad y la colaboración del usuario a proyectos específicos impide que los usuarios con ámbito de proyecto busquen usuarios agregados 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 una resolución está en curso. Para resolver este problema, deshabilite la característica Limitar la visibilidad y la colaboración del usuario 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 se administran en el nivel de organización, incluso si se usan para proyectos específicos. En función de los permisos de usuario, es posible que algunos grupos estén ocultos en el portal web. Para ver todos los nombres de grupo dentro de una organización, puede usar 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.
Nota:
Los grupos de seguridad se administran en el nivel de colección, incluso si se usan para proyectos específicos. En función de los permisos de usuario, es posible que algunos grupos estén ocultos en el portal web. Para ver todos los nombres de grupo dentro de una colección, puede usar 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.
Nota:
Los grupos de seguridad se administran en el nivel de colección, incluso si se usan para proyectos específicos. En función de los permisos de usuario, es posible que algunos grupos estén ocultos en el portal web. Para ver todos los nombres de grupo de una colección, puede usar las 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.
En la imagen siguiente se muestra cómo se pueden asignar los grupos de seguridad definidos en el nivel de proyecto y colección a los permisos asignados en el nivel de objeto, proyecto y colección. Solo puede definir grupos de seguridad de nivel de servidor a permisos de nivel de servidor.
Los miembros de los grupos Administradores de proyectos o Administradores de colecciones de proyectos pueden administrar todas las herramientas de equipo para todos los equipos.
Características en vista previa
Las marcas de características controlan el acceso a las nuevas características. Azure DevOps presenta periódicamente nuevas características detrás de una marca de características. 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.