Los contenedores revolucionaron el proceso de desarrollo, actuando como piedra angular para las iniciativas DevOps, pero los contenedores conllevan riesgos de seguridad complejos 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 contribuyeron al desarrollo ágil, qué riesgos de seguridad únicos aportan los contenedores y qué pueden hacer las organizaciones para proteger las cargas de trabajo en contenedores, yendo más allá de DevOps para lograr DevSecOps.
¿Por qué los contenedores se hicieron populares 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 la prueba y la implementación; de todos modos, un método que es más liviano que el uso de máquinas virtuales completas.
El núcleo de este problema es la compatibilidad de las aplicaciones, ya que las aplicaciones requieren ciertas versiones de bibliotecas, lo que podría entrar en conflicto con los requisitos de otras aplicaciones. Los contenedores solucionaron este problema y se vincularon bien con los procesos de desarrollo y la infraestructura de administración que impulsa estos procesos.
Los contenedores hacen su trabajo al llevar la virtualización al siguiente nivel. La virtualización abstrae la capa de hardware, mientras que los contenedores abstraen la capa del sistema operativo, esencialmente virtualizando el rol del sistema operativo. La creación de contenedores funciona al empaquetar aplicaciones en “contenedores” que incluyen todas las bibliotecas necesarias para que una aplicación funcione, mientras mantiene las aplicaciones sin conocimiento entre sí, ya que cada aplicación cree que tiene el sistema operativo para sí misma.
Funcionalmente, los contenedores son bastante simples: un contenedor es solo un archivo de texto con una descripción que describe qué componentes deben incluirse en una instancia. Esta simplicidad y la naturaleza más liviana de un contenedor facilitan el uso de herramientas de automatización (orquestación) para la implementación 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 claves que desbloquean DevOps. Esa es probablemente una de las principales razones por las que los contenedores se han popularizado tanto, y Gartner estima que para 2023, El 70% de las organizaciones ejecutarán cargas de trabajo en contenedores.
El proceso de desarrollo, prueba e implementación de aplicaciones solía estar lleno de obstáculos, con un ir y venir constante entre los desarrolladores y los equipos que cuidan la infraestructura. Hoy, gracias a los contenedores, los desarrolladores pueden crear 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 simplemente ejecutan esta especificación para crear un entorno coincidente que esté listo para usar. “Sí, pero funciona en mi máquina…” nunca ayudó a solucionar el problema, pero hoy, esa es una expresión que los desarrolladores ya no necesitan usar porque no hay problemas ambientales para depurar.
Entonces, sí, DevOps significa desarrollo rápido. Pero falta un componente: la seguridad. Esta es la razón por la que escuchamos cada vez más acerca de DevSecOps a medida que evoluciona de DevOps porque los desarrolladores han notado que el modelo DevOps por sí solo no aborda suficientemente las preocupaciones de seguridad.
Los contenedores introducen varios riesgos de seguridad
Los contenedores simplifican el proceso de desarrollo pero introducen complejidad en la imagen de seguridad. Cuando empaqueta un entorno operativo completo en un contenedor solo para distribuirlo ampliamente, también aumenta la superficie de ataque y abre la puerta a diferentes vectores de ataque. Cualquier biblioteca vulnerable empaquetada con el contenedor distribuirá estas vulnerabilidades en innumerables cargas de trabajo.
Hay varios riesgos. Uno es un “ataque de la cadena de suministro” en el que un actor malévolo monta un ataque no interfiriendo con su aplicación, sino modificando uno de los paquetes o componentes que se suministran con su aplicación. Por lo tanto, los equipos que se ocupan de los esfuerzos de desarrollo deben evaluar la aplicación que están desarrollando y cada biblioteca incorporada como una dependencia por la configuración del contenedor.
Los riesgos para la seguridad de los contenedores también involucran las herramientas que habilitan los contenedores, desde Dockers hasta herramientas de orquestación como Kubernetes, ya que estas herramientas necesitan ser monitoreadas y protegidas. Por ejemplo, no debe permitir que los administradores de sistemas ejecuten contenedores Docker como raíz. Del mismo modo, debe vigilar de cerca los registros de sus contenedores para asegurarse de que no se vean comprometidos.
La seguridad del kernel en el centro de la seguridad de los contenedores
Algunos de los riesgos de seguridad relacionados con los contenedores son menos visibles que otros. Cada contenedor necesita acceso a un kernel; después de todo, los contenedores son solo un tipo de aislamiento de proceso avanzado. Pero es fácil pasar por alto el hecho de que todos los contenedores se basan en el mismo kernel; no importa que las aplicaciones dentro de los contenedores estén separadas entre sí.
El kernel que ven las aplicaciones en un contenedor es el mismo que el kernel en el que se basa el host para operar. Trae un par de problemas. Si el núcleo del host que admite el contenedor es vulnerable a un exploit, esta vulnerabilidad puede aprovecharse iniciando un ataque desde una aplicación dentro de un contenedor.
Por lo tanto, el hecho de que todos los contenedores del host compartan el kernel significa que un kernel defectuoso debe parchearse rápidamente, o todos los contenedores pueden verse afectados rápidamente por la vulnerabilidad.
Una vez más, se trata de parchear
Mantener actualizado el kernel del host es, por lo tanto, un paso importante para garantizar operaciones de contenedores seguras. Y no es solo el kernel el que necesita parches, los parches deben aplicarse a las bibliotecas extraídas por un contenedor. Pero, como sabemos, parchear constantemente es más fácil decirlo que hacerlo. Probablemente por eso un estudio encontró que el 75% de los contenedores analizados contenían una vulnerabilidad que se clasifica como crítico o de alto riesgo.
Estas vulnerabilidades pueden provocar, por ejemplo, ataques de ruptura en los que un atacante confía en una biblioteca defectuosa dentro de un contenedor para poder ejecutar código fuera del contenedor. Al violar un contenedor, el atacante puede eventualmente llegar a su objetivo previsto, ya sea el sistema host o una aplicación en otro contenedor.
En el contexto de los contenedores, mantener bibliotecas seguras puede ser un verdadero dolor de cabeza: alguien necesita rastrear nuevas vulnerabilidades, así como lo que se ha parcheado y lo que no. El proceso es laborioso, pero también requiere habilidades especializadas, algo que su organización necesitaría adquirir si aún no las tiene.
Dado el valor de la aplicación regular y consistente de parches, esas razones no deberían ser suficientes para causar el tipo de rutinas de parcheo impredecibles que vemos, pero, particularmente cuando se piensa en el kernel del sistema operativo, la interrupción de los reinicios necesarios y el asociado. la necesidad de mantener ventanas de tiempo de inactividad puede retrasar significativamente la aplicación de parches. Parches de kernel en vivo ayuda a mitigar este problema, pero aún no lo implementan todas las organizaciones.
Incluya siempre objetivos de seguridad en sus operaciones de contenedores
Es común que la tecnología de punta introduzca nuevas complicaciones en lo que respecta a la seguridad de la información. Las nuevas herramientas comúnmente conducen a exploits nuevos y novedosos. Eso también es cierto para los contenedores y, si bien no socava el valor general del uso de contenedores en sus cargas de trabajo, sí significa que debe estar atento a 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. Parchar es otro aspecto importante. Como siempre, implementar los pasos correctos para mitigar las fallas de seguridad cibernética ayudará a proteger su organización y permitirá que su equipo se beneficie de esa tecnología de vanguardia sin sufrir noches de insomnio.