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

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

Cuando se trata de acceder a una Azure DevOps, resulta útil comprender los siguientes conceptos clave.

  • Todos los usuarios agregados a Azure DevOps suelen agregarse a uno o varios grupos de seguridad.
  • A los grupos de seguridad se les asignan permisos que permiten o deniegan el acceso a una característica.
  • Los miembros del grupo de seguridad heredan los permisos asignados al grupo.
  • A cada usuario también se le asigna un nivel de acceso que concede o restringe el acceso para seleccionar características del portal web.
  • Los permisos se establecen en varios niveles para la mayoría de los objetos, como repositorios, canalizaciones, rutas de acceso de área, entre otros.
  • Otros permisos se administran mediante asignaciones basadas en roles, como el rol de administrador de equipo, el rol de administración de extensiones y varios roles de recursos de canalización.
  • Por último, a medida que se presentan nuevas características, es posible que tenga que habilitar su marca de características para acceder a ellas.

Por ejemplo, los colaboradores individuales se agregan al grupo de seguridad Colaboradores, que proporciona acceso de lectura y escritura a repositorios, seguimiento de trabajo, canalizaciones, etc. Además, a los colaboradores se les concede principalmente acceso Básico. Si necesitan acceso a los servicios de prueba, se les puede conceder acceso avanzado o básico + Test Plans acceso. Los permisos se pueden aplicar a un proyecto u objetos específicos dentro del proyecto, como repositorios de Git, ramas, canalizaciones, rutas de acceso de área, etc. O bien, se pueden aplicar a toda una organización o colección. Cada área funcional usa grupos de seguridad para simplificar la administración en toda la implementación.

Los administradores administran grupos de seguridad y permisos desde el contexto de administración del portal web. Los colaboradores también administran permisos para los objetos que crean o poseen desde el portal web. Los permisos se establecen automáticamente en función del grupo al que agregue usuarios o en función del objeto, proyecto, colección o nivel de servidor al que agregue usuarios o grupos.

Para más información, revise la información proporcionada en este artículo y en los artículos siguientes:

Grupos de seguridad y pertenencia

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

  • Al agregar un grupo de seguridad personalizado. Puede crear grupos de seguridad personalizados en los niveles siguientes:
    • Nivel de objeto, como para canalizaciones, repositorios, rutas de acceso de área, etc.
    • Nivel del proyecto
    • Organización o nivel de colección
    • Nivel de servidor (solo en el entorno local)
  • Al agregar un equipo, se crea un grupo de seguridad de equipo.

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

  • La administración de pertenencia admite la adición de cuentas de usuario y grupos individuales 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, 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, una carpeta, una canalización de compilación o una consulta compartida. La configuración de permisos corresponde a Permitir, Denegar, Permitir heredado, Denegar heredado y No establecer. Para más información sobre la herencia, consulte Grupos de seguridad y herencia de permisos más adelante en este artículo.

  • La administración del nivel de acceso controla el acceso a las características proporcionadas a través del portal web, la aplicación web para Azure DevOps. En función de lo que se haya adquirido para un usuario, los administradores establecen el nivel de acceso del usuario en Básico, Básico + Prueba, VS Enterprise (anteriormente Avanzado) o Parte interesada.

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

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

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

Puede crear grupos locales o grupos Active Directory (AD) para administrar los usuarios. Si decide usar grupos, asegúrese de que la pertenencia a esos grupos se limita a usuarios válidos. Dado que la pertenencia a grupos puede ser modificada por sus propietarios en cualquier momento, si esos propietarios no consideraron el acceso Azure DevOps Server cuando crearon esos grupos, sus cambios en la pertenencia pueden provocar efectos secundarios no deseados en el servidor.

La mayoría de los usuarios se asignan al grupo Colaboradores de un proyecto para proporcionarles acceso a las características a las que necesitan acceder. Los administradores deben agregarse al grupo Project de recopilación o Project administradores.

Active Directory y Azure Active Directory de seguridad

Puede rellenar grupos de seguridad agregando usuarios individuales. Sin embargo, para facilitar la administración, es más fácil si rellena estos grupos mediante Azure Active Directory (Azure AD) para grupos de usuarios de Azure DevOps Services y Active Directory (AD) o Windows 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 Azure DevOps deben iniciar sesión con cuentas Microsoft y debe administrar el acceso a las cuentas por 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 la organización está conectada a Azure Active Directory, hay una serie de 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, Directivas de seguridad.

Para administrar el acceso de la organización 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 Usuarios válidos de recopilación: todos los miembros agregados a grupos de nivel de organización.
  • Project Usuarios válidos: todos los miembros agregados a un grupo de nivel de proyecto.
  • Servidor \ Azure DevOps Usuarios válidos: todos los miembros agregados a grupos de nivel de servidor.
  • ProjectCollectionName \ Project Usuarios válidos de recopilación: 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.
  • Servidor \ Usuarios válidos de Team Foundation: todos los miembros agregados a grupos de nivel de servidor.
  • ProjectCollectionName \ Project Usuarios válidos de recopilación: 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 e 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 dentro de una colección. Si necesita restringir el acceso a la vista, puede establecer restriccionesa 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 podrá acceder al proyecto, la recopilación o la implementación, en función del grupo que establezca.

Project grupo de usuarios con ámbito de aplicación

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

Para restringir usuarios selectos, como partes interesadas, Azure Active Directory usuarios invitados o miembros de un grupo de seguridad determinado, puede habilitar la característica de vista previa Limitar visibilidad de usuarios para proyectos para la organización. Una vez habilitado, cualquier usuario o grupo agregado al grupo Usuarios con ámbito Project, tiene restringido el acceso a las páginas de Configuración organización, excepto para Información general y Proyectos ; y están restringidos a acceder solo a los proyectos a los que se han agregado.

Para habilitar esta característica, consulte Administración o habilitación de 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, los usuarios sin acceso a un proyecto no pueden ver los grupos que solo tienen permisos para un proyecto específico. 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 Adició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 de 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 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 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 siguiente imagen, 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.

Asignación de imágenes conceptuales de grupos de seguridad predeterminados a niveles de permisos, nube

Como se muestra en la siguiente imagen, 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 para permisos de nivel de servidor.

Asignación de imágenes conceptuales de grupos de seguridad predeterminados a niveles de permisos, en el entorno local

Imagen conceptual de grupos de seguridad y niveles de permisos, TFS-2018 y versiones anteriores

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

Estados de los permisos

Hay cinco posibles asignaciones 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 o restringe explícitamente a los usuarios la realización de tareas específicas y normalmente se heredan de la pertenencia a grupos.

  • No establecido deniega implícitamente a los usuarios la capacidad de realizar tareas que requieren ese permiso, pero permite que la pertenencia a un grupo que tiene ese conjunto de permisos tenga prioridad, también conocido como Permitir (heredado) o Permitir heredado y 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 establecido 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 Project Collection Administrators o Team Foundation Administrators siempre pueden obtener el permiso aunque se les deniegue ese permiso en otro grupo. En otros casos, como la eliminación de elementos de trabajo o las canalizaciones, ser miembro de los administradores de recopilación de proyectos no omite los permisos de denegación establecidos en otra parte.

  • 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.

Grupos de seguridad y herencia de permisos

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 invalidarse. Los grupos de seguridad asignan un conjunto de permisos a esos miembros del grupo. Por ejemplo, a los miembros del grupo Colaboradores o Project De administradores se les asignan los permisos que se establecen como Permitidos para esos grupos.

Si un permiso no se permite o se 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 al grupo, se deniega el permiso.

    Los miembros Project 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 elementos de trabajo son la excepción a esta regla.

  • Los permisos de nivel de objeto asignados 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 establecidos en son heredados por , si no se permite o se deniega explícitamente el mismo area-1 area-1/sub-area-1 permiso para area-1/sub-area-1 . Si se establece explícitamente un permiso para un objeto, como , el nodo primario no se hereda, independientemente de si se area-1/sub-area-1 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 es la herencia. Por ejemplo, un usuario cuyos permisos se establecen explícitamente en Denegar en "area-1" pero también están establecidos explícitamente en Permitir para "area-1/sub-area-1" recibirá en última instancia un permiso en "area-1/sub-area-1".

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

Nota

Para habilitar la nueva interfaz de usuario para la página Project permisos Configuración, vea Habilitar características en versión preliminar.

Cuadro de diálogo Permisos, página de vista previa, Vínculo anotado.

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

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

Al asignar permisos

Hacer:

  • Use Azure Active Directory, Active Directory o Windows 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 de administradores de equipos donde asigne un subconjunto de los permisos disponibles para Project administradores.
  • Considere la posibilidad de conceder a las carpetas de consulta de elementos de trabajo el permiso Contribuir a usuarios o grupos que requieran la capacidad de crear y compartir consultas de elementos de trabajo para el proyecto.

No:

  • No asigne un permiso Denegar al grupo administradores de Project de recopilación o Project administradores en ningún nivel.
  • 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 podrá acceder al proyecto, la recopilación o la implementación, en función del grupo que establezca.
  • No asigne permisos que se anotó como "Asignar solo a cuentas de servicio" a cuentas de usuario.

Permisos basados en roles

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

Marcas de característica

Acceso para seleccionar, las nuevas características se controlan mediante marcas de características. Periódicamente, Azure DevOps Services nuevas características al colocarlas detrás de una marca de características. Las características de una versión preliminar privada requieren que el propietario de la organización solicite que la característica esté activada. Otras características se pueden presentar como una característica en versión preliminar que los usuarios generales pueden habilitar o deshabilitar.

Para más información, consulte Administración o habilitación de características.

Pasos siguientes