Seguridad de OneLake para puntos de conexión de SQL Analytics (versión preliminar)

Con la seguridad de OneLake, Microsoft Fabric está expandiendo cómo las organizaciones pueden administrar y aplicar el acceso a los datos a través de las cargas de trabajo. Este nuevo marco de seguridad proporciona a los administradores mayor flexibilidad para configurar permisos. Los administradores pueden elegir entre la gobernanza centralizada a través de OneLake o un control granular basado en SQL en el punto de conexión de SQL Analytics.

Modos de acceso en el terminal de SQL Analytics

Al usar el punto de conexión de análisis de SQL, el modo de acceso seleccionado determina cómo se aplica la seguridad de los datos. Fabric admite dos modelos de access distintos, cada uno de los cuales ofrece diferentes ventajas en función de sus necesidades operativas y de cumplimiento:

• Modo de identidad de usuario: aplica la seguridad mediante roles y directivas de OneLake. En este modo, el punto de conexión de SQL Analytics pasa la identidad del usuario que ha iniciado sesión a OneLake y read access se rige por completo por las reglas de seguridad definidas en OneLake. Se admiten permisos de nivel SQL en tablas, lo que garantiza una gobernanza coherente entre herramientas como Power BI, cuadernos y lakehouse.

• Modo de identidad delegada: proporciona control total a través de SQL. En este modo, el punto de conexión de SQL Analytics se conecta a OneLake mediante la identidad del propietario del área de trabajo o elemento, y la seguridad se rige exclusivamente por los permisos sql definidos dentro de la base de datos. Este modelo admite enfoques de seguridad tradicionales, como GRANT, REVOKE, roles personalizados, seguridad de Row-Level y enmascaramiento dinámico de datos.

Cada modo admite diferentes modelos de gobernanza. Comprender sus implicaciones es esencial para elegir el enfoque adecuado en el entorno de Fabric.

Comparación entre los modos de acceso

Esta es una tabla de comparación clara y concisa centrada en cómo y dónde se establece la seguridad en modo de identidad de usuario frente al modo de identidad delegada, desglosada por tipo de objeto y directivas de access de datos:

Modo de identidad de usuario en la seguridad de OneLake

En el modo de identidad de usuario, el punto de conexión de SQL Analytics usa un mecanismo de autenticación por transferencia directa para aplicar el acceso a los datos. Cuando un usuario se conecta al punto de conexión de SQL Analytics, su identidad Entra ID se pasa a OneLake, que realiza la comprobación de permisos. Todas las operaciones de lectura en tablas se evalúan mediante las reglas de seguridad definidas en OneLake Lakehouse, no mediante ninguna instrucción GRANT o REVOKE de nivel SQL.

Este modo le permite administrar la seguridad de forma centralizada, lo que garantiza una aplicación coherente en todas las experiencias de Fabric, incluidas Power BI, cuadernos, lakehouse y el endpoint de análisis de SQL. Está diseñado para modelos de gobernanza donde el acceso debe definirse una vez en OneLake y respetarse automáticamente en todas partes.

En el modo de identidad de usuario:

• La seguridad de OneLake gobierna por completo el acceso a la tabla. Se omiten las instrucciones SQL GRANT/REVOKE en las tablas.

• RLS (Row-Level Security), CLS (Column-Level Security) y Object-Level Security se definen en la experiencia de OneLake.

• Se permiten permisos sql para objetos que no son de datos, como vistas, procedimientos almacenados y funciones, lo que permite la flexibilidad para definir la lógica personalizada o los puntos de entrada orientados al usuario a los datos.

• Las operaciones de escritura no están soportadas en el endpoint de SQL Analytics. Todas las operaciones de escritura deben producirse a través de la página de Lakehouse en el portal de Fabric y están gobernadas por los roles del espacio de trabajo (Administrador, Miembro, Colaborador).

Comportamiento del rol en el espacio de trabajo

Los usuarios con el rol Administrador, Miembro o Colaborador en el nivel de área de trabajo no están sujetos a la aplicación de seguridad de OneLake. Estos roles tienen privilegios elevados y omitirán completamente las políticas RLS, CLS y OLS. Siga estos requisitos para asegurarse de que se respeta la seguridad de OneLake:

• Asignar usuarios al rol Visor en el área de trabajo o

• Comparta el punto de conexión de Lakehouse o SQL Analytics con los usuarios que usan permisos de solo lectura . Solo los usuarios con acceso de solo lectura tienen sus consultas filtradas según los roles de seguridad de OneLake.

Precedencia de roles: el acceso más permisivo prevalece

Si un usuario pertenece a múltiples roles de OneLake, el rol más permisivo define su acceso efectivo. Por ejemplo:

• Si un rol concede acceso completo a la tabla y otro aplica RLS para restringir las filas, el RLS no se aplicará.

• El rol de acceso más amplio tiene prioridad. Este comportamiento garantiza que los usuarios no estén bloqueados involuntariamente, pero requiere un diseño de roles cuidadoso para evitar conflictos. Se recomienda mantener roles restrictivos y permisivos excluyentes entre sí al aplicar controles de acceso de nivel de fila o columna.

Para obtener más información, consulte el modelo de control de acceso a datos para la seguridad de OneLake.

Sincronización de seguridad entre OneLake y el punto de conexión de SQL Analytics

Un componente crítico del modo de identidad de usuario es el servicio de sincronización de seguridad. Este servicio en segundo plano supervisa los cambios realizados en los roles de seguridad en OneLake y garantiza que esos cambios se reflejen en el punto de conexión de SQL Analytics.

El servicio de sincronización de seguridad es responsable de lo siguiente:

• Detectar cambios en los roles de OneLake, incluidos los nuevos roles, las actualizaciones, las asignaciones de usuario y los cambios en las tablas.

• Traducción de directivas definidas por OneLake (RLS, CLS, OLS) en estructuras de roles de base de datos compatibles con SQL equivalentes.

• Asegurarse de que los objetos de acceso directo (tablas provenientes de otros almacenes de datos) se validen correctamente para que se respete la configuración de seguridad original de OneLake, incluso cuando se acceda a ellos de forma remota.

Esta sincronización garantiza que las definiciones de seguridad de OneLake permanezcan autoritativas, lo que elimina la necesidad de intervención manual en el nivel de SQL para replicar el comportamiento de seguridad. Dado que la seguridad se aplica de forma centralizada:

• No puede definir RLS, CLS ni OLS directamente mediante T-SQL en este modo.

• Todavía puede aplicar permisos SQL a vistas, funciones y procedimientos almacenados mediante instrucciones GRANT o EXECUTE.

Errores de sincronización de seguridad y resolución

Comportamiento de los accesos directos con la sincronización de seguridad

La seguridad de OneLake se aplica en la fuente fiable, por lo que la sincronización de seguridad desactiva el encadenamiento de propiedad para tablas y vistas que implican atajos. Esto garantiza que los permisos del sistema de origen siempre se evalúan y respetan, incluso para las consultas de otra base de datos.

Como resultado:

• Los usuarios deben tener acceso válido en ambos el acceso directo origen (el Lakehouse actual o el punto de conexión de SQL Analytics) y el destino donde residen físicamente los datos.

• Si el usuario no tiene permiso en cualquiera de los lados, las consultas fallarán con un error de acceso.

• Al diseñar las aplicaciones o vistas que hacen referencia a métodos abreviados, asegúrese de que las asignaciones de roles estén configuradas correctamente en ambos extremos de la relación de acceso directo.

Este diseño conserva la integridad de seguridad a través de los límites de diferentes Lakehouse, pero introduce escenarios donde pueden ocurrir errores de acceso si los roles entre diferentes Lakehouse no están alineados.

Modo delegado en la seguridad de OneLake

En Delegated Identity Mode, el punto de conexión de SQL Analytics usa el mismo modelo de security que existe actualmente en Microsoft Fabric. La seguridad y los permisos se administran completamente en la capa SQL, y no se aplican los roles o políticas de acceso de OneLake para acceso a nivel de tabla. Cuando un usuario se conecta al punto de conexión de SQL Analytics y emite una consulta:

• SQL valida el acceso de acuerdo con los permisos SQL (GRANT, REVOKE, RLS, CLS, DDM, roles, etc.).

• Si la consulta está autorizada, el sistema procede a acceder a los datos almacenados en OneLake.

• Este acceso a datos se realiza mediante la identidad del propietario del punto de conexión de Lakehouse o SQL Analytics, también conocido como la cuenta de elemento.

En este modelo:

• El usuario que ha iniciado sesión no se pasa a OneLake.

• Se supone que todo el control de acceso se maneja en la capa de SQL.

• El propietario del elemento es responsable de tener permisos suficientes en OneLake para leer los archivos subyacentes en nombre de la carga de trabajo.

Dado que se trata de un patrón delegado, cualquier desalineación entre los permisos de SQL y oneLake access para el propietario produce errores de consulta. Este modo proporciona compatibilidad completa con:

• SQL GRANT/REVOKE en todos los niveles de objeto

• Seguridad a nivel de fila definida por SQL, seguridad a nivel de columna y enmascaramiento dinámico de datos

• Herramientas y prácticas de T-SQL existentes que usan los DBA o las aplicaciones

Cómo cambiar el modo de acceso de OneLake

El modo de acceso determina cómo se autentica y aplica el acceso a los datos al consultar OneLake a través del punto de conexión de SQL Analytics. Puede cambiar entre el modo de identidad de usuario y el modo de identidad delegada mediante los pasos siguientes:

1. Vaya al área de trabajo de Fabric y abra su lakehouse. Desde la esquina superior derecha, cambie de lakehouse a punto final de SQL Analytics.

2. En el panel de navegación superior, vaya a Seguridad y seleccione uno de los siguientes modos de OneLake access:

   • Identidad de usuario : usa la identidad del usuario que ha iniciado sesión. Aplica las funciones de OneLake.

   • Identidad delegada : usa la identidad del propietario del elemento; aplica solo los permisos de SQL.

3. Se inicia un elemento emergente para confirmar tu selección. Seleccione Sí para confirmar el cambio.

Consideraciones al cambiar entre modos

Cambio al modo de identidad de usuario

• SQL RLS, CLS y los permisos de nivel de tabla se omiten.

• Los roles de OneLake deben configurarse para que los usuarios mantengan acceso.

• Solo los usuarios con permisos de visualizador o accesos compartidos de solo lectura se regirán por la seguridad de OneLake.

• Los roles SQL existentes se eliminan y no se pueden recuperar.

Cambio al modo de identidad delegada

• Los roles de OneLake y las directivas de seguridad ya no se aplican.

• Los roles de SQL y las directivas de seguridad se activan.

• El propietario del elemento debe tener un acceso válido a OneLake, o todas las consultas pueden fallar.

Limitaciones

• Solo se aplica a los lectores: La seguridad de OneLake controla el acceso de los usuarios a los datos como visores. Los usuarios de otros roles de área de trabajo (administrador, miembro o colaborador) omiten la seguridad de OneLake y conservan el access completo.

• Los objetos SQL no heredan la propiedad: los accesos directos se muestran en el punto de conexión de SQL Analytics como tablas. Al acceder a estas tablas, ya sea directamente o a través de vistas, procedimientos almacenados y otros objetos SQL derivados, estos no poseen propiedad a nivel de objeto; todos los permisos se verifican en tiempo de ejecución para evitar la elusión de seguridad.

• Los cambios de acceso directo desencadenan el tiempo de inactividad de la validación: cuando un destino de acceso directo cambia (por ejemplo, cambiar el nombre, actualizar la dirección URL), la base de datos entra brevemente en modo de usuario único mientras el sistema valida el nuevo destino. Durante este período, las consultas se bloquean, estas operaciones son bastante rápidas, pero a veces, dependiendo de un proceso interno diferente, puede tardar hasta 5 minutos en sincronizarse.

  • La creación de métodos abreviados de esquema puede provocar un error conocido que afecta a la validación y retrasa la sincronización de metadatos.

• Propagación de permisos retrasada: los cambios de permisos no son instantáneos. Cambiar entre modos de seguridad (identidad de usuario frente a delegado) puede requerir tiempo para propagarse antes de surtir efecto, pero debe tardar menos de 1 minuto.

• Dependencia del plano de control: los permisos no se pueden aplicar a usuarios o grupos que aún no existen en el plano de control del área de trabajo. Necesita compartir el elemento de origen o el usuario debe ser miembro del rol Visor del área de trabajo. Tenga en cuenta que el mismo identificador de objeto debe estar en ambos lugares. Un grupo y un miembro de ese grupo no cuentan como coincidencia.

• El acceso más permisivo prevalece: Cuando los usuarios pertenecen a varios grupos o roles, se respeta el permiso efectivo más permisivo Ejemplo: si un usuario tiene tanto DENY a través de un rol como GRANT a través de otro, GRANT tiene prioridad.

• Limitaciones del modo delegado: En modo delegado, la sincronización de metadatos en tablas de acceso directo puede fallar si el elemento de origen tiene directivas de seguridad de OneLake que no conceden acceso completo a la tabla al propietario del elemento.

• Comportamiento de DENY: cuando varios roles se aplican a una misma tabla de acceso directo, la intersección de permisos sigue la semántica de SQL Server: DENY tiene prioridad sobre GRANT. Esto puede producir resultados inesperados de acceso.

• Condiciones de error esperadas: los usuarios pueden encontrar errores en escenarios como:

  • Destino de acceso directo cambiado o no válido

    • Ejemplo: si se eliminó el origen de la tabla.

  • Configuración incorrecta de RLS (Row-Level Security)

    • Algunas expresiones para el filtrado de RLS no se admiten en OneLake y podría permitir el acceso no autorizado a los datos.

    • Quitar la columna utilizada en la expresión de filtro invalida el RLS y la sincronización de metadatos estará desactualizada hasta que se corrija el RLS en el panel de seguridad de OneLake.

    • En versión preliminar pública, solo se admiten tablas de expresiones únicas. En este momento no se admiten RLS dinámicos ni RLS de varias tablas.

  • Limitaciones de Column-Level Security (CLS)

    • CLS funciona manteniendo una lista de permisos de las columnas. Si se quita o cambia el nombre de una columna permitida, la directiva CLS deja de ser válida.

    • Cuando CLS no es válido, la sincronización de metadatos se bloquea hasta que la regla CLS se fija en el panel de seguridad de OneLake.

  • Error de sincronización de metadatos o permisos

    • Si hay cambios en la tabla, como cambiar el nombre de una columna, la seguridad no se replica en el nuevo objeto y recibe errores de interfaz de usuario que muestran que la columna no existe.

• Los cambios de nombre de tabla no conservan las directivas de seguridad: si los roles de seguridad de OneLake (OLS) se definen en el nivel esquema, esos roles permanecen en vigor solo siempre que el nombre de la tabla no cambie. Cambiar el nombre de la tabla interrumpe la asociación y las directivas de seguridad no se migrarán automáticamente. Esto puede dar lugar a una exposición de datos no deseada hasta que se vuelvan a aplicar las directivas.

• Los roles de seguridad de OneLake no pueden tener nombres de más de 124 caracteres; de lo contrario, no se pueden sincronizar los roles de seguridad.

• Los roles de seguridad de OneLake se propagan en el endpoint de SQL Analytics con el prefijo OLS_.

• Los cambios de usuario en los roles de OLS_ no se admiten y pueden provocar comportamientos inesperados.

• No se admiten grupos de seguridad habilitados para correo y listas de distribución.

• El propietario de lakehouse debe ser miembro de los roles de área de trabajo de administrador, miembro o colaborador; De lo contrario, la seguridad no se aplica al punto de conexión de SQL Analytics.

• El propietario de Lakehouse no puede ser un principal de servicio para que la sincronización de seguridad funcione.

Contenido relacionado

• Procedimientos recomendados para proteger los datos en OneLake
• Modelo de control de acceso de seguridad de OneLake