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

Con la seguridad de OneLake, Microsoft Fabric amplía la forma en que las organizaciones pueden administrar y aplicar el acceso a los datos en todas 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 punto de conexión de SQL Analytics

Al usar el punto de conexión de SQL Analytics, el modo de acceso seleccionado determina cómo se aplica la seguridad de los datos. Fabric admite dos modelos de acceso 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 el acceso de lectura 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 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 el modo de identidad de usuario frente al modo de identidad delegada, desglosada por tipo de objeto y directivas de acceso a 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 de paso a través 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, como Power BI, cuadernos, lakehouse y el punto de conexión de análisis de SQL. Está diseñado para los modelos de gobernanza en los que 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 rige completamente el acceso a las tablas. 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 se admiten en el punto de conexión de SQL Analytics. Todas las escrituras deben producirse a través de la interfaz de usuario de Lakehouse y se rigen por roles de área de trabajo (Administrador, Miembro, Colaborador).

Comportamiento del rol del área 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 directivas 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: la mayoría del acceso permisivo gana

Si un usuario pertenece a varios roles oneLake, el rol más permisivo define su acceso efectivo. Por ejemplo:

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

• 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 los roles restrictivos y permisivos mutuamente excluyentes al aplicar controles de acceso de nivel de fila o de 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 procedentes de otras casas de lago) se validan correctamente para que se respete la configuración de seguridad original de OneLake, incluso cuando se accede a él 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 y resolución de sincronización de seguridad

Comportamiento de accesos directos con sincronización de seguridad

La seguridad de OneLake se aplica en el origen de la verdad, por lo que la sincronización de seguridad deshabilita el encadenamiento de propiedad para tablas y vistas que implican accesos directos. 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 el origen de acceso directo (punto de conexión actual de Lakehouse o SQL Analytics) y en el destino donde residen físicamente los datos.

• Si el usuario no tiene permiso en cualquier lado, las consultas producirán 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 la seguridad a través de los límites de Lakehouse, pero presenta escenarios en los que pueden producirse errores de acceso si los roles entre Lakehouse no están alineados.

Modo delegado en la seguridad de OneLake

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

• SQL valida el acceso en función de los permisos DE SQL (GRANT, REVOKE, RLS, CLS, DDM, roles, etc.).

• Si la consulta está autorizada, el sistema continúa con el acceso 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 cuenta de elemento.

En este modelo:

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

• Se supone que todo el cumplimiento del acceso se controla 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 el acceso de OneLake para el propietario produce errores de consulta. Este modo proporciona compatibilidad completa con:

• SQL GRANT/REVOKE en todos los niveles de objeto

• Seguridad deRow-Level definida por SQL, seguridad deColumn-Level 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 lakehouse. Desde la esquina superior derecha, cambie de lakehouse a punto de conexión de SQL Analytics.

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

   • Identidad de usuario : usa la identidad del usuario que ha iniciado sesión. Aplica roles 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 la selección. Seleccione Sí para confirmar el cambio.

Consideraciones al cambiar entre modos

Cambio al modo de identidad de usuario

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

• Los roles oneLake deben configurarse para que los usuarios mantengan el acceso.

• Solo los usuarios con permisos de Visor o acceso compartido 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 acceso de OneLake válido o se pueden producir errores en todas las consultas.

Limitaciones

• Solo se aplica a los lectores: OneLake Security controla el acceso de los usuarios a los datos como visores. Los usuarios de otros roles de área de trabajo (miembro administrador o colaborador) omiten OneLake Security y conservan el acceso 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, directamente o a través de vistas, procedimientos almacenados y otros objetos SQL derivados, no llevan la propiedad de nivel de objeto; todos los permisos se comprueban en tiempo de ejecución para evitar la omisió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. Debe compartir el elemento de origen o el usuario debe ser miembro del rol de área de trabajo Visor. 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 : si un usuario tiene deny a través de un rol y 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 producir un error si el elemento de origen tiene directivas de OneLake Security que no conceden acceso completo a la tabla al propietario del elemento.

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

• 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 a datos no autorizados.

    • Quitar la columna usada en la expresión de filtro invalida la sincronización de metadatos y RLS estará obsoleta hasta que el RLS se corriga 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 permitidos de 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 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 OneLake Security (OLS) se definen en el nivel de 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