Seguridad de redes en la era de los contenedores

Una de las cosas buenas de estar en la industria durante muchos años es el hecho de que podemos observar cómo seguridad de red las tendencias en el data center han evolucionado y de alguna manera predicen lo que viene después, en base a patrones e intuición comunes.

Los límites de red y seguridad están cambiando

Hace quince años, la seguridad de la red era bastante simple en el data center. Los protocolos de capa 2 eran reyes absolutos en su ámbito y el firewall podía estar en el borde para proteger Internet o una conexión WAN. Los servidores para una aplicación determinada estaban todos conectados en el mismo rack y el límite entre las diferentes partes de la infraestructura estaba bien definido. Segmentar esto fue bastante sencillo.

Unos años más tarde, para consolidar todos estos servidores y simplificar la conectividad, los servidores chasis y blade ganaron lentamente tracción, creando el primer cambio en los límites de red y seguridad entre las personas que administran servidores y las personas a cargo de la red y la seguridad. ¿Quién es el responsable de los módulos de conectividad en estos chasis y dónde debemos insertar los dispositivos de seguridad? La mayoría de las veces, el módulo de red terminó siendo el módulo menos importante en el chasis y siempre una pesadilla para conectarse al resto de la infraestructura de red y seguridad.

Pero esta batalla fue puesta en escena por una nueva tecnología. ESX de VMware hipervisor rápidamente democratizó la capacidad de compartir el mismo servidor de hardware para ejecutar muchos servidores virtuales. Y como resultado, para conectar estos servidores virtuales juntos, la red tuvo que cambiar una vez más en un lugar diferente: dentro del hipervisor. Shifts comenzó como un switch virtual muy simple, pero rápidamente se expandió a servicios de capa 3 y, finalmente, a la seguridad.

Y nuevamente, a pesar de la evolución de la infraestructura del data center, la nube pública inició su ascensión para ofrecer una gama de servicios al mercado empresarial, totalmente automatizada y extremadamente ágil. Los desarrolladores no tardaron en comprender el valor de esta nueva infraestructura abstracta que puede ofrecer un servicio escalable y de alta disponibilidad sin tener que lidiar con la complejidad de administrar la infraestructura.

Hace unos años, surgió un nuevo tipo de carga de trabajo, ligera, portátil y fácil de girar o desmontar en segundos: contenedores. Con la proliferación de contenedores, los desarrolladores rápidamente se dieron cuenta de que existe la necesidad de orquestar estos recursos de computación, junto con la red, para asegurarse de que las aplicaciones puedan escalar hacia arriba y hacia abajo sin tener que depender de una red externa y una infraestructura de seguridad. Un cluster de contenedores es un nuevo elemento de infraestructura que mezcla computación, red y seguridad y crea, una vez más, otro cambio en el límite de seguridad de la red.

Entonces, ¿qué aprendimos a lo largo de 15 años? ¿Cuál es el patrón común de todas estas evoluciones?

1. El límite de seguridad de la red se está desplazando cada vez más hacia la capa de computación porque los desarrolladores siempre están empujando el límite para obtener más flexibilidad mientras desarrollan y prueban sus aplicaciones.
2. Los equipos de red y seguridad llegan tarde al juego y, en el mejor de los casos, pueden recomendar opciones o soluciones, pero la mayoría de las veces, heredan lo que han decidido las aplicaciones o los equipos de la nube.
3. Asegurar las infraestructuras es más difícil cuando las cosas no se han pensado y diseñado teniendo en cuenta la seguridad y, por lo general, crea un nivel adicional de complejidad cuando se agrega más adelante.

¿Cuál es el problema con los contenedores?

Los contenedores y los clústeres de contenedores en realidad no son una excepción a esta tendencia de mover cada vez más la red hacia las capas de software y computación. Como se describió anteriormente, hemos visto esto durante muchos años, y no hay razón por la que cambiaría si los equipos de red y seguridad no están revirtiendo esta tendencia.

Desde una perspectiva de red y seguridad, los contenedores no introducen nada nuevo o desconocido, simplemente combinan lo que ya sabemos (IPs, subredes, DHCP/DNS, zonas, segmentos, encapsulación, NAT, firewall o balanceadores de carga), pero todo pasa a estar en el propio SO, y ese es un problema fundamental.

A los equipos de TI les encantan los límites, las responsabilidades y la propiedad, y eso es lo contrario de cómo operan los clústeres de contenedores. Han sido diseñados para ser autosuficientes, orquestados y opacos del mundo exterior. Por un lado, es una gran noticia que una nueva pieza de infraestructura no requiera extensas sesiones de diseño para estar conectado y funcionando. Por otro lado, crea una verdadera pregunta de seguridad en cuanto a cómo se pueden asegurar los flujos de aplicaciones si no sabe y comprende lo que sucede dentro de estos clústeres.

¿Qué se puede hacer para cambiar esto?

Idealmente, los desarrolladores deberían desarrollar código y entregarlo a otro equipo para llevar el código a la producción, de una manera completamente probada y automatizada, en una infraestructura diseñada para la escala y la disponibilidad, y con la seguridad en la cima de las prioridades en cada capa de la pila.

Bueno, parece que en muchas organizaciones, aún no hemos llegado a ese punto. Los equipos de DevOps están conectados con sus pares en desarrollo, pero este no siempre es el caso de los equipos de red y seguridad, y eso tiene que cambiar si queremos ver los contenedores como una tecnología disruptiva en el mercado.

Los equipos de red y seguridad deberían dedicar más tiempo a comprender lo que ha sido transportado y protegido por la infraestructura. Deberían aprender qué es un pipeline de CI/CD, y deben tener una opinión sobre cómo se construyen las cosas dentro de la aplicación para que puedan adaptar los mecanismos de seguridad para complementar lo que la aplicación no es capaz de lograr. Esto requiere aprender nuevas habilidades, aceptar las diferencias y ser crítico pero de mente abierta a nuevos conceptos que al principio pueden no parecer una gran idea pero que en realidad pueden ser muy eficientes.

Los contenedores son un ejemplo perfecto de una tecnología que obliga a las personas de todas las áreas de un departamento de TI a aprender unas de otras.

De lo contrario, es una receta para el desastre. No hay cluster de contenedores sin redes, no hay aplicación contenerizada en producción sin seguridad, y no hay infraestructura compartida sin segmentación. Los equipos de redes y seguridad deben aprovechar esta oportunidad para aprender nuevas formas de hacer las cosas, dedicar más tiempo a comprender cómo se pueden hacer las cosas en el software y tomar posesión de las capas de red y seguridad proponiendo diseños simples, seguros y estables para servir a la capa de aplicación.

¿Por dónde deberías empezar?

Obviamente no hay una bala mágica o un arma secreta que pueda ser la respuesta única para todos. Pero aquí hay algunas ideas que pueden ayudar a impulsar a su equipo hacia el éxito:

Conoce a tus amigos: Los desarrolladores y los equipos de DevOps no son los enemigos de los equipos de red y seguridad. Todos están sirviendo al mismo propósito: el negocio. Pero sin saber lo que hacen otros equipos, es más difícil ver qué se puede hacer para ser mejor como grupo. La construcción de infraestructuras complejas como clústeres de contenedores requiere decisiones entrelazadas para tener éxito, especialmente cuando se trata de seguridad.

Adquirir los conocimientos: Nadie lo sabe todo, pero todo el mundo puede aprender cualquier cosa. Está bien ser ligero en algunas áreas de su infraestructura, pero definitivamente no está bien no estar dispuesto a aprender cómo se hacen o se deben hacer las cosas. Los contenedores, las plataformas de orquestación y las mallas de servicio no son fáciles de abordar. Se necesita tiempo para sentirse cómodo con nueva terminología o conceptos, pero es muy gratificante cuando cruzas ese umbral de comprensión y puedes convertir ese conocimiento en acción.

Una red es una red y la seguridad es universal: Tenga en cuenta que un cluster de contenedores es una colección de direcciones IP (asociadas con contenedores) que se comunican entre sí. Además, las aplicaciones no están destinadas a vivir en un clúster de contenedores sin estar expuestas al mundo, por lo que habrá un concepto de abrir algunas puertas al mundo. Los ingenieros de redes y seguridad son responsables de los flujos que van de un extremo a otro de un cluster, así como de obtener paquetes dentro y fuera de este cluster. Si algo se ve comprometido dentro de un cluster de contenedores, es responsabilidad del equipo de seguridad de la red monitorear, reaccionar y responder para evitar la propagación de una brecha. Sí, los clústeres de contenedores tienen un enfoque diferente para la red y la seguridad, pero sigue siendo una red que necesita ser segmentada y protegida.

Busca la verdad: Es importante entender y cuestionar el statu quo. Cuando las cosas no funcionan como pensabas que lo harían, está bien. Esto significa que colectivamente, como equipo, necesitas buscar la verdad y acordar sobre ella. Una tecnología bien entendida es más fácil de implementar, asegurar y solucionar problemas.

Los contenedores, las plataformas de orquestación y las mallas de servicio están ganando mucha tracción en las organizaciones de TI hoy en día y es extremadamente importante que, como ingeniero de redes y seguridad, entienda los conceptos de estas tecnologías. Algunos conceptos sonarán muy familiares, algunos otros sonarán muy extraños, pero para asegurar adecuadamente las cosas, ¡debes saber cómo funcionan realmente!

Echa un vistazo a nuestra página de contenedores para obtener más información sobre cómo aprovechar Illumio para la segmentación de contenedores.