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

Aquest article també s'aplica a altres bases de dades relacionals, com ara l'Oracle.

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

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 en segon pla com a part de l'encaixada de l'autenticació del Windows o del Azure Active Directory. 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ó.

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
Azure AD integrada FTPS explícit
Autenticació del servidor de l'SQL Implícit
Autenticació del Windows Implícit
Autenticació del Windows (no compartida) Explícit

Riscs per compartir connexions implícites

Des que s'implementen tant l'aplicació com les seves connexions als usuaris finals, significa que els usuaris finals poden crear noves aplicacions a partir d'aquestes connexions.

Per exemple, imagineu que heu creat una aplicació que ha filtrat les dades que no voleu que els usuaris vegin. 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.

Un cop implementada aquesta aplicació, els usuaris finals poden utilitzar la connexió implementada amb l'aplicació a les aplicacions noves que creïn. A les aplicacions noves, els usuaris poden veure les dades que heu filtrat a l'aplicació.

Important

Quan s'implementa una connexió compartida implícitament als usuaris finals, les restriccions que heu establert a l'aplicació que heu compartit (com ara filtres o accés només de lectura) ja no són vàlides per als usuaris finals de les noves aplicacions creades. Els usuaris finals tindran els drets que l'autenticació permeti com a part d'una connexió compartida implícita.

Usos reals de la connexió implícita

Hi ha casos d'ús vàlids per als mètodes d'autenticació implícita i explícita. Penseu en el model de seguretat i la facilitat de desenvolupament a l'hora de triar el vostre mètode. Com a regla general, utilitzeu un mètode d'autenticació explícita per a qualsevol situació en què hàgiu de necessitar un requisit empresarial on s'han de restringir les dades de manera explícita a una fila o a una columna.

Per a un exemple d'un cas d'ús explícit de la connexió, considereu un cap de vendes que només pot veure descomptes de preu o dades de cost base que es troben a la mateixa taula on un altre professional de vendes ha de veure el producte i el preu.

Tanmateix, potser no totes les dades s'han d'assegurar de la mateixa manera. Una aplicació es comparteix i s'implementa a usuaris o grups d'usuaris específics. Les persones de de fora d'aquest grup no tenen accés a l'aplicació ni a la connexió. Per tant, si tots els usuaris d'un grup estan autoritzats a veure totes les dades d'una base de dades, funciona bé un mètode implícit de compartir.

Un exemple d'un cas d'ús implícit de connexió seria un departament que té una petita base de dades de projectes que fan el seguiment. La base de dades pot incloure informació com ara l'activitat departamental de l'empresa o el calendari corporatiu de tota l'empresa. En aquest escenari, es pot animar la creació de més aplicacions a sobre de la connexió compartida implícita sempre que tots els usuaris amb accés tinguin accés a totes les dades.

Les aplicacions creades amb el Power Apps s'han dissenyat amb l'objectiu que siguin accessibles pels usuaris finals. Aquest tipus d'escenari és comú perquè el cost de desenvolupament associat amb connexions implícits és baix.

Les aplicacions basades en departaments poden anar creixent en aplicacions fonamentals de tota l'empresa i de missions. En aquests escenaris, és important comprendre que quan una aplicació departamental es desplaça per a tot l'empresa, haurà de tenir la seguretat empresarial tradicional integrada. Aquest mètode és més car per a la creació d'aplicacions, però és important en escenaris empresarials de tot el món.

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 ara el Azure Active Directory en comptes de confiar en els filtres dissenyats dins de les aplicacions quan es tracta de 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.

Patró de seguretat del client en una aplicació

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.

Patró de seguretat del servidor en una aplicació

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 servei del Power App utilitzant les credencials de l'Azure AD. Aquest comportament és el patró de l'aplicació de seguretat del servidor. L'usuari es coneix amb la identitat del servei de l'Azure AD. 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 mètode utilitzarà la identitat d'usuari de l'Azure AD per filtrar les dades del 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 servidor) utilitza una identitat d'usuari coneguda de l'Azure AD per invocar un procediment emmagatzemat com a principal de l'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 utilitzi la identitat de l'Azure AD com a principal de l'SQL 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ç