Integración de la seguridad de Direct Lake

La seguridad de Direct Lake garantiza que solo los usuarios autorizados puedan consultar tablas Delta en OneLake. Puede administrar los permisos de acceso a datos a través de roles de área de trabajo. Los colaboradores, miembros y administradores del área de trabajo pueden leer datos en OneLake. También puede conceder acceso a los datos de OneLake a través de permisos de proceso y de nivel de elemento. La tercera opción es aprovechar la seguridad de OneLake para aplicar la seguridad basada en roles granular en todos los motores de proceso de Fabric. En este artículo se explica cómo alinear los modelos de permisos, elegir inicio de sesión único (SSO) o identidades fijas, y aprovechar la seguridad de nivel de objeto (OLS) y la seguridad de nivel de fila (RLS). Obtenga más información en Introducción a la seguridad de OneLake.

Conceptos clave y terminología

En este artículo se da por supuesto que está familiarizado con estos conceptos:

• Direct Lake usa expresiones M compartidas en los metadatos del modelo semántico para hacer referencia a orígenes de datos mediante funciones de acceso a datos de Power Query: AzureStorage.DataLake para Direct Lake en OneLake y Sql.Database para Direct Lake en puntos de conexión de SQL. Sin embargo, Direct Lake no usa estas funciones para leer las tablas delta de origen. Lee las tablas delta directamente a través de las API de OneLake.
• Para asegurarse de que solo los usuarios autorizados consultan los datos, Direct Lake comprueba los permisos de acceso a los datos de la identidad efectiva. La identidad efectiva depende de la configuración de conexión de datos. De forma predeterminada, Direct Lake usa SSO (Microsoft Entra ID) y usa la identidad del usuario actual que consulta el modelo semántico. También puede enlazar un modelo de Direct Lake a una conexión explícita en la nube para proporcionar una identidad fija.
• Si concede permisos de acceso a datos a través de roles de área de trabajo, solo los miembros del rol Colaboradores (o superior) pueden leer datos en OneLake. Sin embargo, los visualizadores del espacio de trabajo no tienen permiso de lectura en OneLake. Los visores y usuarios que no son miembros de un rol de área de trabajo pueden obtener acceso de lectura a través de una combinación de permisos de elemento, permisos de proceso o roles de seguridad de OneLake.
• La seguridad de OneLake permite a los miembros de los roles Administrador del área de trabajo y Miembro del área de trabajo definir una seguridad pormenorizada basada en roles para los usuarios en el rol de Visor. Especifique las tablas a las que un visor o usuario con permiso de lectura explícito puede acceder y excluir filas o columnas específicas. Para más información sobre los roles de seguridad de OneLake, consulte Seguridad de tabla en OneLake, Seguridad de nivel de columna en OneLake y RLS en OneLake.

Configuración de conexión

Configure las conexiones de datos para un modelo de Direct Lake de la misma manera que otros tipos de modelos semánticos. Consulte Conexión a orígenes de datos en la nube en el servicio Power BI para obtener más información.

Dado que Direct Lake solo se conecta a orígenes de datos de Fabric, la configuración predeterminada de SSO (Microsoft Entra ID) normalmente funciona, por lo que no es necesario enlazar modelos semánticos a conexiones de datos explícitas. Este enfoque reduce la complejidad de la configuración y reduce la sobrecarga de administración.

Con SSO (Microsoft Entra ID), Direct Lake comprueba que el usuario actual que consulta el modelo semántico tiene acceso de lectura a los datos. Solo los usuarios con acceso de lectura pueden consultar los datos. En la siguiente captura de pantalla se muestra un modelo Direct Lake utilizando la configuración predeterminada de SSO.

Cuando se usa una conexión de datos explícita con una identidad fija en lugar de SSO, Direct Lake no requiere que todos los usuarios tengan permiso de lectura en los datos subyacentes. Si el inicio de sesión único de Microsoft Entra permanece deshabilitado en la conexión de datos, los permisos de la identidad fija determinan a qué datos puede acceder Direct Lake.

Requisitos de autenticación

Los modelos de Direct Lake usan la autenticación de Microsoft Entra ID. En la configuración de conexión de datos, elija OAuth 2.0, Principal de servicio o Identidad de área de trabajo como método de autenticación. Otros métodos, como la autenticación de clave o SAS, pueden aparecer en la interfaz de usuario de configuración, pero no se admiten para los modelos de Direct Lake.

Requisitos de permisos

Los requisitos de permisos difieren entre Direct Lake en puntos de conexión de SQL y Direct Lake en OneLake. Esta diferencia existe porque Direct Lake en endpoints SQL depende del endpoint SQL Analytics de la fuente de datos objetivo, mientras que Direct Lake en OneLake utiliza las APIs de OneLake para comprobaciones de permisos.

Direct Lake en puntos de conexión de SQL

Direct Lake en los puntos de conexión de SQL comprueba los permisos a través del punto de conexión de análisis de SQL para verificar si la identidad efectiva que intenta acceder a los datos dispone de los permisos necesarios. La identidad efectiva no necesita permiso para leer las tablas Delta directamente en OneLake. Solo necesita acceso de lectura al elemento Fabric, como un lakehouse, y permiso SELECT en una tabla a través de su endpoint de analítica SQL. Fabric concede al modelo semántico los permisos necesarios para leer las tablas Delta y los archivos Parquet relacionados y cargar los datos de las columnas en la memoria. El modelo semántico puede leer regularmente el endpoint de analítica SQL para comprobar qué datos puede acceder el usuario que consulta (o la identidad fija).

Direct Lake en OneLake

Direct Lake en OneLake no utiliza un endpoint de analítica SQL para comprobar permisos. Utiliza la seguridad de OneLake. Cuando la seguridad de OneLake está activada, Direct Lake en OneLake utiliza el usuario actual (o una identidad fija) para determinar los roles de seguridad de OneLake y aplicar OLS y RLS en el elemento de Fabric de destino. Si la seguridad de OneLake no está activada, Direct Lake en OneLake necesita que la identidad efectiva tenga permisos Read y ReadAll sobre el elemento Fabric objetivo para acceder a sus tablas Delta en OneLake. Para más información sobre los permisos de Leer y Leer Todo, consulte Compartir elementos y establecer permisos a nivel de elemento.

Usuarios de Direct Lake

En los escenarios siguientes se enumeran los requisitos mínimos de permisos.

Para obtener más información, consulte Permisos de modelo semántico.

Propietarios de Direct Lake

Además de la identidad efectiva (usuario actual o identidad fija), Direct Lake requiere que el propietario del modelo semántico tenga acceso de lectura a las tablas fuente para que Direct Lake pueda enmarcar el modelo semántico como parte de la actualización de datos. Independientemente de quién actualice un modelo de Direct Lake, Direct Lake comprueba el permiso del propietario para asegurarse de que el modelo puede acceder a los datos. Los requisitos de permisos de acceso a datos del propietario son los mismos que para los usuarios que consultan el modelo.

Si el propietario del modelo semántico no tiene los permisos de acceso a datos necesarios, Direct Lake genera el siguiente error durante el marco: We cannot refresh this semantic model because one or multiple source tables either do not exist or access was denied. Please contact a data source admin to verify that the tables exist and ensure that the owner of this semantic model does have read access to these tables. Some restricted tables including fully restricted and partially restricted (indicating column constraints): '\<list of tables\>'.

Accesos directos a tablas de origen

Los atajos son objetos OneLake que añades a una casa de lago Fabric u otro objeto de Fabric para señalar ubicaciones de almacenamiento internas o externas. En un modelo Direct Lake, las tablas Delta añadidas mediante atajos aparecen como nativas en el elemento Fabric conectado porque los accesos directos son transparentes cuando accedes a los datos a través de la API de OneLake.

Cuando accedes a los atajos mediante Direct Lake por endpoints de SQL, Direct Lake primero valida que la identidad efectiva (usuario actual o identidad fija) pueda acceder a la tabla en el origen de datos del modelo semántico. Para accesos directos internos, tras pasar esa comprobación, Direct Lake utiliza la identidad del propietario de la fuente de datos para leer la tabla Delta a través del acceso directo en el elemento Fabric de la tabla. El propietario del origen de datos debe tener permiso de acceso en la ubicación de OneLake de destino. Para los accesos directos externos, el propietario del origen de datos también necesita el permiso para usar en la conexión en la nube al sistema externo que hospeda la tabla Delta. Para más información, consulte Accesos directos de OneLake.

Direct Lake sobre OneLake tiene requisitos de permisos diferentes porque el endpoint de SQL Analytics no está implicado. Cuando un usuario accede a los datos a través de un acceso directo interno a otra ubicación de OneLake, la identidad efectiva (usuario actual o identidad fija) debe tener permiso en la ubicación de destino. La identidad efectiva debe ser colaborador (o superior), tener permisos Read y ReadAll, o estar en un rol de seguridad de OneLake que conceda acceso de lectura .

Seguridad de nivel de objeto (OLS) y seguridad de nivel de fila (RLS)

Tanto los modelos de seguridad OneLake como los de Direct Lake soportan OLS y RLS. OLS permite a los propietarios de elementos y administradores asegurar tablas o columnas específicas. RLS se puede usar para restringir el acceso a los datos en el nivel de fila en función de los filtros. Puedes definir OLS y RLS en la seguridad de OneLake, en un modelo Direct Lake o en ambas ubicaciones.

Direct Lake en OneLake OLS/RLS con OneLake Security OLS/RLS

Direct Lake en OneLake evalúa el acceso a los objetos protegidos mediante OLS/RLS determinando los roles de seguridad de OneLake de la identidad efectiva y aplicando las reglas OLS/RLS definidas. Los roles de seguridad de OneLake se gestionan igual que los roles de Direct Lake. Si la identidad efectiva pertenece a múltiples roles en la seguridad de OneLake y Direct Lake, Direct Lake primero une los roles de seguridad de OneLake y luego intersecta el resultado con los roles de Direct Lake.

Esta tabla enumera casos habituales de solución de problemas provocados por conflictos entre la seguridad de OneLake y las reglas de Direct Lake.

Diferencias de ámbito de OLS/RLS

La aplicación de OLS y RLS en la seguridad de OneLake aplica las reglas en todos los motores de cómputo y garantiza un control de acceso unificado para los usuarios. Esto significa que, independientemente del motor de cómputo —lakehouse, almacén, modelo semántico u otro elemento— las reglas de seguridad de OneLake controlan el acceso a los datos del usuario. En cambio, OLS/RLS definido dentro de un modelo semántico de Direct Lake solo se aplica dentro del ámbito de ese modelo. Otros motores de proceso no aplican estas reglas de seguridad de Direct Lake, lo que puede generar resultados diferentes cuando los usuarios acceden a los datos a través de otras rutas de acceso.

OLS de OneLake y metadatos de modelo semántico

Los metadatos del modelo semántico incluyen definiciones de tablas, columnas, relaciones y otros elementos de esquema. Los usuarios con permisos de compilación o superior pueden ver los metadatos del modelo a través de XML for Analysis (XMLA) y las API REST. Para obtener más información, consulte Permisos de modelo semántico.

Para proteger los nombres sensibles de tablas y columnas en OneLake con OneLake OLS, recuerda que la seguridad de OneLake solo se aplica a los miembros del rol de Visor del espacio de trabajo. OneLake OLS no impide que los miembros del rol de espacio de trabajo Contribuidor (o superior) descubran tablas o columnas seguras porque ya tienen permiso de escritura para todos los elementos del espacio de trabajo. Los miembros del rol Visor con permisos de compilación o superior en un modelo de Direct Lake pueden detectar información confidencial del esquema a través de los metadatos del modelo semántico. Estos visores con privilegios más elevados todavía no tienen acceso a datos, pero pueden ver que existen las tablas y columnas protegidas.

Un modelo Direct Lake podría existir en el mismo espacio de trabajo que el elemento de origen o en un espacio de trabajo separado. Conceda a un visor en el mismo espacio de trabajo build (o superior) acceso a un modelo de Direct Lake mediante permisos de elemento. En un área de trabajo independiente, un usuario podría ser colaborador (o superior) o tener permisos de elemento de compilación (o superior) para acceder a los metadatos del modelo.

Integración de OneLake OLS y Git

La integración de Git permite a los desarrolladores integrar sus procesos de administración del ciclo de vida de las aplicaciones (ALM) en la plataforma Fabric. El repositorio Git preserva la estructura del espacio de trabajo, incluyendo todos los elementos soportados. Los desarrolladores tienen visibilidad completa de los metadatos de todos sus elementos en el repositorio de Git. Los metadatos del modelo de Direct Lake les permiten ver que existen tablas o columnas protegidas incluso si no tienen acceso al origen de datos de destino en otra área de trabajo. Para obtener más información, consulte ¿Qué es la integración de Git de Microsoft Fabric?

Cómo se evalúan las consultas en Direct Lake en SQL

La razón para desarrollar modelos semánticos de Direct Lake es lograr consultas de alto rendimiento en grandes volúmenes de datos en OneLake. Por lo tanto, debe esforzarse por diseñar una solución que maximice las posibilidades de realizar consultas en memoria.

Los siguientes pasos aproximan cómo se evalúan las consultas SQL en Direct Lake (y si fallan). Las ventajas del modo de almacenamiento de Direct Lake solo son posibles cuando se logra el quinto paso.

1. Si la consulta contiene cualquier tabla o columna restringida por olS del modelo semántico, se devuelve un resultado de error (los objetos visuales de informe no se pueden representar).
2. Si la consulta contiene cualquier columna restringida por CLS del punto de conexión de SQL Analytics (o se deniega la tabla), se devuelve un resultado de error (los objetos visuales de informe no se pueden representar).
   1. Si la conexión en la nube usa SSO (valor predeterminado), CLS viene determinado por el nivel de acceso del consumidor del informe.
   2. Si la conexión en la nube usa una identidad fija, CLS viene determinada por el nivel de acceso de la identidad fija.
3. Si el modelo semántico utiliza Direct Lake en los puntos de conexión de SQL y la consulta contiene alguna tabla en el punto de conexión de SQL Analytics que aplica RLS o se utiliza una vista, la consulta se revierte al modo DirectQuery.
   1. Si la conexión en la nube usa SSO (valor predeterminado), RLS viene determinado por el nivel de acceso del consumidor del informe.
   2. Si la conexión en la nube usa una identidad fija, RLS viene determinada por el nivel de acceso de la identidad fija.
4. Si la consulta supera los límites de protección de la capacidad, vuelve al modo DirectQuery.
5. De lo contrario, la consulta se satisface desde la memoria caché. Los datos de columna se cargan en la memoria cuando sea necesario.

Opciones de reglas de acceso a datos

Puede configurar reglas de acceso a datos en:

• Modelo semántico.
• Punto de conexión de SQL Analytics (solo Direct Lake en puntos de conexión de SQL).
• Seguridad de OneLake.

Reglas del modelo semántico

Si debes hacer cumplir las reglas de acceso a datos, hazlo en OneLake Security para que las reglas se apliquen en todos los motores de cómputo y garanticen un control de acceso unificado para los usuarios. Use el modelo semántico RLS o OLS cuando los consumidores de informes no tienen permiso para consultar lakehouse o warehouse y la conexión en la nube usa una identidad fija en lugar de SSO. SSO implica que los usuarios finales pueden acceder directamente al origen de datos y, por lo tanto, omitir las reglas de seguridad en el modelo semántico.

Reglas en varias capas

Puedes aplicar reglas de acceso a datos en todas las capas. Sin embargo, este enfoque implica una sobrecarga adicional de complejidad y administración. En este caso, utiliza una identidad fija para la conexión a la nube en lugar de SSO.

Comparación de las opciones de reglas de acceso a datos

En la tabla siguiente se comparan las opciones de configuración de acceso a datos para Direct Lake en puntos de conexión de SQL y Direct Lake en OneLake.

Consideraciones y limitaciones

Tenga en cuenta estas limitaciones de seguridad de Direct Lake.

• Asigna a los visualizadores de espacio de trabajo roles de seguridad OneLake que concedan acceso de lectura a los elementos Fabric de origen. Si un elemento de origen tiene accesos directos a otros elementos de Fabric, el usuario también necesita permiso de lectura para el elemento de Fabric de destino de cada acceso directo.
• Utiliza una identidad fija para aislar a los usuarios con respecto a un elemento de origen de Fabric. Enlace el modelo de Direct Lake a una conexión en la nube. Mantenga SSO deshabilitado en la conexión en la nube para usar identidad fija para las actualizaciones y las consultas.
• Los modelos semánticos de Direct Lake que dependen de la seguridad de Fabric OneLake sobre el elemento fuente no soportan operaciones de respaldo.
• Las relaciones bidireccionales no están soportadas en un modelo Direct Lake si el elemento Fabric de origen depende de OneLake Security RLS.
• La seguridad de OneLake no admite definiciones dinámicas ni configuraciones de roles complejas, como combinar varios roles OLS y RLS en tablas relacionadas.
• Consolide los permisos RLS y OLS de seguridad de OneLake en un rol por usuario en lugar de asignar varios roles.
• Si la configuración de seguridad de OneLake cambia, por ejemplo debido a cambios en accesos directos en el elemento objetivo, actualiza Direct Lake en modelos OneLake que acceden a ese elemento. Debe actualizar los modelos manualmente o mediante las API de actualización.
• Si un Lakehouse tiene seguridad OneLake:
  • El punto de conexión de SQL Analytics está, de forma predeterminada, asociado de forma fija al propietario de Lakehouse, por lo que la seguridad de OneLake para el punto de conexión de SQL Analytics es la misma que la del propietario (sin limitaciones). Direct Lake en SQL permanece usando Direct Lake, a menos que se agreguen roles de acceso pormenorizados de SQL adicionales.
  • El punto de conexión de SQL Analytics se puede cambiar a SSO. Cuando esto sucede, los roles de seguridad de OneLake se agregan como reglas de control de acceso pormenorizadas de SQL y el usuario no puede editarlos directamente en el punto de conexión de SQL Analytics. En este momento, Direct Lake en SQL vuelve a DirectQuery 100% del tiempo.