Microsoft SQL Server turvaliselt kasutamine Power Apps'is

SQL Serveriga ühenduse loomiseks rakendusega Power Apps ja autentimiseks on erinevad võimalused. Selles artiklis kirjeldatakse mõisteid, mis võivad olla kasulikud valiku tegemisel selle kohta, kuidas luua ühenduse SQL Serveriga teie rakenduse nõuetele vastava turvapõhimõttega.

Oluline

See artikkel kehtib kõigile relatsioonilistele andmebaasidele ja kaudsetele seostele.

Selgete ja kaudsete seoste erinevus

Ühendus SQL Serveriga luuakse iga kord, kui loote rakenduse Power Apps ja SQL Serveriga ühenduse loomisel. Kui sellised rakendused avaldatakse ja jagatakse teistega, juurutatakse neile kasutajatele nii rakendus kui ka ühendus. See tähendab, et rakendus ja ühendus—on kasutajatele nähtavad ning rakendusi jagatakse.

Selliste ühenduste puhul kasutatav autentimismeetod võib olla otsene või kaudne. Võime öelda ka, et sellist ühendust jagatakse otseselt või kaudselt.

  • Otsene ühisühendus tähendab, et rakenduse lõppkasutaja peab SQL Serveri autentimiseks kasutama oma otseseid sisselogimisandmeid. Tavaliselt toimub see autentimine kulisside taga osana Microsoft Entra Windowsi autentimise käepigistusest. Kasutaja ei märka isegi autentimise asetleidmist.
  • Kaudne ühisühendus tähendab, et kasutaja kasutab kaudselt selle konto sisselogimisandmeid, mida rakenduse koostaja rakenduse loomisel andmeallikaga ühenduse loomiseks ja autentimiseks kasutas. Lõppkasutaja sisselogimisandmeid ei kasutata autentimiseks. Iga kord, kui lõppkasutaja rakendust käitab, kasutavad nad sisselogimisandmeid, millega autor rakenduse lõi.

SQL Serveri puhul saab kasutada järgmist nelja Power Apps ühenduseautentimise tüüpi:

Autentimistüüp Power Apps ühendusviis
Microsoft Entra Integreeritud Otsene
SQL-serveri autentimine Kaudne
Windowsi autentimine Kaudne
Windowsi autentimine (mitte ühiskasutuses) Otsene

Kaudse ühenduse jagamise riskid

Kuna nii rakendus kui ka selle ühendused on juurutatud lõppkasutajatele, tähendab see, et lõppkasutajad saavad luua nende ühenduste põhjal uusi rakendusi.

Oletagem näiteks, et lõite rakenduse, mis filtreeris välja andmed, mida te ei soovi kasutajatel näha. Filtreeritud välja andmed on andmebaasis olemas. Kuid toetute seadistatud filtrile, et tagada, et lõppkasutajad ei näe teatud andmeid.

Pärast selle rakenduse juurutamist saavad lõppkasutajad kasutada teie rakendusega juurutatud ühendust mis tahes uutes rakendustes, mille nad loovad. Uutes rakendustes näevad kasutajad andmeid, mille teie rakenduses välja filtreerisite.

Oluline

Kui kaudselt jagatud ühendus on lõppkasutajatele kasutusele võetud, ei kehti teie jagatud rakenduses kehtestatud piirangud (nt filtrid või kirjutuskaitstud juurdepääs) enam uute lõppkasutajate loodud rakenduste jaoks. Lõppkasutajatel on vaikimisi jagatud ühenduse osana kõik õigused, mida autentimine võimaldab.

Kaudse ühenduse tegelik kasutamine

Kehtivad kasutusjuhtumid nii otseste kui ka kaudsete autentimisviiside puhul. Kaaluge lähenemist valides turbemudelit ja hõlbustage arengut. Üldjuhul kasutage selgesõnalist autentimismeetodit igas olukorras, kus teil on ettevõtte nõue, kus andmeid tuleb piirata rea ​​või veeru alusel.

Otseste ühenduste kasutamise juhtumite näiteks on müügijuht, kellel peaks olema lubatud näha hinnasoodustusi või baaskulude andmeid ainult samas tabelis, kus teine ​​müügiprofessionaal peab nägema toodet ja hinda.

Kuid kõiki andmeid ei pruugita samal viisil turvata. Rakendus on ühiskasutuses ja juurutatud kindlatele kasutajatele või kasutajarühmadele. Väljaspool seda rühma ei ole isikutel juurdepääsu rakendusele ega ühendusele. Seega, kui kõigil grupi liikmetel on õigus näha kõiki andmebaasis olevaid andmeid, töötab kaudne jagamismeetod hästi.

Kaudse ühenduse kasutamise juhtumi näiteks on osakond, millel on väike jälgitavate projektide andmebaas. Andmebaas võib sisaldada näiteks osakondade töögraafikut või ettevõtte kalendrit kogu ettevõtte jaoks. Selle stsenaariumi korral võib julgustada kaudselt jagatud ühenduse peale rohkemate rakenduste loomist, kui kõikidele andmetele peaksid olema juurdepääsed kõik kasutajad, kellele juurdepääs on antud.

Power Apps abil loodud rakendused on välja töötatud nii, et lõppkasutajad peaksid neid kasutama. Sellist tüüpi stsenaarium on levinud, kuna kaudsete ühendustega seotud arenduskulu on madal.

Osakonnapõhised rakendused võivad laieneda kogu ettevõtte ja missiooni jaoks olulisteks rakendusteks. Nende stsenaariumide puhul on oluline mõista, et osakonda hõlmava rakendusena peab see olema kogu ettevõtte hõlmav, selleks peab olema rajatud tavapärane ettevõtete turvalisus. See lähenemisviis on rakenduste loomise jaoks kallim, kuid oluline kogu ettevõtte stsenaariumide korral.

Kliendi ja serveri turvalisus

Turvalisuse tagamiseks ei saa filtrite või muude kliendipoolsete toimingute kaudu andmete turvalisusele tugineda. Rakendused, mis nõuavad andmete turvaliset filtreerimist, peavad tagama, et serveris toimub nii kasutaja ID kui ka filtreerimine.

Kasutage selliseid teenuseid nagu Microsoft Entra ID, selle asemel et tugineda kasutaja identiteedi ja turvalisuse osas rakendustes loodud filtritele. See konfiguratsioon tagab serveripoolsete filtrite töö eeldatud viisil.

Järgmistes illustratsioonides selgitatakse, kuidas rakenduste turbemustrid erinevad kliendi- ja serveripoolsetel turvamudelitel.

Rakenduse kliendipoolne turbemustris.

Kliendi turberakenduse mustris [1] autendib kasutaja rakenduse ainult kliendipoolselt. Seejärel [2] taotleb rakendus teenuse kohta teavet ja [3] teenus tagastab teabe ainult andmepäringu põhjal.

Rakenduse serveripoolne turbemustris.

Serveripoolses turbemustris [1] autendib kasutaja teenuse esmalt, et kasutaja oleks teenuse jaoks teada. Seejärel, [2] kui rakendusest päritakse, kasutab teenus [3] praeguse kasutaja teadaolevat identiteeti andmete sobivaks filtreerimiseks ja [4] tagastab andmed.

Eespool kirjeldatud kaudsed osakondade jagamise stsenaariumid on nende kahe mudeli kombinatsioon. Kasutaja peab teenusesse Power Apps sisse logima mandaatide abil Microsoft Entra . Selline käitumine on serveri turberakenduse muster. Kasutaja on tuntud teenuses oleva Microsoft Entra identiteedi abil. Seetõttu on rakendus piiratud kasutajate rühmaga, kes on Power Apps rakendusega ühiskasutusse antud.

Kuid kaudne ühisühendus SQL Serveriga on kliendi turberakenduse muster. SQL Server teab ainult, et kasutatakse konkreetset kasutajanime ja parooli. Näiteks saab kliendipoolsest filtreerimisest mööda minna uue rakendusega, kasutades sama kasutajanime ja parooli.

Andmete turvaliseks filtreerimiseks serveripoolselt kasutage SQL Serveri sisseehitatud turbefunktsiooni nt reatasemel turbeks ja keelake kindlate objektide (nt veergude) õigused kindlatele kasutajatele. See lähenemine kasutab Microsoft Entra serveris olevate andmete filtreerimiseks kasutaja identiteeti.

Mõnes olemasolevas ettevõtteteenuses on kasutatud lähenemisviisi, kus kasutaja identiteet on äriandmete kihis hõivatud umbes samamoodi nagu Microsoft Dataverse. Sel juhul võib või ei pruugi ärikiht kasutada SQL Serveri reataseme turvalisust ja keelata funktsioone otse. Kui seda ei tehta, on turva lubamine sageli salvestatud protseduuride või vaadete abil.

Ärikiht (serveri poolel) kasutab teadaolevat kasutajaidentiteeti Microsoft Entra , et käivitada salvestatud protseduur SQL Serveri printsipaalina ja filtreerida andmeid. Kuid praegu Power Apps ei loo ühendust salvestatud protseduuridega. Ärikiht võib käivitada ka vaate, mis kasutab Microsoft Entra identiteeti SQL Serveri printsipaalina. Sel juhul kasutade rakendust Power Apps vaadetega ühenduse loomiseks, et andmeid filtreeritaks serveri poolel. Võib olla, et kasutajatele ainult vaadete kuvamiseks on vaja Power Automate voogusid.

Vt ka

Ülevaade lõuendirakenduste konnektorite kohta