Compartir por

Recomendaciones de seguridad

  • Artigo

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 MSA:
    • Si su organización usa cuentas de MSA, quite directamente usuarios inactivos de la organización.
    • Desafortunadamente, no hay ninguna otra manera de evitar el acceso a estos usuarios.
    • Tenga en cuenta que no puede crear consultas para elementos de trabajo asignados a cuentas de MSA eliminadas.
  • Deshabilitar o eliminar cuentas de usuario de Microsoft Entra:
    • Si su organización está conectada a Microsoft Entra ID, puede deshabilitar o eliminar la cuenta de usuario de Microsoft Entra mientras mantiene activa la cuenta de usuario de Azure DevOps.
    • Este enfoque 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.
    • Los PAT son tokens de autenticación críticos y administrarlos de forma segura es esencial.
  • Revocar permisos especiales concedidos a usuarios individuales:
    • Audite y revoque los permisos especiales concedidos a cuentas de usuario individuales.
    • Asegúrese de que los permisos se alineen con el principio de privilegios mínimos.
  • Reasignar trabajo de usuarios eliminados:
    • Antes de quitar usuarios, reasigna los elementos de trabajo que estaban controlando.
    • Distribuya la carga de trabajo entre los miembros actuales del equipo.

Uso de Microsoft Entra ID

  • Plano único para la identidad:
    • Al conectar Azure DevOps a Microsoft Entra ID, se establece un sistema de identidad unificado.
    • La coherencia entre servicios reduce la confusión y minimiza los riesgos de seguridad derivados de errores de configuración manuales.
  • Gobernanza de un extremo a otro:
    • El aprovechamiento de Microsoft Entra ID le permite implementar una gobernanza específica.
    • Asigne distintos roles y permisos a grupos específicos de Microsoft Entra en varios ámbitos de recursos.
    • Este enfoque garantiza el acceso controlado y se alinea con los procedimientos recomendados de seguridad.
  • Características de seguridad:
    • Microsoft Entra ID habilita características de seguridad adicionales, como:
      • Autenticación multifactor (MFA): mejore la autenticación del usuario mediante la necesidad de varios factores (por ejemplo, la contraseña y la comprobación del teléfono).
      • Directivas de acceso condicional: defina reglas de acceso basadas en condiciones (por ejemplo, ubicación, dispositivo o nivel de riesgo).

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

Revisión de eventos de auditoría

Una vez respaldada por Microsoft Entra, realice las siguientes tareas para mejorar la seguridad y supervisar los patrones de uso:

  • Habilitar la auditoría:
    • En las directivas de seguridad, habilite la auditoría.
    • La auditoría ayuda a realizar un seguimiento y registrar eventos relacionados con las acciones, los permisos y los cambios del usuario.
  • Revise periódicamente los eventos de auditoría:
    • Revise el registro de auditoría periódicamente.
    • 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.

  • Lista de direcciones IP permitidas:
    • Configure una lista de permitidos para restringir el acceso a direcciones IP específicas.
    • Permitir solo el tráfico de orígenes de confianza, lo que reduce la superficie expuesta a ataques.
  • Cifrado:
    • Use siempre el cifrado para los datos en tránsito y en reposo.
    • Proteger los canales de comunicación mediante protocolos como HTTPS.
  • Validación de certificados:
    • Valide los certificados al establecer conexiones.
    • Asegúrese de que los certificados son válidos y emitidos por las autoridades de confianza.
  • Firewalls de aplicaciones web (WAF):
    • Implemente wafs para filtrar, supervisar y bloquear el tráfico malintencionado basado en web.
    • Las FDF proporcionan una capa adicional de protección contra ataques comunes.

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

Permisos con á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 mínimo: 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:
    • Para reducir el riesgo de perder información confidencial e implementar código no seguro en producción, limite el acceso a proyectos y repositorios.
    • Use los grupos de seguridad integrados o los grupos de seguridad personalizados para administrar los permisos. Para obtener más información, consulte Conceder o restringir permisos a tareas específicas.
  • Deshabilite "Permitir proyectos públicos":
    • En la configuración de directiva de la organización, deshabilite la opción para crear proyectos públicos.
    • Azure DevOps Services permite cambiar la visibilidad del proyecto de público a privado (y viceversa).
    • Los usuarios que no han iniciado sesión en su organización tienen acceso de solo lectura a proyectos públicos.
    • A los usuarios que han iniciado sesión se les puede conceder acceso a proyectos privados y realizar cambios permitidos.
  • Restringir la creación del proyecto:
    • Impedir 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.
    • Tenga en cuenta este paso si no hay necesidad empresarial para invitados externos.
  • Use otro correo electrónico o UPN para sus cuentas personales y empresariales:
    • Aunque se permite, use direcciones de correo electrónico distintas o nombres principales de usuario (UPN) para cuentas personales y empresariales.
    • Esta práctica elimina la ambigüedad al desambiguar entre sus cuentas personales y relacionadas con el trabajo.
  • Agrupar usuarios invitados externos:
    • Coloque todos los usuarios invitados externos en un único grupo de Microsoft Entra.
    • Administre los permisos de este grupo de forma adecuada.
    • Quite las asignaciones directas para asegurarse de que las reglas de grupo se aplican a estos usuarios. Para obtener más información, vea Agregar una regla de grupo para asignar niveles de acceso.
    • Vuelva a evaluar regularmente las reglas en la pestaña Reglas de grupo de la página Usuarios. Tenga en cuenta los cambios de pertenencia a grupos en el identificador de Entra de Microsoft que puedan afectar a su organización. El identificador de Entra de Microsoft puede tardar hasta 24 horas en actualizar la pertenencia dinámica a grupos. 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.
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 puede invalidar un nivel de permiso Permitir .
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.

Para obtener más información, consulte Grupos de usuarios válidos.

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

  1. Cree un grupo asignable de roles en microsoft Entra ID.
  2. 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

  1. Active el acceso.
  2. Actualice los permisos en Azure DevOps.
  3. 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

  • Descripción de las cuentas de servicio
  • Cree 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.
    • Documente su propósito y sus servicios asociados.
  • Identifique y deshabilite las 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.
  • Use identidades independientes para los lectores de informes:
    • Si usa cuentas de dominio para cuentas de servicio, use una identidad diferente para los lectores de informes.
    • Aísle los permisos para evitar el acceso innecesario. Para más información, consulte Cuentas de servicio y dependencias.
  • Use 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. Para obtener más información, consulte Requisitos de la cuenta de servicio.
  • Aproveche las conexiones de servicio:
    • Use conexiones de servicio siempre que sea posible.
    • Proporcionan una manera segura de conectarse a los servicios sin pasar variables secretas directamente a las compilaciones.
    • Restringir las conexiones a casos de uso específicos.
  • Supervisión de la actividad de la cuenta de servicio:
    • Implemente la auditoría y cree flujos de auditoría.

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

Conexiones de servicio de ámbito

  • Ámbito de las conexiones de servicio de Azure Resource Manager :
    • Para limitar el acceso, limite el ámbito de las conexiones de servicio a recursos y grupos específicos. Evite conceder derechos de colaborador amplios en toda la suscripción de Azure.
    • Use la federación de identidades de carga de trabajo para la autenticación. Esto permite conexiones de servicio sin secretos en Azure Pipelines.
  • Use la federación de identidades de carga de trabajo:
    • La federación de identidades de carga de trabajo usa OpenID Connect (OIDC) para autenticarse con recursos de Azure sin usar secretos.
    • Puede crear la federación de identidades de carga de trabajo automáticamente o manualmente. Tenga en cuenta este enfoque si:
      • Tiene el rol Propietario para la suscripción de Azure.
      • No se está conectando a entornos de Azure Stack o Azure US Government.
      • Las tareas de extensiones de Marketplace que use admiten la federación de identidades de carga de trabajo1.
  • Ámbito del grupo de recursos:
    • Asegúrese de que el grupo de recursos solo contiene las máquinas virtuales (VM) o los recursos necesarios para el proceso de compilación.
  • Evite las conexiones de servicio clásico de Azure:
    • Las conexiones de servicio clásicas carecen de opciones de ámbito. Opte por conexiones de servicio modernas de Azure Resource Manager en su lugar.
  • Use 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

Explore alternativas como entidades de servicio e identidades administradas:

  • Entidades de servicio:
    • Representa 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.
    • Configurado para acceder a los recursos de Azure, incluido Azure DevOps.
    • Resulta útil para las aplicaciones que necesitan acceso y control específicos.
  • 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 cuando quiera administrar detalles de inicio de sesión sin problemas.

Uso de PAT con moderación

  • Ámbito de LOS PAT a roles específicos:
    • Asigne PAT solo los permisos necesarios para tareas específicas. Evite conceder acceso global a varias organizaciones o repositorios.
    • Determinar el ámbito de los PAT garantiza que tienen los privilegios mínimos necesarios, lo que reduce el riesgo de uso indebido accidental.
  • Evite escribir o administrar permisos en compilaciones y versiones:
    • Los PAT no deben tener permisos de escritura o 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.
  • Establezca fechas de expiración y mantenga el secreto de PAT:
    • Establezca siempre una fecha de expiración para los PAT. Revise y renueve periódicamente según sea necesario.
    • Trate los PAT tan críticos como contraseñas. Manténgalos confidenciales y evite compartirlos públicamente o codificarlos de forma rígida en el código de la aplicación.
  • Evite codificar los PAT en el código de la aplicación:
    • Aunque puede parecer conveniente, evite insertar archivos PAT directamente en el código.
    • En su lugar, use archivos de configuración seguros o variables de entorno para almacenar y recuperar PAT dinámicamente.
  • Auditar y revocar PAT sin usar con regularidad:
    • 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 los siguientes artículos:

Protección de Azure Artifacts

Protección de Azure Boards

Protección de Azure Pipelines

Directivas

  • Requerir revisores fuera del solicitante original:
    • Tener al menos un revisor fuera del solicitante original garantiza un proceso de revisión más exhaustivo.
    • El aprobador comparte la copropiedad de los cambios y debe ser igualmente responsable de cualquier posible impacto.
  • Requerir que la compilación de CI pase:
    • Requerir que la compilación de integración continua (CI) pase antes de combinar una solicitud de incorporación de cambios establece una línea base para la calidad del código.
    • Las comprobaciones de CI incluyen linting de código, pruebas unitarias y exámenes de seguridad (por ejemplo, comprobaciones de virus y credenciales).
  • No permitir la autoprobación por parte del solicitante original:
    • Impedir que el solicitante de solicitud de solicitud de incorporación de cambios original apruebe sus propios cambios.
    • Esta acción garantiza un proceso de revisión no sesgado y evita posibles conflictos de interés.
  • No permitir la finalización de la solicitud de incorporación de cambios incluso con votos de "espera" o "rechazar":
    • Incluso si algunos revisores votan para esperar o rechazar, evite la finalización de la solicitud de incorporación de cambios.
    • Esta acción recomienda abordar todos los comentarios antes de combinarlos.
  • Restablezca los votos del revisor de código en los cambios insertados:
    • Cuando se insertan cambios recientes en la solicitud de incorporación de cambios, restablezca los votos del revisor.
    • Esta acción garantiza que los revisores vuelvan a evaluar el código actualizado.
  • Bloqueo de canalizaciones de versión en ramas de producción específicas:
    • Limite las canalizaciones de versión a ramas específicas (normalmente producción o principal).
    • Evite implementaciones accidentales de otras ramas.
  • Aplicar variables settables en tiempo de cola:
    • Habilite la opción "Aplicar settable en tiempo de cola" para las variables de canalización.
    • Esta acción impide que los usuarios invalidar 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 se permiten invalidaciones de usuario.
    • Esta acción mantiene la coherencia y evita cambios no deseados.

Agentes

  • Conceder permisos con moderación:
    • Limite los permisos al conjunto de cuentas más pequeño necesario.
    • Evite el acceso excesivamente permisivo, lo que reduce la superficie expuesta a ataques.
  • Firewalls restrictivos para agentes utilizables:
    • Configure los firewalls para que sean lo más restrictivos posible, a la vez que permite que los agentes funcionen.
    • Lograr un equilibrio entre la seguridad y la facilidad de uso.
  • Actualice periódicamente los grupos de agentes:
    • Mantenga actualizada la flota del agente actualizando periódicamente los agentes.
    • Esta acción garantiza que el código vulnerable no se esté ejecutando, lo que reduce el riesgo de explotación.
  • Grupo de agentes independiente para artefactos de producción:
    • Use un grupo de agentes distinto para los artefactos de compilación destinados a producción.
    • Aislar artefactos de producción ayuda a evitar implementaciones accidentales de ramas que no son de producción.
  • Segmentación de grupos confidenciales:
    • 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

  • Use YAML para las definiciones de canalización:
    • YAML (otro lenguaje de marcado) es el enfoque recomendado para definir canalizaciones.
    • Ofrece rastreabilidad para los cambios, lo que facilita el seguimiento de las modificaciones a lo largo del tiempo.
    • Además, las canalizaciones de YAML pueden cumplir 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.
    • Al hacerlo, se reduce el riesgo de cambios accidentales o no autorizados.

Entrada

  • Incluya comprobaciones de integridad para las variables en los scripts de compilación:
    • Implemente comprobaciones de integridad dentro de los scripts de compilación para mitigar posibles ataques de inyección de comandos a través de variables que se pueden establecer.
    • Estas comprobaciones pueden validar los valores de entrada y evitar comandos no deseados o malintencionados.
  • Limite el número de variables de compilación "settable en tiempo de lanzamiento":
    • Establezca las pocas variables de compilación posibles para que se puedan "establecer en tiempo de lanzamiento".
    • Minimizar el número de variables de este tipo reduce la superficie expuesta a ataques y simplifica la administración de la configuración.

Tareas

  • Evite los recursos capturados 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.
  • Evite registrar secretos:
    • Nunca registre información confidencial, como secretos o credenciales, en los registros de compilación.
    • Los secretos de registro pueden exponerlos involuntariamente y poner en peligro la seguridad.
  • Use Azure Key Vault para secretos:
    • En lugar de almacenar secretos directamente en variables de canalización, use Azure Key Vault.
    • Key Vault proporciona una manera segura de administrar y recuperar secretos de forma centralizada.
  • Restrinja las compilaciones en ejecución en ramas arbitrarias o etiquetas:
    • 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.
  • Deshabilite la herencia para los permisos de canalización:
    • Los permisos heredados pueden ser demasiado amplios y es posible que no reflejen con precisión sus necesidades.
    • Deshabilite la herencia y establezca permisos explícitamente para alinearse con los requisitos de seguridad.
  • Limitar los á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 "Requerir un número mínimo de revisores" para asegurarse de que cada solicitud de incorporación de cambios recibe revisiones de al menos dos aprobadores.
    • Esto promueve una revisión exhaustiva del código y la responsabilidad.
  • Configuración de directivas de seguridad específicas del repositorio:
    • En lugar de las directivas de todo el proyecto, adapte las directivas de seguridad a cada repositorio o rama.
    • Las directivas personalizadas reducen el riesgo, aplican los estándares de administración de cambios y mejoran la calidad del código.
  • Aísle los secretos de producción en un almacén de claves independiente:
    • Almacene los secretos de producción por separado en una instancia de Azure Key Vault.
    • Limite el acceso a una base necesaria 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.
    • Asegúrese de que las credenciales y los secretos no se usan en contextos que no son de producción.
  • Deshabilitar la bifurcación:
    • Deshabilitar la bifurcación ayuda a administrar la seguridad.
    • Las bifurcaciones pueden proliferar, lo que dificulta el seguimiento de la seguridad en todas las copias.
  • Evite proporcionar secretos para las compilaciones de bifurcación:
    • Evite compartir secretos con compilaciones bifurcadas.
    • Los secretos deben permanecer confidenciales y no exponerse a bifurcaciones.
  • Considere la posibilidad de desencadenar manualmente compilaciones de bifurcación:
    • Desencadena manualmente compila bifurcaciones en lugar de permitir desencadenadores automáticos.
    • Esto proporciona un mejor control sobre las comprobaciones de seguridad.
  • Use los agentes hospedados por Microsoft para las compilaciones de bifurcación:
    • Aproveche los agentes hospedados por Microsoft para las compilaciones bifurcadas.
    • Estos agentes se mantienen y protegen.
  • Examen de 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.
    • Busque credenciales o 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 canalizaciones que se ejecutan en el contexto de la rama de producción.
    • Esto 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

  • Use el flujo de OAuth en lugar de PAT:
    • Deshabilite la autenticación basada en PAT para las conexiones de servicio de GitHub.
    • Opte por el flujo de OAuth, que proporciona una mejor seguridad e integración.
  • Evite las 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.
  • Evite pats de GitHub de ámbito completo:
    • Absténgase de 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.