Gebruik Microsoft SQL Server veilig met Power Apps
Er zijn verschillende manieren om aan te sluiten en te authenticeren bij SQL Server met Power Apps. In dit artikel worden concepten beschreven die handig kunnen zijn bij het maken van een keuze over hoe u verbinding maakt met SQL Server met een beveiligingsbenadering die overeenkomt met de vereisten voor uw app.
Belangrijk
De functie beveiligde impliciete verbindingen werd uitgebracht in januari 2024. Microsoft moedigt alle apps die momenteel impliciete verbindingen gebruiken ten zeerste aan om te converteren naar beveiligde impliciete verbindingen, en om verbindingen die met eindgebruikers worden gedeeld in te trekken.
Verschil tussen expliciete, impliciete en veilige impliciete verbindingen
Er wordt een verbinding met SQL Server gemaakt wanneer u een app maakt met Power Apps verbinding maken met SQL Server. Wanneer dergelijke apps worden gepubliceerd en gedeeld met anderen, worden zowel de app als de verbinding voor die gebruikers geïmplementeerd. Met andere woorden, de app en de verbinding—beide zijn zichtbaar voor gebruikers met wie de apps worden gedeeld.
De verificatiemethode die voor dergelijke verbindingen wordt gebruikt, kan zijn: expliciet of impliciet. We kunnen ook zeggen dat een dergelijke verbinding expliciet of impliciet wordt gedeeld.
- Een expliciet gedeelde verbinding betekent dat de eindgebruiker van de toepassing zich moet authenticeren bij SQL Server met zijn eigen expliciete referenties. Meestal gebeurt deze authenticatie achter de schermen als onderdeel van Microsoft Entra of Windows-verificatiehandshake. De gebruiker merkt niet eens wanneer de authenticatie plaatsvindt.
- Een impliciet gedeelde verbinding betekent dat de gebruiker impliciet de inloggegevens gebruikt van het account dat de app-maker heeft gebruikt om verbinding te maken en te authenticeren met de gegevensbron tijdens het maken van de app. De inloggegevens van de eindgebruiker worden niet gebruikt om te verifiëren. Elke keer dat de eindgebruiker de app uitvoert, gebruiken ze de inloggegevens waarmee de auteur de app heeft gemaakt.
- Een veilige impliciet gedeelde verbinding verwijst naar een scenario waarbij de eindgebruiker van de app impliciet gebruikmaakt van de inloggegevens van het account dat de app-maker heeft gebruikt om verbinding te maken en te authenticeren met de gegevensbron tijdens het maken van de app. Dit betekent dat de eigen inloggegevens van de eindgebruiker niet worden gebruikt voor verificatie. Wanneer de gebruiker de app uitvoert, gebruikt deze in plaats daarvan de inloggegevens waarmee de auteur van de app deze heeft gemaakt. Belangrijk om te weten is dat de eindgebruiker geen directe toegang krijgt tot de verbinding, en dat de app slechts toegang geeft tot een beperkt aantal acties en tabellen.
De volgende vier verbindingsverificatietypes kunnen worden gebruikt met SQL Server voor: Power Apps:
| Verificatietype | Power Apps-verbindingenmethode |
|---|---|
| Geïntegreerd Microsoft Entra | Expliciet |
| SQL-serververificatie | Impliciet/veilig impliciet |
| Windows-verificatie | Impliciet/veilig impliciet |
| Windows-verficiatie (niet gedeeld) | Expliciet |
Impliciete risico's voor het delen van verbindingen
Alle nieuwe toepassingen maken automatisch gebruik van de nieuwe veilige impliciete verbindingen. Bij apps die gebruik maken van de oudere ‘impliciete verbindingen’ worden zowel de app als de verbindingen daarvan echter ingezet bij eindgebruikers, wat betekent dat eindgebruikers nieuwe applicaties kunnen maken op basis van die verbindingen.
Wanneer een auteur beveiligde impliciete verbindingen gebruikt, betekent dit dat er geen verbinding wordt gedeeld, en dat geen enkele eindgebruiker het verbindingsobject ontvangt. Dit elimineert het risico dat een eindgebruiker-auteur een verbinding opnieuw gebruikt om een nieuwe app te maken. In plaats daarvan werkt de app met een proxyverbinding die op de hoogte is van de app en alleen met die specifieke app communiceert. De proxyverbinding maakt beperkte acties mogelijk (maken, lezen, bijwerken, verwijderen) en toegang tot specifieke tabellen in de app die worden gedefinieerd wanneer de app wordt gepubliceerd. Daarom worden alleen geautoriseerde acties en toegang verleend aan de eindgebruiker.
De eenvoudige impliciete verbinding in oudere stijl distribueert feitelijk een verbindingsobject naar de eindgebruiker. Als u bijvoorbeeld een app maakt die de gegevens eruit filtert waarvan u niet wilt dat gebruikers deze zien. De uitgefilterde gegevens zijn echter aanwezig in de database. Maar u vertrouwt op het filter dat u hebt geconfigureerd om ervoor te zorgen dat de eindgebruikers bepaalde gegevens niet te zien krijgen.
Nogmaals, bij eenvoudige impliciete verbindingen in oudere stijl kunnen eindgebruikers, nadat u de app heeft geïmplementeerd, de verbinding gebruiken die met uw app is geïmplementeerd in alle nieuwe apps die ze maken. In de nieuwe apps kunnen gebruikers de gegevens zien die u in uw toepassing heeft uitgefilterd. Het is belangrijk om de nieuwe veilige impliciete verbindingen te gebruiken.
Belangrijk
Zodra een oudere, impliciet gedeelde verbinding is geïmplementeerd voor eindgebruikers, zijn de beperkingen die u mogelijk heeft gesteld in de app die u hebt gedeeld (zoals filters of alleen-lezen toegang) niet langer geldig voor nieuwe apps die eindgebruikers maken. De eindgebruikers hebben alle rechten die de authenticatie toestaat als onderdeel van een impliciet gedeelde verbinding. Wanneer u een app converteert om veilige impliciete verbindingen te gebruiken, moet u daarom ook de verbindingen intrekken die u met uw app hebt gedeeld. Beheerders kunnen met de met de COE-toolkit een rapport opvragen van apps met impliciet gedeelde verbindingen.
Client- en serverbeveiliging
U kunt niet vertrouwen op de beveiliging van gegevens door middel van filtering of andere bewerkingen aan de clientzijde om veilig te zijn. Toepassingen die een veilige filtering van gegevens vereisen, moeten ervoor zorgen dat zowel de gebruikersidentificatie als de filtering op de server plaatsvindt.
Gebruik diensten zoals: Microsoft Entra ID in plaats van te vertrouwen op de filters die in de apps zijn ontworpen als het gaat om gebruikersidentiteit en beveiliging. Deze configuratie zorgt ervoor dat de filters aan de serverzijde werken zoals verwacht.
In de volgende afbeeldingen wordt uitgelegd hoe de beveiligingspatronen binnen de apps verschillen tussen beveiligingsmodellen aan de clientzijde en aan de serverzijde.
In een app-patroon voor clientbeveiliging, [1] de gebruiker authenticeert zich alleen bij de toepassing aan de clientzijde. Dan [2] de applicatie vraagt om informatie over de dienst, en [3] de service retourneert de informatie uitsluitend op basis van het gegevensverzoek.
In een server-side beveiligingspatroon, [1] de gebruiker authenticeert zich eerst bij de service, zodat de gebruiker bekend is bij de service. Dan, [2] wanneer een oproep wordt gedaan vanuit de applicatie, de service [3] gebruikt de bekende identiteit van de huidige gebruiker om de gegevens op de juiste manier te filteren en [4] geeft de gegevens terug.
De hierboven beschreven impliciete scenario's voor het delen van afdelingen zijn een combinatie van deze twee patronen. De gebruiker moet zich aanmelden bij de Power Apps-service met Microsoft Entra-referenties. Dit gedrag is het patroon van de serverbeveiligingsapp. De gebruiker is bekend met behulp van de Microsoft Entra-identiteit op de service. Daarom is de app beperkt tot de groep gebruikers waarvoor: Power Apps heeft de aanvraag formeel gedeeld.
De impliciete gedeelde verbinding met SQL Server is echter het patroon van de clientbeveiligingsapp. SQL Server weet alleen dat er een specifieke gebruikersnaam en wachtwoord wordt gebruikt. Elke client-side filtering kan bijvoorbeeld worden omzeild met een nieuwe applicatie die dezelfde gebruikersnaam en hetzelfde wachtwoord gebruikt.
Om gegevens aan de serverzijde veilig te filteren, gebruikt u ingebouwde beveiligingsfuncties in SQL Server zoals: beveiliging op rijniveau voor rijen, en de ontkennen machtigingen voor specifieke objecten (zoals kolommen) voor specifieke gebruikers. Deze aanpak maakt gebruik van de Microsoft Entra-gebruikersidentiteit om de gegevens op de server te filteren.
Sommige bestaande bedrijfsservices hebben een benadering gebruikt waarbij de gebruikersidentiteit wordt vastgelegd in een bedrijfsgegevenslaag, ongeveer op dezelfde manier als Microsoft Dataverse dat doet. In dit geval kan de bedrijfslaag de beveiliging op rijniveau van SQL Server al dan niet gebruiken en functies direct weigeren. Als dit niet het geval is, is het vaak zo dat de beveiliging is ingeschakeld met behulp van opgeslagen procedures of weergaven.
De bedrijfslaag (aan de serverkant) gebruikt een bekende gebruiker Microsoft Entra identiteit om een opgeslagen procedure aan te roepen als een SQL Server-principal en de gegevens te filteren. Echter, Power Apps maakt momenteel geen verbinding met opgeslagen procedures. Een bedrijfslaag kan ook een weergave oproepen die gebruikmaakt van de Microsoft Entra identiteit als een SQL Server-principal. Gebruik in dit geval Power Apps om verbinding te maken met de weergaven, zodat de gegevens aan de serverzijde worden gefilterd. Het kan nodig zijn om alleen weergaven aan gebruikers te tonen: Power Automate stromen voor updates.