Con las leyes de protección de datos, y las nuevas plataformas que contienen nuevas y diferentes formas de distribuir y de acceder a la información, la securización de ésta cobra vital importancia. Es un problema recurrente, y que nos suele dar varios quebraderos de cabeza, así que voy a compartir una experiencia concreta, real, de proyecto, por si os puede ayudar a evitar esos momentos más difíciles.
En este sentido, explico la solución que hemos adoptado para la securización del dato, en un proyecto orientado a BI en Cloud, sobre Microsoft Azure y a través de Azure Databricks. Para ello, haré un repaso de la arquitectura general, comentaremos brevemente aspectos generales a tener en cuenta, y por último describiremos la solución que hemos adoptado.
¡Empecemos!:
En el gráfico, podemos ver la arquitectura del DataLake (o Lakehouse si somos puristas), donde los datos son ingestados mediante procesos batch, y se encuentran almacenados en una cuenta de almacenamiento distribuidas en 4 capas:
La orquestación e integración se realiza mediante Azure Data Factory, y para la ingesta y transformación en formato Delta, se utiliza un Framework de desarrollo propio en spark-scala. Toda la información se almacena en una cuenta tipo Azure Data Lake Gen2 (ADLS).
La información se explota mediante dashboards a través de Power BI, y autoconsumo mediante consultas SQL-like, por parte de distintos usuarios de negocio. En ambos casos, el acceso al dato se consigue a través de Azure Databricks, por lo que nos vamos a centrar en la securización del dato en Azure Databricks.
Vamos a ver un breve detalle de algunos elementos introducidos más arriba, que nos serán de utilidad para entender la solución que hemos adoptado.
Entorno de trabajo con acceso a los distintos activos de Databricks, que permiten la creación de clusters para ejecutar procesos Spark. En función del tamaño o necesidades del proyecto es posible tener varios workspaces.
Entre otras muchas capacidades, un workspace de Databricks nos permite realizar lo siguiente:
Sistema de archivos distribuido, disponible en un workspace de Databricks y accesible por todos los usuarios del mismo.
Contiene directorios raíz propios de Databricks, y además permite montar puntos de montaje (mount points) con acceso directo a datos externos. Únicamente los datos en la raíz de Databricks residen en dbfs, los datos de los puntos de montaje residen en un almacenamiento externo.
El montaje del almacenamiento de objetos en DBFS permite acceder a objetos en el almacenamiento de objetos como si estuvieran en el sistema de archivos local. Existen 2 tipos de Mount Points:
Punto montaje vía Service principal
Configuración de puntos de montaje a través del protocolo oAuth 2.0 y mediante el uso de Service Principals. Hay que tener en cuenta que estos mount points, están disponibles para todos los usuarios a través de los clusters del propio workspace, y acceden al ADLS, a través de los permisos sobre el Service Principal (acceso de lectura y/o escritura sobre las cuentas de almacenamiento) que los ha generado. De esta forma la seguridad de este acceso se debe realizar a través del Service Principal. No se realiza por los permisos propios del usuario.
Dejo información con los pasos para la creación de un mount point vía SP: Access Azure Data Lake Storage Gen2 using OAuth 2.0 with an Azure service principal - Azure Databricks | Microsoft Docs
Punto montaje vía Passthrough
Permite autenticarse automáticamente en ADLS desde Clusters de Azure Databricks, con la misma identidad de Azure Active Directory (Azure AD) que usa para iniciar sesión en Azure Databricks.
Permite configurar el acceso al ADLS, a través de los roles asignados a los usuarios (RBAC) y los permisos otorgados a los mismos en los contenedores y carpetas del ADLS (permisos ACL).
Hay que tener en cuenta que estos mount points sólo se pueden usar con un clúster que tenga activo el paso de credenciales, tampoco son accesibles desde Azure Data Factory.
Dejo también información para la creación de un mount point con el paso de credenciales: Access Azure Data Lake Storage using Azure Active Directory credential passthrough - Azure Databricks | Microsoft Docs
Cada workspace de Databricks, contiene por defecto un metastore de Hive accesible por todos los clusters. Este metastore puede ser el que proporciona por defecto Azure Databricks, o puede configurarse un metastore externo (cualquier BBDD propia). En nuestro caso, por políticas de seguridad del proyecto, configuramos un metastore interno propio en Sql Server, que puede ser compartido por diferentes workspaces de Databricks.
Dentro de este Metastore permite la creación de una capa SQL para el acceso al dato, por ejemplo, en nuestro proyecto hemos generado 3 BBDD:
Ejemplo
El formato Delta es una capa de abstracción de Databricks, de código abierto, sobre distintos tipos de Storage (ADLS, S3, HDFS, etc), y diseñado para un almacenamiento eficiente y de alto rendimiento. Delta Lake proporciona una serie de capacidades para cubrir problemáticas que tradicionalmente se han tenido en el ámbito de soluciones de tipo Big Data, como transacciones ACID (atomicidad, consistencia, aislamiento y durabilidad) garantizadas y los viajes en el tiempo (control de versiones de datos). La capacidad de "deshacer" un cambio o volver a una versión anterior es una de las características clave de las transacciones. Delta Lake proporciona instantáneas de datos que le permiten volver a versiones anteriores de datos para auditorías, reversiones o para reproducir experimento.
Información sobre Delta Lake en Azure: Guía de Delta Lake y Delta Engine: Azure Databricks | Microsoft Docs
Son un conjunto de recursos que permite la realización de cálculos y procesos analíticos. Estos clusters pueden ser de uso general (accesibles por diferentes usuarios para distintos análisis) o efímeros (se crean y eliminan después de un trabajo, se suelen usar para procesos automatizados).
En este apartado no voy a detallar las características de los diferentes tipos de clúster de Databricks, sino que me voy a enfocar en las características que nos interesan para el acceso a los datos.
Url Clusters Azure Databricks: Clústeres: Azure Databricks | Documentos de Microsoft
Opciones de Interés del Clúster:
Tipos de Clúster:
SQL Endpoint
Nos permite ejecutar comandos SQL en objetos de datos en Databricks SQL. Puede escalar y se administra de forma similar a un Clúster de Databricks, pero está orientado a la optimización y rendimiento del acceso a los datos. Únicamente permite el acceso a los datos generados en Databricks SQL. No hemos llegado a utilizar esta opción por el momento, debido a que los requisitos iniciales no lo hacen necesario, ni tampoco las volumetrías y la complejidad por el volumen de datos inicial del proyecto, ya que este tipo de recurso supone un mayor coste que un Clúster de Databricks.
Url SqlEndpoints: Puntos de conexión SQL - Azure Databricks - Databricks SQL | Documentos de Microsoft
Azure Databricks se sincroniza automáticamente con la identidad de Azure Active Directory. A nivel de seguridad dentro de Databricks se puede realizar lo siguiente:
Se pueden crear grupos de usuarios que compartan los mismos permisos. Un usuario puede pertenecer a varios grupos y un grupo puede estar compuesto por otros grupos.
Se puede otorgar permisos específicos para un usuario o grupo de usuarios:
Para ver los distintos comportamientos de las diferentes configuraciones, hemos realizado una serie de pruebas:
Los mount point vía SP sólo deberían usarse para espacios comunes a los que todos los usuarios puedan acceder.
Activar un clúster de paso con paso de credenciales activo, permite controlar la seguridad del Storage por carpeta a través del ACL, no securiza el acceso a objetos SQL, este acceso sólo se gestiona con el table Access control activado (ambas configuraciones son incompatibles en un mismo Clúster).
Para securizar el acceso a objetos SQL existen 2 opciones: clúster con table Access control activado o un endpoint de SQL.
Como hemos visto, necesitamos securizar el acceso a la diferente información separando por un lado el acceso por parte de los componentes de desarrollo (ADF, framework ETL) y por otro lado el acceso a los datos de los usuarios (vía PowerBI y Notebooks de Databricks). Con las pruebas que hemos realizado en el apartado anterior hemos adoptado la siguiente solución:
Para la ingesta planificada (desde Azure Data Factory) se van a utilizar clusters efímeros de tipo Standard (únicamente accesibles por ADF).
Los usuarios de negocio únicamente podrán acceder a clusters High Concurrency con el control de tabla activo, por lo que su seguridad será gestionada a nivel de objeto SQL.
La solución final sería la siguiente:
Batch Layer con 4 capas: Landing, Raw, Staging (Delta) y Service (Delta). Seguridad para los usuarios del Active Directory mediante permisos RBAC (asignación de roles) y permisos ACL (permisos de lectura, escritura y ejecución sobre las carpetas del ADLS).
Workspace de Databricks utilizado tanto para la ejecución de la ingesta dentro de las capas Delta del ADLS cómo para la explotación de los datos vía PowerBI y Notebook. Contiene accesos al ADLS (vía mount points), capa SQL con las tablas Delta y diferentes tipos de Clúster para el acceso a los datos.
Mount points del Workspace de Databricks con los accesos al ADLS. Estos mount point son necesarios actualmente para la ejecución del acelerador de ingesta:
Databricks SQL: Contienen las siguientes BBDD:
Gestión de permisos
Creación de grupos de usuarios dentro de Databricks con funcionalidades y accesos comunes.
Control de permisos sobre los grupos de usuarios generados dónde se otorgarán los permisos de estos grupos sobre los diferentes objetos de SQL (BBDD, tablas, vistas …)
Clusters: 2 tipos de Clúster disponibles:
Mantenemos los mount points vía SP, porque no son accesibles por parte de los usuarios, únicamente se utilizan para los componentes de desarrollo (ADF, Framework de ingesta).
En caso de que hubiese nuevos requisitos que requirieran otro tipo de clústeres con diferentes accesos, sería posible asociar los grupos de usuarios al clúster o clústeres que pueden utilizar, de forma que se pudieran dar diferentes tipos de acceso a los datos.
Dentro de la solución inicial, no hemos valorado utilizar los Sql Endpoints por las razones ya indicadas.
Hay que tener en cuenta que la solución adoptada es un primer acercamiento para la puesta en marcha, con la inclusión de unos pocos casos de uso de partida. Será necesario ampliar este análisis, para la inclusión de nuevas tipologías de casos de uso, y dominios funcionales que terminen conformando una plataforma.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
