Seguridad por Usuario en Data Studio: Filtros por Email (Row Level Security)
¿Necesitas publicar un único dashboard para cientos de clientes, managers o unidades de negocio sin que cada usuario pueda visualizar los datos de los demás? La solución no consiste en crear un informe por cliente: consiste en diseñar correctamente la seguridad a nivel de fila y vincular la identidad autenticada del usuario con el conjunto de datos que tiene permitido consultar.
Lo que aprenderás
El problema real: un informe, múltiples identidades
En una arquitectura empresarial es frecuente disponer de una tabla con ventas, operaciones, tickets o KPIs de múltiples organizaciones. El objetivo es publicar un único informe y hacer que el usuario que inicia sesión solamente pueda consultar las filas que le corresponden.
El error conceptual aparece cuando se confunde un filtro de visualización con un control de autorización. Un filtro que el usuario puede modificar no constituye por sí mismo una barrera de seguridad.
La arquitectura correcta desplaza la decisión de acceso hacia la capa de datos o hacia la configuración de seguridad de la fuente, utilizando la identidad autenticada para determinar qué filas pueden llegar al usuario.
Matriz de decisión arquitectónica
Antes de implementar Row Level Security conviene distinguir entre patrones que parecen similares desde la interfaz, pero tienen propiedades muy diferentes desde el punto de vista de seguridad, escalabilidad y operación.
| Patrón | Seguridad | Escalabilidad | Coste operativo | Uso recomendado |
|---|---|---|---|---|
| Un informe por cliente | Alta si los permisos están correctamente aislados | Baja | Alto | Clientes con requisitos de personalización extrema |
| Filtro visual por cliente | Baja como mecanismo de seguridad | Alta | Bajo | Exploración, no autorización |
| Filtro por email a nivel de fuente | Alta para el caso de uso soportado | Alta | Bajo/medio | Dashboards multiusuario y multiempresa |
| Seguridad en BigQuery + dashboard | Muy alta | Muy alta | Medio/alto | Datos sensibles, gobierno centralizado y entornos enterprise |
| Exportaciones separadas | Variable | Baja | Alto | Procesos offline o requisitos legacy |
Antipatrones críticos: donde se rompe la seguridad
⚠ No confundas un filtro del dashboard con autorización
Un diseño como customer_id = 1234 colocado directamente sobre una visualización
puede servir para presentar una vista concreta, pero no debería utilizarse como mecanismo
principal de aislamiento de tenants.
Si el usuario puede modificar el filtro, controlar parámetros o acceder a otra visualización que utilice una configuración diferente, la barrera deja de ser una frontera de seguridad.
El principio correcto es deny by default: la identidad del usuario debe determinar qué subconjunto de datos puede consultar, independientemente de qué gráficos existan en la página.
Antipatrón FinOps: duplicar informes, fuentes de datos y transformaciones para cada cliente puede multiplicar mantenimiento, consultas, cachés, pipelines y costes operativos. Si cien clientes tienen exactamente el mismo modelo semántico, normalmente existe una oportunidad para centralizar el modelo y parametrizar la autorización.
Implementación práctica: modelo de autorización
Una implementación robusta comienza separando los datos de negocio de la relación de autorización. En lugar de incrustar reglas como “este email corresponde a este cliente” dentro de decenas de gráficos, mantenemos una tabla gobernada que representa la relación entre identidad y ámbito de acceso.
-- Tabla de hechos:
-- analytics.sales
--
-- Tabla de autorización:
-- security.user_access
--
-- user_email | customer_id | active
--
-- La relación usuario-entidad se mantiene fuera
-- del dashboard y puede ser gobernada centralmente.
SELECT
s.sale_date,
s.customer_id,
s.product_id,
s.revenue,
s.region
FROM `project.analytics.sales` AS s
INNER JOIN `project.security.user_access` AS a
ON s.customer_id = a.customer_id
WHERE a.active = TRUE;
El punto importante no es solamente el JOIN. La tabla de autorización debe ser
tratada como un activo de seguridad: debe tener ownership claro, proceso de altas y bajas,
auditoría, validaciones y controles sobre quién puede modificarla.
Patrones de diseño y mejores prácticas
En arquitecturas enterprise, Row Level Security funciona mejor cuando se considera parte del modelo de gobierno de datos y no como una característica aislada del dashboard.
Identidad como clave de seguridad
Utiliza la identidad autenticada del usuario como entrada de la política. Evita pedir al usuario que introduzca manualmente el identificador de su organización.
Autorización independiente del UI
Las reglas de acceso deben vivir en la fuente de datos o en una capa de seguridad gobernada, no depender de que un determinado gráfico permanezca correctamente filtrado.
Tabla de acceso gobernada
Mantén una relación explícita entre usuario, tenant, cliente, región o unidad de negocio. Esto facilita auditoría, automatización y cambios de permisos.
Least Privilege
Un usuario debe recibir únicamente el ámbito necesario para su función. Evita reglas globales que concedan acceso adicional por comodidad operativa.
Defensa en profundidad
Para información crítica, combina el control del dashboard con políticas de seguridad del sistema de datos, IAM y mecanismos de gobierno adecuados.
Observabilidad
Registra altas, bajas y cambios de permisos. Un modelo de seguridad que no puede auditarse termina siendo difícil de operar a escala.
Arquitectura recomendada para un entorno empresarial
Un diseño escalable puede representarse como cuatro capas. La primera es la identidad; la segunda, la autorización; la tercera, el modelo de datos; y la cuarta, la visualización. Cada capa tiene una responsabilidad distinta.
┌───────────────────────────┐
│ Usuario autenticado │
│ user@empresa.com │
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Tabla / política de │
│ autorización │
│ │
│ user_email → tenant_id │
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Modelo de datos │
│ │
│ ventas / clientes / KPI │
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Data Studio │
│ │
│ Dashboard compartido │
└───────────────────────────┘Este patrón elimina una de las principales fuentes de deuda técnica en BI: convertir el número de clientes en el número de informes que el equipo debe mantener.
Checklist de implementación paso a paso
Preguntas frecuentes sobre Row Level Security en Data Studio
¿Cómo puedo hacer que cada usuario vea únicamente sus propios datos en Data Studio?
La estrategia recomendada es utilizar el filtrado por correo electrónico a nivel de fila de la fuente de datos, asociando la identidad del usuario autenticado con una columna de email o con una tabla de autorización. De esta manera, un mismo informe puede atender a múltiples usuarios sin duplicar dashboards.
¿Es suficiente añadir un filtro visual por email en un informe?
No. Un filtro visual no debe considerarse una frontera de seguridad. Si el usuario puede modificar la selección, la lógica no constituye una autorización sólida. La restricción debe aplicarse mediante el mecanismo de seguridad de la fuente de datos o mediante controles equivalentes en el sistema de origen.
¿Qué arquitectura es recomendable cuando los datos están en BigQuery?
Una arquitectura empresarial habitual separa los hechos de la tabla de autorización y utiliza una relación entre identidad y entidad de negocio. Para datos especialmente sensibles, conviene reforzar la seguridad también en BigQuery y mantener políticas de mínimo privilegio, auditoría y gobierno centralizado.