Microsoft SQL Server sicher mit Power Apps verwenden
Es gibt verschiedene Möglichkeiten zum Verbinden und Authentifizieren bei SQL Servern mit Power Apps. In diesem Artikel werden Konzepte beschrieben, die bei der Auswahl einer Verbindung mit SQL Server mit einem Sicherheitsansatz hilfreich sein können, der den Anforderungen für Ihre App entspricht.
Wichtig
Das Feature Sichere implizite Verbindungen wurde im Januar 2024 veröffentlicht. Microsoft empfiehlt allen Apps, die derzeit implizite Verbindungen verwenden, dringend, auf sichere implizite Verbindungen umzusteigen und für Endbenutzende freigegebene Verbindungen zu widerrufen.
Unterschied zwischen expliziten, impliziten und sicheren impliziten Verbindungen
Eine Verbindung zu SQL Server wird immer dann hergestellt, wenn Sie eine App mit Power Apps Verbindung zum SQL-Server erstellen. Wenn solche Apps veröffentlicht und mit anderen geteilt werden, werden sowohl die App als auch die Verbindung für diese Benutzer bereitgestellt. Mit anderen Worten, die App und die Verbindung — beide sind für Benutzer sichtbar, mit denen die Apps geteilt werden.
Die für solche Verbindungen verwendete Authentifizierungsmethode kann explizit oder implizit sein. Wir können auch sagen, dass eine solche Verbindung explizit oder implizit geteilt wird.
- Eine explizit geteilte Verbindung bedeutet, dass sich der Endbenutzer der Anwendung mit seinen eigenen expliziten Anmeldeinformationen bei SQL Server authentifizieren muss. Normalerweise erfolgt diese Authentifizierung im Hintergrund als Teil von Microsoft Entra oder Windows-Authentifizierungs-Handshake. Der Benutzer merkt nicht einmal, wann die Authentifizierung stattfindet.
- Eine implizit geteilte Verbindung bedeutet, dass der Benutzer implizit die Anmeldeinformationen des Kontos verwendet, mit dem der App-Entwickler während der Erstellung der App eine Verbindung und Authentifizierung mit Datenquelle hergestellt hat. Die Anmeldeinformationen des Endbenutzers werden nicht zur Authentifizierung verwendet. Jedes Mal, wenn der Endbenutzer die App ausführt, verwendet er die Anmeldeinformationen, mit denen der Autor die App erstellt hat.
- Eine sichere implizit freigegebene Verbindung bezieht sich auf ein Szenario, in dem Endbenutzende der App implizit die Anmeldeinformationen des Kontos verwendet, mit dem die App-Entwicklungsfachkraft während der Erstellung der App eine Verbindung und Authentifizierung mit der Datenquelle hergestellt hat. Dies bedeutet, dass die eigenen Anmeldeinformationen der Endbenutzenden nicht zur Authentifizierung verwendet werden. Stattdessen verwenden die Endbenutzenden, wenn sie die App ausführen, die Anmeldeinformationen, die bei der Erstellung der App verwendet wurden. Es ist wichtig zu beachten, dass die Endbenutzenden keinen direkten Zugriff auf die Verbindung erhalten und die App nur den Zugriff auf eine begrenzte Anzahl von Aktionen und Tabellen ermöglicht.
Die folgenden vier Verbindungsauthentifizierungstypen können mit SQL Server verwendet werden für Power Apps:
| Authentifizierungstyp | Power Apps-Verbindungsmethode |
|---|---|
| Microsoft Entra Integriert | Explizit |
| SQL Server-Authentifizierung | Implizit/sicher implizit |
| Windows-Authentifizierung | Implizit/sicher implizit |
| Windows-Authentifizierung (nicht freigegeben) | Explizit |
Implizite Risiken bei der gemeinsamen Nutzung von Verbindungen
Alle neuen Anwendungen verwenden automatisch die neuen sicheren impliziten Verbindungen. Bei Apps, welche die älteren impliziten Verbindungen verwenden, werden jedoch sowohl die App als auch ihre Verbindungen für Endbenutzende bereitgestellt. Dies bedeutet, dass Endbenutzende neue Anwendungen basierend auf diesen Verbindungen erstellen können.
Wenn ein Autor sichere implizite Verbindungen verwendet, bedeutet dies, dass keine Verbindung freigegeben wird und Endbenutzende das Verbindungsobjekt nicht erhalten. Dadurch wird das Risiko eliminiert, dass Endbenutzende eine Verbindung zum Erstellen einer neuen App wiederverwenden. Stattdessen arbeitet die App mit einer Proxy-Verbindung, welche die App kennt und nur mit dieser bestimmten App kommuniziert. Die Proxy-Verbindung ermöglicht eingeschränkte Aktionen (Erstellen, Lesen, Aktualisieren, Löschen) und den Zugriff auf bestimmte Tabellen in der App, die bei der Veröffentlichung der App festgelegt werden. Den Endbenutzenden werden daher nur autorisierte Aktionen und Zugriffe gewährt.
Bei der einfachen impliziten Verbindung im älteren Stil wird tatsächlich ein Verbindungsobjekt an den Endbenutzenden weitergegeben. Wenn Sie zum Beispiel eine App erstellen, welche die Daten herausfiltert, die Benutzende nicht sehen sollen. Die herausgefilterten Daten sind jedoch in der Datenbank vorhanden. Sie verlassen sich jedoch auf den von Ihnen konfigurierten Filter, um sicherzustellen, dass die Endbenutzer bestimmte Daten nicht sehen.
Auch hier können bei älteren einfachen impliziten Verbindungen Endbenutzende, nachdem Sie die App bereitgestellt haben, die mit Ihrer App bereitgestellte Verbindung in allen neuen Apps verwenden, die sie erstellen. In den neuen Apps können Benutzer die Daten sehen, die Sie in Ihrer Anwendung herausgefiltert haben. Es ist wichtig, die neuen sicheren impliziten Verbindungen zu verwenden.
Wichtig
Sobald eine ältere implizit freigegebene Verbindung für Endbenutzende bereitgestellt wurde, gelten die Einschränkungen, die Sie möglicherweise in der von Ihnen freigegebenen App vorgenommen haben (z. B. Filter oder schreibgeschützter Zugriff), nicht mehr für neue Apps, die Endbenutzende erstellen. Die Endbenutzer haben alle Rechte, die die Authentifizierung als Teil einer implizit geteilten Verbindung zulässt. Wenn Sie eine App so konvertieren, dass sie sichere implizite Verbindungen verwendet, müssen Sie daher auch die Verbindungen widerrufen, die Sie mit Ihrer App freigegeben haben. Mit dem COE-Toolkit können Administrierende einen Bericht über Apps mit implizit freigegebenen Verbindungen erhalten.
Client‑ und Serversicherheit
Sie können sich nicht darauf verlassen, dass die Sicherheit von Daten durch Filterung oder andere clientseitige Vorgänge sicher ist. Anwendungen, die eine sichere Filterung von Daten erfordern, müssen sicherstellen, dass sowohl die Benutzeridentifikation als auch die Filterung auf dem Server erfolgt.
Nutzen Sie Dienste wie Microsoft Entra ID anstatt sich auf die in den Apps entwickelten Filter zu verlassen, wenn es um Benutzeridentität und ‑sicherheit geht. Diese Konfiguration stellt sicher, dass serverseitige Filter wie erwartet funktionieren.
Die folgenden Abbildungen erläutern, wie sich die Sicherheitsmuster innerhalb der Apps zwischen clientseitigen und serverseitigen Sicherheitsmodellen unterscheiden.
In einem Client-Sicherheits-App-Muster, [1] authentifiziert der Benutzer sich nur auf der Client-Seite gegenüber der Anwendung. Dann [2] fordert die Anwendung Informationen zum Dienst an, und [3] der Dienst gibt die Informationen ausschließlich aufgrund der Datenanfrage zurück.
In einem serverseitigen Sicherheitsmuster [1] authentifiziert der Benutzer sich zuerst beim Dienst, sodass der Benutzer dem Dienst bekannt ist. Dann [2] wenn ein Anruf von der Anwendung aus getätigt wird, nutzt der Dienst [3] die bekannte Identität des aktuellen Benutzers, um die Daten entsprechend zu filtern und [4] gibt die Daten zurück.
Die oben beschriebenen impliziten Szenarien für die gemeinsame Nutzung von Abteilungen sind eine Kombination dieser beiden Muster. Der Benutzer muss sich beim Power Apps-Dienst mit den Microsoft Entra-Anmeldeinformationen anmelden. Dieses Verhalten ist das Muster der Serversicherheits-App. Es ist bekannt, dass der Benutzer die Microsoft Entra-Identität für den Dienst verwendet. Daher ist die App auf die Benutzergruppe beschränkt, auf der Power Apps den Antrag offiziell geteilt hat.
Die implizite freigegebene Verbindung mit SQL Server ist jedoch das Muster der Clientsicherheits-App. SQL Server weiß nur, dass ein bestimmter Benutzername und ein bestimmtes Kennwort verwendet werden. Jede clientseitige Filterung kann beispielsweise mit einer neuen Anwendung mit demselben Benutzernamen und Kennwort umgangen werden.
Um Daten auf der Serverseite sicher zu filtern, verwenden Sie integrierte Sicherheitsfunktionen in SQL Server wie z. B. Sicherheit auf Zeilenebene für Reihen und die Ablehnung von Berechtigungen für bestimmte Objekte (z. B. Spalten) für bestimmte Benutzer. Dieser Ansatz verwendet die Microsoft Entra-Benutzeridentität, um die Daten auf dem Server zu filtern.
Einige bestehende Unternehmensdienste haben einen Ansatz verwendet, bei dem die Benutzeridentität in einer Geschäftsdatenschicht ähnlich erfasst wird wie von Microsoft Dataverse. In diesem Fall kann die Geschäftsschicht die Sicherheit auf Zeilenebene von SQL Server verwenden oder nicht und Funktionen direkt verweigern. Wenn dies nicht der Fall ist, wird die Sicherheit häufig mithilfe von gespeicherten Prozeduren oder Ansichten aktiviert.
Die Geschäftsschicht (auf der Serverseite) verwendet eine bekannte Benutzer-Microsoft Entra Identität, um eine gespeicherte Prozedur als SQL Server-Prinzipal aufzurufen und die Daten zu filtern. Power Apps stellt derzeit jedoch keine Verbindung zu gespeicherten Prozeduren her. Eine Geschäftsschicht kann auch eine Ansicht aufrufen, die die Microsoft Entra-Identität als SQL Server-Prinzipal aufruft. Verwenden Sie in diesem Fall Power Apps um eine Verbindung zu den Ansichten herzustellen, damit die Daten serverseitig gefiltert werden. Ansichten für Benutzer verfügbar zu machen benötigt möglicherweise Power Automate-Flows für Updates.