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

  • Artículo

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

Azure DevOps emplea varios conceptos de seguridad para garantizar que solo los usuarios autorizados puedan acceder a características, funciones y datos. Los usuarios 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 funciones o características específicas.

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 pueden beneficiarse 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

Tipos de cuenta

  • Usuarios
  • 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
  • Permisos basados en roles
  • Niveles de acceso
  • Marcas de característica
  • Permisos y espacio de nombres de seguridad

Directivas

  • Repositorio de Git y directivas de rama

Importante

Azure DevOps no admite la autenticación de credenciales alternativas. Si sigue usando credenciales alternativas, le recomendamos encarecidamente que cambie a un método de autenticación más seguro.

Tanto Azure DevOps Services (nube) como Azure DevOps Server (local) admiten el desarrollo de software desde la planeación hasta la implementación. Aprovechan la infraestructura y los servicios de plataforma como servicio de Microsoft Azure, incluidas las bases de datos de Azure SQL, para proporcionar un servicio confiable y globalmente disponible para los proyectos.

Para más información sobre cómo Microsoft garantiza que los proyectos de Azure DevOps Services sean seguros, disponibles, seguros y privados, consulte la introducción a la protección de datos de Azure DevOps Services.

Cuentas

Aunque las cuentas de usuario humanas son el enfoque principal, Azure DevOps también admite otros tipos de cuentas para distintas 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 buscar el propietario de la organización, consulte Buscar el propietario de la organización.
  • Cuentas de servicio: organización interna de Azure DevOps que se usa 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 agregadas a su organización para realizar acciones en nombre de una aplicación de terceros. Algunas entidades de servicio hacen referencia a la organización interna 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 nuestros artículos relacionados con la seguridad, "usuarios" hace referencia a todas las identidades agregadas al Centro de usuarios, que pueden incluir usuarios humanos y entidades de servicio.

  • Cuentas de servicio: organización interna de Azure DevOps que se usa 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 agregadas a su organización para realizar acciones en nombre de una aplicación de terceros. Algunas entidades de servicio hacen referencia a la organización interna 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.

La manera más eficaz de administrar cuentas es agregarlas a grupos de seguridad.

Nota:

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

Autenticación

La autenticación comprueba la identidad de una cuenta en función de las credenciales proporcionadas durante el inicio de sesión en Azure DevOps. Estos sistemas se integran con y dependen de las características de seguridad de los siguientes 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 usar el identificador de Entra de Microsoft para administrar un gran grupo de usuarios. Para que una base de usuarios pequeña acceda a su organización de Azure DevOps, las cuentas Microsoft son suficientes. 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 para 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 Azure DevOps. Para acceder a la cuenta sin pedir repetidamente credenciales de usuario, las aplicaciones pueden usar los métodos de autenticación siguientes:

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

    • 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 usted mismo cuando se usa Linux, macOS o Windows que ejecuta Git para Windows y no puede usar administradores de credenciales de Git ni PAT 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, normalmente automatizando flujos de trabajo que necesitan 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 mediante la restricción específica de 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 tuviera acceso recibe un error de autenticación y no puede acceder a su cuenta.

Vea los siguientes artículos para más información:

Authorization

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 no se autentica una conexión, se produce un error antes de que se realicen comprobaciones de autorización. Incluso si la autenticación se realiza correctamente, es posible que todavía no se pueda permitir una acción específica si el usuario o grupo carece de autorización.

La autorización depende de los permisos asignados al usuario, ya sea directamente 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 administrar el acceso a características específicas. 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 determinan los niveles de acceso de usuario para acciones específicas en los recursos.

  • Cada familia de recursos, como elementos de trabajo o repositorios de Git, tiene un espacio de nombres único.
  • Cada espacio de nombres contiene cero o más listas de control de acceso (ACL).
    • Cada ACL incluye un token, una marca de herencia y entradas de control de acceso (ACE).
    • Cada ACE tiene un descriptor de identidad, una máscara de bits de permisos permitido 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 varias directivas. En concreto, puede habilitar o deshabilitar las siguientes directivas:

General

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. Para obtener más información, consulte Restringir la creación de la organización.

Las siguientes directivas determinan el acceso concedido a los usuarios y las aplicaciones dentro de las organizaciones:

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 se habilita, 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 Conexión a GitHub/preguntas más frecuentes.

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, incluidas las listas de usuarios, las listas de proyectos, los detalles de facturación, los datos de uso, etc.

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 determinados usuarios, como partes interesadas, usuarios invitados de Microsoft Entra o miembros de un grupo de seguridad específico, 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 maneras siguientes:

  • Solo puede acceder a las páginas Información general y Proyectos de la configuración de la organización.
  • Solo se pueden conectar y ver los proyectos a los que se han agregado explícitamente.
  • Solo se pueden seleccionar identidades de usuario y grupo agregadas 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

La habilitación de la característica Limitar la visibilidad y la colaboración del usuario a proyectos específicos impide que los usuarios con ámbito de proyecto busquen usuarios agregados 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 una resolución está en curso. Para resolver este problema, deshabilite la característica Limitar la visibilidad y la colaboración del usuario a proyectos específicos en versión preliminar para la organización.

Directivas de repositorio y rama de Git

Para proteger el código, puede establecer varias directivas de repositorio y rama de Git. Para obtener más información, consulte los siguientes artículos.

seguridad de Azure Repos y Azure Pipelines

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

Pasos siguientes

Referencia de permisos y grupos