Bruge Microsoft SQL Server sikkert sammen med Power Apps

Du kan oprette forbindelse til og godkende SQL Server med Power Apps på forskellige måder. I denne artikel beskrives begreber, der kan være nyttige, når du skal vælge, hvordan du vil oprette forbindelse til SQL Server med en sikkerhed tilgang, der afspejler kravene til din app.

Vigtigt

Denne artikel gælder for alle relationsdatabaser og implicitte forbindelser.

Forskelle mellem eksplicitte og implicitte forbindelser

Der oprettes en forbindelse til SQL Server, når du opretter en app ved at forbinde Power Apps med SQL Server. Når sådanne apps publiceres og deles med andre, installeres både appen og forbindelsen til disse brugere. Med andre ord er appen og forbindelsen begge synlige for de brugere, som appen deles med.

Den godkendelsesmetode, der bruges til sådanne forbindelser, kan være eksplicit eller implicit. Vi kan også sige, at en sådan forbindelse deles eksplicit eller implicit.

  • En eksplicit delt forbindelse betyder, at slutbrugeren af applikationen skal godkendes på SQL Server med sine egne eksplicitte legitimationsoplysninger. Denne godkendelse foregår som regel bag kulisserne som en del af godkendelsen i Microsoft Entra eller Windows. Brugeren bemærker ikke engang, hvornår godkendelsen finder sted.
  • En implicit delt forbindelse betyder, at brugeren implicit bruger legitimationsoplysningerne for den konto, som appudvikleren brugte til at oprette forbindelse til og godkende datakilden under oprettelse af appen. Slutbrugerens legitimationsoplysninger bruges ikke til godkendelse. Hver gang slutbrugeren kører appen, bruger brugeren de legitimationsoplysninger, som forfatteren har oprettet appen med.

Følgende fire godkendelsestyper for forbindelsen kan bruges sammen med SQL Server til Power Apps:

Godkendelsestype Power Apps-forbindelsesmetode
Microsoft Entra Integrated Explicit
SQL Server-godkendelse Implicit
Windows-godkendelse Implicit
Windows-godkendelse (ikke delt) Explicit

Risici ved implicit forbindelsesdeling

Da både appen og dens forbindelser installeres for slutbrugere, betyder det, at slutbrugere kan udvikle nye applikationer på baggrund af disse forbindelser.

Forestil dig f.eks., at du har oprettet en app, der har filtreret de data ud, som brugerne ikke skal kunne se. De filtrerede data findes i databasen. Men du er afhængig af det filter, du har konfigureret, for at sikre, at slutbrugerne ikke kan se bestemte data.

Når du har installeret denne app, kan slutbrugere bruge den forbindelse, der installeres sammen med din app, i alle nye apps, de opretter. I de nye apps kan brugerne se de data, du har filtreret ud i programmet.

Vigtigt

Når en implicit delt forbindelse er installeret for slutbrugere, er de begrænsninger, du har angivet i den app, du har delt (f.eks. filtre eller skrivebeskyttet adgang), ikke længere gældende for nye apps, slutbrugere opretter. Slutbrugerne har de rettigheder, godkendelsen tillader som en del af en implicit delt forbindelse.

Brug af implicitte forbindelser i den virkelige verden

Der findes relevante brugssituationer for både implicitte og eksplicitte godkendelsesmetoder. Overvej sikkerhedsmodellen og brugervenligheden i udviklingen, når du vælger din fremgangsmåde. Som regel skal du bruge en eksplicit godkendelsesmetode i alle de situationer, hvor du har et forretningskrav og data skal begrænses på række- eller kolonnebasis.

Hvis du har en brugssituation med en eksplicit forbindelse, kan du have en salgschef, der kun skal have tilladelse til at se prisrabatter eller data for basisomkostninger, som findes i den samme tabel, som en anden sælger skal have vist produkt og pris for.

Det er dog ikke sikkert, at alle data skal beskyttes på samme måde. En app deles i og installeres til bestemte brugere eller brugergrupper. Personer uden for den pågældende gruppe har ikke adgang til appen eller forbindelsen. Så hvis alle i en gruppe har tilladelse til at se alle data i en database, fungerer en implicit delingsmetode godt.

Hvis du har en brugssituation med en implicit forbindelse, kan du have en afdeling, der har en lille database med de projekter, de sporer. Databasen kan indeholde oplysninger som f.eks. arbejdssedler for afdelingen eller forretningskalenderen for hele virksomheden. I dette scenarie kan det være en fordel at bygge flere apps oven på den implicit delte forbindelse, så længe alle data skal være tilgængelige for alle brugere, der gives adgang.

Apps, der er oprettet ved hjælp af Power Apps, er udviklet, så de kan kontaktes af slutbrugere. Denne type scenarie er almindeligt, fordi de udviklingsomkostninger, der er forbundet med implicitte forbindelser, er lave.

Afdelingsbaserede apps kan vokse til apps, der dækker hele virksomheden og er afgørende for dens arbejde. I disse scenarier er det vigtigt at forstå, at efterhånden som en afdelingsapp udbredes til hele virksomheden, skal der integreres traditionelle sikkerhedsforanstaltninger for virksomheden. Denne fremgangsmåde for opbygning af apps er mere bekostelige, men er vigtig i scenarier, der dækker hele virksomheden.

Sikkerhed for klient og server

Du kan ikke regne med, at data er beskyttede alene gennem filtrering eller andre handlinger på klientsiden. Applikationer, der kræver sikker filtrering af data, skal sikre, at både brugeridentifikation og -filtrering foregår på serveren.

Brug tjenester som f.eks. Microsoft Entra ID i stedet for de filtre, der er udviklet i appsene, når det drejer sig om brugeridentitet og sikkerhed. Denne konfiguration sikrer, at filtre på serversiden fungerer som forventet.

I følgende illustrationer forklares det, hvordan sikkerhedsmønstrene i appsene adskiller sig fra hinanden for sikkerhedsmodeller på henholdsvis klient- og serversiden.

Sikkerhedsmønster på klientsiden i en app.

I en app med sikkerhedsmønster på klientsiden [1] godkender brugeren kun applikationen på klientsiden. Derefter [2] anmoder applikationen om oplysninger fra tjenesten, og [3] tjenesten returnerer oplysningerne udelukkende på baggrund af dataanmodningen.

Sikkerhedsmønster på serversiden i en app.

I et sikkerhedsmønster på serversiden [1] godkender brugeren først tjenesten, så brugeren er kendt for tjenesten. Når der derefter [2] foretages et opkald fra applikationen, bruger tjenesten [3] den aktuelle brugers kendte identitet til at filtrere dataene korrekt og [4] returnerer dataene.

De implicitte delingsscenarier for afdelinger, der er beskrevet ovenfor, er en kombination af disse to mønstre. Brugeren skal logge på tjenesten Power Apps ved hjælp af Microsoft Entra-legitimationsoplysninger. Denne funktionsmåde benytter mønsteret for appen med serversikkerhed. Brugeren genkendes ved hjælp af Microsoft Entra-identiteten i tjenesten. Appen er derfor begrænset til det sæt af brugere, som Power Apps formelt har delt applikationen med.

Den implicitte delte forbindelse til SQL Server benytter til gengæld mønsteret for appen med klientsikkerhed. SQL Server ved kun, at der bruges et bestemt brugernavn og en bestemt adgangskode. Enhver filtrering på klientsiden kan f.eks. omgås med en ny applikation ved hjælp af samme brugernavn og adgangskode.

Hvis du vil filtrere data på serversiden sikkert, skal du bruge de indbyggede sikkerhedsfunktioner i SQL Server, f.eks. sikkerhed på rækkeniveau for rækker, og nægte tilladelserne til at bruge bestemte objekter (f.eks. kolonner) for bestemte brugere. Denne fremgangsmåde benytter Microsoft Entra-brugeridentiteten til at filtrere dataene på serveren.

Visse eksisterende forretningstjenester har benyttet en fremgangsmåde, hvor brugeridentiteten hentes i et forretningsdatalag på stort set samme måde, som Microsoft Dataverse gør det. I dette tilfælde bruger forretningslaget muligvis SQL Server's sikkerhed på rækkeniveau og afviser funktioner direkte. Hvis det ikke er tilfældet, sker det ofte, at sikkerheden aktiveres ved hjælp af lagrede procedurer eller visninger.

I forretningslaget (på serversiden) bruges en kendt Microsoft Entra-brugeridentitet til at aktivere en gemt procedure som en SQL Server-sikkerhedskonto og filtrere dataene. Power Apps opretter dog ikke forbindelse til lagrede procedurer i øjeblikket. Et forretningslag kan også aktivere en visning, der bruger Microsoft Entra-identiteten som SQL Server-sikkerhedskonto. I dette tilfælde kan du bruge Power Apps til at oprette forbindelse til visningerne, så dataene filtreres på serversiden. På den måde afsløres kun visninger for bruger, som har brug for Power Automate-flows til opdateringer.

Se også

Oversigt over connectorer til lærredapps