Recomendaciones de seguridad

Artículo
08/14/2024

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

Al controlar la información y los datos, especialmente en una solución basada en la nube, como Azure DevOps Services, la seguridad debe ser la prioridad más alta. Aunque Microsoft garantiza la seguridad de la infraestructura en la nube subyacente, la configuración de la seguridad dentro de Azure DevOps es su responsabilidad.

Aunque no es obligatorio, la incorporación de procedimientos recomendados puede mejorar significativamente su experiencia y reforzar la seguridad. Las siguientes recomendaciones están diseñadas para ayudarle a mantener un entorno seguro de Azure DevOps.

Protección del entorno de Azure DevOps

Utilice los siguientes procedimientos recomendados para quitar usuarios, revisar los eventos de auditoría e integrarlos con microsoft Entra ID.

Quitar usuarios

Quitar usuarios inactivos de cuentas de Microsoft (MSA):quite directamente usuarios inactivos de su organización si usa MSA. No se pueden crear consultas para elementos de trabajo asignados a cuentas de MSA eliminadas.
Deshabilitar o eliminar cuentas de usuario de Microsoft Entra: si está conectado a Microsoft Entra ID, deshabilite o elimine la cuenta de usuario de Microsoft Entra mientras mantiene activa la cuenta de usuario de Azure DevOps. Esta acción le permite seguir consultando el historial de elementos de trabajo mediante el identificador de usuario de Azure DevOps.
Revocar PAT de usuario: revise y revoque periódicamente los PAT de usuario existentes para garantizar la administración segura de estos tokens de autenticación críticos.
Revocar permisos especiales concedidos a usuarios individuales: audite y revoque los permisos especiales concedidos a usuarios individuales para garantizar la alineación con el principio de privilegios mínimos.
Reasignar el trabajo de los usuarios eliminados: antes de quitar usuarios, vuelva a asignar sus elementos de trabajo a los miembros del equipo actuales para distribuir la carga de forma eficaz.

Uso de Microsoft Entra ID

Establecimiento de un sistema de identidad unificado: conecte Azure DevOps con el identificador de Microsoft Entra para crear un único plano para la identidad. Esta coherencia reduce la confusión y minimiza los riesgos de seguridad de los errores de configuración manual.
Implementar gobernanza específica: use el identificador de Entra de Microsoft para asignar distintos roles y permisos a grupos específicos en varios ámbitos de recursos. Esta acción garantiza el acceso controlado y se alinea con los procedimientos recomendados de seguridad.
Mejorar las características de seguridad: habilite otras características de seguridad con el identificador de Entra de Microsoft, como:
- Autenticación multifactor (MFA): requiere varios factores como la comprobación de contraseñas y teléfonos para la autenticación de usuario. Directivas de acceso condicional: defina reglas de acceso basadas en condiciones como la ubicación, el dispositivo o el nivel de riesgo.

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

Revisión de eventos de auditoría

Con su organización conectada a Microsoft Entra, realice las siguientes tareas para mejorar la seguridad y supervisar los patrones de uso:

Habilitar auditoría: realice un seguimiento y vea los eventos relacionados con las acciones, los permisos y los cambios del usuario.
Revise periódicamente los eventos de auditoría: busque patrones de uso inesperados, especialmente los administradores y otros usuarios.

Protección de la red

Las siguientes funciones son formas eficaces de mejorar la seguridad de la red cuando se trabaja con Azure DevOps.

Configurar listas de direcciones IP permitidas: restrinja el acceso a direcciones IP específicas para permitir el tráfico solo desde orígenes de confianza, lo que reduce la superficie expuesta a ataques.
Usar cifrado: cifre siempre los datos en tránsito y en reposo. Proteger los canales de comunicación mediante protocolos como HTTPS.
Validar certificados: asegúrese de que los certificados son válidos y emitidos por las autoridades de confianza al establecer conexiones.
Implementación de firewalls de aplicaciones web (WAF): filtre, supervise y bloquee el tráfico malintencionado basado en web con WAF para obtener una capa adicional de protección contra ataques comunes.

Para obtener más información, consulte Procedimientos recomendados de administración de aplicaciones.

Permisos de ámbito

El sistema controla los permisos en varios niveles(individual, colección, proyecto y objeto) y los asigna a uno o varios grupos integrados de forma predeterminada. Para mejorar la seguridad, realice las siguientes acciones:

Proporcionar acceso con privilegios mínimos: proporcione a los usuarios y servicios el acceso mínimo necesario para realizar sus funciones empresariales.
Deshabilitar herencia: siempre que sea posible, deshabilite la herencia. La herencia puede conceder accidentalmente acceso o permisos a usuarios inesperados debido a su naturaleza permitida de forma predeterminada. Para obtener más información, consulte la sección sobre la herencia de permisos.

Para obtener más información sobre los permisos, consulte los artículos siguientes:

Permisos de nivel de proyecto

Limitar el acceso a proyectos y repositorios: reduzca el riesgo de perder información confidencial e implementar código no seguro limitando el acceso a proyectos y repositorios. Use grupos de seguridad integrados o personalizados para administrar permisos.
Deshabilite "Permitir proyectos públicos": en la configuración de directiva de la organización, deshabilite la opción para crear proyectos públicos. Cambie la visibilidad del proyecto de público a privado según sea necesario. Los usuarios que no han iniciado sesión tienen acceso de solo lectura a proyectos públicos, mientras que a los usuarios que han iniciado sesión se les puede conceder acceso a proyectos privados y realizar cambios permitidos.
Restringir la creación de proyectos: impida que los usuarios creen nuevos proyectos para mantener el control sobre el entorno.

Acceso de invitado externo

Bloquear el acceso de invitado externo: deshabilite la directiva "Permitir que las invitaciones se envíen a cualquier dominio" para evitar el acceso de invitado externo si no hay necesidad empresarial.
Usar correos electrónicos o UPN distintos: use direcciones de correo electrónico diferentes o nombres principales de usuario (UPN) para cuentas personales y empresariales para eliminar la ambigüedad entre cuentas personales y relacionadas con el trabajo.
Agrupar usuarios invitados externos: coloque todos los usuarios invitados externos en un único grupo de Microsoft Entra y administre los permisos de este grupo correctamente. Quite las asignaciones directas para asegurarse de que las reglas de grupo se aplican a estos usuarios.
Reevaluar las reglas con regularidad: revise periódicamente las reglas en la pestaña Reglas de grupo de la página Usuarios. Considere cualquier cambio de pertenencia a grupos en el identificador de Microsoft Entra que pueda afectar a su organización. El id. de Entra de Microsoft puede tardar hasta 24 horas en actualizar la pertenencia dinámica a grupos y las reglas se vuelven a evaluar automáticamente cada 24 horas y cada vez que cambia una regla de grupo.

Para obtener más información, vea Invitados B2B en el identificador de Entra de Microsoft.

Administración de grupos de seguridad

Grupos de seguridad y usuarios

En la tabla siguiente se muestran recomendaciones para asignar permisos a grupos de seguridad y grupos de usuarios.

Hacer	No
Use microsoft Entra ID, Active Directory o grupos de seguridad de Windows cuando administre muchos usuarios.	*No cambie los permisos predeterminados para el grupo Usuarios válidos del proyecto* .** Este grupo puede acceder a la información del proyecto y verla. Para obtener más información, consulte Grupos de usuarios válidos.
Al agregar equipos, tenga en cuenta qué permisos desea asignar a los miembros del equipo que necesitan crear y modificar rutas de acceso de área, rutas de acceso de iteración y consultas.	No agregue usuarios a varios grupos de seguridad que contengan distintos niveles de permisos. En determinados casos, un nivel de permiso Denegar podría invalidar un nivel de permiso Permitir . Por ejemplo, imagine que tiene dos grupos de seguridad en el proyecto de Azure DevOps: Desarrolladores y evaluadores. El grupo Desarrolladores tiene el permiso para editar los elementos de trabajo establecidos en Permitir. Sin embargo, asegúrese de que algunos elementos de trabajo confidenciales no los edite nadie excepto algunas personas clave. Para ello, cree un nuevo grupo de seguridad denominado Editores de elementos confidenciales y establezca el permiso para editar elementos de trabajo en Denegar para este grupo. Si un usuario es miembro del grupo Desarrolladores y del grupo Editores de elementos confidenciales, el permiso Denegar del grupo Editores de elementos confidenciales tiene prioridad sobre el permiso Permitir del grupo Desarrolladores. Como resultado, este usuario no puede editar los elementos de trabajo confidenciales, aunque tengan el permiso Permitir en el grupo Desarrolladores . Este comportamiento garantiza que los permisos de denegación se aplican estrictamente, lo que proporciona un mayor nivel de seguridad y control sobre las acciones confidenciales en el entorno de Azure DevOps.
Al agregar muchos equipos, considere la posibilidad de crear un grupo personalizado administradores de equipo en el que asigne un subconjunto de los permisos disponibles para los administradores de proyectos.	*No cambie las asignaciones predeterminadas realizadas a los grupos Usuarios válidos del proyecto* .** Si quita o establece Ver información de nivel de instancia en Denegar para uno de los grupos Usuarios válidos del proyecto , ningún usuario del grupo puede tener acceso a cualquier proyecto, colección o implementación en el que establezca el permiso.
Considere la posibilidad de conceder permiso de colaboración a los usuarios o grupos que requieren la capacidad de crear y compartir consultas de elementos de trabajo para el proyecto.	*No asigne permisos que se indiquen como Asignar solo a cuentas de servicio a cuentas* de usuario.**
Mantenga los grupos lo más pequeños posible. El acceso debe estar restringido y los grupos deben auditarse con frecuencia.
Aproveche los roles integrados y utilice el valor predeterminado Colaborador para los desarrolladores. Los administradores se asignan al grupo de seguridad Administrador de proyecto para obtener permisos elevados, lo que les permite configurar los permisos de seguridad.

Acceso Just-In-Time para grupos de administración

Si tiene acceso administrador de colecciones de proyectos y administrador de proyectos, puede modificar la configuración de su organización o proyecto. Para mejorar la seguridad de estos grupos de administradores integrados, considere la posibilidad de implementar el acceso Just-In-Time mediante un grupo de Microsoft Entra Privileged Identity Management (PIM). Este enfoque permite conceder permisos elevados solo cuando sea necesario, lo que reduce el riesgo asociado al acceso permanente.

Configurar el acceso

Cree un grupo asignable de roles en microsoft Entra ID.
Agregue el grupo de Microsoft Entra al grupo de Azure DevOps.

Nota:

Al configurar el acceso Just-In-Time mediante un grupo de Microsoft Entra Privileged Identity Management (PIM), asegúrese de que cualquier usuario con acceso con privilegios elevados también conserva el acceso estándar a la organización. De este modo, pueden ver las páginas necesarias y actualizar sus permisos según sea necesario.

Uso del acceso

Active el acceso.
Actualice los permisos en Azure DevOps.
Realice la acción que requiere acceso de administrador.

Nota:

Los usuarios tienen acceso elevado en Azure DevOps hasta 1 hora después de que se desactive el acceso a su grupo de PIM.

Cuentas de servicio de ámbito

Crear cuentas de servicio de uso único: cada servicio debe tener su cuenta dedicada para minimizar el riesgo. Evite usar cuentas de usuario normales como cuentas de servicio.
Siga las convenciones de nomenclatura y documentación: use nombres claros y descriptivos para las cuentas de servicio y documente su propósito y sus servicios asociados.
Identificar y deshabilitar cuentas de servicio sin usar: revise e identifique periódicamente las cuentas que ya no están en uso. Deshabilite las cuentas sin usar antes de considerar la eliminación.
Restringir privilegios: limite los privilegios de la cuenta de servicio al mínimo necesario. Evite derechos de inicio de sesión interactivos para las cuentas de servicio.
Usar identidades independientes para lectores de informes: si usa cuentas de dominio para cuentas de servicio, use una identidad diferente para que los lectores de informes aíslen los permisos y eviten el acceso innecesario.
Usar cuentas locales para instalaciones de grupo de trabajo: al instalar componentes en un grupo de trabajo, use cuentas locales para cuentas de usuario. Evite las cuentas de dominio en este escenario.
Aprovechar las conexiones de servicio: use las conexiones de servicio siempre que sea posible para conectarse de forma segura a los servicios sin pasar variables secretas directamente a las compilaciones. Restringir las conexiones a casos de uso específicos.
Supervisar la actividad de la cuenta de servicio: implemente la auditoría y cree flujos de auditoría para supervisar la actividad de la cuenta de servicio.

Para más información, consulte Tipos de conexión de servicio comunes.

Conexiones de servicio de ámbito

Establecer el ámbito de las conexiones de servicio: limite el acceso mediante el ámbito de las conexiones de servicio de Azure Resource Manager a recursos y grupos específicos. Evite conceder derechos de colaborador amplios en toda la suscripción de Azure.
Uso de la federación de identidades de carga de trabajo: autenticación con recursos de Azure mediante OpenID Connect (OIDC) sin secretos. Cree automáticamente o manualmente la federación de identidades de carga de trabajo si tiene el rol Propietario para su suscripción de Azure, no se conecta a entornos de Azure Stack o Azure US Government y las tareas de extensiones de Marketplace que use admiten.
Grupos de recursos de ámbito: asegúrese de que los grupos de recursos solo contienen las máquinas virtuales (VM) o los recursos necesarios para el proceso de compilación.
Evite las conexiones de servicio clásicas: opte por las conexiones de servicio modernas de Azure Resource Manager en lugar de las clásicas, que carecen de opciones de ámbito.
Usar cuentas de servicio de equipo específicas de propósito: autentique las conexiones de servicio de servicio mediante cuentas de servicio de equipo específicas de propósito para mantener la seguridad y el control.

Para más información, consulte Tipos de conexión de servicio comunes.

Elección del método de autenticación adecuado

Seleccione los métodos de autenticación de los orígenes siguientes:

Considere la posibilidad de tener en cuenta las entidades de servicio y las identidades administradas
Uso de tokens de acceso personal (PAT) con moderación

Considere la posibilidad de tener en cuenta las entidades de servicio

Explore alternativas como entidades de servicio e identidades administradas:

Usar entidades de servicio: represente objetos de seguridad dentro de una aplicación de Microsoft Entra. Defina lo que una aplicación puede hacer en un inquilino determinado. Configure durante el registro de aplicaciones en Azure Portal. Configure para acceder a los recursos de Azure, incluido Azure DevOps. Resulta útil para las aplicaciones que necesitan acceso y control específicos.
Uso de identidades administradas: similar a la entidad de servicio de una aplicación. Proporcione identidades para los recursos de Azure. Permitir que los servicios que admiten la autenticación de Microsoft Entra compartan credenciales. Azure controla automáticamente la administración y la rotación de credenciales. Ideal para la administración de detalles de inicio de sesión sin problemas.

Uso de PAT con moderación

Ámbito de los PAT a roles específicos: asigne a los PAT solo los permisos necesarios para tareas específicas. Evite conceder acceso global a varias organizaciones o repositorios para minimizar el riesgo de uso indebido accidental.
Evite escribir o administrar permisos en compilaciones y versiones: los PAT no deben tener permisos de escritura ni de administración en compilaciones, versiones u otros recursos críticos. Restringir estos permisos ayuda a evitar acciones no deseadas que podrían afectar a las canalizaciones o implementaciones.
Establecer fechas de expiración y mantener el secreto de PAT: establezca siempre una fecha de expiración para los PAT. Revise y renueve periódicamente según sea necesario. Tratar los PAT como críticos como contraseñas, mantenerlos confidenciales y evitar el uso compartido público o la codificación rígida en el código de aplicación.
Evite la codificación rígida de los PAT en el código de aplicación: en lugar de insertar PAT directamente en el código, use archivos de configuración seguros o variables de entorno para almacenar y recuperar PAT dinámicamente. dinámicamente.
Auditar y revocar los PAT sin usar periódicamente: los administradores deben revisar periódicamente todas las PAT mediante las API REST. Revoque los PAT que ya no sean necesarios o no cumpla los criterios recomendados.

Para obtener más información, consulte Administración de PAT con directivas: para administradores y Uso de PAT.

Protección de Azure Artifacts

Asegúrese de comprender la diferencia entre fuentes, proyectos y administradores de colecciones de proyectos. Para más información, consulte Configuración de la configuración de Azure Artifacts.
Establecer permisos de fuente.

Protección de Azure Boards

Protección de Azure Pipelines

Use plantillas de extensión.
Establecimiento de permisos de canalización
Introducción a Azure Pipelines seguro.

Directivas

Requerir revisores externos: asegúrese de que al menos un revisor fuera del solicitante original para un proceso de revisión exhaustivo. El aprobador comparte la copropiedad de los cambios y la responsabilidad de los posibles efectos.
Requerir que la compilación de CI pase: establezca una línea base para la calidad del código al requerir que se pase la compilación de integración continua (CI) antes de combinar una solicitud de incorporación de cambios. Las comprobaciones de CI incluyen linting de código, pruebas unitarias y exámenes de seguridad.
No permitir la autoprobación: evite que el solicitante de pr original apruebe sus propios cambios para garantizar un proceso de revisión no sesgado y evitar conflictos de interés.
No permitir la finalización de la solicitud de incorporación de cambios con votos de "espera" o "rechazar": impedir la finalización de la solicitud de incorporación de cambios incluso si algunos revisores votan esperar o rechazar, fomentando la dirección de todos los comentarios antes de la combinación.
Restablecer los votos del revisor en los cambios: restablezca los votos del revisor cuando se inserte los cambios recientes en la solicitud de incorporación de cambios para asegurarse de que los revisores vuelvan a evaluar el código actualizado.
Bloquear canalizaciones de versión: limite las canalizaciones de versión a ramas específicas (normalmente producción o principal) para evitar implementaciones accidentales de otras ramas.
Aplicar variables que se pueden establecer en tiempo de cola: habilite la opción "Aplicar settable en tiempo de cola" para que las variables de canalización impidan que los usuarios invalide los valores de variable durante la ejecución de la canalización.
No permitir invalidaciones de variables en el editor: en el caso de las variables establecidas en el editor de canalización, no permitir invalidaciones de usuario para mantener la coherencia y evitar cambios no deseados.

Agentes

Conceder permisos con moderación: limite los permisos al conjunto de cuentas más pequeño necesario para reducir la superficie expuesta a ataques.
Configurar firewalls restrictivos para agentes: configure los firewalls para que sean lo más restrictivos posible, a la vez que permite que los agentes funcionen, equilibren la seguridad y la facilidad de uso.
Actualizar periódicamente los grupos de agentes: mantenga actualizada la flota del agente actualizando periódicamente los agentes para asegurarse de que el código vulnerable no se está ejecutando, lo que reduce el riesgo de explotación.
Use un grupo de agentes independiente para artefactos de producción: aísle los artefactos de producción mediante un grupo de agentes distinto, lo que impide implementaciones accidentales de ramas que no son de producción.
Grupos confidenciales de segmentos: cree grupos independientes para cargas de trabajo confidenciales y no sensibles. Permitir solo las credenciales en las definiciones de compilación asociadas al grupo adecuado.

Definiciones

Uso de YAML para definiciones de canalización: defina canalizaciones mediante YAML (sin embargo, otro lenguaje de marcado) para mejorar la rastreabilidad y el cumplimiento de las directrices de aprobación y los procedimientos de control de versiones.
Restringir el acceso de edición a las definiciones de canalización: limite el acceso a la edición de definiciones de canalización a las cuentas mínimas necesarias para reducir el riesgo de cambios accidentales o no autorizados.

Entrada

Incluir comprobaciones de variables en scripts de compilación: implemente comprobaciones dentro de los scripts de compilación para mitigar posibles ataques por inyección de comandos a través de variables configurables. Valide los valores de entrada y evite comandos no deseados o malintencionados.
Limitar las variables de compilación "settables en tiempo de lanzamiento": minimice el número de variables de compilación que se pueden establecer en tiempo de lanzamiento para reducir la superficie expuesta a ataques y simplificar la administración de la configuración.

Tareas

Evite capturar recursos de forma remota: siempre que sea posible, evite capturar recursos de direcciones URL externas durante el proceso de compilación. Si se necesitan recursos remotos, use control de versiones y comprobación de hash para garantizar la integridad.
Evitar el registro de secretos: nunca registre información confidencial, como secretos o credenciales, en los registros de compilación para evitar la exposición involuntaria y el riesgo de seguridad.
Uso de Azure Key Vault para secretos: en lugar de almacenar secretos directamente en variables de canalización, use Azure Key Vault para administrar y recuperar secretos de forma segura.
Restringir la ejecución de compilaciones en ramas o etiquetas arbitrarias: en el caso de las canalizaciones críticas para la seguridad, limite a los usuarios la ejecución de compilaciones en cualquier rama o etiqueta. Defina ramas o etiquetas autorizadas específicas para evitar ejecuciones accidentales o no autorizadas.
Deshabilitar la herencia para los permisos de canalización: los permisos heredados pueden ser demasiado amplios y podrían no reflejar con precisión sus necesidades. Deshabilite la herencia y establezca permisos explícitamente para alinearse con los requisitos de seguridad.
Limitar ámbitos de autorización de trabajos: restrinja siempre los ámbitos de autorización del trabajo al mínimo necesario. Ajuste los permisos en función de las tareas específicas realizadas por cada trabajo.

Repositorios y ramas

Requerir un número mínimo de revisores: habilite la directiva para asegurarse de que cada solicitud de incorporación de cambios recibe revisiones de al menos dos aprobadores, lo que promueve una revisión exhaustiva del código y la responsabilidad.
Configurar directivas de seguridad específicas del repositorio: adapte las directivas de seguridad a cada repositorio o rama en lugar de las directivas de todo el proyecto para reducir el riesgo, aplicar estándares de administración de cambios y mejorar la calidad del código.
Aislamiento de secretos de producción en un almacén de claves independiente: almacene los secretos de producción por separado en azure Key Vault y limite el acceso a una base de necesidad para mantener la separación de las compilaciones que no son de producción.
Separar entornos de prueba de producción: evite mezclar entornos de prueba con producción para asegurarse de que las credenciales y los secretos no se usan en contextos de no producción.
Deshabilitar la bifurcación: deshabilitar la bifurcación ayuda a administrar la seguridad evitando la proliferación de bifurcaciones, lo que facilita el seguimiento de la seguridad en todas las copias.
Evite proporcionar secretos a las compilaciones de bifurcación: evite compartir secretos con compilaciones bifurcadas para mantenerlos confidenciales y no expuestos a bifurcaciones.
Considere la posibilidad de desencadenar manualmente compilaciones de bifurcación: desencadene manualmente las bifurcaciones en lugar de permitir que los desencadenadores automáticos proporcionen un mejor control sobre las comprobaciones de seguridad.
Usar agentes hospedados por Microsoft para las compilaciones de bifurcación: use agentes hospedados por Microsoft para compilaciones bifurcadas a medida que se mantienen y protegen.
Examinar las definiciones de compilación de producción en repositorios de Git: compruebe periódicamente las definiciones de compilación de producción almacenadas en el repositorio git del proyecto para ver las credenciales o la información confidencial.
Configurar comprobaciones de control de rama para el contexto de producción: configure comprobaciones de control de rama para restringir el uso de conexiones confidenciales (por ejemplo, prod-connection) a las canalizaciones que se ejecutan en el contexto de la rama de producción, lo que garantiza una autorización adecuada y evita el uso indebido accidental.

Para obtener más información, consulte Otras consideraciones de seguridad.

Protección de Azure Repos

Protección de Azure Test Plans

Protección de las integraciones de GitHub

Usar flujo de OAuth en lugar de PAT: deshabilite la autenticación basada en PAT para las conexiones de servicio de GitHub y opte por el flujo de OAuth para mejorar la seguridad y la integración.
Evitar identidades de administrador o propietario: nunca autentique las conexiones de servicio de GitHub mediante una identidad que sea un administrador o propietario de ningún repositorio. Limite los permisos al nivel necesario.
Evitar PAT de GitHub de ámbito completo: evite usar un PAT de GitHub de ámbito completo para autenticar las conexiones de servicio. Use tokens con los permisos mínimos necesarios.
Evite las cuentas personales de GitHub como conexiones de servicio: no use cuentas personales de GitHub como conexiones de servicio en Azure DevOps. En su lugar, cree cuentas de servicio dedicadas o use cuentas de nivel de organización.

Compartir vía