Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los accesos directos de OneLake sirven como punteros a los datos que residen en varias cuentas de almacenamiento, ya sea dentro de OneLake o en sistemas externos como Azure Data Lake Storage (ADLS). En este artículo se explican los permisos necesarios para crear accesos directos y acceder a los datos mediante ellos.
Para garantizar la claridad en torno a los componentes de un acceso directo, en este artículo se usan los términos siguientes:
- Ruta de acceso de destino: ubicación a la que apunta un acceso directo.
- Ruta de acceso directo: ubicación en la que aparece el acceso directo.
Crear y eliminar accesos directos
Para crear un acceso directo, necesitas permiso de escritura en el elemento de Fabric en el que crees el acceso directo. Además, se necesita permiso de lectura para los datos a los que apunta el acceso directo. Los accesos directos a orígenes externos pueden requerir determinados permisos en el sistema externo. El artículo ¿Qué son los accesos directos? tiene la lista completa de los tipos de acceso directo y los permisos necesarios.
| Capacidad | Permiso en la ruta de acceso directo | Permisos en la ruta de acceso de destino |
|---|---|---|
| Crear un acceso directo | Permiso de escritura en el elemento o seguridad ReadWrite de OneLake | Seguridad de OneLake Más información1 |
| Eliminar un acceso directo | Permiso de escritura en el elemento o seguridad ReadWrite de OneLake | N/D |
1 Para los elementos que aún no son compatibles con la seguridad de OneLake, este permiso es el permiso ReadAll del elemento.
Acceso a atajos
Una combinación de los permisos en la ruta del acceso directo y la ruta de acceso de destino determina los permisos para los accesos directos. Cuando un usuario accede a un acceso directo, se aplica el permiso más restrictivo de las dos ubicaciones. Por lo tanto, un usuario que tiene permisos de lectura y escritura en el lakehouse, pero solo permisos de lectura en la ruta de destino, no puede escribir en la ruta de destino. Del mismo modo, un usuario que solo tiene permisos de lectura en lakehouse, pero permisos de lectura y escritura en la ruta de acceso de destino tampoco puede escribir en la ruta de acceso de destino.
En esta tabla se muestran los permisos necesarios para cada acción de acceso directo.
| Capacidad | Permiso en la ruta de acceso directo | Permisos en la ruta de acceso de destino |
|---|---|---|
| Leer el contenido del archivo o de la carpeta a los que apunta el acceso directo | Seguridad de OneLake Más información1 | Seguridad de lectura de OneLake1, 2 |
| Escribir a la ubicación de destino del acceso directo | Permiso de escritura en el elemento o seguridad ReadWrite de OneLake | Permiso de escritura en el elemento o seguridad ReadWrite de OneLake |
1 Para los elementos que aún no son compatibles con la seguridad de OneLake, este permiso es el permiso ReadAll del elemento.
Importante
2Excepción al paso de identidad: mientras que la seguridad de OneLake normalmente pasa a través de la identidad del usuario que realiza la llamada para aplicar permisos, determinados motores de consulta funcionan de forma diferente. Al acceder a los datos de acceso directo a través de modelos semánticos de Power BI usando DirectLake sobre motores SQL o T-SQL configurados para el modo de identidad delegada, estos motores no transmiten la identidad del usuario que realiza la llamada al objetivo del acceso directo. En su lugar, usan la identidad del propietario del elemento para acceder a los datos y, a continuación, aplican roles de seguridad de OneLake para filtrar lo que el usuario que llama puede ver.
Esta condición significa:
- Se accede al destino de acceso directo mediante los permisos del propietario del elemento (no los del usuario final).
- Los roles de seguridad de OneLake siguen determinando qué datos puede leer el usuario final
- Se omiten los permisos configurados directamente en la ruta de acceso directo de destino para el usuario final.
Seguridad de OneLake
La seguridad de OneLake permite aplicar el control de acceso basado en rol (RBAC) a los datos almacenados en OneLake. Puede definir roles de seguridad que concedan acceso de lectura a tablas y carpetas específicas dentro de un elemento de Fabric y asignarlos a usuarios o grupos. Los permisos de acceso determinan qué pueden hacer los usuarios en todos los motores de Fabric, lo que garantiza un control de acceso coherente.
Los usuarios en los roles de Administrador, Miembro y Colaborador tienen acceso completo para leer datos desde un acceso directo. Para crear o actualizar un acceso directo, también necesitan acceso de lectura a la ruta de destino.
Los usuarios en el rol Visor, o los usuarios con permisos de lectura de ítems, tienen acceso determinado por sus roles de seguridad en OneLake. Para realizar operaciones de acceso directo, estos usuarios necesitan el permiso de seguridad correspondiente de OneLake además del permiso de lectura de Fabric.
La siguiente tabla muestra los permisos combinados requeridos para cada operación de acceso directo:
| Operación de acceso rápido | Permiso en la ruta de acceso directo | Permisos en la ruta de acceso de destino |
|---|---|---|
| Crear | Fabric Read más OneLake Security ReadWrite | Consulta de seguridad de OneLake |
| Lectura (comandos GET/LIST) | Fabric Read más OneLake Security Read | N/D |
| Actualizar | Fabric Read más OneLake Security ReadWrite | Lectura de seguridad de OneLake (en el nuevo destino) |
| Eliminar | Fabric Read más OneLake Security ReadWrite | N/D |
Para más información sobre el modelo de control de acceso con accesos directos, véase Modelo de control de acceso de datos en OneLake.
Modelos de autenticación rápida
Los accesos directos de OneLake usan dos modelos de autenticación: passthrough y delegated. El modelo depende del tipo de acceso directo.
| Tipo de acceso directo | Modelo de autenticación | Detalles |
|---|---|---|
| De OneLake a OneLake con el mismo inquilino | Transferencia o delegado | Passthrough es el valor predeterminado. Para usar autenticación delegada en su lugar, elige Identidad delegada al crear el acceso. |
| De un Lago con inquilino cruzado a OneLake | Solo delegado | Configura una cuenta organizativa o un principal de servicio en el tenant del productor al crear el acceso directo entre inquilinos. |
| Externo (multinube) | Solo delegado | Los usuarios pueden acceder a datos externos sin acceso directo al sistema externo. Configure la seguridad de OneLake en el acceso directo para controlar a qué datos se puede acceder en el sistema externo. |
Autenticación de paso a través
En el modelo de paso a través, el acceso directo accede a los datos de la ubicación de destino al pasar la identidad del usuario al sistema de destino. Cualquier usuario que acceda al acceso directo solo puede ver los datos a los que tienen acceso en el destino. El sistema de origen conserva el control total sobre sus datos y no es necesario replicar ni volver a definir los controles de acceso.
Autenticación delegada
En el modelo delegado, el acceso directo accede a los datos mediante una credencial intermedia, como la identidad de otro usuario, una entidad de servicio o una clave de cuenta. Los accesos directos delegados permiten separar o "delegar" la administración de permisos a otro equipo o usuario de nivel inferior para administrar. Todos los accesos directos delegados en OneLake pueden tener roles de seguridad de OneLake asociados a ellos.
Utiliza autenticación delegada cuando el comportamiento de paso por defecto no coincide con el patrón de acceso que quieres para tus datos. Por ejemplo, un atajo delegado puede usar una identidad de conexión fija que representa una unidad de negocio en lugar de exigir que cada usuario downstream tenga acceso a los datos fuente. La unidad de negocio puede gestionar el acceso de seguridad OneLake para sus usuarios respetando los controles de seguridad aplicados a la identidad de conexión.
Los accesos directos a sistemas externos como Amazon S3 o Google Cloud Storage siempre usan la autenticación delegada. Los accesos directos a destinos internos de OneLake pueden usar la autenticación delegada si está configurada en el momento de la creación del acceso directo.
Accesos directos delegados de OneLake
Los accesos directos delegados de OneLake utilizan una identidad de conexión configurada en lugar de la identidad del usuario con sesión iniciada. Al acceder a un acceso directo delegado, el usuario que realiza la llamada ve la intersección de su seguridad y la seguridad que se aplica a la identidad delegada. En la tabla siguiente se describen escenarios de ejemplo.
Para atajos OneLake con el mismo inquilino, la autenticación delegada es opcional. Si no lo seleccionas, el acceso directo usa autenticación de paso y corriente. Los atajos OneLake entre inquilinos siempre utilizan autenticación delegada. La identidad de conexión configurada necesita acceso a los datos de destino. Para cambiar un acceso directo existente entre la autenticación transferida y delegada, elimine y vuelva a crear el acceso directo con el método de autenticación deseado.
| Permiso para la ruta de acceso directo (usuario) | Permiso de la ruta de destino (productor) | Acceso resultante |
|---|---|---|
| Acceso total | Acceso total | Acceso total |
| Acceso total | CLS: solo columnas C1, C2 | CLS: solo columnas C1, C2 |
| CLS: solo columna C1 | CLS: solo columnas C1, C2 | CLS: solo columna C1 |
Las siguientes consideraciones de seguridad se aplican a los accesos directos delegados:
- Un usuario solo puede pertenecer a un único rol de seguridad de OneLake con CLS en el lado del consumidor si el lado del productor también tiene RLS.
- La seguridad a nivel de columna (CLS) está soportada tanto para el productor como para el consumidor de un atajo delegado.
- La seguridad a nivel de fila (RLS) está soportada para el lado productor de un atajo delegado, pero no puedes configurarla en el lado de consumidor.
- Además de los permisos de seguridad de OneLake para acceder a la ruta del productor, el acceso a accesos directos externos mediante Spark o llamadas directas a la API también requiere permisos de lectura sobre el elemento que contiene la ruta del acceso directo externo.