Usar Microsoft SQL Server de forma segura con Power Apps

Hai diferentes xeitos de conectar e autenticarse en SQL Server con Power Apps. Este artigo describe conceptos que poden ser útiles para facer unha elección sobre como conectarse a SQL Server cun enfoque de seguridade que coincida cos requisitos da súa aplicación.

Importante

Este artigo aplícase a todas as bases de datos relacionais e conexións implícitas.

Diferenza entre conexións explícitas e implícitas

Créase unha conexión a SQL Server sempre que crea unha aplicación usando Power Apps conectándose a SQL Server. Cando estas aplicacións se publican e se comparten con outras persoas, tanto a aplicación como a conexión despregaranse a eses usuarios. Noutras palabras, a aplicación e a conexión—son visibles para os usuarios cos que se comparten as aplicacións.

O método de autenticación empregado para tales conexións pode ser explícito ou implícito. Tamén podemos dicir que esa conexión se comparte de xeito explícito ou implícito.

• Unha conexión compartida explicitamente significa que o usuario final da aplicación debe autenticarse en SQL Server coas súas propias credenciais explícitas. Normalmente esta autenticación ocorre entre bastidores como parte de Azure Active Directory ou do protocolo de ligazón da autenticación de Windows. O usuario nin sequera nota cando ten lugar a autenticación.
• Unha conexión compartida implicitamente significa que o usuario utiliza de xeito implícito as credenciais da conta que o fabricante da aplicación utilizou para conectarse e autenticarse na orixe de datos durante a creación da aplicación. As credenciais do usuario final non se usan para autenticarse. Cada vez que o usuario final executa a aplicación, está a usar as credenciais coas que o autor creou a aplicación.

Os seguintes catro tipos de autenticación de conexión pódense usar con SQL Server para Power Apps:

Tipo de autenticación	Método de conexión de Power Apps
Azure AD integrado	Explícito
Autenticación de SQL Server	Implícito
Autenticación de Windows	Implícito
Autenticación de Windows (non compartida)	Explícito

Riscos implícitos para compartir conexións

Dado que tanto a aplicación como as súas conexións están despregadas para usuarios finais, iso significa que os usuarios finais poden crear novas aplicacións en función desas conexións.

Por exemplo, considere que creou unha aplicación que filtrou os datos que non quere que vexan os usuarios. Os datos filtrados están presentes na base de datos. Pero dependerá do filtro que configurou para garantir que os usuarios finais non vexan determinados datos.

Despois de implementar esta aplicación, os usuarios finais poderán usar a conexión despregada coa súa aplicación en calquera aplicación nova que creen. Nas novas aplicacións, os usuarios poden ver os datos que filtrou na súa aplicación.

Importante

Unha vez que se desprega unha conexión compartida de xeito implícito cos usuarios finais, as restricións que pode ter colocadas na aplicación que compartiu (como filtros ou acceso de só lectura) xa non son válidas para as novas aplicacións que crean os usuarios finais. Os usuarios finais terán os dereitos que permita a autenticación como parte dunha conexión compartida de xeito implícito.

Usos do mundo real da conexión implícita

Hai casos de uso válidos para métodos de autenticación implícitos e explícitos. Considere o modelo de seguridade e a facilidade de desenvolvemento á hora de elixir o seu enfoque. Como regra xeral, use un método de autenticación explícito para calquera situación na que teña un requisito empresarial onde os datos deben restrinxirse en fila ou columna.

Para obter un exemplo de caso de uso de conexión explícito, considere o caso dun xestor de vendas ao que só se lle debería permitir ver descontos de prezos ou datos de custos base que se atopan na mesma táboa onde outro profesional de vendas necesita ver o produto e o prezo.

Non obstante, é posible que non todos os datos teñan que estar protexidos do mesmo xeito. Unha aplicación é compartida e despregada a usuarios específicos ou grupos de usuarios. As persoas alleas a ese grupo non teñen acceso á aplicación nin á conexión. Polo tanto, se todos os membros dun grupo están autorizados a ver todos os datos dunha base de datos, un método implícito de compartir funciona ben.

Para obter un exemplo de caso de uso de conexión implícita, considere o caso dun departamento que teña unha base de datos de proxectos pequena que están a seguir. A base de datos pode incluír información como tíckets de traballo de departamentos ou calendarios corporativos para toda a empresa. Neste escenario, pode fomentarse a creación de máis aplicacións encima da conexión compartida de xeito implícito sempre que todos os usuarios aos que se lles conceda acceso teñan acceso aos datos.

As aplicacións creadas con Power Apps están deseñadas para que os usuarios finais poidan acceder a elas. Este tipo de escenario é común porque o custo de desenvolvemento asociado ás conexións implícitas é baixo.

As aplicacións baseadas nos departamentos poden converterse en aplicacións esenciais para toda a empresa e para unha misión. Nestes escenarios, é importante comprender que a medida que unha aplicación dun departamento pasa a ser para toda unha empresa, necesitará incorporar a seguridade empresarial tradicional. Este enfoque é máis caro para a creación de aplicacións, pero é importante en escenarios para toda a empresa.

Seguridade do cliente e do servidor

Non pode confiar na seguridade dos datos mediante filtros ou outras operacións do lado do cliente para estar seguro. As aplicacións que requiren un filtrado seguro de datos deben garantir que a identificación e a filtraxe do usuario se produzan no servidor.

Use servizos como Azure Active Directory no canto de confiar nos filtros deseñados dentro das aplicacións cando se trata da identidade e seguridade do usuario. Esta configuración garante que os filtros do servidor funcionen como se esperaba.

As seguintes ilustracións explican como os padróns de seguridade das aplicacións varían entre os modelos de seguridade do lado do cliente e do servidor.

Nun padrón de aplicación de seguridade do cliente, [1] o usuario só se autentica na aplicación do lado do cliente. Entón [2] a aplicación solicita información do servizo e [3] o servizo devolve a información baseada exclusivamente na solicitude de datos.

Nun padrón de seguridade do servidor, [1] o usuario autentícase primeiro no servizo polo que o usuario é coñecido polo servizo. Entón, [2] cando se fai unha chamada desde a aplicación, o servizo [3] usa a identidade coñecida do usuario actual para filtrar os datos adecuadamente e [4] devolve os datos.

Os escenarios de uso compartido de departamentos implícitos descritos anteriormente son a combinación destes dous padróns. O usuario debe iniciar sesión no servizo Power App usando credenciais de Azure AD. Este comportamento é o padrón de aplicación de seguridade do servidor. O usuario é coñecido usando a identidade de Azure AD no servizo. Polo tanto, a aplicación está restrinxida ao conxunto de usuarios cos que Power Apps compartiu formalmente a aplicación.

Non obstante, a conexión compartida implícita con SQL Server é o padrón de aplicación de seguridade do cliente. SQL Server só sabe que se emprega un nome de usuario e un contrasinal específicos. Calquera filtraxe do lado do cliente, por exemplo, pode ignorarse cunha nova aplicación usando o mesmo nome de usuario e contrasinal.

Para filtrar datos de forma segura no lado do servidor, use funcións de seguridade integradas en SQL Server como seguridade a nivel de fila para as filas e denegar permisos a obxectos específicos (como columnas) a usuarios específicos. Este enfoque empregará a identidade de usuario de Azure AD para filtrar os datos no servidor.

Algúns servizos corporativos existentes empregaron un enfoque onde a identidade do usuario é capturada nunha capa de datos empresariais do mesmo xeito que Microsoft Dataverse. Neste caso, a capa empresarial pode usar ou non a seguridade a nivel de fila de SQL Server e denegar as funcións directamente. Se non o fai, normalmente adoita activarse a seguridade mediante procedementos ou vistas almacenados.

A capa empresarial (no lado do servidor) usa unha identidade de Azure AD de usuario coñecida para invocar un procedemento almacenado como principal de SQL Server e filtrar os datos. Non obstante, Power Apps actualmente non se conecta aos procedementos almacenados. Unha capa empresarial tamén pode invocar unha vista que usa a identidade de Azure AD como principal de SQL Server. Neste caso, use Power Apps para conectarse ás vistas para que os datos se filtren no lado do servidor. É posible que para expoñer só visualizacións para usuarios precise fluxos de Power Automate para actualizacións.

Consulte tamén

Visión xeral de conectores para aplicacións de lenzo