Cómo la seguridad de OneLake controla el acceso a los datos

La seguridad de OneLake es un sistema basado en roles que determina quién puede acceder a los datos en OneLake y qué acciones pueden tomar sobre esos datos. Entender el modelo de control de acceso a datos te ayuda a conceder a los usuarios solo el acceso que necesitan, para proteger datos sensibles mientras permites que las personas adecuadas trabajen con ellos.

Este artículo explica cómo se estructuran los roles de seguridad de OneLake, cómo se integran con los permisos de espacio de trabajo y de objetos, cómo OneLake aplica y resuelve el acceso a tus datos, y los límites a tener en cuenta.

Roles de seguridad de OneLake

La seguridad de OneLake utiliza un modelo de control de acceso basado en roles (RBAC) para gestionar el acceso a los datos en OneLake. En la experiencia de seguridad de OneLake, cada puesto tiene los siguientes componentes:

  • Permisos: Los permisos que concede el rol sobre los datos, como Lectura o Escritura Read.
  • Tipo: El tipo de papel. La seguridad de OneLake solo admite roles Grant, que conceden a los miembros acceso a los datos del rol. No es compatible con roles Deny que eliminan el acceso.
  • Datos en el rol: Las tablas, carpetas o esquemas a los que el rol concede acceso. También puedes definir el acceso a datos con seguridad a nivel de fila y columna en tablas.
  • Miembros en el puesto: Las identidades de Microsoft Entra asignadas al rol, como usuarios, grupos o identidades no usuarias. Si asignas un grupo de Microsoft Entra, OneLake Security otorga el rol a todos los miembros del grupo.

La seguridad de OneLake utiliza un modelo de denegación por defecto, por lo que los usuarios empiezan sin acceso a los datos a menos que un rol de seguridad de OneLake conceda explícitamente acceso. Algunos elementos de Fabric comienzan con roles predeterminados que dan a los usuarios acceso básico según los permisos de su espacio de trabajo.

Permisos y elementos compatibles

Los roles de seguridad de OneLake soportan los siguientes permisos:

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

Puedes crear roles de seguridad en OneLake para los siguientes artículos Fabric:

Elemento de tela Permisos admitidos
Lakehouse Lectura, Lectura/Escritura
Catálogo reflejado de Azure Databricks Lectura
Bases de datos reflejadas Lectura
Catálogos duplicados Lectura

Permiso de lectura y escritura

Utiliza el permiso ReadWrite para conceder acceso de escritura a los usuarios de solo lectura a datos específicos en un elemento.

ReadWrite solo se aplica a usuarios con permiso de lectura sobre un elemento, como los usuarios con el rol de espacio de trabajo Visor. Asignar ReadWrite a un Administrador, Miembro o Colaborador de espacio de trabajo no tiene efecto porque estos roles de espacio de trabajo ya tienen acceso de escritura.

ReadWrite incluye todos los privilegios concedidos por el permiso de lectura, además de conceder acceso de escritura al objeto seleccionado y a su contenido. Por ejemplo, el permiso de ReadWrite en una carpeta otorga acceso de escritura tanto a la carpeta como a los datos que contiene ella.

Los usuarios con permiso de ReadWrite pueden realizar las siguientes acciones:

  • Crea, elimina o renombra una carpeta o tabla.
  • Sube o edita un archivo.
  • Crear, borrar o renombrar un acceso directo.

Los usuarios pueden realizar operaciones de escritura a través de cuadernos Spark, el explorador de archivos OneLake o las APIs de OneLake. Dado que Fabric solo admite la escritura en datos mediante un único motor, los usuarios con permiso ReadWrite solo pueden escribir en dichos datos a través de OneLake. Todos los motores de consulta continúan aplicando operaciones de lectura de forma consistente.

Los roles de seguridad de OneLake que otorgan permisos de ReadWrite no pueden contener restricciones de seguridad a nivel de fila (RLS) ni de seguridad a nivel de columna (CLS).

Permisos de seguridad y área de trabajo de OneLake

Los roles del área de trabajo son la primera frontera de seguridad para los datos en OneLake. Gestionan el plano de control —creando y gestionando los elementos y permisos de Fabric— y aplican a todos los elementos del espacio de trabajo. Para consultar los permisos específicos de OneLake que concede cada rol del área de trabajo, consulta Conceder acceso con roles del área de trabajo. Para saber más sobre los roles en los espacios de trabajo, consulta Roles en los espacios de trabajo en Fabric.

Más allá del acceso por plano de control, los roles de espacio de trabajo también pueden proporcionar acceso a elementos de datos a través de los roles predeterminados de seguridad de OneLake. (Los roles predeterminados solo se aplican a los Visores, porque los roles de Administrador, Miembro y Colaborador tienen acceso elevado mediante el permiso de escritura.) Un rol predeterminado es un rol de seguridad normal de OneLake que Fabric 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 el rol de DefaultReader, que permite a los usuarios con el permiso ReadAll ver los datos en el lakehouse. Este acceso por defecto garantiza que los usuarios que trabajan con un elemento recién creado tengan un nivel básico de acceso. Todos los roles predeterminados utilizan una función de virtualización de miembros, de modo que los miembros del rol son cualquier usuario en ese espacio de trabajo con el permiso requerido. Por ejemplo, todos los usuarios con permiso ReadAll en lakehouse.

La siguiente tabla muestra los roles estándar por defecto. Los objetos pueden tener roles por defecto especializados que solo se aplican a ese tipo de objeto.

Elemento de tela Nombre del rol Permiso concedido Miembros asignados
Lakehouse DefaultReader Lectura Todos los usuarios con permiso de lectura total
Catálogo reflejado de Azure Databricks DefaultReader Lectura Todos los usuarios con permiso de lectura
Catálogo replicado DefaultReader Lectura Todos los usuarios con permiso de lectura
Base de datos reflejada DefaultReader Lectura Todos los usuarios con permiso de lectura total

Puedes modificar o eliminar el rol predeterminado de un elemento de Fabric para cambiar el acceso de los usuarios de ese grupo de miembros.

Motor y acceso de usuario a datos

La seguridad de OneLake por defecto es el acceso menos privilegiado. Algunas operaciones a nivel de almacenamiento no pueden hacer cumplir RLS o CLS, así que cuando una consulta no puede filtrarse de forma segura, OneLake la bloquea por completo en lugar de arriesgarse a exponer datos que el usuario no puede ver. Si una consulta está filtrada o bloqueada depende del camino de acceso: un motor de consulta compatible o acceso directo del usuario.

Para los motores que admiten el filtrado de RLS y CLS, y los requisitos de cada uno, consulte Leer datos protegidos por la seguridad de OneLake.

Ámbitos y aplicación

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

OneLake representa todas las tablas como carpetas, pero desde la perspectiva de los motores de seguridad y consulta de OneLake en Fabric, no todas las carpetas son tablas. Para que sea una tabla válida, una carpeta debe cumplir las siguientes condiciones:

  • La carpeta existe en el Tables/ directorio de un elemento. Para los elementos habilitados para esquemas, la carpeta también debe estar en una carpeta de esquema válida.
  • La carpeta contiene una _delta_log carpeta con archivos JSON correspondientes para los metadatos de la tabla.
  • La carpeta no contiene accesos directos secundarios.

Si configuras RLS o CLS en una tabla, OneLake niega el acceso cuando la carpeta de la tabla no cumple estos criterios. Sin RLS ni CLS, OneLake trata una carpeta que no cumple estos criterios como una carpeta y aplica seguridad a nivel de carpeta.

Seguridad de nivel de fila y de nivel de columna

Dentro de un rol, puedes restringir el acceso a filas y columnas específicas de una tabla usando seguridad a nivel de fila y seguridad a nivel de columna. Para más información sobre qué hace cada control y cómo OneLake lo hace cumplir, consulta Seguridad a nivel de tabla, columna y fila en OneLake. Para información sobre cómo se resuelven RLS y CLS cuando un usuario pertenece a múltiples roles, consulte Evaluar múltiples roles de seguridad de OneLake.

Seguridad de metadatos

El permiso de lectura de OneLake security concede acceso total a los datos y metadatos de una tabla. Para los usuarios sin acceso a una tabla, los datos nunca se exponen. Esta regla también se aplica a la seguridad a nivel de columna y a la capacidad del usuario para 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. Ciertos mensajes de error y experiencias pueden mostrar nombres de columnas.

Herencia de permisos de carpeta y desplazamiento

Los permisos de carpeta afectan a una jerarquía en dos direcciones:

  • Herencia: Los permisos concedidos a una carpeta se aplican hacia abajo a sus archivos y subcarpetas.
  • Desplazamiento y listado: Cuando los usuarios tienen permiso sobre un elemento secundario, la seguridad de OneLake les permite enumerar y recorrer sus carpetas principales para descubrir los datos a los que pueden acceder y desplazarse hasta ellos. El desplazamiento no concede acceso a archivos o carpetas hermanas.

Consideremos la siguiente jerarquía de una casa lacustre en OneLake:

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

Creas un rol, Role1, que otorga permiso para Leer en subfolder11. A través de la herencia, los miembros de ese rol pueden leer file111.txt y todo lo que hay en subfolder111. Los miembros pueden ver y atravesar folder1 para llegar a subfolder11, pero no pueden ver file11.txt porque es un elemento hermano de subfolder11 y no pueden ver Tables porque es un elemento hermano de Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Crea otro rol, Role2, que concede permiso de lectura sobre folder2. Mediante la herencia, los miembros pueden leer file21.txt. Los miembros pueden atravesar folder2 y Files para llegar a él, pero no pueden ver folder1 ni a ninguno de sus hijos.

Files/
│
└───folder2 <-- READ
    │   file21.txt

En cuanto a atajos, el comportamiento es ligeramente diferente. Los accesos directos a fuentes de datos externas se comportan igual que las carpetas. Sin embargo, los atajos hacia otras ubicaciones de OneLake presentan comportamientos especializados. Los permisos de destino del acceso directo determinan el acceso a un acceso directo de OneLake. Al listar accesos directos, OneLake no hace ninguna llamada para comprobar el acceso objetivo. Como resultado, cuando listas un directorio, OneLake devuelve todos los atajos internos independientemente de si tienes acceso al destino. La comprobación de acceso se evalúa una vez que intentas abrir el acceso directo, y entonces solo ves los datos para los que tienes los permisos necesarios.

Métodos abreviados

La seguridad de OneLake se integra con atajos para proteger los datos dentro y fuera de OneLake. Los atajos utilizan uno de dos modos de autenticación:

  • Paso directo: El acceso directo utiliza la identidad del usuario que consulta para acceder al destino. La transferencia directa es la opción predeterminada para los accesos directos de OneLake a OneLake.
  • Delegado: El atajo usa la identidad o credencial de conexión configurada para acceder al destino. Los atajos OneLake-to-OneLake pueden usar autenticación delegada, y los atajos a sistemas externos siempre emplean autenticación delegada.

Crear un acceso directo requiere permisos tanto en la ruta donde se crea el acceso directo como en la ruta de destino. Para los requisitos para crear y acceder a cada tipo de acceso directo, véase la seguridad de atajos de OneLake.

Seguridad de OneLake en métodos abreviados de acceso directo

Cuando un usuario accede a los datos a través de un acceso directo de transferencia de OneLake a OneLake, OneLake utiliza la identidad del usuario que realiza la llamada para autorizar el acceso a la ruta de destino. El acceso efectivo del usuario está limitado por sus permisos tanto en la ruta de acceso directo como en la ruta de destino.

Nota:

La identidad del motor de consulta y la autenticación por acceso directo son configuraciones separadas. Un acceso directo de paso normalmente utiliza la identidad del usuario que llama para acceder al destino. Sin embargo, los modelos semánticos de Power BI que usan Direct Lake sobre SQL y endpoints de analítica SQL en modo de identidad delegada emplean la identidad del propietario del artículo de consumo o fuente de datos. Este comportamiento no cambia el modo de autenticación configurado del acceso directo. Para el paso de identidad de usuario de extremo a extremo, utiliza Direct Lake sobre OneLake o configura el endpoint de análisis SQL para usar el modo de acceso a identidad del usuario.

No puedes definir permisos de seguridad de OneLake directamente en un atajo OneLake-to-OneLake. Los permisos en la carpeta que contiene el acceso directo se combinan con los permisos en la ruta de destino. Si el elemento objetivo soporta seguridad OneLake, el usuario necesita acceso a través de un rol de seguridad OneLake. Si el elemento objetivo no soporta seguridad OneLake, el usuario necesita el permiso Fabric ReadAll sobre el elemento objetivo. El usuario no necesita permiso de lectura de Fabric sobre el elemento objetivo únicamente para acceder a sus datos a través del acceso directo.

Seguridad de OneLake en accesos directos delegados

Los atajos delegados utilizan una identidad de conexión configurada o credencial en lugar de la identidad del usuario que llama para acceder al destino. La seguridad de OneLake limita a lo que el usuario que llama puede acceder a través de esa conexión.

Accesos directos delegados de OneLake

Para un atajo delegado de OneLake a OneLake, el usuario que realiza la llamada ve la intersección entre su acceso en la ruta del atajo y el acceso de la identidad de conexión configurada en la ruta de destino. La seguridad a nivel de columna (CLS) se admite en ambas rutas. La seguridad a nivel de fila (RLS) se soporta en la ruta de destino, pero no puedes definir RLS en la ruta de acceso directo.

Atajos externos delegados

Los accesos directos a sistemas externos, como ADLS, Amazon S3 y Dataverse, utilizan una credencial de conexión configurada para acceder al código fuente externo. La seguridad OneLake se aplica además del acceso otorgado por esa credencial.

Por ejemplo, supongamos que el usuario1 crea un acceso directo de la casa del lago a una carpeta en un cubo de Amazon S3, y el usuario2 accede al acceso directo desde la casa del lago. El usuario2 solo puede acceder a los datos de S3 si la credencial de conexión S3 configurada puede acceder a la fuente y la seguridad de OneLake autoriza al usuario2 a acceder a la ruta de acceso directo.

Puedes conceder a OneLake acceso de seguridad a todo el acceso directo externo o a subrutas seleccionadas. Los permisos en una carpeta se heredan recursivamente a todas sus subcarpetas, incluidas las carpetas dentro del acceso directo. Un usuario que acceda a un acceso directo externo a través de otro acceso directo de OneLake debe seguir siendo autorizado por la seguridad de OneLake aplicada al acceso directo externo original.

Acceder a un acceso directo externo a través de Spark o a una llamada directa a la API OneLake también requiere permiso de lectura Fabric sobre el elemento que contiene el acceso directo externo. Este permiso es necesario para resolver de forma segura la conexión al sistema externo.

Evalúa múltiples roles de seguridad en OneLake

Un usuario puede pertenecer a varios roles de seguridad de OneLake. OneLake combina el acceso otorgado por esos roles en un rol efectivo, que determina los datos a los que el usuario puede acceder. OneLake evalúa el papel efectivo en etapas.

Resolución del acceso dentro de cada rol

OneLake primero resuelve cada rol de forma independiente. Dentro de un rol, un usuario solo puede acceder a los datos permitidos por los tres componentes de seguridad:

  • La seguridad a nivel de objeto (OLS) determina a qué tablas o carpetas puede acceder el rol.
  • La seguridad a nivel de fila (RLS) limita a qué filas de una tabla determinada puede acceder el rol.
  • La seguridad a nivel de columna (CLS) limita a qué columnas de una tabla dada puede acceder el rol.

Como se aplican los tres componentes, OneLake toma la intersección de los tres. Por ejemplo, si Role1 concede acceso a Table1 y restringe sus filas y columnas, el acceso resuelto para Role1 es:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

El símbolo de intersección (∩) significa que el usuario solo recibe los permisos de acceso permitidos por OLS, RLS y CLS en ese rol.

Combinar el acceso entre roles

Tras resolver cada rol, OneLake combina los roles utilizando un modelo sindical, o menos restrictivo. El símbolo sindical (∪) significa que el acceso otorgado por cualquier rol pasa a formar parte del rol efectivo. Si el Rol1 concede acceso a la Tabla A y el Rol2 concede acceso a la Tabla B, un usuario que pertenezca a ambos roles puede acceder a ambas tablas.

Para dos roles, el rol efectivo es:

Effective role = Role1 ∪ Role2

Cuando varios roles otorgan acceso a la misma tabla, las reglas de seguridad de nivel de fila se combinan con un operador OR. Por ejemplo, predicados que permiten city = 'Redmond' y city = 'New York' combinan como city = 'Redmond' OR city = 'New York'.

Las reglas de seguridad a nivel de columna también se combinan como una unión, excepto en el endpoint de analítica SQL. En el endpoint de analítica SQL, CLS utiliza una semántica de denegación más estricta. Si algún rol oculta una columna, el extremo bloquea el acceso a esa columna. Como resultado, el endpoint intersecta listas de permiso CLS entre todos los roles del usuario en lugar de combinarlos como una unión.

Importante

Mantén las reglas RLS y CLS que deben aplicarse juntas en el mismo rol. OneLake no soporta una combinación de roles en la que dos roles permitan un conjunto diferente de columnas para una tabla y cualquiera de los dos roles también aplique RLS a esa tabla. Por ejemplo, un usuario no puede pertenecer a Role1, que permite columnas c1 y c2 y un subconjunto de filas, y a Role2, que permite columnas c2 y c3.

Combinar acceso directo y acceso de destino

En un acceso directo, OneLake evalúa los roles en la ubicación del acceso directo y en el destino del acceso directo por separado. Los roles de destino se convierten en roles inferidos en la ubicación del acceso directo. OneLake intersecta entonces el acceso combinado de los roles de acceso directo con el acceso combinado de los roles objetivo inferidos. Este paso impide que el acceso heredado en la ubicación del acceso directo prevalezca sobre las restricciones en el destino.

Para dos roles de acceso rápido y dos roles de destino inferidos, el acceso efectivo es:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

En esta expresión, ShortcutRole1 y ShortcutRole2 son los roles en la ubicación del acceso directo. InferredRole1 y InferredRole2 son las funciones correspondientes deducidas a partir del destino del acceso directo. Cada rol se resuelve a partir de los componentes OLS, RLS y CLS antes de que OneLake los combine.

Limitaciones de seguridad de OneLake

  • Si asigna un rol de seguridad de OneLake a un usuario invitado B2B, debe configurar las opciones de colaboración externa para B2B en Id. externa de Microsoft Entra. Configura la configuración de acceso de usuario invitado a que los usuarios invitados tengan el mismo acceso que los miembros (el más inclusivo).

  • Si agrega una lista de distribución a un rol en la seguridad de OneLake, el punto de conexión de SQL Analytics no puede resolver los miembros de la lista para aplicar el acceso. Como resultado, los usuarios parecen no ser miembros del rol cuando acceden al endpoint de analítica SQL. Direct Lake en modelos semánticos SQL también está sujeto a esta limitación.

  • Los cuadernos de Spark requieren que el entorno sea la versión 3.5 o superior y que utilice el entorno de ejecución de Fabric 1.3.

  • Los lakehouses sin esquema no admiten la vista previa de los datos para las tablas protegidas con RLS y CLS. Usa lakehouses con compatibilidad para esquemas y seguridad de OneLake.

  • La seguridad de OneLake no funciona con Azure Data Share ni con Purview Data Share. Para más información, consulte Azure Data Share.

  • La siguiente tabla enumera las limitaciones de los roles de seguridad de OneLake.

    Escenario Límite
    Número máximo de roles de seguridad de OneLake por elemento de Fabric 250 roles por elemento (ver nota)
    Número máximo de miembros por rol de seguridad de OneLake 500 usuarios o grupos de usuarios por rol
    Número máximo de permisos por rol de seguridad de OneLake 500 permisos por rol

    Nota:

    Puedes solicitar un aumento del número de roles por elemento hasta 1.000. Para solicitar un aumento, póngase en contacto con Azure Support.

Latencias

Los cambios en las definiciones de roles tardan unos cinco minutos en aplicarse.

Los cambios en un grupo de usuarios de un rol de seguridad de OneLake tardan aproximadamente una hora para que OneLake aplique los permisos del rol en el grupo de usuarios actualizado. Algunos motores de Fabric tienen su propia capa de almacenamiento en caché, por lo que puede requerir una hora adicional para actualizar el acceso en todos los sistemas.

Contenido relacionado

  • Last updated on