Use o Microsoft SQL Server de forma segura com o Power Apps
Existem diferentes formas de ligar e autenticar ao 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 da sua aplicação.
Importante
A funcionalidade de ligações implícitas seguras foi lançada em janeiro de 2024. A Microsoft encoraja vivamente todas as aplicações que atualmente utilizam ligações implícitas a converterem para ligações implícitas seguras e a revogarem as ligações partilhadas com os utilizadores finais.
Diferença entre ligações explícitas, implícitas e implícitas seguras
Uma ligação ao SQL Server é criada sempre que cria uma aplicação utilizando o Power Apps a ligar ao SQL Server. Quando estas aplicações são publicadas e partilhadas com outras, tanto a aplicação como a ligação são implementadas para esses utilizadores. Por outras palavras, a aplicação e a ligação—ambos são visíveis para os utilizadores com quem se partilhas as aplicações.
O método de autenticação utilizado para tais ligações pode ser explícito ou implícito. Também podemos dizer que tal ligação é partilhada explicita ou implicitamente.
- Uma ligação explicitamente partilhada significa que o utilizador final da aplicação se deve autenticar no SQL Server com as suas próprias credenciais explícitas. Normalmente, esta autenticação acontece nos bastidores como parte da autenticação do Microsoft Entra ou do Windows. O utilizador nem sequer nota quando a autenticação ocorre.
- Uma ligação implicitamente partilhada significa que o utilizador utiliza implicitamente as credenciais da conta que o criador de aplicações usou para ligar e autenticar à origem de dados durante a criação da aplicação. As credenciais do utilizador final não são utilizadas para autenticar. Cada vez que o utilizador final executa a aplicação, está a usar as credenciais com que o autor criou a aplicação.
- Uma ligação partilhada implicitamente segura refere-se a um cenário onde o utilizador final da aplicação utiliza implicitamente as credenciais da conta que o criador de aplicações usou para ligar e autenticar à origem de dados durante a criação da aplicação. Isto significa que as próprias credenciais do utilizador final não são utilizadas para autenticar. Em vez disso, quando o utilizador executa a aplicação, está a usar as credenciais com que o autor da aplicação a criou. É importante notar que o utilizador final não tem acesso direto à ligação e a aplicação só permite o acesso a um conjunto limitado de ações e tabelas.
Os seguintes quatro tipos de autenticação de ligação podem ser utilizados com o SQL Server para o Power Apps:
| Tipo de Autenticação | Métod de ligação do Power Apps |
|---|---|
| Microsoft Entra Integrado | Explícito |
| Autenticação do SQL Server | Implícito / Implícito Seguro |
| Autenticação do Windows | Implícito / Implícito Seguro |
| Autenticação do Windows (não partilhada) | Explícito |
Riscos implícitos de partilha da ligação
Todas as novas aplicações utilizam automaticamente as novas ligações implícitas seguras. No entanto, com as aplicações que utilizam as "ligações implícitas" mais antigas, tanto a aplicação como as respetivas ligações são implementadas para os utilizadores finais, o que significa que os utilizadores finais podem criar novas aplicações com base nessas ligações.
Quando um autor usa ligações implícitas seguras, isso significa que nenhuma ligação é partilhada e nenhum utilizador final recebe o objeto de ligação. Isto elimina o risco de um autor utilizador final reutilizar uma ligação para criar uma nova aplicação. Em vez disso, a aplicação funciona com uma ligação de proxy que está ciente da aplicação e apenas comunica com essa aplicação específica. A ligação de proxy permite ações limitadas (criar, ler, atualizar, eliminar) e o acesso a tabelas específicas na aplicação que são definidas quando a aplicação é publicada. Consequentemente, só são concedidos ações e acesso autorizados ao utilizador final.
A ligação implícita simples do estilo antigo distribui realmente um objeto de ligação para o utilizador final. Por exemplo, se criar uma aplicação que filtre os dados que não quer que os utilizadores vejam. Mas, os dados filtrados estão presentes na base de dados. Mas está a contar com o filtro configurado para garantir que os utilizadores finais não vejam determinados dados.
Mais uma vez, com ligações implícitas simples de estilo mais antigo, depois de implementar a aplicação, os utilizadores finais podem utilizar a ligação implementada com a sua aplicação em quaisquer novas aplicações que criem. Nas novas aplicações, os utilizadores podem ver os dados filtrados na sua aplicação. É importante utilizar as novas ligações implícitas seguras.
Importante
Uma vez implementada uma ligação implicitamente partilhada mais antiga para os utilizadores finais, as restrições que pode ter colocado na aplicação que partilhou (como filtros ou acesso só de leitura) já não são válidas para novas aplicações que os utilizadores finais criam. Os utilizadores finais terão todos os direitos que a autenticação permite como parte de uma ligação implicitamente partilhada. Por conseguinte, quando converte uma aplicação para utilizar ligações implícitas seguras, também tem de revogar as ligações que partilhou com a sua aplicação. Os administradores podem obter um relatório de aplicações com ligações partilhadas implicitamente com o kit de ferramentas COE.
Segurança do cliente e do servidor
Não pode confiar na segurança dos dados através da filtragem ou de outras operações do lado do cliente para ser seguro. As aplicações que exijam uma filtragem segura dos dados devem garantir que tanto a identificação como a filtragem do utilizador ocorrem no servidor.
Utilize serviços como o ID do Microsoft Entra, em vez de confiar nos filtros concebidos nas aplicações no que diz respeito à identidade e segurança do utilizador. Esta configuração garante que os filtros do lado do servidor funcionam conforme o esperado.
As seguintes ilustrações explicam como os padrões de segurança nas aplicações diferem entre os modelos de segurança do lado do cliente e do servidor.
Num padrão de aplicação de segurança do cliente, [1] o utilizador autentica apenas a aplicação do lado do cliente. Em seguida [2], a aplicação solicita informações do serviço e [3] o serviço devolve a informação unicamente com base no pedido de dados.
Num padrão de segurança do lado do servidor, [1] o utilizador autentica-se pela primeira vez no serviço para que o utilizador seja conhecido do serviço. Em seguida, [2] quando uma chamada é feita a partir da aplicação, o serviço [3] utiliza a identidade conhecida do utilizador atual para filtrar os dados adequadamente e [4] devolver os dados.
Os cenários implícitos de partilha de departamentos descritos acima é a combinação destes dois padrões. O utilizador deve iniciar sessão no serviço Power Apps utilizando credenciais do Microsoft Entra. Este comportamento é o padrão da aplicação de segurança do servidor. O utilizador é conhecido utilizando a identidade Microsoft Entra no serviço. Assim, a aplicação está restringida ao conjunto de utilizadores com quem o Power Apps partilhou formalmente a aplicação.
No entanto, a ligação partilhada implícita ao SQL Server é o padrão da aplicação de segurança do cliente. O SQL Server só sabe que é utilizado um nome de utilizador e uma palavra-passe específicas. Qualquer filtragem do lado do cliente, por exemplo, pode ser contornada com uma nova aplicação usando o mesmo nome de utilizador e senha.
Para filtrar de forma segura os dados do lado do servidor, utilize funcionalidades de segurança incorporadas no SQL Server, como a segurança do nível da linha para linhas e as permissões de negação para objetos específicos (como colunas) para utilizadores específicos. Esta abordagem utiliza a identidade do utilizador do Microsoft Entra para filtrar os dados no servidor.
Alguns serviços corporativos existentes usaram uma abordagem em que a identidade do utilizador é capturada numa camada de dados empresariais da mesma forma que o Microsoft Dataverse o faz. Neste caso, a camada empresarial pode ou não usar a segurança de nível de linha do SQL Server e negar diretamente as funcionalidades. Se não o fizer, é frequentemente o caso em que a segurança é ativada usando procedimentos ou vistas armazenadas.
A camada empresarial (do lado do servidor) utiliza uma identidade conhecida do Microsoft Entra do utilizador para invocar um procedimento armazenado como principal do SQL Server e filtrar os dados. No entanto, o Power Apps atualmente não se conecta a procedimentos armazenados. Uma camada empresarial também pode invocar uma vista que usa a identidade do Microsoft Entra como principal do SQL Server. Neste caso, utilize o Power Apps para ligar as vistas de modo a que os dados sejam filtrados no lado do servidor. Expor apenas vistas aos utilizadores pode precisar de fluxos do Power Automate para atualizações.