Algo que cada departamento de IT o responsables de tecnología se pregunta cuando hay que incorporar nuevos servicios o software en una empresa esta muy cercano a la seguridad. De ellos es el gran interés por administrar usuarios, roles y patrones para que las responsabilidades de quienes ingresan este acorde a lo que les corresponde.
Con la creciente popularidad de Microsoft Fabric y sus distintas experiencias o servicios de desarrollo que tiene la suite, podemos marearnos en como se maneja. Por esta y otras razones, ladataweb trae un artículo para mostrar como esta organizada la seguridad en Fabric.
En caso que aún no estés familiarizado con Microsoft Fabric, te invito a dar una vuelta por este artículo introductorio.
Para comenzar no esta demás mencionar algunas aclaraciones. Fabric es un software as a service que abarca la experiencia de desarrollo end to end de un proyecto de datos, desde Gobernanza hasta un experimento de Ciencia de Datos. Esta integrado con el ecosistema de Microsoft en lo que respecta a 365 o Azure en diversos ejes.
Cuando un usuario quiere acceder a Fabric existen tres capas de seguridad que necesita atravesar:
- Ingreso con Microsoft Entra ID: como un SaaS de la misma compañía, el acceso a la plataforma para lectura y escritura se encuentra bajo el servicio de administración de identidades de Azure.
- Acceso a Fabric: luego de validar la existencia de la cuenta corporativa en el tenant, comprueba si el usuario puede acceder al servicio.
- Seguridad de datos: existen distintos bloques de creación en la experiencia de Fabric y en este nivel vamos a enfocarnos puesto que refiere al fino de hasta donde puede llegar el usuario en el servicio.
Microsoft Fabric se encuentra organizado bajo áreas de trabajo. Éstas áreas son un espacio de trabajo colaborativo que permite alojar distintos ítems (reportes, pipelines, experimentos) de las experiencias/servicios (PowerBi, Data Factory, Data Science, etc). De esa forma, distintos profesionales de datos pueden trabajar en conjunto en un espacio. Así mismo, estos espacios rigen permisos y usuarios. Veamos gráficamente como se ajustarán los permisos
Bajo un Tenant disponemos de N áreas de trabajo que así mismo tienen N ítems creados por los servicios disponibles que alojan su información en el almacenamiento único OneLake.
NOTA: recordemos que un Tenant puede tener permitido o bloqueado ciertas acciones puntuales para grupos de seguridad de usuarios de manera adicional para la seguridad de la organización. Por ejemplo: exportar tableros a excel o permitir crear un ítem en preview.
La capa de seguridad de datos se encuentra subdivida en tres niveles:
- Roles de área de trabajo
- Permisos de ítem o elemento
- Permisos de granular interno del ítem
Roles de área
Las áreas permiten agregar usuarios para que puedan interactuar y trabajar de manera colaborativa. Sin embargo, hay cuatro roles que en definitiva puede tomar un usuario que participa de este espacio.
- Admin: permisos para editar todos los ítems, compartirlos y manejar el área.
- Member: permisos para editar todos los ítems, compartirlos.
- Contribuidor: permisos para editar todos los ítems
- Visor: permiso para ver todos los items.
NOTA: Información de roles totalmente detallada aquí: https://learn.microsoft.com/es-es/power-bi/collaborate-share/service-roles-new-workspaces
Como podrán apreciar. Si un usuario forma parte del área de trabajo puede ver todos los ítems creados sin excepción. Para aquellos casos que necesitamos prender un permiso para un específico ítem es que nace el permiso que sigue.
Permiso de ítem o elemento
La mayoría de las creaciones dentro de un área de trabajo puede ser compartida de forma individual. Si nuestra área contiene un lakehouse, un modelo semántico, un informe y un notebook. Tranquilamente podríamos compartir a un data engineer el lakehouse y notebook mientras que un Bi o analista de datos tenga compartido el lakehouse, modelo semántico e informe. Finalmente, un usuario final solo compartirle el informe.
Esta claro que cuando trabajamos con muchos involucrados intentamos generar grupos para evitar compartir de manera tan directa por usuario, pero la posibilidad existe:
Permisos granulares
No siempre los desarrolladores deberían tener permisos totales. En los proyectos de datos muchas veces existe información sensible o simplemente de otra área. Así mismo hay distintos usuarios finales que no debería poder leer ciertos datos. Para los detalles finos dentro de los datos existen los permisos granulares.
Éstos permisos son configuraciones especiales de algunos ítems puntuales. De momento, aquellos con almacenamiento, es decir, lakehouse, warehouse y modelos semánticos. La idea es que dentro del mismo recurso podamos delimitar pautas o reglas.
- Lakehouse: crear roles para asignar a usuarios. Dichos roles son delimitados para visualizar, ejecutar consultas SQL/Spark o compartir específicas carpetas o archivos.
- Warehouse: también cuentan con seguridad a nivel de filas
- Modelos semánticos: al estar constituido por tablas, se vuelve crítico su seguridad dentro de esos objetos. Dando pie a seguridad a nivel de filas (filtrar filas para algún usuario) o seguridad a nivel objeto (restringir columnas o tablas).
- SQL Endpoint: tanto lakehouse como warehouse tienen por defecto este servicio. El mismo nos brinda configuraciones de seguridad de datos tradicionales de SQL como lo son seguridad a nivel de tablas, de filas y enmascarado de datos.
En definitiva, Fabric nos brinda puertas a una flexible y profunda seguridad que nos ayude a mantener las responsabilidades adecuadas para el rol o perfil de desarrollador que corresponda. No olvidemos las configuraciones del Tenant que pueden tener ciertas configuraciones adicionales que den permiso o negación a acciones concretas de grupos de usuarios. Pueden leer más detalle de ellas aquí: https://learn.microsoft.com/es-es/fabric/admin/tenant-settings-index