Bruk Microsoft SQL Server sikkert med Power Apps

Det finnes forskjellige måter å koble til og godkjenne til SQL Server med Power Apps. Denne artikkelen beskriver konsepter som kan være nyttige når du skal velge om du vil koble til SQL Server med en sikkerhetstiltak som oppfyller kravene for appen.

Viktig

Funksjonen for sikre implisitte tilkoblinger ble gitt ut i januar 2024. Microsoft anbefaler på det sterkeste at alle apper som bruker implisitte tilkoblinger, til å konvertere til sikre implisitte tilkoblinger og tilbakekalle tilkoblinger som deles med sluttbrukere.

Forskjellen mellom eksplisitte, implisitte og sikre implisitte tilkoblinger

En tilkobling til SQL Server opprettes når du oppretter en app ved hjelp av Power Apps-tilkobling til SQL Server. Når slike apper publiseres og deles med andre, distribueres både appen og tilkoblingen til disse brukerne. Appen og tilkoblingen er med andre ord synlige for brukere appene deles med.

Godkjenningsmetoden som brukes for slike tilkoblinger, kan være eksplisitt eller implisitt. Vi kan også si at en slik tilkobling deles eksplisitt eller implisitt.

• En eksplisitt delt tilkobling betyr at sluttbrukeren av programmet må godkjenne til SQL Server med sin egen eksplisitte legitimasjon. Denne godkjenningen skjer vanligvis bak kulissene som en del av Microsoft Entra eller håndtrykket i Windows-godkjenning. Brukeren legger ikke merke til når godkjenningen skjer.
• En implisitt delt tilkobling betyr at brukeren implisitt bruker legitimasjonen for kontoen som apputvikleren brukte til å koble til og godkjenne til datakilde under oppretting av appen. Sluttbrukerlegitimasjonen brukes ikke til godkjenning. Hver gang sluttbrukeren kjører appen, bruker de legitimasjonen som forfatteren opprettet appen med.
• En sikker implisitt delt tilkobling henviser til et scenario der sluttbrukeren av appen implisitt bruker legitimasjonen for kontoen som apputvikleren brukte til å koble seg til og godkjenne til datakilde under oppretting av appen. Dette betyr at sluttbrukerens egen legitimasjon ikke brukes til godkjenning. I stedet når brukeren kjører appen, bruker vedkommende legitimasjonen som forfatteren av appen opprettet den med. Det er viktig å merke seg at sluttbrukeren ikke har direkte tilgang til tilkoblingen, og at appen bare gir tilgang til et begrenset sett med handlinger og tabeller.

Følgende fire tilkoblingsgodkjenningstyper kan brukes med SQL Server for Power Apps:

Godkjenningstype	Power Apps-tilkoblingsmetode
Microsoft Entra-integrert	Eksplisitt
SQL Server-godkjenning	Implisitte / sikre implisitte
Windows-godkjenning	Implisitte / sikre implisitte
Windows-autentisering (ikke delt)	Eksplisitt

Implisitt tilkobling deling risikoene

Alle nye programmer bruker automatisk de nye sikre implisitte tilkoblingene. Med apper som bruker eldre implisitte tilkoblinger, der både appen og tilkoblingene rulles ut til sluttbrukere, betyr det imidlertid at sluttbrukere kan redigere nye programmer basert på disse tilkoblingene.

Når en forfatter bruker sikre implisitte tilkoblinger, betyr det at ingen tilkobling deles og ingen sluttbruker mottar tilkoblingsobjektet. Dette eliminerer risikoen for at sluttbrukere som bruker en tilkobling på nytt, kan opprette en ny app. I stedet fungerer appen med en proxy-tilkobling som er klar over appen, og som bare kommuniserer med den bestemte appen. Proxy-tilkoblingen tillater begrensede handlinger (opprette, lese, oppdatere, slette) og tilgang til bestemte tabeller i appen som defineres når appen publiseres. Derfor gis bare autoriserte handlinger og tilgang til sluttbrukeren.

Den implisitte tilkoblingen i eldre stil ruller faktisk ut et tilkoblingsobjekt til sluttbrukeren. Hvis du for eksempel oppretter en app som filtrerer ut dataene du ikke vil at brukerne skal se. Men de filtrerte dataene finnes i databasen. Men du er avhengig av filteret du konfigurerte for å sikre at sluttbrukerne ikke ser bestemte data.

Igjen, med sikre implisitte tilkoblinger med eldre stil, når du har rullet ut appen, kan sluttbrukere bruke tilkoblingen som er distribuert med appen, i alle nye apper de oppretter. I de nye appene kan brukerne se dataene du filtrerte ut i programmet. Det er viktig å bruke de nye sikre implisitte tilkoblingene.

Viktig

Når en eldre implisitt delt tilkobling er distribuert til sluttbrukere, er begrensningene du har angitt i appen du delte (f.eks. filtre eller skrivebeskyttet tilgang), ikke lenger gyldig for nye apper sluttbrukerne oppretter. Sluttbrukerne har de rettighetene godkjenningen tillater som en del av en implisitt delt tilkobling. Når du konverterer en app til å bruke sikre implisitte tilkoblinger, må du derfor også oppheve tilkoblingene du delte med appen. Administratorer kan få en rapport over apper med implisitt delte tilkoblinger med COE-verktøysettet.

Klient- og serversikkerhet

Du kan ikke være avhengig av datasikkerheten ved hjelp av filtrering eller andre operasjoner på klientsiden for å være sikker. Programmer som krever sikker filtrering av data, må sørge for at både brukeridentifiseringen og filtreringen skjer på serveren.

Bruk tjenester som Microsoft Entra ID i stedet for å være avhengig av filtrene som er utformet i appene, når det gjelder brukeridentitet og sikkerhet. Denne konfigurasjonen sikrer at filtre på serversiden fungerer som forventet.

Illustrasjonene nedenfor forklarer hvordan sikkerhetsmønstrene i appene varierer mellom sikkerhetsmodeller på klientsiden og serversiden.

I et klientsikkerhetsappmønster [1] godkjenner brukeren bare til programmet på klientsiden. Deretter [2] ber programmet om informasjon om tjenesten, og [3] tjenesten returnerer informasjonen bare basert på dataforespørselen.

I et sikkerhetsmønster på serversiden [1] godkjenner brukeren først til tjenesten, slik at brukeren er kjent for tjenesten. Deretter [2] når en samtale deretter utføres fra programmet, [3] bruker tjenesten den kjente identiteten til den gjeldende brukeren til å filtrere dataene på riktig måte og [4] returnere dataene.

Scenariene for implisitt deling av avdelingene som er beskrevet ovenfor, er en kombinasjon av disse to mønstrene. Brukeren må logge på Power Apps-tjenesten med Microsoft Entra-legitimasjon. Denne virkemåten er mønsteret for serversikkerhetsapp. Brukeren er kjent ved å bruke Microsoft Entra-identiteten i tjenesten. Appen er derfor begrenset til settet med brukere som Power Apps formelt har delt programmet med.

Den implisitte delte tilkoblingen til SQL Server er imidlertid mønsteret for klientsikkerhetsappen. SQL Server vet bare at et bestemt brukernavn og passord brukes. Alle filtreringer på klientsiden kan for eksempel omgås et nytt program med samme brukernavn og passord.

Hvis du vil filtrere data sikkert på serversiden, bruker du de innebygde sikkerhetsfunksjonene i SQL Server, for eksempel sikkerhet på radnivå for rader, og nekter bestemte objekter (for eksempel kolonner) for bestemte brukere. Denne metoden bruker Microsoft Entra-bruker-ID-en til å filtrere dataene på serveren.

Noen eksisterende bedriftstjenester har brukt en metode der brukeridentiteten fanges opp i et forretningsdatalag mye på samme måte som Microsoft Dataverse gjør. I dette tilfellet kan forretningslaget bruke SQL Servers sikkerhet på radnivå og nekte-funksjoner direkte. Hvis den ikke gjør det, er det ofte slik at sikkerheten aktiveres ved hjelp av lagrede prosedyrer eller visninger.

Forretningslaget (på serversiden) bruker en kjent Microsoft Entra-brukeridentitet til å starte en lagret prosedyre som hovedkontohaver for SQL Server og filtrere dataene. Power Apps kobler imidlertid ikke til lagrede prosedyrer for øyeblikket. Et forretningslag kan også starte en visning som bruker Microsoft Entra-identiteten som sikkerhetskontohaver for SQL Server. I dette tilfellet brukes Power Apps til å koble til visningene slik at dataene filtreres på serversiden. Hvis du bare skal viser visninger til brukere, må Power Automate-flytene oppdateres.

Se også

Oversikt over koblinger for lerretsapper