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.

Skillnad mellan explicita, implicita och säkra implicita anslutningar

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.
• En säker implicit delad anslutning hänvisar till ett scenario där slutanvändaren av appen 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. Detta innebär att slutanvändarens egna referenser inte används för att autentisera. Istället, när användaren kör appen, använder de de autentiseringsuppgifter som författaren till appen skapade den med. Det är viktigt att notera att slutanvändaren inte har direkt åtkomst till anslutningen och att appen endast tillåter åtkomst till en begränsad uppsättning åtgärder och tabeller.

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

Implicita risker för anslutningsdelning

För alla nya program används automatiskt de nya säkra anslutningarna. Men med appar som använder de äldre "implicita anslutningarna", både programmet och dess anslutningar distribueras för slutanvändare betyder det att slutanvändare kan skapa nya applikationer baserat på dessa anslutningar.

Om en författare använder säkra implicita anslutningar innebär det att ingen anslutning delas och att inga slutanvändare tar emot anslutningsobjektet. Detta eliminerar risken för att en slutanvändarförfattare återanvänder en anslutning för att skapa en ny app. Appen fungerar i stället med en proxyanslutning som känner till appen och som bara kommunicerar med den specifika appen. Proxyanslutningen tillåter begränsade åtgärder (skapa, läsa, uppdatera, ta bort) och åtkomst till specifika tabeller i appen som definieras när appen publiceras. Därför ges endast auktoriserade åtgärder och åtkomst till slutanvändaren.

Den äldre enkla och enkla anslutningen distribuerar egentligen ett anslutningsobjekt till slutanvändaren. Till exempel, om du skapar en app som filtrerar bort data som du inte vill att användarna ska se. Men 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.

Återigen, med enkla implicita anslutningar i äldre stil, efter att du har implementerat appen 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. Det är viktigt att du använder de nya säkra anslutningarna.

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