Compatibilidad de Spark con la seguridad de OneLake (RLS y CLS)

Fabric Spark se integra con OneLake security para que las directivas de seguridad de nivel de fila (RLS) y seguridad de nivel de columna (CLS) definidas una vez en OneLake se apliquen de forma coherente cuando los usuarios lean tablas delta de lakehouse desde cuadernos de Spark y definiciones de trabajos de Spark. Los usuarios siguen escribiendo consultas estándar de Spark SQL o DataFrame; Spark filtra de forma transparente el resultado para que cada usuario vea solo las filas y columnas a las que está autorizado para acceder.

En este artículo se explica cómo funciona Spark con la seguridad de OneLake, incluida la arquitectura de cumplimiento, el flujo de preparación de datos, la experiencia del usuario y los escenarios y límites admitidos.

Nota:

Para la creación de directivas y el modelo entre motores, consulte Seguridad de nivel de fila en OneLake y Seguridad de nivel de columna en OneLake.

Conceptos de un vistazo

  • Una única fuente de verdad. Las reglas de RLS y las listas de columnas de CLS se definen una sola vez en el Lakehouse mediante los roles de seguridad de OneLake. Spark no almacena ni duplica la política.
  • Acceso efectivo independiente del motor. OneLake devuelve el acceso efectivo predefinido para el usuario solicitante, incluidas las columnas permitidas y los metadatos de filtro de fila RLS. Spark consume ese acceso efectivo en el momento de la consulta.
  • Filtrado de solo delta. La capa de plataforma OneLake y Fabric aplica RLS y CLS únicamente a tablas parquet del tipo Delta. La plataforma bloquea los objetos no Delta con reglas aplicadas, en lugar de que Spark los filtre.
  • Omisión de roles con privilegios. Con respecto al comportamiento de las plataformas OneLake y Fabric, el área de trabajo Admin, Member y Contributor no está restringida por RLS ni CLS. El filtrado se aplica al Visor y a los usuarios a los que se concede acceso a través de roles de seguridad de OneLake.

Cómo Aplica Spark la seguridad de OneLake

Cuando un usuario envía una consulta que involucra una tabla protegida de lakehouse, Spark prepara un plan de ejecución que combina la consulta del usuario con el acceso de seguridad efectivo de OneLake para ese usuario. El cumplimiento se produce durante la ejecución, no como un paso posterior al filtro en el código de usuario, por lo que no se puede omitir mediante APIs alternativas ni lecturas basadas en rutas de archivos alternativas.

Modelo de ejecución de dos contextos

Fabric Spark usa dos contextos de ejecución para mantener la evaluación de directivas aislada del código de usuario:

  • Contexto de usuario. Ejecuta el cuaderno del usuario o la definición de trabajo de Spark con la identidad del usuario. Este contexto planea la consulta y consume la salida filtrada, pero nunca tiene acceso directo y sin filtrar a las tablas protegidas.
  • Contexto del sistema (seguridad). Un contexto privilegiado, administrado por Microsoft, que resuelve el acceso efectivo del usuario en OneLake, lee los archivos Delta subyacentes, aplica el filtrado de filas RLS y las proyecciones CLS, y devuelve solo las filas y columnas que el usuario puede ver.

El contexto del sistema se muestra en el centro de supervisión como SparkSecurityControl trabajos que se ejecutan junto con la sesión del cuaderno del usuario. El nombre de la tarea y la experiencia de supervisión son el comportamiento de la plataforma Fabric. Estos trabajos se esperan e indican que la aplicación de seguridad de OneLake está activa.

Flujo de consulta para una tabla protegida

  1. El usuario ejecuta una consulta en un cuaderno de Spark, por ejemplo SELECT * FROM lakehouse.sales.
  2. Spark resuelve la tabla a través del catálogo lakehouse y detecta que la seguridad de OneLake está habilitada.
  3. Spark solicita el acceso efectivo para el usuario actual desde OneLake. La respuesta incluye la lista de columnas permitidas (CLS) y los metadatos de filtro de fila de RLS.
  4. El contexto de seguridad del sistema lee los archivos Delta, proyecta solo las columnas permitidas y aplica RLS (seguridad a nivel de filas) mediante el filtrado de filas con estilo bitmap o vector de eliminación durante la ejecución.
  5. El resultado filtrado se devuelve al contexto de usuario, que completa el resto de la consulta del usuario (combinaciones, agregaciones, escrituras en destinos no protegidos, etc.) en los datos ya filtrados.

¿Qué ocurre para cada tipo de directiva?

Política Qué devuelve Spark Notas
Solo RLS Todas las columnas, pero solo las filas permitidas por la regla RLS. El filtrado de filas se aplica en el contexto de seguridad mediante el filtrado de estilo de mapa de bits o el filtrado de estilo de vector de eliminación; los usuarios no pueden observar la lógica de filtro.
Solo CLS Solo las columnas permitidas; todas las filas. SELECT * se realiza correctamente y devuelve las columnas permitidas cuando se permite al menos una columna. Si no se permite ninguna columna, Spark produce un error en la consulta.
RLS + CLS en el mismo rol Filas permitidas transformadas en columnas permitidas. Se admite siempre que ambas reglas pertenezcan al mismo rol.
RLS en el rol A, CLS en el rol B (mismo usuario) Se produce un error en la consulta. La capa de plataforma OneLake y Fabric no admite que un usuario sea miembro de dos roles, donde uno define RLS y el otro define CLS. Consulte Seguridad de nivel de fila y Seguridad de nivel de columna.
Objeto no delta Acceso bloqueado. La capa de la plataforma OneLake y Fabric aplica RLS y CLS solo a tablas de parquet Delta; otros objetos en un rol de seguridad están bloqueados.

Para conocer las reglas canónicas de creación y la sintaxis de expresiones RLS, consulte los artículos seguridad de nivel de fila y seguridad de nivel de columna.

Cómo Spark prepara los datos para los usuarios

La seguridad de OneLake está diseñada para ser transparente para el consumidor de datos. Los usuarios siguen usando las API que ya conocen y Spark controla la resolución de directivas y el filtrado en su nombre.

Spark SQL

-- Returns only rows and columns the current user is authorized to see.
SELECT product_category, SUM(amount) AS total
FROM sales.transactions
GROUP BY product_category;

PySpark DataFrame

df = spark.read.table("sales.transactions")
df.filter("region = 'EMEA'").groupBy("product_category").sum("amount").show()

En ambos ejemplos, los datos de la tabla que se cargan en el transactions DataFrame ya están filtrados por la seguridad de OneLake. Las transformaciones posteriores funcionan solo sobre los datos filtrados.

El acceso directo a archivos está bloqueado

El acceso directo a la ruta omite la resolución de directivas del catálogo de Lakehouse. Cuando la seguridad de OneLake está habilitada en una tabla, la capa de plataforma OneLake y Fabric bloquea los siguientes patrones para los usuarios sin privilegios:

  • spark.read.format("delta").load("abfss://...")
  • DeltaTable.forPath(spark, "abfss://...")
  • OneLake REST/SDK realiza lecturas en la carpeta Tables/<table> de una tabla protegida.

Los usuarios deben acceder a las tablas protegidas a través del nombre de la tabla lakehouse (por ejemplo spark.read.table("lakehouse.table") , o Spark SQL) para que Spark pueda resolver y aplicar el acceso efectivo.

Experiencia del usuario

  • Filtrado transparente. No se requiere reescritura de consultas ni sintaxis especial. El mismo cuaderno funciona para los usuarios con distintos roles y devuelve datos específicos del rol.
  • Resultados coherentes entre motores. La misma regla de RLS y la proyección CLS que se aplica en Spark también se aplica en el endpoint de SQL Analytics, los modelos semánticos basados en Direct Lake y los motores de terceros autorizados. Consulte Introducción a las integraciones de seguridad de OneLake.
  • Los roles privilegiados lo ven todo. Como parte del comportamiento de las plataformas OneLake y Fabric, los usuarios de las áreas de trabajo Admin, Member y Contributor continúan viendo datos sin filtrar, lo que es útil para el desarrollo de canalizaciones, mantenimiento de tablas (OPTIMIZE, VACUUM) y resolución de problemas.
  • Monitorización. Los SparkSecurityControl trabajos que aparecen en el centro de supervisión corresponden al contexto del sistema que realiza la aplicación de directivas. El nombre del trabajo y la entrada del hub de monitoreo forman parte de las operaciones de la plataforma Fabric.

Marcador de captura de pantalla: Centro de monitoreo que muestra una tarea de SparkSecurityControl junto con la sesión del notebook del usuario.

Consideraciones sobre el rendimiento

  • Filtrado de filas por RLS. RLS se aplica cerca del escaneo Delta mediante el filtrado de estilo bitmap o estilo vector de eliminación y, donde sea compatible, el motor de ejecución nativa. Este diseño minimiza las filas que se materializan en el contexto del usuario.
  • Eliminación de columnas. Las listas de columnas CLS se combinan con la proyección del usuario. La intersección se lee solo desde el almacenamiento delta.
  • Caché de acceso eficiente Spark almacena en caché la directiva y los metadatos de acceso efectivo por consulta y los limpia cuando se detiene la ejecución de la consulta.
  • Uso de particiones y estadísticas. La eliminación de particiones delta estándar y la omisión de datos continúan aplicándose con el filtrado de filas RLS, por lo que las consultas en tablas con particiones siguen siendo eficaces.

Escenarios compatibles

  • Lectura de tablas Delta de Lakehouse en cuadernos de Spark y definiciones de trabajos de Spark a través del catálogo de Lakehouse (<lakehouse>.<table>).
  • APIs de DataFrame de Spark SQL y PySpark/Scala contra tablas protegidas.
  • Realiza combinaciones, agregaciones y transformaciones posteriores en tablas protegidas.
  • Escribe desde fuentes seguras a salidas inseguras. Las tablas de salida escritas fuera del lakehouse seguro contienen solo los datos ya filtrados que el usuario con permisos de escritura pudo leer.
  • Acceso cruzado a lakehouses entre áreas de trabajo a través de accesos directos, donde el lakehouse de origen tiene habilitada la seguridad de OneLake.

Limitaciones

OneLake security RLS y CLS en Spark heredan las limitaciones generales de seguridad de OneLake. Entre los comportamientos y límites importantes se incluyen:

  • La implementación de Spark RLS/CLS no admite entidades de servicio; solo se evalúan las identidades de usuario para las directivas de seguridad de nivel de fila y columna. Al ejecutar cuadernos utilizando la identidad del área de trabajo, no se aplicará RLS/CLS para la propia identidad del área de trabajo, sólo se aplicará a los usuarios individuales que ejecutan las consultas dentro del contexto del cuaderno.
  • La capa de plataforma OneLake y Fabric aplican solo RLS y CLS a tablas Delta parquet. Los objetos que no son Delta en un rol protegido están bloqueados.
  • La capa de la plataforma OneLake y Fabric bloquea las lecturas de acceso directo (abfss://, DeltaTable.forPath) en tablas protegidas para usuarios sin privilegios.
  • La capa de plataforma OneLake y Fabric no admite que un usuario sea miembro de dos roles, donde uno define RLS y el otro define CLS para las tablas afectadas.
  • Según el comportamiento de las plataformas OneLake y Fabric, los roles del área de trabajo Admin, Member y Contributor pueden pasar por alto RLS y CLS.
  • Las escrituras desde orígenes protegidos hacia salidas no protegidas están permitidas y operan sobre datos ya filtrados. Es posible que las escrituras (INSERT/UPDATE/DELETE/MERGE) en un destino protegido no sean compatibles para los usuarios sujetos a RLS o CLS; use una identidad con privilegios para las escrituras ETL en tablas protegidas.

Contenido relacionado

  • Last updated on