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
O recurso de conexões implícitas seguras foi lançado em janeiro de 2024. A Microsoft incentiva fortemente a conversão de todos os aplicativos que atualmente usam conexões implícitas em conexões implícitas seguras e a revogação das conexões compartilhadas com usuários finais.
Diferença entre conexões explícitas e implícitas e implícitas seguras
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.
- Uma conexão implicitamente compartilhada segura refere-se a um cenário em que o usuário final 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. Isso significa que as próprias credenciais do usuário final não são usadas para a autenticação. Em vez disso, quando o usuário final executa o aplicativo, ele usa as credenciais com as quais o autor criou o aplicativo. É importante observar que o usuário final não tem acesso direto à conexão, e o aplicativo só permite acesso a um conjunto limitado de ações e tabelas.
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ícita/implícita segura |
| Autenticação do Windows | Implícita/implícita segura |
| Autenticação do Windows (não compartilhada) | Explícito |
Riscos implícitos de compartilhamento de conexão
Todos os novos aplicativos usam automaticamente as novas conexões implícitas seguras. No entanto, com os aplicativos que usam as 'conexões implícitas' mais antigas, 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.
Quando um autor usa conexões implícitas seguras, isso significa que nenhuma conexão é compartilhada e nenhum usuário final recebe o objeto de conexão. Isso elimina o risco de um autor do usuário final reutilizar uma conexão para criar um novo aplicativo. Em vez disso, o aplicativo funciona com uma conexão proxy que reconhece o aplicativo e se comunica somente com esse aplicativo específico. A conexão proxy permite ações limitadas (criar, ler, atualizar, excluir) e acesso a tabelas específicas no aplicativo que são definidas quando o aplicativo é publicado. Portanto, somente ações e acesso autorizados são concedidos ao usuário final.
A conexão implícita simples de estilo mais antigo, na verdade, distribui um objeto de conexão para o usuário final. Por exemplo, se você criar um aplicativo que filtra os dados que você não quer que os usuários vejam. Mas, 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.
Novamente, com as conexões implícitas simples de estilo mais antigo, depois que você implantar esse aplicativo, os usuários finais poderão 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 usar as novas conexões implícitas seguras.
Importante
Depois que uma conexão compartilhada implicitamente mais antiga é 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 serão mais válidas para os 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. Portanto, ao converter um aplicativo para usar conexões implícitas seguras, você também deve revogar as conexões compartilhadas com seu aplicativo. Os administradores podem obter um relatório de aplicativos com conexões compartilhadas implicitamente com o kit de ferramentas do COE.
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 usa 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.