Compartir a través de

Protección de la canalización y el flujo de trabajo de CI/CD

  • Artículo

En este artículo se describe cómo proteger las canalizaciones y el flujo de trabajo de CI/CD.

La automatización y la metodología ágil permiten a los equipos ofrecer resultados más rápidos, pero también agregan complejidad a la seguridad, ya que el flujo de trabajo se extiende a los propios equipos de desarrolladores.

En el siguiente diagrama se ilustra un entorno de CI/CD de referencia. El icono de configuración rojo indica los permisos de seguridad que debe configurar el cliente. Esto sigue el modelo de responsabilidad compartida, donde Azure y otros proveedores proporcionan permisos que el cliente debe configurar según su modelo de gobernanza y requisitos empresariales.

Flujo de trabajo típico de CI/CD que muestra cómo afectarán los cambios de código en un repositorio de Git a los recursos en la nube

Examinemos cada fase de este flujo de trabajo típico para comprender mejor cómo suelen depender las configuraciones unas de otras. El flujo de trabajo puede tener más fases. Los siguientes conceptos le ayudarán a comprender la integración continua y entrega continua y le ayudarán a diseñar el flujo de trabajo para la seguridad.

Fase 1: Flujo de trabajo de Git

Los cambios de código, no solo en el software, sino también en la canalización como código y la infraestructura como código,se guardan y se administran en Git. Git es un software de administración de código fuente distribuido. Cuando se inserta código de máquinas locales en el servidor Git centralizado, se pueden aplicar reglas de negocio antes de aceptarlo.

Solicitudes de incorporación de cambios y colaboración

El flujo de trabajo estándar del sector, independientemente del proveedor de software como servicio (SaaS) de administración de configuración de software (SCM), es usar solicitudes de incorporación de cambios que pueden actuar a la vez como equipo selector de calidad automatizado y como paso de aprobación manual antes de que se acepte el código fuente.

El flujo de trabajo de solicitud de incorporación de cambios está diseñado para introducir una fricción en buen estado, por lo que solo se debe aplicar para proteger ramas de Git específicas. Especialmente, las ramas que desencadenarán flujos de trabajo automatizados de implementación o configuración de recursos o que los afecten de alguna otra manera. Estas ramas se denominan ramas protegidas y normalmente siguen convenciones de nomenclatura como production o releases/*.

Es habitual que las solicitudes de incorporación de cambios requieran:

  • Revisiones por homólogos
  • Pasada de las compilaciones de integración continua (CI)
  • Aprobación manual

Si se cumplen los requisitos, se aceptan los cambios en el código y se pueden combinar.

Restricción del acceso a ramas protegidas

El flujo de trabajo de solicitud de incorporación de cambios se usa junto con controles de acceso restringido. Sin embargo, no se puede aplicar el flujo de trabajo de la solicitud de incorporación de cambios a menos que el servidor esté configurado para rechazar los cambios directos en las ramas protegidas.

Un desarrollador no puede insertar directamente en la rama production, sino que debe crear una solicitud de incorporación de cambios que se dirija a la rama protegida. Cada proveedor de SCM tiene un acceso restringido a las ramas protegidas de distinto tipo. Por ejemplo, con GitHub esta característica solo está disponible para las organizaciones que usan el equipo de GitHub o la nube de GitHub Enterprise.

Documentación del modelo de acceso de Git

Dado que el modelo de colaboración es complejo y tiene muchas partes móviles, resulta útil crear una tabla que documente todas las formas posibles en que los cambios de código pueden desencadenar implementaciones, por ejemplo:

Nombre de la rama ¿Requiere solicitud de incorporación de cambios? ¿Realiza implementaciones? Acceso de desarrollador Acceso de administrador
feat/* No No Lectura/escritura Lectura/escritura
main Sí Ensayo Lectura Lectura/escritura
production Sí, solo desde main. Producción Lectura Lectura/escritura

Este ejemplo de tabla de acceso de Git está simplificado en exceso para ilustrar su propósito. En la práctica suele haber más actores, más destinos de implementación y varias canalizaciones que se ejecutan para distintos casos de uso. La estructura de la tabla puede diferir en función de los requisitos de la organización y las cargas de trabajo.

La tabla debe ayudarle a responder preguntas como:

  • Si un desarrollador inserta cambios de código en la rama X, ¿se implementará? Si es así, ¿en qué entorno?
  • ¿En qué momento del ciclo de vida del código de la aplicación se realiza un examen de vulnerabilidad?
  • Si se encuentra una vulnerabilidad de seguridad, ¿cuántas inserciones y aprobaciones de código son necesarias antes de que entre en producción?

Esta tabla no solo es útil para la depuración y la documentación estática, sino también para la colaboración en equipo. Es transparente para los desarrolladores en los que se ha introducido una fricción en buen estado en el flujo de trabajo para priorizar la calidad y la seguridad del código. Lo que es más importante, muestra al desarrollador la ruta de acceso esperada para que los cambios de código lleguen a producción.

Dado que DevOps es un recorrido, el modelo de acceso de Git no es estático. Cambiará y evolucionará a medida que los equipos encuentren sus propios ritmos y maduren. Por eso es importante almacenar esta documentación lo más cerca posible del código, por ejemplo, en los repositorios de Git.

Para más información sobre las solicitudes de incorporación de cambios y las ramas protegidas, consulte:

Fase 2: Canalizaciones como código

El movimiento de canalización como código acelera la adopción de la automatización y las implementaciones mediante el traslado de las definiciones y las configuraciones de canalización del proveedor de CI a los desarrolladores, lo que acerca la lógica de compilación e implementación a la lógica de aplicación correspondiente. La mayor flexibilidad aquí también supone mayor responsabilidad.

Los controles de RBAC de una canalización controlada por la interfaz de usuario pueden impedir que usuarios individuales realicen cambios destructivos. Las canalizaciones como código, sin embargo, a menudo se ejecutan con identidades con privilegios y pueden destruir las cargas de trabajo si se les indica que lo hagan.

Fase 3: Protección de las credenciales de implementación

Las canalizaciones y los repositorios de código no deben incluir credenciales ni secretos con código muy protegido. Las credenciales y los secretos deben almacenarse en otro lugar y usar las características del proveedor de CI para la seguridad. Dado que las canalizaciones se ejecutan como agentes desatendidos, nunca deben usar la contraseña de un usuario. Las canalizaciones deben ejecutarse con entidades de seguridad desatendidas en su lugar, como entidades de servicio o identidades administradas. El acceso a las credenciales de esta entidad de seguridad, las cadenas de conexión de base de datos y las claves de API de terceros también se deben administrar de forma segura en la plataforma de CI.

Cómo se protegen las credenciales, las puertas y las aprobaciones son características específicas del proveedor. Al elegir una plataforma de CI, asegúrese de que admite todas las características que necesita.

Azure Pipelines es una solución de integración continua a escala empresarial donde las credenciales se almacenan como conexiones de servicio en las que puede configurar aprobaciones y comprobaciones. Esta configuración incluye la aprobación manual y autorizaciones específicas de rama o canalización.

Azure Key Vault

Si la plataforma de CI lo admite, considere la posibilidad de almacenar las credenciales en un almacén de secretos dedicado, por ejemplo, Azure Key Vault. El agente de compilación captura las credenciales en tiempo de ejecución y la superficie de ataque se reduce.

Fase 4: Protección de los recursos de Azure

Los recursos de Azure deben protegerse según el principio de privilegios mínimos, aplicado tanto a los permisos como al ámbito.

Para más información, consulte:

Creación de roles personalizados para los agentes de compilación

La automatización de CI/CD no solo concierne a las aplicaciones, sino también a la infraestructura. Las plantillas de infraestructura como código (IaC) garantizan la coherencia entre implementaciones y ayudan a escalar los equipos centralizados de la plataforma en la nube.

Es importante comprender que la automatización de IaC puede salir mal. Puede configurarse erróneamente y, en el peor de los casos, eliminar la infraestructura de forma permanente. Al planear el recorrido en la nube, identifique de antemano qué operaciones son críticas para la empresa y requieren intervención humana.

Por ejemplo, los bloqueos de administración CanNotDelete se pueden aplicar a recursos críticos para la empresa, como los datos. Para evitar que esto suceda, puede quitar los permisos Microsoft.Authorization/*/Delete de una entidad de servicio que se usa en la automatización de CI. En este ejemplo y en el caso de uso la entidad de servicio puede crear el bloqueo de administración, pero no eliminarlo.

Se recomienda crear un rol personalizado para los agentes de CI. Recuerde que los agentes de compilación se ejecutan desatendidos, los cuales no tienen cerebro. Elija los permisos con atención.

Para obtener más información, consulte:

Recursos

Pasos siguientes

Ahora que sabe cómo proteger DevOps, obtenga más información sobre la gobernanza integral de DevOps a Azure.

Gobernanza integral de DevOps a Azure