Otras consideraciones de seguridad para Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

En lo que respecta a la protección de Azure Pipelines, hay otras consideraciones que se deben tener en cuenta, como proteger la infraestructura compartida, los repositorios, los proyectos, etc.

Protección de la infraestructura compartida

Los recursos protegidos en Azure Pipelines son una abstracción de la infraestructura real. Siga estas recomendaciones para proteger la infraestructura subyacente.

Uso de grupos hospedados por Microsoft

Los grupos hospedados por Microsoft ofrecen aislamiento y una máquina virtual limpia para cada ejecución de una canalización. Si es posible, use grupos hospedados por Microsoft en lugar de grupos autohospedados.

Agentes distintos para cada proyecto

Un agente solo se puede asociar a un único grupo. Puede compartir agentes entre proyectos asociando el grupo con varios proyectos. En la práctica, varios proyectos pueden usar el mismo agente consecutivamente. Aunque resulta rentable, este enfoque puede introducir riesgos de movimiento lateral.

Para mitigar el movimiento lateral y evitar la contaminación cruzada entre proyectos, mantenga grupos de agentes independientes, cada uno dedicado a un proyecto específico.

Uso de cuentas con pocos privilegios para ejecutar agentes

Aunque puede ser tentado, la ejecución del agente bajo una identidad con acceso directo a los recursos de Azure DevOps puede ser arriesgada. Esta configuración es frecuente en las organizaciones que usan el identificador de Entra de Microsoft, pero supone riesgos. Si ejecuta el agente en una identidad respaldada por microsoft Entra ID, puede acceder directamente a las API de Azure DevOps sin depender del token de acceso del trabajo. Para mejorar la seguridad, considere la posibilidad de ejecutar el agente mediante una cuenta local sin privilegios, como el servicio de red.

Importante

En Azure DevOps, hay un grupo denominado Cuentas de servicio de recopilación de proyectos, que puede ser engañoso. Por herencia, los miembros de las cuentas de servicio de recopilación de proyectos también se consideran miembros de los administradores de la colección de proyectos. Algunos clientes ejecutan sus agentes de compilación mediante una identidad respaldada por microsoft Entra ID y estas identidades pueden formar parte de las cuentas de servicio de recopilación de proyectos. Pero si los adversarios ejecutan una canalización en uno de estos agentes de compilación, podrían ganar control sobre toda la organización de Azure DevOps.

Hay instancias en las que los agentes autohospedados funcionan con cuentas con privilegios elevados. Estos agentes suelen usar estas cuentas con privilegios para acceder a secretos o entornos de producción. Pero si los adversarios ejecutan una canalización en peligro en uno de estos agentes de compilación, obtienen acceso a esos secretos. A continuación, los adversarios pueden moverse lateralmente a través de otros sistemas accesibles a través de estas cuentas.

Para mejorar la seguridad del sistema, se recomienda usar la cuenta con privilegios más bajos para ejecutar agentes autohospedados. Por ejemplo, use la cuenta de la máquina o una identidad de servicio administrada. Además, encomenda Azure Pipelines a la administración del acceso a secretos y entornos.

Minimización del ámbito de las conexiones de servicio

Asegúrese de que las conexiones de servicio solo tienen acceso a los recursos necesarios. Siempre que sea factible, considere la posibilidad de usar la federación de identidad de carga de trabajo en lugar de una entidad de servicio para la conexión de servicio de Azure. La federación de identidades de carga de trabajo usa Open ID Connect (OIDC), una tecnología estándar del sector, para facilitar la autenticación entre Azure y Azure DevOps sin depender de secretos.

Asegúrese de que la conexión de servicio de Azure esté limitada para acceder solo a los recursos necesarios. Evite conceder derechos de colaborador amplios para toda la suscripción de Azure a los usuarios.

Al crear una nueva conexión de servicio de Azure Resource Manager, elija siempre un grupo de recursos específico. Asegúrese de que el grupo de recursos contiene solo las máquinas virtuales o los recursos necesarios para la compilación. De forma similar, al configurar la aplicación de GitHub, conceda acceso solo a los repositorios que pretende compilar mediante Azure Pipelines.

Protección de proyectos

Además de los recursos individuales, es fundamental tener en cuenta los grupos de recursos en Azure DevOps. Los recursos se organizan por proyectos de equipo y comprenden a qué puede acceder la canalización en función de la configuración del proyecto y la contención es esencial.

Cada trabajo de la canalización recibe un token de acceso con permisos para leer los recursos abiertos. En algunos casos, las canalizaciones también pueden actualizar estos recursos. Esto significa que, aunque es posible que la cuenta de usuario no tenga acceso directo a un recurso, scripts y tareas específicos que se ejecutan en la canalización podría seguir accediendo a ella. Además, el modelo de seguridad de Azure DevOps permite el acceso a estos recursos desde otros proyectos de la organización. Si decide restringir el acceso de canalización a determinados recursos, esta decisión se aplica a todas las canalizaciones dentro de un proyecto, no se puede conceder acceso de forma selectiva a los recursos abiertos.

Proyectos independientes

Dada la naturaleza de los recursos abiertos, considere la posibilidad de administrar cada producto y equipo en proyectos independientes. Al hacerlo, se evita que las canalizaciones de un producto accedan accidentalmente a recursos abiertos desde otro producto, lo que minimiza la exposición lateral. Sin embargo, cuando varios equipos o productos comparten un proyecto, el aislamiento pormenorizados de sus recursos se vuelve difícil.

Si la organización de Azure DevOps se creó antes de agosto de 2019, es posible que las ejecuciones sigan teniendo acceso a recursos abiertos en todos los proyectos de la organización. El administrador de la organización debe revisar una configuración de seguridad crítica en Azure Pipelines que permita el aislamiento del proyecto para las canalizaciones.

Puede encontrar esta configuración en Configuración de la organización>Configuración de canalizaciones>o directamente: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Protección de repositorios

En los repositorios de control de versiones, puede almacenar código fuente, el archivo YAML de la canalización y las herramientas y scripts necesarios. Para garantizar cambios seguros en el código y la canalización, es fundamental aplicar permisos y directivas de rama. Además, considere la posibilidad de agregar permisos y comprobaciones de canalización a los repositorios.

Además, revise la configuración predeterminada del control de acceso para los repositorios.

Tenga en cuenta que el diseño de Git significa que la protección de nivel de rama tiene limitaciones. Los usuarios con acceso de inserción a un repositorio normalmente pueden crear nuevas ramas. Si trabaja con proyectos de código abierto de GitHub, cualquier persona con una cuenta de GitHub puede bifurcar el repositorio y proponer contribuciones. Dado que las canalizaciones están asociadas a un repositorio (no ramas específicas), es esencial tratar el código y los archivos YAML como potencialmente que no son de confianza.

Horquillas

Al trabajar con repositorios públicos de GitHub, es esencial tener en cuenta cuidadosamente su enfoque para las compilaciones de bifurcación. Las bifurcaciones, que se originan desde fuera de la organización, suponen riesgos concretos. Para proteger sus productos de código que potencialmente no es de confianza, tenga en cuenta las siguientes recomendaciones.

Nota:

Estas recomendaciones se aplican principalmente a la creación de repositorios públicos desde GitHub.

No se deben proporcionar secretos a las compilaciones de bifurcación

De forma predeterminada, las canalizaciones están configuradas para compilar bifurcaciones, pero los secretos y los recursos protegidos no se exponen automáticamente a los trabajos de esas canalizaciones. Es esencial no deshabilitar esta protección para mantener la seguridad.

Nota:

Al habilitar compilaciones de bifurcación para acceder a secretos, Azure Pipelines restringe el token de acceso que se usa de forma predeterminada. Este token tiene acceso limitado a los recursos abiertos en comparación con un token de acceso normal. Para conceder a las compilaciones de bifurcación los mismos permisos que las compilaciones normales, habilite las compilaciones de bifurcación tener los mismos permisos que la configuración de compilaciones normales .

Considerar la posibilidad de desencadenar manualmente compilaciones de bifurcación

Puede desactivar las compilaciones automáticas de bifurcación y, en su lugar, usar comentarios de solicitud de cambios para crear manualmente estas contribuciones. Esta configuración le ofrece la oportunidad de revisar el código antes de desencadenar una compilación.

Usar agentes hospedados por Microsoft para compilaciones de bifurcación

Evite ejecutar compilaciones de bifurcaciones en agentes autohospedados. Si lo hace, podría permitir que las organizaciones externas ejecuten código externo en máquinas dentro de la red corporativa. Siempre que sea posible, use agentes hospedados por Microsoft. En el caso de los agentes autohospedados, implemente el aislamiento de red y asegúrese de que los agentes no conserven su estado entre trabajos.

Revisar los cambios de código

Antes de ejecutar la canalización en una solicitud de incorporación de cambios bifurcada, revise cuidadosamente los cambios propuestos y asegúrese de que se siente cómodo ejecutándolo.

La versión de la canalización YAML que se ejecuta es la de la solicitud de incorporación de cambios. Por lo tanto, preste especial atención a los cambios en el código YAML y al código que se ejecuta cuando se ejecuta la canalización, como scripts de línea de comandos o pruebas unitarias.

Limitación del ámbito del token de GitHub

Al compilar una solicitud de incorporación de cambios bifurcada de GitHub, Azure Pipelines garantiza que la canalización no puede cambiar ningún contenido del repositorio de GitHub. Esta restricción se aplica solo si usa la aplicación de Azure Pipelines GitHub para integrarse con GitHub. Si usa otras formas de integración de GitHub, por ejemplo, la aplicación OAuth, la restricción no se aplica.

Ramas de usuario

Los usuarios de su organización con los permisos adecuados pueden crear nuevas ramas que contengan código nuevo o actualizado. Este código puede ejecutarse a través de la misma canalización que las ramas protegidas. Si se cambia el archivo YAML de la nueva rama, se usa YAML actualizado para ejecutar la canalización. Aunque este diseño permite una gran flexibilidad y autoservicio, no todos los cambios son seguros (ya sean realizados de forma malintencionada o no).

Si la canalización consume código fuente o está definida en Azure Repos, debe comprender completamente el modelo de permisos de Azure Repos. En concreto, un usuario con el permiso Crear rama a nivel de repositorio puede introducir código en el repositorio incluso si ese usuario no tiene el permiso Contribución.

Otras consideraciones de seguridad

Hay el siguiente conjunto de otras cosas que debe tener en cuenta al proteger las canalizaciones.

Confiar en PATH

Confiar en la configuración de PATH del agente es peligroso. Es posible que no apunte a dónde cree que lo hace, ya que se modificó potencialmente mediante un script o una herramienta anteriores. Con scripts y archivos binarios críticos para la seguridad, use siempre una ruta de acceso completa al programa.

Secretos de registro

Siempre que sea posible, Azure Pipelines intenta borrar los secretos de los registros. Este filtrado se realiza de la mejor manera posible y no puede detectar todas las formas de filtración de los secretos. Evite reproducir secretos en la consola, usarlos en parámetros de la línea de comandos o registrarlos en archivos.

Bloqueo de contenedores

Los contenedores tienen algunos montajes de volumen proporcionados por el sistema que se asignan a las tareas, al espacio de trabajo y a los componentes externos necesarios para comunicarse con el agente host. Puede marcar algunos de estos volúmenes de solo lectura o todos ellos.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Normalmente, la mayoría de las personas deben establecer los tres primeros directorios como de solo lectura y dejar work como lectura y escritura. Si no escribe en el work directorio en un trabajo o paso específico, no dude en hacer que también sea work de solo lectura. Sin embargo, si las tareas de canalización implican auto-modificación, es posible que tenga que mantenerla tasks como lectura y escritura.

Control de las tareas disponibles

Puede deshabilitar la capacidad de instalar y ejecutar tareas desde Marketplace, lo que le permite controlar mejor el código que se ejecuta en una canalización. También puede deshabilitar todas las tareas integradas (excepto Desproteger, que es una acción especial en el agente). En la mayorías de los casos, se recomienda no deshabilitar las tareas incorporadas.

Las tareas instaladas directamente con tfx siempre están disponibles. Con ambas características habilitadas, solo están disponibles esas tareas.

Uso del servicio de auditoría

Muchos eventos de canalización se registran en el servicio de auditoría. Revise el registro de auditoría periódicamente para asegurarse de que no se ha recortado ningún cambio malintencionado. Para comenzar, visite https://dev.azure.com/ORG-NAME/_settings/audit.

Pasos siguientes

Revise la introducción a la seguridad.