Introducción a los permisos y el acceso

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

En este artículo, obtenga información sobre cómo administrar los niveles de acceso y los permisos a través de herencia, grupos de seguridad, roles y mucho más en Azure DevOps. Empiece por comprender los siguientes conceptos clave.

• Acerca de los 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.

• Acerca de los niveles de acceso:

  • Todos los usuarios agregados a Azure DevOps se asignan a 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.

• Acerca de las características en versión preliminar:
  • A medida que se introducen nuevas características, los usuarios pueden habilitarlas o deshabilitarlas a través de características en versión preliminar para acceder a ellas.
  • Un pequeño subconjunto de características nuevas se administra en el nivel de organización y los propietarios de la organización lo habilitan o deshabilitan.

Por ejemplo, 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 administradores deben agregarse al grupo Administradores de colección de proyectos o Administradores de proyectos. Administración istrators administran grupos de seguridad y permisos desde el portal web, principalmente desde Configuración del proyecto. Los colaboradores también administran los permisos de los objetos que crean desde el portal web.

Para información general sobre los permisos predeterminados, consulte Referencia rápida de los permisos predeterminados.

Grupos de seguridad y pertenencia

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

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.

Para obtener una descripción de cada grupo y cada permiso, consulte Referencia de permisos y grupos, Grupos.

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. Para obtener más información, consulte Herencia de permisos y grupos de seguridad más adelante en este artículo.

• La administración de nivel de acceso controla el acceso a las características del portal web. En función de lo que se ha adquirido para un usuario, los administradores establecen el nivel de acceso del usuario en Partes interesadas, Básica, Básica y 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. Sin embargo, para facilitar la administración, es más fácil si rellena 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 método permite administrar la pertenencia a grupos y permisos de forma más eficaz en varios equipos.

Si solo tiene que administrar un pequeño conjunto de usuarios, puede omitir este paso. Sin embargo, si prevé que su organización puede crecer, es posible que desee configurar Active Directory o Microsoft Entra ID. Además, si planea pagar por servicios adicionales, debe configurar el identificador de Entra de Microsoft para usarlo 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, debe configurar 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, hay muchas directivas de organización que puede habilitar o deshabilitar para proteger su organización. Para obtener más información, consulte Acerca de la seguridad, autenticación y autorización, Directivas de seguridad.

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

• 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 que se heredan a través de la pertenencia a grupos se actualizan. Si quiere actualizar la pertenencia a Microsoft Entra y los permisos heredados en Azure DevOps, cierre 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 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.

Los permisos predeterminados asignados a estos grupos se limitan principalmente al 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. Si necesita 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 usuarios de Project-Scoped

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, los detalles de facturación, los datos de uso y mucho más a los que se accede 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 los usuarios seleccionados, como las partes interesadas, los usuarios invitados de Microsoft Entra o los 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 a acceder a las páginas de configuración de la organización, excepto en Información general y proyectos; y está restringido a acceder solo a los proyectos a los que se han agregado.

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. Algunos grupos pueden estar 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.

Niveles de acceso

Los niveles de acceso controlan qué características son visibles para los usuarios en el portal web. El acceso depende de las licencias de usuario.

Si quiere conceder a un usuario acceso a las características de administración de cartera de Agile o administración de casos de prueba, cambie los niveles de acceso, no los permisos.

Establecer el nivel de acceso para usuarios o grupos no les proporciona acceso a un proyecto o al portal web. Solo los usuarios o grupos agregados a un equipo o grupo de seguridad pueden conectarse a un proyecto y al portal web. Asegúrese de que los usuarios tienen los permisos y el nivel de acceso que necesitan. Para ello, asegúrese de que se agregan al proyecto o a un equipo.

Permisos

Como se muestra en la imagen siguiente, los grupos de seguridad definidos en el nivel de proyecto y colección se pueden asignar a los permisos asignados en el objeto, proyecto y nivel de organización.

Para obtener una descripción de cada grupo de seguridad predeterminado, consulte Grupos de seguridad, cuentas de servicio y permisos.

Estados de permisos

Un permiso puede tener las siguientes asignaciones. Conceden o restringen 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 un grupo diferente. 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 cambiar un permiso para un grupo, cambia ese permiso para todos los usuarios que son miembros de ese grupo. Según el tamaño del grupo, puede afectar a la capacidad de cientos de usuarios para realizar sus trabajos cambiando solo un permiso. Así que asegúrese de comprender los posibles efectos antes de realizar un cambio.

Herencia de permisos y grupos de seguridad

Algunos permisos se administran a través de una jerarquía. Dentro de esta jerarquía, los permisos se pueden heredar del elemento primario o invalidado. Los grupos de seguridad asignan un conjunto de permisos a esos miembros del grupo. Por ejemplo, a los miembros del grupo Colaboradores o del grupo Project Administración istrators se les asignan los permisos que se establecen como Permitidos para esos grupos.

Si un permiso no se permite o deniega directamente para un usuario, se puede heredar de las maneras siguientes.

• Los usuarios heredan permisos de los grupos a los que pertenecen. Cuando un usuario tiene una pertenencia directa o a un grupo Permitir permiso, un permiso de denegación de pertenencia directa o de grupo lo invalida.

  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. Los permisos de operación de elemento de trabajo son la excepción a esta regla.

• Los permisos de nivel de objeto que se asignan a los nodos de una jerarquía ( áreas, iteraciones, carpetas de control de versiones, carpetas de consulta de elementos de trabajo) se heredan de la jerarquía. Es decir, los permisos de un usuario que se establecen en area-1 get inherited by area-1/sub-area-1, si el mismo permiso no se permite o deniega explícitamente para area-1/sub-area-1. Si un permiso se establece explícitamente para un objeto, como area-1/sub-area-1, el nodo primario no se hereda, independientemente de si se deniega o se permite. Si no se establece, los permisos para ese nodo se heredan del antecesor más cercano que tiene el permiso establecido explícitamente. Por último, en la jerarquía de objetos, la especificidad supera la herencia. Por ejemplo, un usuario cuyos permisos se establecen explícitamente en Denegar en "area-1", pero también se establecen explícitamente en Permitir para "area-1/sub-area-1" recibe un allow en "area-1/sub-area-1".

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

Se abre una nueva ventana que muestra la información de herencia de ese permiso.

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 puede 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".

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.

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.

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
• ¿Qué es Microsoft Entra ID?
• Introducción a Microsoft Entra ID
• Referencia de permisos y grupos
• Herramientas de administración de permisos y seguridad
• Agregar usuarios a una organización
• Adición y administración de grupos de seguridad
• Administrar tokens, espacios de nombres, permisos
• Funcionamiento de la facturación
• Configuración de la facturación para pagar usuarios, canalizaciones y pruebas de carga basadas en la nube en Azure DevOps