Recomendaciones de seguridad

  • Artículo

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

Cuando trabaja con información y datos, especialmente en una solución basada en la nube, como Azure DevOps Services, priorizar la seguridad siempre debe ser su principal preocupación. Aunque Microsoft mantiene la seguridad de la infraestructura en la nube subyacente, es su responsabilidad configurar la seguridad en Azure DevOps.

Aunque no es obligatorio, la incorporación de procedimientos recomendados al usar Azure DevOps puede mejorar su experiencia y hacerlo más seguro. Hemos compilado los siguientes procedimientos recomendados que tienen como objetivo proteger el entorno de Azure DevOps:

Protección del entorno de Azure DevOps

Eliminación de usuarios

  • Si su organización usa cuentas de MSA, quite usuarios inactivos directamente de la organización, ya que no tiene ninguna otra manera de evitar el acceso. Al hacerlo, no puede crear una consulta para los elementos de trabajo asignados a la cuenta de usuario eliminada. Para más información, consulte Eliminación de usuarios de Azure DevOps.
  • Si su organización está conectada a Microsoft Entra ID, puede deshabilitar o eliminar la cuenta de usuario de Microsoft Entra y dejar activa la cuenta de usuario de Azure DevOps. De este modo, puede seguir consultando el historial de elementos de trabajo mediante el identificador de usuario de Azure DevOps.
  • Revocar PAT de usuario.
  • Revoque los permisos especiales que se hayan concedido a cuentas de usuario individuales.
  • Reasignar el trabajo de los usuarios que va a quitar a los miembros del equipo actuales.

Uso de Microsoft Entra ID

Integre Azure DevOps con microsoft Entra ID para tener un único plano para la identidad. La coherencia y una única fuente autoritativa aumentan la claridad y reducen los riesgos de seguridad de los errores humanos y la complejidad de la configuración. La clave para la gobernanza final es tener varias asignaciones de roles (con diferentes definiciones de roles y ámbitos de recursos diferentes a los mismos grupos de Microsoft Entra). Sin microsoft Entra ID, es el único responsable de controlar el acceso de la organización.

El uso de Microsoft Entra ID también permite acceder a otras características de seguridad, como la autenticación multifactor u otras directivas de acceso condicional.

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

Revisión de eventos de auditoría

Una vez que tenga una organización respaldada por Microsoft Entra, puede activar Auditoría en las directivas de seguridad. Revise periódicamente los eventos de auditoría para supervisar y reaccionar ante patrones de uso inesperados por parte de los administradores y otros usuarios.

Protección de la red

Algunas maneras de hacerlo pueden incluir:

  • Configure una lista de permitidos para restringir direcciones IP específicas.
  • Use siempre el cifrado.
  • Validar certificados.
  • Implemente firewalls de aplicaciones web (WAF), para que puedan filtrar, supervisar y bloquear cualquier tráfico malintencionado basado en web hacia y desde Azure DevOps.
  • Para más información, consulte esta guía sobre los procedimientos recomendados de administración de aplicaciones.

Permisos con ámbito

El sistema administra los permisos en distintos niveles ( individual, colección, proyecto y objeto) y los asigna a uno o varios grupos integrados de forma predeterminada.

Permisos de nivel de proyecto

  • Limite el acceso a proyectos y repositorios para reducir el riesgo de filtrar información confidencial e implementar código no seguro en producción.
  • 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 para seleccionar tareas.
  • Deshabilite "Permitir proyectos públicos" en la configuración de directiva de la organización para evitar que todos los usuarios de la organización creen un proyecto público. Azure DevOps Services permite cambiar la visibilidad de los proyectos de público a privado y viceversa. Si los usuarios no han iniciado sesión en su organización, tienen acceso de solo lectura a los proyectos públicos. Si los usuarios han iniciado sesión, se les puede conceder acceso a proyectos privados y realizar cambios permitidos en ellos.
  • No permita a los usuarios crear nuevos proyectos.

Acceso de invitado externo

  • Para bloquear el acceso de invitado externo por completo, deshabilite la directiva "Permitir que las invitaciones se envíen a cualquier dominio". Es una buena idea hacerlo si no hay necesidad empresarial para ello.
  • Use otro correo electrónico o nombre principal de usuario (UPN) para sus cuentas personales y empresariales, aunque se permita. Esta acción elimina el desafío de desambiguar entre sus cuentas empresariales y personales cuando el correo electrónico o UPN es el mismo.
  • Coloque todos los usuarios invitados externos en un único grupo de Microsoft Entra y administre los permisos de ese grupo de forma adecuada. Puede administrar y auditar fácilmente de esta manera.
    • Quite las asignaciones directas para que las reglas de grupo se apliquen a esos usuarios. Para obtener más información, vea Agregar una regla de grupo para asignar niveles de acceso.
    • Vuelva a evaluar las reglas periódicamente en la pestaña Reglas de grupo de la página Usuarios. Aclarar si los cambios de pertenencia a grupos en el identificador de Entra de Microsoft podrían afectar a su organización. El identificador de Entra de Microsoft puede tardar hasta 24 horas en actualizar la pertenencia dinámica a grupos. Cada 24 horas y cada vez que cambia una regla de grupo, las reglas se vuelven a evaluar automáticamente en el sistema.
  • 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

Consulte las siguientes 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

Puede cambiar la configuración de su organización o proyecto si tiene acceso a Project Collection Administración istrator y Project Administración istrator. Para proteger el acceso a estos grupos de administradores integrados, necesita acceso Just-In-Time mediante un grupo de Microsoft Entra Privileged Identity Management (PIM).

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:

Asegúrese de que cualquier usuario con acceso elevado mediante un grupo PIM también tiene acceso estándar a la organización, por lo que puede ver la página para actualizar sus permisos.

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

  • Asegúrese de que las cuentas de servicio tienen cero derechos de inicio de sesión interactivos.
  • Restrinja los privilegios de la cuenta de servicio al mínimo necesario.
  • Use otra identidad para la cuenta del lector de informes si usa cuentas de dominio para las cuentas de servicio. Para más información, consulte Cuentas de servicio y dependencias.
  • Use cuentas locales para cuentas de usuario, si va a instalar un componente en un grupo de trabajo. Para obtener más información, consulte Requisitos de la cuenta de servicio.
  • Use las conexiones de servicio siempre que sea posible. Las conexiones de servicio proporcionan un mecanismo seguro para conectarse a servicios ordenados sin necesidad de pasar variables secretas a la compilación directamente. - Restrinja estas conexiones al lugar específico en el que se deben usar y nada más.
  • Supervise la actividad de la cuenta de servicio y cree streaming de auditoría. La auditoría permite detectar y reaccionar ante inicios de sesión y actividad sospechosos.
  • Para más información, consulte Tipos de conexión de servicio comunes.

Conexiones de servicio de ámbito

  • Ámbito de Azure Resource Manager y otras conexiones de servicio, solo a los recursos y grupos a los que necesitan acceso. Las conexiones de servicio no deben tener derechos de colaborador amplios en toda la suscripción de Azure.
  • Use la federación de identidades de carga de trabajo para las conexiones de servicio de Azure Resource Manager (ARM). La federación de identidades de carga de trabajo permite crear conexiones de servicio sin secretos en Azure Pipelines a Azure.
  • No proporcione a los usuarios derechos genéricos ni amplios de colaborador en la suscripción de Azure.
  • No use conexiones de servicio clásico de Azure, ya que no hay ninguna manera de definir el ámbito de los permisos.
  • Asegúrese de que el grupo de recursos solo contiene Virtual Machines (VM) o recursos a los que la compilación necesita acceso.
  • Use una cuenta de servicio de equipo específica para autenticar una conexión de servicio.
  • 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 que le permiten usar tokens de Microsoft Entra para acceder a los recursos de Azure DevOps. Estos tokens conllevan menos riesgo cuando se filtran en comparación con las PAT y contienen ventajas como la administración sencilla de credenciales.

Uso de PAT con moderación

Si es posible, se recomienda usar siempre los servicios de identidad para la autenticación en lugar de las claves criptográficas, ya que administrar claves de forma segura con código de aplicación es difícil y puede provocar errores como publicar accidentalmente claves de acceso confidenciales en repositorios de código públicos como GitHub. Sin embargo, si debe usar tokens de acceso personal (PAT), tenga en cuenta las siguientes directrices:

  • Las PAT siempre deben tener como ámbito roles específicos.

  • Las PAT no deben proporcionar acceso global a varias organizaciones.

  • Las PAT no deben conceder permisos de escritura o administración en compilaciones o versiones.

  • Las PAT deben tener una fecha de expiración y mantenerse secretas, ya que son tan críticas como contraseñas.

  • Las PAT nunca se deben codificar de forma rígida en el código de la aplicación, aunque sea tentador hacerlo para simplificar el código.

  • Administración istrators debe auditar periódicamente todos los PAT mediante Las API REST y revocan los que no cumplan los criterios anteriores.

  • Mantenga los PAT un secreto. Los tokens son tan críticos como contraseñas.

  • Almacene los tokens en un lugar seguro.

  • No codificar de forma rígida los tokens en las aplicaciones. Puede resultar tentador simplificar el código para obtener un token durante un largo período de tiempo y almacenarlo en la aplicación, pero no lo haga.

  • Asigne a los tokens una fecha de expiración.

  • 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 al menos un revisor fuera del solicitante original. El aprobador comparte la copropiedad de los cambios y debe ser igualmente responsable de cualquier posible impacto.
  • Requerir que se pase la compilación de CI. Este requisito es útil para establecer la calidad del código de línea base, a través de linting de código, pruebas unitarias y comprobaciones de seguridad, como los exámenes de virus y credenciales.
  • Asegúrese de que el solicitante de incorporación de cambios original no puede aprobar el cambio.
  • No permitir la finalización de una solicitud de incorporación de cambios (solicitud de incorporación de cambios), incluso si algunos revisores votan esperar o rechazar.
  • Restablezca los votos del revisor de código cuando se inserte cambios recientes.
  • Bloquee las canalizaciones de versión ejecutándolas solo en ramas de producción específicas.
  • Habilite "Aplicar la tabla establecida en tiempo de cola para las variables" en la configuración de canalización de la organización.
  • No permita "Permitir que los usuarios invaliden este valor al ejecutar esta canalización", para las variables establecidas en el editor.

Agentes

  • Conceda permisos al menor número posible de cuentas.
  • Tener el firewall más restrictivo que deja los agentes utilizables.
  • Actualice los grupos con regularidad para asegurarse de que la flota de compilación no ejecute código vulnerable que un actor malintencionado pueda aprovechar.
  • Use un grupo de agentes independiente para los artefactos de compilación que se envían o implementan en producción.
  • Segmente el grupo "confidencial" de los grupos sin distinción y solo permita el uso de credenciales en las definiciones de compilación bloqueadas en ese grupo.

Definiciones

  • Administrar definiciones de canalización con YAML (otro lenguaje de marcado). YAML es el método preferido para administrar definiciones de canalización, ya que proporciona rastreabilidad para los cambios y puede seguir las directrices de aprobación.
  • Proteger la definición de canalización Edite el acceso al número mínimo de cuentas.

Entrada

  • Incluya comprobaciones de integridad para las variables en los scripts de compilación. Una comprobación de integridad puede mitigar un ataque por inyección de comandos a través de las variables que se pueden establecer.
  • Establezca tantas variables de compilación como sea posible en "Settable at release time".

Tareas

  • Evite capturar recursos de forma remota, pero, si es necesario, use control de versiones y comprobación de hash.
  • No registre secretos.
  • No almacene secretos en variables de canalización, use Azure Key Vault. Examine periódicamente las canalizaciones de compilación para asegurarse de que los secretos no se almacenan en variables de canalización de compilación.
  • No permita que los usuarios ejecuten compilaciones en ramas arbitrarias o etiquetas en canalizaciones críticas para la seguridad.
  • Deshabilite la herencia en la canalización, ya que los permisos heredados son amplios y no reflejan con precisión las necesidades de los permisos.
  • Limite los ámbitos de autorización de trabajos en todos los casos.

Repositorios y ramas

  • Establezca la directiva "Requerir un número mínimo de revisores" en activado, de modo que cada solicitud de incorporación de cambios se revise por al menos dos aprobadores.
  • Configure directivas de seguridad específicas de cada repositorio o rama, en lugar de en todo el proyecto. Las directivas de seguridad reducen el riesgo, aplican los estándares de administración de cambios y mejoran la calidad del código de su equipo.
  • Almacene secretos de producción en un almacén de claves independiente y asegúrese de que el acceso solo se concede de forma necesaria para mantener las compilaciones que no son de producción independientes.
  • No combine entornos de prueba con producción, incluido el uso de credenciales.
  • Deshabilite la bifurcación. Cuantos más bifurcaciones haya, más difícil es realizar un seguimiento de la seguridad de cada bifurcación. Además, un usuario puede bifurcar fácilmente una copia de un repositorio en su propia cuenta privada.
  • No proporcione secretos para bifurcar compilaciones.
  • Considere la posibilidad de desencadenar manualmente compilaciones de bifurcación.
  • Use los agentes hospedados por Microsoft para las compilaciones de bifurcación.
  • Para Git, compruebe las definiciones de compilación de producción en el repositorio git del proyecto, por lo que se pueden examinar para ver las credenciales.
  • Configure una comprobación de control de rama para que solo las canalizaciones que se ejecuten en el contexto de la production rama puedan usar .prod-connection
  • 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

  • Deshabilite la autenticación basada en token de acceso personal (PAT), por lo que el flujo de OAuth se usa con la conexión de servicio de GitHub.
  • Nunca autentique las conexiones de servicio de GitHub como una identidad que sea un administrador o propietario de ningún repositorio.
  • Nunca use un PAT de GitHub de ámbito completo (token de acceso personal) para autenticar las conexiones de servicio de GitHub.
  • No use una cuenta de GitHub personal como conexión de servicio con Azure DevOps.