Asegurar contenedores con confianza cero



Un enfoque basado en la identidad del computer software debería convertirse en una medida de seguridad estándar para proteger las cargas de trabajo en todas las redes empresariales.

Los contenedores tienen muchos beneficios: fácil portabilidad, menos requisitos del sistema y mayor eficiencia, solo para empezar. Pero estos beneficios tienen un costo. Para proporcionar estos beneficios, los contenedores se basan en redes extremadamente complejas, muchas de ellas opacas, con direcciones de pink efímeras y en constante cambio. Como resultado, es un gran desafío asegurar los contenedores a través de tecnologías que dependen de direcciones IP confiables, como firewalls o microsegmentación tradicional.

Echemos un vistazo a cómo los contenedores gestionan las redes. Cuando se introdujo Docker basic, Docker necesitaba una forma de baja fricción para introducir contenedores, por lo que utilizó la traducción de direcciones de red (NAT), que modifica la información de la dirección de crimson en el encabezado IP durante el tránsito para reasignar el espacio de direcciones. Simplifica la administración de TI al ocultar la complejidad de la crimson detrás de la máquina host, pero también hace que los aspectos básicos de su purple sean opacos. Los contenedores pueden tener diferentes direcciones IP que sus hosts, ni siquiera residen en la misma subred.

Otro método, llamado puente, es más transparente. En este método, todo actúa como si tuviera una dirección IP en la misma purple, aunque algunas cosas son hosts, otras son contenedores y los contenedores pueden moverse entre hosts, pero la complejidad de la pink subyacente es seen para TI.

Además, muchos contenedores usan redes superpuestas. Esto crea una pink distribuida que se ubica sobre redes específicas de host, lo que permite que los contenedores se comuniquen fácilmente, como si estuvieran uno al lado del otro, mientras que la infraestructura los traslada a diferentes hosts. Es identical a lo que hizo VMware NSX para la infraestructura de virtualización.

La conclusión clave es que la pink de contenedores es muy conectable y personalizable, pero su variabilidad y complejidad hacen que la aplicación de la política de firewall basada en direcciones de crimson sea muy difícil de hacer.

Cortafuegos
Ya no es estático, como lo fue en los años ochenta y noventa. La infraestructura coloca los contenedores de forma dinámica y automática, y si la carga cambia o un host se bloquea, la infraestructura colocará ese contenedor en otro lugar. TI no sabrá qué dirección usar para una regla de firewall hasta que la infraestructura la coloque en algún lugar.

Para que las políticas de firewall basadas en direcciones de crimson funcionen, deben calcularse automáticamente en tiempo genuine, y eso es extremadamente complejo. No estamos cerca de poder hacer esto. Los cambios de infraestructura ocurren en milisegundos, mientras que las políticas pueden tardar horas en cambiar, y eso significa que las políticas de firewall siempre se retrasarán. TI se ve obligado a crear políticas de seguridad excesivamente permisivas para hacer frente a la naturaleza rápidamente cambiante de las direcciones de red dentro de los contenedores.

Movimiento lateral y la complejidad de las políticas de seguridad de red
Digamos que un cibercriminal ha explotado el demonio de shell seguro de un host y quiere acceder a una foundation de datos SQL. Desde la perspectiva de un firewall, todo lo que vería sería un paquete proveniente de ese host, una máquina en la que se le ha dicho que confíe. Permitirá ese paquete, que a su vez permite a los atacantes filtrar datos, cifrarlos o usar el propio SQL para avanzar más en la red hacia su objetivo.

Ahora agreguemos un segundo contenedor al host. En un entorno clásico de Docker, todos los contenedores están traducidos a direcciones de pink para parecerse al host, por lo que es imposible determinar dónde se originó el tráfico. En un escenario de puente, hay varias formas de hacerse pasar por el microservicio de Java dentro del contenedor. Y al igual que con otros complementos de pink, la máquina Linux que actúa como host tiene una gran superficie de ataque de purple. Hay llamadas al sistema, herramientas de administración, sistemas de archivos de propósito especial, protocolos de pink de propósito especial que se comunican con el núcleo en sí cualquiera de estos puede verse comprometido para permitir actividades que la política de firewall nunca tuvo la intención de permitir.

Si el propósito de una política es permitir que este microservicio Java específico se comunique con una foundation de datos SQL, en un modelo de firewall, todo esto debe transformarse en una larga serie de direcciones de crimson, que deben cambiar sobre la marcha a medida que la crimson La infraestructura misma cambia. Pero, ¿qué sucede si, en lugar de traducir estas cargas de trabajo en direcciones, creamos políticas basadas en las identidades de las propias cargas de trabajo?

En este enfoque, a cada carga de trabajo se le asigna una identidad inmutable y única basada en docenas de propiedades del software program, host o dispositivo en sí, como un hash SHA-256 de un binario, el UUID del bios o un hash criptográfico de un guión. De esta manera, no solo podemos separar nuestras políticas de la capa de crimson en constante cambio, sino también garantizar una conectividad segura de extremo a extremo porque sabremos exactamente lo que se está comunicando en ambos lados. Aún mejor, debido a que la identidad se basa en atributos intrínsecos, este método evita que se comuniquen application, dispositivos y hosts falsos o alterados.

Mediante el uso de la identidad, también podemos ir más allá de los firewalls, que han sido diseñados para proteger el perímetro de una red, para permitir un entorno de confianza cero. (Nota del editor: la empresa del autor utiliza un enfoque de confianza cero para la microsegmentación). En este modelo, todo el tráfico de purple se trata como hostil, y solo los hosts, dispositivos o software autorizados pueden comunicarse con cargas de trabajo específicas. Si un computer software o servicio dentro de un contenedor se ve comprometido, los firewalls no evitarán que se mueva lateralmente a través de la red para causar más daño porque dependen de direcciones de purple que son efímeras y cambian rápidamente en entornos de contenedor. En un entorno de confianza cero que se basa en la identidad, podemos evitar que las cargas de trabajo comprometidas se comuniquen porque sus identidades ya no serán reconocidas.

Mediante el uso de políticas basadas en la identidad, los equipos de seguridad finalmente pueden asegurar entornos de autoescalado como contenedores y evitar que las amenazas se muevan lateralmente de un host a otro. Un enfoque basado en la identidad del software (como la confianza cero) debería convertirse en una medida de seguridad estándar para proteger las cargas de trabajo en todas las redes empresariales, ya sea en las instalaciones, en la nube o en contenedores.

Contenido relacionado:

Peter Smith, fundador y CEO de Edgewise, es un emprendedor en serie que construyó e implementó el primer sistema NAC de la Universidad de Harvard antes de que se convirtiera en una categoría de seguridad. Peter trae la perspectiva de un profesional de seguridad a Edgewise con más de diez años de experiencia como … Ver biografía completa

Más concepts





Enlace a la noticia authentic