Acerca de la seguridad, la autenticación y la autorización

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

Azure DevOps emplea muchos conceptos de seguridad para garantizar que solo los usuarios que deben tener acceso a características, funciones y datos tengan acceso. Las cuentas obtienen acceso a Azure DevOps mediante la autenticación de sus credenciales de seguridad y la autorización de sus derechos de cuenta para acceder a una característica o función.

Este artículo se basa en la información proporcionada en Introducción a los permisos, el acceso y los grupos de seguridad. Los administradores se benefician de comprender los tipos de cuenta, los métodos de autenticación, los métodos de autorización y las directivas que se usan para proteger Azure DevOps.

---

Tipos de cuenta

• Usuarios
• Propietario de la organización
• Cuentas de servicio
• Entidades de servicio o identidades administradas
• Agentes de trabajo

Autenticación

• Credenciales de usuario
• Autenticación de Windows.
• Autenticación en dos fases (2FA)
• Autenticación de clave SSH
• Tokens de acceso personal
• Configuración de Oauth
• Biblioteca de autenticación de Active Directory

Autorización

• Pertenencia a grupos de seguridad
• Control de acceso basado en rol
• Niveles de acceso
• Marcas de característica
• Permisos y espacio de nombres de seguridad

Directivas

• Dirección URL de la directiva de privacidad
• Directivas de seguridad y conexión de aplicaciones
• Directivas de usuario
• Repositorio de Git y directivas de rama

---

Importante

Azure DevOps ya no admite la autenticación de credenciales alternativas desde el 2 de marzo de 2020. Si sigue usando credenciales alternativas, le recomendamos encarecidamente cambiar a un método de autenticación más seguro (por ejemplo, tokens de acceso personal). Más información.

Tanto nuestro servicio en la nube, Azure DevOps Services y servidor local, Azure DevOps Server, admiten proyectos de desarrollo de software, desde la planificación hasta la implementación. Azure DevOps usa la infraestructura de plataforma como servicio de Microsoft Azure y muchos de los servicios de Azure, incluidas las bases de datos de Azure SQL, para ofrecer un servicio confiable y globalmente disponible para los proyectos de desarrollo.

Para obtener más información sobre los pasos que Microsoft realiza para mantener los proyectos en Azure DevOps Services seguros, disponibles, seguros y privados, consulte este documento técnico, Azure DevOps Services Información general sobre la protección de datos.

Cuentas

Aunque los principales tipos de cuentas de interés son las cuentas de usuario humanas que se agregan a su organización o proyecto, Azure DevOps admite otros tipos de cuentas para realizar diversas operaciones. Estos incluyen los siguientes tipos de cuenta.

• Propietario de la organización: creador de una organización Azure DevOps Services o propietario asignado. Para obtener información sobre quién es el propietario de la organización para su organización, consulte Búsqueda del propietario de la organización.
• Cuentas de servicio: cuentas internas de Azure DevOps que se usan para admitir un servicio específico, como el servicio de grupo de agentes, PipelinesSDK. Para obtener descripciones de las cuentas de servicio, consulte Grupos de seguridad , cuentas de servicio y permisos.
• Entidades de servicio o identidades administradas: aplicaciones de Microsoft Entra o identidades administradas que se han agregado a su organización para realizar acciones en nombre de una aplicación de terceros. Algunas entidades de servicio hacen referencia a cuentas internas de Azure DevOps para admitir operaciones internas.
• Agentes de trabajo: cuentas internas usadas para ejecutar trabajos específicos según una programación normal.
• Cuentas de terceros: cuentas que requieren acceso para admitir webhooks, conexiones de servicio u otras aplicaciones de terceros.

A lo largo de estos documentos, los usuarios pueden hacer referencia a todas las identidades que se han agregado al Centro de usuarios, que pueden incluir usuarios humanos y entidades de servicio.

El medio más eficaz para administrar cuentas es agregarlas a grupos de seguridad.

Nota

El propietario de la organización y los miembros del grupo Administradores de la colección de proyectos tienen acceso total a la mayoría de las características y funciones.

Authentication

La autenticación comprueba una identidad de cuenta en función de las credenciales proporcionadas al iniciar sesión en Azure DevOps. Estos sistemas se integran con y dependen de las características de seguridad proporcionadas por estos otros sistemas:

• Microsoft Entra ID
• Cuenta de Microsoft (MSA)
• Active Directory (AD)

Microsoft Entra ID y MSA admiten la autenticación en la nube. Se recomienda el identificador de Entra de Microsoft cuando necesite administrar un gran grupo de usuarios. De lo contrario, si tiene una base de usuarios pequeña que accede a su organización en Azure DevOps, puede usar cuentas de Microsoft. Para más información, consulte Acerca del acceso a Azure DevOps con el identificador de Microsoft Entra.

En el caso de las implementaciones locales, se recomienda AD al administrar un gran grupo de usuarios. Para más información, consulte Configuración de grupos para su uso en implementaciones locales.

Métodos de autenticación, integración con otros servicios y aplicaciones

Otras aplicaciones y servicios se pueden integrar con servicios y recursos en Azure DevOps. Para acceder a la cuenta sin pedir credenciales de usuario varias veces, las aplicaciones pueden usar los siguientes métodos de autenticación.

• Tokens de acceso personal para generar tokens en su nombre:

  • Acceso a recursos o actividades específicos, como compilaciones o elementos de trabajo
  • Clientes como Xcode y NuGet que requieren nombres de usuario y contraseñas como credenciales básicas y no admiten cuentas de Microsoft y características de Microsoft Entra, como la autenticación multifactor.
  • Acceso a las API REST de Azure DevOps

• OAuth de Azure DevOps para generar tokens en nombre de los usuarios para acceder a las API REST. Las API de cuentas y perfiles solo admiten OAuth.

• Autenticación SSH para generar claves de cifrado para ti mismo cuando use Linux, macOS o Windows y ejecute Git para Windows y no pueda usar Administradores de credenciales de Git o tokens de acceso personal para la autenticación HTTPS.

• Entidades de servicio o identidades administradas para generar tokens de Microsoft Entra en nombre de una aplicación o servicio, que normalmente automatiza algún flujo de trabajo que necesita acceder a los recursos de Azure DevOps. La mayoría de las acciones realizadas tradicionalmente por una cuenta de servicio y un PAT se pueden realizar mediante una entidad de servicio o una identidad administrada.

De forma predeterminada, la cuenta o colección permite el acceso a todos los métodos de autenticación. Puede limitar el acceso, pero debe restringir específicamente el acceso para cada método. Al denegar el acceso a un método de autenticación, ninguna aplicación puede usar ese método para acceder a su cuenta. Cualquier aplicación que anteriormente tenía acceso obtiene un error de autenticación y no puede acceder a su cuenta.

Para más información sobre cómo se almacenan las credenciales, consulte Almacenamiento de credenciales para Azure DevOps.

Para obtener más información sobre cómo elegir el mecanismo de autenticación adecuado, consulte Guía para la autenticación.

Autorización

La autorización comprueba que la identidad que intenta conectarse tiene los permisos necesarios para acceder a un servicio, una característica, una función, un objeto o un método. La autorización siempre se produce tras una autenticación correcta. Si una conexión no se autentica, se produce un error antes de que se realice la comprobación de autorización. Si la autenticación de una conexión se realiza correctamente, es posible que todavía no se permita una acción específica porque el usuario o grupo no tenía autorización para realizar esa acción.

La autorización depende de los permisos asignados a la cuenta. Los permisos se conceden directamente a una cuenta o a través de la pertenencia a un grupo de seguridad o a un rol de seguridad. Los niveles de acceso y las marcas de características también pueden conceder o restringir el acceso a una característica. Para obtener más información sobre estos métodos de autorización, consulte Introducción a los permisos, el acceso y los grupos de seguridad.

Espacios de nombres y permisos de seguridad

Los espacios de nombres de seguridad almacenan datos que determinan el nivel de acceso que las cuentas de Azure DevOps tienen que realizar una acción específica en un recurso específico. Cada familia de recursos, como los elementos de trabajo o los repositorios de Git, se protege a través de un espacio de nombres único. Cada espacio de nombres de seguridad contiene cero o más listas de control de acceso (ACL). Cada ACL contiene un token, una marca heredada y un conjunto de cero o más entradas de control de acceso (ACE). Cada ACE contiene un descriptor de identidad, una máscara de bits de permisos permitida y una máscara de bits de permisos denegada.

Para obtener más información, consulte Security namespaces and permission reference (Referencia de permisos y espacios de nombres de seguridad).

Directivas de seguridad

Para proteger la organización y el código, puede establecer muchas directivas. En concreto, puede habilitar o deshabilitar las siguientes directivas:

General

• Dirección URL de la directiva de privacidad: especifica una dirección URL que vincula al documento personalizado que describe cómo se controla la privacidad de los datos internos y externos de los invitados. Para obtener más información, consulte Incorporación de una dirección URL de directiva de privacidad para su organización.

Directivas de seguridad y conexión de aplicaciones

Use la directiva de inquilinos de Microsoft Entra para restringir la creación de nuevas organizaciones solo a los usuarios deseados. Esta directiva está desactivada de forma predeterminada y solo es válida cuando la organización está conectada a Microsoft Entra ID. Consulte Restringir la creación de la organización para obtener más detalles.

Las siguientes directivas determinan el acceso que desea conceder a los usuarios y las aplicaciones a las organizaciones:

• Acceso a aplicaciones de terceros a través de OAuth.
• Acceso de autenticación SSH.
• Permitir proyectos públicos: cuando está habilitado, los usuarios pueden crear proyectos públicos que permitan a los no miembros de un proyecto y usuarios que no hayan iniciado sesión de solo lectura, acceso limitado a los artefactos y servicios del proyecto. Obtenga más información en Hacer público el proyecto.
• Registrar eventos de auditoría : active la capacidad de realizar un seguimiento de los eventos y flujos de auditoría de su organización.
• Habilite la validación de la directiva de acceso condicional (CAP) de Microsoft Entra.

Directivas de usuario

• Acceso de invitado externo (solo válido cuando la organización está conectada a Microsoft Entra ID.): cuando está habilitada, las invitaciones se pueden enviar a cuentas de correo electrónico de usuarios que no son miembros del identificador de Microsoft Entra del inquilino a través de la página Usuarios . Para obtener más información, consulte Incorporación de usuarios externos a su organización.
• Permitir que los administradores del equipo y del proyecto inviten a nuevos usuarios: solo es válido cuando la organización está conectada a Microsoft Entra ID. Cuando está habilitado, los administradores de equipos y proyectos pueden agregar usuarios a través de la página Usuarios . Para obtener más información, vea Restringir las nuevas invitaciones de usuario de Los administradores de proyecto y equipo.
• Solicitar acceso: solo es válido cuando la organización está conectada a Microsoft Entra ID. Cuando está habilitado, los usuarios pueden solicitar acceso a un recurso. Una solicitud da como resultado una notificación por correo electrónico a los administradores que solicitan revisión y acceso, según sea necesario. Para obtener más información, consulte Incorporación de usuarios externos a su organización.
• Invitar a usuarios de GitHub: solo es válido cuando la organización no está conectada a Microsoft Entra ID. Cuando se habilita, los administradores pueden agregar usuarios basados en sus cuentas de usuario de GitHub desde la página Usuarios . Para obtener más información, consulte Preguntas más frecuentes sobre autenticación e invitación a usuarios de GitHub.

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

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 , se restringe de las siguientes maneras:

• Solo puede acceder a las páginas Información general y Proyectos de configuración de la organización.
• Solo se pueden conectar y ver los proyectos a los que se han agregado explícitamente (consulte Agregar usuarios a un proyecto o equipo.
• Solo se pueden seleccionar identidades de usuario y grupo que se han agregado explícitamente al proyecto al que están conectados.

Para obtener más información, consulte Administrar su organización, Limitar la visibilidad del usuario para proyectos y más y Administrar características en versión preliminar.

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.

Directivas de repositorio y rama de Git

• Configuración de las directivas y la configuración del repositorio
• Configuración de directivas de rama
• Configurar directiva de rama para un servicio externo
• Usar Azure Functions para crear directivas de rama personalizadas

seguridad de Azure Repos y Azure Pipelines

Dado que los repositorios y las canalizaciones de compilación y versión representan desafíos de seguridad únicos, se emplean otras características más allá de las características que se describen en este artículo. Para obtener más información, consulte los siguientes artículos.

• Protección de Azure Pipelines
• Planear cómo proteger las canalizaciones de YAML
• Protección de repositorios
• Recursos de canalización
• Recomendaciones para estructurar proyectos de forma segura en la canalización
• Seguridad mediante plantillas
• Uso seguro de variables y parámetros en la canalización
• Recomendaciones para proteger la infraestructura compartida en Azure Pipelines
• Otras consideraciones de seguridad

Pasos siguientes

Referencia de permisos y grupos

Artículos relacionados

• Permisos predeterminados y asignaciones de acceso
• Agregar o eliminar usuarios mediante Microsoft Entra ID
• Configuración de grupos para su uso en implementaciones locales
• Configuración de HTTPS con capa de sockets seguros (SSL)
• Permisos predeterminados y asignaciones de acceso