Sigurna uporaba usluge Microsoft SQL Server koristeći Power Apps

Postoje različiti načini da spajanja i provjerite autentičnost na SQL poslužitelju s pomoću Power Apps. Ovaj članak iznosi koncepte koji mogu biti korisni pri odabiru načina povezivanja na SQL poslužitelj pomoću sigurnosnog pristupa koji odgovara zahtjevima vaše aplikacije.

Važno

Značajka sigurnih implicitnih veza objavljena je u siječnju 2024. Microsoft snažno potiče sve aplikacije koje trenutno koriste implicitne veze da se pretvaraju u sigurne implicitne veze i da opozovu veze koje se zajednički koriste s krajnjim korisnicima.

Razlika između eksplicitnih, implicitnih i sigurnih implicitnih veza

Veza s SQL poslužiteljem stvara se svaki put kada kreirate aplikaciju s pomoću Power Apps povezujući se SQL poslužitelj. Kada se takve aplikacije objave i podijele s drugima, i aplikacija i veza se raspoređuju na te korisnike. Drugim riječima, i aplikacija i veza—vidljive su korisnicima s kojima se aplikacije dijele.

Način provjere autentičnosti koji se koristi za takve veze može biti eksplicitan ili implicitan. Možemo također reći da se takva veza dijeli eksplicitno ili implicitno.

  • Eksplicitno podijeljena veza znači da krajnji korisnik aplikacije mora provjeriti autentičnost na SQL poslužitelju s vlastitim eksplicitnim vjerodajnicama. Obično se ta provjera autentičnosti događa iza kulisa kao dio rukovanja za Microsoft Entra provjeru autentičnosti ili Windows provjere autentičnosti. Korisnik niti ne primjećuje kada se provjera autentičnosti odvija.
  • Implicitno podijeljena veza znači da korisnik implicitno koristi vjerodajnice računa koji je izrađivač aplikacija koristio za povezivanje i provjeru autentičnosti na izvoru podataka tijekom izrade aplikacije. Vjerodajnice krajnjeg korisnika se ne koriste se za autentifikaciju. Svaki put kada krajnji korisnik pokrene aplikaciju, koriste se vjerodajnicama s kojima je autor stvorio aplikaciju.
  • Sigurna, implicitno dijeljena veza odnosi se na scenarij u kojem krajnji korisnik aplikacije implicitno koristi vjerodajnice računa koje je proizvođač aplikacije koristio za povezivanje i provjeru autentičnosti izvor podataka tijekom izrade aplikacije. To znači da se vjerodajnice krajnjeg korisnika ne koriste za provjeru autentičnosti. Umjesto toga, kada korisnik pokrene aplikaciju, koristi vjerodajnice s kojima ju je autor aplikacije stvorio. Važno je napomenuti da krajnjem korisniku nije omogućen izravan pristup vezi, a aplikacija dopušta pristup samo ograničenom skupu radnji i tablica.

Sljedeće četiri vrste provjere autentičnosti veze mogu se koristiti sa SQL poslužiteljem za Power Apps:

Vrsta provjere autentičnosti Način povezivanja Power Apps
Microsoft Entra Integriran Eksplicitno
Provjera autentičnosti za SQL Server Implicitno / sigurno implicitno
Provjera autentičnosti sustava Windows Implicitno / sigurno implicitno
Provjera autentičnosti u sustavu Windows (nije zajednička) Eksplicitno

Implicitni rizici dijeljenja veze

Sve nove aplikacije automatski koriste nove sigurne implicitne veze. Međutim, s aplikacijama koje koriste starije "implicitne veze", i aplikacija i njezine veze implementiraju se krajnjim korisnicima, to znači da krajnji korisnici mogu stvarati nove aplikacije na temelju tih veza.

Kada autor koristi sigurne implicitne veze, to znači da se veza ne dijeli i nijedan krajnji korisnik ne prima objekt veze. Time se eliminira rizik od ponovnog korištenja veze za stvaranje nove aplikacije od strane autora krajnjeg korisnika. Umjesto toga, aplikacija radi s proxy vezom koja je svjesna aplikacije i komunicira samo s tom aplikacijom. Proxy veza omogućuje ograničene radnje (stvaranje, čitanje, ažuriranje, brisanje) i pristup određenim tablicama u aplikaciji koje su definirane prilikom objavljivanja aplikacije. Stoga se krajnjem korisniku odobravaju samo ovlaštene radnje i pristup.

Jednostavna implicitna veza starijeg stila zapravo distribuira objekt veze krajnjem korisniku. Na primjer, ako izradite aplikaciju koja filtrira podatke koje ne želite da korisnici vide. No, filtrirani podaci prisutni su u bazi podataka. No, oslanjate se na filtar koji ste konfigurirali kako biste osigurali da krajnji korisnici neće vidjeti određene podatke.

Opet, sa starijim stilom jednostavnih implicitnih veza, nakon što implementirate aplikaciju, krajnji korisnici mogu koristiti vezu implementiranu s vašom aplikacijom u bilo kojoj novoj aplikaciji koju stvore. U novim aplikacijama korisnici mogu vidjeti podatke koje ste filtrirali u svojoj aplikaciji. Važno je koristiti nove sigurne implicitne veze.

Važno

Nakon što se starija implicitno dijeljena veza uvede krajnjim korisnicima, ograničenja koja ste možda stavili u aplikaciju koju ste podijelili (kao što su filtri ili pristup samo za čitanje) više ne vrijede za nove aplikacije koje krajnji korisnici stvore. Krajnji će korisnici imati prava koja autentifikacija dopušta kao dio implicitno podijeljene veze. Stoga, kada pretvarate aplikaciju da koristi sigurne implicitne veze, morate opozvati i veze koje ste podijelili s aplikacijom. Administratori mogu dobiti izvješće o aplikacijama s implicitno dijeljenim vezama s paketom alata COE.

Sigurnost klijenta i poslužitelja

Ne možete se pouzdati u sigurnost podataka filtriranjem ili drugim klijentskim operacijama da biste bili sigurni. Aplikacije koje zahtijevaju sigurno filtriranje podataka moraju osigurati da se identifikacija korisnika i filtriranje događaju na poslužitelju.

Koristite usluge kao Microsoft Entra što je ID umjesto da se oslanjate na filtre dizajnirane unutar aplikacija kada je riječ o korisničkom identitetu i sigurnosti. Ova konfiguracija osigurava da filtri na strani poslužitelja rade kako se očekuje.

Sljedeće ilustracije objašnjavaju kako se sigurnosni obrasci unutar aplikacija razlikuju između sigurnosnih modela na strani klijenta i poslužitelja.

Klijentski sigurnosni obrazac u aplikaciji.

U obrascu sigurnosne aplikacije klijenta, [1] korisnik provjerava autentičnost aplikacije samo na klijentskoj strani. Zatim [2] aplikacija zahtijeva podatke o usluzi i usluga [3] vraća informacije isključivo na temelju zahtjeva za podacima.

Sigurnosni obrazac na strani poslužitelja u aplikaciji.

U sigurnosnom uzorku na strani poslužitelja, [1] korisnik se prvo ovjerava na usluzi kako bi korisnik bio poznat usluzi. Zatim, [2] kada se iz aplikacije uputi poziv, usluga [3] koristi poznati identitet trenutnog korisnika za odgovarajuće filtriranje podataka i [4] vraća podatke.

Gore opisani implicitni scenariji dijeljenja odjela kombinacija su ova dva uzorka. Korisnik se mora prijaviti na Power Apps uslugu pomoću Microsoft Entra vjerodajnica. To je ponašanje uzorka sigurnosne aplikacije poslužitelja. Korisnik je poznat po korištenju identiteta Microsoft Entra na usluzi. Stoga je aplikacija ograničena na skup korisnika s kojima je Power Apps službeno podijelio prijavu.

Međutim, implicitna dijeljena veza sa SQL poslužiteljem je obrazac sigurnosne aplikacije klijenta. SQL poslužitelj zna samo da se koristi određeno korisničko ime i lozinka. Bilo koje filtriranje na strani klijenta, na primjer, može se zaobići novom aplikacijom koristeći isto korisničko ime i lozinku.

Da biste sigurno filtrirali podatke na strani poslužitelja, upotrijebite ugrađene sigurnosne značajke u SQL poslužitelju, poput sigurnost na razini retka za redove i poricati dozvole za određene objekte (kao što su stupci) za određene korisnike. Ovaj pristup koristi Microsoft Entra korisnički identitet za filtriranje podataka na poslužitelju.

Neke postojeće korporativne usluge koristile su pristup u kojem se identitet korisnika bilježi u sloj poslovnih podataka na sličan način kako to radi Microsoft Dataverse. U ovom slučaju, poslovni sloj može ili ne mora koristiti sigurnost na razini retka SQL poslužitelja i izravno zabraniti značajke. Ako se to ne dogodi, često se dogodi da je zaštita omogućena pomoću pohranjenih procedura ili pogleda.

Poslovni sloj (na strani poslužitelja) koristi poznati korisnički Microsoft Entra identitet za pozivanje pohranjene procedure kao glavni SQL Server i filtriranje podataka. Međutim, Power Apps trenutno se ne povezuje s pohranjenim procedurama. Poslovni sloj također može pozvati prikaz koji koristi Microsoft Entra identitet kao glavni SQL Server. U ovom slučaju koristite Power Apps za povezivanje s prikazima tako da se podaci filtriraju na strani poslužitelja. Izlaganje samo pogleda korisnicima koji će možda trebati tijekove Power Automate za ažuriranja.

Pogledajte također

Pregled poveznika za aplikacije od gotovih gradivnih elemenata