Nota
L'accés a aquesta pàgina requereix autorització. Pots provar d'iniciar sessió o canviar de directori.
L'accés a aquesta pàgina requereix autorització. Pots provar de canviar directoris.
Hi ha diferents maneres de connectar-se i autenticar-se a l'SQL Server amb el Power Apps. En aquest article es descriuen conceptes que poden ser útils per triar com connectar-se a l'SQL Server amb un enfocament de seguretat que coincideixi amb els requisits de l'aplicació.
Important
La funció de connexions implícites segures es va llançar el gener de 2024. Microsoft recomana que totes les aplicacions que actualment utilitzen connexions implícites es converteixin en connexions implícites segures i revoquin les connexions compartides amb els usuaris finals.
Diferència entre connexions explícites, implícites i segures
Es crea una connexió a l'SQL Server cada vegada que creeu una aplicació amb el Power Apps que es connecta a l'SQL Server. Quan aquestes aplicacions es publiquen i es comparteixen amb altres persones, tant l'aplicació com la connexió s'implementen a aquests usuaris. En altres paraules, l'aplicació i la connexió, tots dos són visibles per als usuaris amb els quals es comparteixen les aplicacions.
El mètode d'autenticació utilitzat per a aquestes connexions pot ser explícit o implícit. També podem dir que aquesta connexió és compartida explícitament o implícitament.
- Una connexió compartida explícitament significa que l'usuari final de l'aplicació s'ha d'autenticar 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 d'autenticació de Microsoft Entra o Windows. L'usuari ni tan sols s'adona quan es produeix l'autenticació.
- Una connexió compartida implícitament significa que l'usuari utilitza implícitament les credencials del compte que el fabricant de l'aplicació va utilitzar per connectar-se i autenticar-se a la font de dades durant la creació de l'aplicació. Les credencials de l'usuari final no s'utilitzen per autenticar-se. Cada vegada que l'usuari final executa l'aplicació, utilitza les credencials amb què l'autor ha creat l'aplicació.
- Una connexió compartida implícita segura fa referència a un escenari en què l'usuari final de l'aplicació utilitza implícitament les credencials del compte que el fabricant de l'aplicació va utilitzar per connectar-se i autenticar-se a la font de dades mentre creava l'aplicació. Això vol dir que les credencials de l'usuari final no s'utilitzen per autenticar-se. En canvi, quan l'usuari executa l'aplicació, utilitza les credencials amb les quals l'autor de l'aplicació l'ha creada. És important tenir en compte que l'usuari final no té accés directe a la connexió i que 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ó | Mètode de connexió del Power Apps |
|---|---|
| Microsoft Entra integrat | Explícit |
| Autenticació de l'SQL Server | Implícit / Segur Implícit |
| Autenticació del Windows | Implícit / Segur Implícit |
| Autenticació del Windows (no compartida) | Explícit |
Riscos de compartició de connexions implícites
Totes les aplicacions noves utilitzen automàticament les noves connexions implícites segures. Tanmateix, amb les aplicacions que utilitzen les "connexions implícites" més antigues, tant l'aplicació com les seves connexions es despleguen als usuaris finals, vol dir que els usuaris finals poden crear noves aplicacions basades en aquestes connexions.
Quan un autor utilitza connexions implícites segures, vol dir 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ó proxy que coneix l'aplicació i només es comunica amb aquesta aplicació específica. La connexió proxy permet accions limitades (crear, llegir, actualitzar, suprimir) i accedir 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.
La connexió implícita simple d'estil anterior distribueix un objecte de connexió a l'usuari final. Per exemple, si creeu una aplicació que filtra les dades que no voleu que vegin els usuaris. Però les dades filtrades estan presents a la base de dades. Però confieu en el filtre que heu configurat per assegurar-vos que els usuaris finals no vegin determinades dades.
De nou, amb les connexions implícites simples d'estil antic, després d'implementar l'aplicació, els usuaris finals poden utilitzar la connexió implementada 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
Un cop implementada una connexió compartida implícitament antiga als usuaris finals, les restriccions que podeu haver posat a l'aplicació que heu compartit (com ara filtres o accés només de lectura) ja no són vàlides per a les aplicacions noves que creen els usuaris finals. Els usuaris finals tindran els drets que l'autenticació permeti com a part de la connexió compartida implícitament. 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 de clients i servidors
No podeu confiar en la seguretat de les dades mitjançant filtratge o altres operacions del costat del client per estar segur. Les aplicacions que requereixen un filtratge segur de dades han de garantir que tant la identificació com el filtratge de l'usuari es produeixin al servidor.
Utilitzeu serveis com Microsoft Entra 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 com s'esperava.
Les il·lustracions següents expliquen en què els patrons de seguretat de les aplicacions difereixen entre els models de seguretat del client i del servidor.
En un patró d'aplicació de seguretat del client, [1] l'usuari només s'autentica a l'aplicació al costat del client. A continuació, [2] l'aplicació sol·licita informació del servei i [3] el servei retorna la informació únicament en funció de la sol·licitud de dades.
En un patró de seguretat del servidor, [1] l'usuari s'autentica primer al servei perquè l'usuari sigui conegut pel servei. Aleshores, [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 adequadament i [4] retorna les dades.
Els escenaris de compartició departamental implícita descrits anteriorment són la combinació d'aquests dos patrons. L'usuari ha d'iniciar la sessió al servei del Power Apps amb les credencials del Microsoft Entra. Aquest comportament és el patró de l'aplicació de seguretat del servidor. L'usuari és conegut mitjançant la identitat del Microsoft Entra al servei. Per tant, l'aplicació està restringida al conjunt d'usuaris amb els 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. Qualsevol filtratge del client, per exemple, es pot evitar amb una nova aplicació que utilitzi el mateix nom d'usuari i contrasenya.
Per filtrar de manera segura les dades del servidor, utilitzeu les característiques de seguretat integrades de l'SQL Server, com ara la seguretat a nivell de fila per a les files i la denegació de permisos a objectes específics (com ara columnes) a usuaris específics. Aquest enfocament utilitza la identitat d'usuari del Microsoft Entra per filtrar les dades del servidor.
Alguns serveis corporatius existents han utilitzat un enfocament en què la identitat de l'usuari es captura en una capa de dades empresarials de la mateixa manera que ho fa Microsoft Dataverse. En aquest cas, la capa de negoci pot utilitzar o no la seguretat a nivell de fila de l'SQL Server i denegar les característiques directament. Si no és així, sovint es dóna el cas que la seguretat s'habilita mitjançant procediments emmagatzemats o visualitzacions.
La capa de negoci (al costat del servidor) utilitza una identitat coneguda del Microsoft Entra per invocar un procediment emmagatzemat com a principal de SQL 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 del Microsoft Entra com a entitat principal de l'SQL Server. En aquest cas, utilitzeu el Power Apps per connectar-vos a les visualitzacions de manera que les dades es filtrin al servidor. L'exposició només de visualitzacions als usuaris pot necessitar fluxos del Power Automate per a les actualitzacions.