Protegendo seu portal do Power Pages: um mergulho profundo em permissões de tabela e escopos

By Mirko Peters · 2026-08-11

Bem-vindo de volta ao blog do podcast! Ao criar aplicativos web voltados para clientes na Microsoft Power Platform, a segurança não pode ser um pensamento tardio. O Power Pages é uma ferramenta incrível para implantar rapidamente portais externos robustos conectados diretamente ao Dataverse. No entanto, com grande poder vem grande responsabilidade, especificamente a responsabilidade de garantir qu

Automatically translated with AI from the original post. Read the English original

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

Neste post, vamos aprofundar bastante os conceitos centrais de arquitetura de segurança que discutimos em nosso episódio recente. Se você ainda não o ouviu, vale conferir o episódio Build Customer Portals with Power Pages and Dataverse, com um passo a passo completo para configurar seu ambiente, lidar com identidades externas e implantar sua primeira solução de portal.

Vamos mergulhar na mecânica da segurança do Power Pages, começando por como planejar os limites dos seus dados e dominar as permissões de tabela.

Introdução à segurança do Power Pages

Quando você cria um site no Power Pages pela primeira vez, a plataforma oferece uma tela flexível e altamente personalizável. Mas por trás dessa tela existe um canal direto para o seu ambiente Microsoft Dataverse. Se as configurações de segurança forem mal gerenciadas, cada registro do seu banco de dados pode ficar exposto por meio de um endpoint sem proteção ou de uma exibição de lista mal delimitada.

A segurança no Power Pages depende de uma estratégia de defesa em múltiplas camadas. Na camada externa, existem os mecanismos de autenticação, como o Azure AD B2C, contas locais ou provedores de identidade externos, que garantem que os usuários comprovem quem são. Na camada interna, existem as funções da Web e as permissões de tabela do Dataverse. Essas permissões definem exatamente o que as identidades autenticadas podem visualizar, criar, atualizar ou excluir. Acertar nisso é a diferença entre um portal corporativo seguro e uma violação de dados massiva esperando para acontecer.

Planejando os limites dos dados e as permissões de tabela

Antes de tocar em qualquer botão no Power Pages Studio, pegue um quadro branco e mapeie com cuidado os limites dos seus dados. Esses são, sem dúvida, os 15 minutos mais críticos de todo o ciclo de vida do seu projeto de portal.

Comece criando um inventário completo de cada tabela do Dataverse que você planeja expor aos seus usuários externos. Para cada tabela, defina o mínimo absoluto de ações CRUD necessárias. Um cliente realmente precisa poder excluir uma fatura ou deveria ter apenas acesso de leitura e anexação? Depois de definir as ações, determine o escopo de linha de cada tabela:

Escopo de contato: O usuário só pode interagir com registros associados diretamente ao seu próprio registro de contato.
Escopo de conta: O usuário pode interagir com registros associados a toda a sua empresa ou conta.
Escopo global: O usuário pode ver todos os registros de toda a tabela (normalmente reservado para artigos públicos da Base de Conhecimento ou metadados).

Ao mapear esses limites logo no início, você estabelece uma linha de base de privilégio mínimo antes de qualquer configuração ser criada no seu ambiente de desenvolvimento.

Entendendo os escopos de contato e de conta

Um dos pontos de confusão mais comuns para criadores novos no Power Pages é entender a diferença entre os escopos de contato e de conta. Escolher o escopo errado pode tanto quebrar completamente a experiência do usuário, ocultando dados relevantes da empresa, quanto expor inadvertidamente dados confidenciais a pessoas não autorizadas.

O Escopo de contato foi projetado para portais individuais no estilo consumidor. Se um usuário faz login e envia um chamado de suporte, uma permissão com escopo de contato garante que ele só possa visualizar os casos em que está explicitamente listado como contato principal ou criador. Se outro usuário da mesma empresa fizer login, ele não verá os chamados de suporte pessoais do colega.

Por outro lado, o Escopo de conta é feito para arquiteturas de portal B2B. Em um cenário B2B, você quer que um gerente de contas ou um responsável principal de compras consiga ver todos os casos, pedidos e faturas associados à conta-mãe corporativa. Ao atribuir um escopo de Conta a uma permissão de tabela, o portal avalia a conta-mãe vinculada ao registro de Contato do usuário conectado e, em seguida, exibe todos os registros filhos relacionados àquela organização. Mapear esse relacionamento corretamente no Dataverse é fundamental para o sucesso em B2B.

Definindo funções da Web e evitando a armadilha do grupo Usuários autenticados

As funções da Web são a ponte entre seus usuários autenticados e as permissões de tabela do Dataverse. Por padrão, o Power Pages inclui uma função padrão chamada "Usuários autenticados". É aqui que muitos administradores caem em uma armadilha perigosa de segurança.

Por padrão, qualquer usuário que faça login com sucesso no seu portal é automaticamente incluído na função Usuários autenticados. Se você atribuir permissões de tabela amplas, ou pior, permissões de escopo Global, a essa função padrão, todas as pessoas que se registrarem no seu site herdarão automaticamente esses privilégios excessivos. Isso é um antipadrão de segurança gravíssimo.

Em vez disso, crie funções da Web personalizadas e granulares, adaptadas aos perfis específicos dos seus usuários. Por exemplo:

CustomerUser: associada a um escopo de Contato para tabelas operacionais como Casos e Pedidos, permitindo que os usuários acompanhem as próprias interações.
AccountManager: associada a um escopo de Conta, dando a líderes organizacionais designados visibilidade sobre os ativos de toda a empresa.
KnowledgeBaseViewer: associada globalmente, mas estritamente restrita a ações somente leitura em artigos de suporte públicos.

Sempre remova acessos padrão desnecessários e garanta que os usuários sejam explicitamente atribuídos a funções específicas, de acordo com o relacionamento deles com a organização.

Reforçando a visibilidade em nível de campo e protegendo dados pessoais

Controlar o acesso em nível de linha por meio de escopos de tabela é apenas metade da batalha. Você também precisa prestar muita atenção ao que está visível dentro de cada linha e lista. Expor Informações de Identificação Pessoal (PII), como números de telefone, endereços residenciais, dados financeiros ou anotações internas sobre funcionários, pode levar a graves violações de conformidade (como falhas em relação à LGPD ou ao GDPR).

Ao criar listas e formulários básicos no Power Pages, certifique-se de limpar suas exibições de colunas sensíveis. Só porque um campo está oculto no layout do formulário na interface não significa que ele não possa ser inspecionado ou obtido por meio das APIs da web subjacentes se as permissões forem amplas demais. Use exibições separadas e reforçadas (como uma "PublicView" designada) que contenham exclusivamente colunas seguras e saneadas. Se determinadas colunas precisarem permanecer na tabela do banco de dados, considere implementar a segurança em nível de coluna no Dataverse para restringir totalmente o acesso no nível do mecanismo de banco de dados.

Testes de penetração nas permissões do seu portal

Você nunca pode simplesmente presumir que seu modelo de segurança funciona; é preciso comprová-lo. Antes de promover qualquer solução de portal para um ambiente de teste ou de produção, execute testes de penetração rigorosos nas permissões de tabela e na lógica de roteamento.

Configure contas de usuário de teste para cada uma das funções da Web definidas. Entre como um CustomerUser padrão e tente visualizar dados pertencentes a outro Contato ou Conta. Experimente manipular a URL diretamente e adulterar GUIDs, trocando os IDs dos registros na barra de endereços do navegador, para verificar se o servidor bloqueia corretamente as solicitações não autorizadas. Além disso, revise os logs de diagnóstico e de auditoria do portal para confirmar que as tentativas de escalonamento de privilégios geram as respostas 403 Forbidden apropriadas.

Conclusão e melhores práticas

Proteger um portal do Power Pages exige planejamento deliberado, rigorosa aderência ao princípio do menor privilégio e um entendimento aprofundado das permissões de tabela e dos escopos do Dataverse. Ao abandonar padrões perigosos como a função Usuários autenticados, delimitar com cuidado o acesso às tabelas nos níveis de Contato ou Conta e reforçar a visibilidade em nível de campo, você consegue construir um portal de clientes que é altamente funcional e excepcionalmente seguro.

Para se aprofundar ainda mais neste tema e ver um guia de implementação completo, do início ao fim, incluindo a configuração de identidades externas, o desenho da arquitetura da solução e a preparação para o go-live, não deixe de ouvir o episódio do nosso podcast complementar: Build Customer Portals with Power Pages and Dataverse. Obrigado por ler, e fique ligado para mais dicas de especialista sobre como dominar o Microsoft Power Platform!