Tenant settings do Power BI: o que todo admin deve configurar

O admin portal fica ligado no padrão e ninguém percebe o risco#

Na maioria das empresas que atende, a Fynx encontra o mesmo cenário: o Power BI foi adotado pela área de negócio, cresceu rápido, virou operação, e o admin portal nunca foi revisado. As tenant settings do Power BI continuam exatamente como a Microsoft entregou, e é justamente aí que mora o problema. Configuração padrão não é configuração segura, é configuração conveniente para adoção. Quem paga a conta é a governança, quando descobre que um relatório com dados financeiros está publicado na internet aberta ou que qualquer usuário exporta a base inteira para um Excel que sai voando por e-mail.

As tenant settings do Power BI ficam no admin portal do serviço, acessível apenas para quem tem papel de administrador do Fabric ou do Power BI (ou administrador global do Microsoft 365). São dezenas de chaves que controlam o que os usuários podem fazer: exportar dados, compartilhar com gente de fora, publicar conteúdo na web pública, usar service principals para automação, criar apps, instalar aplicativos de template. Cada uma dessas chaves é uma decisão de risco. E a maioria delas vem ligada.

Este artigo é o passeio honesto pelas configurações que todo administrador precisa revisar. Não é uma lista de "desligue tudo", porque desligar tudo mata a adoção e cria BI sombra. É sobre encontrar o equilíbrio entre liberdade e risco, decisão por decisão.

Tenant settings do Power BI são controles de tenant inteiro, não de workspace#

Antes de mexer em qualquer chave, é preciso entender o alcance. As tenant settings valem para todo o tenant, ou seja, para toda a organização. Elas não são permissões de um workspace nem papéis atribuídos a um relatório. Quando você desliga uma exportação no admin portal, ela some para todo mundo, ou para os grupos que você definir.

E esse é o ponto mais poderoso e mais ignorado: a maioria das tenant settings pode ser restrita por grupos de segurança do Microsoft Entra ID (o antigo Azure AD). Cada chave costuma oferecer três estados, e entender a diferença muda tudo.

Estado da configuração	O que acontece	Quando usar
Desabilitado para toda a organização	Ninguém consegue usar o recurso	Recursos de alto risco sem caso de uso legítimo
Habilitado para toda a organização	Qualquer usuário consegue usar o recurso	Só para recursos de baixo risco ou muito demandados
Habilitado, mas com grupos de segurança específicos	Só os grupos escolhidos usam (ou todos, exceto os grupos excluídos)	A escolha certa para quase tudo

A terceira opção é a que separa um admin maduro de um que só liga e desliga. Em vez de "todo mundo pode compartilhar externamente", você diz "só o grupo Compartilhamento-Externo-Aprovado pode". Cria o grupo no Entra ID, coloca as pessoas certas, e a configuração passa a acompanhar sua estrutura de governança em vez de ser um interruptor binário. Exige disciplina para manter os grupos atualizados, mas é o preço de um controle que funciona de verdade.

Publicar na Web é a configuração mais perigosa do admin portal#

Se você só for revisar uma configuração hoje, revise esta. A opção "Publicar na Web" (Publish to Web) permite que um usuário gere um código de incorporação de um relatório e coloque esse relatório em qualquer página, blog ou site. Parece inofensivo até você entender o que significa na prática: o relatório fica publicamente acessível na internet, sem autenticação, indexável por buscadores. Qualquer pessoa com o link vê os dados. Não existe "só quem tem a URL", porque a URL vaza, é compartilhada, cai em histórico e em cache de buscador.

A Fynx já viu relatório de faturamento e de folha de pagamento exposto assim, por engano, por um usuário bem-intencionado que só queria mostrar um gráfico para um fornecedor. Não foi ataque, não foi má-fé. Foi uma configuração ligada por padrão encontrando um usuário sem contexto de risco.

A recomendação direta: desabilite "Publicar na Web" para toda a organização, ou no mínimo restrinja a um grupo minúsculo e auditado, com aprovação formal por publicação. Não existe meio-termo confortável aqui. Se a empresa precisa mesmo mostrar um dado publicamente, existem caminhos melhores, como o Embed for your customers com controle de acesso. Publicar na Web é a porta dos fundos, e ela vem escancarada de fábrica.

Vale ainda revisar os códigos de incorporação já existentes. O admin portal tem uma área para gerenciar e remover embeds ativos, e se a configuração ficou ligada por meses, provavelmente há embeds antigos que ninguém lembra, cada um uma exposição viva.

Controle de exportação decide para onde o dado vai depois que sai do Power BI#

O Power BI é ótimo justamente porque governa o dado dentro dele: permissões, row-level security, auditoria. O problema começa quando o dado sai, e as configurações de exportação controlam exatamente isso:

• Exportar para Excel e .csv: o clássico. Deixa o usuário baixar os dados por trás de um visual.
• Exportar como PowerPoint, PDF ou imagem: menos crítico, mas ainda tira o dado do ambiente governado.
• Baixar o relatório (.pbix): entrega o modelo inteiro, com dados e medidas, para quem baixar.
• Copiar e colar visuais e Analisar no Excel: caminhos alternativos de saída que muita gente esquece.

Desligar tudo isso parece seguro, mas na prática empurra o usuário para tirar print da tela ou digitar o número na mão, o que é pior porque sai do radar de auditoria. A abordagem que a Fynx recomenda é escalonada: mantenha exportações de baixo risco (imagem, PowerPoint) mais liberais e restrinja as de alto risco (download do .pbix, Analisar no Excel) a grupos específicos. O .pbix merece atenção redobrada, porque entrega o modelo semântico completo, e não só o resultado de um visual.

Aqui entra a LGPD de forma concreta. A Lei nº 13.709/2018 responsabiliza a empresa pelo tratamento de dados pessoais, e uma exportação descontrolada é um vazamento esperando para acontecer. Um Excel com CPF, nome e endereço que sai do Power BI e circula por e-mail é exatamente o tipo de fluxo que a LGPD exige que você controle e consiga rastrear. Configurar exportação não é paranoia de admin, é parte do dever de conformidade. Vale aprofundar no material da Fynx sobre governança de dados e LGPD no Power BI.

Compartilhamento externo precisa de fronteira clara#

Duas configurações governam a saída de conteúdo para fora da empresa, e é comum confundi-las. A primeira, "Compartilhar conteúdo com usuários externos", permite convidar pessoas de fora do tenant para ver relatórios via colaboração B2B do Entra ID. A segunda, "Usuários externos convidados podem editar e gerenciar conteúdo", vai muito além, deixando o convidado atuar como se fosse de dentro.

A diferença de risco entre as duas é enorme. Compartilhar em modo leitura com um cliente ou parceiro é um caso de uso legítimo e comum. Deixar um externo editar e gerenciar conteúdo é abrir a estrutura interna para alguém que não passa pelos seus controles de RH, de offboarding e de política de segurança. Essa segunda chave, salvo exceção muito bem justificada, deve ficar desabilitada.

O caminho maduro é restringir o compartilhamento externo de leitura a um grupo de segurança de pessoas autorizadas, combinar com as políticas de acesso externo do próprio Entra ID (quais domínios podem ser convidados) e manter auditoria ativa. Compartilhamento externo não é o vilão, o vilão é o compartilhamento sem fronteira e sem registro de quem compartilhou o quê para quem.

Service principals são o que sustenta automação madura#

Aqui a conversa muda de tom, porque service principal não é risco, é maturidade. É uma identidade de aplicação no Entra ID, sem usuário humano por trás, usada para automação: publicar relatórios via pipeline, atualizar datasets por API, provisionar workspaces. Em vez de amarrar uma automação crítica à conta pessoal de um funcionário (que um dia sai da empresa e derruba tudo), você usa uma identidade dedicada e controlada.

A configuração relevante é "Permitir que service principals usem APIs do Power BI". Ela vem desabilitada, e faz sentido: você não quer qualquer aplicação batendo nas suas APIs. Mas mantê-la desabilitada para sempre condena seu time a automação frágil, feita na conta de alguém.

A recomendação: habilite service principals restrito a um grupo de segurança com apenas as aplicações de automação aprovadas. Assim você tem automação robusta e escopo controlado. Combine com o princípio do menor privilégio, dando a cada service principal só o acesso de workspace que ele precisa. Essa é a fundação que separa um ambiente de BI que escala de um que quebra a cada troca de pessoa, e é um dos pilares que a Fynx implementa em projetos de sustentação de BI.

A tabela de decisão que uso na primeira revisão de tenant#

Quando a Fynx faz o assessment de um tenant, começa por um punhado de chaves de alto impacto. Esta é a leitura rápida que uso, com a recomendação padrão para quem leva governança a sério:

Configuração	Padrão de fábrica	Recomendação Fynx	Motivo
Publicar na Web	Habilitado	Desabilitado ou grupo mínimo auditado	Expõe dados na internet aberta, sem autenticação
Exportar para Excel / .csv	Habilitado	Habilitado por grupo	Saída de dados que a LGPD exige controlar
Baixar relatórios (.pbix)	Habilitado	Grupo restrito	Entrega o modelo completo, não só o visual
Compartilhar com externos (leitura)	Varia	Grupo autorizado	Caso de uso legítimo, mas precisa de fronteira
Externos editam e gerenciam	Desabilitado	Manter desabilitado	Convidado atuando como interno é risco alto
Service principals nas APIs	Desabilitado	Habilitado por grupo de apps	Automação madura com escopo controlado
Criar workspaces	Habilitado	Grupo ou processo definido	Evita espalhamento descontrolado de conteúdo
Instalar apps de template e tipos de visual	Habilitado	Revisar e restringir visuais não certificados	Visuais de terceiros podem exfiltrar dados

Uma nota sobre a última linha: os visuais personalizados (custom visuals) não certificados podem, em tese, enviar dados para fora. Restringir o tenant a visuais certificados ou a uma lista aprovada fecha um vetor real que quase ninguém trava.

Liberdade demais cria BI sombra, controle demais também#

O erro que vejo com mais frequência não é o excesso de liberdade, é a reação exagerada a ele. O admin descobre o risco, entra em pânico e desliga tudo. Duas semanas depois, a área que não consegue mais exportar um Excel simples está mandando dado por WhatsApp e montando planilha paralela fora do Power BI. Você não eliminou o risco, você o empurrou para onde não consegue mais ver.

Governança de tenant é uma negociação permanente entre liberdade e risco. A régua certa depende do setor, da maturidade do time e do tipo de dado. Uma fintech regulada configura diferente de uma varejista. O que não muda é o método: revise cada chave sabendo o que ela faz, prefira restringir por grupo em vez de desligar no braço, documente a decisão e reavalie a cada trimestre, porque a Microsoft adiciona configurações novas o tempo todo. Esse trabalho contínuo é o coração de um bom programa de governança de dados.

Perguntas frequentes#

Quem consegue acessar as tenant settings do Power BI?

Apenas quem tem papel de administrador do Fabric, administrador do Power BI ou administrador global do Microsoft 365. Quem administra o tenant controla o que toda a organização pode fazer com os dados. Trate esse acesso como privilegiado, com poucas pessoas e, de preferência, com PIM no Entra ID.

Desligar "Publicar na Web" quebra os relatórios internos?

Não. Publicar na Web só afeta a incorporação pública em sites abertos. O compartilhamento interno, os apps, os workspaces e a incorporação autenticada continuam funcionando igual. Você está fechando uma porta que quase ninguém deveria usar, sem tocar no uso legítimo do dia a dia.

Restringir por grupo de segurança dá muito trabalho de manter?

Dá algum trabalho, e é trabalho que vale a pena. O segredo é criar grupos com nomes claros e amarrá-los ao seu processo de solicitação de acesso, com fluxo de aprovação. O custo de manter os grupos é muito menor do que o de um vazamento ou de uma auditoria de LGPD que encontra dados expostos sem controle.

Service principal é seguro ou é mais um risco a gerenciar?

É mais seguro do que a alternativa, que é rodar automação na conta pessoal de um funcionário. O service principal é uma identidade dedicada, sem senha de usuário, com escopo que você controla e que não some quando alguém sai da empresa. O risco só aparece se você habilitar para todo mundo sem restrição, por isso limite a um grupo com as aplicações aprovadas.

Como a LGPD entra nas decisões de exportação e compartilhamento?

A LGPD, Lei nº 13.709/2018, torna a empresa responsável por como trata dados pessoais, inclusive quando eles saem do ambiente controlado. Uma exportação para Excel com dados pessoais que circula sem rastreio é o tratamento sem controle que a lei cobra. Configurar exportação e compartilhamento por grupo, com auditoria, demonstra que a empresa governa esse fluxo.

Com que frequência devo revisar as tenant settings?

No mínimo a cada trimestre, e sempre que a Microsoft anunciar configurações novas, o que acontece com frequência porque o Fabric evolui rápido. Muitas chaves novas chegam habilitadas por padrão, então a revisão periódica é o que impede que um recurso novo abra um risco silencioso sem ninguém decidir por isso.

O admin portal é onde a governança começa#

Tenant settings não são detalhe técnico, são as regras do jogo para todo o Power BI da sua empresa. Revisar cada chave sabendo o que ela faz, restringir por grupo de segurança em vez de desligar no impulso, tratar Publicar na Web com o respeito que o risco merece e usar service principals para amadurecer a automação: esse é o roteiro que separa um tenant governado de um que só não deu problema ainda. Faça a primeira revisão hoje e coloque a reavaliação trimestral no calendário.

Se você quer um assessment das suas tenant settings feito por quem já configurou dezenas de tenants, fale com a gente. A Fynx ajuda a encontrar o equilíbrio entre liberdade e risco e a colocar a governança do seu Power BI em ordem sem travar a adoção.