Securización del acceso al dato desde Azure Databricks

1-Introducción

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:

  • Landing: capa en la que se encuentran, de manera temporal, los datos de origen. Sirve para aplicar determinados preprocesamientos o filtrados, que pueden ser necesarios para cumplir con determinadas políticas y/o normativas entorno a los datos.
  • Raw (bronce layer): datos “en crudo” e historificados.
  • Staging (silver layer): datos a los que se les han aplicado una serie de reglas técnicas, con el fin de estandarizarlos y enriquecerlos. Se encuentran en formato Delta Lake (luego veremos qué es).
  • Service (gold layer): capa consolidada de información, preparada para el consumo y explotación. También en formato Delta, y además se genera una capa adicional Business, no persistida, a partir de esta, que contiene vistas sobre los datos almacenados en staging y Service, orientada al autoconsumo por parte de analistas, y equipos especializados en la explotación de la información.

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.

2-Conceptos Generales

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.

Workspace Databricks

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:

  • Notebooks dónde poder ejecutar distintos procesos en Python, R, Scala o Sql.
  • Conexión con las cuentas de almacenamiento, ya sea de forma directa (vía abfs) o a través de mount points disponibles en el File System de Databricks (dbfs).
  • Configuración de diferentes tipos de Clusters con los que acceder a los datos y ejecutar procesos.
  • Metastore de Hive en el que guardar las estructuras y metainformación tipo SQL, de los datos almacenados en el ADLS.
  • Creación de Tablas Delta a partir de los ficheros generados en la cuenta de almacenamiento.
  • Configuración de permisos para grupos y usuarios, tanto para el acceso y control de los diferentes clusters y notebooks, como para el acceso a los diferentes objetos SQL generados en Hive.

Databricks File System (dbfs)

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.

Mount points

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

Databricks SQL (Hive)

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

Clusters Databricks

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:

  • Credential Passthrough: lo vimos en los puntos de montaje. El paso a través de credenciales permite auteticarnos automáticamente en ADLS, desde clústeres de Azure Databricks con la identidad que usa para iniciar sesión en Azure Databricks.
  • Table Access Control: El control de acceso a tablas le permite conceder y revocar mediante programación el acceso a sus datos desde Python y SQL. Esta opción deshabilita el acceso mediante dbfs, únicamente permite el acceso a objetos SQL.

Tipos de Clúster:

  • Clúster Standard: Este tipo de Clusters están enfocados para uso específico de un usuario. Los clústeres estándar pueden ejecutar cargas de trabajo desarrolladas en cualquier lenguaje: Python, SQL, R y Scala. Este tipo de clúster admite el paso de credenciales, pero obligatoriamente se ha de configurar para un único usuario (El clúster ejecuta las cargas usando las credenciales del usuario configurado). Este tipo de clúster no tiene la opción Table Access control.
cluster
  • Clúster High Concurrency: Las principales ventajas de los clústeres de alta concurrencia son que proporcionan un uso compartido que maximiza el uso de los recursos del clúster, y proporciona latencias de consulta muy bajas. Pueden ejecutar cargas de trabajo desarrolladas SQL, Python y R. Este tipo de clúster admite el paso de credenciales para varios usuarios, es decir todos los usuarios que se conecten a este clúster estarían accediendo mediante sus credenciales de AD. Este tipo de clúster admite Table Access Control.

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

Grupos y usuarios Databricks

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:

  • A nivel de Workspace (usuarios admin) Configuración de capacidades del workspace: Acceso, almacenamiento, Jobs … Por ejemplo, aquí se activa la posibilidad de activar Table Access control a nivel de Workspace
  • A nivel de Clúster: Permite indicar que usuario o grupos de usuarios pueden gestionar el clúster, quienes pueden usarlo y quienes pueden reiniciarlo
  • A nivel de Sql (Table Access control): Permite otorgar o denegar acceso a objetos SQL (BBDD, tablas, vistas …) a los usuarios o grupos de usuarios del Workspace.

3-Pruebas Realizadas

Para ver los distintos comportamientos de las diferentes configuraciones, hemos realizado una serie de pruebas:

tabla pruebas

Conclusiones:

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.

4-Solución adoptada

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:

  • Bin: necesario para la ejecución desde ADF al framework de ingesta (acceso a librerías y ficheros de configuración).
  • Raw/Staging/Service: necesarios para acceso a las rutas del ADL desde el framework de ingesta para la carga de tablas Delta.

Databricks SQL: Contienen las siguientes BBDD:

  • Stage: Vinculado con la capa staging del ADL. Contiene las tablas Delta en formato SQL de los datos de staging.
  • Service: Vinculado con la capa service del ADL. Contiene las tablas Delta en formato SQL de los datos de service.
  • Business: Capa de vistas sobre las tablas de la BBDD Service

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:

  • Creación de clusters efímeros de Databricks desde ADF para la ejecución del framework de ingesta. Clusters de tipo Standard que acceden a los mount point generados anteriormente. No accesible por parte de los usuarios.
  • Uno o varios Clúster High Concurrency con Table Access Control activado. A este clúster se conectarán el usuario de servicio de PowerBi y los analistas y datascientist que acceden a los datos vía Notebooks. Al acceder a este tipo de clúster, los usuarios sólo pueden acceder a los objetos SQL para los que tienen permisos (sin acceso a dbfs)

Comentarios

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.

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA