Seguridad de red 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 evolucionaron las tendencias de seguridad de red en el centro de datos y predecir de alguna manera lo que viene después, en función de patrones comunes e intuición.

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

Hace quince años, la seguridad de la red era bastante simple en el centro de datos. Los protocolos de capa 2 eran los reyes absolutos en su reino y el firewall podía ubicar en el borde para proteger Internet o una conexión WAN. Los servidores para una aplicación determinada estaban todos conectados en el mismo bastidor y el límite entre las diferentes piezas 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 chasis y los servidores blade ganaron terreno lentamente, creando el primer cambio en los límites de red y seguridad entre las personas que gestionan los servidores y las personas a cargo de la red y la seguridad. ¿Quién es 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 terminaba siendo el módulo menos importante del chasis y siempre una pesadilla para conectarse al resto de la infraestructura de red y seguridad.

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

Y nuevamente, a pesar de la evolución de la infraestructura del centro de datos, la nube pública comenzó su ascenso para ofrecer una gama de servicios al mercado empresarial, totalmente automatizados y extremadamente ágiles. Los desarrolladores no tardaron mucho 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 gestionar la infraestructura.

Hace unos años, surgió un nuevo tipo de carga de trabajo, liviana, portátil y fácil de voltear o desmontar en segundos: los contenedores. Con la proliferación de contenedores, los desarrolladores se dieron cuenta rápidamente de que existe la necesidad de orquestar estos recursos informáticos, junto con la red, para cerciorar 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 clúster de contenedores es un nuevo elemento de infraestructura que mezcla la computación, la red y la seguridad y crea, una vez más, otro cambio en el límite de seguridad de la red.

Entonces, ¿qué aprendimos durante 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 cálculo porque los desarrolladores siempre están empujando el límite para obtener más flexibilidad al desarrollar y probar 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 decidieron las aplicaciones o los equipos en la nube.
3. Cerciorar las infraestructuras es más difícil cuando las cosas no se pensaron 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 la red cada vez más hacia las capas de software y cálculo. Como se describió anteriormente, vimos esto durante muchos años, y no hay ninguna razón por la que cambiaría si los equipos de red y seguridad no están revirtiendo esta tendencia.

Desde el punto de vista de la red y la seguridad, los contenedores no introducen nada nuevo o desconocido, simplemente combinan lo que ya conocemos (IPs, subredes, DHCP/DNS, zonas, segmentos, encapsulación, NAT, firewall o balanceadores de carga), pero todo pasa a estar en el propio sistema operativo, 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 opuesto a cómo funcionan los clústeres de contenedores. Fueron 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 conectarse y ejecutar. Por otro lado, crea una pregunta de seguridad real sobre cómo se pueden proteger los flujos de aplicaciones si no sabe y comprende lo que está sucediendo 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 que lo ponga en 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 parte superior de las prioridades en cada capa de la pila.

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

Los equipos de red y seguridad deben dedicar más tiempo a comprender lo que transportó y protegido la infraestructura. Deben aprender qué es una canalización 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 puede 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 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 clúster de contenedores sin redes, no hay aplicación en contenedores en producción sin seguridad y no hay infraestructura compartida sin segmentación. Los equipos de red 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 apropiar 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 existe 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 colegas-enemigos: Los desarrolladores y los equipos de DevOps no son enemigos de los equipos de red y seguridad. Todos tienen el 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 creación de infraestructuras complejas como los 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 deberían hacer las cosas. Los contenedores, las plataformas de orquestación y las mallas de servicios no son fáciles de abordar. Se necesita tiempo para sentir cómodo con la 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 clúster de contenedores es una colección de direcciones IP (asociadas a 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 red y seguridad son responsables de los flujos que van de un extremo a otro de un clúster, así como de obtener paquetes dentro y fuera de este clúster. Si algo se ve comprometido dentro de un clúster de contenedores, es responsabilidad del equipo de seguridad de red monitorear, reaccionar y responder para evitar la propagación de una infracción. Sí, los clústeres de contenedores tienen un enfoque diferente para la red y la seguridad, pero sigue siendo una red que debe segmentar y proteger.  

Busca la verdad: Es importante comprender y desafiar el statu quo. Cuando las cosas no funcionan como pensabas, está bien. Esto significa que colectivamente, como equipo, deben buscar la verdad y poner de acuerdo sobre ella. Una tecnología bien entendida es más fácil de implementar, proteger y solucionar problemas.  

Los contenedores, las plataformas de orquestación y las mallas de servicios 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, comprenda los conceptos de estas tecnologías. Algunos conceptos sonarán muy familiares, otros sonarán muy extraños, pero para cerciorar adecuadamente las cosas, ¡debes saber cómo funcionan realmente!  

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