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

Ovaj se članak odnosi i na druge relacijske baze podataka, poput Oraclea.

Razlika između eksplicitnih i 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 ova autentifikacija događa iza kulisa kao dio Azure Active Directory ili rukovanja autentifikacijom sustava Windows. 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.

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
Azure AD Integrated Eksplicitno
Provjera autentičnosti za SQL Server Implicitno
Provjera autentičnosti sustava Windows Implicitno
Provjera autentičnosti sustava Windows (ne dijeli se) Eksplicitno

Implicitni rizici dijeljenja veze

Budući da su i aplikacija i njene veze postavljene na krajnje korisnike, to znači da krajnji korisnici mogu stvarati nove aplikacije na temelju tih veza.

Na primjer, uzmite u obzir da ste izradili aplikaciju koja je filtrirala podatke za koje ne želite da ih korisnici vide. 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.

Nakon što implementirate ovu aplikaciju, krajnji korisnici mogu koristiti vezu postavljenu s vašom aplikacijom u bilo kojoj novoj aplikaciji koju kreiraju. U novim aplikacijama korisnici mogu vidjeti podatke koje ste filtrirali u svojoj aplikaciji.

Važno

Nakon što se implicitno podijeljena veza primijeni na krajnje korisnike, ograničenja koja ste možda postavili u aplikaciju koju ste podijelili (poput filtara ili pristupa samo za čitanje) više ne vrijede za nove aplikacije koje krajnji korisnici kreiraju. Krajnji će korisnici imati prava koja autentifikacija dopušta kao dio implicitno podijeljene veze.

Upotrebe implicitne veze u stvarnom svijetu

Postoje valjani slučajevi upotrebe i za implicitne i za eksplicitne metode provjere autentičnosti. Uzmite u obzir sigurnosni model i jednostavnost razvoja kada odabirete svoj pristup. Kao općenito pravilo, koristite eksplicitnu metodu provjere autentičnosti za svaku situaciju u kojoj imate poslovni zahtjev gdje podaci moraju biti ograničeni na osnovi redaka ili stupaca.

Za primjer eksplicitnog slučaja korištenja veze, razmotrite voditelja prodaje kojem bi trebalo biti omogućeno da vidi samo popuste na cijene ili podatke o osnovnim troškovima koji se nalaze u istoj tablici gdje drugi prodajni stručnjak treba vidjeti proizvod i cijenu.

Međutim, možda neće biti potrebno osigurati sve podatke na isti način. Aplikacija se dijeli i raspoređuje na određene korisnike ili skupine korisnika. Osobe izvan te grupe nemaju pristup aplikaciji ili vezi. Stoga, ako je svatko u grupi ovlašten vidjeti sve podatke u bazi podataka, implicitna metoda dijeljenja dobro funkcionira.

Za primjer slučaja implicitne veze, razmotrite odjel koji ima malu bazu podataka projekata koje prate. Baza podataka može sadržavati informacije poput radnih karata za odjele ili korporativnog kalendara za cijelu tvrtku. U ovom se scenariju može poticati izgradnja više aplikacija povrh implicitno podijeljene veze sve dok svi podaci kojima je odobren pristup trebaju biti dostupni svim podacima.

Aplikacije stvorene s pomoću Power Apps napravljene su tako da im krajnji korisnici mogu pristupiti. Ovakav je scenarij uobičajen jer su troškovi razvoja povezani s implicitnim vezama niski.

Aplikacije koje se temelje na odjelima mogu prerasti u aplikacije cijelog poduzeća i kritične za misiju. U tim je scenarijima važno shvatiti da će, kako se aplikacija odjela kreće u cijelo poduzeće, trebati imati ugrađenu tradicionalnu sigurnost poduzeća. Ovaj je pristup skuplji za napore u izradi aplikacija, ali važan je u korporacijskim scenarijima.

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 poput Azure Active Directory umjesto da se oslanjate na filtre napravljene u aplikacijama kada je riječ o identitetu i sigurnosti korisnika. 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 uslugu Power App pomoću vjerodajnica za Azure AD. To je ponašanje uzorka sigurnosne aplikacije poslužitelja. Korisnik je poznat zahvaljujući identitetu Azure AD 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 će se pristup koristiti korisnički identitet Azure AD 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 identitet poznatog korisnika za Azure AD za pozivanje pohranjene procedure kao glavni SQL poslužitelj i filtriranje podataka. Međutim, Power Apps trenutno se ne povezuje s pohranjenim procedurama. Poslovni sloj također može pozvati pogled koji koristi identitet Azure AD kao glavni SQL poslužitelj. 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