Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Há 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 do seu aplicativo.
Importante
O recurso de conexões implícitas seguras foi lançado em janeiro de 2024. A Microsoft incentiva fortemente todos os aplicativos que atualmente usam conexões implícitas a converter em conexões implícitas seguras e revogar conexões compartilhadas com usuários finais.
Diferença entre conexões implícitas explícitas, implícitas e seguras
Uma conexão com o SQL Server é criada sempre que você cria um aplicativo usando o Power Apps que se conecta ao SQL Server. Quando esses aplicativos são publicados e compartilhados com outras pessoas, o aplicativo e 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 essas conexões pode ser explícito ou implícito. Também podemos dizer que essa conexão é compartilhada explicitamente ou implicitamente.
- Uma conexão compartilhada explicitamente significa que o usuário final do aplicativo deve autenticar-se no SQL Server com suas próprias credenciais explícitas. Normalmente, essa autenticação ocorre nos bastidores como parte do handshake de autenticação do Microsoft Entra ou do Windows. O usuário nem percebe quando a autenticação ocorre.
- Uma conexão compartilhada implicitamente significa que o usuário usa implicitamente as credenciais da conta que o criador de aplicativos usou para se conectar e autenticar na fonte de dados durante a criação do aplicativo. As credenciais do usuário final não são usadas para autenticar. Sempre que o usuário final executa o aplicativo, ele está usando as credenciais com as quais o autor criou o aplicativo.
- Uma conexão compartilhada implicitamente segura refere-se a um cenário em que o usuário final do aplicativo usa implicitamente as credenciais da conta que o criador de aplicativos usou para se conectar e autenticar à 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 autenticar. Em vez disso, quando o usuário executa o aplicativo, ele está usando as credenciais com as quais o autor do aplicativo o criou. É importante observar que o usuário final não é fornecido com acesso direto à conexão e o aplicativo só permite o 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 Power Apps:
| Tipo de autenticação | Método de conexão do Power Apps |
|---|---|
| Microsoft Entra Integrado | Explicit |
| Autenticação do SQL Server | Implícito/seguro implícito |
| Autenticação do Windows | Implícito/seguro implícito |
| Autenticação do Windows (não compartilhada) | Explicit |
Riscos implícitos de compartilhamento de conexão
Todos os novos aplicativos usam automaticamente as novas conexões implícitas seguras. No entanto, com 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 os usuários finais podem criar novos 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 reutilizando uma conexão para criar um novo aplicativo. Em vez disso, o aplicativo funciona com uma conexão proxy que esteja ciente do aplicativo e se comunique apenas com esse aplicativo específico. A conexão de 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 autorizadas e acesso são concedidos ao usuário final.
A conexão implícita simples de estilo mais antigo distribui um objeto de conexão para o usuário final. Por exemplo, se você criar um aplicativo que filtra os dados que não deseja que os usuários vejam. Porém, os dados filtrados estão presentes no banco de dados. Mas você está confiando no filtro configurado para garantir que os usuários finais não vejam determinados dados.
Novamente, com conexões implícitas simples de estilo mais antigo, depois de implantar o aplicativo, os usuários finais podem usar a conexão implantada com seu aplicativo em qualquer novo aplicativo que eles criarem. Nos novos aplicativos, os usuários podem ver os dados filtrados em seu aplicativo. É importante usar as novas conexões implícitas seguras.
Importante
Depois que uma conexão compartilhada implicitamente mais antiga é implantada para usuários finais, as restrições que você pode ter colocado no aplicativo compartilhado (como filtros ou acesso somente leitura) não são mais válidas para a criação de novos aplicativos que os usuários finais criam. Os usuários finais terão todos os direitos que a autenticação permitir como parte da conexão implicitamente compartilhada. 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 implicitamente compartilhadas com o kit de ferramentas COE.
Segurança do cliente e do servidor
Você não pode contar com a segurança dos dados por meio da filtragem ou de outras operações do lado do cliente para ser seguro. Os aplicativos que exigem filtragem segura de dados devem garantir que tanto a identificação do usuário quanto a filtragem ocorram no servidor.
Use serviços como a ID do Microsoft Entra em vez de depender dos filtros projetados dentro dos aplicativos quando se trata de identidade e segurança do usuário. Essa configuração garante que os filtros do lado do servidor funcionem conforme o esperado.
As ilustrações a seguir explicam como os padrões de segurança dentro dos aplicativos diferem entre modelos de segurança do lado do cliente e do servidor.
Em um padrão de aplicativo de segurança do cliente, [1] o usuário se autentica apenas no aplicativo no lado do cliente. Em seguida, [2] o aplicativo solicita informações do serviço e [3] o serviço retorna as informações apenas com base na solicitação de dados.
Em um padrão de segurança do lado do servidor, [1] o usuário se autentica primeiro no serviço para que o usuário seja conhecido pelo serviço. Em seguida, [2] quando uma chamada é feita do aplicativo, o serviço [3] usa a identidade conhecida do usuário atual para filtrar os dados adequadamente e [4] retorna os dados.
Os cenários implícitos de compartilhamento departamental descritos acima são uma combinação desses dois padrões. O usuário deve fazer logon no serviço do Power Apps usando as credenciais do Microsoft Entra. Esse comportamento é o padrão do aplicativo de segurança do servidor. O usuário é conhecido usando a identidade do Microsoft Entra no serviço. Portanto, o aplicativo é restrito ao conjunto de usuários ao qual o Power Apps compartilhou formalmente o aplicativo.
No entanto, a conexão compartilhada implícita com o SQL Server é o padrão do aplicativo de segurança do cliente. O SQL Server só sabe que um nome de usuário e uma senha específicos são usados. Qualquer filtragem do lado do cliente, por exemplo, pode ser ignorada com um novo aplicativo usando o mesmo nome de usuário e senha.
Para filtrar dados com segurança no lado do servidor, use recursos de segurança internos no SQL Server, como segurança em nível de linha para linhas, e as permissões de negação para objetos específicos (como colunas) para usuários específicos. Essa abordagem usa a identidade do usuário do Microsoft Entra para filtrar os dados no servidor.
Alguns serviços corporativos existentes usaram uma abordagem em que a identidade do usuário é capturada em uma camada de dados de negócios da mesma forma que o Microsoft Dataverse. Nesse caso, a camada de negócios pode ou não usar a segurança em nível de linha do SQL Server e negar recursos diretamente. Caso contrário, geralmente é o caso de a segurança estar habilitada usando procedimentos armazenados ou exibições.
A camada de negócios (no lado do servidor) usa uma identidade conhecida do Microsoft Entra do usuário para invocar um procedimento armazenado como uma entidade de segurança do SQL Server e filtrar os dados. No entanto, o Power Apps não se conecta atualmente aos procedimentos armazenados. Uma camada de negócios também pode invocar uma exibição que usa a identidade do Microsoft Entra como uma entidade de segurança do SQL Server. Nesse caso, use o Power Apps para se conectar aos modos de exibição para que os dados sejam filtrados no lado do servidor. Expor apenas exibições aos usuários pode precisar de fluxos do Power Automate para atualizações.