Usar o Microsoft SQL Server de forma segura com o Power Apps

Existem diferentes maneiras de se conectar e autenticar no SQL Server com o Power Apps. Este artigo descreve conceitos que podem ser úteis para fazer uma escolha sobre como se conectar ao SQL Server com uma abordagem de segurança que corresponda aos requisitos de seu aplicativo.

Importante

Este artigo se aplica a todos os bancos de dados relacionais e conexões implícitas.

Diferença entre conexões explícitas e implícitas

Uma conexão com o SQL Server é criada sempre que você cria um aplicativo usando o Power Apps conectando-se ao SQL Server. Quando esses aplicativos são publicados e compartilhados com outras pessoas, tanto o aplicativo quanto a conexão são implantados para esses usuários. Em outras palavras, o aplicativo e a conexão são visíveis para os usuários com os quais os aplicativos são compartilhados.

O método de autenticação usado para tais conexões pode ser explícito ou implícito. Também podemos afirmar que essa conexão é compartilhada explícita ou implicitamente.

• Uma conexão explicitamente compartilhada significa que o usuário final do aplicativo deve se autenticar no SQL Server com suas próprias credenciais explícitas. Geralmente, essa autenticação ocorre em segundo plano como parte do Microsoft Entra ou do handshake de autenticação do Windows. O usuário nem percebe quando a autenticação ocorre.
• Uma conexão implicitamente compartilhada significa que o usuário usa implicitamente as credenciais da conta que o criador do aplicativo usou para conectar e autenticar a fonte de dados durante a criação do aplicativo. As credenciais do usuário final não são usadas para autenticação. Cada vez que o usuário final executa o aplicativo, ele está usando as credenciais com as quais o autor criou o aplicativo.

Os quatro tipos de autenticação de conexão a seguir podem ser usados com o SQL Server para o Power Apps:

Tipo de Autenticação	Método de conexão do Power Apps
Microsoft Entra Integrated	Explícito
Autenticação do SQL Server	Implícito
Autenticação do Windows	Implícito
Autenticação do Windows (não compartilhada)	Explícito

Riscos implícitos de compartilhamento de conexão

Como o aplicativo e suas conexões são implantados para usuários finais, isso significa que usuários finais podem criar aplicativos com base nessas conexões.

Por exemplo, considere que você criou um aplicativo que filtrou os dados que você não deseja que os usuários vejam. Os dados filtrados estão presentes no banco de dados. Mas você está contando com o filtro que configurou para garantir que os usuários finais não vejam determinados dados.

Depois de implantar este aplicativo, os usuários finais podem usar a conexão implantada com o seu aplicativo em qualquer novo aplicativo que eles criarem. Nos novos aplicativos, os usuários podem ver os dados que você filtrou em seu aplicativo.

Importante

Depois que uma conexão compartilhada implicitamente é implantada nos usuários finais, as restrições que você pode ter colocado no aplicativo que você compartilhou (como filtros ou acesso somente leitura) não são mais válidas para novos aplicativos criados pelos usuários finais. Os usuários finais terão todos os direitos que a autenticação permitir como parte da conexão compartilhada implicitamente.

Usos de conexão implícita no mundo real

Existem casos de uso válidos para métodos de autenticação implícitos e explícitos. Considere o modelo de segurança e a facilidade de desenvolvimento ao escolher sua abordagem. Como regra geral, use um método de autenticação explícito para qualquer situação em que haja um requisito de negócios em que os dados devam ser restritos por linha ou coluna.

Como exemplo de caso de uso de conexão explícita, considere um gerente de vendas que só deve ter permissão para ver descontos de preço ou dados de custo de base que estão na mesma tabela onde outro vendedor precisa ver o produto e o preço.

Contudo, nem todos os dados precisam ser protegidos da mesma maneira. Um aplicativo é compartilhado e implantado em usuários ou grupos de usuários específicos. Pessoas fora desse grupo não têm acesso ao aplicativo ou à conexão. Portanto, se todos em um grupo estiverem autorizados a ver todos os dados de um banco de dados, um método implícito de compartilhamento funcionará bem.

Como exemplo de caso de uso de conexão implícita, considere um departamento que possui um pequeno banco de dados de projetos que estão rastreando. O banco de dados pode incluir informações como tíquetes de trabalho departamentais ou calendário corporativo para toda a empresa. Nesse cenário, a criação de mais aplicativos sobre a conexão implicitamente compartilhada pode ser incentivada, desde que todos os dados devam estar acessíveis a todos os usuários que têm acesso.

Os aplicativos criados com o Power Apps são projetados para serem acessíveis pelos usuários finais. Esse tipo de cenário é comum porque o custo de desenvolvimento associado às conexões implícitas é baixo.

Os aplicativos departamentais podem se transformar em aplicativos corporativos e de missão crítica. Nesses cenários, é importante entender que, à medida que um aplicativo departamental passa a abranger toda a empresa, ele precisará ter a segurança corporativa tradicional integrada. Essa abordagem é mais cara para esforços de criação de aplicativos, mas importante em cenários corporativos.

Segurança de cliente e servidor

Você não pode confiar na segurança dos dados por meio da filtragem ou de outras operações no cliente para estar seguro. Os aplicativos que requerem filtragem segura de dados devem garantir que a identificação do usuário e a filtragem ocorram no servidor.

Use serviços como o Microsoft Entra ID em vez de depender dos filtros criados nos aplicativos quando se trata de identidade e segurança do usuário. Essa configuração garante que os filtros no servidor funcionem conforme o esperado.

As ilustrações a seguir explicam como os padrões de segurança nos aplicativos diferem entre os modelos de segurança no cliente e no servidor.

Em um padrão de aplicativo de segurança do cliente, [1] o usuário só se autentica no aplicativo no cliente. Depois, [2] o aplicativo solicita informações do serviço e [3] o serviço retorna as informações exclusivamente com base na solicitação de dados.

Em um padrão de segurança no servidor, [1] o usuário primeiro se autentica no serviço para que ele seja conhecido pelo serviço. Depois, [2] quando uma chamada é feita por meio do aplicativo, o serviço [3] usa a identidade conhecida do usuário atual para filtrar os dados apropriadamente e [4] retorna os dados.

Os cenários implícitos de compartilhamento departamental descritos acima são a combinação desses dois padrões. O usuário deve fazer logon no serviço Power Apps usando credenciais do Microsoft Entra. Esse comportamento é o padrão do aplicativo de segurança do servidor. O usuário é conhecido por meio da identidade do Microsoft Entra no serviço. Portanto, o aplicativo é restrito ao conjunto de usuários com os quais o Power Apps compartilhou formalmente o aplicativo.

Entretanto, a conexão compartilhada implícita com o SQL Server é o padrão de aplicativo de segurança do cliente. O SQL Server sabe apenas que um nome de usuário e senha específicos são usados. Qualquer filtragem do cliente, por exemplo, pode ser contornada com um novo aplicativo usando o mesmo nome de usuário e senha.

Para filtrar dados com segurança no servidor, use recursos de segurança integrados no SQL Server, como segurança em nível de linha para linhas e negar permissões para objetos específicos (como colunas) para usuários específicos. Essa abordagem usará a identidade de usuário do Microsoft Entra para filtrar os dados no servidor.

Alguns serviços corporativos existentes têm usado uma abordagem em que a identidade do usuário é capturada em uma camada de dados corporativos da mesma forma que o Microsoft Dataverse faz. Nesse caso, a camada de negócios pode ou não usar a segurança de nível de linha do SQL Server e negar recursos diretamente. Em caso negativo, geralmente a segurança é ativada usando procedimentos armazenados ou exibições.

A camada de negócios (no servidor) usa uma identidade de usuário conhecida do Microsoft Entra para invocar um procedimento armazenado como uma entidade de segurança do SQL e filtrar os dados. No entanto, o Power Apps atualmente não se conecta a procedimentos armazenados. Uma camada de negócios também pode invocar uma exibição que usa a identidade do Microsoft Entra como entidade de segurança do SQL Server. Nesse caso, use o Power Apps para se conectar às exibições para que os dados sejam filtrados no servidor. A exposição de apenas exibições aos usuários pode requerer fluxos do Power Automate para atualizações.

Consulte também

Visão geral de conectores para aplicativos de tela