Se você tem um dashboard multi-tenant em uma plataforma de BI compatível com OAuth e quer restringir o acesso a linhas de uma tabela por usuário ou grupo específico, o row-level security do BigQuery pode resolver isso pra você.
A forma tradicional de restringir o acesso a linhas específicas era adicionar colunas extras à tabela para identificar quem tinha acesso e fazer um JOIN com uma tabela auxiliar contendo esses usuários/grupos. Por exemplo:
SELECT
t.*
FROM `project.dataset.table` AS t
JOIN `project.dataset.users` AS u ON t.access=u.name;
Bem direto, né? Só que manter essa tabela de usuários dá um trabalho extra toda vez que precisa adicionar ou remover alguém. Dá pra evitar isso usando o recurso de row-level disponível no BigQuery. Agora você consegue conceder acesso direto com base em grupos do Google e unificar a gestão. Por exemplo:
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>');
Além disso, em vez de usar credenciais comuns baseadas em uma Single-Service Account, dá pra aproveitar a autorização do usuário via OAuth. Assim você oferece um acesso mais granular (segurança e auditoria), controle de cota e informações de uso para evoluir o produto com base nesses dados.
Espero que você seja criterioso e tome decisões com base em dados concretos.
O desafio
Se você tem mais de 100 clientes no processo de escalar a operação, essa solução não se sustenta, porque existe um limite rígido no BigQuery (pode confiar e não perca tempo pedindo pro Google aumentar esse teto). Fora que criar mais de 100 regras para uma única tabela soa meio estranho, não acha?
E se você quiser ter um grupo de admins com usuários que realmente precisam acessar todos os dados? Esse cenário também pode ser complicado.
Como resolver isso?
A abordagem a seguir filtra o acesso pelo nome do domínio do usuário. A vantagem é que você não precisa criar novos grupos nem ficar gerenciando quem entra e quem sai. E ainda garante que o seu grupo interno tenha acesso ilimitado aos dados — tudo com apenas duas políticas de row-level.
A desvantagem clara é que seus clientes precisam usar um domínio corporativo para a coisa funcionar direito. Essa solução não serve para domínios genéricos como gmail.com, yahoo.com e hotmail.com, porque você estaria liberando acesso para milhões de usuários.
-- 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);
Resultado:
1. [email protected], que pertence ao grupo allAuthenticatedUsers, consegue ver apenas uma linha, enquanto
2. [email protected], que pertence ao grupo [email protected], vê todas as linhas.
Resumindo: políticas de row-level permissivas prevalecem sobre as mais restritivas (a mesma lógica da herança de permissões do IAM) e, mesmo sem estar documentado explicitamente pelo Google, dá pra usar grupos como allAuthenticatedUsers.
Para fechar, vimos como tirar o máximo do row-level security combinado com a sua ferramenta de BI compatível com OAuth. Assim, você tem controle do que, quando e quem pode executar cada ação. E ainda com bem menos manutenção. Vale testar!
Para ficar por dentro, siga a gente no DoiT Engineering Blog , no LinkedIn da DoiT e no Twitter da DoiT . Para conferir oportunidades de carreira, acesse https://careers.doit-intl.com .