Mejores prácticas para la segmentación de la carga de trabajo: ¿Lean y optimizada o pesada y compleja?

La "ciberseguridad" cubre una amplia gama de temas, algunos de los cuales incluyen prioridades de red, prioridades de host, autenticación, identidad, automatización, cumplimiento y más. La microsegmentación es una pieza de este principio más amplio, pero muchos todavía creen que es un desafío implementarla 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 gran escala 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 práctica. 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 se 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 red a menudo se implementa por razones diferentes a las que se requieren de la segmentación de la carga de trabajo.

Dos requisitos 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. La automatización significa eliminar el elemento humano tanto como sea posible, ya que cuanto más se involucre un humano en el proceso operativo, más probable es que ocurran errores de configuración y errores. Y admitir arquitecturas a gran escala significa habilitar la automatización de la segmentación de tal manera que se eviten obstáculos en la arquitectura general luego de alcanzar cierta escala.

Estos requisitos se pueden implementar 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 de la microsegmentación

Primero analicemos 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 en la implementación de políticas de segmentación a escala. La puesta en práctica de tales herramientas es bastante compleja y, por lo tanto, puede describir como un enfoque "pesado" para implementar la microsegmentación.

Por el contrario, los enfoques "ligeros", como Illumio, fueron diseñados específicamente para la microsegmentación. No nacieron como un producto y luego se modificaron en un producto diferente. Se centran exclusivamente en la segmentación en la capa de carga de trabajo y son deliberadamente agnósticos a 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, lo que requiere poca o ninguna intervención humana.

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

Es una perogrullada, pero vale la pena repetirla: cuanto más compleja sea la solución, antes alcanzará un límite superior operativo. En algún momento, una solución compleja incurrirá en un obstáculo eventual para determinar hasta dónde 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 crezcan, eventualmente lastrarán los gastos generales operativos y alcanzarán un límite estricto. En ese momento, las cargas de trabajo adicionales a menudo quedan desprotegidas y la automatización comienza a fallar. A medida que la solución realiza más tareas, la complejidad eventualmente se convierte en una carga operativa.

Los proveedores de microsegmentación publican con frecuencia números que reflejan su límite superior de cargas de trabajo gestionadas, y estos números parecen ser lo suficientemente grandes como para adaptar 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 tradicionales sin sistema operativo. 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 gestionadas no debe estar determinado por las herramientas empleadas para poner en práctica 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 romper luego 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 de los administradores. A medida que los ciclos de vida de las cargas 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, emplea el concepto de etiquetas de cuatro dimensiones y delimitación de aplicaciones para simplificar y automatizar el proceso de aplicación de segmentación a una carga de trabajo en el momento de su creación. 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 un error inadvertidamente.

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

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

Introduzca microservicios, espere 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 gestionar. Con la llegada de la virtualización, un solo host sin sistema operativo podría gestionar muchas máquinas virtuales, cada una con su propia dirección IP. Y ahora, con la llegada de los microservicios, cada una de estas máquinas virtuales puede alojar muchas construcciones en contenedores, lo que da como resultado aún más direcciones IP.

Si cada entidad de 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 se dispare. La gran cantidad de cargas de trabajo que deben monitorear requiere una solución que pueda escalar a números muy grandes.

La visualización es primordial

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

Las soluciones pesadas, como Tetration, pueden aplicar 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 sin sistema operativo 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, crea su mapa de dependencias de aplicaciones.

Visualizar todo el tráfico y el comportamiento de las aplicaciones, independientemente de cómo estén alojadas, es esencial a medida que sus cargas de trabajo evolucionan a través de la nube híbrida y diferentes recursos informáticos, tanto en centros de datos locales como en estructuras 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 aplicar una política declarativa legible por humanos.

La conclusión

Al decidir cómo implementar la segmentación de la carga 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 a veces es una mejor opción que implementar un acorazado si el objetivo es la velocidad y la agilidad en el agua, lo mismo se aplica a cómo se implementa la microsegmentación en las nubes híbridas modernas y las estructuras informáticas. Reduzca la complejidad y mantenga la solución "liviana", no "pesada".