Introducción a los permisos, el acceso y los grupos de seguridad

  • Artículo
  • Tiempo de lectura: 19 minutos

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Cuando se trata de acceder a una característica de Azure DevOps, resulta útil 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 permiten o 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 mediante asignaciones basadas en roles, como el administrador del equipo, la administración de extensiones y varios roles de recursos de canalización.
    • Los administradores 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 a las características del portal web.
    • Hay tres niveles de acceso principales: Parte interesada, Básica y Básica + Test Plans.
    • El acceso a las partes interesadas proporciona acceso gratuito a un número ilimitado de usuarios a un conjunto limitado de características. Para más información, consulte Referencia rápida sobre el acceso a las partes interesadas.
  • 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 Azure DevOps se agregan al grupo de seguridad Colaboradores y se 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. A los usuarios que requieren acceso para administrar Azure Test Plans se les debe conceder acceso básico y Test Plans o avanzado.

Los administradores deben agregarse al grupo administradores de Project colección o Project administradores. Los administradores administran los grupos de seguridad y los permisos desde el portal web, principalmente desde Project configuración. Los colaboradores también administran los permisos de los objetos que crean desde el portal web.

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

Grupos de seguridad y pertenencia

Con la creación de una organización, colección o proyecto, Azure DevOps crea un conjunto de grupos de seguridad predeterminados, que se asignan automáticamente permisos predeterminados. Los grupos de seguridad adicionales se definen con las siguientes acciones:

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

Sugerencia

No se 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 más información sobre los permisos de nivel de objeto, consulte Establecimiento de 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 administradores de Project.

Project Organización o recopilación
- Administradores de compilación
- Colaboradores
- administradores de Project
- Project usuarios válidos
- Lectores
- Administradores de versiones
- TeamName Equipo		 - Administradores de recopilación de Project
- administradores de compilación de recopilación de Project
- cuentas de servicio de compilación de recopilación de Project
- Project cuentas de servicio de proxy de recopilación
- cuentas de servicio de recopilación de Project
- cuentas de servicio de prueba de recopilación de Project
- usuarios válidos de la colección Project
- usuarios de Project-Scoped
- 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 a 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 Project.

Nota:

En la lista siguiente se indican los grupos más recientes definidos para TFS 2017 y versiones posteriores. Para versiones anteriores de Azure DevOps, la lista puede diferir. Agregue solo cuentas de servicio a Azure DevOps grupos de cuentas de servicio. Para comprender los grupos de usuarios válidos, consulte Grupos de usuarios válidos más adelante en este artículo.

nivel de Project Nivel de colección
- Administradores de compilación
- Colaboradores
- administradores de Project
- Project usuarios válidos
- Lectores
- Administradores de versiones
- TeamName Equipo		 - Administradores de recopilación de Project
- administradores de compilación de recopilación de Project
- cuentas de servicio de compilación de recopilación de Project
- Project cuentas de servicio de proxy de recopilación
- cuentas de servicio de recopilación de Project
- cuentas de servicio de prueba de recopilación de Project
- usuarios válidos de la colección Project
- Grupo de servicios de seguridad

Sugerencia

En el caso de 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 Project. En el caso de los usuarios a los que se les encarga administrar las características de la organización o de nivel de recopilación (como, por ejemplo, proyectos, directivas, procesos, directivas de retención, grupos de agente e implementación) y extensiones, agréguelas al grupo administradores de recopilación de Project. Para 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 pertenencia, permisos y acceso

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

  • La administración de pertenencias admite la adición de cuentas de usuario individuales y grupos a grupos de seguridad predeterminados. Cada grupo predeterminado está asociado a un conjunto de permisos predeterminados. Todos los usuarios agregados a cualquier grupo de seguridad se agregan al grupo Usuarios válidos. Un usuario válido es alguien que puede conectarse a un proyecto, una colección o una 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 y No establecido. Para más información sobre la herencia, 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 comprado para 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 toda la implementación. Los usuarios y grupos se agregan a través del contexto de administración web. Los permisos se establecen automáticamente en función del grupo de seguridad al que se agregan usuarios o en función del nivel de objeto, proyecto, colección o servidor al que se agregan grupos.

Los miembros del grupo de seguridad pueden ser una combinación de usuarios, otros grupos y grupos Azure Active Directory.

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 Azure Active Directory

Puede rellenar los grupos de seguridad agregando usuarios individuales. Sin embargo, para facilitar la administración, es más fácil rellenar estos grupos mediante Azure Active Directory (Azure AD) para Azure DevOps Services y Active Directory (AD) o Windows grupos de usuarios para Azure DevOps Server. Este método permite administrar la pertenencia a grupos y los 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 AD o Azure AD. Además, si planea pagar por servicios adicionales, deberá configurar Azure AD para su uso con Azure DevOps para admitir la facturación.

Nota:

Sin Azure AD, todos los usuarios Azure DevOps deben iniciar sesión con cuentas microsoft y debe administrar el acceso de 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 Azure Active Directory para su uso con Azure DevOps Services, consulte Conectar su organización para Azure Active Directory.

Nota:

Cuando su organización está conectada a Azure Active Directory, hay varias directivas de organización que puede habilitar o deshabilitar para proteger la organización. Para más información, consulte Acerca de la seguridad, la autenticación y la autorización, Security-policies.

Para administrar el acceso organizativo con Azure AD, consulte los siguientes artículos:

Para configurar Active Directory para su uso con Azure DevOps Server, consulte los siguientes artículos:

Normalmente, debe instalar 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 grupos de usuarios válidos.

  • Project colección Usuarios válidos: todos los miembros agregados a un grupo de nivel de organización.
  • Project Usuarios válidos: 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 colección Usuarios válidos: todos los miembros agregados a grupos de nivel de colección.
  • ProjectName\Project Usuarios válidos: todos los miembros agregados a grupos de nivel de proyecto.
  • Usuarios válidos de Server\Team Foundation: todos los miembros agregados a grupos de nivel de servidor.
  • ProjectCollectionName\Project colección Usuarios válidos: todos los miembros agregados a grupos de nivel de colección.
  • ProjectName\Project Usuarios válidos: todos los miembros agregados a grupos 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.

Esto significa que 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 de usuarios válidos, ningún miembro del grupo puede acceder al proyecto, la recopilación o la implementación, en función del grupo que establezca.

grupo de usuarios con ámbito de Project

De forma predeterminada, los usuarios agregados a una organización pueden ver toda la información y la configuración del proyecto. Esto incluye ver 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.

Para restringir usuarios seleccionados, como partes interesadas, Azure Active Directory usuarios invitados o miembros de un grupo de seguridad determinado, puede habilitar la característica Limitar visibilidad y colaboración de usuarios a proyectos específicos de la organización. Una vez habilitado, cualquier usuario o grupo agregado al grupo usuarios con ámbito de Project, está restringido a acceder a las páginas organización Configuración, excepto información general y proyectos, y está restringido a acceder solo a los proyectos a los que se han agregado.

Para habilitar esta característica, consulte Administrar o habilitar características.

Nota:

Todos los grupos de seguridad son entidades de nivel de organización, incluso aquellos grupos que solo tienen permisos para un proyecto específico. Desde el portal web, la visibilidad de algunos grupos de seguridad puede limitarse en función de los permisos de usuario. Sin embargo, puede detectar los nombres de todos los grupos de una organización mediante la herramienta de la CLI de Azure devops o nuestras API REST. Para más información, consulte Incorporación y administración de grupos de seguridad.

Nota:

Todos los grupos de seguridad son entidades de nivel de colección, incluso aquellos grupos que solo tienen permisos para un proyecto específico. Desde el portal web, la visibilidad de algunos grupos de seguridad puede limitarse en función de los permisos de usuario. Sin embargo, puede detectar los nombres de todos los grupos de una organización mediante la herramienta de la CLI de Azure devops o nuestras API REST. Para más información, consulte Incorporación y administración de grupos de seguridad.

Nota:

Todos los grupos de seguridad son entidades de nivel de colección, incluso aquellos grupos que solo tienen permisos para un proyecto específico. Desde el portal web, la visibilidad de algunos grupos de seguridad puede limitarse en función de los permisos de usuario. Sin embargo, puede detectar los nombres de todos los grupos de una organización mediante las API REST. Para 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 y dependen de las licencias de usuario; los permisos controlan la capacidad de un usuario para conectarse a Azure DevOps y usar características en Azure DevOps. Si intenta conceder a alguien acceso a las características de administración de carteras de Agile o administración de casos de prueba, querrá cambiar los niveles de acceso, no los permisos.

Establecer el nivel de acceso para usuarios o grupos no les proporciona acceso a un proyecto ni 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 al 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 nivel de objeto, proyecto y organización.

Conceptual image mapping default security groups to permission levels, cloud

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 nivel de objeto, proyecto y colección. Solo puede definir grupos de seguridad de nivel de servidor a permisos de nivel de servidor.

Conceptual image mapping default security groups to permission levels, on-premises

Conceptual image of security groups and permission levels, TFS-2018 and earlier versions

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

Estados de los permisos

Hay cinco asignaciones posibles realizadas a un permiso. Conceden o restringen el acceso como se indica.

  • El usuario o grupo tiene permisos para realizar una tarea:
    • Permitir
    • Permitir herencia
  • El usuario o grupo no tiene permiso para realizar una tarea:
    • Denegar
    • Herencia denegada
    • Sin establecer

Esto es lo que necesita saber sobre la configuración de permisos:

  • Permitir o Denegar concede explícitamente o restringe a los usuarios a realizar tareas específicas y normalmente se heredan de la pertenencia a grupos.

  • No establecido implícitamente deniega a los usuarios la capacidad de realizar tareas que requieren ese permiso, pero permite la pertenencia a un grupo que tiene ese permiso establecido para tener prioridad, también conocido como Permitir (heredado)o Permitir (heredado) y Denegar (heredado) o Denegar (heredado) o Denegar heredado.

  • Para la mayoría de los grupos y 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.

    En algunos casos, los miembros de los grupos administradores de colecciones de Project o administradores de Team Foundation siempre pueden obtener el permiso incluso si se les deniega ese permiso en un grupo diferente. En otros casos, como la eliminación de elementos de trabajo o las canalizaciones, ser miembro de los administradores de la colección de proyectos no omite los permisos Denegar establecidos en otro lugar.

  • Cambiar un permiso para un grupo cambia ese permiso para todos los usuarios que son miembros de ese grupo. Es decir, según el tamaño del grupo, es posible que el cambio de un solo permiso afecte a la capacidad de centenares de usuarios para realizar sus trabajos. Por tanto, asegúrese de que entiende el impacto antes de realizar un cambio.

Herencia de permisos y grupos de seguridad

Algunos permisos se administran mediante 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 los miembros del grupo. Por ejemplo, a los miembros del grupo Colaboradores o Project grupo Administradores se les asignan los permisos establecidos como Permitidos a esos grupos.

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

  • Los usuarios heredan permisos de los grupos a los que pertenecen. Cuando se permite un permiso para un usuario directamente o a través de la pertenencia a un grupo que tiene ese permiso, y se deniega, ya sea directamente o a través de la pertenencia a grupos, se deniega el permiso.

    Los miembros de Project administradores de recopilación o administradores de Team Foundation 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 se heredan de area-1/sub-area-1, si el mismo permiso no se permite ni 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 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 "área-1/sub-área-1" recibirá en última instancia un permiso 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 nueva interfaz de usuario para la página Configuración permisos de Project, consulte Habilitación de características en versión preliminar.

Permissions dialog, preview page, Why link annotated.

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

La interfaz de usuario de vista previa de los permisos de Project página Configuración no está disponible para Azure DevOps Server 2020 y versiones anteriores.

Al asignar permisos

Sí:

  • Use Azure Active Directory, Active Directory o Windows grupos de seguridad al administrar muchos usuarios.
  • Al agregar equipos, considere qué permisos quiere asignar a los responsables de equipo, scrummasters y otros miembros de equipos que puede que necesiten crear y modificar rutas de acceso de área, rutas de acceso de iteración y consultas.
  • Al agregar muchos equipos, considere la posibilidad de crear un grupo personalizado administradores de equipo en el que asigne un subconjunto de los permisos disponibles para Project Administradores.
  • Considere la posibilidad de conceder permiso de contribución a los usuarios o grupos de elementos de trabajo 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 contengan distintos niveles de permisos. En algunos casos, un nivel de permiso Denegar puede invalidar un nivel de permiso Permitir .
  • No cambie las asignaciones predeterminadas realizadas a los grupos de usuarios válidos. Si quita o establece el permiso Ver información de nivel de instancia en Denegar para uno de los grupos Usuarios válidos, ningún usuario del grupo puede acceder al proyecto, la colección o la implementación, según el grupo que establezca.
  • No asigne permisos que se indiquen como "Asignar solo a cuentas de servicio" a cuentas de usuario.

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 para obtener más información.

  • Roles de seguridad de fuente de artefactos o 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.

    Nota:

    Los miembros de los grupos administradores de Project o administradores de recopilación de Project pueden administrar todas las herramientas de equipo para todos los equipos.

Características en vista previa

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

Pasos siguientes

Permisos y acceso predeterminado