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

Este artigo aplica-se a todas as bases de dados relacionais e ligações implícitas.

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

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.

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
Autenticação do Windows	Implícito
Autenticação do Windows (não partilhada)	Explícito

Riscos implícitos de partilha da ligação

Uma vez que tanto a aplicação como as suas ligações são implementadas para os utilizadores finais, isso significa que os utilizadores finais podem ser autores de novas aplicações com base nessas ligações.

Por exemplo, considere que criou uma aplicação que filtrava os dados que não quer que os utilizadores vejam. 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.

Depois de implementar esta aplicação, os utilizadores finais podem utilizar a ligação implementada com a sua aplicação em novas aplicações que criem. Nas novas aplicações, os utilizadores podem ver os dados filtrados na sua aplicação.

Importante

Uma vez implementada uma ligação implicitamente partilhada para os utilizadores finais, as restrições que pode ter colocado na aplicação que partilhou (como filtros ou acesso apenas 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.

Utilizações reais da ligação implícita

Existem casos de utilização válidos para métodos de autenticação implícita e explícita. Considere o modelo de segurança e a facilidade de desenvolvimento ao escolher a sua abordagem. Regra geral, utilize um método de autenticação explícito para qualquer situação em que tenha um requisito de negócio em que os dados devem ser restringidos numa base de linha ou coluna.

Para um exemplo de caso de utilização explícita de ligação, considere um gestor de vendas que só deve ser autorizado a ver descontos de preço ou dados de custos base que estejam na mesma tabela onde outro profissional de vendas precisa ver produto e preço.

No entanto, nem todos os dados podem ser protegidos da mesma forma. Uma aplicação é partilhada e implementada para utilizadores ou grupos de utilizadores específicos. As pessoas fora desse grupo não têm acesso à aplicação ou à ligação. Assim, se num grupo todos estiverem autorizados a ver todos os dados numa base de dados, um método implícito de partilha funciona bem.

Para um exemplo de caso de uso de ligação implícita, considere um departamento que tem uma pequena base de dados de projetos que estão a monitorizar. A base de dados pode incluir informações como bilhetes de trabalho dos departamentos ou calendário corporativo para toda a empresa. Neste cenário, a construção de mais aplicações em cima da ligação implicitamente partilhada pode ser incentivada desde que todos os dados estejam acessíveis a todos os utilizadores que tenham acesso.

As aplicações criadas com recurso ao Power Apps são concebidas para serem acedidas pelos utilizadores finais. Este tipo de cenário é comum porque o custo de desenvolvimento associado às ligações implícitas é baixo.

As aplicações baseadas no departamento podem crescer para aplicações críticas em missão e em toda a empresa. Nestes cenários, é importante entender que, à medida que uma aplicação de departamento se move para ser de toda a empresa, terá de ter a segurança empresarial tradicional incorporada. Esta abordagem é mais cara para os esforços de construção de aplicações, mas importante em cenários corporativos.

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 utilizará 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.

Consulte também

Descrição geral dos conectores para aplicações de tela