Avishag Daniely

Director of Product Management, Guardicore.

---

Los grupos de seguridad son los firewalls de la Nube. Están integrados y proporcionan una funcionalidad básica de control de acceso como parte del modelo de responsabilidad compartida. Sin embargo, los grupos de seguridad en la Nube no proporcionan la misma protección o funcionalidad que las empresas esperan con las implementaciones locales. Mientras que los firewalls de última generación protegen el perímetro y segmentan las aplicaciones en las instalaciones de las empresas, AWS, Azure y GCP no reflejan esto en la Nube. La segmentación de aplicaciones mediante Grupos de seguridad en la Nube se realiza de manera restringida, soportando únicamente tráfico de capa 4, puertos e IPs. Esto significa que para beneficiarse de las capacidades de seguridad a nivel de aplicación en sus aplicaciones en la Nube, necesitará un conjunto adicional de controles que no está disponible con la funcionalidad integrada de los Grupos de seguridad en la Nube. 

La función básica que deben proporcionar los grupos de seguridad en la Nube es la separación de la red, por lo que pueden compararse mejor con lo que las VLAN proporcionan en la infraestructura on-premise, las listas de control de acceso en los switches y los FW de punto final. Desafortunadamente, al igual que las VLAN, ACL y FW de punto final, los grupos de seguridad en la Nube tienen carencias y limitaciones similares. Esto hace que su uso sea complejo, costoso y, en última instancia, ineficaz para las redes modernas, que son híbridas y requieren una segmentación adecuada. Para crear políticas con reconocimiento de aplicaciones y microsegmentar una aplicación, debe visualizar las dependencias de la aplicación, funcionalidad que los grupos de seguridad en la Nube no proporcionan. Además, si las dependencias de su aplicación cruzan regiones dentro del mismo proveedor de la Nube o entre Nubes y en las instalaciones, los grupos de seguridad de la aplicación son ineficaces por diseño. 

En este texto, estudiaremos en un escenario específico y en un caso de uso que es común para la mayoría de las organizaciones, discutiendo las limitaciones de los grupos de seguridad de la Nube y los registros de flujo dentro de una red virtual específica e ilustrando cuál es el valor de una solución que permita ofrecer visibilidad de las dependencias en el centro de datos y segmentación definida por software, como es el caso de GuardiCore Centra, en este escenario.

Experimento: simule una migración de aplicaciones SWIFT a Azure

Veamos los detalles de un experimento realizado por uno de nuestros clientes durante una simulación de una migración de la aplicación SWIFT a Azure.

Nuestro cliente usó una suscripción en Azure, en la región sur de Brasil. Dentro de la suscripción, hay una red virtual ( vNet ). La red virtual incluye una subred 10.0.2.0/24 con varios servidores de aplicaciones que sirven diferentes roles.

Este cliente intentó simular la migración de su aplicación SWIFT a Azure dada la suscripción anterior. Las reglas generales de segmentación para su aplicación SWIFT migrada se establecieron utilizando NSG (grupos de seguridad de red) y ASG (grupos de seguridad de aplicaciones). Estos se usaron para administrar y controlar el tráfico de red dentro de la red virtual ( vNet ) y específicamente para segmentar esta aplicación.

Repasemos la diferencia:

•         Un NSG es el recurso de Azure que se usa para imponer y controlar el tráfico de red. Los NSG controlan el acceso al permitir o denegar el tráfico de red. Todo el tráfico que ingresa o sale de su red de Azure se puede procesar a través de un NSG. 
•         Un ASG es una referencia de objeto dentro de un grupo de seguridad de red. Los ASG se usan dentro de un NSG para aplicar una regla de seguridad de red a una carga de trabajo específica o grupo de máquinas virtuales. Un ASG es un "objeto de red" y se agregan direcciones IP explícitas a este objeto. Esto proporciona la capacidad de agrupar máquinas virtuales en grupos asociados o cargas de trabajo. 

La configuración del laboratorio:

La configuración de la Nube en este experimento incluyó una única vNet, con una única subred, que tiene su propio grupo de seguridad de red (NSG) asignado.

ASGs

•         Nótese que todos están contenidos en el mismo Grupo de recursos y pertenecen a la ubicación de la red virtual (Brasil Sur).

NSGs:

Las siguientes reglas NSG estaban vigentes para la aplicación SWIFT migrada simulada:

•         Equilibradores de carga a servidores web, a través de puertos específicos, permitir.
•         Los servidores web para bases de datos, a través de puertos específicos, permitir.
•         Denegar todo lo demás entre servidores SWIFT.

El problema:

Un miembro del equipo de aplicaciones SWIFT a cargo del proyecto de simulación llamó al equipo de seguridad de la Nube y les dijo que una operación de copia de seguridad crítica había dejado de funcionar en la aplicación migrada, y sospecha que la conexión está bloqueada. El equipo de la red en la Nube, en este punto, tuvo que verificar la causa raíz del problema, parcialmente mediante un proceso de eliminación, de varias opciones posibles:

1. El miembro del equipo de la aplicación estaba equivocado, no es un problema de política sino un problema de configuración dentro de la aplicación.
2. Los ASG están mal configurados mientras que los NSG están configurados correctamente.
3. Los ASG están configurados correctamente, pero los NSG están mal configurados o no tienen una regla.

El equipo de la Nube comenzó el proceso de eliminación. Utilizaron los registros de flujo de Azure para intentar detectar las posibles conexiones bloqueadas. El siguiente es un ejemplo de dicho registro:

Utilizando la plataforma Microsoft Azure Log Analytics, el equipo de la Nube analizó los datos sin éxito. Estaban buscando una conexión bloqueada que podría ser el proceso de respaldo. La conexión bloqueada no era detectable. Por lo tanto, los miembros del equipo de la Nube descartaron el problema como una configuración incorrecta en la aplicación.

El miembro del equipo SWIFT insistió en que no se trataba de un problema de aplicación y pasaron varios días sin solución, todo mientras la operación de copia de seguridad SWIFT seguía fallando. En un entorno en vivo, este punto muerto habría sido una catástrofe, y los miembros del equipo probablemente trabajarían las 24 horas para encontrar la conexión bloqueada o probar una configuración incorrecta en la aplicación misma. En muchos casos, un incidente como este llevaría a la eliminación de la política de seguridad en aras de la continuidad del negocio, ya que millones de dólares están en juego diariamente.

Después de muchos debates y una escalada del incidente, se decidió, basándose en la recomendación del equipo de Protect, utilizar las capacidades de visibilidad de GuardiCore en el entorno de la Nube de Azure para ayudar con el proyecto de investigación y simulación de migración.

Así, el equipo usó Reveal para filtrar todas las conexiones fallidas relacionadas con la aplicación SWIFT. Esto reveló inmediatamente un intento de conexión fallida, entre el balanceador de carga SWIFT y las bases de datos SWIFT . La conexión estaba fallando debido a la falta de grupos de seguridad en modo allow. No había ningún NSG para permitir que SWIFT LB hablara con SWIFT DB en la política.  

Los filtros en Reveal

                                

Descubriendo el proceso

Utilizando la herramienta de visibilidad de Centra se identificó el proceso de copia de seguridad que estaba fallando.

El contexto de la aplicación es una necesidad

La razón por la que los registros de flujo eran inadecuados para detectar la conexión era que las IP cambiaban constantemente a medida que la aplicación crecía y menguaba, y el proyecto de simulación de migración avanzaba. A lo largo de todo el proceso, los equipos no contaron con un contexto de cuándo se suponía que debía ocurrir la operación de respaldo o qué servidores iniciarían estos intentos de conexión, por lo que la búsqueda resultó infructuosa. Estaban buscando lo que pensaban que revelaría las conexiones fallidas. Como los registros de flujo están limitados a IP y puertos, no pudieron realizar búsquedas en función del contexto de la aplicación.

El equipo de la Nube procedió entonces a la segmentación de la simulación de la aplicación SWIFT, agregando procesos y contexto de usuario a las reglas para proporcionar una seguridad más granular. Utilizando centra se comparó la implementación de la aplicación local con la configuración de la Nube para asegurarse de que todas las configuraciones estaban en su lugar.

Posteriormente se simuló la política SWIFT sobre el tráfico SWIFT real, asegurándose de que no estaban bloqueando servicios críticos adicionales y que no los bloquearían inadvertidamente en el futuro.

                                      

Las claves de la resolución exitosa del incidente fueron:

•         Visibilidad y velocidad para detectar los flujos bloqueados relevantes 
•         Contexto del usuario y el proceso para identificar la operación fallida como la operación de respaldo 
•         Posibilidad de recibir alertas en tiempo real sobre cualquier violación de la política  
•         Aplicación de reglas de nivel de proceso y reglas de nivel de usuario necesarias para la aplicación SWIFT crítica  
•         Capacidades de simulación y prueba para simular las políticas sobre el tráfico real de aplicaciones antes de bloquear 

Todas estas características no están disponibles en Azure. Estas limitaciones tuvieron serias implicaciones, como la falla de la operación de respaldo y la imposibilidad de investigar y resolver el problema adecuadamente.

Además, como parte de la higiene general del entorno, nuestro cliente intentó agregar varias reglas para gobernar toda la vNet , bloqueando Telnet y FTP inseguro. Para Telnet, nuestro cliente pudo agregar una regla de bloqueo en Azure en el puerto 23; Para FTP, se planteó un problema. FTP puede comunicarse a través de puertos de alto rango que muchas otras aplicaciones necesitarán usar, por lo que se implementó una regla de bloqueo simple sobre el proceso ftpd sin restricción de puerto, bloqueando inmediatamente cualquier comunicación ftp insegura a nivel de proceso, independientemente de los puertos utilizados.

                                            

La visibilidad es clave para cualquier proyecto exitoso de migración de aplicaciones. Comprender las dependencias de su aplicación es un paso crítico, que permite configurar la aplicación con éxito en la Nube.