Mejores prácticas de seguridad de DevOps

La seguridad de DevOps consiste en aplicar políticas y tecnologías de seguridad de la información a todo el ciclo de vida y flujo de valor de DevOps. Como DevOps suele abarcar todas las etapas del ciclo de vida del desarrollo de software (SDLC), una seguridad eficaz es aún más importante.

Para la mayoría de las organizaciones, la seguridad de la información no es algo nuevo. Una de las principales preocupaciones de la tecnología de la información es cómo protegerla de los ataques. Sin embargo, la infraestructura de DevOps se aparta considerablemente de los paradigmas de TI más tradicionales. ¿Cómo se puede aplicar correctamente la seguridad de la información a DevOps?

Comparación entre DevOps y DevSecOps

Conoce más sobre la transición de DevOps a DevSecOps aquí.

4 desafíos principales de la seguridad de DevOps

El paso de los modelos tradicionales de TI y desarrollo de software al enfoque moderno y ágil de DevOps ha dado lugar a nuevos desafíos de seguridad, que requieren no solo un cambio en las herramientas de seguridad, sino también en la cultura, las personas y los procesos. Aunque suele considerarse que DevOps combina desarrollo y operaciones, DevOps y seguridad han seguido funcionando por separado.

1. Ritmo acelerado de cambio

Uno de los efectos más notorios en la seguridad es el ritmo acelerado de cambio de DevOps. En los entornos heredados, la nueva infraestructura solía aprovisionarse como hardware físico dedicado, con un largo intervalo entre la solicitud de aprovisionamiento y la disponibilidad funcional. El desarrollo de software solía seguir un ritmo en cascada, con lanzamientos importantes cada varios meses o trimestres. En cambio, en los entornos ágiles modernos pueden realizarse varios despliegues a producción en un solo día.

Además, el uso de infraestructura basada en la nube permite ampliar la capacidad en cuestión de minutos, en lugar de horas o días. Todo esto se traduce en un aumento considerable del ritmo de cambio en un entorno determinado. La tecnología y los procesos heredados no se diseñaron para adaptarse a un entorno con tantas variaciones.

2. Seguridad en la nube

Otro desafío es consecuencia directa de la prevalencia de las arquitecturas que priorizan la nube. En comparación con una implementación tradicional local, la nube presenta una superficie de ataque mucho más amplia, con límites de red poco definidos y difusos. Casi cualquier recurso aprovisionado puede configurarse para permitir el acceso desde el tráfico público de Internet con solo unos clics o líneas de código. La seguridad de red heredada partía del supuesto de que la red estaría bien definida, con unos pocos vectores de entrada y salida bien establecidos. Conoce más sobre los desafíos de la seguridad en la nube.

3. Contenerización de cargas de trabajo

Esto también incorpora nuevas variables al entorno de seguridad. Los contenedores ofrecen características atractivas para los flujos de trabajo modernos de desarrollo e implementación, pero la mayor complejidad del motor subyacente, la orquestación y las redes implica más vectores de ataque potenciales que deben monitorearse y protegerse.

4. Colaboración

Las herramientas, tecnologías y procesos de seguridad heredados simplemente no se diseñaron para muchos de estos casos de uso. Los equipos de seguridad e ingeniería aislados no podrán escalar al ritmo rápido e iterativo de una cultura que prioriza DevOps. Cuando seguridad e ingeniería operan en compartimentos separados, suelen duplicar tareas operativas y flujos de información que podrían reunirse fácilmente en un solo lugar.

También es fundamental crear un solo pipeline para que los equipos estén coordinados y reciban la misma información de la misma fuente. Sin embargo, en realidad no es raro ver organizaciones que ejecutan dos agentes de Splunk en el mismo equipo: uno para el equipo de seguridad y otro para el equipo de aplicaciones; o un equipo de fraude que recibe datos tanto de seguridad como de infraestructura, cada uno con pipelines de eventos completamente independientes y paralelos.

¿Qué pasa con DevSecOps?

DevSecOps integra el modelo de DevOps —entrega de software con retroalimentación rápida y cultura organizacional— con las prácticas de seguridad de la información. A diferencia de la seguridad de DevOps, que incorpora la seguridad de la información a las etapas del ciclo de DevOps después de que ocurren, DevSecOps busca integrar los objetivos de seguridad e ingeniería con un enfoque de «shift left».

La seguridad se está desplazando hacia la izquierda

Figura 2: Los objetivos de seguridad se desplazan hacia la izquierda

La seguridad de DevOps suele comenzar con una mentalidad o postura general. En la seguridad de DevOps, las herramientas no lo son todo. Las prácticas de DevSecOpsno consisten en marcar casillas de una lista de tareas. Si el equipo no tiene una mentalidad de seguridad, será casi imposible lograr el objetivo de contar con una plataforma segura.

En DevSecOps, los objetivos de seguridad se aplican a las distintas etapas del ciclo de vida mediante las herramientas y los procesos disponibles. Es posible que los equipos de seguridad sigan trabajando en silos separados de los equipos de ingeniería y operaciones, aunque exista una cultura más colaborativa. Si bien el modelo de responsabilidad compartida entre desarrollo y operaciones ha sido un principio fundamental de DevOps desde sus inicios, la seguridad todavía suele implicar la interacción con un equipo u organización de seguridad externa y aislada.

DevSecOps busca integrar los objetivos de seguridad en todo el ciclo de vida de DevOps, especialmente en las primeras etapas de diseño y desarrollo. Las responsabilidades de seguridad se «desplazan hacia la izquierda», lo que permite que los desarrolladores se hagan cargo de corregir los problemas antes de que lleguen a entornos con SLA más estrictos.

Para las empresas con equipos reducidos, desplazar la seguridad hacia la izquierda puede ayudar a aliviar parte de la carga de corrección que recae en los equipos de seguridad. En el caso de Reddit, una API automatizada permitió que un equipo de seguridad pequeño administrara una gran cantidad de repositorios y también dio a los desarrolladores la capacidad de hacerse cargo de corregir los problemas de seguridad:

«Después de limpiar nuestros repositorios, cambiamos el enfoque para que los nuevos pull requests fallaran si contenían vulnerabilidades de seguridad. Esto hizo que Reddit dejara de depender de un enfoque reactivo iniciado por el equipo de seguridad y adoptara uno centrado en los desarrolladores y liderado por ellos para corregir los problemas. La única forma de gestionar todo este trabajo era usar la API de Snyk».

Spencer Koch, profesional de seguridad en Reddit

Las capacidades de retroalimentación rápida de DevOps y las herramientas de DevSecOps, en especial CI/CD, permiten que los desarrolladores respondan de inmediato a los comentarios automatizados sobre seguridad, eliminando los ciclos de revisión manual y mejorando la postura de seguridad en todo el SDLC.

Pasa de DevOps a DevSecOps

¿Cómo puede una organización pasar de una cultura de DevOps a una de DevSecOps? La respuesta podría parecer contradictoria: debe dejar de preocuparse por la seguridad. En cambio, una organización debe darles a todos la capacidad de hacerse responsables de ella. Hay algunas estrategias fundamentales que pueden ayudar a iniciar ese proceso.

Como se explicó antes, desplazar la seguridad hacia la izquierda es un aspecto clave de un esfuerzo serio de DevSecOps. Adelantar los objetivos de seguridad en el SDLC mejora los resultados generales de seguridad. ¿Cómo se ve esto en la práctica? En lugar de que los equipos de desarrollo entreguen los artefactos de implementación terminados para que seguridad los revise e informe sobre ellos al final del SDLC, la seguridad se integra sin problemas en los ciclos iniciales de desarrollo, incluidos el levantamiento de requisitos y el diseño.

No se trata de imponer requisitos engorrosos ni procesos adicionales sobre los flujos de trabajo existentes. El objetivo final es reducir al mínimo la fricción en cada etapa. DevSecOps permite que una organización adopte un ciclo de vida de desarrollo de software seguro (SSDLC).

Figura 3: DevSecOps + SDLC = SSDLC

Al ampliar el enfoque de desplazar la seguridad hacia la izquierda y dar a los desarrolladores e ingenieros de infraestructura la capacidad de hacerse responsables de los objetivos de seguridad de principio a fin, se fortalece la postura de seguridad de una aplicación. Para lograrlo, es necesario hacer hincapié en la automatización y los ciclos de retroalimentación rápida. Cuando un desarrollador envía código, debe recibir retroalimentación inmediata sobre posibles problemas de seguridad en las nuevas funciones o correcciones. Si esa retroalimentación es útil, el desarrollador realiza los cambios necesarios y la organización mejora de inmediato su seguridad sin la intervención de un ingeniero de seguridad.

En Red Ventures, centrarse en ofrecer una experiencia «sin fricción» a los desarrolladores permitió que se adoptaran fácilmente las iniciativas para mejorar aspectos críticos de la seguridad, en particular las cargas de trabajo en contenedores. Es posible aprovechar los flujos de trabajo existentes para reforzar la seguridad con una interrupción mínima.

Integrar aún más esta automatización en CI/CD permite analizar el código de las aplicaciones y los cambios de infraestructura como código (IaC) para detectar posibles problemas y ofrecer retroalimentación rápida cuando sea necesario.

Las organizaciones pueden mejorar los resultados de seguridad con DevSecOps

Figura 4: La propuesta de valor de DevSecOps

Cuando las organizaciones dejan de preocuparse por la seguridad de DevOps e implementan DevSecOps, hacen evolucionar su desarrollo y entrega de software hacia la siguiente etapa de la cultura DevOps. En la cultura de DevSecOps, la seguridad se suma al modelo colaborativo que comparten operaciones y desarrollo.

Desplazar la seguridad hacia la izquierda significa integrar los objetivos de seguridad desde el principio. Los desarrolladores, ingenieros de infraestructura y equipos de operaciones pueden hacerse responsables de los problemas de seguridad. Los ciclos de retroalimentación rápida propios de la cultura y las herramientas de DevSecOps permiten que la automatización, como los pipelines de CI/CD, ofrezca una visión detallada de los posibles problemas de seguridad en segundos o minutos, no en horas o días.

Elegir herramientas modernas para apoyar una iniciativa de DevSecOps es fundamental. Las herramientas y los procesos de seguridad heredados no se diseñaron para el ritmo acelerado de cambio propio de las arquitecturas nativas de la nube.

Con DevSecOps, una organización puede entregar software más rápido y de forma más segura y, en última instancia, generar más valor para sus clientes y para sí misma.