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

Las infracciones, los hackeos, los secuestros, la pérdida de datos y la exfiltración son problemas que existen en la mayoría de las arquitecturas en la 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 gestión general de procesos se diseñaron teniendo en cuenta diferentes prioridades: funcionalidad y resiliencia. Todas estas tareas deben funcionar y deben sobrevivir a fallas de elementos en la arquitectura general, pero cerciorar estos elementos generalmente fue una ocurrencia tardía.

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

Independientemente de cómo se desarrollen las aplicaciones, cómo se construyan e implementen los diferentes sistemas operativos, y cómo se virtualice, abstraiga y gestione todo esto, la mayoría de estos elementos deben comunicar 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 que los clientes remotos puedan acceder a ellas, ya sea a través de una red privada o a través de Internet. Esto es necesario en cualquier tipo de arquitectura en la nube, y cualquier arquitectura nativa en la nube simplemente no funcionará sin una red ya existente para comunicar a través de ella. Por lo tanto, se puede argumentar que el elemento más crítico de cualquier arquitectura general de la 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 independientes de 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)
• Resistencia (el error de uno o más dispositivos de red no debe provocar un error en todo el sistema)
• Ingeniería de tráfico y calidad de servicio (las redes IP son, por diseño, "sin conexión", pero debe haber formas de diseñar y priorizar diferentes tipos de tráfico)
• Escalado (las redes deben poder evolucionar sin alcanzar un techo de recursos)

Las aplicaciones y las cargas de trabajo no deben tener en cuenta ninguno de estos detalles para poder usar la red.

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

Una breve historia de la seguridad de la red

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

Si retrocede el reloj varias décadas, la seguridad en las redes IP originalmente tomó la forma de listas de control de acceso ("ACL") en enrutadores y conmutadores. Los dispositivos de red generalmente manejan el tráfico por paquete, por lo que a medida que los paquetes llegan a un enrutador o conmutador, estas ACL se verifican para tomar decisiones sobre si permitir o bloquear el reenvío de un paquete.

Este enfoque se subcontrató a dispositivos de red dedicados, firewalls, que originalmente usaban 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 emplea esta información para tomar decisiones de reenvío basadas en sus propias listas de control de acceso. Como 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 que se centraran en otras preocupaciones.

Sin embargo, generalmente es fácil engañar a un firewall basado en paquetes. No es demasiado difícil "falsificar" direcciones y números de puerto TCP/UDP en un paquete IP, lo que da como resultado un paquete que puede enmascarar fácilmente lo que contiene su carga útil de datos. Por lo tanto, los firewalls basados en sesiones evolucionaron para centrar en asignar todos los paquetes de un flujo determinado a una sesión única y monitorear el comportamiento de esa sesión en función de la aplicación con la que "piensa" que está asociada. Estos firewalls no tenían una visibilidad completa de cada paquete, pero comparan cómo se comportaron esos paquetes y sesiones con los comportamientos de referencia de la aplicación, buscando anomalías.

Más tarde, aparecieron los llamados firewalls de "próxima generación", que aplican mucha más inteligencia para identificar lo que contiene un paquete, con qué aplicación está asociado, con qué usuario está asociado y otros detalles que indican una violación de seguridad. Pero 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 envían y reciben estos paquetes, a menos que de alguna manera se comuniquen con alguna herramienta central que también esté monitoreando cargas de trabajo y aplicaciones y luego dirijan el tráfico seleccionado al firewall. Pero esto puede ser complejo de implementar, por lo que los firewalls a menudo simplemente están sentados en la red, esperando que lleguen los paquetes.

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

Paralelamente a los firewalls que toman decisiones sobre qué paquetes se pueden y no se pueden reenviar, los enrutadores y conmutadores 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 emplean 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 resistencia. La seguridad no era una prioridad en los inicios de las 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 red se emplearon para abordar las preocupaciones de seguridad que son específicas 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 en la 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 intermediarios
• Propagación de rutas falsas
• Secuestro del router de primer salto
• Secuestro de cookies de sesión

Los elementos de esta breve lista son todos problemas de seguridad específicos de las redes, no de las cargas de trabajo o las aplicaciones. Por ejemplo, los desafíos de la ingeniería de tráfico se abordan con tecnologías como MPLS y la confiabilidad de los protocolos de distribución de etiquetas. 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 ISP. La suplantación de ARP es un problema en el que los enrutadores cambian sus asignaciones entre direcciones de capa 3 y capa 2, lo que hace que se secuestre el destino del tráfico. 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. Las redes tienen su propio vocabulario especializado para tratar los problemas de seguridad que son exclusivos de la capa de red de cualquier arquitectura en la 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 aplicaciones. Los equipos de desarrollo de aplicaciones y sistemas generalmente no tienen visibilidad de estos problemas de seguridad de la red, porque no deberían necesitarla. Cuando el sistema operativo de una carga de trabajo usa iptables, por ejemplo, para enviar o recibir un paquete, no necesitan saber si BGP está siendo secuestrado de alguna manera entre ISP en algún lugar de la red. Las cargas de trabajo y las aplicaciones se ocupan de la seguridad de la carga de trabajo y de las aplicaciones, no de la seguridad de la red.

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

Lo que esto significa es que las herramientas diseñadas para abordar los desafíos de seguridad de las redes no suelen ser las herramientas adecuadas para abordar los desafíos de seguridad y microsegmentación en cargas de trabajo o aplicaciones. La seguridad de la carga 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 seguridad a nivel de aplicación a esas cargas de trabajo.

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

Algunos proveedores de redes propondrán sus soluciones SDN como soluciones para los requisitos de microsegmentación y seguridad de la carga de trabajo y las aplicaciones. 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 la automatización, la virtualización, el análisis de red, las superposiciones de red y la tunelización, y la autenticación entre protocolos de enrutamiento dinámico. Las herramientas SDN no se diseñaron 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 a los requisitos de seguridad de cargas de trabajo y aplicaciones, argumentando que los firewalls de próxima generación brindan visibilidad completa de capa 7 del tráfico de red. Sin embargo, cualquier firewall solo es útil una vez que los paquetes lo alcanzan. 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 que los paquetes lleguen al puerto de un firewall. Los firewalls refuerzan la seguridad de la red y la microsegmentación a medida que el tráfico está en tránsito: tráfico norte-sur. No aplican la seguridad de las aplicaciones o las cargas de trabajo en el origen: tráfico este-oeste. Ambas soluciones son necesarias para que se realice una verdadera arquitectura Zero Trust , pero una capa de la arquitectura no puede proporcionar seguridad y microsegmentación completas a la otra.

Los equipos de redes no deben encargar de la carga de trabajo o la seguridad de las aplicaciones

Los equipos de red se centran en las tareas de red, que son diferentes de las tareas de carga de trabajo o de aplicación. 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 emparejan entre sí, y sus propios mecanismos de autenticación. Las soluciones a los problemas de red de capa 2, como el árbol de expansión y 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 son prioritarios los riesgos de seguridad dentro de una carga de trabajo en sí misma.

Lo que todo esto significa es que al diseñar soluciones de seguridad y microsegmentación para cargas de trabajo, esas soluciones deben implementar allí: 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 red siempre existirán, centrar en hacer cumplir el tráfico norte-sur, dentro y fuera de la estructura de red general. Estas herramientas de red se implementarán en dispositivos de red. La seguridad de la carga de trabajo debe implementar en las propias cargas de trabajo, y estas se centrarán en hacer cumplir el tráfico este-oeste, entre cargas de trabajo y entre aplicaciones.

Mantener cada capa de la arquitectura general centrada 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 sobre cómo opera o escala la otra. El resultado es una arquitectura Zero Trust totalmente realizada.

Muchas arquitecturas nativas de la nube siguen las mejores prácticas de seguridad e implementarán soluciones de seguridad de cargas de trabajo en las propias cargas de trabajo. Pero los viejos hábitos tardan en morir y, a menudo, cuando los entornos de TI existentes se migran de los centros de datos a los servicios en la nube, también se migrará el enfoque tradicional de usar soluciones de red para tratar de hacer cumplir la seguridad de la carga de trabajo, con el resultado de una capa de red que a menudo es ciega a los requisitos de seguridad este-oeste entre cargas de trabajo y aplicaciones. El resultado no es Zero Trust.

Aquí es donde Illumio encaja en la arquitectura de seguridad general. A diferencia de los enfoques tradicionales para la segmentación de la red, Illumio permite que la seguridad y la microsegmentación se apliquen directamente en la entidad que está tratando de proteger y segmentar: la carga de trabajo en sí. Hacerlo permite que la seguridad y la microsegmentación de cargas de trabajo y aplicaciones 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 centros de datos locales o entre proveedores de nube.

Una arquitectura multinube creará una estructura de red amplia, con accesibilidad en todas las topologías de red subyacentes. La seguridad y la microsegmentación deben seguir la misma pauta, proporcionando una solución coherente y escalable en la misma estructura de red, de extremo a extremo. Confianza cero significa que el límite de confianza de seguridad se extiende a cada carga de trabajo y aplicación que necesita protección, y ese objetivo no debe limitar al intentar 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 seguridad de las cargas de trabajo y las aplicaciones:

• Vea este video de descripción general rápida sobre la evolución de la segmentación
• Consulte este seminario sitio web a pedido: Desbloquee la seguridad de la red: segmentación simplificada