Microsoft SQL Server droša izmantošana kopā ar Power Apps

Ir dažādi veidi, kā izveidot savienojumu un autentificēt SQL Server ar Power Apps. Šajā rakstā apskatīti jēdzieni, kas var būt noderīgi, izvēloties veidu, kā izveidot savienojumu ar SQL Server, izmantojot drošības pieeju, kas atbilst jūsu programmas prasībām.

Svarīgi

Šis raksts attiecas arī visām relāciju datu bāzēm un netiešiem savienojumiem.

Atšķirība starp skaidri izteiktiem un netiešiem savienojumiem

Savienojums ar SQL Server tiek izveidots ikreiz, kad izveidojat programmu, lietojot Power Apps savienojumu ar SQL Server. Kad šādas programmas tiek publicētas un kopīgotas ar citām, gan programma, gan savienojums tiek izvietots šiem lietotājiem. Citiem vārdiem sakot, gan programma, gan savienojums—ir redzami lietotājiem, ar kuriem programmas tiek kopīgotas.

Šādiem savienojumiem izmantotā autentifikācijas metode var būt izteikta vai netieša. Varam arī teikt, ka šāds savienojums tiek kopīgots tieši vai netieši.

• Tieši kopīgots savienojums nozīmē, ka programmas lietotājam ir jāveic autentificēšana ar SQL Server ar saviem skaidri norādītiem akreditācijas datiem. Parasti šī autentifikācija notiek aizkulisēs kā daļa no Microsoft Entra vai Windows autentifikācijas rokasspiediena. Lietotājs pat nepamana, kad notiek autentifikācija.
• Netieši kopīgots savienojums ka lietotājs netieši izmanto konta akreditācijas datus, ko programmas veidotājs izmantoja, lai izveidotu savienojumu ar datu avotu un veiktu autentifikāciju ar datu avotu programmas izveides laikā. Lietotāja akreditācijas dati netiek izmantoti, lai veiktu autentifikāciju. Katru reizi, kad lietotājs palaiž programmu, viņš izmanto tos akreditācijas datus, ar kuriem autors izveidoja šo programmu.

SQL Server pakalpojumam Power Apps var izmantot šādus četrus savienojuma autentifikācijas tipus:

Autentifikācijas tips	Power Apps savienojuma režīms
Microsoft Entra Integrēta	Tiešs
SQL Server autentifikācija	Netiešs
Windows autentifikācija	Netiešs
Windows autentifikācija (nekopīgota)	Tiešs

Netieša savienojumu kopīgošanas riski

Tā kā gan programma, gan tās savienojumi tiek izvietoti gala lietotājiem, tas nozīmē, ka lietotāji var autorēt jaunas programmas, pamatojoties uz šiem savienojumiem.

Piemēram, apsveriet iespēju, ka esat izveidojis programmu, kas filtrē datus, kurus nevēlaties darīt redzamus lietotājiem. Filtrētie dati ir pieejami datu bāzē. Taču jūs paļaujaties uz filtru, ko konfigurējat, lai nodrošinātu, ka lietotāji neredzēs noteiktus datus.

Pēc šīs programmas izvietošanas lietotāji var izmantot savienojumu, kas izvietots ar jūsu programmu jebkurās jaunajās programmās, ko tie izveido. Jaunajās programmās lietotāji var redzēt jūsu programmā filtrētos datus.

Svarīgi

Kad lietotājiem ir izvietots netieši kopīgots savienojums, jūsu kopīgotajā programmā (piemēram, filtru vai tikai lasīšanas piekļuves) ierobežojumi vairs nav derīgi jaunām programmām, kuras izveido lietotāji. Lietotājiem būs tādas tiesības, ko autentifikācija atļauj kā daļu no netieši kopīgota savienojuma.

Netieša savienojuma faktiska izmantošana

Ir derīgi lietošanas gadījumi gan netiešām, gan tiešām autentifikācijas metodēm. Izvēloties savu pieeju, apsveriet drošības modeli un atvieglojiet izstrādi. Parasti izmantojiet tiešas autentifikācijas metodi jebkurai situācijai, kurā jums ir uzņēmuma prasība, ka datiem jābūt ierobežotiem pēc rindas vai kolonnas principa.

Piemēram, tiešas savienojuma lietošanas gadījumā apsveriet pārdošanas vadītāju, kuram vajadzētu būt atļaujai skatīt tikai cenu atlaides vai pamatcenu datus, kas atrodas tajā pašā tabulā, kurā citam pārdošanas speciālistam ir jāredz prece un cena.

Tomēr ne visi dati ir nodrošināti tādā pašā veidā. Programma tiek kopīgota un izvietota noteiktiem lietotājiem vai lietotāju grupām. Personām, kas neietilpst šajā grupā, nav piekļuves programmai vai savienojumam. Tāpēc, ja visiem grupas dalībniekiem ir atļauja skatīt visus datus datu bāzē, netiešas kopīgošanas metode darbojas labi.

Kā piemēru netieša savienojuma izmantošanas gadījumam apsveriet departamentu, kuram ir neliela datu bāze par projektiem, kurus tas izseko. Datu bāzē var būt iekļauta tāda informācija kā departamenta darba uzdevumi vai korporatīvais kalendārs visam uzņēmumam. Šādā gadījumā var veicināt vairāk programmu veidošanu virs netieši kopīgotā savienojuma, ciktāl visiem datiem jābūt pieejamiem visiem lietotājiem, kuriem ir piešķirta piekļuve.

Programmas, kas izveidotas, izmantojot Power Apps, ir izstrādātas, lai tās būtu pieejamas lietotājiem. Šis scenārijs ir izplatīts, jo ar netiešiem savienojumiem saistītās izstrādes izmaksas ir zemas.

Departamenta programmas var izaugt par uzņēmuma mēroga un darbībai kritiskām programmām. Šajos scenārijos ir svarīgi saprast, ka, departamenta programmai attīstoties par uzņēmuma mēroga programmu, tajā būs jāiebūvē tradicionālā uzņēmuma drošība. Šī pieeja ir dārgāka programmu veidošanas nolūkos, bet ir svarīga korporatīvā mēroga scenārijos.

Klientu un servera drošība

Jūs nevarat paļauties uz datu drošību, izmantojot filtrēšanu vai citas klienta puses operācijas, kam jābūt drošām. Programmām, kurām nepieciešama droša datu filtrēšana, ir jānodrošina, ka gan lietotāju identifikācija, gan filtrēšana notiek serverī.

Izmantojiet tādus pakalpojumus kā Microsoft Entra ID, nevis paļaujieties uz lietotnēs izstrādātajiem filtriem, kad runa ir par lietotāja identitāti un drošību. Šī konfigurācija nodrošina servera puses filtru darbību, kā paredzēts.

Ilustrācijas zemāk paskaidro, kā programmu drošības shēmas atšķiras starp klienta puses un servera puses drošības modeļiem.

Klienta drošības programmas modelī [1] lietotājs autentificējas tikai ar programmu klienta pusē. Pēc tam [2] programma pieprasa informāciju par pakalpojumu, un [3] pakalpojums atgriež informāciju, pamatojoties tikai uz datu pieprasījumu.

Servera puses drošības modelī [1] lietotājs vispirms autentificējas pakalpojumā, lai lietotājs būtu zināms šim pakalpojumam. Pēc tam, [2] kad no programmas tiek izveidots izsaukums, pakalpojums [3] izmanto pašreizējā lietotāja zināmo identitāti, lai attiecīgi filtrētu [4] un atgrieztu datus.

Iepriekš aprakstītie netiešas departamenta bāzētas kopīgošanas scenāriji ir abu šo modeļu apvienojums. Lietotājam ir jāpiesakās pakalpojumā, Power Apps izmantojot Microsoft Entra akreditācijas datus. Šāda darbība ir servera drošības programmas modelis. Lietotājs ir zināms, Microsoft Entra izmantojot pakalpojumā esošo identitāti. Tāpēc programma ir ierobežota līdz lietotāju kopai, ar kuriem Power Apps oficiāli ir kopīgojusi programmu.

Taču netieši kopīgots savienojums ar SQL Server ir klienta drošības programmas modelis. SQL Server tikai zina, ka tiek izmantots noteikts lietotājvārds un parole. Jebkuru klienta puses filtrēšanu, piemēram, var apiet ar jaunu programmu, izmantojot to pašu lietotājvārdu un paroli.

Lai droši filtrētu datus servera pusē, izmantojiet iebūvētos SQL Server drošības līdzekļus, piemēram, rindas līmeņa drošību rindām un liegt atļaujas piekļūt konkrētiem objektiem (piemēram, kolonnām) konkrētiem lietotājiem. Šī pieeja izmantos Microsoft Entra lietotāja identitāti, lai filtrētu datus serverī.

Daži esošie korporatīvie pakalpojumi ir izmantojuši pieeju, kurā lietotāja identitāte tiek tverta biznesa datu slānī tādā pašā veidā, kā to dara Microsoft Dataverse. Šādā gadījumā biznesa slānis var vai nevar izmantot SQL Server rindas līmeņa drošību un liegt līdzekļus tieši. Ja tas nevar, bieži vien drošība ir iespējota, izmantojot iekļautās procedūras vai skatus.

Biznesa slānis (servera pusē) izmanto zināmu lietotāja Microsoft Entra identitāti, lai izsauktu saglabāto procedūru kā SQL servera principālu un filtrētu datus. Tomēr pašlaik Power Apps nav izveidots savienojums ar iekļautajām procedūrām. Biznesa slānis var arī izsaukt skatu, kas izmanto Microsoft Entra identitāti kā SQL Server principāls. Šajā gadījumā izmantojiet Power Apps, lai izveidotu savienojumu ar skatiem, tā ka dati tiek filtrēti servera pusē. Rādot lietotājiem tikai skatus, ir iespējams, ka nepieciešamas Power Automate plūsmas atjauninājumiem.

Skatiet arī

Pārskats par pamatnes programmu savienotājiem