En estos tiempos en los que todas las compañías quieren unirse a la ola de la nube por temas de ahorro de coste y globalización, muchos de ellos encuentran reticencias para poder lograrlo porque sus departamentos de seguridad no certifican al 100% la solución como compatible con los estándares de la compañía en cuanto a seguridad. Esto sobre todo pasa con compañías donde trabajan con datos personales críticos tanto para la compañía como porque lo exige el reglamento de protección de datos, no se pueden permitir que los datos viajen por redes que no son privadas y que puedan estar expuestas a ataques del tipo man-in-the-middle, sniffing, etc.
Estos departamentos solo van a permitir que los datos con los que trabajan estos servicios en la nube solo fluyan por las redes privadas donde ellos puedan poner algún tipo de firewall para controlar que en ningún momento nada del exterior que no sea autorizado por ellos pueda entrar.
En un cliente con una exigencia de seguridad como la comentada anteriormente, nos hemos encontrado nosotros en un proyecto, donde aparte de otros recursos a implementar en la nube de Microsoft Azure, teníamos que utilizar el servicio PaaS de Databricks.
Arquitectura de Databricks
Para ponernos en situación de partida, vamos a dar un repaso rápido de cómo queda configurada la arquitectura de Databricks en Azure cuando creas el recurso con las opciones por defecto:
Cuando creamos el recurso de Databricks esto por debajo implementa dos paneles de trabajo de la siguiente manera:
- El panel de control. Estos son recursos que existen fuera de la suscripción de Azure donde estamos creando el recurso de databrick y que están en la nube de la empresa Databricks.
- El panel de datos. Son recursos que se crean en la suscripción de Azure donde hemos decidido crear el recurso de databricks.
Hay que tener en cuenta lo siguiente en cuanto al flujo de los datos que vamos a tratar en el servicio de databricks:
- El panel de control nunca va a recibir los datos, este panel solo tiene la función de gestionar los clusters, por tanto el trafico que fluye entre el panel de control y el de datos es solo trafico para controlar las actualizaciones, arranques y paradas de los nodos del cluster y va encriptado. IMPORTANTE: el trafico entre el panel de control y el de datos fluye por la red de Microsoft no sale por el internet público.
- El panel de datos es el único sitio donde los datos fluyen entre los diferentes nodos del cluster, y entre los orígenes y los nodos. Aquí es donde tenemos que poner el foco para que los datos vayan siempre por la red privada que hayamos configurado.
Implementación del recurso Databricks en la suscripción
Por defecto cuando creas el recurso de databricks en Azure ,si tu no especificas nada, este crea dentro de tu suscripción una red virtual (Vnet) totalmente gestionada por Microsoft donde van a existir dos subnets y una serie de grupos de seguridad (Nsg) que van a permitir la ingesta de los datos para que Databricks pueda tratarlos.
Que requisitos no se cumplen con la opción por defecto para cumplir con la seguridad que requiere la empresa en cuanto al flujo de datos
Una vez planteado el punto de partida, nos encontramos con los siguientes focos donde debemos de buscar soluciones para cumplir con los estándares de seguridad del cliente:
Todos los recursos que cree Databricks en la suscripción deben estar dentro de la red que existe ya en la suscripción, no se pueden crear recursos no controlados por el cliente.
Solución
Lo que tenemos que hacer es configurar la creación de Databricks para que utilice las subredes que el cliente cree para este servicio dentro de su red, lo que se llama “Vnet injection”. Para no hacer muy largo el artículo, os adjunto un link a la documentación de Microsoft donde se detallan los requisitos y pasos a dar para generar esta configuración.
Los accesos a los orígenes datos deben de hacerse dentro de la red privada.
Solución
La solución fue trabajar con los “private links” , siempre que los recursos de Azure que son el origen de datos lo permitan, en este caso era así, ya que trabajábamos con cuentas de almacenamiento e instancias manejadas de SQL. Para ello deshabilitábamos los accesos por fuera de la red privada en la configuración de seguridad de cada recurso y solo dejamos activo el acceso por un punto privado (private endpoint) . Para más información sobre “private links”.
La red del cliente en la suscripción de Azure tiene configurada una ruta en la tabla de rutas para que todo el trafico de salida y entrada de la red pase por un firewall.
Solución
El problema que nos encontramos es la comunicación que existe entre el panel de control y de datos, para ello debemos de abrir una serie de puerto en el firewall y aquí os dejo la lista.
El requisito que ponía el cliente es que para asegurar su red privada , el firewall estaba configurado de la tal manera que no permitía la entrada desde fuera, es decir permitía algunos puertos y/o protocolos hacia fuera pero nada hacia dentro.
Por lo que tuvimos que ir a una solución, todavía en preview, donde configurabas la comunicación entre el panel del control y el de datos de la siguiente manera con la opción “conectividad de cluster segura”, esto consiste en lo siguiente:
Con la “conectividad de clúster segura” habilitada, las redes virtuales de clientes no tienen puertos abiertos y los nodos del databricks del clúster no tienen ninguna dirección IP pública.
- A nivel de red, cada clúster cuando arranca, inicia una conexión con el panel de control. El clúster establece esta conexión mediante el puerto 443 (HTTPS) y una dirección IP distinta de la que se usa para la aplicación web y la API de REST (por donde nos conectamos cuando entramos al área de trabajo de databricks en el portal de Azure).
- Las acciones que el plano de control debe realizar, como iniciar nuevos trabajos del Databricks o la administración de clústeres, se envían como solicitudes al clúster a través de este túnel inverso.
- De esta manera el panel de datos ( su red virtual) no tiene puertos abiertos y los nodos del Databrick de clúster no tienen direcciones IP públicas.
En este diagrama vemos como quedan las comunicaciones con esta opción entre el panel de datos y el panel de control de databricks:
Para más información: https://docs.microsoft.com/es-es/azure/databricks/security/secure-cluster-connectivity
Conclusión
A la hora de trabajar con los sistemas en las nubes, no solo hay que contar con los beneficios que esta nos aporta para mejorar nuestros procesos, sino que también hay que configurar una buena configuración de seguridad para que nuestros datos no caigan en manos extrañas, por lo que si necesitas moverte a la nube y quieres que te acompañemos en este viaje de una forma segura no dejes de contactar con nosotros.
Moderniza tu plataforma de datos ahora y duerme tranquilo
Mejora la eficiencia de tu plataforma, con seguridad y cumpliendo las normativas vigentes, mientras despliegas proyectos innovadores para acelerar tu negocio. Mantente competitivo y mejora el rendimiento de tus datos.
Me interesa
