Si tienes un dashboard multi-tenant en una plataforma de BI compatible con OAuth y necesitas restringir el acceso a las filas de una tabla según un usuario o grupo específico, la seguridad a nivel de fila de BigQuery te ayuda a conseguirlo.
La forma tradicional de restringir el acceso a filas específicas consistía en agregar columnas adicionales a la tabla para identificar quién tenía acceso y hacer un JOIN contra una tabla auxiliar con esos usuarios o grupos. Por ejemplo:
SELECT
t.*
FROM `project.dataset.table` AS t
JOIN `project.dataset.users` AS u ON t.access=u.name;
Muy sencillo, ¿verdad? El problema es que mantener esa tabla de usuarios implica un esfuerzo extra cada vez que agregas o eliminas a alguien. Eso se puede evitar usando la funcionalidad de seguridad a nivel de fila disponible en BigQuery. Ahora puedes otorgar acceso directamente a partir de grupos de Google y unificar la gestión. Por ejemplo:
CREATE OR REPLACE ROW ACCESS POLICY policy_<customer_id>
ON `project.dataset.table`
GRANT TO ('group:<customer_id>@<domain>')
FILTER USING (customer_id = '<customer_id>');
Además, en lugar de usar credenciales comunes basadas en una única Service Account, puedes aprovechar la autorización del usuario vía OAuth. Así logras un acceso más granular (seguridad y auditoría), control de cuotas e información de uso para tomar decisiones de producto a partir de esos datos.
Ojalá seas riguroso y tomes decisiones basadas en datos concretos.
El reto
Si tienes más de 100 clientes mientras escalas, esta solución deja de ser viable, ya que BigQuery impone un límite estricto (créeme y no pierdas el tiempo pidiéndole a Google que lo amplíe). Además, crear más de 100 reglas para una sola tabla suena un poco descabellado, ¿no?
Y, ¿qué pasa si quieres tener un grupo de administradores cuyos usuarios sí necesitan acceso a todos los datos? Ese caso también puede complicarse.
¿Cómo resolverlo?
El siguiente enfoque filtra el acceso según el dominio del usuario. La ventaja es que te ahorra crear nuevos grupos y mantener su membresía. Y, además, garantiza que tu grupo interno tenga acceso ilimitado a los datos, todo con apenas dos políticas a nivel de fila.
La desventaja evidente es que tus clientes necesitan un dominio corporativo para que funcione correctamente. La solución no sirve para dominios genéricos como gmail.com, yahoo.com o hotmail.com, ya que terminarías otorgando acceso a millones de usuarios.
-- Create a table
CREATE TABLE test.my_table (
id INT,
name STRING,
domain STRING);
-- Insert some values
INSERT INTO test.my_table (id, name, domain) VALUES
(1, 'test1', 'example.com'),
(2, 'test2', 'domain.com');
-- Restrict access to the users based on their domain name
CREATE OR REPLACE ROW ACCESS POLICY restrict_per_domain
ON `test.my_table`
GRANT TO ('allAuthenticatedUsers')
FILTER USING (domain = SUBSTR(SESSION_USER(),STRPOS(SESSION_USER(),'@')+1));
-- Grant access to an internal DoiT group
CREATE OR REPLACE ROW ACCESS POLICY grant_internal_group
ON `test.my_table`
GRANT TO ('group:<internal_group>@<domain>')
FILTER USING (1=1);
Como resultado:
1. [email protected], que pertenece al grupo allAuthenticatedUsers, solo puede ver una fila, mientras que
2. [email protected], que pertenece al grupo [email protected], puede ver todas las filas.
En resumen, se observa que las políticas permisivas a nivel de fila prevalecen sobre las más restrictivas (lo mismo que ocurre con la herencia de permisos de IAM) y, aunque Google no lo documenta de forma explícita, puedes usar grupos como allAuthenticatedUsers.
Para cerrar, vimos cómo sacarle el máximo provecho a la seguridad a nivel de fila junto con una herramienta de BI compatible con OAuth. Así controlas qué, cuándo y quién puede ejecutar acciones. Y todo con menos mantenimiento. ¡Pruébalo!
Para no perderte nada, síguenos en el DoiT Engineering Blog , en el canal de DoiT en LinkedIn y en el canal de DoiT en Twitter . Si te interesan las oportunidades laborales, visita https://careers.doit-intl.com .