Segurança de Dados no Looker: Controle Quem Vê o Quê com Row-Level Security

No mundo atual da análise de dados, segurança e governança vão muito além de simplesmente controlar quem pode fazer login. É crucial definir o que cada pessoa pode visualizar depois de acessar a plataforma. Quando vários departamentos, regiões ou clientes compartilham os mesmos painéis, controlar o acesso a informações sensíveis em um nível bem detalhado se torna fundamental.

É aí que entra a Row-Level Security (RLS), ou Segurança em Nível de Linha, no Looker. Essa funcionalidade oferece um jeito flexível e poderoso de impor RLS por meio de Access Filters e User Attributes. O resultado? Cada usuário só vê os dados que tem permissão para acessar, tudo gerenciado dentro do modelo LookML.

Este guia explica como projetar e implementar RLS no Looker, com exemplos práticos, casos de uso e as melhores práticas.

O Que é Row-Level Security (RLS)?

RLS é um método para restringir o acesso a linhas específicas de um conjunto de dados, com base na identidade ou função do usuário. Pense em cenários como:

• Um gerente de vendas vendo apenas dados da sua própria região.
• Um cliente acessando e visualizando apenas suas próprias transações.
• Um analista que pode ver todos os registros, mas com algumas colunas ocultas.

O RLS garante que, mesmo que vários usuários consultem o mesmo Explore ou painel, cada um receba um conjunto de dados personalizado e restrito. No Looker, isso é feito com a combinação de Access Filters e User Attributes.

Componentes Chave do RLS no Looker

Existem dois elementos principais que trabalham juntos para controlar a visibilidade dos dados:

1. User Attributes

São variáveis dinâmicas e específicas de cada usuário, definidas no nível de administrador do Looker. Elas armazenam metadados sobre os usuários — como região, departamento ou ID do cliente — e podem ser referenciadas nos modelos LookML. Por exemplo, um atributo pode ser 'região' com o valor 'América do Norte' ou 'departamento' com o valor 'Finanças'.

2. Access Filters

Esses filtros definem como as regras de visibilidade de dados são aplicadas, com base nos User Attributes. Eles ficam dentro de um arquivo de modelo LookML e filtram linhas em uma tabela ou view de acordo com uma condição. Juntos, User Attributes e Access Filters formam a base do RLS no Looker.

Como Funciona o RLS no Looker

O fluxo é direto: um administrador define os User Attributes (por exemplo, 'região') no painel de administração. Em seguida, cada usuário ou grupo recebe um valor específico para esse atributo (ex: 'APAC'). Desenvolvedores aplicam Access Filters no modelo LookML que referenciam o atributo para filtrar os dados dinamicamente. Quando um usuário consulta os dados, o Looker injeta automaticamente a cláusula WHERE apropriada, retornando apenas as linhas que correspondem ao seu atributo.

Por exemplo, se o atributo 'região' de um Gerente de Vendas for 'Oeste', o Looker executará as consultas com WHERE region = 'Oeste'.

Criando User Attributes

Para criar um User Attribute, vá em Admin → Users → User Attributes → New. Dê um nome (ex: 'region'), um rótulo ('User Region'), selecione o tipo (String) e, opcionalmente, um valor padrão. Depois, atribua esse atributo a usuários individuais ou, de preferência, a grupos inteiros para facilitar a gestão.

Definindo Access Filters em LookML

Os Access Filters são definidos no arquivo do seu modelo (.model.lkml). Eles aplicam filtros específicos do usuário automaticamente sempre que uma consulta é executada. Por exemplo, um filtro de acesso baseado em região:

access_filter: {
  field: region.name
  user_attribute: region
}

Se o atributo de usuário 'region' de João for 'Oeste', o Looker adicionará WHERE region.name = 'Oeste' a todas as consultas executadas nesse modelo. Isso garante que João só veja os dados da região 'Oeste', independentemente de qualquer filtro manual que ele aplique na interface.

Exemplo: Acesso a Dados Específicos do Cliente

Para configurações multi-tenant (onde clientes acessam seus próprios dados), o RLS é essencial. Configure um User Attribute chamado 'customer_id' e um Access Filter no LookML como:

access_filter: {
  field: orders.customer_id
  user_attribute: customer_id
}

O resultado é que cada cliente verá apenas os dados associados ao seu ID. Por exemplo, o Cliente A verá apenas dados onde customer_id = A, e o Cliente B, apenas onde customer_id = B. Essa abordagem é muito usada em portais de análise voltados para o público externo ou painéis embarcados.

Usando Access Filters Condicionais

Para usuários com privilégios especiais (como Administradores), que precisam ver todos os dados, é possível usar filtros de acesso condicionais com lógica LookML. Você pode definir um filtro de acesso para a região e, em seguida, usar uma estrutura `CASE WHEN` para permitir que usuários com o atributo 'region' definido como 'All' vejam tudo, ou que os demais sejam filtrados:

access_filter: {
  field: sales.region
  user_attribute: region
}

explore: sales {
  always_filter: {
    sql: CASE
      WHEN {% condition region %} ${sales.region} {% endcondition %}
      ELSE 1=1
    END ;;
  }
}

Uma alternativa é tratar 'All' no SQL:

WHERE (${region} = 'All' OR sales.region = ${region})

Isso garante que administradores vejam tudo, enquanto outros usuários são restritos.

Combinando Múltiplos Access Filters

É possível definir vários filtros no mesmo modelo para uma segurança em camadas. Por exemplo, combinando filtros de região e departamento:

access_filter: {
  field: region.name
  user_attribute: region
}

access_filter: {
  field: department.name
  user_attribute: department
}

Isso garante que os usuários vejam apenas dados que correspondam a ambas as condições, como região 'Oeste' e departamento 'Finanças'.

Testando o Row-Level Security

Para testar, vá em Admin → Users → Switch to User (ou use 'Login as user'). Abra o mesmo painel ou Explore e verifique se os dados mudam de acordo com os atributos atribuídos ao usuário. O SQL Runner também pode ser usado para pré-visualizar o SQL subjacente e confirmar se a cláusula WHERE está correta.

Melhores Práticas para Implementar RLS

• Centralize a gestão de atributos: Defina e mantenha User Attributes no painel de administração, não no LookML.
• Use grupos: Atribua atributos em nível de grupo para escalabilidade.
• Mantenha Access Filters simples: Use um ou dois filtros por modelo para clareza e performance.
• Segurança por padrão: Garanta que usuários sem atributos definidos não vejam dados.
• Audite regularmente: Revise as atribuições de atributos e valide se estão alinhadas com as funções atuais.
• Documente a lógica de acesso: Mantenha documentação explicando quais filtros se aplicam a quais modelos.
• Teste com múltiplos papéis: Valide se diferentes usuários veem as fatias corretas de dados.

Caso de Uso Avançado: Mapeamento Dinâmico de Atributos

Quando atributos de usuário precisam mapear para regras mais complexas, como acesso a múltiplas regiões, listas separadas por vírgula e manipulação via SQL são úteis:

access_filter: {
  field: sales.region
  user_attribute: region_list
}

E no SQL:

WHERE sales.region IN ( {% list user_attribute region_list %} )

Isso permite que um usuário veja várias regiões, como 'Leste, Oeste'.

Armadilhas Comuns a Evitar

• Atribuição de Atributo Ausente: Usuários sem atributos definidos podem ver poucos ou nenhum dado.
• Regras Sobrepostas: Múltiplos filtros no mesmo campo podem causar conflitos.
• Valores Codificados: Nunca codifique valores de região ou ID; sempre referencie User Attributes.
• Sensibilidade a Maiúsculas/Minúsculas: Garanta que os valores dos atributos correspondam aos registros do banco de dados.
• Sobrecarga de Performance: Muitos filtros podem lentificar as consultas. Teste com grandes volumes de dados.

Conclusão

Implementar Row-Level Security (RLS) no Looker, usando Access Filters e User Attributes, permite entregar análises personalizadas e seguras em escala. Ao controlar a visibilidade dos dados no nível da linha, você garante que os usuários vejam apenas informações relevantes para eles, fortalecendo a governança de dados, a conformidade e a confiança em toda a organização. Seja restringindo vendas por região, dados de clientes por ID ou métricas financeiras por departamento, o RLS é uma prática essencial que todo desenvolvedor e administrador Looker deve dominar.