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

Ta članek velja za vse relacijske baze podatkov in implicitne povezave.

Razlika med eksplicitnimi in 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 ozadju aplikacije Azure Active Directory ali pri rokovanju za preverjanje pristnosti sistema Windows. 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.

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
Integrirano preverjanje pristnosti Azure AD	Eksplicitno
Preverjanje pristnosti strežnika SQL Server	Implicitno
Preverjanje pristnosti sistema Windows	Implicitno
Preverjanje pristnosti sistema Windows (ni v skupni rabi)	Eksplicitno

Tveganja, povezana z implicitno skupno rabo povezave

Ker sta aplikacija in njene povezave uvedene za končne uporabnike, to pomeni, da lahko končni uporabniki na podlagi teh povezav ustvarjajo nove aplikacije.

Če ste na primer ustvarili aplikacijo, ki je filtrirala podatke, za katere ne želite, da jih uporabniki vidijo. Filtrirani podatki so prisotni v zbirki podatkov. Vendar se zanašate na filter, ki ste ga konfigurirali, da zagotovite, da končni uporabniki ne bodo videli določenih podatkov.

Ko uvedete to aplikacijo, lahko končni uporabniki uporabijo 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

Ko je implicitna povezava v skupni rabi uvedena končnim uporabnikom, omejitve, ki ste jih morda določili v aplikaciji, ki ste jo dali v skupno rabo (na primer filtri ali dostop samo za branje), ne bodo več veljale 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.

Dejanska uporaba implicitnih povezav

Obstajajo veljavni primeri uporabe za implicitne in eksplicitne načine preverjanja pristnosti. Pri izbiri pristopa upoštevajte varnostni model in enostavnost razvoja. Praviloma uporabite izrecno metodo preverjanja pristnosti za vse primere, ko imate poslovno zahtevo, pri kateri morajo biti podatki omejeni na podlagi vrstic ali stolpcev.

Primer eksplicitne povezave je na primer prodajni vodja, ki bi smel videti samo popuste na ceno ali osnovne podatke o stroških, ki so v isti tabeli, kjer mora drug prodajni strokovnjak videti izdelek in ceno.

Vseh podatkov morda ni treba zaščititi na enak način. Aplikacija je v skupni rabi in razmeščena za določene uporabnike ali skupine uporabnikov. Osebe zunaj te skupine nimajo dostopa do aplikacije ali povezave. Če je torej vsem v skupini dovoljeno videti vse podatke v zbirki podatkov, je zadostna že implicitna metoda skupne rabe.

Za primer implicitne povezave lahko vzamete oddelek, ki ima majhno zbirko podatkov o projektih, ki jim sledijo. Zbirka podatkov lahko vključuje informacije, kot so službene vozovnice posameznih oddelkov ali poslovni koledar za celotno podjetje. V tem primeru je priporočljivo graditi več aplikacij na vrhu implicitne povezave v skupni rabi, če bi moral biti do vseh podatkov omogočen dostop vseh uporabnikov, ki jim je omogočen dostop.

Aplikacije, ustvarjene z Power Apps so zasnovane tako, da so dostopne končnim uporabnikom. Takšen scenarij je pogost, ker so razvojni stroški, povezani z implicitnimi povezavami, nizki.

Aplikacije, ki temeljijo na oddelkih, lahko prerastejo v aplikacije, pomembne za celotno podjetje. V teh scenarijih je pomembno razumeti, da bo morala oddelčna aplikacija v celotnem podjetju imeti vgrajeno splošno uporabljeno varnost podjetja. Ta pristop je dražji za prizadevanja za ustvarjanje aplikacij, vendar je pomemben v scenarijih podjetij.

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.

Ko gre za identiteto uporabnika in varnost, uporabljajte storitve, kot je Azure Active Directory, namesto da se zanašate na filtre, zasnovane v aplikacijah. 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 storitev Power App s poverilnicami Azure AD. To vedenje je vzorec varnostne aplikacije strežnika. Uporabnik je znan prek uporabe identitete Azure AD 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 bo uporabil identiteto uporabnika Azure AD 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.

Poslovna plast (na strani strežnika) uporablja identiteto znanega uporabnika Azure AD za priklic shranjene procedure kot glavnice strežnika SQL Server in filtriranje podatkov. Vendar se Power Apps trenutno ne poveže s shranjenimi procedurami. Poslovna plast lahko prikliče tudi pogled, ki uporablja identiteto Azure AD kot glavni strežnik 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