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 a través de asignaciones basadas enroles, 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:

• Permisos y acceso predeterminado
• Solución de problemas de permisos

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 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 entre 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,Denegarheredado 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 de 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 ha comprado 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.

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 Azure DevOps Services y Active Directory (AD) o grupos de usuarios Windows para Azure DevOps Server. Este método le 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.

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.

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.

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

Para obtener una descripción de cada grupo de seguridad predeterminado, vea Grupos de seguridad, cuentas de 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:
  • Deny
  • 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 permiso establecido tenga prioridad, también conocida como Permitir (heredar) 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 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, el hecho de ser miembro de los administradores de la colecció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.

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 invalidarse. Los grupos de seguridad asignan un conjunto de permisos a esos miembros del grupo. Por ejemplo, a los miembros del grupo Colaboradoreso Project administradores 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, puede heredarse de dos maneras.

• Los usuarios heredan los 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 Project collection administrators o team foundation administrators 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 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 en la jerarquía. Es decir, los permisos de un usuario establecidos en son heredados por , si no se permite o deniega explícitamente el mismo permiso area-1area-1/sub-area-1 para area-1/sub-area-1 . Si un permiso se establece explícitamente 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 están establecidos explícitamente en Denegar en "area-1" pero también se establecen explícitamente en Permitir para "area-1/sub-area-1" recibirá en última instancia una allow en "area-1/sub-area-1".

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

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 las 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 principales y los vínculos para obtener más información.

• Roles de seguridad de fuente de paquetes o artefactos:los roles admiten varios niveles de permiso 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 de equipo pueden administrar todas las herramientas de equipo.

  Nota

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

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 colocándolas 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

Artículos relacionados