Los contenedores revolucionaron el proceso de desarrollo, actuando como piedra angular de las iniciativas DevOps, pero los contenedores conllevan complejos riesgos de seguridad que no siempre son obvios. Las organizaciones que no mitigan estos riesgos son vulnerables a los ataques.
En este artículo, describimos cómo los contenedores han contribuido al desarrollo ágil, qué riesgos de seguridad únicos aportan los contenedores y qué pueden hacer las organizaciones para asegurar las cargas de trabajo en contenedores, yendo más allá de DevOps para lograr DevSecOps.
¿Por qué los contenedores se pusieron de moda tan rápido?
Los contenedores son, en muchos sentidos, la evolución de la virtualización. El objetivo era acelerar el proceso de desarrollo, creando una ruta más ágil desde el desarrollo hasta las pruebas y la implementación – un método que es más ligero que el uso de máquinas virtuales completas, de todos modos.
El núcleo de este problema es la compatibilidad de las aplicaciones, ya que éstas requieren ciertas versiones de las bibliotecas, que podrían chocar con los requisitos de otras aplicaciones. Los contenedores solucionan este problema y resulta que se vinculan bien con los procesos de desarrollo y la infraestructura de gestión que impulsa estos procesos.
Los contenedores hacen su trabajo llevando la virtualización al siguiente nivel. La virtualización abstrae la capa de hardware, mientras que los contenedores abstraen la capa del sistema operativo, virtualizando esencialmente el papel del SO. La contenedorización funciona empaquetando las aplicaciones en «contenedores» que incluyen todas las librerías necesarias para que una aplicación funcione, a la vez que mantienen las aplicaciones ajenas entre sí, ya que cada aplicación piensa que tiene el SO para sí misma.
Funcionalmente, los contenedores son bastante sencillos: un contenedor no es más que un archivo de texto con una descripción que describe los componentes que deben incluirse en una instancia. Esta simplicidad y la naturaleza más ligera de un contenedor facilitan el uso de herramientas de automatización (orquestación) para el despliegue a lo largo del ciclo de vida del desarrollo.
DevOps para ganar… pero la seguridad también importa
Los contenedores tienen el poder de aumentar significativamente la eficiencia del desarrollo, actuando como las llaves que abren las operaciones de desarrollo. Esta es probablemente una de las principales razones por las que los contenedores se han puesto de moda, ya que Gartner estima que para 2023, el 70% de las organizaciones ejecutarán cargas de trabajo en contenedores.
El proceso de desarrollo, prueba y despliegue de aplicaciones solía estar lleno de obstáculos, con un constante ir y venir entre los desarrolladores y los equipos que se ocupan de la infraestructura. Hoy en día, gracias a los contenedores, los desarrolladores pueden construir y probar en un entorno que funciona y simplemente enviar el código terminado junto con una especificación que define ese entorno.
En el lado operativo, los equipos se limitan a ejecutar esta especificación para crear un entorno adecuado que esté listo para su uso. «Sí, pero funciona en mi máquina…» nunca ayudó a solucionar el problema, pero hoy en día, esa es una expresión que los desarrolladores ya no necesitan utilizar porque no hay problemas de entorno que depurar.
Así que, sí, DevOps significa desarrollo rápido. Pero hay un componente que falta: la seguridad. Por eso, cada vez oímos hablar más de DevSecOps, ya que evoluciona a partir de DevOps, porque los desarrolladores se han dado cuenta de que el modelo DevOps por sí solo no aborda suficientemente los problemas de seguridad.
Los contenedores introducen varios riesgos de seguridad
Los contenedores simplifican el proceso de desarrollo pero introducen complejidad en el panorama de la seguridad. Cuando se empaqueta un entorno operativo completo en un contenedor para luego distribuirlo ampliamente, también se aumenta la superficie de ataque y se abre la puerta a diferentes vectores de ataque. Cualquier librería vulnerable empaquetada con el contenedor propagará estas vulnerabilidades a través de innumerables cargas de trabajo.
Existen varios riesgos. Uno de ellos es el «ataque a la cadena de suministro», en el que un actor malintencionado monta un ataque, no trastocando su aplicación, sino modificando uno de los paquetes o componentes que se suministran con ella. Por lo tanto, los equipos que se encargan de los esfuerzos de desarrollo deben evaluar la aplicación que están desarrollando y cada una de las bibliotecas que la configuración del contenedor hace depender.
Los riesgos para la seguridad de los contenedores también implican a las herramientas que los habilitan, desde Dockers hasta herramientas de orquestación como Kubernetes, ya que estas herramientas deben ser supervisadas y protegidas. Por ejemplo, no se debe permitir que los administradores de sistemas ejecuten los contenedores Docker como root. Del mismo modo, debes vigilar de cerca tus registros de contenedores para asegurarte de que no se vean comprometidos.
Kernel security at the core of container security
Algunos de los riesgos de seguridad relacionados con los contenedores son menos visibles que otros. Todos los contenedores necesitan acceder a un kernel; al fin y al cabo, los contenedores no son más que un tipo de aislamiento avanzado de procesos. Pero es fácil pasar por alto el hecho de que todos los contenedores dependen del mismo kernel – no importa que las aplicaciones dentro de los contenedores estén segregadas unas de otras.
El kernel que ven las aplicaciones en un contenedor es el mismo que el kernel en el que se basa el host para funcionar. Esto conlleva un par de problemas. Si el kernel del host que soporta el contenedor es vulnerable a un exploit, esta vulnerabilidad puede ser explotada iniciando un ataque desde una app dentro de un contenedor.
Así que el hecho de que el kernel sea compartido por todos los contenedores en el host significa que un kernel defectuoso debe ser parcheado rápidamente, o todos los contenedores pueden ser rápidamente afectados por la vulnerabilidad.
Una vez más, se trata de parchear
Mantener el kernel del host actualizado es, por tanto, un paso importante para garantizar la seguridad de las operaciones de los contenedores. Y no sólo hay que parchear el kernel, también hay que aplicar parches a las librerías que utiliza el contenedor. Pero, como sabemos, aplicar parches de forma sistemática es más fácil de decir que de hacer. Probablemente por eso, un estudio descubrió que el 75% de los contenedores analizados contenían una vulnerabilidad clasificada como crítica o de alto riesgo.
Estas vulnerabilidades pueden dar lugar, por ejemplo, a ataques de fuga en los que un atacante se basa en una biblioteca defectuosa dentro de un contenedor para poder ejecutar código fuera del mismo. Al penetrar en un contenedor, el atacante puede llegar a su objetivo, ya sea el sistema anfitrión o una aplicación en otro contenedor.
En el contexto de los contenedores, el mantenimiento de las bibliotecas seguras puede ser un verdadero dolor de cabeza: alguien tiene que hacer un seguimiento de las nuevas vulnerabilidades, así como de lo que se ha parcheado y lo que no. El proceso es laborioso, pero también requiere conocimientos especializados que su organización deberá adquirir si no los tiene ya.
Dado el valor de la aplicación de parches de forma regular y consistente, estas razones no deberían ser suficientes para causar el tipo de rutinas de parcheo de acierto y error que vemos, pero -especialmente cuando se piensa en el núcleo del sistema operativo- la interrupción de los reinicios necesarios y la necesidad asociada de mantener ventanas de tiempo de inactividad pueden retrasar significativamente la aplicación de parches. La aplicación de parches en vivo en el núcleo ayuda a reducir este problema, pero todavía no está implantada en todas las organizaciones.
Incluya siempre los objetivos de seguridad en sus operaciones con contenedores
Es habitual que la tecnología punta introduzca nuevas complicaciones en lo que respecta a la seguridad de la información. Las nuevas herramientas suelen dar lugar a nuevos y novedosos exploits. Esto también ocurre con los contenedores y, aunque no socava el valor general del uso de contenedores en sus cargas de trabajo, significa que debe vigilar los riesgos que plantean los contenedores.
Educar a sus desarrolladores y administradores de sistemas sobre las fallas comunes en la seguridad de los contenedores y las mejores prácticas que mitigan estas fallas es un comienzo. La aplicación de parches es otro aspecto importante. Como siempre, poner en marcha los pasos adecuados para mitigar los fallos de ciberseguridad ayudará a proteger su organización, y permitirá a su equipo beneficiarse de esa tecnología de vanguardia sin sufrir noches de insomnio.
