Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Servicios de Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
En este artículo, obtendrá 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 más información, consulte Introducción a la seguridad.
Para obtener instrucciones de rendimiento para organizaciones grandes, consulte Recomendaciones de rendimiento de permisos.
Sugerencia
Puede usar la inteligencia artificial para ayudar con las tareas de Azure DevOps. Consulte Habilitar la asistencia de IA con el servidor MCP de Azure DevOps para comenzar.
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. Existen tres niveles de acceso principales: partes interesadas, básicas y básicas y planes de prueba. 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. Asigne permisos a grupos de seguridad que permitan o denieguen el acceso a características o tareas.
- Los miembros heredan los permisos asignados a su grupo de seguridad.
- Defina permisos en distintos niveles: organización o colección, proyecto o objeto.
- Administre algunos permisos a través de asignaciones basadas en roles (por ejemplo, administrador de equipos, administración de extensiones o roles de recursos del pipeline).
- Los administradores pueden definir grupos de seguridad personalizados para administrar permisos para diferentes áreas funcionales.
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:
- Tener permisos administrativos amplios dentro de una organización o colección de proyectos.
- Administrar la configuración, las directivas y los procesos de la organización.
- Cree y administre proyectos.
Administradores de proyectos:
- Operar a nivel de proyecto.
- Administrar grupos de seguridad y permisos desde la configuración del proyecto en el portal web.
- Controle los permisos para los objetos específicos que los colaboradores crean en el 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 el permiso al usuario o grupo seleccionado en el ámbito actual. |
| Permitir (heredado) | Concede el permiso a través de un ámbito primario o pertenencia a grupos. |
| Permitir (sistema) | Concede un permiso que Azure DevOps administra. No se pueden editar los permisos del sistema. |
| Deny | Deniega explícitamente el permiso al usuario o grupo seleccionado en el ámbito actual. |
| Denegar (heredado) | Deniega el permiso a través de un ámbito principal o de la pertenencia a un grupo. |
| Denegar (sistema) | Deniega un permiso que Azure DevOps administra. No se pueden editar los permisos del sistema. |
| Sin establecer | Ni concede ni deniega el permiso en el ámbito actual. Otras asignaciones aplicables determinan el permiso efectivo. |
Azure DevOps calcula los permisos efectivos de asignaciones directas, pertenencias a grupos y asignaciones heredadas. Cuando combina asignaciones en el mismo ámbito, Deny suele tener prioridad sobre Allow. En una jerarquía de objetos, una asignación explícita en un objeto secundario puede reemplazar el valor heredado de su elemento primario para la misma identidad.
Advertencia
Al modificar un permiso para un grupo, afecta a todos los usuarios de ese grupo. Incluso un único cambio de permiso puede afectar a cientos de usuarios, por lo que debe tener en cuenta los posibles efectos antes de realizar cualquier ajuste.
Herencia de permisos
Los permisos siguen una jerarquía, por lo que puede heredar permisos de un nodo primario o invalidarlos.
Herencia de grupos:
- Los usuarios reciben los permisos combinados de los grupos a los que pertenecen.
- En el mismo ámbito, una denegación de un grupo generalmente tiene prioridad sobre una autorización de otro grupo.
- No establecido no concede ni deniega un permiso y no anula una asignación de otro grupo.
Herencia de nivel de objeto:
Asigne permisos de nivel de objeto a nodos como áreas, iteraciones, carpetas de control de versiones y carpetas de consulta de elementos de trabajo. Estos permisos se heredan hacia abajo en la jerarquía.
Reglas de jerarquía de objetos:
- Todos los subnodos heredan los permisos establecidos en un nodo de nivel superior, a menos que se invaliden explícitamente.
- Si un permiso no está explícitamente permitido o denegado para un subnodo, hereda el permiso de su nodo padre.
- Si un permiso se establece de forma explícita para una identidad en un subnodo, la configuración heredada del nodo principal para esa identidad no se aplica en el subnodo.
- Después de resolver la jerarquía de objetos, Azure DevOps combina las asignaciones directas y de grupo aplicables. Una denegación de otro grupo en el ámbito resultante puede seguir teniendo prioridad sobre un Permitir.
Ejemplo:
-
Denegar explícitamente en
area-1(nodo primario). -
Permitir explícitamente para
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, seleccione ¿Por qué? para ese permiso. Para abrir una página Seguridad , consulte Ver permisos.
Se abre un cuadro de diálogo que muestra la información de herencia de ese permiso.
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 y asigna automáticamente permisos predeterminados a estos grupos. Para definir más grupos de seguridad, use las siguientes acciones:
- Crear grupos de seguridad personalizados en los siguientes niveles:
- Nivel del proyecto
- Nivel de organización o colección.
- Nivel de servidor (solo local)
- Agregar un equipo, que 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 necesitan acceso para administrar Azure Test Plans requieren planes básicos y de prueba o una ventaja de suscripción Visual Studio aplicable.
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 construcción -Colaboradores - Administradores de proyectos - Usuarios válidos del proyecto - Lectores - Administradores de versiones - TeamName Equipo |
- 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 colecciones de proyectos - Usuarios válidos de la colección de proyectos - Usuarios definidos en el ámbito del 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 de datos |
|---|---|
| - Administradores de construcción -Colaboradores - Administradores de proyectos - Usuarios válidos del proyecto - Lectores - Administradores de versiones - TeamName Equipo |
- 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 colecciones de proyectos - Usuarios válidos de la colección de proyectos - Grupo de servicios de seguridad |
Agregue usuarios que administran características de nivel de proyecto al grupo Administradores de proyectos. Estas características incluyen equipos, rutas de acceso de área e iteración, repositorios, enlaces de servicio y puntos de conexión de servicio.
Agregue usuarios que administran características de nivel de colección o organización al grupo Administradores de colecciones de proyectos. Estas características incluyen proyectos, directivas, procesos, políticas de retención, grupos de agentes e implementación, y extensiones. Para obtener más información, consulte Acerca de la configuración de usuario, equipo, proyecto y nivel de organización.
Administración de pertenencia, permisos y nivel de acceso
Azure DevOps controla el acceso a través de estas tres áreas funcionales interconectadas:
- Gestión de membresía es compatible con la adición de cuentas de usuario individuales y grupos 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 establecido.
- La administración de nivel de acceso controla el acceso a las características del portal web. En función de las licencias y el rol del usuario, los administradores asignan partes interesadas, Basic, Basic + Test Plans o un nivel de acceso de suscripción Visual Studio aplicable.
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 basan en el 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. Se actualizan los permisos heredados derivados de la pertenencia a grupos. 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 Servicios de dominio de Active Directory (Nivel 100)
- Introducción a los Servicios de dominio de Active Directory.
Instale Active Directory antes de instalar Azure DevOps Server.
Grupos de usuarios válidos
Al agregar cuentas de usuario directamente a un grupo de seguridad, los usuarios se convierten automáticamente en parte de uno de los siguientes grupos de usuarios válidos.
- Usuarios válidos de la colección de proyectos: 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.
Para acceder a los recursos del proyecto, un usuario necesita Ver información de nivel de proyecto y los permisos necesarios para el recurso específico. Los permisos de ruta de acceso de área controlan el acceso a los elementos de trabajo y a los artefactos de prueba dentro de un proyecto; no controlan si un usuario puede acceder al proyecto. No cambie los permisos predeterminados para un grupo Usuarios válidos. Denegar Ver información de nivel de proyecto, Ver información de nivel de colección o Ver información de nivel de instancia a uno de estos grupos puede bloquear todos sus miembros desde el ámbito correspondiente.
Grupo de usuarios con ámbito de proyecto
De forma predeterminada, los usuarios que agregue a una organización pueden ver la información de la organización y del proyecto más allá de los proyectos de los que son miembros.
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. Al habilitar esta función, los usuarios y grupos del grupo Usuarios con ámbito de proyecto solo pueden acceder a los proyectos a los que se les añada explícitamente. Esta función también limita el acceso de los usuarios a la configuración de la organización y a las identidades en los selectores de usuarios.
Advertencia
Tenga en cuenta las siguientes limitaciones al usar esta característica en versión preliminar:
- Las características de visibilidad limitadas descritas en esta sección solo se aplican a las interacciones a través del portal web. Mediante el uso de las API REST o
az devopslos comandos de la CLI, los miembros del proyecto pueden acceder a los datos restringidos. - Los usuarios del grupo limitado solo pueden seleccionar usuarios que se agregan explícitamente a Azure DevOps y no a los usuarios que tienen acceso a través de la pertenencia a grupos de Microsoft Entra.
- 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.
Para conocer los pasos y las limitaciones de la configuración, consulte Limitar la visibilidad del usuario.
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 de una organización, puede usar la herramienta de la CLI de Azure DevOps o las 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 a nivel de la colección, incluso si se utilizan para determinados proyectos. 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 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 y cada rol tiene uno o varios permisos. Los siguientes recursos admiten permisos basados en roles:
- Roles de seguridad de artefactos o fuentes de paquetes
- Rol de Administrador de extensiones de Marketplace
- Roles de seguridad del pipeline
- Rol de administrador de equipo
Para obtener más información, consulte Acerca de los roles de seguridad de canalización.
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. Únicamente puede definir grupos de seguridad a nivel de servidor para permisos de nivel de servidor.
Los miembros de los grupos Administradores de proyectos o Administradores de colecciones de proyectos administran todas las herramientas de equipo para todos los equipos.
Características de vista previa
Las características en versión preliminar proporcionan acceso anticipado a la funcionalidad antes de que esté disponible con carácter general. Los usuarios pueden administrar características en versión preliminar que se ofrecen en el nivel de usuario. Los miembros del grupo Project Collection Administrators pueden administrar características en versión preliminar a nivel de organización en Azure DevOps Services y características en versión preliminar a nivel de colección en Azure DevOps Server. Para obtener más información, consulte Administración o habilitación de características.