Power BI RLS: A Segurança de Dados que Você Estava Fazendo Errado Você tem 50 vendedores. Cada um deve ver apenas seus próprios dados. Simples, certo? A maioria dos analistas vai direto ao banco de dados: cria 50 logins diferentes, uma senha para cada vendedor, configura permissões individuais. Parece seguro. Na verdade, é um pesadelo de manutenção. Há uma forma melhor: Row-Level Security (RLS) no Power BI. E é nativa, grátis, e muito mais eficiente. O Problema com Segurança no Banco de Dados Quando você implementa segurança na camada do banco, você assume que será responsável por manter 50 (ou 500) logins sincronizados com a estrutura organizacional. Cenário típico (errado): Os problemas reais: 1. Manutenção = Pesadelo Adicionar vendedor = criar novo login + senha + atribuição de permissões Cada mudança exige intervalo de manutenção Alto risco de erro humano 2. Segurança = Risco Senhas compartilhadas entre departamentos Senhas padrão que ninguém muda Acesso não revogado rápido o suficiente quando alguém sai 3. Custo = Alto R$ 5.000+/mês em ferramentas de AD (Active Directory) management Tempo de TI dedicado apenas para gerenciar logins Complexidade que cresce exponencialmente Power BI RLS: A Solução Nativa Row-Level Security é um recurso do Power BI que filtra dados automaticamente baseado no usuário logado. Você tem um único login no banco, e o Power BI controla quem vê o quê. Como funciona: O que muda na prática: Antes (banco de dados): Depois (Power BI RLS): Benefícios que você sente na prática: | Aspecto | Sem RLS (Banco) | Com RLS (Power BI) | |---------|-----------------|-------------------| | Manutenção | Pesadelo (manual) | Zero (herda Azure AD) | | Novo vendedor | 30 min (criar login) | Automático (já no AD) | | Segurança | Risco alto | Controlada pelo BI | | Custo | R$ 5.000+/mês | R$ 0 (built-in) | | Escalabilidade | Frágil | Infinita | Implementando RLS no Power BI: Passo a Passo Passo 1: Garanta que seus dados têm a coluna de filtro Sua tabela de vendas precisa de uma coluna que identifique o vendedor: A coluna vendedor é fundamental. Ela é o elo entre o usuário logado e seus dados. Passo 2: Criar a Função RLS no Power BI Desktop 1. Vá para Segurança de Nível de Linha 2. Clique em Gerenciar Funções 3. Crie uma nova função chamada "Vendedor" 4. Escreva a regra DAX: Isso significa: filtre a tabela para mostrar apenas linhas onde a coluna "Vendedor" é igual ao username do usuário logado. Passo 3: Testar localmente No Power BI Desktop, você pode "impersonar" um usuário para testar: 1. Vá para Segurança de Nível de Linha 2. Clique em Visualizar como 3. Selecione a função "Vendedor" 4. Digite um nome de usuário para testar (exemplo: "joao@empresa.com.br") 5. Veja como os dados mudam automaticamente Resultado esperado: você só vê os dados de João. Passo 4: Publicar no Power BI Service Quando você publica o relatório no Power BI Service (nuvem): 1. Os dados continuam no mesmo banco 2. O Power BI Service aplica a regra RLS automaticamente 3. Cada usuário vê apenas seus dados Passo 5: Configurar Acesso no Power BI Service No Power BI Service: 1. Vá para Segurança de Nível de Linha 2. Clique na função "Vendedor" 3. Mapeie usuários/grupos do Azure AD: Pronto. Quando João acessa o relatório, ele vê só seus dados automaticamente. Casos de Uso Comuns 1. Segurança por Regional Cada regional gerente vê só seus dados. 2. Segurança por Departamento Cada departamento vê só seus dados. 3. Gerentes veem tudo Uma regra pode ser: "se o usuário é gerente, vê tudo. Se não, vê só seus dados." Erro #1: RLS só esconde dados, não protege Mito: "Se RLS está ativo, os dados estão seguros." Realidade: RLS controla o que o usuário VÊ no relatório. Mas se alguém tiver acesso direto ao banco (via SQL), pode burlar RLS. Solução: Restrinja acesso direto ao banco (conexão via Power BI Service apenas) Use firewalls para bloquear acesso ao banco de fora do Power BI Service Implemente auditoria (quem acessou o quê e quando) Erro #2: Confundir RLS com permissões de relatório RLS filtra DADOS. Permissões de relatório controlam acesso ao arquivo. Use os dois: 1. Permissões: controla quem pode abrir o relatório 2. RLS: controla quais dados cada pessoa vê dentro do relatório Erro #3: Performance cai com RLS RLS pode impactar performance se mal implementado. Regras DAX complexas rodando em milhões de linhas = lentidão. Solução: Use em vez de quando possível (mais rápido) Crie agregações pré-computadas se os dados são muito grandes Teste performance com dados reais antes de lançar Quando Usar RLS vs Banco de Dados | Cenário | Use RLS | Use Banco | |---------|---------|-----------| | Filtrar por usuário (vendedor/regional) | ✅ | ❌ | | Acesso direto ao banco (SQL, Python) | ❌ | ✅ | | Muito simples (1 coluna de filtro) | ✅ | ❌ | | Muito complexo (múltiplas dimensões) | Talvez | ✅ | | Muitos usuários (100+) | ✅ | ❌ | Exemplo Real: De 50 Logins para 1 Antes: Depois (com RLS): Conclusão