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
A función conexións implícitas seguras lanzouse en xaneiro de 2024. Microsoft recomenda encarecidamente que todas as aplicacións que utilicen actualmente conexións implícitas se convertan en conexións implícitas seguras e que revoguen as conexións compartidas cos usuarios finais.
Diferenza entre conexións implícitas explícitas, implícitas e seguras
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 Microsoft Entra ou a 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.
- Unha conexión compartida de forma implícita segura refírese a un escenario no que o usuario final da aplicación utiliza implicitamente as credenciais da conta que o creador da aplicación usou para conectarse e autenticarse no orixe de datos ao crear a aplicación. Isto significa que as propias credenciais do usuario final non se utilizan para autenticarse. Pola contra, cando o usuario executa a aplicación, está a usar as credenciais coas que a creou o autor da aplicación. É importante ter en conta que o usuario final non ten acceso directo á conexión e a aplicación só permite o acceso a un conxunto limitado de accións e táboas.
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 |
|---|---|
| Microsoft Entra Integrado | Explícito |
| Autenticación de SQL Server | Implícito / Seguro Implícito |
| Autenticación de Windows | Implícito / Seguro Implícito |
| Autenticación de Windows (non compartida) | Explícito |
Riscos implícitos para compartir conexións
Todas as novas aplicacións usan automaticamente as novas conexións implícitas seguras. Non obstante, coas aplicacións que usan as "conexións implícitas" máis antigas, tanto a aplicación como as súas conexións despréganse aos usuarios finais, isto significa que os usuarios finais poden crear novas aplicacións en función desas conexións.
Cando un autor utiliza conexións implícitas seguras, significa que non se comparte ningunha conexión e que ningún usuario final recibe o obxecto de conexión. Isto elimina o risco de que un autor do usuario final reutilice unha conexión para crear unha aplicación nova. Pola contra, a aplicación funciona cunha conexión proxy que coñece a aplicación e só se comunica con esa aplicación específica. A conexión proxy permite accións limitadas (crear, ler, actualizar, eliminar) e acceder a táboas específicas da aplicación que se definen cando se publica a aplicación. Polo tanto, só se conceden accións e acceso autorizados ao usuario final.
A conexión implícita simple de estilo máis antigo realmente distribúe un obxecto de conexión ao usuario final. Por exemplo, se creas unha aplicación que filtra os datos que non queres que vexan os usuarios. Pero, 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.
De novo, con conexións implícitas simples de estilo máis antigo, despois de implementar a aplicación, os usuarios finais poden usar a conexión implantada coa tú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 utilizar as novas conexións implícitas seguras.
Importante
Unha vez que se implementa unha conexión compartida implícitamente máis antiga para os usuarios finais, as restricións que puidese poñer na aplicación que compartiches (como os filtros ou o 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. Polo tanto, cando convertes unha aplicación para que utilice conexións implícitas seguras, debes tamén revogar as conexións que compartiches coa túa aplicación. Os administradores poden obter un informe de aplicacións con conexións compartidas implicitamente co kit de ferramentas COE.
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.
Usa servizos como Microsoft Entra ID en lugar de confiar nos filtros deseñados nas aplicacións cando se trata de 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 Power Apps servizo utilizando Microsoft Entra credenciais. Este comportamento é o padrón de aplicación de seguridade do servidor. Coñécese ao usuario mediante a Microsoft Entra identidade do 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 utiliza a Microsoft Entra identidade de usuario 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 empresa capa (no lado do servidor) usa unha identidade de usuario coñecida Microsoft Entra 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 empresa capa tamén pode invocar unha vista que utiliza a Microsoft Entra identidade 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.