Acerca de la seguridad, la autenticación y la autorización
Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019 | TFS 2018
Azure DevOps emplea una serie de conceptos de seguridad para asegurarse de que solo aquellos que deben tener acceso a características, funciones y datos tienen 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
- 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
- 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 ya no admite la autenticación de credenciales alternativas desde el 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 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 que agrega 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: 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.
- 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: 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.
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.
Autenticación
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 sistemas adicionales:
- Azure Active Directory (Azure AD)
- Cuenta de Microsoft (MSA)
- Active Directory (AD)
Azure AD y MSA admiten la autenticación en la nube. Se recomienda Azure AD 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 Azure Active Directory (Azure AD).
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 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 Azure Active Directory, como la autenticación multifactor.
- Acceso a las API REST de Azure DevOps
OAuth para generar tokens para acceder a las API REST. Las API de cuentas y perfiles solo admiten OAuth.
Autenticación SSH para generar claves de cifrado cuando se usa Linux, macOS o Windows que ejecutan Git para Windows y no se pueden 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. 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 almacenamos las credenciales, consulte Almacenamiento de credenciales para Azure DevOps.
Para más información sobre cómo elegir el mecanismo de autenticación adecuado, consulte Instrucciones 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 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 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, vea 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 elementos de trabajo o repositorios de Git, se protege mediante 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 permitida y una máscara de bits de permisos denegada.
Para más información, consulte Security namespaces and permission reference (Espacios de nombres de seguridad y referencia de permisos).
Directivas de seguridad
Para proteger la organización y el código, puede establecer una serie de 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 se vincula al documento personalizado que describe cómo se controla la privacidad de los datos de invitado internos y externos. Para más información, consulte Adició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 inquilino de Azure Active Directory (Azure AD) 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 Azure Active Directory respalda la organización. Consulte Restringir la creación de la organización para obtener más detalles.
Estas 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 usuarios que no sean miembros de un proyecto y usuarios que no hayan iniciado sesión de solo lectura, con acceso limitado a los artefactos y servicios del proyecto. Obtenga más información en Make your project public (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 Azure Active Directory (Azure AD).
Directivas de usuario
- Acceso de invitado externo (solo válido cuando La organización está respaldada por Azure Active Directory). Cuando está habilitada, las invitaciones se pueden enviar a cuentas de correo electrónico de usuarios que no son miembros del inquilino de Azure Active Directory a través de la página Usuarios . Para más información, consulte Incorporación de usuarios externos a su organización.
- Permitir que los administradores de equipos y proyectos inviten a nuevos usuarios: solo es válido cuando La organización está respaldada por Azure Active Directory. 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 proyectos y equipos.
- Solicitud de acceso: solo es válido cuando Azure Active Directory respalda la organización. Cuando está habilitada, 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 más información, consulte Incorporación de usuarios externos a su organización.
- Invitar a usuarios de GitHub: solo es válido cuando Azure Active Directory no está respaldado por la organización. Cuando está habilitada, los administradores pueden agregar usuarios en función de sus cuentas de usuario de GitHub desde la página Usuarios . Para más información, consulte Autenticación de preguntas más frecuentes sobre la 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 de la organizació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.
Para restringir usuarios seleccionados, como partes interesadas, usuarios invitados de Azure Active Directory o miembros de un grupo de seguridad determinado, puede habilitar la característica Limitar la visibilidad y 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 tener acceso 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 (consulte Agregar usuarios a un proyecto o equipo.
- Solo se pueden seleccionar las 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 y la colaboración a proyectos específicos, consulte Administrar su organización, Limitar la visibilidad del usuario para proyectos y mucho más. Para habilitar la característica, consulte Administración o habilitación de características.
Repositorio de Git y directivas de rama
Para proteger el código, puede establecer una serie de directivas de repositorio y rama de Git. Para más información, consulte los siguientes artículos:
Azure Repos y seguridad de 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 descritas en este artículo. Para más información, consulte los siguientes artículos:
- Protección de Azure Pipelines
- Planeamiento de cómo proteger las canalizaciones de YAML
- Protección de repositorios
- Recursos de canalización
- Recomendaciones para estructurar de forma segura los proyectos de 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