Varna uporaba strežnika Microsoft SQL Server z orodjem Power Apps

Obstajajo različni načini za povezavo in preverjanje pristnosti v strežniku SQL z aplikacijo Power Apps. V tem članku so opisani koncepti, ki so lahko v pomoč pri izbiri, kako vzpostaviti povezavo s strežnikom SQL Server z varnostnim pristopom, ki ustreza zahtevam za vašo aplikacijo.

Pomembno

Funkcija varne implicitne povezave je bila izdana januarja 2024. Microsoft močno spodbuja vse aplikacije, ki trenutno uporabljajo implicitne povezave, da pretvorijo v varne implicitne povezave in prekličejo povezave, ki so v skupni rabi s končnimi uporabniki.

Razlika med eksplicitnimi, implicitnimi in varnimi implicitnimi povezavami

Povezava s strežnikom SQL Server se ustvari vsakič, ko ustvarite aplikacijo z uporabo Power Apps za povezavo s strežnikom SQL. Ko so take aplikacije objavljene in dane v skupno rabo z drugimi, se aplikacija in povezava uvedeta za te uporabnike. Z drugimi besedami sta tako aplikacija kot povezava vidni uporabnikom, s katerimi so aplikacije v skupni rabi.

Način preverjanja pristnosti, ki se uporablja za take povezave, je lahko ekspliciten ali impliciten. Lahko rečemo tudi, da je taka povezava dana v skupno rabo eksplicitno ali implicitno.

• Povezava v eksplicitni skupni rabi pomeni, da mora končni uporabnik aplikacije potrditi pristnost v strežniku SQL Server s svojimi eksplicitnimi poverilnicami. Običajno se to preverjanje pristnosti zgodi v zakulisju kot del rokovanja Microsoft Entra ali Windows preverjanja pristnosti. Uporabnik niti ne opazi, kdaj poteka preverjanje pristnosti.
• Povezava v implicitni skupni rabi pomeni, da uporabnik implicitno uporablja poverilnice računa, ki ga je ustvarjalec aplikacije uporabljal za povezavo in preverjanje pristnosti z virom podatkov med ustvarjanjem aplikacije. Poverilnice končnega uporabnika niso uporabljene za preverjanje pristnosti. Vsakič, ko končni uporabnik zažene aplikacijo, uporabi poverilnice, s katerimi je avtor ustvaril aplikacijo.
• Varna povezava v implicitni skupni rabi se nanaša na scenarij, kjer končni uporabnik aplikacije implicitno uporablja poverilnice računa, ki ga je izdelovalec aplikacije uporabil za povezavo in preverjanje pristnosti na vir podatkov med ustvarjanjem aplikacije. To pomeni, da se lastne poverilnice končnega uporabnika ne uporabljajo za preverjanje pristnosti. Namesto tega, ko uporabnik zažene aplikacijo, uporablja poverilnice, s katerimi jo je ustvaril avtor aplikacije. Pomembno je omeniti, da končnemu uporabniku ni omogočen neposreden dostop do povezave in da aplikacija omogoča dostop le do omejenega nabora dejanj in tabel.

Naslednje štiri vrste preverjanja pristnosti povezave je mogoče uporabiti s strežnikom SQL Server za Power Apps:

Vrsta preverjanja pristnosti	Način povezave Power Apps
Microsoft Entra Integrirano	Eksplicitno
Preverjanje pristnosti strežnika SQL Server	Implicitno / Varno implicitno
Preverjanje pristnosti sistema Windows	Implicitno / Varno implicitno
Preverjanje pristnosti sistema Windows (brez skupne rabe)	Eksplicitno

Tveganja, povezana z implicitno skupno rabo povezave

Vse nove aplikacije samodejno uporabljajo nove varne implicitne povezave. Vendar pa so pri aplikacijah, ki uporabljajo starejše 'implicitne povezave', aplikacija in njene povezave razporejene končnim uporabnikom, kar pomeni, da končni uporabniki lahko ustvarjajo nove aplikacije na podlagi teh povezav.

Ko avtor uporablja varne implicitne povezave, to pomeni, da nobena povezava ni v skupni rabi in noben končni uporabnik ne prejme objekta povezave. To odpravi tveganje, da bi avtor končnega uporabnika znova uporabil povezavo za ustvarjanje nove aplikacije. Namesto tega aplikacija deluje s povezavo proxy, ki pozna aplikacijo in komunicira samo s to določeno aplikacijo. Povezava proxy omogoča omejena dejanja (ustvarjanje, branje, posodobitev, brisanje) in dostop do določenih tabel v aplikaciji, ki so definirane ob objavi aplikacije. Zato so končnemu uporabniku omogočena samo pooblaščena dejanja in dostop.

Preprosta implicitna povezava v starejšem slogu dejansko razdeli objekt povezave končnemu uporabniku. Na primer, če ustvarite aplikacijo, ki filtrira podatke, za katere ne želite, da jih vidijo uporabniki. Toda filtrirani podatki so prisotni v bazi podatkov. Vendar se zanašate na filter, ki ste ga konfigurirali, da zagotovite, da končni uporabniki ne bodo videli določenih podatkov.

Spet pri starejših preprostih implicitnih povezavah lahko končni uporabniki po uvedbi aplikacije uporabljajo povezavo, uvedeno z vašo aplikacijo, v vseh novih aplikacijah, ki jih ustvarijo. V novih aplikacijah lahko uporabniki vidijo podatke, ki ste jih filtrirali v svoji aplikaciji. Pomembno je, da uporabljate nove varne implicitne povezave.

Pomembno

Ko je starejša povezava v implicitni skupni rabi uvedena za končne uporabnike, omejitve, ki ste jih morda postavili v aplikacijo, ki ste jo dali v skupno rabo (kot so filtri ali dostop samo za branje), niso več veljavne za nove aplikacije, ki jih ustvarijo končni uporabniki. Končni uporabniki bodo imeli vse pravice, ki jih preverjanje pristnosti dovoli kot del implicitne povezave v skupni rabi. Zato morate, ko pretvorite aplikacijo za uporabo varnih implicitnih povezav, prav tako preklicati povezave, ki ste jih delili z aplikacijo. Skrbniki lahko dobijo poročilo o aplikacijah z implicitno skupnimi povezavami s kompletom orodij COE.

Varnost odjemalca in strežnika

Na varnost podatkov s filtriranjem ali drugimi operacijami na strani odjemalca se ne morete zanesti. Aplikacije, ki zahtevajo varno filtriranje podatkov, morajo zagotoviti, da se identifikacija uporabnika in filtriranje izvajata na strežniku.

Uporabite storitve, kot je Microsoft Entra ID, namesto da se zanašate na filtre, zasnovane v aplikacijah, ko gre za identiteto in varnost uporabnika. Ta konfiguracija zagotavlja, da filtri na strani strežnika delujejo po pričakovanjih.

Naslednje slike pojasnjujejo, kako se varnostni vzorci v aplikacijah razlikujejo med odjemalskimi in strežniškimi varnostnimi modeli.

V varnostnem vzorcu aplikacije odjemalca [1] uporabnik preverja pristnost aplikacije samo na odjemalski strani. Potem [2] aplikacija zahteva informacije o storitvi in [3] storitev vrne informacije izključno na podlagi zahteve za podatke.

V varnostnem vzorcu na strani strežnika [1] uporabnik najprej opravi preverjanje pristnosti v storitvi, tako da je uporabnik storitev znan. Ko nato [2] pokličete iz aplikacije, storitev [3] uporabi znano identiteto trenutnega uporabnika za ustrezno filtriranje podatkov in [4] vrne podatke.

Zgoraj opisani implicitni scenariji deljene skupne rabe so kombinacija teh dveh vzorcev. Uporabnik se mora prijaviti v Power Apps storitev s Microsoft Entra poverilnicami. To vedenje je vzorec varnostne aplikacije strežnika. Uporabnik je znan po Microsoft Entra identiteti v storitvi. Zato je aplikacija omejena na nabor uporabnikov, s katerimi je storitev Power Apps uradno delila aplikacijo.

Vendar je implicitna skupna povezava s strežnikom SQL Server vzorec varnostne aplikacije odjemalca. Strežnik SQL Server ve samo, da se uporablja določeno uporabniško ime in geslo. Vsako filtriranje na strani odjemalca, je na primer mogoče obiti z novo aplikacijo z istim uporabniškim imenom in geslom.

Za varno filtriranje podatkov na strani strežnika uporabite vgrajene varnostne funkcije v strežniku SQL Server, kot jevarnost na ravni vrstice za vrstice in dovoljenja za neodobritev za določene predmete (na primer stolpce) za določene uporabnike. Ta pristop uporablja Microsoft Entra identiteto uporabnika za filtriranje podatkov na strežniku.

Nekatere obstoječe podjetniške storitve uporabljajo pristop, pri katerem je uporabniška identiteta zajeta v poslovno podatkovno plast, podobno okolju Microsoft Dataverse. V tem primeru lahko poslovna plast uporablja ali ne uporablja varnosti strežnika SQL Server na ravni vrstice in neposredno zavrne funkcije. V nasprotnem primeru se pogosto zgodi, da je zaščita omogočena s shranjenimi postopki ali pogledi.

Podjetje sloj (na strani strežnika) uporablja znano uporabniško Microsoft Entra identiteto, da prikliče shranjeno proceduro kot principala SQL Server in filtrira podatke. Vendar se Power Apps trenutno ne poveže s shranjenimi procedurami. Poslovni sloj lahko prikliče tudi pogled, ki uporablja Microsoft Entra identiteto kot principala SQL Server. V tem primeru uporabite Power Apps za povezavo s pogledi, tako da se podatki filtrirajo na strani strežnika. Z izpostavljanjem pogledov uporabnikom bodo morda potrebni tokovi Power Automate za posodobitve.

Glejte tudi

Pregled povezovalnikov za aplikacije s platnom