La seguridad de la red no es seguridad de carga de trabajo

Las brechas, los hackeos, el secuestro, la pérdida de datos y la exfiltración son todos problemas que existen en la mayoría de las arquitecturas de nube por una razón muy simple: la mayor parte de la tecnología de TI no se diseñó originalmente con la seguridad como prioridad. Las complejidades en torno al desarrollo de aplicaciones, los sistemas operativos de carga de trabajo, los protocolos de red y la administración general de procesos se diseñaron con diferentes prioridades en mente: funcionalidad y resiliencia. Todas estas tareas necesitan funcionar y deben sobrevivir a fallas de elementos en la arquitectura general, pero asegurando estos elementos generalmente han sido una idea tardía.

Dado que la red es la infraestructura crítica en la arquitectura general, parecería tener sentido aplicar allí soluciones de seguridad y microsegmentación.

Independientemente de cómo se desarrollen las aplicaciones, cómo se construyen e implementan los diferentes sistemas operativos y cómo se virtualiza, abstrae y administra todo esto, la mayoría de estos elementos necesitan comunicarse entre sí. Si no hay red, cada aplicación es una isla. Y la mayoría de las aplicaciones actuales están diseñadas para ser accedidas por clientes remotos, ya sea a través de una red privada o a través de Internet. Esto se requiere en cualquier tipo de arquitectura de nube, y cualquier arquitectura nativa de la nube simplemente no funcionará sin una red ya existente para comunicarse a través de ella. Entonces, se puede argumentar que el elemento más crítico de cualquier arquitectura general de nube es en realidad la propia red.

Debido a la naturaleza crítica de la infraestructura de red en cualquier arquitectura de nube, existen desafíos y prioridades que son específicos solo para la capa de red de todas las arquitecturas. La red tiene preocupaciones que son completamente agnósticas a las cargas de trabajo y las aplicaciones, que dependen de la red. Algunos ejemplos de estas preocupaciones de la red incluyen:

• Confiabilidad (la red necesita funcionar)
• Resiliencia (la falla de uno o más dispositivos de red no debería causar una falla en todo el sistema)
• Ingeniería de tráfico y calidad de servicio (las redes IP son, por diseño, “sin conexión”, pero debería haber formas de diseñar y priorizar diferentes tipos de tráfico)
• Escalado (las redes deberían poder evolucionar sin alcanzar algún límite de recursos)

Las aplicaciones y las cargas de trabajo no deben tener conocimiento de ninguno de estos detalles para que puedan usar la red.

Entonces, ¿qué significa esto para asegurar la red y asegurar las cargas de trabajo? Hay distintas consideraciones que exploraré, específicamente el contraste entre seguridad de red y soluciones basadas en red y seguridad de cargas de trabajo y soluciones como la microsegmentación.

Breve historia de la seguridad de la red

Dado que la seguridad siempre es la última en llegar a la mayoría de las arquitecturas de nube, la seguridad y segmentación de red tradicionalmente se han implementado en la capa de red. Dado que la red es la infraestructura crítica en la arquitectura general, parecería tener sentido aplicar allí soluciones de seguridad y microsegmentación.

Si hace retroceder el reloj varias décadas, la seguridad en las redes IP originalmente tomó la forma de listas de control de acceso (“ACL”) en routers y switches. Los dispositivos de red generalmente manejan el tráfico por paquete, por lo que a medida que los paquetes llegan a un router o switch, estas ACL se verifican para tomar decisiones sobre si permitir o bloquear un paquete para que no sea reenviado.

Luego, este enfoque se externalizó a dispositivos de red dedicados (firewalls) que originalmente utilizaban el mismo enfoque básico. Dado que todos los paquetes IP contienen información en sus encabezados que indican su origen y destino, además de números TCP o UDP que indican qué tipo de datos están presentes en la carga útil de datos del paquete, un firewall utiliza esta información para tomar decisiones de reenvío basadas en sus propias listas de control de acceso. A medida que la red se ocupa de los paquetes, tenía sentido dejar que la red también se ocupara de la seguridad y la microsegmentación, liberando a los equipos de desarrollo de aplicaciones y sistemas para centrarse en otras preocupaciones.

Sin embargo, generalmente es fácil engañar a un firewall basado en paquetes. No es demasiado difícil “suplantación” de direcciones y números de puerto de TRACK/PAC en un paquete IP, lo que da como resultado un paquete que puede enmascarar fácilmente lo que está contenido en su carga útil de datos. Entonces, los firewalls basados en sesiones evolucionaron para enfocarse en mapear todos los paquetes en un flujo dado a una sesión única, y para monitorear el comportamiento de esa sesión en función de la aplicación a la que “piensa” que está asociada. Estos firewalls no tenían visibilidad completa de cada paquete, pero comparan cómo se comportaban esos paquetes y sesiones con los comportamientos de línea base de las aplicaciones, buscando anomalías.

Posteriormente aparecieron los llamados firewalls de “próxima generación”, que aplican mucha más inteligencia para identificar qué contiene un paquete, a qué aplicación está asociado, a qué usuario está asociado y otros detalles que indican una brecha de seguridad. Sin embargo, todos estos detalles se producen en línea en la red, no en las cargas de trabajo de origen o destino en sí. Los firewalls no tienen idea de lo que sucede en las cargas de trabajo que están enviando y recibiendo estos paquetes, a menos que de alguna manera se estén comunicando con alguna herramienta central que también esté monitoreando cargas de trabajo y aplicaciones y luego dirigiendo el tráfico seleccionado al firewall. Pero esto puede ser complejo de implementar, por lo que los firewalls a menudo simplemente se encuentran en la red, esperando que lleguen los paquetes.

La seguridad de la red es diferente a la seguridad de la carga de trabajo

Paralelamente a los firewalls que toman decisiones sobre qué paquetes pueden y qué no pueden reenviarse, los routers y switches tienen sus propias preocupaciones de seguridad, que son el resultado del mismo problema básico: la seguridad no era una preocupación principal cuando se diseñaron originalmente los protocolos de red.

Los protocolos TCP/IP y de enrutamiento dinámico que se utilizan para reenviar paquetes, como BGP y OSPF, se diseñaron con los mismos objetivos básicos que las aplicaciones y las cargas de trabajo: funcionalidad y resiliencia. La seguridad no era una prioridad al inicio de la creación de redes. La seguridad y la microsegmentación se convirtieron en una prioridad en una etapa posterior de la evolución de la red, y las soluciones de seguridad de la red se han utilizado para abordar problemas de seguridad que son específicos de las redes. La seguridad no es solo una preocupación para las cargas de trabajo y las aplicaciones. Existen problemas de seguridad en la red de los que las cargas de trabajo y las aplicaciones no tienen visibilidad.

Como recordatorio, estos son solo algunos ejemplos de los desafíos de seguridad que existen en la capa de red de cualquier arquitectura de nube:

• Ingeniería de tráfico
• Denegación de servicio (DoS)
• suplantación de ARP
• Autenticación BGP
• Redirección de tráfico
• Ataques de hombre en el medio
• Propagación de rutas falsas
• Secuestro de router de primer salto
• Secuestro de cookies de sesión

Los elementos de esta breve lista son todos los problemas de seguridad específicos de las redes, no de las cargas de trabajo o las aplicaciones. Por ejemplo, las tecnologías como MPLS y la confiabilidad de los protocolos de distribución de etiquetas abordan los desafíos de ingeniería de tráfico. La denegación de servicio es un problema importante que a menudo se aborda mediante el uso de comunidades BGP intercambiadas con pares de enrutamiento de ISP. La suplantación de ARP es un problema en el que los routers cambian sus mapeos entre direcciones de Capa 3 y Capa 2, causando que el destino del tráfico sea secuestrado. La autenticación BGP requiere algo como RPKI para cifrar la información intercambiada entre pares BGP, para evitar problemas de enrutamiento a través de Internet. Y así sucesivamente. El networking tiene su propio vocabulario especializado para hacer frente a problemas de seguridad que son exclusivos de la capa de red de cualquier arquitectura de nube.

Estos ejemplos son solo algunas de las principales preocupaciones de seguridad de las arquitecturas de red, no de las arquitecturas de carga de trabajo o de aplicaciones. Los equipos de desarrollo de aplicaciones y sistemas generalmente no tienen visibilidad de estos problemas de seguridad de la red, ya que no deberían tener que hacerlo. Cuando el sistema operativo de una carga de trabajo utiliza iptables, por ejemplo, para enviar o recibir un paquete, no necesitan saber si BGP está siendo secuestrado de alguna manera entre ISP en alguna parte de la red. Las cargas de trabajo y las aplicaciones se ocupan de la carga de trabajo y la seguridad de las aplicaciones, no de la seguridad de la red.

Las soluciones de seguridad de redes no son soluciones de seguridad de carga de trabajo

Lo que esto significa es que las herramientas diseñadas para enfrentar los desafíos de seguridad de las redes no suelen ser las herramientas adecuadas para enfrentar los desafíos de seguridad y microsegmentación en cargas de trabajo o aplicaciones. La seguridad de las cargas de trabajo a menudo requiere no estar limitada por la escala: la implementación de miles de cargas de trabajo en múltiples nubes no debe depender de ninguna herramienta de capa de red para brindar de alguna manera seguridad a nivel de aplicación a esas cargas de trabajo.

Las cargas de trabajo a menudo migran en vivo a través de los límites de la capa 3, o entre nubes, y las cargas de trabajo no deben depender de herramientas de capa de red que de alguna manera rastreen estas migraciones para hacer cumplir seguridad de carga de trabajo y microsegmentación. Las aplicaciones dependen de dependencias entre cargas de trabajo, y estas dependencias a menudo no son visibles para las herramientas de capa de red, por lo que la definición de una barrera alrededor de las aplicaciones no debe estar limitada por la falta de visibilidad de la red sobre las dependencias completas de las aplicaciones.

Algunos proveedores de redes propondrán sus soluciones SDN como soluciones para los requerimientos de microsegmentación y seguridad de las aplicaciones y de carga de trabajo. Pero estas herramientas residen en las capas de red o hipervisor, y estas herramientas fueron diseñadas para abordar las prioridades en esas capas: como automatización, virtualización, análisis de red, superposiciones de red y tunelización, y autenticación entre protocolos de enrutamiento dinámico. Las herramientas SDN no fueron diseñadas para proporcionar seguridad y microsegmentación a cargas de trabajo y aplicaciones a escala.

También pueden proponer firewalls, ya sea hardware o instancias virtualizadas en un hipervisor, como soluciones para la carga de trabajo y los requerimientos de seguridad de las aplicaciones, argumentando que los firewalls de próxima generación proporcionan visibilidad completa de capa 7 del tráfico de red. Sin embargo, cualquier firewall sólo es útil una vez que los paquetes llegan a él. Los firewalls no tienen la capacidad de influir en el comportamiento de las aplicaciones o cargas de trabajo en su origen, sino que solo esperan a que los paquetes lleguen al puerto de un firewall. Los firewalls refuerzan la seguridad de la red y microsegmentación a medida que el tráfico está en tránsito: tráfico norte-sur. No imponen la seguridad de las aplicaciones o de la carga de trabajo en el origen: el tráfico este-oeste. Ambas soluciones son necesarias para una verdadera Cero Confianza arquitectura que debe realizarse, pero una capa de la arquitectura no puede proporcionar seguridad completa y microsegmentación a la otra.

Los equipos de redes no deben tener que encargarse de la carga de trabajo o la seguridad de las aplicaciones

Los equipos de red se enfocan en las tareas de red, que son diferentes a las tareas de carga de trabajo o aplicaciones. Estas tareas involucran términos relevantes para esos equipos, como traducciones de capa 2 y capa 3 y mecanismos de reenvío, protocolos de enrutamiento como BGP y OSPF y cómo se hacen pares entre sí, y sus propios mecanismos de autenticación. Las soluciones a los problemas de redes de capa 2, como el árbol de extensión y el ECMP, también tienen sus propias prioridades de seguridad. Las herramientas de red como SDN y los dispositivos de red virtualizados implementados en hipervisores se centran en problemas específicos de las prioridades de red. En ninguna de estas soluciones, los riesgos de seguridad dentro de una carga de trabajo en sí son una prioridad.

Lo que todo esto significa es que al diseñar soluciones de seguridad y microsegmentación para cargas de trabajo, esas soluciones deben implementarse ahí: en la carga de trabajo. Las herramientas de red tienen prioridades que difieren de las preocupaciones de la carga de trabajo o de las aplicaciones. Las herramientas de seguridad de la red siempre existirán, enfocándose en imponer el tráfico norte-sur, dentro y fuera de la estructura general de la red. Estas herramientas de red se implementarán en dispositivos de red. La seguridad de la carga de trabajo debe implementarse en las propias cargas de trabajo, y éstas se centrarán en imponer el tráfico este-oeste, entre cargas de trabajo y entre aplicaciones.

Mantener cada capa de la arquitectura general enfocada en las prioridades específicas de su propia capa permitirá que cada una sea agnóstica a la otra, sin que ninguna de las capas imponga limitaciones en la forma en que la otra opera o escala. El resultado es una arquitectura Zero Trust completamente realizada.

Muchas arquitecturas nativas de la nube siguen las mejores prácticas de seguridad e implementan soluciones de seguridad de carga de trabajo en las propias cargas de trabajo. Pero los viejos hábitos mueren y, a menudo, cuando los entornos de TI existentes se migran de data centers a servicios en la nube, también se migrará el enfoque tradicional de usar soluciones de red para tratar de imponer la seguridad de la carga de trabajo, con el resultado de una capa de red que a menudo es ciega a los requerimientos de seguridad este-oeste entre las cargas de trabajo y las aplicaciones. El resultado no es Cero Confianza.

Aquí es donde Illumio encaja en la arquitectura de seguridad general. A diferencia de los enfoques tradicionales para la segmentación de redes, Illumio permite que la seguridad y la microsegmentación se apliquen directamente en la entidad que está tratando de asegurar y segmentar: la carga de trabajo en sí. Hacerlo permite que la seguridad de la carga de trabajo y las aplicaciones y la microsegmentación escalen y evolucionen sin depender de dónde residen en la red. Y esto permite que las cargas de trabajo residan o migren en cualquier lugar a través de data centers locales o entre proveedores de nube.

Una arquitectura multinube creará una estructura de red amplia, con capacidad de acceso a todas las topologías de red subyacentes. La seguridad y la microsegmentación deben seguir la misma pauta, proporcionando una solución consistente y escalable en la misma estructura de red, end-to-end. La confianza cero significa que el límite de confianza de seguridad se extiende a cada carga de trabajo y aplicación que necesita protegerse, y ese objetivo no debe limitarse tratando de habilitar este objetivo en cualquier capa diferente de la arquitectura de la nube.

Para obtener más información sobre estos temas y cómo Illumio resuelve la carga de trabajo y la seguridad de las aplicaciones:

• Vea este video de descripción general rápida en La evolución de la segmentación
• Echa un vistazo a este seminario web bajo demanda: Desbloquee la seguridad de la red: segmentación simplida