Power Pages: como criar um portal externo seguro

O problema não é criar o portal, é decidir quem enxerga o quê#

Toda empresa chega num momento em que precisa abrir uma porta para fora. Um fornecedor que deveria acompanhar o status do pedido dele sem ligar para o comprador. Um cliente que quer abrir um chamado e ver o andamento. A tentação é resolver isso com uma planilha compartilhada ou uma caixa de e-mail, e o resultado é sempre o mesmo: retrabalho, dado desatualizado e nenhuma rastreabilidade. O Power Pages existe justamente para essa camada externa, permitindo publicar um site web onde pessoas de fora da sua organização interagem com dados que vivem no Dataverse.

Este artigo é para quem já entendeu que precisa de um portal e agora quer saber como fazer isso sem abrir um buraco de segurança. Vou tratar o Power Pages de forma honesta: a parte difícil nunca é a página bonita, e sim o controle de acesso. Expor dado externo é uma decisão que envolve arquitetura, permissões e conformidade com a LGPD, não apenas design.

Power Pages é o antigo Power Apps Portals sobre o Dataverse#

Vale começar pelo que a ferramenta é de fato. O Power Pages é a evolução do que a Microsoft chamava de Power Apps Portals. Ele faz parte da família Power Platform e serve para criar sites web voltados ao público externo, sites que qualquer pessoa com o link pode acessar, com ou sem login, dependendo de como você configura.

A diferença central em relação a um site institucional comum é o que está por baixo. O Power Pages nasce conectado ao Dataverse, o banco de dados gerenciado da plataforma. Isso significa que uma página do portal pode listar registros de uma tabela, exibir o detalhe de um deles e permitir que o visitante crie ou edite um registro, tudo respeitando as regras de segurança que você definir. O portal não é uma vitrine estática, é uma janela controlada para os seus dados de negócio.

Se você ainda está avaliando a plataforma como um todo antes de mergulhar no portal, vale ler o nosso guia de Power Apps e Power Automate, que dá o panorama de onde cada peça se encaixa.

Páginas, templates e o estúdio de design#

A construção visual acontece em um estúdio de design próprio, com páginas, seções e componentes que você arrasta e configura. Há templates prontos para cenários comuns, como um portal de autoatendimento ou um site de captação, e você pode partir de um deles ou de uma página em branco. Para quem precisa de mais controle, o portal aceita HTML, CSS e JavaScript customizados, além de um mecanismo de templates chamado Liquid, que injeta dados do Dataverse diretamente no HTML da página.

Na prática, a camada visual raramente é o gargalo do projeto. O tempo de verdade vai para as três decisões seguintes: como a pessoa entra, o que ela pode ver e o que ela pode gravar.

Autenticação de usuários externos define quem entra#

A primeira decisão de segurança é a identidade. O Power Pages separa dois mundos: conteúdo anônimo, visível para qualquer visitante, e conteúdo autenticado, visível apenas para quem fez login. Essa fronteira precisa ser desenhada antes de qualquer página ir para o ar.

Para os usuários externos, o portal delega a autenticação a provedores de identidade. Em vez de você guardar senhas, o login é feito por um provedor confiável e o portal apenas confia no resultado. Os caminhos mais comuns são:

• Azure AD B2C ou o Microsoft Entra External ID, a opção recomendada pela Microsoft para gerenciar identidades de clientes e parceiros em escala.
• Provedores sociais e corporativos que seguem padrões abertos, como contas de outros diretórios via OpenID Connect, SAML ou OAuth 2.0.
• Um cadastro local com e-mail e senha, útil para cenários simples, porém com menos recursos de segurança que um provedor dedicado.

O ponto honesto aqui: cada usuário externo que se autentica vira um registro de contato no Dataverse, e é a esse contato que as permissões vão se prender. Autenticação e autorização são coisas diferentes. Fazer login apenas prova quem a pessoa é. O que ela pode fazer depende inteiramente da próxima camada.

Permissões de tabela e web roles controlam o que cada um vê#

Este é o coração da segurança do portal, e é onde a maioria dos projetos malfeitos falha. O acesso a dados no Power Pages é negado por padrão: nada de uma tabela do Dataverse aparece no portal até que você conceda permissão explícita. Isso é uma virtude, desde que você entenda o modelo.

Duas peças trabalham juntas:

• Permissões de tabela: definem quais operações são permitidas sobre quais registros de uma tabela. As operações são as clássicas de criar, ler, escrever, excluir e anexar.
• Web roles: são papéis atribuídos aos usuários. Uma permissão de tabela só tem efeito quando associada a um web role, e o usuário só ganha aquele acesso quando o web role é atribuído a ele.

O que torna o modelo poderoso, e exige atenção, é o escopo de cada permissão. Uma permissão de tabela não diz apenas "pode ler pedidos", ela diz "pode ler quais pedidos". Esse escopo muda tudo.

Escopo da permissão	Quem o registro alcança	Uso típico
Global	Todos os registros da tabela	Dados públicos ou de catálogo, onde não há segregação por dono
Contato	Apenas registros ligados ao contato logado	Cada cliente vê somente os próprios chamados ou pedidos
Conta	Registros da empresa (conta) do contato	Vários usuários da mesma empresa compartilham a visão
Self	O próprio registro de contato do usuário	Permitir que a pessoa edite o próprio cadastro

O erro clássico é conceder escopo Global por pressa e deixar um cliente enxergando os pedidos de outro. Em um portal externo, esse tipo de vazamento é grave e pode ter consequências legais. A regra de ouro é começar pelo escopo mais restrito e abrir só o necessário, testando com usuários reais de cada perfil antes de publicar.

Listas e formulários expõem os dados do Dataverse com controle#

Com identidade e permissões resolvidas, a exposição do dado acontece por dois componentes principais, ambos ancorados em objetos que você já configurou no Dataverse.

• Listas: são as visões em formato de tabela. Uma lista no portal reaproveita uma view do Dataverse para decidir quais colunas mostrar, como ordenar e como filtrar. É o que o visitante usa para navegar por vários registros, por exemplo a relação dos chamados dele.
• Formulários: são as telas de detalhe e de entrada de dados. Um formulário reaproveita a definição de um form do Dataverse e pode operar em três modos: inserção, edição e somente leitura. É por ele que o visitante cria um novo chamado ou atualiza um cadastro.

O detalhe que muitos ignoram: listas e formulários respeitam as permissões de tabela, mas não substituem elas. Esconder uma coluna no formulário não protege o dado, apenas o oculta da tela. Se a permissão de tabela concede leitura ampla, o dado ainda pode ser acessado por outras vias, como chamadas de API do próprio portal. A proteção real mora na permissão de tabela, não na interface.

Quando o portal precisa de lógica além do que o formulário oferece, entra o Power Automate para orquestrar aprovações, notificações e integrações, e o Dataverse para sustentar os relacionamentos. Essa combinação é o que transforma um formulário isolado em um processo de ponta a ponta. Se o seu caso pede esse tipo de orquestração, faz sentido olhar a plataforma de forma integrada em Power Platform.

Expor dado externo é uma decisão de segurança e de LGPD#

No momento em que você publica um portal externo, você passa a tratar dados pessoais de gente de fora da empresa, e isso ativa a Lei Geral de Proteção de Dados, a Lei nº 13.709/2018. Não é opcional e não é detalhe de rodapé.

Alguns pontos que precisam estar no seu checklist antes de abrir o portal ao público:

• Minimização de dados: colete e exiba apenas o que o processo exige. Um portal de chamados não precisa mostrar o CPF completo do cliente na tela de detalhe só porque a coluna existe.
• Base legal e finalidade: cada dado pessoal exposto ou coletado precisa de uma justificativa. Deixe claro ao titular por que aquele dado é pedido e como será usado.
• Segregação de acesso: garanta que o escopo das permissões de tabela impeça um titular de ver dados de outro. Este é o teste mais importante de todos.
• Trilha de auditoria: registre quem acessou e alterou o quê. O Dataverse oferece auditoria, e você deve ligá-la para as tabelas sensíveis.
• Ciclo de vida do dado: defina retenção e exclusão. Dado que não precisa mais existir é risco parado.

O quadro abaixo resume os riscos mais comuns em portais externos e o controle que os neutraliza.

Risco ao expor dados	Como se manifesta	Controle no Power Pages
Vazamento entre titulares	Cliente A vê dados do cliente B	Escopo Contato ou Conta nas permissões de tabela
Exposição de dado sensível	Coluna com CPF ou saúde visível sem necessidade	Remover a coluna da view e restringir a leitura
Acesso anônimo indevido	Página autenticada aberta como pública	Revisar a marcação de páginas e permissões por web role
Falta de rastreabilidade	Ninguém sabe quem alterou um registro	Auditoria do Dataverse ligada nas tabelas críticas
Coleta excessiva	Formulário pede mais dado do que precisa	Minimização de campos no formulário e na tabela

Governança de dados não é uma fase depois do portal, ela é requisito de projeto. Vale conectar essa disciplina ao restante do seu ambiente Microsoft, um tema que aprofundamos em governança de dados no Power BI e LGPD.

Um roteiro prático para colocar o portal no ar sem sustos#

Reunindo tudo, a ordem que costuma dar certo em projeto real é esta:

1. Modele os dados primeiro no Dataverse. Defina as tabelas, os relacionamentos e as colunas antes de pensar em telas. O portal só é tão bom quanto o modelo por baixo.
2. Desenhe os perfis de acesso. Liste quem entra, o que cada perfil pode ver e gravar, e traduza isso em web roles e permissões de tabela com o escopo mais restrito possível.
3. Configure a autenticação. Escolha o provedor de identidade adequado ao seu público e teste o fluxo de cadastro e login de ponta a ponta.
4. Construa listas e formulários. Reaproveite views e forms do Dataverse e monte a navegação. Deixe o visual para depois de a segurança estar de pé.
5. Teste com usuários reais de cada perfil. Faça login como se fosse cada tipo de visitante e tente ver o que não deveria. É neste teste que os vazamentos aparecem.
6. Ligue auditoria e revise a LGPD. Só depois de conformidade e trilha de auditoria em ordem o portal vai para produção.

Note que quatro dos seis passos são sobre dados e acesso, não sobre a página. Um portal externo é, antes de tudo, um exercício de segurança de dados vestido de site.

Perguntas frequentes#

O Power Pages substitui um site institucional em WordPress? Não é essa a proposta. O Power Pages brilha quando o site precisa ler e gravar dados do Dataverse com controle de acesso por usuário, como portais de autoatendimento, cadastro e chamados. Para um site puramente informativo, sem interação com dados de negócio, uma plataforma de conteúdo tradicional pode ser mais simples e barata.

Preciso de licença para cada usuário externo do portal? O licenciamento do Power Pages é baseado em capacidade, geralmente por volume de acessos autenticados ou anônimos, e não por uma licença nominal para cada usuário como nos apps internos. Os modelos e valores mudam com o tempo, então valide os números atuais com a Microsoft ou com o seu parceiro antes de fechar o escopo.

Qual a diferença entre web role e permissão de tabela? São camadas complementares. A permissão de tabela define quais operações são possíveis sobre quais registros de uma tabela. O web role é o papel atribuído ao usuário. A permissão só tem efeito quando ligada a um web role, e o usuário só recebe o acesso quando o web role é atribuído a ele. Pense no web role como o crachá e na permissão de tabela como a porta que aquele crachá abre.

Dá para conectar o portal aos meus dados que estão fora do Dataverse? Sim, com ressalvas. O Power Pages é nativo do Dataverse, então o caminho mais direto e seguro é ter os dados lá. Para fontes externas, você pode integrar por meio de fluxos do Power Automate, tabelas virtuais ou APIs, mas cada integração adiciona complexidade e superfície de segurança. Se o dado externo for grande ou sensível, vale planejar a arquitetura com apoio de engenharia de dados.

Como garanto que um cliente não veja os dados de outro? Pelo escopo das permissões de tabela. Use o escopo Contato para amarrar cada registro ao usuário logado, ou o escopo Conta quando vários usuários da mesma empresa devem compartilhar a visão. Depois, teste fazendo login como usuários diferentes e tentando acessar registros que não são seus. Nunca confie apenas em esconder colunas na tela.

O portal atende os requisitos da LGPD automaticamente? Não. A ferramenta oferece os controles, como permissões, auditoria e minimização, mas a conformidade depende de como você os configura e de políticas que vão além da tecnologia, como base legal, retenção e resposta a titulares. A Lei nº 13.709/2018 responsabiliza quem trata o dado, não o software.

Portal seguro é modelo de dados e permissão bem feitos#

O Power Pages entrega uma forma rápida de abrir seus dados do Dataverse para o mundo externo, com autenticação por provedores confiáveis, permissões de tabela e web roles para controlar cada acesso, e listas e formulários para expor os registros com critério. A página bonita é a parte fácil. O que separa um portal profissional de um incidente de segurança é o rigor no modelo de dados, no escopo das permissões e na conformidade com a LGPD.

Se você está avaliando um portal externo e quer desenhar essa camada de acesso do jeito certo desde o começo, fale com a gente.