Modelo de control de acceso de seguridad de OneLake (versión preliminar)

En este documento se proporciona una guía detallada sobre cómo funciona el modelo de control de acceso de seguridad de OneLake. Contiene detalles sobre cómo se estructuran los roles, cómo se aplican a los datos y cuál es la integración con otras estructuras dentro de Microsoft Fabric.

Roles de seguridad de OneLake

La seguridad de OneLake usa un modelo de control de acceso basado en rol (RBAC) para administrar el acceso a los datos en OneLake. Cada rol se compone de varios componentes clave.

Tipo: Indica si el rol concede acceso (GRANT) o quita el acceso (DENY). Solo se admiten los roles de tipo GRANT.
Permiso: Acción o acciones específicas que se conceden o deniegan.
Alcance: Los objetos OneLake que tienen el permiso. Los objetos son tablas, carpetas o esquemas.
Miembros: Cualquier identidad de Microsoft Entra asignada al rol, como usuarios, grupos o identidades que no son de usuario. El rol se concede a todos los miembros de un grupo de Microsoft Entra.

Al asignar un miembro a un rol, ese usuario está sujeto a los permisos asociados en el ámbito de ese rol. Dado que la seguridad de OneLake usa un modelo de denegación de forma predeterminada, todos los usuarios comienzan sin acceso a los datos a menos que se conceda explícitamente un rol de seguridad de OneLake.

Permisos y elementos admitidos

Los roles de seguridad oneLake admiten el permiso siguiente:

Leer: Concede al usuario la capacidad de leer datos de una tabla y ver los metadatos de columna y tabla asociados. En términos SQL, este permiso es equivalente tanto a VIEW_DEFINITION como a SELECT. Para obtener más información, consulte Seguridad de metadatos.
ReadWrite: Concede al usuario la capacidad de leer y escribir datos desde una tabla o carpeta y ver los metadatos de columna y tabla asociados. En términos SQL, este permiso es equivalente a ALTER, DROP, UPDATE e INSERT. Para obtener más información, consulte Permiso ReadWrite.

La seguridad de OneLake permite a los usuarios definir roles de acceso a datos solo para los siguientes elementos de Fabric.

Elemento de tela	Estado	Permisos admitidos
Lakehouse	Public Preview	Lectura, Lectura/Escritura
Catálogo espejado de Azure Databricks	Public Preview	Lectura

Permisos de seguridad y área de trabajo de OneLake

Los permisos de área de trabajo son el primer límite de seguridad para los datos de OneLake. Cada área de trabajo representa un único dominio o área de proyecto donde los equipos pueden colaborar en los datos. Gestionas la seguridad en el espacio de trabajo a través de los roles de área de trabajo de Fabric. Más información sobre el control de acceso basado en roles (RBAC) de Fabric: Roles de área de trabajo

Los roles del área de trabajo de Fabric conceden permisos que se aplican a todos los elementos del área de trabajo. En la tabla siguiente se describen los permisos básicos permitidos por los roles de área de trabajo.

Permiso	Administrador	Miembro	Colaborador	Visor
Ver archivos en OneLake	Siempre* Sí	Siempre* Sí	Siempre* Sí	No de manera predeterminada. Use la seguridad de OneLake para conceder el acceso.
Escribir archivos en OneLake	Siempre* Sí	Siempre* Sí	Siempre* Sí	No
Puede editar roles de seguridad de OneLake	Siempre* Sí	Siempre* Sí	No	No

*Como los roles de Administrador del área de trabajo, Miembro y Colaborador conceden automáticamente permisos de escritura a OneLake, invalidan los permisos de lectura de la seguridad de OneLake.

Los roles de área de trabajo administran el acceso a los datos del plano de control, lo que significa que las interacciones con la creación y administración de artefactos y permisos de Fabric. Además, los roles de área de trabajo también proporcionan niveles de acceso predeterminados a los elementos de datos mediante roles predeterminados de seguridad de OneLake. (Tenga en cuenta que los roles predeterminados solo se aplican a los visores, ya que el administrador, el miembro y el colaborador tienen acceso elevado a través del permiso De escritura). Un rol predeterminado es un rol de seguridad de OneLake normal que se crea automáticamente con cada nuevo elemento. Proporciona a los usuarios determinados permisos de área de trabajo o elemento un nivel predeterminado de acceso a los datos de ese elemento. Por ejemplo, los elementos de Lakehouse tienen un rol DefaultReader que permite a los usuarios con el permiso ReadAll ver los datos en Lakehouse. Esto garantiza que los usuarios que acceden a un elemento recién creado tengan un nivel básico de acceso. Todos los roles predeterminados usan una característica de virtualización de miembros, de modo que los miembros del rol sean cualquier usuario de esa área de trabajo con el permiso necesario. Por ejemplo, todos los usuarios con permiso ReadAll en Lakehouse. En la tabla siguiente se muestra cuáles son los roles predeterminados estándar. Los elementos pueden tener roles predeterminados especializados que solo se aplican a ese tipo de elemento.

Elemento de tela	Nombre del rol	Permiso	Carpetas incluidas	Miembros asignados
Lakehouse	`DefaultReader`	Lectura	Todas las carpetas en `Tables/` y `Files/`	Todos los usuarios con permiso de lectura total
Lakehouse	`DefaultReadWriter`	Lectura	Todas las carpetas	Todos los usuarios con permiso de escritura

Nota:

Para restringir el acceso a usuarios específicos o carpetas específicas, modifique el rol predeterminado o quítelo y cree un rol personalizado.

Permisos de seguridad y elementos de OneLake

Dentro de un área de trabajo, los elementos de Fabric pueden tener permisos configurados por separado de los roles del área de trabajo. Los permisos se pueden configurar compartiendo un elemento o administrando los permisos de un elemento. Los siguientes permisos determinan la capacidad de un usuario para realizar acciones en los datos de OneLake. Para obtener más información sobre el uso compartido de elementos, consulte Cómo funciona el uso compartido de Lakehouse.

Permiso	¿Puede ver archivos en OneLake?	¿Puede escribir archivos en OneLake?	¿Puede leer datos a través del punto de conexión de análisis SQL?
Lectura	No de manera predeterminada. Use la seguridad de OneLake para conceder el acceso.	No	No
LeerTodo	Sí a través del rol DefaultReader. Use la seguridad de OneLake para restringir el acceso.	No	No*
Escribir	Sí	Sí	Sí
Ejecutar, Compartir de nuevo, Ver resultados, Ver registros	N/D: no se puede conceder por sí solo	N/D: no se puede conceder por sí solo	N/D: no se puede conceder por sí solo

*Depende del modo de punto de conexión de SQL Analytics.

Crear roles

Puede definir y administrar roles de seguridad de OneLake desde la configuración de acceso a datos del almacén de lago de datos.

Más información en Introducción a los roles de acceso a datos.

Acceso de usuario y motor a datos

El acceso a datos a OneLake se produce de una de estas dos maneras:

A través de un motor de consulta de Fabric o
A través del acceso de usuario (las consultas de motores que no son de Fabric se consideran acceso de usuario)

La seguridad de OneLake garantiza que los datos siempre se mantengan seguros. Dado que algunas características de seguridad de OneLake como la seguridad de nivel de fila y columna no son compatibles con las operaciones de nivel de almacenamiento, no se pueden permitir todos los tipos de acceso a datos protegidos de nivel de fila o columna. Esto garantiza que los usuarios no puedan ver filas ni columnas a las que no están permitidos. Los motores de Microsoft Fabric están habilitados para aplicar el filtrado de seguridad de nivel de fila y columna a las consultas de datos. Esto significa que cuando un usuario consulta datos en una instancia de Lakehouse u otro elemento con OneLake security RLS o CLS en él, los resultados que ve el usuario tienen quitadas las filas y columnas ocultas. Para el acceso de usuario a los datos de OneLake con RLS o CLS en él, la consulta se bloquea si el usuario que solicita acceso no puede ver todas las filas o columnas de esa tabla.

En la tabla siguiente se describe qué motores de Microsoft Fabric admiten el filtrado de RLS y CLS.

Motor	Filtrado de RLS/CLS	Estado
Lakehouse	Sí	Versión preliminar pública
Cuadernos de Spark	Sí	Versión preliminar pública
Punto de conexión de SQL Analytics en "modo de identidad del usuario"	Sí	Versión preliminar pública
Modelos semánticos con DirectLake en modo OneLake	Sí	Versión preliminar pública
Centro de eventos	No	Programado
Tablas externas de almacenamiento de datos	No	Programado

Detalles del modelo de control de acceso de seguridad de OneLake

En esta sección se proporcionan detalles sobre cómo los roles de seguridad de OneLake conceden acceso a ámbitos específicos, cómo funciona ese acceso y cómo se resuelve el acceso en varios roles y tipos de acceso.

Seguridad de nivel de tabla

Todas las tablas de OneLake se representan mediante carpetas en el lago, pero no todas las carpetas en el lago son tablas desde la perspectiva de los motores de seguridad y consulta de OneLake en Fabric. Para considerarse una tabla válida, se deben cumplir las siguientes condiciones:

La carpeta existe en el directorio Tables/ de un elemento.
La carpeta contiene una carpeta _delta_log con los archivos JSON correspondientes para los metadatos de la tabla.
La carpeta no contiene ningún acceso directo secundario.

Las tablas que no cumplan esos criterios tendrán acceso denegado si la seguridad de nivel de tabla está configurada en ellos.

Seguridad de metadatos

El acceso de lectura de OneLake security a los datos concede acceso completo a los datos y metadatos de una tabla. Para los usuarios sin acceso a una tabla, los datos nunca se exponen y, por lo general, los metadatos no son visibles. Esto también se aplica a la seguridad de nivel de columna y a la capacidad de un usuario de ver o no ver una columna en esa tabla. Sin embargo, la seguridad de OneLake no garantiza que los metadatos de una tabla no sean accesibles , en concreto en los casos siguientes:

Consultas de punto de conexión de SQL: el punto de conexión de SQL Analytics usa el mismo comportamiento de seguridad de metadatos que SQL Server. Esto significa que si un usuario no tiene acceso a una tabla o columna, el mensaje de error de esa consulta indicará explícitamente los nombres de tabla o columna a los que el usuario no tiene acceso.
Modelos semánticos: conceder a un usuario permiso de compilación en un modelo semántico permite el acceso para ver los nombres de tabla incluidos en el modelo, independientemente de si el usuario tiene acceso a ellos o no. Además, los objetos visuales de informe que contienen columnas ocultas muestran el nombre de columna en el mensaje de error.

Herencia de permisos

Para cualquier carpeta determinada, los permisos de seguridad de OneLake siempre heredan toda la jerarquía de los archivos y subcarpetas de la carpeta.

Por ejemplo, considere la siguiente jerarquía de un almacén de lago de datos en OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Puede crear dos roles para este almacén de lago de datos. Role1 concede permiso de lectura a folder1 y Role2 concede permiso de lectura a folder2.

Para la jerarquía dada, los permisos de seguridad de OneLake para Role1 y Role2 heredan de la siguiente manera:

Role1: Lectura en folder1

│   │   file11.txt
│   │
│   └───subfolder11
│       │   file1111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: Lectura en folder2
```
    │   file21.txt
```

Recorrido y enumeración en la seguridad de OneLake

La seguridad de OneLake proporciona recorrido automático de elementos primarios para garantizar que los datos sean fáciles de detectar. Conceder a un usuario permisos de lectura a la subcarpeta11 le permite enumerar y recorrer la carpeta1 del directorio primario. Esta funcionalidad es similar a los permisos de carpeta de Windows en los que proporcionar acceso a una subcarpeta proporciona detección y recorrido para los directorios primarios. La enumeración y el recorrido concedidos al elemento primario no se extienden a otros elementos fuera de los elementos primarios directos, lo que garantiza que otras carpetas se mantengan seguras.

Por ejemplo, considere la siguiente jerarquía de un almacén de lago de datos en OneLake.

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt
│   
└───folder2
    │   file21.txt

Para la jerarquía dada, los permisos de seguridad de OneLake para "Role1" proporcionan el acceso siguiente. El acceso a file11.txt no es visible, ya que no es un elemento primario de la subcarpeta11. Del mismo modo para Role2, tampoco es visible file111.txt.

Role1: Lectura de subfolder11

Files/
────folder1
│   │
│   └───subfolder11
│       │   file111.txt
|       │
│       └───subfolder111
|            │   file1111.txt

Role2: Lectura de subfolder111

Files/
────folder1
│   │
│   └───subfolder11
|       │
│       └───subfolder111
|            │   file1111.txt

En el caso de los accesos directos, el comportamiento de descripción es ligeramente diferente. Los accesos directos a orígenes de datos externos se comportan igual que las carpetas; pero los accesos directos a otras ubicaciones de OneLake tienen un comportamiento especializado. Los permisos de destino del acceso directo determinan el acceso a un acceso directo de OneLake. Al enumerar accesos directos, no se realiza ninguna llamada para comprobar el acceso de destino. Como resultado, al enumerar un directorio, se devuelven todos los accesos directos internos independientemente del acceso de un usuario al destino. Cuando un usuario intenta abrir el acceso directo, la comprobación de acceso se evalúa y un usuario solo ve los datos para los que tiene los permisos necesarios. Para más información sobre los accesos directos, vea la sección de seguridad de los accesos directos.

Considere la siguiente jerarquía de carpetas que contiene accesos directos.

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role1: Lectura en folder1

Files/
────folder1
│   
└───shortcut2
|
└───shortcut3

Role2: Sin permisos definidos

Files/
│   
└───shortcut2
|
└───shortcut3

Seguridad de nivel de fila

La seguridad de OneLake permite a los usuarios especificar la seguridad de nivel de fila escribiendo predicados SQL para limitar los datos que se muestran a un usuario. RLS funciona mostrando filas donde el predicado se evalúa como true. Para obtener más información, consulte la seguridad de nivel de fila.

La seguridad de nivel de fila evalúa los datos de cadena como no distingue mayúsculas de minúsculas, utilizando la siguiente intercalación para ordenar y comparar: Latin1_General_100_CI_AS_KS_WS_SC_UTF8

Al usar la seguridad de nivel de fila, asegúrese de que las instrucciones RLS son limpias y fáciles de entender. Use columnas enteras para ordenar y mayor o menor que las operaciones. Evite las equivalencias de cadenas si no conoce el formato de los datos de entrada, especialmente en relación con caracteres unicode o sensibilidad de énfasis.

Seguridad de nivel de columna

La seguridad de OneLake permite limitar el acceso a las columnas quitando (ocultando) el acceso de un usuario a una columna. Una columna oculta se trata como sin permisos asignados, lo que da lugar a la directiva predeterminada sin acceso. Las columnas ocultas no serán visibles para los usuarios y las consultas en los datos que contienen columnas ocultas no devuelven datos para esa columna. Como se indica en la seguridad de los metadatos , hay cierto caso en el que los metadatos de una columna podrían seguir siendo visibles en algunos mensajes de error.

La seguridad de nivel de columna también sigue un comportamiento más estricto en el punto de conexión de SQL trabajando a través de una semántica de denegación. Denegar en una columna del punto de conexión de SQL garantiza que todo el acceso a la columna esté bloqueado, incluso si varios roles se combinaran para conceder acceso a ella. Como resultado, CLS en el punto de conexión de SQL funciona mediante una intersección entre todos los roles de los que un usuario forma parte en lugar del comportamiento de unión para todos los demás tipos de permisos. Consulte la sección Evaluación de varios roles de seguridad de OneLake para obtener más información sobre cómo combinar roles.

Permiso de lectura y escritura

El permiso ReadWrite proporciona a los usuarios de solo lectura la capacidad de realizar operaciones de escritura en elementos específicos. El permiso de lectura y escritura solo es aplicable a lectores o usuarios con el permiso de lectura en un elemento. La asignación de acceso ReadWrite a un administrador, miembro o colaborador no tiene ningún efecto, ya que esos roles ya tienen ese permiso implícitamente.

El acceso ReadWrite permite a los usuarios realizar operaciones de escritura a través de cuadernos de Spark, el explorador de archivos oneLake o las API de OneLake. No se admiten las operaciones de escritura a través de la interfaz de Lakehouse para los usuarios visualizadores.

El permiso ReadWrite funciona de las siguientes maneras:

El permiso ReadWrite incluye todos los privilegios concedidos por el permiso Read.
Los usuarios con permisos de lectura y escritura en un objeto pueden realizar operaciones de escritura en ese objeto. Es decir, cualquier operación también se puede realizar en el propio objeto.
ReadWrite permite las siguientes acciones:
- Crear una nueva carpeta o tabla
- Eliminación de una carpeta o tabla
- Cambiar el nombre de una carpeta o tabla
- Cargar o editar un archivo
- Crear un acceso directo
- Eliminar un acceso directo
- Cambiar el nombre de un acceso directo
Los roles de seguridad OneLake con acceso ReadWrite no pueden contener restricciones RLS o CLS.
Dado que Fabric solo admite escrituras en datos desde un único motor, los usuarios con permiso ReadWrite en un objeto solo pueden escribir en esos datos a través de OneLake. Sin embargo, las operaciones de lectura se aplicarán de forma coherente a través de todos los motores de consulta.

Métodos abreviados

Introducción a los accesos directos

OneLake security se integra con accesos directos en OneLake para asegurarse de que los datos dentro y fuera de OneLake se pueden proteger fácilmente. Hay dos modos de autenticación principales para los accesos directos:

Accesos directos de paso a través (SSO): la credencial del usuario que realiza la consulta se evalúa con respecto al destino de acceso directo para determinar qué datos se pueden ver.
Accesos directos delegados: el acceso directo usa una credencial fija para acceder al destino y el usuario que realiza la consulta se evalúa con la seguridad de OneLake antes de comprobar el acceso de la credencial delegada al origen.

Además, los permisos de seguridad de OneLake se evalúan al crear los accesos directos en OneLake. Obtenga información sobre los permisos de acceso directo en el documento de seguridad de acceso directo.

Seguridad de OneLake en métodos abreviados de acceso directo

La configuración de seguridad establecida en una carpeta OneLake siempre se propaga a través de los accesos directos internos para restringir el acceso a la ruta de origen del acceso directo. Cuando un usuario accede a los datos desde un acceso directo a otra ubicación de OneLake, la identidad del usuario que realiza la llamada se usa para autorizar el acceso a los datos en la ruta de acceso de destino del acceso directo. Como resultado, este usuario debe tener permisos de seguridad de OneLake en la ubicación de destino para leer los datos.

Importante

Al acceder a accesos directos mediante modelos semánticos de Power BI utilizando DirectLake sobre SQL o motores de T-SQL en modo de identidad delegada, la identidad del usuario que realiza la llamada no se transmite al destino del acceso directo. En su lugar, se pasa la identidad del propietario del elemento que realiza la llamada y se delega el acceso al usuario que realiza la llamada. Para resolverlo, use modelos semánticos de Power BI en DirectLake a través del modo OneLake o T-SQL en el modo de identidad del usuario.

No se permite definir permisos de seguridad de OneLake para el acceso directo interno y se debe definir en la carpeta de destino ubicada en el elemento de destino. El elemento de destino debe ser un tipo de elemento que admita roles de seguridad de OneLake. Si el elemento de destino no admite la seguridad de OneLake, el acceso del usuario se evalúa en función de si tienen el permiso Fabric ReadAll en el elemento de destino. Los usuarios no necesitan el permiso De lectura de Fabric en un elemento para acceder a él a través de un acceso directo.

Seguridad de OneLake en accesos directos delegados

OneLake admite la definición de permisos para accesos directos, como accesos directos de ADLS, S3 y Dataverse. En este caso, los permisos se aplican sobre el modelo de autorización delegado habilitado para este tipo de acceso directo.

Imagine que user1 crea un acceso directo S3 en un almacén de lago de datos que apunta a una carpeta en un cubo de AWS S3. Después, user2 intenta acceder a los datos en este acceso directo.

¿La conexión S3 autoriza el acceso para el usuario delegado user1?	¿La seguridad de OneLake autoriza el acceso para el usuario 2 que realiza la solicitud?	Resultado: ¿Puede usuario2 acceder a los datos en el acceso directo de S3?
Sí	Sí	Sí
No	No	No
No	Sí	No
Sí	No	No

Los permisos de seguridad de OneLake se pueden definir para todo el ámbito del acceso directo o para subcarpetas seleccionadas. Los permisos establecidos en una carpeta se heredan de forma recursiva en todas las subcarpetas, incluso si la subcarpeta está dentro del acceso directo. La seguridad establecida en un acceso directo externo se puede limitar para conceder acceso a todo el acceso directo o a cualquier subruta dentro del acceso directo. Otro acceso directo interno que apunta a un acceso directo externo todavía requiere que el usuario tenga acceso al acceso directo externo original.

A diferencia de otros tipos de acceso en la seguridad de OneLake, un usuario que accede a un acceso directo externo requiere el permiso Fabric Read en el elemento de datos donde reside el acceso directo externo. Esto es necesario para resolver de forma segura la conexión al sistema externo.

Más información sobre los accesos directos de S3, ADLS y Dataverse en Accesos directos de OneLake.

Evaluación de varios roles de seguridad de OneLake

Los usuarios pueden ser miembros de varios roles de seguridad de OneLake diferentes, cada uno de los cuales proporciona su propio acceso a los datos. La combinación de estos roles se denomina "rol efectivo" y es lo que verá un usuario al acceder a los datos en OneLake. Los roles se combinan en la seguridad de OneLake mediante un modelo UNION o menos restrictivo. Esto significa que si Role1 proporciona acceso a TableA y Role2 proporciona acceso a TableB, el usuario podrá ver TableA y TableB.

Los roles de seguridad de OneLake también contienen seguridad de nivel de fila y columna, que limita el acceso a las filas y columnas de una tabla. Cada directiva RLS y CLS existe dentro de un rol y limita el acceso a los datos de todos los usuarios dentro de ese único rol. Por ejemplo, si Role1 proporciona acceso a Table1, pero tiene RLS en Table1 y solo muestra algunas columnas de Table1, el rol efectivo para Role1 será los subconjuntos RLS y CLS de Table1. Esto se puede expresar como (R1ols n R1cls n R1rls) donde n es la INTERSECCIÓN de cada componente del rol.

Al tratar con varios roles, RLS y CLS se combinan con una semántica UNION en las tablas respectivas. CLS es un conjunto directo UNION de las tablas visibles en cada rol. RLS se combina entre predicados mediante un operador OR. Por ejemplo, WHERE city = 'Redmond' OR city = 'New York'.

Para evaluar varios roles cada uno con RLS o CLS, cada rol se resuelve primero en función del acceso proporcionado por el propio rol. Esto significa evaluar la intersección de toda la seguridad de nivel de objeto, fila y columna. A continuación, cada rol evaluado se combina con todos los demás roles de los que un usuario es miembro a través de la operación UNION. La salida es el rol efectivo para ese usuario. Esto se puede expresar como:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) )

Por último, cada acceso directo de una instancia de Lakehouse genera un conjunto de roles inferidos que se usan para propagar los permisos del destino del acceso directo al elemento que se consulta. Los roles inferidos funcionan de forma similar a los roles no inferidos, excepto que se resuelven en primer lugar en el destino de acceso directo antes de combinarse con roles en el lago de acceso directo. Esto garantiza que cualquier herencia de permisos en el lago de acceso directo se interrumpe y los roles inferidos se evalúan correctamente. A continuación, la lógica de combinación completa se puede expresar como:

( (R1ols n R1cls n R1rls) u (R2ols n R2cls n R2rls) ) n ( (R1'ols n R1'cls n R1'rls) u (R2'ols n R2'cls n R2'rls)) )

Donde R1' y R2' son los roles inferidos y R1 y R2 son los roles de lakehouse de acceso directo.