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

La seguridad y las redes han sido durante mucho tiempo una fuente de prioridades conflictivas. 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 data center o arquitectura de nube. Después de todo, las cargas de trabajo, los clientes y las bases de datos no pueden comunicarse entre sí a menos que exista 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 routers y switches intercambian información sobre los conceptos de capa 2 y capa 3, los cuales son en gran medida independientes de 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 aplicaciones están contenidos en ese tráfico.

Entonces, cuando se trata de asegurar 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.

Funciones internas 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 basándose en conceptos que generalmente no dependen de los detalles contenidos en los encabezados de paquetes de red.

A diferencia de las cargas de trabajo tradicionales de tipo bare-metal, las cargas de trabajo modernas se abstraen en gran medida por encima de los recursos subyacentes de la red o del servidor. Se supone que la presencia de una carga de trabajo en cualquier recurso subyacente es transitoria y se puede migrar dinámicamente en vivo a través de hosts, centros de datos y nubes. Estas migraciones generalmente ocurren dinámicamente, sin dirección humana manual. Debido a esta abstracción de las 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 durante la vida 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 cómo se definen los límites de seguridad en las redes modernas.

Segmentación de redes y firewalls tradicionales

Los cambios en las redes son tradicionalmente lentos, por diseño, debido a la naturaleza crítica de las telas de red. Muchas redes de data centers son en gran medida planas, y muchas de las redes de nube pública contienen sólo niveles de segmentación. Cuando las redes se segmentan en cualquier entorno, generalmente se realiza para prioridades específicas de la red, como crear aislamiento en amplias categorías de recursos, como una DMZ, un segmento WAN, un segmento Campus o los segmentos tradicionales Web/App/Dev. Otras razones para segmentar una red son optimizar el performance 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 el ECMP sean más eficientes.

Los segmentos de red se implementan tradicionalmente mediante la creación de VLAN y subredes, ya sea en redes “subyacentes” heredadas 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 routers o switches, ya sea de hardware o virtuales. Además, la implementación de la seguridad en esos segmentos se realiza comúnmente mediante el uso de firewalls de red.

Tradicionalmente, los firewalls ven cualquier segmento como un grupo de rangos IP junto con los puertos de CPC 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 el destino o la dirección IP de origen de un paquete y el puerto como la identidad de una carga de trabajo. Incluso con moderno Firewalls de “próxima generación”, que son capaces de tomar decisiones basadas en datos de aplicaciones contenidos en lo profundo del paquete, la mayoría de las reglas de firewalls todavía se configuran a lo largo de los rangos tradicionales de IP y puertos. Los viejos hábitos mueren duro.

Rompiendo con las tradiciones

La filosofía de 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 operacionales, que pueden ser difíciles de modificar. El resultado es que la seguridad suele ser una idea tardía, ya que simplemente ralentiza los procesos. Por lo general, las cargas de trabajo se implementan de manera rápida y ágil, y la seguridad regresa como prioridad solo después de que se produce una violación y el negocio enfrenta litigios. Nadie quiere ser la persona que le explique al CEO por qué la seguridad no era una prioridad alta y por qué su negocio ahora está siendo demandado.

Amazon expresó este 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 cambiantes de la red son obstáculos para las implementaciones ágiles de cargas de trabajo. Entonces, segmentación de red a menudo no se hace, o se hace de manera muy tosca por equipos de networking.

Pero, ¿qué pasaría si la segmentación y la seguridad de la red pudieran implementarse directamente desde dentro de la carga de trabajo? Se acabó la espera de que las operaciones de red implementen la segmentación en la estructura de red subyacente.

En cambio, ¿y si pudieras ¿implementar los segmentos requeridos 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, ¿y si ¿La seguridad entre estos segmentos podría definirse utilizando políticas de lenguaje natural, en lugar de depender de reglas de firewall IP/puerto obsoletas? No más políticas definidas contra IP de origen y puertos que apuntan a IP y puertos de destino, ya que estos ya no están vinculados a las cargas de trabajo a lo largo de sus ciclos de vida.

En cambio, ¿y si pudieras escribir una política que refleje la forma en que los usuarios perciben los recursos, como “¿Solo los servidores Web desplegados en Nueva York pueden comunicarse con los servidores de bases de datos en Londres?”

¿Y si pudieras definir esto en un enfoque granular, logrando un verdadero enfoque “microsegmentado” Zero Trust, como “Solo Webserver-1 puede hablar con Webserver-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 subes las capas, la política se expresa en un lenguaje más natural, agnóstico a las capas inferiores. La aplicación de políticas de carga de trabajo directamente en las cargas de trabajo libera las capas inferiores para centrarse en las prioridades de la red.

Permitir que las herramientas de capa de carga de trabajo definan la segmentación y el cumplimiento entre cargas de trabajo, de una manera abstraída por encima de la estructura de red subyacente, libera a los equipos de operaciones de red de que los requerimientos de las aplicaciones influyan en el diseño de la red. Al llevar la segmentación y aplicación de las aplicaciones “hasta” la capa de carga de trabajo, los equipos de operaciones de red diseñen las telas de red según las prioridades de la red.

Los firewalls seguirán utilizándose para crear segmentos amplios en toda la estructura, como siempre se ha hecho, pero ya no es necesario crear un número difícil de VLAN o subredes para adaptarse a los requerimientos de segmentación de aplicaciones. En su lugar, los arquitectos de red pueden centrarse en las prioridades de la red al diseñar segmentación de red, como rendimiento, redundancia, resumen de rutas, árbol de extensión y ECMP. La segmentación de aplicaciones ya no necesita agregar dolores de cabeza al diseño de redes. El hecho de 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 línea cuando se busca una causa al solucionar problemas de seguridad.

Segmentación moderna para cargas de trabajo modernas

Illumino's Plataforma de Seguridad Adaptativa (ASP) permite la microsegmentación entre cargas de trabajo, esencial para construir un verdadero Arquitectura Zero Trust, y utiliza expresiones de lenguaje natural para definir políticas entre esas cargas de trabajo. Te da un mapa de dependencia de aplicaciones que proporciona una imagen clara de exactamente qué cargas de trabajo se comunican entre sí y quién está iniciando conexiones con quién, en toda su estructura de nube híbrida. Y aunque tiene una visibilidad completa del direccionamiento IP utilizado por las cargas de trabajo, la política no se define, ni debe, definirse contra el direccionamiento IP, ya que la asociación entre el direccionamiento de red y las aplicaciones es transitoria.

Illumio utiliza etiquetas para identificar las cargas de trabajo en función de criterios abstraídos por encima de cualquier segmento de los segmentos de red de nube híbrida subyacentes en los que están alojados:

• Estas etiquetas incluyen metadatos asociados con cargas de trabajo, independientemente de su direccionamiento IP actual.
• Las etiquetas son Rol, Aplicación, Entorno y Ubicación (“RAEL”).
• Se utilizan 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 Web pueden comunicarse con las cargas de trabajo de la aplicación, pero solo las cargas de trabajo de App pueden comunicarse con las cargas de trabajo de la base de datos. La política no es específica para el direccionamiento IP.
• Luego, Illumino traduce estas reglas de políticas basadas en etiquetas en configuraciones específicas para las capacidades de filtrado de red de cualquier sistema operativo que esté ejecutando actualmente esas cargas de trabajo, ya sea iptables e ipsets de Linux, Windows Filtering Platform (WFP) o la tabla de estado IPFilter para las cargas de trabajo Solaris y AIX.

Dado que Illumio le permite definir políticas de una manera totalmente abstracta por encima de cómo y dónde se aloja una carga de trabajo, el resultado es que las prioridades de networking y las prioridades de aplicaciones ya no están en conflicto.

Resumiendo

En las arquitecturas de red de nube híbrida y centros de datos modernos, el perímetro se define simplemente como donde se aloja actualmente su carga de trabajo, y esa carga de trabajo puede moverse dinámicamente a través de cualquier segmento de la nube. La definición heredada del perímetro como que se encuentra 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 las aplicaciones es difícil de escalar. Las soluciones SDN que utilizan controladores y redes superpuestos que terminan en hipervisores mueven de manera efectiva el límite entre la red y las cargas de trabajo hacia el host, pero aún dependen de definir segmentos de “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 modernas telas de nube es ir a la carga de trabajo para crear microsegmentos y hacer cumplir políticas que sean relevantes para las cargas de trabajo, liberando así la segmentación de la red para ser definida a lo largo de prioridades que son relevantes para el diseño de la red. La red ya no es el obstáculo para carga de trabajo de aplicaciones agilidad y seguridad. Y la red ya no es la primera en la línea cuando seguridad de aplicaciones se produce la solución de problemas, lo que reduce la necesidad de señalar con el dedo durante las respuestas a incidentes.

Echa un vistazo a esto vídeo para un viaje rápido que desglose la evolución de la segmentación y conozca más sobre nuestra solución aquí.