Gestión de la seguridad de los containers con el escaneo de containers y otras opciones
Aunque gran parte de la conversación en torno a la seguridad de los containers se centra actualmente en los requisitos de seguridad de las plataformas de orquestación como Kubernetes, no todos los riesgos de seguridad de los containers se pueden abordar a nivel de orquestación. También es importante gestionar las amenazas a los containers individuales.
La mejor manera de hacerlo es seguir las prácticas de seguridad estándar de Docker, que datan de los primeros días de los containers de Docker tras su lanzamiento en 2013. Aunque el ecosistema de containers ha evolucionado hoy en día más allá de Docker (de hecho, Docker en sí ya no forma parte de muchas pilas de aplicaciones en containers, que en su lugar utilizan otros tiempos de ejecución y otras soluciones de orquestación), todavía se siguen aplicando los principios fundamentales de seguridad de Docker, como el escaneo de containers, la gestión de vulnerabilidades en containers y el control de acceso a los mismos.
Este artículo vuelve a estos principios básicos para ofrecer una visión general de las principales categorías de vulnerabilidades en containers, así como las medidas que las empresas pueden tomar para solventarlas.
Vulnerabilidades en imágenes de containers
Las vulnerabilidades en imágenes siguen siendo el tipo de amenaza de seguridad más frecuente para los containers individuales. Una vulnerabilidad en una imagen de container es un riesgo de seguridad que está incrustado dentro de una imagen de container. Aunque las imágenes vulnerables no suponen en sí mismas una amenaza activa, si se crean containers basados en una imagen vulnerable, estos introducirán la vulnerabilidad en un entorno activo.
Las vulnerabilidades en las imágenes de containers suelen originarse en bibliotecas inseguras u otras dependencias que se importan en una imagen de un container. Las imágenes también pueden contener código malicioso insertado durante un ataque a la cadena de suministro de software o una brecha similar del entorno de desarrollo.
Detección de las vulnerabilidades en imágenes con el escaneo de containers
Afortunadamente, la mayoría de las vulnerabilidades en imágenes de containers se pueden detectar con relativa facilidad mediante el escaneo de containers. El escaneo de containers es el despliegue de herramientas automatizadas que comparan el contenido de cada container con una base de datos de vulnerabilidades conocidas. Si estas herramientas determinan que una biblioteca u otra dependencia dentro de una imagen de container está expuesta a una vulnerabilidad conocida, marcarán la imagen como insegura.
La principal limitación del escaneo de containers es que no suele ser útil para detectar vulnerabilidades desconocidas, es decir, aquellas que aún no se han hecho públicas o se han puesto a disposición de los analistas de seguridad. Esto significa que, si su imagen de container utiliza una biblioteca que tiene un fallo de seguridad pero dicho fallo aún no ha sido descubierto, los escáneres de imágenes de containers no lo detectarán porque el fallo no estará registrado en las bases de datos de vulnerabilidades que utilizan. Tampoco es probable que se detecten las vulnerabilidades que afectan al código propietario personalizado, ya que no se hace un seguimiento público de las mismas.
Si bien el escaneo de imágenes de containers es un paso crucial para proteger los containers, es importante tener en cuenta que se trata únicamente de un paso, no de una solución completa de gestión de vulnerabilidades.
Imágenes maliciosas de containers
Aunque las imágenes legítimas de containers pueden (y a menudo lo hacen) contener vulnerabilidades, las imágenes maliciosas que los atacantes diseñan deliberadamente para hacerse pasar por imágenes legítimas son un riesgo mucho mayor para la seguridad de las imágenes de Docker. Subiendo una imagen que contenga malware a un registro público de containers como Docker Hub y dándole un nombre que parezca legítimo (como mysqldatabase o nginxserver), los atacantes pueden engañar a los administradores desprevenidos para que desplieguen versiones maliciosas de software de dominio público.
Cómo evitar las imágenes maliciosas
Los escáneres de imágenes de Docker pueden no detectar estas imágenes si contienen malware que no está asociado con una vulnerabilidad conocida. Por esta razón, la mejor manera de protegerse de las imágenes maliciosas es asegurarse de que las imágenes que descarga proceden de fuentes de confianza. Evite los registros no oficiales de Docker Hub o los repositorios de GitHub.
Evite así mismo usar la etiqueta “latest” cuando extraiga imágenes de containers. En su lugar, especifique una versión de la imagen. Eso reduce el riesgo de que los atacantes introduzcan una imagen maliciosa en un registro de containers por lo demás legítimo y engañen a la gente para que la utilice otorgándole un número de versión más reciente que las demás imágenes.
Amenazas de escalada de privilegios
Aun en el caso de que todas las imágenes de containers que despliegue estén libres de vulnerabilidades, podría producirse una brecha debido a un ataque de escalada de privilegios.
En un ataque de escalada de privilegios, los procesos que supuestamente solo pueden acceder a los recursos dentro de un container determinado “escapan” del mismo y acceden a los recursos de otros containers o del servidor anfitrión.
Prevención de la escalada de privilegios
El principal vector de escalada de privilegios son los fallos en el software de tiempo de ejecución del container, que es responsable de su ejecución, o en el sistema operativo anfitrión.
Por lo tanto, el principal medio de defensa contra la escalada de privilegios es asegurar el tiempo de ejecución del container y el sistema operativo anfitrión. Para ello, deberá asegurarse de que todo el software que se ejecuta en el servidor anfitrión (o servidores) esté actualizado y no contenga vulnerabilidades conocidas.
También puede reducir el riesgo de un ataque de escalada de privilegios desplegando un marco de endurecimiento del núcleo (hardening), como AppArmor o SELinux. Estos marcos imponen controles de acceso adicionales (basados en políticas que usted configura y aplica) al sistema operativo anfitrión, proporcionando una segunda capa de defensa contra procesos que escapan de los containers en los que deberían estar.
Por último, elegir un sistema operativo minimalista, como Alpine Linux, puede limitar el riesgo de escalada de privilegios en containers al reducir el número de bibliotecas y servicios que puede explotar un atacante. La práctica más recomendable es que su OS anfitrión no incluya más software que el mínimo necesario para desplegar, orquestar, monitorizar y proteger los containers. Si desea ejecutar otras workloads junto con sus containers, hágalo en un otro servidor o VM diferentes.
Vulnerabilidades de la aplicación
Independientemente de lo seguras que sean las imágenes de los containers y el entorno en el que se ejecutan, tendrá problemas de seguridad si la aplicación que aloja utilizando containers contiene fallos en su código fuente.
Por ejemplo, una validación de entrada de datos insuficiente podría permitir ataques como la inyección SQL y facilitar así que los atacantes puedan acceder a información sensible. O bien, una vulnerabilidad de desbordamiento de búfer podría permitir a los atacantes ejecutar código arbitrario y hacerse con el control de su container (y, posiblemente, de todo el host).
Gestión de las vulnerabilidades de la aplicación
Como las vulnerabilidades de la aplicación ocurren en el código de la aplicación y no en los procesos o herramientas asociados con los containers, las vulnerabilidades deberán gestionarse a nivel de la aplicación.
Escanee el código fuente de su aplicación en busca de vulnerabilidades como parte de su pipeline de CI/CD, utilizando para ello pruebas de seguridad de aplicaciones estáticas capaces de identificar prácticas de codificación deficientes que podrían permitir amenazas. Vuelva a probar la aplicación antes de su despliegue utilizando pruebas de seguridad de aplicaciones dinámicas, un método que supervisa una aplicación que se ejecuta en un entorno de caja de arena para detectar comportamientos que indiquen una vulnerabilidad de seguridad.
También en este caso, los marcos de endurecimiento del núcleo, como SELinux y AppArmor, pueden ayudar a reducir el riesgo de vulnerabilidades de la aplicación al dificultar la ejecución de exploits. Pero estos recursos no resuelven la principal causa de la inseguridad de las aplicaciones.
Uso de los puntos de referencia CIS para Docker
Aunque no es posible garantizar la ausencia total de amenazas de seguridad de los containers, puede ser útil establecer una línea de base comparando las configuraciones de sus containers con los puntos de referencia de seguridad para Docker del Center for Internet Security (CIS).
Los puntos de referencia de seguridad del CIS abarcan todas las capas de la pila de software de los containers. Establecen las mejores prácticas para, entre otros, asegurar el host, configurar los permisos en las imágenes de los containers y configurar el tiempo de ejecución de estos.
Así pues, aunque el cumplimiento de las recomendaciones del CIS no garantiza la seguridad de Docker, merece la pena dedicarle tiempo a revisar los puntos de referencia y asegurarse de que se cumplen todos.
Para desplegar containers seguros en un entorno seguro, se necesitan herramientas y prácticas que puedan hacer frente a diferentes amenazas. Desde los escáneres de imágenes de containers hasta los marcos de endurecimiento del núcleo o la seguridad de las aplicaciones, por ejemplo, necesitará todo un abanico de defensas que le permitan minimizar el riesgo de vulnerabilidades de seguridad en los entornos de aplicaciones en containers.