Vorherige

Nächste

Zugriff auf Dataverse

Abgeschlossen

Daten sind immer als wertvolles Gut zu betrachten. Daher ist es beim Sicherheitsentwurf Sicht wichtig, ein Sicherheitsmodell zu entwerfen, das die ordnungsgemäße Verwendung dieses wertvollen Guts und den Zugriff darauf sicherstellt. In Microsoft Dataverse werden Daten für Microsoft Power Platform gespeichert und Dienste für Apps angeboten. Microsoft Power Platform zeichnet sich durch mehrschichtige Sicherheitsmechanismen aus, um den Zugriff auf die Dataverse-Umgebung zu regulieren. Sobald Benutzer aber auf die Umgebung zugreifen können, muss der Lösungsarchitekt den Zugriff innerhalb der Datenbank regeln. Eines der Hauptmerkmale von Dataverse ist das umfassende Sicherheitsmodell, das an viele verschiedene Geschäftsszenarien angepasst werden kann.

Autorisierung

Bei der Autorisierung werden Ressourcen Zugriffsrechte, das heißt, Berechtigungen, zugewiesen. Die Sicherheitsplanung sieht für den Zugriff auf Daten und Funktionen eine Autorisierung vor. Die Entscheidung, wer auf welche Daten und welche Dienste zugreifen kann, ist ein wesentlicher Bestandteil des Lösungsentwurfs.

Ein unangemessenes Sicherheitsmodell kann zu einem schlechten Systementwurf führen, was weitreichende Folgen und teure Reparaturen nach sich ziehen kann:

• Verwaltbarkeit – Schwierigkeiten bei der Verwaltung des individuellen Zugriffs
• Leistung – Beispielsweise vergrößert sich die PrincipalAccessObject-Tabelle (POA-Tabelle) bei der Freigabe
• Anwenderfreundlichkeit – Umständliche Verfahren zur Zugriffsvergabe
• Transparenz – Anhand des Datensatzes ist nicht ersichtlich, wer Zugriff darauf hat

Jede Lösung hat spezielle Anforderungen, aber gängige Funktionen und Muster können ermittelt und wiederverwendet werden.

Gängige Muster

Im Folgenden sind einige gängige Verwendungsmuster aus diversen Geschäftsanwendungen aufgeführt:

• Aktives Engagement – regelmäßiges und spürbares Engagement mit dem Kunden bzw. Handhabung von Daten Sachkundig und mit Vorwissen über den Kunden/die Daten und die damit verbundenen Aktionen. Persönliche Handlungen beruhen auf einer direkten Beziehung zu den beteiligten Personen.
• Sekundäres Engagement – sachkundiges Engagement, Pflege von aktivem Wissen über Aktivitäten, aber keine direkte Teilnahme oder Arbeit mit den Daten bzw. mit dem Kunden, wie z. B. Vertretung bei Abwesenheit aktiv involvierter Mitarbeiter Unterstützung anderer, die eine persönliche Beziehung zum Kunden haben, z. B. Beratung oder Unterstützung der aktiv beteiligten Personen, Unterstützung durch Fachwissen über bestimmte Daten oder Kunden
• Interaktion mit Transaktionen – spezifisches aktivitätsorientiertes Engagement, z. B. Entgegennahme und Abwicklung von Anfragen zur Änderung von Kundenadressen Kein persönliches oder laufendes Engagement, wie in einem Callcenter
• Aufsicht als Vorgesetzter – Management‑ oder Governance-Verantwortung in einem Unternehmen oder einer Region Beobachtung und Lenkung des Engagements anderer anstelle einer spezifischen Beteiligung
• Berichterstellung – Erstellung aggregierter Geschäftsberichte Daten werden so präsentiert, dass die Anonymität gewahrt bleibt und kein direkter Zugriff auf Kunden/Abschlüsse möglich ist.
• Konformität – nur Lesezugriff auf alle Datensätze eines Geschäftsbereichs zur Kontrolle

Der Lösungsarchitekt muss beim Sicherheitsentwurf verstehen, wie die Benutzer arbeiten. Sie müssen feststellen, ob Benutzer alleine, als Teil eines statischen Teams oder in dynamischen Teams arbeiten, die sich aufgrund bestimmter Regeln ändern. All diese Faktoren haben Einfluss auf das Sicherheitsmodell. Lösungsarchitekten müssen nach der Bestimmung dieser Faktoren außerdem wissen, wie andere Mitarbeiter dazu beitragen. Beispielsweise sollte der Lösungsarchitekt nachfragen, ob die Benutzer Supportmitarbeiter zugewiesen haben und ob die Supportmitarbeiter für andere Benutzer gemeinsam zuständig sind. Darüber hinaus sollte sich der Lösungsarchitekt erkundigen, was passiert, wenn keine Supportmitarbeiter verfügbar sind, was über Nacht und an Wochenenden passiert und wie die Aufsicht gehandhabt wird.

Entwurfsprinzipien

Beim Sicherheitsentwurf müssen Lösungsarchitekten bestimmte Prinzipien befolgen:

• Eine zugewiesene Verantwortlichkeit geht nicht immer mit einem eingeschränkten Zugriff einher.
• Ausnahmen sollten als solche gehandhabt werden. Bevorzugen Sie die gängigen Zugriffsmuster.
• Der Zugriff auf einen Datensatz, bei dem Sie Zugriff auf eine darin enthaltene größere Datenmenge gewährt haben, kann nicht widerrufen werden.
• Geschäftsbereiche dienen zur Verwaltung und Eindämmung, nicht zur Zuordnung der Organisationsstruktur.
• Der Entwurf sollte möglichst einfach und effizient sein und die Anforderungen erfüllen.

Hinweis

Gelegentlich stimmt die Organisationsstruktur mit der erforderlichen Sicherheitsstruktur überein. Dies ist jedoch selten. Greifen Sie bei der Planung des Sicherheitsmodells nicht nur auf die Organisationsstruktur als Standard zurück.

Sicherheitsfunktionen

Dataverse hat viele Sicherheitsfunktionen für den Zugriff auf Daten:

• Zuständigkeit für Tabellen
• Benutzer
• Teams
• Konzernmandanten
• Sicherheitsrollen
• Freigabe
• Microsoft Entra ID-Sicherheitsgruppen
• Sicherheit auf Spaltenebene
• Hierarchische Sicherheit
• Überwachung

Lösungsarchitekten müssen mit allen dieser Funktionen vertraut sein und wissen, wie diese kombiniert werden, um das Sicherheitsmodell für seine Lösung zu entwickeln. In dieser Lerneinheit wird nicht auf die einzelnen Sicherheitsfunktionen eingegangen. Vielmehr wird erläutert, wie sich damit im Zusammenspiel ein Sicherheitsmodell für die Lösung entwerfen lässt.

Zuständigkeit für Tabellen

Für Tabellen in Dataverse kann entweder ein Benutzer oder Team oder die Organisation zuständig sein. Tabellen, für die ein Benutzer oder Team zuständig ist, haben ein Besitzerfeld, und jeder Tabellenzeile kann ein Besitzer zugewiesen werden. Anhand des Besitzers einer Zeile und der anderen Sicherheitsfunktionen wird bestimmt, wer Zugriff auf die Zeile hat. Der Zugriff auf Zeilen ist differenziert und kann horizontal unterteilt werden. Andererseits kann der Zugriff auf einzelne Zeilen von Tabellen, für die die Organisation zuständig ist, wahlweise auch nicht eingeschränkt werden, und Benutzer haben Zugriff auf alle oder keine Datensätze.

Hinweis

Nach dem Erstellen einer Tabelle können Sie die Besitzoption nicht mehr ändern. Geben Sie im Zweifelsfall bei der Erstellung von Tabellen den Benutzer-/Team-Typ an.

Teams

Teams ist eine Gruppe von Benutzern. Mit ihm können Benutzer auf Daten zugreifen. Mit Teams lassen sich Benutzern Berechtigungen pauschal zuweisen, ohne den Zugriff auf Ebene der einzelnen Benutzer minutiös verwalten zu müssen. Benutzer können mehreren Teams angehören.

Die drei Teamtypen sind:

• Besitzer – Besitzerteams können Zeilen besitzen, mit denen jedes Teammitglied direkten Zugriff auf diese Zeile erhält.
• Zugriff – Mit dieser Methode können Benutzer eine Zeile aus einem Formular heraus problemlos an andere Benutzer freigeben.
• Microsoft Entra ID-Gruppe – ist mit Besitzerteams vergleichbar, allerdings wird die Mitgliedschaft im Team in Microsoft Entra ID geregelt.

Sicherheitsrollen

Sicherheitsrollen bilden das Fundament der Datensicherheit in Dataverse. Anstelle Benutzern bestimmte Rechte zu gewähren, erstellen Sie Sicherheitsrollen. Zur Bündelung von Berechtigungen in einer Sammlung basiert die Sicherheit in Dataverse auf Rollen.

Sicherheitsrollen können Benutzern oder Teams zugewiesen werden. Teams und Benutzer können Sicherheitsrollen mit Pauschalberechtigungen haben

Wichtig

Die gewährten Rechte summieren sich, wobei der größte Zugriffsumfang maßgeblich ist. Wenn Sie auf breiter Ebene im Unternehmen Lesezugriff auf alle Kontaktdatensätze gewährt haben, können Sie keinen einzigen Datensatz hiervon ausnehmen.

Konzernmandanten

Konzernmandanten bestehen aus Benutzern und Teams und fungieren als Sicherheitsgrenzen. Sie dienen hauptsächlich zur Steuerung des Zugriffs auf Teilmengen von Daten innerhalb einer Tabelle, das heißt, der horizontalen Unterteilung von Daten. Benutzer und deren Daten können durch Konzernmandanten segmentiert werden.

Jede Dataverse-Datenbank hat einen einzelnen Stammkonzernmandanten. Um Benutzergruppen streng hierarchisch anzuordnen, können Sie untergeordnete Konzernmandanten erstellen.

Hinweis

Konzernmandanten haben ein Standardteam, dem alle Benutzer in dieser Einheit angehören. Sie können Benutzer nicht manuell zu Standardteams hinzufügen oder daraus löschen. Es kann also passieren, dass Benutzer bei fortschreitender Lösungsentwicklung in einigen Fällen die Weiterentwicklung blockieren.

Wichtig

Die Kombination aus Sicherheitsrollen und Konzernmandanten bildet die Grundlage des Sicherheitsmodells von Dataverse.

Mit Konzernmandanten lassen sich viele Benutzer und der Zugriff auf Datensätze effizient verwalten. Anwendungsbenutzer können sie nicht sehen, wohl aber Administratoren. Spiegeln Sie nicht einfach das Organigramm eines Unternehmens wider, sondern gestalten Sie die Hierarchie der Konzernmandanten entsprechend den Sicherheitsanforderungen. Bei diesem Ansatz kann es mitunter erforderlich sein, zum Zweck der Erfüllung von Sicherheitsanforderungen Konzernmandanten zu erstellen, wie beispielsweise einen Konzernmandanten, der dem Vertrieb und Marketing übergeordnet ist, damit einige Benutzer auf diese zugreifen können, nicht aber auf den Betrieb.

Zeilen freigeben

Einzelne Zeilen können an Benutzer und Teams freigegeben werden. So können Benutzer mit dieser Funktion auf Datensätze zugreifen, die durch das von den Konzernmandanten generierte Sicherheitsmodell eingeschränkt sind. Durch eine Freigabe sind Zeilen auch außerhalb der strengen Hierarchie der Konzernmandanten zugänglich.

Sicherheitsrollen und Teams

Sicherheitsrollen können Teams zugewiesen werden. Dem Team können dann Benutzer zugeordnet werden, damit alle Teammitglieder von der Rolle profitieren. Die Benutzer haben Zugriff auf die Zeilen, für die das Team verantwortlich zeichnet, und können in Abhängigkeit der anderen Sicherheitsfunktionen Zugriff auf Zeilen haben, die anderen Benutzern im Team gehören.

Im Folgenden sind Optionen aufgeführt, die steuern, wie die Sicherheitsrolle im Zusammenhang mit einem Team funktioniert:

• Standard: nur Teamrechte
• Direkte Benutzerzugriffsebene (Basic) und Teamrechte

Bei Verwendung von Direkter Benutzer werden Berechtigungen so behandelt, als wären sie dem Benutzer direkt zugewiesen worden. Damit müssen Sie Benutzern keine Sicherheitsrollen zuweisen, sondern nutzen nur Teams und diesen zugewiesene Sicherheitsrollen.

Hinweis

Besitzerteams gehören zu Konzernmandanten. Ein Benutzer kann jeweils nur einem Konzernmandanten angehören, kann aber in einem Team aus einem anderen Konzernmandant ergänzt werden. Mit dieser Funktion können Benutzer auf Daten in einem Konzernmandanten zugreifen, der sich nicht in ihrer Hierarchie befindet.

Sicherheit auf Spaltenebene

Die mit einer Sicherheitsrolle verbundenen Rechte gelten auf Zeilenebene. Darf ein Benutzer eine Zeile aktualisieren, darf er auch alle Spalten darin aktualisieren. Manchmal ist die Zugriffskontrolle auf Zeilenebene nicht ausreichend, wie z. B. bei Spalten mit personenbezogenen Daten. In Dataverse gibt es eine Sicherheitsfunktion auf Spaltenebene, um so die Sicherheit zu verbessern.

Die Sicherheit auf Spaltenebene ist von Sicherheitsrollen unabhängig. Sicherheitsprofile für Spalten geben die Lese-/Schreibrechte in Zusammenhang mit den Spalten vor und werden Benutzern und Teams zugewiesen.

Hinweis

Ist ein Benutzer nicht berechtigt, eine gesicherte Spalte zu lesen, kann er die Spalte im Formular zwar weiterhin sehen, nicht aber deren Inhalt, das heißt, die Datenwerte. Wird mithilfe von Code auf gesicherte Felder zugegriffen und der Benutzer hat keine Leseberechtigung, lautet der Wert null.

Hierarchische Sicherheit

Eines der Probleme von Konzernmandanten ist deren strenge Hierarchie. Der Zugriff auf Daten erfolgt nur gemäß der Hierarchie der Konzernmandanten. Im Diagramm der Konzernmandanten kann ein Benutzer in Sales Zugriff auf die Konzernmandanten „Nord“, „Zentral“ und „Süd“ erhalten. Umgekehrt kann ein Benutzer im Betriebs-Konzernmandanten nicht auf Daten zugreifen, die zum Vertrieb gehören, ohne Zugriff auf alle Daten in der Organisation zu erhalten.

Bei einer hierarchischen Sicherheit darf der Benutzer ganz oben alle Daten seiner ihm unterstellten Mitarbeiter lesen und bearbeiten. Diese wiederum dürfen außerdem die Daten von weiter unten in der Hierarchie angesiedelten Benutzern lesen.

Die hierarchische Sicherheit ist ein alternatives Sicherheitsmodell, das für Fälle entwickelt wurde, in denen sich ein Benutzer, der einem Vorgesetzten unterstellt ist, nicht im selben Teil der Hierarchie des Konzernmandanten befindet. Die hierarchische Sicherheit ist auch in Situationen nützlich, in denen sich Manager in anderen Ländern/Regionen oder Abteilungen als ihre Mitarbeiter befinden.

Bei einer hierarchischen Sicherheit gibt es zwei Möglichkeiten:

• Managerhierarchie – Hierbei wird die Benutzerhierarchie aus der Systembenutzertabelle verwendet. Die Einschränkung besteht darin, dass ein Manager im selben Konzernmandant oder in der oben genannten direkten Kette von Konzernmandanten keine Daten von Benutzern in verschiedenen Abteilungen lesen und schreiben kann.
• Positionshierarchie – Für diese Option wird die Positionstabelle verwendet. Diese Option ist vielseitiger einsetzbar und berücksichtigt nicht die Struktur des Konzernmandanten. Bei der Positionshierarchie dürfen auch mehrere Personen an einer Position sein.

Es darf immer nur ein Hierarchietyp verwendet werden.

Überwachung

Bei der Überwachung werden alle Änderungen an Daten erfasst. So lässt sich feststellen, wer welche Änderungen vorgenommen hat, und es kann auch ermittelt werden, wie Benutzer das System tatsächlich nutzen. Die Überwachungsfunktion in Dataverse erfasst nicht das Lesen von Daten oder Vorgänge, wie zum Beispiel Importe in Microsoft Excel.

Im Microsoft 365 Security and Compliance Center gibt es eine weitere Überwachungsmöglichkeit, die sogenannte Aktivitätsprotokollierung. Die Aktivitätsprotokollierung umfasst Datenlese‑ und andere Vorgänge. Die Aktivitätsprotokollierung trägt zur Umsetzung der Konformitätsvorgaben ein. Sie muss aktiviert werden.

Sicherheit in mehreren Umgebungen koordinieren

Sicherheitsrollen und Sicherheitsprofile für Spalten können in Lösungen gebündelt und in andere Umgebungen transportiert werden. Die Vorlagen des Zugriffsteams sind Teil der Tabellenmetadaten und werden bei Aufnahme in die Lösung in die Tabelle übernommen. Andere Sicherheitsfunktionen, wie z. B. Konzernmandanten und Teams, können nicht in Lösungen eingebunden werden. Hier muss der Lösungsarchitekt die Bereitstellung in den Umgebungen organisieren.

Strategien zur Definition von Sicherheitsrollen

Für den Aufbau von Sicherheitsrollen gibt es drei grundlegende Strategien:

• Positionsspezifischer Aufbau
• Basis + Position
• Basis + Fähigkeit

Bei einer positionsspezifischen Strategie wird eine einzelne Sicherheitsrolle erstellt, die alle für die Stelle erforderlichen Berechtigungen enthält. Die sofort einsetzbaren Rollen sind positionsspezifisch und nach Stellenbezeichnungen benannt, z. B. Verkäufer. Bei bestimmten Stellen können Sie sich an diesem Rollenmodell orientieren, es kann jedoch passieren, dass Sie am Ende viele ähnliche Sicherheitsrollen haben, die gepflegt werden müssen. Beispiel: Wird eine neue benutzerdefinierte Tabelle hinzugefügt, müssen Sie viele, wenn nicht gar alle Rollen ändern.

Ein etwas zeitgemäßerer Ansatz wäre, ein mehrschichtiges Sicherheitsmodell anzuwenden. Bei diesem Modell kopieren Sie eine sofort nutzbare Rolle, wie z. B. Verkäufer oder Basic-Benutzer, und ändern die Zugriffsebenen auf die allgemeine oder minimale Ebene, die alle Benutzer benötigen. Eine mögliche Bezeichnung für diese Rolle wäre „Basis“. Anschließend legen Sie neue Rollen an und bestimmen nur die Zugriffsebenen im Zusammenhang mit den wenigen Rechten, die die einzelnen Benutzergruppen neben der Basisrolle benötigen. Diese Minimalrollen enthalten die weiteren Berechtigungen, die für Position oder erforderliche Fähigkeit vonnöten sind.

In der folgenden Abbildung heißt die Basisrolle „Alle Mitarbeiter“ und wird allen Benutzern zugewiesen. Alle Benutzer im Vertrieb erhalten außerdem die Rolle „Vertrieb“, also eine Positionsrolle, wobei einigen Vertriebsbenutzern mit der Rolle „Mobil“ eine Funktionsrolle mit nur der Berechtigung „Mobil“ und dem Manager die Rollen „Vertrieb“ und „Manager“ zugewiesen werden.

Sicherheitsrollen sind, wenn auch nicht offensichtlich, mit Konzernmandanten verknüpft. Rollen, die in der Stammeinheit erstellt werden, werden von allen untergeordneten Konzernmandanten übernommen. Soll eine Sicherheitsrolle auf die Benutzer aus einem bestimmten Konzernmandanten beschränkt werden, können Sie eine spezifische Sicherheitsrolle für diesen Konzernmandanten anlegen. Beachten Sie jedoch, dass Sicherheitsrollen in Lösungen bei einem Import der Lösung immer dem Stammkonzernmandanten hinzugefügt werden.

Microsoft Entra ID-Gruppenteams

Ein Microsoft Entra ID-Gruppenteam ist mit einem Besitzerteam insofern vergleichbar, dass es Datensätze besitzen kann und dem Team Sicherheitsrollen zugewiesen werden können. Der Unterschied besteht darin, dass sich die Teammitgliedschaft in Dataverse dynamisch aus der Zugehörigkeit der zugeordneten Microsoft Entra ID-Gruppe ableitet. Die Microsoft Entra ID-Gruppenmitgliedschaft kann manuell zugewiesen oder anhand der regelbasierten Zuweisung auf Basis der Attribute des Benutzers in Microsoft Entra ID abgeleitet werden.

Neue Benutzer lassen sich besonders einfach hinzufügen, wenn Sie Microsoft Entra ID-Gruppenteams verwenden und Teams mithilfe der Option Direkter Benutzer Sicherheitsrollen zuweisen.

Bei Microsoft Entra ID-Gruppenteams können sowohl Sicherheitsgruppen als auch Office 365-Gruppen verwendet werden.

Weiter