Service principal no Power BI: automação segura

Automação de BI presa na conta de um funcionário é uma bomba-relógio#

Você já viu isso: o script que atualiza um dataset toda madrugada roda com o login pessoal de um analista. No dia em que esse analista sai da empresa, troca de senha ou tem o MFA acionado, a automação inteira para, e ninguém sabe direito onde o usuário e a senha estão guardados. Um service principal no Power BI existe justamente para acabar com esse tipo de gambiarra: ele é a identidade de máquina que roda a automação sem depender de gente, sem senha de usuário e sem MFA para quebrar no meio da noite.

Neste artigo eu explico o que é um service principal, por que ele é a forma correta de automatizar no Power BI, como ele se conecta na API REST e no endpoint XMLA, e onde a maioria dos times erra na guarda do segredo e nas permissões. É um assunto de meio de funil: você já sabe que precisa automatizar, o que falta é fazer isso de um jeito seguro e sustentável.

Um service principal é a identidade de um app, não de uma pessoa#

Todo tenant do Microsoft 365 tem um diretório de identidades chamado Microsoft Entra ID, o antigo Azure Active Directory. Quando você registra uma aplicação nesse diretório, o Entra ID cria dois objetos: o registro do app, que é a definição global da aplicação, e o service principal, que é a instância dessa aplicação dentro do seu tenant. Na prática, o service principal é a conta com que o seu código se autentica. Ele tem um identificador único, o Application ID, e uma credencial própria: um segredo ou um certificado.

A diferença para uma conta de usuário é o ponto central. Uma conta de usuário foi feita para uma pessoa: tem senha que expira, pode exigir MFA, pode ser bloqueada por política de acesso condicional e some do tenant quando o RH desliga a pessoa. Nada disso combina com um processo que roda sozinho às três da manhã. O service principal não tem senha interativa, não passa por MFA e não desaparece quando alguém pede demissão. Ele existe enquanto a aplicação existir, com credenciais que você controla e renova de forma planejada.

Aspecto	Conta de usuário	Service principal
Para quem foi feita	Uma pessoa	Uma aplicação ou processo
Autenticação	Senha, muitas vezes com MFA	Segredo ou certificado
Quebra com troca de senha	Sim	Não
Some quando a pessoa sai	Sim	Não
Sujeita a acesso condicional e MFA	Sim	Em geral não, no fluxo de app
Ideal para automação sem humano	Não	Sim

A tabela deixa claro por que insistir em conta de usuário para automação é um erro de arquitetura, não questão de gosto: cada item da coluna do usuário é um ponto de falha para um processo que roda sem interação.

Service principal no Power BI serve para automação sem interação humana#

Vale separar bem os dois modos de acesso. O fluxo interativo é aquele em que um humano abre o navegador, digita usuário e senha e confirma o MFA para acessar o portal e olhar relatórios. O fluxo de aplicação é o oposto: o código apresenta o Application ID mais o segredo ou o certificado, recebe um token de acesso do Entra ID e chama a API com esse token. Não há tela de login, não há humano, não há MFA. Esse fluxo, conhecido como client credentials, é exatamente para o que o service principal foi desenhado.

Os casos em que isso importa aparecem o tempo todo em projetos sérios de Power BI:

• Disparar a atualização de um dataset a partir de um pipeline, logo depois que a carga do data warehouse termina, sem depender do agendador nativo.
• Provisionar workspaces, publicar relatórios e mover conteúdo entre desenvolvimento, homologação e produção de forma automatizada.
• Exportar relatórios em PDF ou PPTX em lote para envio programado.
• Ler metadados de uso e inventário do tenant para alimentar um painel de governança.
• Rodar operações de escrita no modelo via XMLA, como processar partições ou aplicar mudanças de metadados.

Em todos esses cenários, o que você quer é um agente que não seja uma pessoa. Amarrar qualquer um deles a um login pessoal cria dependência de um indivíduo para um processo que deveria ser institucional. Se você está montando esse tipo de esteira, vale ver como estruturamos a sustentação de BI, porque o service principal é a peça de identidade que sustenta toda a automação de promoção de conteúdo.

Habilitar nas tenant settings e dar acesso ao workspace são passos obrigatórios#

Aqui está o erro mais comum de quem registra o app e sai tentando chamar a API: esquecer que existem dois portões antes de o service principal conseguir fazer qualquer coisa útil no Power BI.

O primeiro portão é o tenant. Registrar o app no Entra ID não basta. Um administrador do Power BI precisa entrar no portal de administração, na área de configurações do tenant, e habilitar explicitamente o uso de service principals para a API do Power BI. A boa prática, e o que eu recomendo em todo projeto, é não liberar isso para o tenant inteiro. Crie um grupo de segurança no Entra ID, coloque o service principal nesse grupo e restrinja a configuração para atender apenas esse grupo. Assim você controla exatamente quais aplicações podem usar a API, em vez de abrir a porta para qualquer app registrado no diretório.

O segundo portão é o workspace. Ter permissão de API não dá acesso a nenhum conteúdo específico. O service principal precisa ser adicionado como membro do workspace onde estão os relatórios e datasets que ele vai manipular, exatamente como você adicionaria um colega de equipe. O papel que você concede nesse workspace define o que ele pode fazer, e é aqui que o menor privilégio começa a valer na prática.

Etapa	Onde se configura	Quem executa
Registro do app	Microsoft Entra ID	Admin do Entra ID
Criação do segredo ou certificado	Microsoft Entra ID	Admin do Entra ID
Habilitar service principal na API	Configurações do tenant do Power BI	Admin do Power BI
Restringir por grupo de segurança	Entra ID mais tenant settings	Admin do Power BI
Acesso ao conteúdo	Papel no workspace	Admin do workspace

Quando algo não funciona, o problema quase sempre está em um desses passos. O token vem certinho do Entra ID, mas a chamada retorna erro de permissão porque o tenant não habilitou service principals ou porque ninguém adicionou o app ao workspace. Cheque os dois antes de sair depurando o código.

API REST e endpoint XMLA são os dois caminhos de acesso#

Um service principal autenticado consegue falar com o Power BI por duas portas diferentes, e cada uma serve a um propósito.

A API REST do Power BI é a porta de gestão. Por ela você atualiza datasets, publica e exporta relatórios, cria e administra workspaces, gerencia permissões e lê informações de administração do tenant. É uma API HTTP comum: você manda a requisição com o token no cabeçalho de autorização e recebe a resposta em JSON. É o caminho para automatizar operações de plataforma, do refresh agendado ao inventário de governança.

O endpoint XMLA é a porta de dados do modelo semântico. Ele expõe o motor Analysis Services que roda por baixo de todo dataset do Power BI. Por ele você conecta ferramentas como Tabular Editor, SQL Server Management Studio ou bibliotecas de código para operações profundas no modelo: processar partições, editar metadados via TMSL, rodar consultas DAX e MDX diretamente contra o dataset. É o caminho para quem faz gestão avançada do modelo e cenários de ALM que a interface do portal não cobre. O acesso de escrita pelo XMLA exige capacidade Premium ou Fabric, então vale confirmar o tipo de licença antes de desenhar a solução em cima dele.

Na maioria dos projetos você usa os dois: a API REST orquestra o processo e o XMLA faz o trabalho fino no modelo. Um service principal bem configurado atende às duas portas com a mesma identidade. Se a sua automação nasce de um pipeline de engenharia de dados, o padrão comum é o próprio pipeline chamar a API REST para disparar o refresh assim que a camada de dados fica pronta.

O segredo mal guardado joga toda a segurança no lixo#

Aqui está a parte que separa a automação madura da improvisada. O service principal resolve o problema da conta de usuário, mas cria um novo: a credencial dele, o segredo ou o certificado, é o que dá acesso a tudo. Se ela vaza, quem a tem se passa pela sua aplicação, e o segredo não tem MFA nem segunda barreira, ele é a barreira. Guardá-lo direito não é detalhe, é o ponto que faz ou desfaz a segurança da solução inteira.

O que eu recomendo, do mais fraco ao mais forte:

• Nunca deixe o segredo em texto puro no código, em arquivo de configuração versionado no Git ou colado num script de agendador. É o erro que aparece em quase toda auditoria de projeto herdado.
• Use um cofre gerenciado, como o Azure Key Vault. O código busca a credencial em tempo de execução, com acesso controlado, e o valor nunca fica escrito no repositório.
• Prefira certificado a segredo sempre que a ferramenta permitir. Um certificado é mais difícil de vazar por acidente do que uma string colável e casa melhor com rotação.
• Defina prazo de expiração e um processo de rotação. Segredo que nunca expira é segredo que um dia vaza sem ninguém perceber.
• Registre e monitore o uso da identidade. Saber quando e de onde ela autenticou ajuda a detectar uso indevido antes que vire incidente.

Essas práticas fazem parte de uma disciplina maior de proteção de credenciais e acessos, que trato no serviço de governança de dados. Automação segura não é só ter o service principal, é ter o processo de guarda e rotação em volta dele.

O menor privilégio é a regra que quase todo mundo ignora#

O princípio do menor privilégio diz o óbvio que raramente é praticado: dê à identidade apenas o acesso de que ela realmente precisa, e nada além. Na pressa de fazer funcionar, o padrão que eu mais encontro é o service principal virar administrador de tudo, com papel de Admin em todo workspace. Funciona, e é por isso que é perigoso: no dia em que a credencial vazar, o estrago é do tamanho do acesso que você concedeu.

Pense em cada automação separadamente. Um service principal que só atualiza datasets não precisa ser Admin do workspace, o papel de Contribuidor costuma bastar para disparar refresh. Um app que só lê metadados para um painel de governança precisa de leitura administrativa, não de escrita em conteúdo. Se você tem processos com necessidades diferentes, considere identidades separadas, cada uma com o seu escopo, em vez de uma superidentidade que faz tudo.

Os papéis de workspace dão o controle fino de que você precisa:

Papel no workspace	O que permite	Bom para
Visualizador	Ler conteúdo	Leitura controlada, exportação simples
Colaborador	Publicar e atualizar conteúdo	Refresh de dataset, publicação automatizada
Membro	Colaborar e compartilhar	Automação que gerencia acesso
Administrador	Controle total do workspace	Provisionamento e gestão completa

Comece pelo papel mais baixo que resolve a tarefa e só suba se a operação exigir. Menor privilégio não é burocracia, é o que limita o raio de explosão de um vazamento.

Perguntas frequentes#

Qual a diferença entre um service principal e uma conta de serviço no Power BI?

Uma conta de serviço é uma conta de usuário comum criada para automação, com usuário e senha, e por isso ainda sofre com expiração de senha, MFA e políticas de acesso condicional. Um service principal é uma identidade de aplicação no Entra ID, sem senha interativa e sem MFA, feita para acesso não interativo. O service principal é a abordagem recomendada pela própria Microsoft justamente por não carregar as fragilidades da conta de usuário.

Preciso de licença Power BI Pro para o service principal?

Para operações via API REST em conteúdo dentro de um workspace, o que costuma pesar é a licença do workspace, não uma licença Pro atribuída ao service principal, já que ele não é um usuário que consome licença da mesma forma. Para escrita pelo endpoint XMLA e cenários mais avançados, você precisa de capacidade Premium ou Fabric associada ao workspace. Vale confirmar o cenário específico antes de dimensionar as licenças.

O service principal funciona com gateway de dados local?

Sim. Fontes de dados on-premises acessadas por gateway continuam funcionando com refresh disparado por service principal, desde que a configuração da fonte e do gateway esteja correta. O que muda é quem dispara a atualização, não o caminho pelo qual os dados são lidos. Ainda é preciso mapear a fonte no gateway normalmente.

Segredo ou certificado, qual devo usar?

Prefira certificado quando a ferramenta permitir. O segredo é uma string, mais fácil de copiar por engano, colar em log ou versionar sem querer. O certificado é mais robusto e se encaixa melhor em rotação automatizada. Se optar por segredo, guarde em um cofre como o Azure Key Vault, defina expiração e mantenha um processo de rotação ativo.

Como um service principal pode acessar um dataset se ele não faz login no portal?

Ele não faz login interativo, mas se autentica no Entra ID pelo fluxo de client credentials, apresentando o Application ID e a credencial. O Entra ID devolve um token de acesso, que o service principal usa para chamar a API REST ou o XMLA. Do ponto de vista do Power BI, é uma identidade legítima com permissão no workspace, ela só não passa por uma tela de senha.

O que acontece se o segredo do service principal vazar?

Quem tiver o segredo consegue se passar pela sua aplicação e fazer tudo o que ela pode fazer, até você revogar a credencial. Por isso o menor privilégio importa tanto: quanto menor o acesso concedido, menor o estrago. Ao suspeitar de vazamento, revogue o segredo comprometido no Entra ID imediatamente, gere um novo e atualize o cofre. Monitorar o uso da identidade ajuda a perceber o problema antes que ele escale.

Automação de BI se faz com identidade de máquina, não com login de gente#

Um service principal bem configurado é o que transforma automação de Power BI de gambiarra frágil em processo confiável: identidade própria no Entra ID, habilitada no tenant e no workspace, credencial guardada em cofre e permissões cortadas ao mínimo necessário. O trabalho não termina no registro do app, ele começa ali. A guarda do segredo e o menor privilégio são o que fazem a diferença entre uma solução segura e uma auditoria constrangedora daqui a um ano.

Se você quer estruturar a automação e a governança do seu ambiente Power BI do jeito certo, fale com a gente. A Fynx já entregou mais de 2.000 soluções Microsoft e mais de 10.000 horas de desenvolvimento para mais de 50 clientes, e ajudamos o seu time a fazer isso sem deixar credencial de pessoa física sustentando produção.