Utilitzar el Microsoft SQL Server de manera segura amb el Power Apps

Hi ha diverses maneres de connectar i autenticar-se a l'SQL Server amb el Power Apps. En aquest article es definiu els conceptes que poden ser útils per triar com podeu connectar-vos a l'SQL Server amb un mètode de seguretat que coincideixi amb els requisits de l'aplicació.

Important

La funció de connexions implícites segures es va llançar el gener del 2024. Microsoft recomana encaridament a totes les aplicacions que actualment utilitzen connexions implícites que es converteixin en connexions implícites segures i que revoquin les connexions compartides amb els usuaris finals.

Diferència entre connexions implícites explícites, implícites i segures

Es crea una connexió a l'SQL Server sempre que creeu una aplicació amb el Power Apps connectant-se a l'SQL Server. Quan aquestes aplicacions es publiquen i es comparteixen amb altres usuaris, tant l'aplicació com la connexió s'implementen a aquests usuaris. En altres paraules, l'aplicació i la connexió (ambdues) son visibles per als usuaris amb les aplicacions compartides.

El mètode d'autenticació utilitzat per a aquestes connexions pot ser explícit o implícit. També podem dir que aquesta connexió es comparteix de manera explícita o implícita.

• Una connexió compartida explícitament significa que l'usuari final de l'aplicació ha d'autenticar-se a l'SQL Server amb les seves pròpies credencials explícites. Normalment, aquesta autenticació es produeix entre bastidors com a part de l'encaixada de mans o l'autenticació de Microsoft Entra Windows. L'usuari encara no s'adona quan es produeix l'autenticació.
• Una connexió implícitament compartida significa que l'usuari utilitza implícitament les credencials del compte que utilitza el creador de l'aplicació per connectar i autenticar-se a la font de dades durant la creació de l'aplicació. Les credencials de l'usuari final no s'utilitzen per a l'autenticació. Cada vegada que l'usuari final executa l'aplicació, utilitza les credencials amb les que l'autor ha creat l'aplicació.
• Una connexió compartida implícitament segura fa referència a un escenari en què l'usuari final de l'aplicació utilitza implícitament les credencials del compte que el creador de l'aplicació ha utilitzat per connectar-se i autenticar-se al font de dades durant la creació de l'aplicació. Això significa que les credencials pròpies de l'usuari final no s'utilitzen per autenticar-se. En canvi, quan l'usuari executa l'aplicació, utilitza les credencials amb què l'autor de l'aplicació l'ha creat. És important tenir en compte que a l'usuari final no se li proporciona accés directe a la connexió i l'aplicació només permet accedir a un conjunt limitat d'accions i taules.

Els quatre tipus d'autenticació de connexió següents es poden utilitzar amb l'SQL Server per al Power Apps:

Tipus d’autenticació	Mode de connexió del Power Apps
Microsoft Entra Integrat	FTPS explícit
Autenticació del servidor de l'SQL	Implícit / Segur Implícit
Autenticació del Windows	Implícit / Segur Implícit
Autenticació del Windows (no compartida)	FTPS explícit

Riscs per compartir connexions implícites

Totes les noves aplicacions utilitzen automàticament les noves connexions implícites segures. Tanmateix, amb les aplicacions que utilitzen les "connexions implícites" antigues, tant l'aplicació com les seves connexions s'implementen als usuaris finals, significa que els usuaris finals poden crear noves aplicacions basades en aquestes connexions.

Quan un autor utilitza connexions implícites segures, significa que no es comparteix cap connexió i cap usuari final rep l'objecte de connexió. Això elimina el risc que un autor d'usuari final reutilitzi una connexió per crear una aplicació nova. En canvi, l'aplicació funciona amb una connexió de servidor intermediari que és conscient de l'aplicació i només es comunica amb aquesta aplicació específica. La connexió del servidor intermediari permet accions limitades (crear, llegir, actualitzar, suprimir) i accés a taules específiques de l'aplicació que es defineixen quan es publica l'aplicació. Per tant, només es concedeixen accions autoritzades i accés a l'usuari final.

L'estil més antic, la connexió implícita simple en realitat distribueix un objecte de connexió a l'usuari final. Per exemple, si creeu una aplicació que filtri les dades que no voleu que vegin els usuaris. Però, les dades filtrades estan presents a la base de dades. Però utilitzeu el filtre que heu configurat per assegurar-vos que els usuaris finals no veuran algunes dades.

De nou, amb connexions implícites simples d'estil antic, després d'implementar l'aplicació, els usuaris finals poden utilitzar la connexió desplegada amb l'aplicació en qualsevol aplicació nova que creïn. A les aplicacions noves, els usuaris poden veure les dades que heu filtrat a l'aplicació. És important utilitzar les noves connexions implícites segures.

Important

Quan s'implementa una connexió compartida implícitament antiga als usuaris finals, les restriccions que hagis posat a l'aplicació que has compartit (com ara filtres o accés només de lectura) ja no són vàlides per a les aplicacions noves que creïn els usuaris finals. Els usuaris finals tindran els drets que l'autenticació permeti com a part d'una connexió compartida implícita. Per tant, quan convertiu una aplicació per utilitzar connexions implícites segures, també heu de revocar les connexions que heu compartit amb l'aplicació. Els administradors poden obtenir un informe d'aplicacions amb connexions compartides implícitament amb el conjunt d'eines COE.

Seguretat del client i del servidor

No podeu utilitzar la seguretat de les dades mitjançant el filtratge i altres operacions del client per protegir-les. Les aplicacions que requereixen un filtratge segur de dades han de garantir que es produeixi la identificació i el filtratge de l'usuari al servidor.

Utilitzeu serveis com Microsoft Entra ara ID en lloc de confiar en els filtres dissenyats dins de les aplicacions pel que fa a la identitat i la seguretat de l'usuari. Aquesta configuració garanteix que els filtres del servidor funcionin tal com està previst.

A les il·lustracions següents s'explica com els patrons de seguretat de les aplicacions son diferents entre els models de seguretat del client i del servidor.

En un patró de seguretat de l'aplicació client, [1] l'usuari només s'autentica a l'aplicació al client. Després, [2]l'aplicació sol·licita informació del servei i el servei [3] torna la informació únicament basada en la sol·licitud de dades.

En un patró de seguretat del servidor, [1] l'usuari s'autentica primer al servei per tal que el servei conegui l'usuari. Després, [2] quan es fa una trucada des de l'aplicació, el servei [3] utilitza la identitat coneguda de l'usuari actual per filtrar les dades correctament i [4] retorna les dades.

Els escenaris implícits de l'ús compartit departamental descrits anteriorment és la combinació d'aquests dos patrons. L'usuari ha d'iniciar sessió al Power Apps servei mitjançant Microsoft Entra credencials. Aquest comportament és el patró de l'aplicació de seguretat del servidor. L'usuari és conegut mitjançant la Microsoft Entra identitat del servei. Per tant, l'aplicació està restringida al conjunt d'usuaris als quals el Power Apps ha compartit formalment l'aplicació.

Tanmateix, la connexió compartida implícita a l'SQL Server és el patró de l'aplicació de seguretat del client. L'SQL Server només sap que s'utilitza un nom d'usuari i una contrasenya específics. Per exemple, qualsevol filtratge del client es pot ometre amb una aplicació nova utilitzant el mateix nom d'usuari i la mateixa contrasenya.

Per filtrar de manera segura les dades del servidor, utilitzeu les característiques de seguretat incorporades a l'SQL Server, com ara la seguretat del nivell de fila de les files i els permisos que es deneguen a objectes específics (com ara columnes) a usuaris específics. Aquest enfocament utilitza la Microsoft Entra identitat d'usuari per filtrar les dades al servidor.

Alguns serveis corporatius existents han utilitzat una manera de capturar la identitat d'usuari en una capa de dades empresarials de la mateixa manera que ho fa el Microsoft Dataverse. En aquest cas, la capa de negoci pot o no utilitzar la seguretat del nivell de fila de l'SQL Server i denegar les característiques directament. Si no ho fa, sovint és el cas que la seguretat s'habilita mitjançant procediments o visualitzacions emmagatzemades.

La capa de negoci (al costat del servidor) utilitza una identitat d'usuari coneguda per invocar un procediment emmagatzemat com a principal de l'SQL Microsoft Entra Server i filtrar les dades. Tanmateix, el Power Apps no es connecta actualment als procediments emmagatzemats. Una capa de negoci també pot invocar una visualització que utilitza la identitat com a principal de l'SQL Microsoft Entra Server. En aquest cas, utilitzeu el Power Apps per connectar-vos a les visualitzacions per tal que les dades es filtrin al servidor. En exposar només visualitzacions als usuaris, pot ser que es necessitin fluxos del Power Automate per a les actualitzacions.

Consulteu també

Informació general de connectors per a les aplicacions de llenç