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

Dieser Artikel gilt für alle relationalen Datenbanken und implizite Verbindungen.

Unterschied zwischen expliziten und 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.

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
Windows-Authentifizierung	Implizit
Windows-Authentifizierung (nicht freigegeben)	Explizit

Implizite Risiken bei der gemeinsamen Nutzung von Verbindungen

Da sowohl die App als auch ihre Verbindungen für Endbenutzer bereitgestellt werden, bedeutet dies, dass Endbenutzer neue Anwendungen basierend auf diesen Verbindungen erstellen können.

Angenommen, Sie haben eine App erstellt, die die Daten herausgefiltert hat, die Benutzer nicht sehen sollen. Die herausgefilterten Daten sind in der Datenbank vorhanden. Sie verlassen sich jedoch auf den von Ihnen konfigurierten Filter, um sicherzustellen, dass die Endbenutzer bestimmte Daten nicht sehen.

Nachdem Sie diese App bereitgestellt haben, können Endbenutzer 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.

Wichtig

Sobald eine implizit freigegebene Verbindung für Endbenutzer 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 Endbenutzer erstellen. Die Endbenutzer haben alle Rechte, die die Authentifizierung als Teil einer implizit geteilten Verbindung zulässt.

Reale Verwendung von impliziter Verbindung

Es gibt gültige Anwendungsfälle sowohl für implizite als auch für explizite Authentifizierungsmethoden. Berücksichtigen Sie bei der Auswahl Ihres Ansatzes das Sicherheitsmodell und die einfache Entwicklung. Verwenden Sie in der Regel eine explizite Authentifizierungsmethode für alle Situationen, in denen Sie geschäftliche Anforderungen haben, bei denen Daten auf Zeilen‑ oder Spaltenbasis eingeschränkt werden müssen.

Als Beispiel für einen Anwendungsfall einer expliziten Verbindung stellen Sie sich einen Vertriebsleiter vor, der nur Preisrabatte oder Basiskostendaten anzeigen darf, die sich in derselben Tabelle befinden, in der ein anderer Vertriebsmitarbeiter Produkt und Preis sehen muss.

Möglicherweise müssen jedoch nicht alle Daten auf die gleiche Weise gesichert werden. Eine App wird freigegeben und für bestimmte Benutzer oder Benutzergruppen bereitgestellt. Personen außerhalb dieser Gruppe haben keinen Zugriff auf die App oder die Verbindung. Wenn also jeder in einer Gruppe berechtigt ist, alle Daten in einer Datenbank zu sehen, funktioniert eine implizite Methode der gemeinsamen Nutzung gut.

Als Beispiel für den Anwendungsfall einer impliziten Verbindung stellen Sie sich eine Abteilung vor, die über eine kleine Datenbank mit Projekten verfügt, die sie verfolgen. Die Datenbank kann Informationen wie etwa Abteilungsarbeitstickets oder einen Unternehmenskalender für das gesamte Unternehmen enthalten. In diesem Szenario kann das Erstellen weiterer Apps zusätzlich zu der implizit freigegebenen Verbindung gefördert werden, solange alle Daten für alle Benutzer zugänglich sein sollten, denen Zugriff gewährt wird.

Apps erstellt mit Power Apps sind so konzipiert, dass sie für Endbenutzer zugänglich sind. Diese Art von Szenario ist üblich, da die mit impliziten Verbindungen verbundenen Entwicklungskosten gering sind.

Abteilungsbasierte Apps können zu unternehmensweiten und geschäftskritischen Apps werden. In diesen Szenarien ist es wichtig zu verstehen, dass eine Abteilungs-App, die unternehmensweit eingesetzt wird, über eine integrierte traditionelle Unternehmenssicherheit verfügen muss. Dieser Ansatz ist für die App-Erstellung teurer, aber in unternehmensweiten Szenarien wichtig.

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.

Siehe auch

Übersicht über die Konnektoren für Canvas-Apps