Seguridad de OneLake para puntos de conexión de SQL Analytics

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 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 el acceso de lectura se rige por completo por las reglas de seguridad definidas en OneLake. Se admiten permisos de nivel SQL en objetos que no son de datos (vistas, procedimientos almacenados, funciones), 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.

Importante

Acceso al artefacto necesario para usar el punto de conexión de SQL Analytics. Para conectarse a datos y consultarlos a través de un punto de conexión de SQL Analytics, los usuarios deben tener permiso de lectura en el artefacto asociado al punto de conexión. Si un usuario no tiene acceso al plano de control del artefacto (como acceso a roles del espacio de trabajo o permiso explícito para un elemento), se rechazará la conexión al punto de conexión de análisis SQL, independientemente de cualquier permiso de SQL que ese usuario pueda tener.

Comparación entre los modos de acceso

En la tabla siguiente se compara 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 acceso a datos:

Objetivo de seguridad Modo de identidad de usuario Modo de identidad delegada
Tables El acceso está controlado mediante roles de seguridad de OneLake. No se permite SQL GRANT/REVOKE . Control total mediante SQL GRANT/REVOKE.
Views Use SQL GRANT/REVOKE para asignar permisos. Use SQL GRANT/REVOKE para asignar permisos.
procedimientos almacenados Use SQL GRANT EXECUTE para asignar permisos. Use SQL GRANT EXECUTE para asignar permisos.
Funciones Utilice SQL GRANT EXECUTE para asignar permisos. Use SQL GRANT EXECUTE para asignar permisos.
Seguridad a Nivel de Fila (RLS) Se define en oneLake UI como parte de los roles de seguridad de OneLake. Definido mediante SQL CREATE SECURITY POLICY.
Seguridad a Nivel de Columna (CLS) Se define en oneLake UI como parte de los roles de seguridad de OneLake. Se define mediante SQL GRANT SELECT con la lista de columnas.
Enmascaramiento dinámico de datos (DDM) No es compatible con la seguridad de OneLake. Se define mediante SQL ALTER TABLE con la opción MASKED.

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 por declaraciones de nivel SQL como GRANT o REVOKE.

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).

Importante

Asignación de identidades uno a uno entre el productor y el consumidor (concentrador y radio). Cuando las políticas de seguridad de OneLake se transfieren de un productor (el elemento de origen donde se define el rol) a un consumidor (un elemento de destino que accede a los datos mediante un acceso directo), las identidades asignadas a los roles de seguridad de OneLake en el productor deben corresponder exactamente 1:1 en el consumidor. El mismo principal (ya sea un usuario o un grupo) debe tener concedido el permiso de lectura de Fabric en el artefacto del consumidor como el que se menciona en el rol de seguridad del productor. La pertenencia a grupos anidada o efectiva no se resuelve a través de este límite.

Por ejemplo, si el rol de seguridad de OneLake en el productor hace referencia a user123@microsoft.com, user123@microsoft.com (ese identificador de objeto exacto) también debe tener permiso de lectura de Fabric en el lago casa del consumidor. Del mismo modo, si el rol de productor hace referencia a Group A, Group A debe tener permiso de lectura de Fabric en el consumidor —conceder ese permiso solo a un miembro del Grupo A no satisface el requisito.

Para obtener más información sobre el modelo de permisos con el modo de identidad del usuario, 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 de SQL a vistas, funciones y procedimientos almacenados mediante instrucciones GRANT o EXECUTE.

Estrategia de retroceso para reintentos de sincronización de seguridad

La sincronización de seguridad incluye un mecanismo de retroceso en los reintentos para proteger la estabilidad del sistema y evitar el consumo innecesario de recursos computacionales.

  • Si se producen errores repetidos al aplicar roles de seguridad de OneLake al punto de conexión de SQL Analytics, el sistema puede pausar temporalmente los intentos de sincronización automática.

  • La sincronización se reanuda automáticamente cuando se modifica un rol de seguridad de OneLake existente o se crea uno nuevo.

Errores de sincronización de seguridad y su resolución

Scenario Comportamiento en el modo de identidad de usuario Comportamiento en modo delegado Acción correctiva Notas
La directiva RLS hace referencia a una columna eliminada o cuyo nombre ha cambiado Error: La directiva de seguridad de nivel de fila hace referencia a una columna que ya no existe. La base de datos entra en estado de error hasta que se corrija la directiva. Error: Nombre de columna no válido <nombre de columna> Actualice o quite uno o varios roles afectados o restaure la columna que falta. La actualización debe realizarse en la instancia de Lakehouse donde se creó el rol.
La directiva CLS hace referencia a una columna eliminada o cuyo nombre ha cambiado Error: la directiva de seguridad de nivel de columna hace referencia a una columna que ya no existe. La base de datos escribe el estado de error hasta que se corrigió la directiva. Error: Nombre de columna no válido <nombre de columna> Actualice o quite uno o varios roles afectados o restaure la columna que falta. La actualización debe realizarse en el lakehouse donde se haya creado el rol.
La directiva RLS/CLS hace referencia a una tabla eliminada o cuyo nombre ha cambiado Error: la directiva de seguridad hace referencia a una tabla que ya no existe. No se ha producido ningún error; la consulta falla silenciosamente si falta la tabla. Actualice o quite uno o varios roles afectados o restaure la tabla que falta. La actualización debe realizarse en el lakehouse donde se creó el rol.
La directiva DDM (enmascaramiento dinámico de datos) hace referencia a una columna eliminada o cuyo nombre se ha cambiado DDM no es compatible con la seguridad de OneLake; debe implementarse a través de SQL. Error: Nombre de columna no válido <nombre de columna> Actualice o quite una o varias reglas DDM afectadas o restaure la columna que falta. Actualice la directiva DDM en el endpoint de análisis de SQL.
Error del sistema (error inesperado) Error: se produjo un error inesperado del sistema. Inténtelo de nuevo o póngase en contacto con el soporte técnico. Error: se ha producido un error interno al aplicar los cambios de tabla a SQL. Vuelva a intentar la operación; si el problema persiste, póngase en contacto con Soporte técnico de Microsoft. N/A
El usuario no tiene permiso en el artefacto Error: El usuario no tiene permiso en el artefacto Error: El usuario no tiene permiso en el artefacto Proporcione al usuario objectID {objectID} permiso para el artefacto. El identificador de objeto debe coincidir exactamente entre el miembro del rol de seguridad de OneLake y los permisos de elementos de Fabric. Si se agrega un grupo a la membresía de rol, ese mismo grupo debe tener el permiso de lectura de Fabric. Agregar un miembro de ese grupo al elemento no cuenta como coincidencia directa.
No se admite el principal de usuario Error: Principal de usuario no es compatible. Error: Principal de usuario no es compatible. Quite el usuario {username} del rol DefaultReader. Este error se produce si el usuario ya no es un Entra ID válido (por ejemplo, el usuario abandonó la organización o se eliminó). Quítelos del rol para resolver el error.

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 ninguno de los lados, las consultas fallarán con un error de acceso.

  • Al diseñar aplicaciones o vistas que hacen referencia a accesos directos, 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 modo de identidad delegada, el punto de conexión de SQL Analytics mantiene la compatibilidad hacia atrás con el modelo de seguridad de SQL tradicional. La seguridad se define y aplica en la capa del motor de SQL y los roles de seguridad y directivas de acceso de OneLake no se transfieren al acceso de nivel de tabla. Todos los filtros y el control de acceso, incluido el acceso a esquemas y tablas, Row-Level Security (RLS), Column-Level Security (CLS) y Dynamic Data Masking (DDM) deben definirse mediante construcciones SQL (GRANT/REVOKE, directivas de seguridad, etc.).

Dado que los roles de seguridad de OneLake para el usuario final no se aplican directamente, las reglas de seguridad definidas en OneLake (por ejemplo, las reglas aplicadas por Spark u otros motores que leen a través de OneLake) no se aplicarán cuando se consulten los mismos datos a través del punto de conexión de SQL Analytics. Elija este modo cuando la carga de trabajo dependa de la semántica de seguridad nativa de SQL o cuando las herramientas de T-SQL existentes requieran compatibilidad completa.

Cuando un usuario se conecta al punto de conexión de SQL Analytics y emite una consulta:

  • SQL valida la consulta con los permisos definidos en la capa de SQL.

  • 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, no el usuario que ha iniciado sesión.

Por lo tanto, el propietario del elemento es responsable de tener permisos suficientes en OneLake para leer los archivos subyacentes en nombre de la carga de trabajo. Cualquier desalineación entre los permisos de SQL concedidos a los usuarios finales y el acceso de OneLake del propietario del elemento produce errores de consulta.

Este modo admite las herramientas y prácticas de T-SQL existentes que usan los DBA o las aplicaciones, con compatibilidad completa con SQL GRANT/REVOKE en todos los niveles de objeto y RLS, CLS y DDM definidos por SQL.

Comportamiento de atajos en modo delegado

Dado que el modo delegado se conecta a OneLake mediante la identidad del propietario del elemento, los accesos directos solo funcionan cuando el propietario tiene acceso sin restricciones a toda la tabla de origen. Si la tabla de origen tiene aplicada una regla de seguridad de nivel OneLake, como Row-Level Security (RLS) o Column-Level Security (CLS), el punto de conexión de análisis de SQL bloquea el acceso a ese acceso directo.

Como resultado:

  • Los accesos directos que apuntan a tablas de origen sin reglas de seguridad de nivel de datos funcionan normalmente en modo delegado.

  • Los accesos directos que apuntan a tablas de origen con RLS o CLS en la seguridad de OneLake del productor no son accesibles a través del endpoint de SQL Analytics en modo delegado, incluso cuando el usuario final tiene permisos SQL en el objeto de acceso directo.

  • Para consumir accesos directos cuyo origen tiene directivas de seguridad de OneLake, use el modo de identidad de usuario en el punto de conexión de consumidor para que la identidad del usuario final se evalúe con respecto a las reglas de seguridad de OneLake del origen.

Cómo cambiar el modo de acceso de OneLake

El modo de acceso determina cómo se autentica y se aplica el acceso a los datos cuando se consulta 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 endpoint 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 tu selección. Seleccione Sí para confirmar el cambio.

Importante

Cambiar el modo de seguridad temporalmente hace que los puntos de conexión de SQL Analytics no estén disponibles en todo el área de trabajo. Esta acción cancela todas las consultas en ejecución y en cola en todos los puntos de conexión de SQL Analytics de esa área de trabajo. Cambie los modos solo si es necesario y preferiblemente durante las horas no laborables para evitar el tiempo de inactividad.

Consideraciones al cambiar entre modos

Importante

Al cambiar entre la identidad de usuario y los modos delegados (en cualquier dirección), actualmente se quitan los objetos de metadatos insertados, incluidas las funciones con valores de tabla (TVF) y las funciones con valores escalares. Este comportamiento solo afecta a las definiciones de metadatos; Los datos subyacentes de OneLake no se ven afectados.

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 Visor o acceso compartido de solo lectura se rigen 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.

Observaciones

  • Los objetos SQL no heredan la propiedad: los atajos funcionan como tablas en el punto de conexión de análisis de SQL, pero se desvían intencionadamente del encadenamiento de propiedad estándar de SQL para mantener una postura de seguridad unificada.

    • Regla sin herencia: los objetos SQL derivados (vistas, procedimientos almacenados o funciones) no heredan permisos del propietario del objeto.

    • Validación en tiempo de ejecución: los permisos se comprueban con la identidad del autor de la llamada en tiempo de ejecución, lo que garantiza que las abstracciones de SQL no pueden eludir las directivas de nivel de OneLake.

    • Security por diseño: las directivas de seguridad siguen siendo coherentes si se accede a los datos a través de SQL, Spark o Power BI.

  • Dependencia del plano de control (coincidencia de identidad estricta): la seguridad oneLake requiere que la identidad concedida al productor sea la misma identidad reconocida durante la evaluación de acceso en el plano de datos del consumidor. El sistema valida la entidad de seguridad específica a la que se concedió acceso en el origen y no expande la pertenencia a grupos anidados ni infiere el acceso efectivo a través de la pertenencia indirecta.

    • Coincidencia literal del principal: el acceso se evalúa en función del ID de objeto exacto otorgado por el productor.

    • No hay resolución anidada o efectiva: La pertenencia a grupos anidados o la herencia indirecta no se considera suficiente para la aplicación. Consulte la sección en modo de identidad de usuario en la seguridad de OneLake para obtener un ejemplo práctico.

  • Comportamiento de evaluación de permisos: la evaluación de permisos varía según el tipo de tabla en función del modelo de cumplimiento actual.

    • Tablas de acceso directo: se puede denegar el acceso cuando no se cumplen las condiciones de autorización necesarias. Se trata de un resultado restrictivo de cumplimiento, no una funcionalidad DENY basada en roles en la seguridad de OneLake.

    • Regla general: cuando el cumplimiento no puede validar claramente el acceso, el sistema aplica el resultado más restrictivo.

  • Diseño de Seguridad a Nivel de Columna (CLS): CLS mantiene una lista estricta de permitidos de columnas.

    • Cambiar el nombre o quitar una columna permitida invalida la regla de seguridad. Aunque la regla persiste en el sistema, permanece inactiva (denegando todo el acceso al recurso) hasta que se restaure la nomenclatura de columna original.

    • Protección de sincronización: cuando una directiva no es válida, la sincronización de metadatos está bloqueada por diseño hasta que la regla se corrija en el panel de seguridad de OneLake.

    • Validación del esquema: cambiar el nombre de las columnas sin actualizar las directivas de seguridad desencadena errores de interfaz de usuario que indican que la columna "no existe" hasta que se sincroniza la configuración.

  • Propagación y sincronización de roles (SLA):

    • Sincronización de seguridad de OneLake: cuando un rol de seguridad de OneLake cambia en la modalidad de identidad de usuario, la actualización no es inmediata. Aunque normalmente es rápido, puede tardar hasta 5 minutos en sincronizarse con el punto de conexión de SQL Analytics.

    • Prefijo automático: Los roles de seguridad de OneLake se propagan al extremo de análisis SQL con el OLS_ prefijo.

    • Prioridad de sincronización: el proceso de sincronización de seguridad actualiza periódicamente el estado de OLS_ los roles. No se admiten cambios manuales en estos roles y se sobrescriben durante el siguiente ciclo de sincronización. Si no hay ningún cambio en la sincronización, la sincronización de seguridad no invalida los cambios manuales.

  • Seguridad y métodos abreviados de SQL de almacenamiento: las directivas de seguridad definidas mediante construcciones SQL en un almacén, como Row-Level Security (RLS), Column-Level Security (CLS) o Object-Level Security (OLS), solo se aplican dentro del contexto de ejecución de SQL del almacenamiento (punto de conexión de TDS).

Importante

Cuando se accede a los datos de un almacén a través de accesos directos de OneLake, esta semántica de seguridad de SQL no se traduce en directivas de seguridad de OneLake. Como resultado, los usuarios que acceden a los datos a través de un acceso directo pueden ver el conjunto de datos completo, independientemente de las directivas de seguridad de SQL configuradas en el almacenamiento de origen.

Limitaciones

  • Se aplica solo a los lectores: la seguridad de OneLake se aplica principalmente a los usuarios que acceden a los datos a través del área de trabajo de nivel Viewer o mediante el acceso a ítems. Los usuarios con roles de área de trabajo más amplios, como Administrador, Miembro o Colaborador , conservan el acceso elevado y no son el destino principal de la aplicación de seguridad de OneLake.

    • Excepciones:

      • Comportamiento de denegación de acceso directo: en el caso de las tablas respaldadas por acceso directo, el cumplimiento todavía puede denegar el acceso a administradores, miembros o colaboradores en casos específicos.

      • Casos de error de sincronización de seguridad: si la sincronización de seguridad no puede aplicar la seguridad correctamente para determinadas tablas o roles, los usuarios de roles de administrador, miembro o colaborador que son miembros de esos roles afectados también pueden experimentar acceso restringido.

      • RLS en modo de identidad de usuario: cuando Row-Level Seguridad (RLS) está configurado en modo de identidad de usuario, se aplican las reglas de seguridad definidas para todos los usuarios, incluidos los de roles de administrador, miembro y colaborador.

  • Dependencia de sincronización de seguridad: en el modo de identidad de usuario, los roles de seguridad de OneLake se sincronizan con el punto de conexión de SQL Analytics a través del proceso de sincronización de seguridad. Hasta que se complete la sincronización, SQL puede evaluar temporalmente el acceso mediante el estado de permiso de SQL existente. Una vez finalizada la sincronización, el punto de conexión de SQL refleja la configuración de seguridad de OneLake.

  • Reconocimiento de límites de atajos: el punto de conexión de SQL Analytics puede evaluar inicialmente las tablas respaldadas por atajos mediante la semántica de objetos SQL estándar. Una vez que se produce la sincronización de seguridad, las directivas de seguridad de OneLake se aplican para asegurarse de que la aplicación de acceso se alinea con los límites del artefacto y del área de trabajo.

  • Momento de aplicación del acceso entre artefactos: El acceso a las tablas respaldadas por accesos directos de OneLake que hacen referencia a datos de otros artefactos se aplica mediante los roles de seguridad sincronizados de OneLake. Hasta que se produzca la sincronización, la autorización de SQL puede reflejar temporalmente el estado de permiso anterior.

  • Cambios de propiedad en tablas respaldadas por acceso directo: las tablas respaldadas por acceso directo se representan como objetos SQL en el punto de conexión de SQL Analytics y, por tanto, admiten operaciones de propiedad de SQL estándar. Los comandos administrativos como ALTER AUTHORIZATION pueden cambiar el propietario de una tabla respaldada por acceso directo. En determinados escenarios, esto puede permitir el comportamiento de encadenamiento de propiedad que omite las directivas de seguridad de OneLake y concede acceso no deseado a los datos subyacentes. Hasta que se introduzcan mecanismos de cumplimiento adicionales, los administradores deben evitar modificar la propiedad en tablas respaldadas por acceso directo.

  • Tiempo de inactividad para la validación de destino: cuando cambia un destino de acceso directo (por ejemplo, cambiarle el nombre o actualizar una URL), la base de datos pasa brevemente a modo de usuario único mientras el sistema valida el nuevo destino. Durante este período, se bloquean las consultas. Estas operaciones suelen ser rápidas, pero, en función de los procesos internos, pueden 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.

  • Almacenamiento en caché de tokens de modo delegado: en modo delegado, el punto de conexión de SQL Analytics almacena en caché el token de acceso de almacenamiento que se usa para recuperar datos de OneLake en nombre de la identidad del propietario. Si cambian los permisos del propietario, un token emitido anteriormente puede permanecer válido hasta que expire. Como resultado, los cambios de acceso vinculados a la identidad del propietario pueden no surtir efecto inmediatamente y pueden persistir hasta la expiración del token, normalmente de hasta 30 a 60 minutos.

  • Los cambios en las directivas de seguridad GRANT/DENY de OneLake se aplican inmediatamente y no se ven retrasados por el almacenamiento en caché del token.

  • Cancelación de consultas activas: para mantener la integridad y la seguridad de los datos, las consultas activas se pueden cancelar automáticamente si cambia una configuración de acceso directo durante la ejecución.

  • restricciones de Row-Level Security (RLS):

    • En versión preliminar pública, solo se admiten tablas de expresión única. RLS dinámico y RLS de varias tablas no están disponibles.

    • Al quitar una columna usada en una expresión de filtro, se detiene la sincronización de metadatos hasta que el RLS se fija en el panel de seguridad de OneLake.

  • Complejidad del rol y sincronización de metadatos: la alta complejidad de los roles de seguridad( específicamente las que implican numerosas intersecciones y semántica de unión mediante RLS) puede provocar un error en la sincronización de seguridad. Una sincronización de seguridad con errores impide que se apliquen directivas de seguridad y bloquea la capacidad de sincronizar metadatos.

  • Restricciones de esquema y rol:

    • Cambio de nombre: los roles de seguridad de OneLake están vinculados al nombre de la tabla. Cambiar el nombre de una tabla interrumpe la asociación y las directivas no se migran automáticamente. Esto puede dar lugar a una exposición de datos no deseada hasta que se vuelvan a aplicar las directivas.

    • Límites de caracteres: los nombres de rol de seguridad de OneLake no pueden superar los 124 caracteres; De lo contrario, se produce un error en la creación o sincronización de roles en el punto de conexión de SQL Analytics.

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

  • Identidades no admitidas: actualmente no se admiten grupos de seguridad habilitados para correo y listas de distribución.

  • Requisitos de propietario de Lakehouse:

    • El propietario de Lakehouse debe ser miembro de los roles de área de trabajo Administrador, Miembro o Colaborador. De lo contrario, la seguridad no se aplica al endpoint de SQL Analytics.

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

Contenido relacionado

  • Last updated on