Más allá de la incrustación: cómo proteger los dashboards de AI/BI para cada usuario

El desafío

Integrar un panel de Databricks AI/BI en una aplicación orientada al cliente es relativamente sencillo: habilite la integración, genere un token con alcance en el backend y renderice el panel con el SDK del cliente. La guía fundamental, Cómo integrar paneles de Databricks AI/BI en aplicaciones orientadas al cliente, explica ese proceso de principio a fin.

La pregunta más difícil es la autorización: una vez integrado el panel, ¿qué filas debe ver cada lector? Un socio debería ver solo sus propios datos, mientras que un equipo interno podría ver solo su región. Esta guía muestra cómo aplicar esas reglas.

Este patrón de referencia combina varias capacidades de Databricks: __aibi_external_value, Unity Catalog row filters and column masks, y grupos sincronizados desde un proveedor de identidad (IdP). Es un patrón de diseño, no una única función que deba habilitarse.

Un único conjunto de reglas, dos vías de aplicación

La misma tabla de permisos (entitlements) rige dos vías: los paneles integrados a los que se accede a través de la aplicación y las consultas SQL directas ejecutadas por los usuarios de Databricks.

Un escenario concreto

Considere una empresa que utiliza un panel compartido de "Tareas pendientes de cuentas por cobrar (AR)" para datos de tres regiones: West, East y Central. El panel sirve a dos audiencias.

• Los socios operativos externos, como Acme Ops, Bolt Partners y Core Logistics, no tienen inicio de sesión en Databricks y acceden al panel a través de un portal de marca blanca. Cada socio debe ver solo su propia región, con los correos electrónicos de contacto enmascarados.
• Los equipos internos son los empleados de la empresa, que inician sesión en Databricks. El equipo de Finanzas (Finance) necesita acceso a todas las regiones, mientras que un equipo de operaciones regionales ve solo la suya. Su acceso proviene de grupos del proveedor de identidad como Okta o Entra ID, no de listas de usuarios mantenidas manualmente.

Cinco lectores comparten un mismo conjunto de datos, y cada uno ve una parte diferente: Acme Ops, Bolt Partners, Core Logistics, Finance y un equipo de operaciones regionales. Los siguientes ejemplos se centran en Acme y Finance; los identificadores partner_acme, finance_all y West representan esos ejemplos. Acme ve West con los correos electrónicos enmascarados, mientras que Finance ve las tres regiones al completo, ambos desde el mismo panel publicado.

Una tabla, una vista, un panel

Las reglas de acceso residen en un solo lugar en vez de estar dispersas en paneles o consultas. Crear un panel por cliente genera copias que pueden desincronizarse, mientras que repetir los filtros en cada consulta aumenta la posibilidad de cometer errores.

El modelo consta de tres objetos:

• La tabla base `open_ar_tasks` contiene una fila por tarea de AR, etiquetada con una región y un correo electrónico de contacto.

• La tabla de permisos (entitlements) es la única fuente de verdad para el acceso. Cada fila identifica la región a la que puede acceder un alcance (scope) y si los valores confidenciales deben enmascararse. La columna viewer_scope almacena tanto los ID de socios externos, como partner_acme, como los nombres de grupos internos, como finance_all.

• La vista protegida une la tabla base con la de permisos, de modo que un lector solo ve las regiones autorizadas, con los correos electrónicos enmascarados cuando la marca (flag) está activada.

En la mayoría de las implementaciones, un sistema de permisos ascendente o un mapeo de grupo a región propiedad de la aplicación alimenta esta tabla; no se edita manualmente para cada lector.

Esto evita tener paneles por cliente y filtros repetidos en las consultas. Las reglas residen en una tabla que se puede consultar, auditar y modificar sin necesidad de cambiar el panel.

Aplicada por lector, la vista protegida devuelve solo aquello a lo que ese lector tiene derecho:

Acme (external_value = partner_acme): solo West, correo electrónico de contacto enmascarado.

Finance (external_value = finance_all): las tres regiones, correo electrónico de contacto completo.

De dónde proviene __aibi_external_value

El backend establece este valor cuando genera el token de integración. Se autentica como un principal de servicio (service principal) y solicita un token con alcance a Databricks con dos valores: external_viewer_id, que identifica al lector para fines de auditoría, y external_value, que representa el alcance (scope) del lector. Databricks firma el token y el lector no puede modificar el valor integrado, el cual se expone al SQL del panel como __aibi_external_value. Debido a que contiene las credenciales del principal de servicio, este backend es un componente seguro del lado del servidor, nunca del navegador, y esas credenciales se guardan en un gestor de secretos en lugar de en el control de código fuente.

El detalle clave es qué identidad ejecuta la consulta. Las consultas integradas se ejecutan bajo la identidad de publicación configurada, no bajo la identidad de Databricks del lector.

Para la integración externa, Databricks recomienda permisos de datos individuales y otorgar al principal de servicio su propio acceso a los datos, de modo que las consultas se ejecuten como el principal de servicio. (Por el contrario, publicar con permisos de datos compartidos ejecuta las consultas con las credenciales del publicador). Luego, la vista restringe ese acceso para cada lector a través de __aibi_external_value. Dado que la consulta se ejecuta como el principal de servicio, is_account_group_member() no puede identificar a la persona real que está viendo el panel en la ruta de integración.

El detalle importante es que external_value no se limita a un ID de socio. Puede ser cualquier alcance (scope) que el backend firme en el token, por ejemplo, partner_acme para un socio externo o finance_all para un grupo interno (su nombre de grupo).

Dado que la tabla de permisos contiene los ID de los socios y los nombres de los grupos en la misma columna, un solo panel, una sola vista y un solo filtro cubren ambos casos.

Dado que el lector nunca ve ni establece el valor firmado, no puede cambiarlo. Un alcance desconocido no coincidirá con ninguna fila, lo que proporciona un comportamiento de denegación por defecto.

La misma vista y el mismo filtro (WHERE viewer_scope = __aibi_external_value) sirven para ambas audiencias. Solo difiere el origen de ese alcance:

Otorgue acceso a grupos, no a personas

Las organizaciones suelen gestionar el acceso a través de grupos sincronizados desde un proveedor de identidad. Cuando alguien se une al grupo Finance en Okta, su acceso se asigna a finance_all automáticamente, sin necesidad de tocar ninguna tabla de datos. En este ejemplo, finance_all se asigna a todas las regiones y ops_west se asigna a la región West.

¿Cómo sabe la aplicación qué grupos pertenecen al visor? No puede depender de SQL durante la incrustación, porque la consulta se ejecuta como la entidad de servicio e is_account_group_member() verificaría la identidad incorrecta. La aplicación debe resolver los grupos del visor en el backend, que puede ver al visor, antes de generar el token.

Una opción es ejecutar la aplicación en Databricks Apps con la autorización de usuario habilitada.

Para un usuario interno que ha iniciado sesión, la plataforma reenvía el contexto de identidad de confianza al backend, incluido el correo electrónico del visor y un token on-behalf-of (OBO). El backend utiliza ese token para llamar a SCIM /Me como el visor y leer sus grupos.

Este enfoque no requiere derechos de administrador en la entidad de servicio, porque el usuario está leyendo su propio registro. Sí requiere alcances de autorización de usuario, y Apps OBO aún está madurando, por lo que debe validarlo con la implementación de destino antes de confiar en él.

Si no se encuentra ningún grupo con derechos, aplique un fallo de seguridad (fail closed) y rehúse generar un token en lugar de recurrir a una identidad más amplia como el correo electrónico sin procesar.

Si un visor pertenece a varios grupos con derechos, resuelva el resultado de forma determinante. Defina un orden de prioridad o asocie varios grupos a un único alcance canónico antes de generar el token, para que el mismo visor siempre reciba un acceso coherente.

Los socios externos son más sencillos. Al no tener una identidad de Databricks, su alcance es un id de socio fijo asignado al iniciar sesión. Mismo token, mismo filtro, sin búsquedas.

Una limitación que se debe tener en cuenta al diseñar: un token firmado contiene un único external_value. Si un visor pertenece a varios grupos con diferentes derechos, un token solo puede representar un alcance. Para el caso común de un rol por persona, esto es correcto.

Para una verdadera unión de múltiples grupos, utilice un grupo de acceso total o la ruta SQL directa que se muestra a continuación, donde un filtro de filas puede aplicar un operador OR en todos los grupos. Se puede empaquetar un alcance compuesto (como JSON) en external_value, pero luego el análisis y la coincidencia se trasladan al SQL del conjunto de datos y siguen limitados por el límite de carga útil de 1 KB.

Refuerzo de las garantías

El filtrado de filas ofrece el comportamiento básico: cada visor ve solo sus filas. Tres capas adicionales refuerzan los controles, y las tres leen de la misma tabla de derechos.

Enmascarar columnas sensibles por visor

La seguridad a nivel de fila determina a qué filas puede acceder un visor. El enmascaramiento determina qué columnas pueden ver, ya que los socios externos no suelen necesitar el mismo nivel de detalle que los equipos internos.

La bandera mask_pii, true para los socios y false para los grupos internos, dirige la lógica de enmascaramiento en la vista protegida (la expresión CASE en el SQL anterior). El mismo tablero puede mostrar a un visor interno el correo electrónico completo mientras muestra a un socio un valor enmascarado como ****@example.com. Cuando las reglas de enmascaramiento abarcan muchas tablas y se vuelven complejas, las máscaras de columna de Unity Catalog y el control de acceso basado en atributos (ABAC) son la mejor opción a largo plazo; aquí la vista mantiene el ejemplo autocontenido.

Denegar por defecto y demostrarlo

Un alcance desconocido no debería devolver ninguna fila del tablero y no debería revelar nada sobre la estructura de datos subyacente: ningún error que sugiera la estructura, ningún dato parcial, solo un resultado vacío. Detener el proceso antes es aún más limpio: antes de que el backend genere un token, comprueba la tabla de derechos y rechaza cualquier alcance con derecho a cero filas. Igual de importante es que el alcance se deriva del visor autenticado, nunca de un parámetro proporcionado por el cliente, por lo que un visor no puede solicitar el alcance de otro inquilino.

La restricción en la emisión de tokens evita que un visor denegado reciba un token, lo cual es mejor que confiar en el filtro SQL como única protección. Registrar tanto la emisión de tokens exitosa como las solicitudes denegadas hace que las decisiones de autorización sean auditables: el visor denegado simplemente nunca aparece, e incluso si se filtrara una solicitud, un alcance desconocido no devolvería ninguna fila del tablero. Registrar el external_viewer_id y su alcance en esos registros permite rastrear cada decisión de autorización hasta un cliente o usuario real durante una auditoría.

Proteger la ruta SQL directa

Los controles de incrustación protegen la ruta de la aplicación. Un usuario de Databricks que consulta la tabla base directamente representa una amenaza independiente. Agregue un filtro de filas de Unity Catalog a la tabla base, asociado a la identidad y los grupos del usuario que realiza la consulta. En esta ruta de consulta directa, is_account_group_member() evalúa al usuario real y puede combinar todos sus grupos con derechos. La excepción del publicador en la siguiente función (current_user() igual a la identidad de publicación) es una concesión deliberada de emergencia (break-glass) para la identidad que publica o actualiza el tablero, no una omisión general para el operador. Es opcional y de alto riesgo, por lo que debe incluirse solo cuando esté justificado y aprobarse por implementación.

Una máscara de columna para campos sensibles funciona de la misma manera. Estos controles de Unity Catalog son independientes de la ruta de incrustación: los visores incrustados se limitan a través de __aibi_external_value y la vista de derechos, mientras que las consultas directas del espacio de trabajo están protegidas por el filtro de filas de Unity Catalog, que evalúa la identidad y los grupos del emisor de la llamada. Ambos puntos de control utilizan la misma tabla de derechos.

Antes de crearlo

Sobre el "multi-tenancy" (multinquilinato). Este es un multinquilinato lógico y agrupado: los socios externos están aislados entre sí, mientras que los empleados internos reciben acceso basado en grupos (basado en roles) dentro del propio inquilino de la empresa. Todos los datos permanecen en tablas compartidas; el token, el filtro de vista y la tabla de derechos imponen la separación. El filtro de filas de SQL directo extiende la misma garantía fuera de la aplicación.

Cuándo usar este patrón. Utilice este patrón cuando los socios externos sin cuentas de Databricks y los empleados internos necesiten compartir un mismo tablero. Si cada visor es un usuario interno de Databricks, la incrustación básica con la seguridad de filas y columnas de Unity Catalog puede ser suficiente.

Restricciones prácticas y aspectos a tener en cuenta. Verifique los siguientes límites del producto y detalles operativos con la documentación actual antes de la publicación:

• Los tokens son de corta duración (1 hora), por lo que la aplicación tiene que actualizarlos, especialmente si se deja una pestaña abierta. El SDK del cliente facilita esto: una función de devolución de llamada (callback) getNewToken vuelve a realizar la obtención desde el endpoint /api/token a medida que el token se acerca a su vencimiento.
• Mantenga `external_viewer_id` + `external_value` por debajo de 1 KB combinados: identificadores compactos, no objetos JSON ni correos electrónicos largos.
• Límite de velocidad de 20 cargas de tablero por segundo por espacio de trabajo para la incrustación externa. Vale la pena saberlo para un portal B2B grande.
• Utilice un `external_viewer_id` que no sea PII. Este se registra en los logs de auditoría, por lo que un id de usuario o cliente estable es mejor que un nombre completo o un correo electrónico sin procesar.

Conclusiones clave

• Mantenga las reglas de acceso en una sola tabla de autorizaciones y úsela tanto para los paneles incrustados como para la protección de SQL directo.
• Firme un visor o ámbito de grupo en __aibi_external_value; no confíe en filtros editables por el usuario.
• Utilice la denegación por defecto, el enmascaramiento y los filtros de fila de Unity Catalog como controles en capas.
• La incrustación es solo el primer paso; diseñar y validar los controles de acceso es el trabajo crítico.

Llamada a la acción

Comience con la guía fundamental, Cómo incrustar paneles de AI/BI de Databricks en aplicaciones orientadas al cliente, luego aplique los patrones de autorización, enmascaramiento y denegación por defecto descritos en esta publicación. Para conocer los controles de gobernanza subyacentes, consulte la documentación de incrustación de AI/BI además de los filtros de fila y las máscaras de columna de Unity Catalog y la guía de ABAC.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original