No permita que su red sea un obstáculo para la segmentación de la carga de trabajo

La seguridad y la creación de redes fueron durante mucho tiempo una fuente de prioridades contradictorias. Al diseñar un centro de datos tradicional o una estructura de nube híbrida, la prioridad de la arquitectura de red es la entrega confiable y resistente del tráfico. La red es, quizás, el recurso más crítico en cualquier centro de datos o arquitectura en la nube. Luego de todo, las cargas de trabajo, los clientes y las bases de datos no pueden comunicar entre sí a menos que haya una red entre ellos. Y todas las redes operan tomando decisiones de reenvío basadas en el análisis de los encabezados de los paquetes y varias otras métricas. Además, los enrutadores y conmutadores intercambian información sobre los conceptos de capa 2 y capa 3, los cuales son en gran medida agnósticos a los detalles específicos de la aplicación contenidos en la carga útil de datos de los paquetes. Las redes se centran principalmente en mover el tráfico de manera confiable y rápida, en lugar de en qué datos de aplicación están contenidos en ese tráfico.

Entonces, cuando se trata de proteger esas aplicaciones, y sus cargas de trabajo, ¿por qué seguimos considerando enfoques que están vinculados a la red? Exploremos cómo evolucionar su enfoque para que la red ya no sea un obstáculo para la entrega ágil de cargas de trabajo, la automatización y la seguridad.

Funcionamiento interno de las cargas de trabajo modernas

Las cargas de trabajo, que se comunican a través de cualquier red, están diseñadas para hacerlo en función de las prioridades específicas de la aplicación. Lo que está haciendo una carga de trabajo es más importante que el aspecto de la estructura de red subyacente. Los clientes se comunican con las cargas de trabajo y las cargas de trabajo se comunican con las bases de datos en función de conceptos que normalmente no dependen de los detalles contenidos en los encabezados de los paquetes de red.

A diferencia de las cargas de trabajo tradicionales sin sistema operativo, las cargas de trabajo modernas se abstraen en gran medida por encima de los recursos de red o servidor subyacentes. Se supone que la presencia de una carga de trabajo en cualquier recurso subyacente es transitoria y se puede migrar dinámicamente en tiempo real entre hosts, centros de datos y nubes. Estas migraciones generalmente ocurren dinámicamente, sin dirección humana manual. Debido a esta abstracción de cargas de trabajo por encima de los recursos subyacentes, ya no es realista considerar la dirección IP de una carga de trabajo como una forma útil de identidad para la vida útil de esa carga de trabajo. Una carga de trabajo puede tener muchas direcciones IP diferentes a lo largo de su ciclo de vida, y esto afecta directamente a la forma en que se definen los límites de seguridad en las redes modernas.

Segmentación de red tradicional y firewalls

Los cambios en las redes son tradicionalmente lentos, por diseño, debido a la naturaleza crítica de las estructuras de red. Muchas redes de centros de datos son en gran medida planas, y muchas estructuras de red de nube pública contienen solo niveles aproximados de segmentación. Cuando las redes se segmentan en cualquier entorno, generalmente se hace para prioridades específicas de la red, como crear aislamiento en amplias categorías de recursos, como una DMZ, un segmento WAN, un segmento de campus o los segmentos tradicionales de sitio web/aplicación/desarrollo. Otras razones para segmentar una red son optimizar el rendimiento de la red, aumentar el rendimiento, implementar redundancia de rutas o hacer que tareas como el resumen de rutas, el árbol de expansión y ECMP sean más eficientes.

Los segmentos de red se implementan tradicionalmente mediante la creación de VLAN y subredes, ya sea en redes heredadas de "subyacente" o en redes "superpuestas", implementadas mediante controladores SDN y tunelización como VXLAN. Independientemente de si la topología es subyacente o superpuesta, todos estos segmentos de red terminan en enrutadores o conmutadores, ya sean de hardware o virtuales. Y la implementación de seguridad en esos segmentos se realiza comúnmente mediante el uso de firewalls de red.

Los firewalls tradicionalmente ven cualquier segmento como un grupo de rangos de IP junto con puertos TCP/UDP asociados o como zonas, que son una colección de segmentos, junto con los puertos que se bloquean o permiten entre rangos de IP relevantes. Los firewalls de red no implementan seguridad basada en el contenido específico de la aplicación de la carga útil de datos de un paquete. Los firewalls consideran la dirección IP y el puerto de destino u origen de un paquete como la identidad de una carga de trabajo. Incluso con los firewalls modernos de"próxima generación",que son capaces de tomar decisiones basadas en los datos de la aplicación contenidos en lo profundo del paquete, la mayoría de las reglas de los firewalls todavía están configuradas a lo largo de los rangos tradicionales de IP y puertos. Los viejos hábitos tardan en morir.

Rompiendo con las tradiciones

La filosofía DevOps pone un fuerte énfasis en la velocidad de implementación y en la automatización. Y, como se mencionó, los cambios en los segmentos de red y los firewalls suelen ser lentos y manuales. La automatización de los cambios en las redes y la seguridad a menudo se encuentra con barreras operativas, que pueden ser difíciles de modificar. El resultado es que la seguridad es a menudo una ocurrencia tardía, ya que simplemente ralentiza los procesos. Por lo general, las cargas de trabajo se implementan de forma rápida y ágil, y la seguridad vuelve a ser una prioridad solo después de que se produce una infracción y la compañía se enfrenta a un litigio. Nadie quiere ser la persona que le explique al CEO por qué la seguridad no era una alta prioridad y por qué su negocio ahora está siendo demandado.

Amazon expresó este famoso conflicto de prioridades entre la agilidad de la carga de trabajo y los cambios en la red en 2012 diciendo: "La red está en mi camino". La red y los segmentos de red cambiantes son obstáculos para las implementaciones ágiles de cargas de trabajo. Por lo tanto, la segmentación de la red a menudo no se realiza, o se realiza de manera muy burda por parte de los equipos de redes.

Pero, ¿qué pasaría si la segmentación y la seguridad de la red pudieran implementar directamente desde la carga de trabajo? Ya no tendrá que esperar a que las operaciones de red implementen la segmentación en la estructura de red subyacente.

En su lugar, ¿qué pasaría si pudiera implementar los segmentos necesarios directamente desde el mismo proceso ágil que la implementación de una carga de trabajo a través del proceso DevOps?

Y, lo que es más importante, ¿qué pasaría si la seguridad entre estos segmentos pudiera definir empleando una política de lenguaje natural, en lugar de depender de reglas de firewall de IP/puerto obsoletas? Ya no se definieron directivas contra la IP de origen y los puertos que apuntan a la IP y los puertos de destino, ya que ya no están vinculados a las cargas de trabajo a lo largo de sus ciclos de vida.

En su lugar, ¿qué pasaría si pudiera escribir una directiva que refleje la forma en que los usuarios perciben los recursos, como "Solo los servidores sitio web implementados en Nueva York pueden comunicar con los servidores de bases de datos en Londres?"

¿Y si pudiera definir esto en un enfoque granular, logrando un verdadero enfoque de Zero Trust "microsegmentado", como "Solo el servidor sitio web-1 puede hablar con el servidor sitio web-2 dentro de la misma ubicación"?

Hay cuatro capas amplias en una arquitectura de red donde se puede aplicar la política, como se ilustra en este diagrama:

A medida que asciende en las capas, la política se expresa en un lenguaje más natural, independiente de las capas inferiores. La aplicación de la política de carga de trabajo directamente en las cargas de trabajo libera a las capas inferiores para centrar en las prioridades de la red.

Permitir que las herramientas de capa de carga de trabajo definan la segmentación y la aplicación entre cargas de trabajo, de una manera que se abstraiga por encima de la estructura de red subyacente, libera a los equipos de operaciones de red de que los requisitos de la aplicación influyan en el diseño de la red. Llevar la segmentación y el cumplimiento de aplicaciones "arriba" a la capa de carga de trabajo permite a los equipos de operaciones de red diseñar estructuras de red a lo largo de las prioridades de la red.

Los firewalls se seguirán empleando para crear segmentos amplios en toda la estructura, como siempre se hizo, pero ya no es necesario crear un número difícil de manejar de VLAN o subredes para adaptar a los requisitos de segmentación de aplicaciones. En cambio, los arquitectos de red pueden centrar en las prioridades de la red al diseñar la segmentación de la red, como el rendimiento, la redundancia, el resumen de rutas, el árbol de expansión y ECMP. La segmentación de aplicaciones ya no necesita agregar dolores de cabeza al diseño de la red. Hacer que las cargas de trabajo creen y apliquen límites de segmentación también libera a la red de ser la primera en la fila cuando se buscan causas al solucionar problemas de seguridad.

Segmentación moderna para cargas de trabajo modernas

La plataforma de seguridad adaptativa (ASP) de Illumio permite la microsegmentación entre cargas de trabajo, esencial para crear una verdadera arquitectura de confianza cero, y emplea expresiones de lenguaje natural para definir políticas entre esas cargas de trabajo. Le proporciona un mapa de dependencias de aplicaciones que proporciona una imagen clara de exactamente qué cargas de trabajo se comunican entre sí y quién inicia conexiones con quién, en toda su estructura de nube híbrida. Y aunque tiene visibilidad completa del direccionamiento IP empleado por las cargas de trabajo, la política no se define (y no debe) con respecto al direccionamiento IP, ya que la asociación entre el direccionamiento de red y las aplicaciones es transitoria.

Illumio emplea etiquetas para identificar las cargas de trabajo en función de criterios que se abstraen sobre cualquier segmento de los segmentos de red de nube híbrida subyacentes en los que estén alojados:

• Estas etiquetas incluyen metadatos asociados a cargas de trabajo, independientemente de su dirección IP actual.
• Las etiquetas son Rol, Aplicación, Entorno y Ubicación ("RAEL").
• Se usan para definir segmentos entre cargas de trabajo y la aplicación entre estas cargas de trabajo etiquetadas se define mediante expresiones de lenguaje natural, como las cargas de trabajo sitio web pueden comunicar con las cargas de trabajo de la aplicación, pero solo las cargas de trabajo de la aplicación pueden comunicar con las cargas de trabajo de la base de datos. La política no es específica del direccionamiento IP.
• A continuación, Illumio traduce estas reglas de directiva basadas en etiquetas en configuraciones específicas para las capacidades de filtrado de red de cualquier sistema operativo que ejecute actualmente esas cargas de trabajo, ya sean iptables e ipsets de Linux, la plataforma de filtrado de Windows (WFP) o la tabla de estado IPFilter para cargas de trabajo de Solaris y AIX.

Dado que Illumio le permite definir la política de una manera totalmente abstracta sobre cómo y dónde se aloja una carga de trabajo, el resultado es que las prioridades de red y las prioridades de la aplicación ya no están en conflicto.

Resumiendo

En las arquitecturas modernas de red de nube híbrida y centro de datos, el perímetro se define simplemente como cualquier lugar donde se aloje actualmente su carga de trabajo, y esa carga de trabajo puede mover dinámicamente a través de cualquier segmento de la nube. La definición heredada del perímetro como algo entre el centro de datos e Internet ya no es relevante, y tratar de diseñar la estructura de red para permitir la microsegmentación a través de los límites de la aplicación es difícil de escalar. Las soluciones SDN que emplean controladores y redes superpuestas que terminan en hipervisores mueven efectivamente el límite entre la red y las cargas de trabajo hacia el host, pero aún se basan en la definición de segmentos desde "abajo hacia arriba": desde la capa de red para resolver un problema en la capa de carga de trabajo.

Un enfoque mucho más escalable en las estructuras de nube modernas es ir a la carga de trabajo para crear microsegmentos y aplicar políticas que sean relevantes para las cargas de trabajo, liberando así la segmentación de la red para que se defina a lo largo de las prioridades que son relevantes para el diseño de la red. La red ya no es el obstáculo para la agilidad y la seguridad de la carga de trabajo de las aplicaciones . Y la red ya no es la primera en la fila cuando se produce la resolución de problemas de seguridad de las aplicaciones , lo que reduce las acusaciones durante las respuestas a incidentes.

Vea este video para un viaje rápido que desglosa la evolución de la segmentación y obtenga más información sobre nuestra solución aquí.