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

  • Artículo
  • 12 minutos para leer

Tipos de cuenta

  • Usuarios
  • Propietario de la organización
  • Cuentas de servicio
  • Entidades de servicio
  • 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
  • Active Directory de autenticación

Autorización

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

Directivas

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

Tipos de cuenta

  • Usuarios
  • Cuentas de servicio
  • Entidades de servicio
  • 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
  • Active Directory de autenticación

Autorización

  • Pertenencia a grupos de seguridad
  • Permisos basados en roles
  • Niveles de acceso
  • Marcas de característica
  • Permisos de espacios de & nombres de seguridad

Directivas

  • Directivas de repositorio y rama de Git

Importante

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

Tanto el servicio en la nube, Azure DevOps Services y el servidor local, Azure DevOps Server, admiten proyectos de desarrollo de software, desde la planeación hasta la implementación. Azure DevOps 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 disponible globalmente 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 estas 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 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 laorganización: creador de una Azure DevOps Services organización o propietario asignado. Para saber quién es el propietario de la organización, consulte Aumentar los permisos; busque un administrador.
  • Cuentas deservicio: cuentas Azure DevOps internas que se usan para admitir un servicio específico, como Servicio de grupo de agentes, PipelinesSDK. Para obtener descripciones de las cuentas de servicio, vea Grupos de seguridad, cuentas de servicio y permisos.
  • Entidades de servicio:cuentas de Azure DevOps internas para admitir operaciones internas.
  • Agentes de trabajo:cuentas internas que se usan para ejecutar trabajos específicos de forma periódica.
  • Cuentas de terceros:cuentas que requieren acceso para admitir web hooks, conexiones de servicio u otras aplicaciones de terceros.
  • Cuentas deservicio: cuentas Azure DevOps internas que se usan para admitir un servicio específico, como Servicio de grupo de agentes, PipelinesSDK. Para obtener descripciones de las cuentas de servicio, vea Grupos de seguridad, cuentas de servicio y permisos.
  • Entidades de servicio:cuentas de Azure DevOps internas para admitir operaciones internas.
  • Agentes de trabajo:cuentas internas que se usan para ejecutar trabajos específicos de forma periódica.
  • Cuentas de terceros:cuentas que requieren acceso para admitir web hooks, conexiones de servicio u otras aplicaciones de terceros.

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

Nota

Al propietario de la organización y a los miembros del grupo Project recopilación de recursos se les concede 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 Azure DevOps. Estos sistemas se integran con y se basan en las características de seguridad proporcionadas por estos sistemas adicionales:

  • Azure Active Directory (Azure AD)
  • Cuenta de Microsoft (MSA)
  • Active Directory (AD)

Azure AD MSA admiten la autenticación en la nube. Se recomienda Azure AD cuando necesite administrar un grupo grande de usuarios. De lo contrario, si tiene una base de usuarios pequeña que accede a su organización Azure DevOps, puede usar cuentas de Microsoft. Para obtener más información, vea Acerca del acceso Azure DevOps con Azure Active Directory (Azure AD).

En el caso de las implementaciones locales, se recomienda AD al administrar un grupo grande 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 los servicios y recursos de Azure DevOps. Para acceder a su cuenta sin pedir varias veces credenciales de usuario, las aplicaciones pueden usar los siguientes métodos de autenticación.

  • Tokens de acceso personal para generar tokens 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 características de cuenta microsoft y Azure Active Directory como la autenticación multifactor
    • Acceso Azure DevOps API REST

  • OAuth para generar tokens para acceder a las API REST. Las API cuentas y perfiles solo admiten OAuth.

  • Autenticación SSH para generar claves de cifrado cuando se usa Linux, macOS o Windows que ejecuta Git para Windows y no puede usar administradores de credenciales de Git ni tokens de acceso personal para la autenticación HTTPS.

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. Cuando se deniega 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 previamente tuviera acceso recibe un error de autenticación y no puede acceder a su cuenta.

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

Para obtener más información sobre cómo elegir el mecanismo de autenticación correcto, vea Guía para la autenticació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 después de 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 pueda realizar 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 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 Azure DevOps tienen que realizar una acción específica en un recurso específico. Cada familia de recursos, como elementos de trabajo o 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 de herencia 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 permitidos y una máscara de bits de permisos denegados.

Para más información, consulte 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

  • Acceso a aplicaciones de terceros a través de OAuth:cuando está habilitado, permite que las aplicaciones de terceros se conecten mediante OAuth. Para más información, consulte Cambio de las directivas de seguridad de conexión de aplicaciones para su organización.
  • Acceso de autenticación SSH:cuando está habilitado, permite que las aplicaciones se conecten mediante la autenticación SSH. Para más información, consulte Cambio de las directivas de seguridad de conexión de aplicaciones para su organización.
  • Permitirproyectos públicos: cuando se habilita, los usuarios pueden crear proyectos públicos que permitan a los usuarios que no son miembros de un proyecto y a los usuarios que no han iniciado sesión en solo lectura, acceso limitado a los artefactos y servicios del proyecto. Obtenga más información en Hacer que el proyecto sea público y Habilitar el acceso anónimo a los proyectos de su organización.
  • Restringir la creación de la organización Azure AD través de una directiva de inquilinos ( solo válida cuando la organización tiene el respaldo deAzure Active Directory.): cuando está habilitada, impide que los usuarios creen organizaciones de Azure DevOps adicionales que el Azure AD. Para obtener información sobre cómo habilitar, consulte Restricción de la creación de la organización a través Azure AD directiva de inquilino.
  • Habilitar Azure Active Directory (Azure AD) validación de la directiva de acceso condicional (CAP) ( solo es válida cuando la organización tiene el respaldo deAzure Active Directory.): cuando está habilitada, permite establecer condiciones adicionales para acceder a la organización. Dependiendo de las condiciones que cumpla el usuario, puede requerir autenticación multifactor, comprobaciones adicionales o bloquear el acceso. Esta directiva se establece en desactivada de forma predeterminada y solo se aplica a credenciales alternativas. Esta directiva no se aplica a las CAP establecidas en Azure AD, independientemente de la configuración de Azure DevOps. Para más información, consulte Cambio de las directivas de seguridad de conexión de aplicaciones para su organización.

Directivas de usuario

  • Acceso de invitado externo ( solo válido cuando la organización tiene el respaldo deAzure Active Directory.): cuando se habilita, se pueden enviar invitaciones a cuentas de correo electrónico de usuarios que no son miembros del inquilino Azure Active Directory a través de la página Usuarios. Para más información, consulte Adición de usuarios externos a la organización.
  • Permitir que los administradores de equiposy proyectos inviten a nuevos usuarios: solo es válido cuando la organización está Azure Active Directory. Cuando se habilita, los administradores de equipos y proyectos pueden agregar usuarios a través de la página Usuarios. Para más información, consulte Restringir nuevas invitaciones de usuario de Project administradores de equipos.
  • Solicitar acceso:solo es válido cuando la organización tiene el respaldo de Azure Active Directory. Cuando se habilita, los usuarios pueden solicitar acceso a un recurso. Una solicitud genera una notificación por correo electrónico a los administradores que solicitan revisión y acceso, según sea necesario. Para más información, consulte Adición de usuarios externos a la organización.
  • Invitar GitHub usuarios:solo es válido cuando la organización no está Azure Active Directory. Cuando se habilita, los administradores pueden agregar usuarios en función de sus GitHub de usuario desde la página Usuarios. Para más información, consulte Preguntas más frecuentes sobre la autenticación de GitHub usuarios.

Project-Scoped Usuarios

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 habilitada, todos los usuarios o grupos agregados al grupo Project de usuarios con ámbito de aplicación se restringen de las maneras siguientes:

  • Solo puede acceder a las páginas Información general y Proyectos de la Configuración.
  • Solo puede conectarse y ver los proyectos a los que se han agregado explícitamente (vea Agregar usuarios a un proyecto o equipo).
  • Solo puede 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 sobre limitar la visibilidad del usuario para los proyectos, vea Acerca de los proyectos, Limitar la visibilidad del usuario para los proyectos. Para habilitar la característica, consulte Administración o habilitación de características.

Directivas de repositorio y rama de Git

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

Azure Repos seguridad Azure Pipelines seguridad

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 que se analizan en este artículo. Para más información, consulte los siguientes artículos:

Pasos siguientes

Referencia de permisos y grupos

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

Azure DevOps emplea una serie de conceptos de seguridad para garantizar que solo los que deben tener acceso a características, funciones y datos tengan acceso. Las cuentas obtienen acceso a Azure DevOps a través de 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.