Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Es gibt verschiedene Möglichkeiten zum Herstellen einer Verbindung und Authentifizierung bei SQL Server mit Power Apps. In diesem Artikel werden Konzepte beschrieben, die hilfreich sein können, um eine Entscheidung darüber zu treffen, wie Sie eine Verbindung mit SQL Server herstellen, mit einem Sicherheitsansatz, der den Anforderungen ihrer App entspricht.
Von Bedeutung
Das Feature für sichere implizite Verbindungen wurde im Januar 2024 veröffentlicht. Microsoft empfiehlt dringend allen Apps, die derzeit implizite Verbindungen verwenden, um zu sicheren impliziten Verbindungen zu konvertieren und Verbindungen zu widerrufen, die für Endbenutzer freigegeben wurden.
Unterschied zwischen expliziten, impliziten und sicheren impliziten Verbindungen
Eine Verbindung mit SQL Server wird immer dann erstellt, wenn Sie eine App mit Power Apps erstellen, die eine Verbindung mit SQL Server herstellt. Wenn solche Apps veröffentlicht und für andere freigegeben 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, für die die Apps freigegeben werden.
Die für solche Verbindungen verwendete Authentifizierungsmethode kann explizit oder implizit sein. Wir können auch sagen, dass diese Verbindung explizit oder implizit freigegeben wird.
- Eine explizit freigegebene Verbindung bedeutet, dass sich der Endbenutzer der Anwendung mit eigenen expliziten Anmeldeinformationen bei SQL Server authentifizieren muss. In der Regel erfolgt diese Authentifizierung im Hintergrund als Teil von Microsoft Entra oder Windows-Authentifizierungs-Handshake. Der Benutzer bemerkt nicht einmal, wann die Authentifizierung erfolgt.
- Eine implizit freigegebene Verbindung bedeutet, dass der Benutzer implizit die Anmeldeinformationen des Kontos verwendet, das der App-Hersteller zum Herstellen einer Verbindung und Authentifizierung mit der Datenquelle während der Erstellung der App verwendet 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 der Endbenutzer der App implizit die Anmeldeinformationen des Kontos verwendet, mit dem der App-Hersteller beim Erstellen der App eine Verbindung mit der Datenquelle herstellt und authentifiziert hat. Dies bedeutet, dass die eigenen Anmeldeinformationen des Endbenutzers nicht zur Authentifizierung verwendet werden. Wenn der Benutzer die App ausführt, verwenden sie stattdessen die Anmeldeinformationen, mit denen der Autor der App sie erstellt hat. Es ist wichtig zu beachten, dass der Endbenutzer keinen direkten Zugriff auf die Verbindung erhält, und die App ermöglicht nur den Zugriff auf eine begrenzte Gruppe von Aktionen und Tabellen.
Die folgenden vier Verbindungsauthentifizierungstypen können mit SQL Server für Power Apps verwendet werden:
| Authentifizierungstyp | Power Apps-Verbindungsmethode |
|---|---|
| Microsoft Entra Integriert | Explicit |
| SQL Server-Authentifizierung | Implizit/implizit sicher |
| Windows-Authentifizierung | Implizit/implizit sicher |
| Windows-Authentifizierung (nicht teilend) | Explicit |
Implizite Verbindungsfreigaberisiken
Alle neuen Anwendungen verwenden automatisch die neuen sicheren impliziten Verbindungen. Bei Apps, die die älteren impliziten Verbindungen verwenden, werden jedoch sowohl die App als auch ihre Verbindungen für Endbenutzer bereitgestellt, bedeutet dies, dass Endbenutzer neue Anwendungen basierend auf diesen Verbindungen erstellen können.
Wenn ein Autor sichere implizite Verbindungen verwendet, bedeutet dies, dass keine Verbindung freigegeben wird und kein Endbenutzer das Verbindungsobjekt empfängt. Dadurch wird das Risiko verhindert, dass ein Endbenutzerautor eine Verbindung zum Erstellen einer neuen App wiederverwenden kann. Stattdessen funktioniert die App mit einer Proxyverbindung, die der App bekannt ist und nur mit dieser bestimmten App kommuniziert. Die Proxyverbindung ermöglicht eingeschränkte Aktionen (Erstellen, Lesen, Aktualisieren, Löschen) und Zugriff auf bestimmte Tabellen in der App, die beim Veröffentlichen der App definiert sind. Daher werden nur autorisierte Aktionen und Der Zugriff auf den Endbenutzer gewährt.
Die einfache implizite Verbindung im älteren Stil verteilt tatsächlich ein Verbindungsobjekt an den Endbenutzer. Wenn Sie beispielsweise eine App erstellen, die die Daten herausfiltert, die benutzern nicht angezeigt werden sollen. Die gefilterten 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.
Mit einfachen impliziten Verbindungen im älteren Stil können Endbenutzer nach der Bereitstellung der App 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.
Von Bedeutung
Sobald eine ältere implizit freigegebene Verbindung für Endbenutzer bereitgestellt wurde, gelten die Einschränkungen, die Sie möglicherweise in der freigegebenen App (z. B. Filter oder schreibgeschützten Zugriff) für neue Apps-Endbenutzer erstellt haben. Die Endbenutzer haben alle Rechte, die die Authentifizierung als Teil der implizit freigegebenen Verbindung zulässt. Daher müssen Sie beim Konvertieren einer App zur Verwendung sicherer impliziter Verbindungen auch die Verbindungen widerrufen, die Sie für Ihre App freigegeben haben. Administratoren können einen Bericht von Apps mit implizit freigegebenen Verbindungen mit dem COE-Toolkit abrufen.
Client- und Serversicherheit
Sie können sich nicht auf die Sicherheit von Daten verlassen, indem Sie Filterung oder andere clientseitige Vorgänge verwenden, um sicher zu sein. Anwendungen, die eine sichere Filterung von Daten erfordern, müssen sicherstellen, dass sowohl die Benutzeridentifikation als auch die Filterung auf dem Server erfolgt.
Verwenden Sie Dienste wie Microsoft Entra ID, anstatt sich auf die Filter zu verlassen, die in den Apps entwickelt wurden, wenn es um Benutzeridentität und Sicherheit geht. Diese Konfiguration stellt sicher, dass serverseitige Filter erwartungsgemäß funktionieren.
In den folgenden Abbildungen wird erläutert, wie sich die Sicherheitsmuster innerhalb der Apps zwischen clientseitigen und serverseitigen Sicherheitsmodellen unterscheiden.
[1] In einem Clientsicherheits-App-Muster authentifiziert sich der Benutzer nur bei der Anwendung auf clientseitiger Seite. Dann [2] fordert die Anwendung Informationen des Diensts an, und [3] der Dienst gibt die Informationen ausschließlich basierend auf der Datenanforderung zurück.
[1] In einem serverseitigen Sicherheitsmuster authentifiziert sich der Benutzer zuerst beim Dienst, damit der Benutzer dem Dienst bekannt ist. [2] wenn ein Aufruf aus der Anwendung erfolgt, verwendet 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 szenarien für die implizite Abteilungsfreigabe sind eine Kombination dieser beiden Muster. Der Benutzer muss sich mit Microsoft Entra-Anmeldeinformationen beim Power Apps-Dienst anmelden. Dieses Verhalten ist das Serversicherheits-App-Muster. Der Benutzer ist bekannt, indem er die Microsoft Entra-Identität für den Dienst verwendet. Daher ist die App auf die Benutzergruppe beschränkt, für die Power Apps die Anwendung formell freigegeben hat.
Die implizite freigegebene Verbindung mit SQL Server ist jedoch das Clientsicherheits-App-Muster. SQL Server weiß nur, dass ein bestimmter Benutzername und ein bestimmtes Kennwort verwendet werden. Jede clientseitige Filterung kann z. B. mit einer neuen Anwendung mit demselben Benutzernamen und Kennwort umgangen werden.
Um Daten auf Serverseite sicher zu filtern, verwenden Sie integrierte Sicherheitsfeatures in SQL Server, z. B. Zeilenebenensicherheit für Zeilen, und die Berechtigungen für bestimmte Objekte (z. B. Spalten) für bestimmte Benutzer. Bei diesem Ansatz wird die Microsoft Entra-Benutzeridentität verwendet, um die Daten auf dem Server zu filtern.
Einige vorhandene Unternehmensdienste haben einen Ansatz verwendet, bei dem die Benutzeridentität in einer Geschäftsdatenebene auf die gleiche Weise erfasst wird wie Microsoft Dataverse. In diesem Fall kann die Geschäftsebene die Sicherheit auf Zeilenebene von SQL Server verwenden und Features direkt verweigern. Wenn dies nicht der Fall ist, ist es häufig der Fall, dass die Sicherheit mithilfe gespeicherter Prozeduren oder Ansichten aktiviert ist.
Auf der Geschäftsebene (auf der Serverseite) wird eine bekannte Microsoft Entra-Identität verwendet, um eine gespeicherte Prozedur als SQL Server-Prinzipal aufzurufen und die Daten zu filtern. Power Apps stellt derzeit jedoch keine Verbindung mit gespeicherten Prozeduren her. Eine Geschäftsebene kann auch eine Ansicht aufrufen, die die Microsoft Entra-Identität als SQL Server-Prinzipal verwendet. Verwenden Sie in diesem Fall Power Apps, um eine Verbindung mit den Ansichten herzustellen, sodass die Daten auf der Serverseite gefiltert werden. Das Verfügbarmachen von Ansichten für Benutzer benötigt möglicherweise Power Automate-Flüsse für Updates.