Mejores prácticas para la segmentación de cargas de trabajo: ¿Lean y optimizadas o pesadas y complejas?

'Ciberseguridad' cubre una amplia gama de temas, algunos de los cuales incluyen prioridades de red, prioridades de host, autenticación, identidad, automatización, cumplimiento de normas y más. Micro-segmentación es una parte de este principio más amplio, pero muchos todavía creen que es un desafío implementarlo a escala.

Todas las cargas de trabajo modernas contienen un firewall integrado y un filtro de puertos, como iptables en Linux. Configurar esto en cargas de trabajo individuales es relativamente sencillo, pero hacerlo a grandes escalas suele ser un desafío. Y hacerlo en la migración en evolución de cargas de trabajo monolíticas a microservicios hace que ese desafío sea aún más difícil de poner en marcha. El resultado es que la segmentación en la capa de carga de trabajo de la arquitectura con frecuencia no se realiza, sino que simplemente deja esta tarea a la estructura de red subyacente para que la implemente. Este enfoque crea un conflicto en las prioridades, ya que la segmentación de la red a menudo se implementa por razones diferentes a las que se requiere de la segmentación de la carga de trabajo.

Dos requerimientos clave para la segmentación en la capa de carga de trabajo tanto en la nube híbrida como en las arquitecturas de microservicios son la automatización y el soporte de arquitecturas a gran escala. Automatización significa eliminar el elemento humano tanto como sea posible, ya que cuanto más un humano esté involucrado en el proceso operativo, más probable es que se produzcan errores y configuraciones erróneas. Y soportar arquitecturas a gran escala significa permitir la automatización de la segmentación de tal manera que se eviten obstáculos en la arquitectura general después de alcanzar cierta escala.

Estos requerimientos pueden implementarse de una de dos maneras: un enfoque “pesado” o un enfoque “ligero”. Comparemos estos dos enfoques para ver cuál tiene más sentido para usted y su organización.

Una historia de dos enfoques para la microsegmentación

Analicemos primero lo que consideramos un enfoque “pesado”. Los enfoques más pesados, como Cisco Tetration, por ejemplo, se centran en capturar cada paquete de cada carga de trabajo, realizar análisis de red en toda la estructura de la red y requerir una cantidad significativa de intervención humana para implementar políticas de segmentación a escala. Operacionalizar tales herramientas es bastante complejo y, por lo tanto, puede describirse como un enfoque “pesado” para implementar la microsegmentación.

En contraste, los enfoques “ligeros”, como Illumio, fueron diseñado específicamente para la microsegmentación. No nacieron como un solo producto y posteriormente se modificaron en un producto diferente. Se enfocan exclusivamente en la segmentación en la capa de carga de trabajo y son deliberadamente agnósticos de cómo se implementa la red subyacente, dejando la tarea de análisis de red a las herramientas de red. Con este enfoque se agiliza la implementación de la política de segmentación, con énfasis en la automatización, requiriendo poca o ninguna intervención humana.

¿Cuándo la segmentación romperá mi arquitectura?

Es un truismo, pero es necesario repetirlo: cuanto más compleja sea la solución, más pronto alcanzará un límite superior operativo. En algún momento, una solución compleja incurrirá en un posible obstáculo para determinar hasta qué punto puede escalar la arquitectura general de segmentación de la carga de trabajo.

Las soluciones más pesadas y complejas para la microsegmentación funcionarán en casos de uso más pequeños, pero a medida que esos casos de uso crecen, eventualmente pesarán la sobrecarga operativa y alcanzarán un límite difícil. En ese momento, las cargas de trabajo adicionales a menudo quedan desprotegidas y la automatización comienza a romperse. A medida que la solución realiza más tareas, la complejidad eventualmente se convierte en una carga operacional.

Los proveedores de microsegmentación frecuentemente publican números que reflejan su límite superior de cargas de trabajo administradas, y estos números parecen ser lo suficientemente grandes como para adaptarse al crecimiento esperado. Pero a medida que más organizaciones adoptan arquitecturas de nube híbrida, la virtualización crea muchas más cargas de trabajo que en el caso de los hosts bare-metal tradicionales. Y las arquitecturas de microservicios crean un número adicional significativo de entidades direccionables por IP dentro de un host, lo que hace que el número total de cargas de trabajo aumente rápidamente. El número de cargas de trabajo administradas no debe determinarse mediante las herramientas utilizadas para operacionalizar la segmentación. Para garantizar un ciclo de crecimiento ininterrumpido de la carga de trabajo, nunca asuma que un número menor será suficiente.

Para automatizar la microsegmentación en cualquier arquitectura de nube híbrida en evolución, la solución no debe descomponerse después de alcanzar un número superior.

Automatización ≠ Humanos

La automatización requiere una arquitectura ágil y optimizada. Un gran porcentaje de las brechas de seguridad en cualquier entorno de nube se deben a errores honestos por parte de los administradores. A medida que los ciclos de vida de la carga de trabajo se vuelven más dinámicos y el lugar donde residen en los segmentos de red se vuelve cada vez más efímero, es más crítico automatizar los procesos de seguridad y eliminar el riesgo significativo introducido por la intervención humana en el proceso operativo.

Illumio, como ejemplo de un enfoque ligero, utiliza el concepto de etiquetas de cuatro dimensiones y el ringfencing de aplicaciones para simplificar y automatizar el proceso de aplicación de segmentación a una carga de trabajo en el momento de su inicio. Permite sugerir límites de segmentación automáticamente o permitir que el administrador defina estos límites. Esto reduce significativamente el riesgo de que la intervención humana pueda introducir inadvertidamente un error.

La mayoría de las soluciones pesadas, como Tetration, incluyen opciones para aplicar etiquetas a las cargas de trabajo con el fin de rastrearlas independientemente del direccionamiento IP. Dicho esto, el proceso es “pesado”, complejo y requiere una cantidad significativa de interacción humana inicial y experiencia para operacionalizar. Y como puede adivinar, cuanto más requiere un proceso de intervención y experiencia humana, mayor es el riesgo de error involuntario.

Cuando planifica la segmentación de la carga de trabajo automatizada, tenga en cuenta esta regla: cuanto más complejo sea el proceso, mayor será el riesgo.

Introducir microservicios, esperar más cargas de trabajo

La migración del desarrollo de aplicaciones de cargas de trabajo monolíticas a microservicios introduce el efecto de aumentar significativamente el número de cargas de trabajo que deben administrarse. Con la llegada de la virtualización, un único host bare-metal podría administrar muchas máquinas virtuales, cada una con su propia dirección IP. Y ahora, con la llegada de los microservicios, cada una de estas VM puede alojar muchas construcciones en contenedores, lo que resulta en aún más direcciones IP.

Si cada entidad en una red con una dirección IP se define como una carga de trabajo, un entorno de microservicios puede hacer que el número de cargas de trabajo explote. La gran cantidad de cargas de trabajo que necesitan ser monitoreadas requiere una solución que pueda escala a números muy grandes.

La visualización es primordial

Monitorear una carga de trabajo significa dos cosas básicas: aplicar políticas y visualización. Pero, ¿cómo visualiza lo que las aplicaciones se están haciendo entre sí a través de una gran cantidad de cargas de trabajo? La visualización de la comunicación de la carga de trabajo no puede depender de segmentación de red. En el caso de los microservicios, la necesidad de visualización se extiende más allá del tráfico de VM a VM y debe incluir la comunicación entre pods, nodos y servicios cuando se utiliza Kubernetes u OpenShift para orquestar los ciclos de vida de los contenedores.

Las soluciones pesadas, como Tetration, pueden imponer políticas dentro de un entorno en contenedores, pero la visualización del tráfico de aplicaciones dentro de estas construcciones es limitada. Estas soluciones a menudo pueden crear un mapa visual del tráfico entre hosts, pero la vista se detiene allí y falta el tráfico entre construcciones en contenedores dentro de un host. Por otro lado, una solución ligera amplía la visibilidad desde los hosts de metal puro hasta las máquinas virtuales y todas las construcciones en contenedores dentro de cualquier host. Todas las cargas de trabajo, ya sean monolíticas o en contenedores, son completamente visibles cuando Illumio, por ejemplo, construye su mapa de dependencia de aplicaciones.

Visualizar todo el tráfico y el comportamiento de las aplicaciones, independientemente de cómo se alojen, es esencial a medida que sus cargas de trabajo evolucionan a través de la nube híbrida y diferentes recursos de cómputo, tanto en centros de datos locales como en entornos de nube pública. La visualización se vuelve más importante a medida que estos detalles se vuelven más complejos y dinámicos, con el fin de crear y hacer cumplir política declarativa legible por el ser humano.

El resultado final

Al decidir cómo implementar la segmentación de cargas de trabajo a escala y de manera automatizada, un enfoque ágil y optimizado es la única opción viable. De manera similar a cómo implementar una lancha rápida es a veces una mejor opción que desplegar un acorazado si el objetivo es la velocidad y la agilidad en el agua, lo mismo se aplica a la forma en que se implementa la microsegmentación en las nubes híbridas modernas y las estructuras de cómputo. Reduzca la complejidad y mantenga la solución “ligera”, no “pesada”.