Cómo resolver problemas de permisos en canalizaciones de CI/CD



Los equipos de DevOps están familiarizados con las formas en que las preocupaciones de seguridad y los problemas de procesos pueden detener las operaciones de CI/CD. Los obstáculos operativos que conducen a la falta de comunicación entre los miembros del equipo y la organización en standard son muy comunes en las canalizaciones de DevOps. Uno de los principales problemas operativos que enfrentan los equipos de DevOps son los problemas de permisos.

Los problemas de permisos son un obstáculo aparentemente pequeño, pero significativo, para suavizar las canalizaciones de CI/CD. Si no los aborda, el resultado es una falta de cohesión entre el desarrollo y los objetivos organizacionales.

Aquí se explica cómo optimizar estos procesos, impulsar la integración de la seguridad dentro del marco más amplio de CI/CD y mantener sólidas posturas de seguridad.

Revise las herramientas de canalización

El ciclo DevOps contiene varias herramientas con diferentes necesidades de acceso y permisos. Jeremy Hess, jefe de relaciones con los desarrolladores de la plataforma de gestión de secretos Akeyless, llama a esto una «expansión de secretos».

“La combinación de proliferación y descentralización de secretos crea una carga operativa, si no una pesadilla”, dice Hess. «Para las organizaciones que operan tanto en un entorno nativo de la nube como en una infraestructura de TI clásica, se crea un problema de duplicación debido a que sus propios secretos se administran con diferentes herramientas y soluciones nativas de la nube».

También existe el riesgo de que estas herramientas expongan las credenciales y los permisos de los usuarios a actores malintencionados. Por ejemplo, las herramientas de configuración como Jenkins usan complementos para determinar el acceso y la implementación de artefactos. Gracias a la comunicación con otras herramientas de canalización, los detalles de las credenciales pueden estar presentes en los detalles de configuración.

Las contraseñas de los desarrolladores no están visibles en la interfaz, pero se puede acceder a ellas desde el sistema. Cualquier usuario con permisos de «configuración» puede solicitar una credencial e inyectarla en los agentes. El resultado es que las claves de AWS, las credenciales de git y las contraseñas están en riesgo.

Qué hacer:

  • El primer paso es eliminar los secretos codificados de los archivos de herramientas de CI/CD.
  • La distribución de secretos entre varios archivos de configuración de herramientas también lessen la posibilidad de ataques al tiempo que facilita el acceso de desarrolladores e ingenieros.
  • Los administradores de contraseñas también son una buena opción, pero valídelos por seguridad antes de implementar una solución.

Practique el acceso con privilegios mínimos

Los problemas de acceso a menudo generan mucha frustración entre los equipos de DevOps, ya que se ven obligados a asignar un acceso common a la mayoría, independientemente del rol o la función laboral del miembro. Si bien esta situación fomenta un desarrollo rápido, crea problemas de seguridad masivos.

Equilibrar la seguridad con las necesidades de CI/CD es difícil de lograr. Ahí es donde entra en juego el principio de privilegio mínimo. Los miembros del equipo reciben acceso a los secretos en función de la necesidad de conocerlos. Tenga en cuenta que este principio se aplica a todo, desde aplicaciones hasta sistemas y dispositivos conectados.

Si bien la mayoría de los equipos ponen en práctica este principio, dejan su proceso intacto. La falta de auditorías de acceso, no el nivel de acceso, genera frustración en DevOps.

Qué hacer:

  • Los CISO deben involucrar regularmente a los equipos de DevOps cuando revisan el acceso para mitigar los problemas rápidamente. Incorporar un rol de seguridad dentro de cada equipo de entrega mitigará rápidamente los riesgos relacionados con el acceso. El miembro del equipo de seguridad tendrá información sobre las necesidades de acceso basadas en riesgos y podrá aprobar o rechazar solicitudes rápidamente.
  • La creación de un repositorio de administración de acceso también eliminará cualquier confusión relacionada con el acceso basado en funciones. Además, registre los permisos de acceso basados ​​en tiempo y tareas en el repositorio. El resultado es que cada miembro del equipo de DevOps comprenderá sus rutas de acceso antes de que comiencen los proyectos. Les da tiempo para ofrecer comentarios y solicitar acceso único a secretos confidenciales.
  • Revise las reglas de segmentación dentro de sus sistemas cuando asigne acceso basado en roles. A menudo, estas reglas tendrán que cambiar según los plazos de entrega. Involucrar a todas las partes interesadas en estas discusiones es una buena práctica y evita la frustración en el futuro.

La implementación de contraseñas de un solo uso (OTP) y otros factores de autenticación también es una buena idea al validar el acceso de los usuarios a los secretos.

Revisar proyectos OSS

Los proyectos de código abierto son esenciales para el crecimiento de la industria, pero pueden presentar riesgos de seguridad si el acceso no se gestiona correctamente. Zan Markan, defensor de los desarrolladores de la plataforma CI CircleCI, resume el problema acertadamente.

«A menudo, la empresa que inició y es propietaria de un well-liked proyecto de OSS continúa empleando a los colaboradores principales», escribe Markan. «Probablemente se les unirán otros colaboradores habituales y mantenedores que no forman parte de esa empresa. Y luego están todos los demás, cualquiera que ocasionalmente pueda contribuir con una solución o una función».

A medida que crece el acceso de los usuarios, las preocupaciones por la seguridad crecen exponencialmente. Hacer cumplir un acceso rígido basado en el usuario no es realista y es perjudicial para un proyecto de OSS.

Qué hacer:

  • Los CISO u otros administradores centrados en la seguridad deben revisar si se transmiten secretos confidenciales durante las compilaciones para las solicitudes de incorporación de cambios. Supervisar quién puede realizar solicitudes y los roles que las revisan garantizará un buen nivel de seguridad.
  • Establecer la identidad de la máquina también es basic, dado el grado de acceso que requieren las canalizaciones no humanas. La autenticación se puede basar en verificar si los atributos del contenedor de tiempo de ejecución del cliente coinciden con las características del contenedor válido. Una vez autenticado, el acceso basado en roles puede hacerse cargo, limitando el acceso a los secretos.
  • También es una buena política destruir contenedores y máquinas virtuales (VM) después de que se hayan utilizado.

La optimización de las operaciones de DevOps es una prioridad máxima

DevOps es essential para el éxito de todas las organizaciones. Los problemas relacionados con el acceso y los permisos son situaciones comunes que se evitan fácilmente. Revisar el acceso y establecer un equilibrio entre la entrega y las necesidades operativas es esencial para mantener una ventaja competitiva.



Enlace a la noticia unique