Använd Microsoft SQL Server säkert med Power Apps

Det finns olika sätt att ansluta och autentisera till SQL Server med Power Apps. Den här artikeln beskriver begrepp som kan vara till hjälp vid valet av hur du ansluter till SQL Server med en säkerhetsmetod som matchar kraven för ditt program.

Viktigt

Den här artikeln gäller alla relationsdatabaser och implicita anslutningar.

Skillnad mellan uttryckliga och implicita kopplingar

En anslutning till SQL Server skapas när du skapar ett program med Power Apps ansluta till SQL Server. När sådana appar publiceras och delas med andra distribueras både programmet och anslutningen till dessa användare. Med andra ord programmet och anslutningen— båda är synliga för användare som apparna delas med.

Verifieringsmetoden som används för sådana anslutningar kan vara explicit eller implicit. Vi kan också säga att sådan anslutning delas uttryckligen eller implicit.

• En uttryckligen delad anslutning innebär att slutanvändaren av applikationen måste autentisera till SQL Server med sina egna uttryckliga referenser. Vanligtvis sker denna autentisering bakom kulisserna som en del av Microsoft Entra eller Windows-autentiseringshandskakning. Användaren märker inte ens när autentiseringen äger rum.
• En implicit delad anslutning innebär att användaren implicit använder autentiseringsuppgifterna för det konto som apptillverkaren använde för att ansluta och autentisera till datakällan under skapandet av programmet. Slutanvändarens referenser används inte för att autentisera. Varje gång slutanvändaren kör programmet används de autentiseringsuppgifter som författaren skapade programmet med.

Följande fyra anslutningsautentiseringstyper kan användas med SQL Server för Power Apps:

Autentiseringstyp	Power Apps-anslutningens metod
Integrerad Microsoft Entra	Explicit
SQL Server-autentisering	Implicit
Windows-autentisering	Implicit
Windows-autentisering (ej delad)	Explicit

Implicita risker för anslutningsdelning

Eftersom både programmet och dess anslutningar distribueras för slutanvändare betyder det att slutanvändare kan skapa nya applikationer baserat på dessa anslutningar.

Tänk till exempel att du skapade ett program som filtrerade bort de data som du inte vill att användarna ska se. De bortfiltrerade uppgifterna finns i databasen. Men du förlitar dig på filtret du konfigurerade för att säkerställa att slutanvändarna inte ser vissa data.

När du har distribuerat den här programmet kan slutanvändare använda anslutningen som distribueras med ditt program i alla nya appar de skapar. I de nya apparna kan användarna se den data du filtrerat bort i din applikation.

Viktigt

När en implicit delad anslutning har distribuerats till slutanvändare är de begränsningar du kan ha lagt i programmet du delade (till exempel filter eller skrivskyddad åtkomst) inte längre giltiga för nya appar som slutanvändare skapar. Slutanvändarna har de rättigheter som autentiseringen tillåter som en del av implicit delad anslutning.

Verklig användning av implicit anslutning

Det finns giltiga användningsfall för både implicita och explicita autentiseringsmetoder. Tänk på säkerhetsmodell och enkel utveckling när du väljer ditt tillvägagångssätt. Använd som en allmän regel en uttrycklig autentiseringsmetod för alla situationer där du har ett affärsbehov där data måste begränsas på rad- eller kolumnbasis.

För ett exempel på ett uttryckligt användningsfall för anslutningar, överväg en försäljningschef som endast bör få se prisrabatter eller baskostnadsdata som finns i samma tabell där en annan försäljningspersonal behöver se produkt och pris.

Det är dock inte alla data som behöver säkras på samma sätt. ett program delas och distribueras till specifika användare eller grupper av användare. Personer utanför gruppen har inte tillgång till programmet eller anslutningen. Därför, om alla i en grupp har behörighet att se all information i en databas, fungerar en implicit delningsmetod bra.

För ett exempel på implicit anslutningsanvändningsfall, överväg en avdelning som har en liten databas med projekt de spårar. Databasen kan innehålla information som avdelningsarbetsbiljetter eller företagskalender för hela företaget. I det här scenariot kan det uppmuntras att bygga fler appar ovanpå den implicit delade anslutningen så länge all information ska vara tillgänglig för alla användare som får åtkomst.

Appar skapade med Power Apps är utformade för att vara tillgängliga för slutanvändare. Denna typ av scenario är vanligt eftersom utvecklingskostnaden för implicita anslutningar är låg.

Avdelningsbaserade appar kan växa till företagsomfattande och verksamhetskritiska appar. I dessa scenarier är det viktigt att förstå att när en avdelningsapp flyttar för att vara företagsomfattande måste den ha traditionell företagssäkerhet inbyggd. Detta tillvägagångssätt är dyrare för appbyggande, men viktigt i företagsomfattande scenarier.

Klient- och serversäkerhet

Du kan inte lita på datasäkerheten genom filtrering eller andra klientsidåtgärder för att vara säker. Applikationer som kräver säker filtrering av data måste säkerställa att både användaridentifiering och filtrering sker på servern.

Använd tjänster som Microsoft Entra ID istället för att förlita sig på de filter som designats i apparna när det gäller användaridentitet och säkerhet. Den här konfigurationen säkerställer att serversidan fungerar som förväntat.

Följande illustrationer förklarar hur säkerhetsmönstren inom apparna skiljer sig mellan säkerhetsmodeller på klientsidan och serversidan.

I ett klientsäkerhetsappmönster,[1] användaren autentiserar endast applikationen på klientsidan. Sedan[2] ansökan begär information om tjänsten, och[3] tjänsten returnerar informationen enbart baserat på dataförfrågan.

I ett säkerhetsmönster på serversidan,[1] användaren autentiserar först till tjänsten så att användaren är känd för tjänsten. Sedan,[2] när ett samtal görs från applikationen, tjänsten[3] använder den kända identiteten för den nuvarande användaren för att filtrera data på lämpligt sätt och[4] returnerar data.

De implicita avdelningsdelningsscenarierna som beskrivs ovan är en kombination av dessa två mönster. Användaren måste logga in på Power Apps-tjänsten med Microsoft Entra-referenser. Detta beteende är serverns säkerhetsappmönster. Användaren är känd med hjälp av Microsoft Entra identitet på tjänsten. Därför är programmet begränsad till den uppsättning användare som Power Apps har formellt delat ansökan.

Den implicita delade anslutningen till SQL Server är dock klientens säkerhetsappmönster. SQL Server vet bara att ett specifikt användarnamn och lösenord används. Varje klientsidesfiltrering kan till exempel kringgås med en ny applikation med samma användarnamn och lösenord.

För att säkert filtrera data på serversidan använder du inbyggda säkerhetsfunktioner i SQL Server som radnivåsäkerhet för rader och neka behörigheter till specifika objekt (t.ex. kolumner) för specifika användare. Denna metod kommer att använda Microsoft Entra användaridentitet för att filtrera data på servern.

Vissa befintliga företagstjänster har använt ett tillvägagångssätt där användaridentiteten fångas i ett affärsdata lager på samma sätt som Microsoft Dataverse gör. I det här fallet kan affärslagret använda eller inte använda SQL Servers säkerhetsnivå på radnivå och neka funktioner direkt. Om den inte gör det är det ofta så att säkerheten aktiveras med lagrade procedurer eller vyer.

Affärslaget (på serversidan) använder en känd användare Microsoft Entra identitet för att åberopa en lagrad procedur som en SQL Server-princip och filtrera data. I alla fall, Power Apps ansluter för närvarande inte till lagrade procedurer. Ett affärslager kan också åberopa en vy som använder Microsoft Entra identitet som SQL Server-princip. Använd i så fall Power Apps för att ansluta till vyerna så att data filtreras på serversidan. Exponering av endast visningar för användare kan behöva Power Automate flöden för uppdateringar.

Se även

Översikt över anslutningar för arbetsyteappar