Históricamente, las aplicaciones se han desplegado y creado de una forma que recuerda a los clásicos centros comerciales. En primer lugar, un desarrollador construye el centro comercial y, a continuación, crea las distintas tiendas de su interior. Las tiendas se ajustan a las dimensiones del centro comercial y operan dentro de su plano.
En los enfoques más antiguos del desarrollo de aplicaciones, el desarrollador tenía un sistema o conjunto de sistemas para el que pretendía crear una aplicación. Este sistema sería el centro comercial. Entonces, al crear la aplicación, la adaptaba para que encajara dentro de los confines del sistema objetivo, como la tienda del centro comercial.
Históricamente, sin embargo, han surgido problemas con este enfoque. ¿Qué pasa si quiero desplegar una tienda en un centro comercial pero la tienda no encaja en los planos del centro comercial? El mismo principio se aplica a las aplicaciones. ¿Qué ocurre si quiero desplegar una aplicación en un sistema para el que no ha sido diseñada? Normalmente, no funciona.
El sector minorista encontró una solución creativa al problema de las tiendas de ladrillo y mortero inadaptadas: el comercio electrónico. Con los sitios web, se podían vender artículos que no cabían en los escaparates físicos. Del mismo modo, el sector tecnológico tiene una solución para el problema de las aplicaciones inadaptadas: la contenedorización.
¿Qué es la contenedorización?
La contenedorización ofrece a los desarrolladores un método para distribuir aplicaciones como un paquete portátil.
Con la contenedorización, los desarrolladores e ingenieros pueden distribuir una aplicación como un paquete que contiene los componentes del sistema operativo necesarios para la aplicación. Esto permite a los ingenieros y desarrolladores crear aplicaciones sin preocuparse de si una aplicación se desplegará con éxito en un sistema operativo o plataforma personalizada. Dado que los contenedores normalmente sólo incluyen los componentes y archivos necesarios de su aplicación contenida, pueden tener una superficie de ataque significativamente reducida en comparación con otras soluciones como las máquinas virtuales.
Las máquinas virtuales se crearon originalmente como una solución para permitir que un único ordenador o servidor ejecutara software de forma aislada preservando la integridad del host de soporte. Se trataba de una evolución del despliegue de aplicaciones de software en hosts y hardware dedicados con la intención de proporcionar una mayor portabilidad y seguridad. Las máquinas virtuales logran este objetivo pero también incluyen software y herramientas que no son utilizadas por una aplicación desplegada pero sí por los atacantes. Las funcionalidades y utilidades adicionales dentro del entorno que ejecuta una aplicación proporcionan a los atacantes funcionalidades que pueden aprovechar para atacar aún más a las organizaciones.
Aunque se pretende que los contenedores no incluyan herramientas y funcionalidades extra como las máquinas virtuales, los contenedores no están exentos de riesgos o problemas de seguridad. Los contenedores no proporcionan un aislamiento perfecto del host en el que se ejecutan, como pretenden hacer las máquinas virtuales. Hay software y funcionalidad compartidos entre los contenedores y sus hosts ejecutores que aumentan el riesgo para el host, como compartir el mismo kernel, lo que normalmente no es un problema con las máquinas virtuales. A veces, esta funcionalidad compartida puede utilizarse para escapar de un contenedor y permitir a un atacante acceder a otros contenedores y a información sensible dentro del host del contenedor.
Dentro del contenedor, al igual que las máquinas virtuales, los secretos y la información sensible son utilizados por las aplicaciones y pueden suponer un riesgo para otros sistemas si son descubiertos por los atacantes. Las aplicaciones que dependen de credenciales de bases de datos, por ejemplo, podrían tener esas credenciales almacenadas en archivos incluidos dentro de la imagen del contenedor. Si la imagen del contenedor se publicara, supondría un grave riesgo para la base de datos y los datos que contiene. Aunque los contenedores no contienen sistemas operativos completos, las partes de un sistema operativo que sí contienen pueden quedar obsoletas y ser vulnerables a los ataques. Las bibliotecas que las aplicaciones utilizan en sus cadenas de suministro de software también pueden ser vulnerables, especialmente si están obsoletas.
Abundan las vulnerabilidades de los contenedores
El interior de un contenedor no es el único lugar que puede contener vulnerabilidades. La forma en que un contenedor específico interactúa con su entorno también puede crear vulnerabilidades. Las aplicaciones que están diseñadas para ejecutarse en entornos de nube como contenedores pueden tener funcionalidad adicional implementada para la integración con esos entornos. La integración puede elevar el riesgo de un ataque.
El proveedor de la nube, el contenedor y la plataforma en la que opera el contenedor representan el contexto de un contenedor. El contexto en el que se ejecuta un contenedor puede incluir cosas como cuentas de servicio que la aplicación dentro del contenedor puede aprovechar para acceder al entorno de la nube. Las cuentas de servicio pueden tener permisos y privilegios asignados que pueden ser demasiado amplios y permitir a un atacante realizar operaciones en la plataforma del proveedor de la nube. Estas operaciones podrían incluir el acceso a bases de datos con datos confidenciales, como números de tarjetas de crédito, o la creación de mineros de criptomonedas que ejecuten altos costes en las cuentas.
Cómo proteger sus entornos en contenedores
Para evitar este tipo de problemas, se han creado muchas herramientas que permiten a los ingenieros analizar la seguridad de los contextos en los que se ejecutan las aplicaciones en contenedores. Las herramientas que se han creado, como Snyk y KubeAudit más notablemente, escanean configuraciones y permisos para identificar permisos que pueden ser demasiado amplios o configuraciones que podrían permitir escapes de contenedores o vulnerabilidades de aplicaciones. Estas herramientas son fantásticas para identificar problemas muy básicos dentro de sus dominios objetivo.
Desafortunadamente, la mayoría de las veces estas herramientas se construyen a partir de ideas preconcebidas sobre cómo se construyen e integran las aplicaciones en sus contextos de nube. Sin embargo, a menudo estas ideas preconcebidas no coinciden con la realidad y, por lo tanto, informan a los ingenieros de «problemas» de seguridad que no son relevantes para los contenedores y las aplicaciones dentro del entorno. Las aplicaciones en contenedores necesitan muchas veces interactuar e integrarse con su plataforma de una forma dictada por los requisitos empresariales que las diversas herramientas automatizadas no pueden tener en cuenta. Estos falsos positivos pueden hacer perder mucho tiempo. Dado que las plataformas y utilidades que ejecutan contenedores están diseñadas para la integración, el sistema resultante de contenedor, contexto y proveedor de nube necesita ser revisado y atacado utilizando la mentalidad de un atacante para determinar la seguridad cuantificable real del sistema integrado. Este proceso sólo puede realizarlo un humano, y así es como irrumpen los atacantes del mundo real.
Un buen enfoque práctico para minimizar el riesgo en entornos de contenedores aprovecha todos los recursos disponibles. Afortunadamente, muchas de las herramientas y recursos disponibles son gratuitos y fáciles de usar. Muchos proveedores de servicios en la nube ofrecen servicios de escaneado de imágenes de contenedores, que están integrados en sus plataformas. El uso de estos servicios puede añadir un valor significativo. Aprovechar los escáneres de configuración tanto para cuentas en la nube como para entornos de plataformas de contenedores puede proporcionar un punto de partida fantástico para determinar el riesgo inicial de estos entornos y ayudar a los equipos a remediar cualquier problema de poca importancia.
La utilización de Kubernetes y de sistemas de detección y respuesta de puntos finales conscientes de los contenedores puede proporcionar inteligencia sobre un compromiso antes de que un atacante pueda afectar a sus sistemas. Después de tomar esas medidas, las pruebas de penetración se pueden utilizar para cortar a través de los diversos falsos positivos y negativos de herramientas y sistemas de monitoreo, validar una postura de seguridad, y dar inteligencia procesable sobre su entorno con recomendaciones específicas de contexto.
X-Force Red, el equipo de hackers de IBM Security, puede proporcionar servicios de pruebas de contenedores a organizaciones de todo el mundo. Su objetivo es descubrir y ayudar a corregir fallos dentro y alrededor de los contenedores en la nube. Las pruebas incluyen los propios contenedores y su infraestructura de apoyo, como los orquestadores. Para obtener más información, descargue la hoja informativa de X-Force Red Container Testing Services aquí.
Fuente WEB | Editado por CambioDigital OnLine
