Publicação e compartilhamento com segurança: permissões e acesso controlado

O que significa publicar e compartilhar com segurança no Power BI

Publicar e compartilhar com segurança é o conjunto de práticas para disponibilizar relatórios e dashboards para outras pessoas sem expor dados indevidos, sem perder controle de versões e sem criar “atalhos” perigosos (como enviar arquivo com dados sensíveis por e-mail). Em pequenos negócios, isso costuma envolver três preocupações principais: (1) quem pode ver o quê (permissões), (2) por onde a pessoa acessa (canais e dispositivos) e (3) como manter o acesso sob controle ao longo do tempo (revogar, auditar e padronizar).

No Power BI, a publicação normalmente acontece quando você envia seu relatório do Power BI Desktop para o Power BI Service (ambiente online). A partir daí, você decide como outras pessoas vão consumir: como visualizadores de um relatório, como consumidores de um aplicativo (App), como membros de um workspace (área de trabalho) ou por meio de compartilhamento de itens específicos. Segurança, nesse contexto, não é só “colocar senha”; é desenhar um fluxo em que cada perfil de usuário tenha o mínimo acesso necessário para executar sua função.

Princípios práticos de segurança (para não errar no básico)

• Princípio do menor privilégio: cada pessoa deve ter apenas o nível de acesso necessário. Evite dar permissão de edição para quem só precisa visualizar.

• Separação entre criação e consumo: quem constrói e mantém (analista/gestor) não é necessariamente quem consome (vendas, caixa, compras). Isso reduz risco de alterações acidentais.

• Fonte única de verdade: prefira compartilhar via Service (relatório publicado) em vez de enviar PBIX ou exportar planilhas com dados.

  Continue em nosso aplicativo

  Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

  ou continue lendo abaixo...

  

  Baixar o aplicativo

• Controle de distribuição: use App e grupos de segurança quando possível, em vez de compartilhar item a item para pessoas individuais.

• Revisão periódica: acessos mudam (funcionário sai, função muda). Tenha rotina de revisão e remoção.

Entendendo os “lugares” e os “papéis” no Power BI Service

Workspace (Área de trabalho): onde o conteúdo é gerenciado

O workspace é o local onde relatórios, datasets (modelos), dataflows e dashboards ficam organizados para criação, manutenção e publicação. Pense nele como a “pasta de trabalho” da equipe responsável por manter o conteúdo. Em geral, o workspace não é o melhor lugar para distribuir consumo amplo, porque ele tende a concentrar permissões mais altas.

App (Aplicativo): onde o conteúdo é distribuído para consumo

O App é o canal recomendado para distribuir relatórios e dashboards para usuários finais. Ele permite uma experiência mais controlada: você escolhe quais itens entram no App, define audiência (quem recebe) e reduz a chance de alguém “se perder” no workspace ou acessar itens em construção.

Relatório, Dashboard e Dataset: o que cada permissão afeta

• Relatório: o arquivo visual que o usuário abre e interage (filtros, páginas, drill).

• Dashboard: painel com tiles fixados (pins) a partir de relatórios; útil para visão rápida.

• Dataset (conjunto de dados/modelo): a base publicada que alimenta relatórios. Permissões no dataset são críticas porque podem permitir “Build” (criar novos relatórios) e acesso indireto aos dados.

Funções (roles) típicas no workspace

Os nomes podem variar conforme o ambiente, mas a lógica é: quanto mais alto o papel, mais poder de alterar conteúdo e permissões.

• Admin: controla tudo, inclusive permissões e configuração do workspace.

• Member/Contributor: publica, edita e mantém conteúdo (ideal para quem desenvolve).

• Viewer: apenas visualiza conteúdo do workspace (ainda assim, pode não ser o melhor para distribuição ampla; prefira App para consumo).

Em pequenos negócios, uma configuração comum e segura é: 1 ou 2 pessoas como Admin/Member (responsáveis pelo BI) e o restante como consumidores via App.

Tipos de compartilhamento: o que usar (e o que evitar)

Compartilhar um relatório diretamente

Você pode usar o botão de compartilhar (Share) em um relatório. Isso funciona, mas tende a virar bagunça quando o número de pessoas cresce: permissões ficam espalhadas, difíceis de auditar, e você pode acabar concedendo acesso ao dataset sem perceber, dependendo das opções e do cenário.

Quando faz sentido: poucos usuários, necessidade pontual e controlada.

Quando evitar: distribuição recorrente para times inteiros (vendas, lojas, franquias, compras).

Publicar um App (recomendado para consumo)

O App é a forma mais organizada de entregar conteúdo. Você controla versões, define audiência e mantém o workspace como ambiente de manutenção. Usuários acessam o App e veem apenas o que você publicou.

Quando faz sentido: quase sempre que você quer distribuir dashboards para operação.

Permissão “Build” no dataset (cuidado)

Conceder “Build” permite que a pessoa crie relatórios novos a partir do dataset. Isso pode ser ótimo para um analista interno, mas perigoso para usuários finais, porque aumenta o risco de interpretações erradas, relatórios paralelos e até exposição de campos sensíveis (dependendo do modelo e das regras de segurança).

Regra prática: só dê “Build” para quem realmente vai criar conteúdo e entende o modelo.

Passo a passo: publicar do Power BI Desktop para o Service com controle

1) Preparar o arquivo para publicação

• Confirme que o arquivo PBIX está apontando para as fontes corretas (produção, não “planilha de testes”).

• Verifique se não há páginas “rascunho” que não deveriam ir para o público (ex.: páginas técnicas, validações internas).

• Revise nomes de campos e medidas para não expor termos internos (ex.: “CustoFornecedorConfidencial”).

2) Publicar

No Power BI Desktop, use Publicar (Publish) e selecione o workspace correto (idealmente um workspace de “BI - Produção” ou equivalente). Evite publicar em “Meu Workspace” quando o objetivo é compartilhar com a empresa, porque isso dificulta governança e continuidade.

3) Validar no Service

• Abra o relatório no Service e confira se tudo carrega corretamente.

• Teste filtros e interações principais.

• Confirme se o dataset foi criado/atualizado e se o relatório está vinculado ao dataset esperado.

Passo a passo: configurar acesso por App (distribuição organizada)

1) Organizar o workspace antes de publicar o App

• Mantenha apenas itens relevantes no workspace (datasets, relatórios finais, dashboards úteis).

• Se houver relatórios em desenvolvimento, use um workspace separado (ex.: “BI - Dev”) para não misturar com produção.

2) Criar/Publicar o App

No workspace, escolha a opção de criar/publicar App. Em seguida:

• Conteúdo: selecione quais relatórios e dashboards entrarão no App (não precisa ser tudo).

• Navegação: organize a ordem e visibilidade dos itens (ex.: “Visão Geral”, “Vendas”, “Financeiro”, “Estoque”).

• Audiência (permissões do App): defina quem pode acessar. Prefira grupos (ex.: “Equipe Vendas”, “Gerentes Loja”, “Financeiro”) em vez de usuários individuais.

3) Testar como usuário final

Antes de liberar para todos, teste com 1 ou 2 usuários de cada área. O objetivo é validar: acesso, performance, entendimento e se não há “vazamento” de informação (por exemplo, vendedor vendo margem detalhada se isso não for desejado).

Controle de acesso por perfil: exemplos práticos para pequenos negócios

Cenário A: Loja com equipe de vendas e gerente

• Vendedores: acesso ao App com páginas de acompanhamento de vendas e metas, sem detalhes sensíveis (ex.: custos, margem por item, dados pessoais de clientes se não for necessário).

• Gerente: acesso a páginas adicionais (ex.: desempenho por vendedor, devoluções, descontos), possivelmente com mais detalhamento.

• Financeiro: acesso a relatórios de caixa/recebimentos e visão consolidada.

Implementação típica: um único App com audiências diferentes (quando disponível) ou dois Apps (Operação e Gestão), cada um com seu conjunto de relatórios.

Cenário B: E-commerce com agência/consultor externo

• Consultor: acesso de Member/Contributor em workspace de desenvolvimento, mas não necessariamente em produção. Em produção, pode ser Viewer ou acesso controlado apenas ao que precisa.

• Dono/gestor: Admin do workspace de produção e consumidor do App.

• Time interno: consumidores via App.

Ponto de atenção: evite que terceiros tenham acesso amplo a datasets com dados sensíveis se não houver necessidade. Prefira entregar relatórios prontos via App.

Segurança em nível de linha (RLS): restringindo dados por usuário

Permissões de acesso dizem “quem entra”. RLS (Row-Level Security) define “o que a pessoa vê” dentro do mesmo relatório/dataset. Isso é essencial quando você quer um único relatório para várias unidades/lojas, representantes ou franquias, mas cada um deve ver apenas seus próprios números.

Exemplo prático de uso

Você tem um relatório de vendas com dados de todas as lojas. O gerente da Loja A deve ver apenas Loja A; o gerente da Loja B, apenas Loja B; e a diretoria vê tudo.

Passo a passo: configurar RLS no Desktop

• 1) Criar uma tabela de segurança (recomendado): uma tabela com colunas do tipo Email e Unidade (ou Loja). Exemplo:

  Email,Unidade
  gerenteA@empresa.com,Loja A
  gerenteB@empresa.com,Loja B

• 2) Relacionar a tabela de segurança: conecte Unidade da tabela de segurança com a dimensão de unidade/loja do seu modelo (relação adequada para filtrar fatos).

• 3) Criar a role: no Desktop, vá em Modelagem > Gerenciar funções (Manage roles) e crie uma função (ex.: RLS_Unidade).

• 4) Definir a regra DAX: na tabela de segurança, crie um filtro do tipo:

  [Email] = USERPRINCIPALNAME()

• 5) Testar: use Exibir como (View as) e simule usuários para confirmar que cada um vê apenas sua unidade.

Passo a passo: aplicar RLS no Service

• 1) Publicar o relatório/dataset no workspace de produção.

• 2) Abrir o dataset no Service e acessar Segurança (Security).

• 3) Adicionar membros à role (usuários ou grupos). Se você usa a regra com USERPRINCIPALNAME(), ainda assim precisa garantir que os usuários tenham acesso ao relatório/App; a role define o recorte.

• 4) Validar com “Testar como função” (quando disponível) e com usuários reais.

Boas práticas de RLS

• Use grupos, não indivíduos: quando possível, atribua grupos à role. Trocas de equipe ficam mais simples.

• Evite regras complexas demais: RLS mal desenhado pode afetar performance e manutenção.

• Documente a lógica: registre quais perfis existem e quais campos controlam o acesso (ex.: Unidade, Canal, Vendedor).

Permissões no dataset: evitar “vazamento” por exportação e análise

Mesmo quando o usuário só “visualiza” um relatório, dependendo das configurações e licenças, ele pode conseguir exportar dados resumidos ou detalhados. Isso não é necessariamente ruim, mas precisa ser intencional.

O que revisar

• Permitir exportação de dados: avalie se usuários operacionais precisam exportar. Se não, desabilite para reduzir risco de circulação de planilhas com dados sensíveis.

• Permitir “Analyze in Excel”/conexões externas: isso aumenta o poder do usuário sobre o dataset. Libere apenas para perfis analíticos.

• Campos sensíveis no modelo: se um campo não deve ser visto por ninguém fora do financeiro (ex.: custo unitário, dados pessoais), considere separar em outro dataset/relatório ou restringir via RLS/estratégia de modelagem e permissões.

Compartilhamento externo (convidados): como reduzir riscos

Alguns pequenos negócios precisam compartilhar relatórios com contabilidade, consultoria, agência ou sócios. Isso exige cuidado extra, porque envolve identidades fora do domínio principal.

Regras práticas

• Prefira acesso via App com escopo mínimo: entregue apenas o necessário, não o workspace inteiro.

• Evite dar permissão de edição: externo geralmente deve ser Viewer/consumidor, a menos que ele seja responsável por manutenção.

• Prazo e revisão: acessos externos devem ser revisados com frequência e removidos quando o projeto termina.

Governança leve: como manter controle sem burocracia

Estrutura recomendada de ambientes

• Workspace de Desenvolvimento (Dev): testes, rascunhos, validações. Acesso restrito a quem constrói.

• Workspace de Produção (Prod): apenas conteúdo aprovado. Acesso de edição bem limitado.

• Apps: um ou mais Apps para distribuição (Operação, Gestão, Financeiro), conforme necessidade.

Rotina de publicação controlada

• Checklist antes de publicar: páginas corretas, filtros funcionando, nomes adequados, RLS testado, exportação revisada.

• Versão e mudança: mantenha um registro simples do que mudou (ex.: “incluída página de Estoque”, “ajuste no cálculo de devoluções”). Pode ser uma nota interna no workspace ou um documento de controle.

• Janela de atualização: publique mudanças em horários combinados para reduzir impacto na operação.

Auditoria e manutenção de acessos: o que checar e com que frequência

Lista de verificação mensal (prática e rápida)

• Usuários com acesso ao workspace: confirme se todos ainda precisam de acesso e se o papel está correto (Admin/Member/Viewer).

• Quem tem acesso ao App: revise a audiência e remova ex-funcionários ou terceiros.

• Quem tem “Build” no dataset: reduza ao mínimo. Se alguém não cria relatórios, não precisa de Build.

• RLS: valide se novos gerentes/unidades foram incluídos e se ninguém está em role errada.

• Exportações: reavalie se permissões de exportar continuam adequadas.

Erros comuns em pequenos negócios (e como evitar)

• Compartilhar PBIX por e-mail/WhatsApp: além de expor dados, perde-se controle de versão. Prefira Service/App.

• Todo mundo como editor: aumenta risco de alterações acidentais e quebra de relatórios. Restrinja edição.

• Um único workspace para tudo: mistura rascunho com produção e dificulta controle. Separe Dev e Prod.

• RLS não testado: um erro de regra pode expor dados de outra unidade. Sempre teste “View as” e com usuários reais.

• Permitir exportação sem necessidade: gera planilhas paralelas e circulação de dados. Defina política clara.

Passo a passo rápido: um modelo seguro de implantação em 60 minutos

Objetivo

Colocar um relatório no ar com acesso controlado para operação e gestão, minimizando risco de edição indevida e vazamento.

Roteiro

• 1) Criar dois workspaces: BI - Dev e BI - Prod.

• 2) Definir papéis: no Prod, apenas 1 Admin e 1 Member (backup). Todos os demais serão consumidores via App.

• 3) Publicar no Dev: validar visualmente e com 1 usuário-chave.

• 4) Publicar no Prod: enviar a versão aprovada.

• 5) Configurar RLS (se necessário): criar role, publicar, adicionar grupos/usuários na role no Service, testar.

• 6) Publicar App do Prod: selecionar relatórios finais, organizar navegação, definir audiência por grupos.

• 7) Revisar exportação e Build: garantir que apenas perfis analíticos tenham Build e que exportação esteja alinhada com a política do negócio.

• 8) Teste final: um usuário de cada área abre o App e confirma acesso e recortes corretos.