Einführung
Um sicherzustellen, dass die Bereitstellung von Microsoft Dynamics 365 durch den Kunden sicherer ist, sollte der Lösungsarchitekt einen Workshop zum Sicherheitsmodell planen und durchführen. Ziel des Workshops ist es, das vorgeschlagene Sicherheitsmodell zu bewerten, Feedback und Empfehlungen zu geben, die technische Risiken und Probleme hervorzuheben und auf bewährte Methoden hinzuweisen.
Der Workshop zum Sicherheitsmodell sollte während der Implementierungsphase des Projekts geplant und abgeschlossen werden. Er sollte eine Zusammenfassung aller sicherheitsrelevanten Bereiche enthalten, die in früheren Workshops erörtert wurden.
Sie können für jeden Modul-Workshop Beispiele von Vorlagen herunterladen und diese verwenden, wenn Sie diese Workshops für Lösungen durchführen.
Warum Sicherheit wichtig ist
Dynamics 365 fördert das Geschäft Ihrer Kunden. Sensible Geschäftsdaten zu Kunden, Finanzinformationen und geschäftskritischen Prozessen im System müssen für Kunden, die das System übernehmen, sicher sein.
Die richtige Sicherheitsstrategie bringt legitime Sicherheitsanforderungen mit der Notwendigkeit von Systemzugriff und unternehmensübergreifender Zusammenarbeit in Einklang. Bei der Implementierung von Dynamics 365 müssen Sie zwei Aspekte berücksichtigen: Benutzerzugriff und Systemsicherheit.
Einerseits ist das Anliegen der Daten‑ und Systemsicherheit wichtig. Ihre Daten bestimmen Ihr Geschäft. Ihre Kunden, Ihre Bestellungen, die Kontaktinformationen für wichtige Geschäftskontakte – dies sind Aspekte, die nicht in die Hände eines Konkurrenten gelangen dürfen. Aufgrund der Bestimmungen zu personenbezogenen Daten kann Ihr Unternehmen haftbar gemacht werden, wenn sich ein Datenverstoß auf personenbezogene Daten auswirkt.
Auf der anderen Seite haben Sie Bedenken hinsichtlich der Benutzerfreundlichkeit des Systems und der Benutzerakzeptanz. Ein Hauptgrund für die Implementierung von Dynamics 365 ist die Verbesserung der Sichtbarkeit und die Freigabe von Geschäftsdaten zwischen Gruppen sowie die Beseitigung von Datensilos in Ihrer Organisation. Indem Sie Transparenz in Bezug auf Kontakte und Konten in Ihrer Organisation schaffen, können Teams effektiv zusammenarbeiten, anstatt miteinander zu konkurrieren,. So können Sie sicherstellen, dass Sie keinen Spielraum für Interpretationen lassen, wenn es darum geht, Kontakt‑ und Kontoinformationen zu verwalten. Wenn Sie in die eine oder andere Richtung zu weit gehen, besteht die Gefahr, dass Ihre Implementierung fehlschlägt.
Wenn Sie bei Sicherheit zu nachlässig sind, können Benutzer Daten ändern, die sie nicht ändern sollten, wodurch die einzige zuverlässige Informationsquelle beeinträchtigt wird und die Vermutung entstehen lässt, dass die Daten im System nicht zuverlässig sind.
Wenn Sie bei Ihrer Sicherheit zu streng sind und alles sperren, sodass Benutzer nur einen kleinen Teil der Datensätze im System sehen können, verringern Sie den Wert von Dynamics 365 als Tool für die Zusammenarbeit. So kehren Sie entwurfsbedingt zu den alten Datensilos zurück, nur an einem anderen Ort.
Überlegungen zu Sicherheitsmodellen
Bevor wir uns mit den Details des Workshops befassen, wollen wir in den folgenden Abschnitten einige wichtige Sicherheitselemente untersuchen, die bei den meisten Dynamics 365-Implementierungen üblich sind.
Eine Sicherheitsstrategie erstellen
Auch wenn sich die Sicherheitsstrategie von Unternehmen immer ein wenig unterscheidet, sind die folgenden Richtlinien für Ihre Implementierung möglicherweise hilfreich.
Beim Schreiben restriktiver als beim Lesen vorgehen
Um eine gute Datenqualität aufrechtzuerhalten, ist es sinnvoll, einzuschränken, wer Datensätze bearbeiten oder löschen kann, z. B. indem die Rechte zum Bearbeiten oder Löschen nur auf Besitzer der Datensätze beschränkt werden. Oft ist es jedoch sinnvoller, weniger restriktiv zu sein, wenn es darum geht, welche Datensätze andere Benutzer lesen können. Mit diesem Ansatz wird die Benutzerfreundlichkeit von Dynamics 365 aufrechterhalten und Benutzer können den Kontext der Beziehung ihrer Datensätze zu anderen Datensätzen wie übergeordneten Konten beibehalten. Gleichzeitig wird mit diesem Ansatz jedoch das Risiko beseitigt, dass sie Datensätze, die sie nicht besitzen, böswillig oder versehentlich bearbeiten oder löschen.
Vereinfachen
In der Dynamics 365-Sicherheitstoolbox sind viele Tools enthalten. Bevor Sie jedoch alle Tools verwenden, sollten Sie überlegen, wie einfach die Verwaltung des Sicherheitsmodells langfristig wäre. Wenn der Administrator daran denken muss, einem neuen Benutzer vier verschiedene Rollen zuzuweisen, und ihn dann zu mehreren Teams hinzufügen muss, damit das Sicherheitsmodell funktioniert, ist es unwahrscheinlich, dass der Kunde die Strategie langfristig beibehalten kann. Der Lösungsarchitekt sollte die Auswirkungen des Sicherheitsdesigns auf die Benutzererfahrung berücksichtigen. Zusätzlich muss er auch daran denken, wie komplex die Verwaltung der Sicherheitsstrategie für Systemadministratoren sein wird. Die besten Sicherheitsstrategien sind einfach, gut dokumentiert und reproduzierbar. Daher ist die Verwendung von Funktionen wie Active Directory-Sicherheitsgruppen eine großartige Idee für größere, komplexere Bereitstellungen, da die Zuweisung von Rollen, Teams und Konzernmandaten automatisiert werden kann und das Risiko menschlicher Fehler minimiert wird.
Sicherstellen, dass das Sicherheitsdesign auf legitimen Geschäftsanforderungen basiert
Sie sollten bestimmen, ob Sie Entscheidungen zum Sicherheitsdesign aus einer Position der Angst oder aus einer legitimen Geschäftsanforderung heraus treffen. Wenn Sie Entscheidungen aus einer Position der Angst treffen, werden sie vielleicht von einem Fehler beeinflusst, den jemand in der Vergangenheit gemacht hat. Angst, insbesondere die Angst vor Ihren Mitarbeitern, ist niemals eine gute Motivation für einen Entwurf. Sie trauen Ihren Mitarbeitern, dass sie ihre Arbeit erledigen, Ihr Unternehmen vertreten und Ihre Produkte verkaufen. Manchmal weist ein zu strenges Sicherheitsdesign auf grundlegende Vertrauensprobleme zwischen Management und Mitarbeitern hin.
Sicherheitsdesign dokumentieren und neu bewerten
Sicherheitsdesign ist ein Konzept, das zu Beginn einer Dynamics 365-Implementierung berücksichtigt, anschließend aber gelegentlich übersehen wird. Wenn sich die Nutzungsmuster des Kunden oder die Benutzerbasis in regelmäßigen Abständen ändern, sind anfängliche Entscheidungen zum Sicherheitsdesign nicht die beste Lösung und müssen angepasst werden.
Wenn Sie beispielsweise eine kleinere Benutzerbasis haben, kann auch ein einzelnes Geschäftsbereichsdesign funktionieren. Wenn Ihre Benutzerbasis allerdings wächst und mehrere Abteilungen mit unterschiedlichen Anforderungen umfasst, müssen Sie möglicherweise zusätzliche Mandanten hinzufügen, um Ihre Bereitstellung auf eine größere Benutzerbasis zu skalieren. Es gibt dabei keine festen Regeln, aber die beste Vorgehensweise besteht darin, die Sicherheitsstrategie und das Sicherheitsdesign regelmäßig zu überprüfen, ihre Stärken und Schwächen zu bewerten und dann Verbesserungsmöglichkeiten zu identifizieren. Aus diesem Grund ist die Dokumentation des Sicherheitsmodells als Teil des Success by Design-Frameworks wichtig, da hierdurch eine Dokumentation erstellt wird, die vom Kunden und Berater periodisch überprüft und aktualisiert werden kann, wenn sich die Sicherheitsanforderungen ändern.
Die Sicherheitsstrategie bestimmt die Auswahl der Konfiguration
Bei der Gestaltung der Tabellenstruktur durch den Kunden oder Partner muss die Sicherheitsstrategie berücksichtigt werden. Die Tabellenkonfiguration unterstützt Ihre Sicherheitsstrategie. Wenn beispielsweise Tabellen mit Besitzern auf Organisationsebene erstellt werden, kann der Kunde den Zugriff auf Tabellendatensätze nach Besitzer oder Konzernmandant nicht einschränken. Selbst wenn Sie nicht vorhaben, den Zugriff auf die Tabelle einzuschränken, empfiehlt es sich, immer den Benutzer‑ oder Teambesitz auszuwählen, es sei denn, die Tabelle wird nur für unternehmensübergreifende Referenzdaten verwendet, z. B. um eine Nachschlageliste zu erstellen. Beachten Sie auch, wie sich die Sicherheit einer Tabelle auf die Sicherheit der zugehörigen Tabelle auswirken sollte. Wenn der Zugriff auf einen übergeordneten Datensatz auf die untergeordneten Datensätze übergehen soll, sollten Sie übergeordnete oder konfigurierbare kaskadierende Beziehungstypen verwenden.
Sicherheit auf der Plattformebene – und nicht auf der App-Ebene
Es sind zahlreiche Möglichkeiten verfügbar, um das Lesen und Bearbeiten von Daten zu steuern. Sie können Felder in Ihrem modellgesteuerten Formular als schreibgeschützt festlegen; JavaScript verwenden, um Felder aus der Benutzererfahrung zu maskieren; und Felder in Formularen und Ansichten ausblenden. Keiner dieser Ansätze wird als sicher eingeschätzt, denn obwohl sie das Benutzerverhalten steuern, sichern sie die Daten nicht wirklich. Benutzer können auf andere Weise auf die Daten zugreifen. Für echte Sicherheit müssen Sie Sicherheitsfunktionen wie Rollen, Teams und Konzernmandanten verwenden.
Sicherheitsmodellkomponenten
Dynamics 365 bietet mehrere Tools, die Sie zusammen verwenden können, um nahezu alle Sicherheitsanforderungen zu erfüllen. In diesem Abschnitt werden kurz die wichtigsten Tools beschrieben, die einem Lösungsarchitekten zur Verfügung stehen, um ein umfassendes Sicherheitsmodell bereitzustellen.
Konzernmandanten
Konzernmandanten bieten ein Framework zum Definieren der Organisationsstruktur Ihrer Benutzer und Datensätze in Dynamics 365. Mit Konzernmandanten werden Benutzer und Teams nach Organisationshierarchie gruppiert und sie können in Verbindung mit Sicherheitsrollen den Zugriff auf Daten gewähren oder einschränken.
Die wahre Stärke der Konzernmandanten beruht auf ihrer Hierarchie. Benutzer können Zugriff auf Datensätze nur in ihrem Konzernmandanten oder in ihrem Konzernmandanten und den untergeordneten Konzernmandanten erhalten. Aufgrund der Hierarchie der Konzernmandanten können Sie beispielsweise den Zugriff auf Datensätze auf Standort‑, Bezirks‑, Regional‑ und Unternehmensebene beschränken.
Die folgenden Aspekte sollten Sie bei Konzernmandanten berücksichtigen:
Der Stammkonzernmandant wird erstellt, wenn eine Microsoft Dataverse-Datenbank bereitgestellt wird.
Ein Benutzer oder ein Team kann nur Mitglied eines Konzernmandanten sein.
Datensätze sind über ihren zuständigen Benutzer oder ihr eigenes Team nur an einen Konzernmandanten gebunden.
Ein Benutzer oder ein Team kann in einen anderen Konzernmandanten verschoben werden. Wenn Sie einen Benutzer oder ein Team zwischen Konzernmandanten verschieben, müssen alle Datensätze, die dem Benutzer oder Team gehören, möglicherweise erneut dem neuen Konzernmandanten zugeordnet werden, und Personen mit Lesesicherheit auf Konzernmandantenebene im alten Konzernmandanten verlieren den Zugriff auf diese Datensätze.
Wenn Sie einen Benutzer oder ein Team in einen neuen Konzernmandanten verschieben, müssen alle Sicherheitsrollen erneut auf den Benutzer oder das Team angewendet werden.
Konzernmandanten ohne Stamm können gelöscht werden, nachdem sie deaktiviert wurden.
Konzernmandanten können in der Hierarchie verschoben werden, der Stamm-Konzernmandant kann jedoch nicht erneut übergeordnet werden.
Die Struktur der Konzernmandanten ähnelt normalerweise dem Organigramm eines Unternehmens, sollte jedoch nicht so detailliert sein wie Ihr Organigramm, es sei denn, es gibt einen bestimmten Geschäftsgrund dafür. Sie sollten Konzernmandanten als Bausteine für Ihr Sicherheitsmodell betrachten. In den meisten Fällen müssen Sie nicht für jede Abteilung in Ihrem Unternehmen einen Konzernmandanten erstellen. Beispielsweise können an einem Standort die Vertriebsabteilung und die Marketingabteilung möglicherweise denselben Konzernmandanten gemeinsam nutzen, wenn keine Datensätze zwischen Gruppen eingeschränkt werden müssen. Beachten Sie, dass Sicherheitsrollen mit Konzernmandanten zusammenarbeiten. Nur weil sich Vertrieb und Marketing im selben Konzernmandanten befinden, können also nicht unbedingt alle Benutzer alle Datensätze anzeigen, wenn ihre Sicherheitsrollen sie auf Benutzerebene beschränken.
Sicherheitsrollen
Sicherheitsrollen bestimmen die Berechtigungsstufe, über die Benutzer innerhalb der Entitäten in der Organisation verfügen. Sicherheitsrollen können den Benutzern oder Teams zugewiesen werden. Sicherheitsrollen bestimmen, auf welche Entitäten der Benutzer zugreifen kann, auf welche Datensätze innerhalb der Tabelle er reagiert und welche Berechtigungen er für diese Datensätze hat.
Bei Zuweisung zu einem Benutzer oder einem Team gilt die Sicherheitsrolle immer im Rahmen des Konzernmandanten des Benutzers oder Teams. Wenn ein Benutzer eine Sicherheitsrolle von einem Team erbt, gelten die von dieser Sicherheitsrolle gewährten Berechtigungen daher im Bereich des Konzernmandanten des Teams und nicht im Bereich des Benutzers. Dieser Ansatz kann nützlich sein, um den Zugriffsrechtsbereich eines Benutzers auf weitere Konzernmandanten auszudehnen. Mithilfe des obigen Diagramms zu Konzernmandanten kann beispielsweise ein Benutzer aus dem Konzernmandanten „Chicago Office“ einem Team hinzugefügt werden, das mit dem Konzernmandanten „Atlanta Office“ verbunden ist, und Leserechte für die Datensätze des Konzernmandanten erhalten.
Teams
Teams sind eine weitere Möglichkeit, Benutzer zu gruppieren, und können eine Rolle in Ihrer Sicherheitsstrategie spielen. In Dynamics 365 sind verschiedene Typen von Teams verfügbar:
Besitzerteams können Sicherheitsrollen zugewiesen und in Dynamics 365 als Datensatzbesitzer verwendet werden. Wenn ein Benutzer als Mitglied eines Besitzerteams hinzugefügt wird, erbt er die Sicherheitsrolle des Teams, die Rolle gilt jedoch im Kontext des Konzernmandanten des Teams. Besitzerteams können hilfreich sein, wenn Sie einen Datensatz mit einem bestimmten Konzernmandanten verknüpfen.
Microsoft Entra ID-Sicherheitsgruppenteams ähneln Besitzerteams, sind jedoch mit einer Microsoft Entra ID-Sicherheitsgruppe verknüpft. Benutzer, die zur Microsoft Entra ID-Sicherheitsgruppe mit einer Dynamics 365-Lizenz hinzugefügt wurden, werden automatisch im System aktiviert und zum verknüpften Dynamics 365-Team hinzugefügt, wenn sie eine Verbindung zur Umgebung herstellen. Diese Funktion ist nützlich, wenn Sie Benutzerzugriffsrechte außerhalb von Dynamics 365 verwalten, da Benutzer die den Dynamics 365-Teams zugewiesenen Sicherheitsrollen erben können.
Microsoft Entra ID-Büro-Gruppenteams ähneln den Microsoft Entra ID-Sicherheitsgruppenteams, verwenden jedoch eine Office 365-Gruppe statt einer Microsoft Entra ID-Sicherheitsgruppe. Der Hauptunterschied besteht darin, dass die Office 365-Gruppen erstellt werden können. Die Gruppenverwaltung kann von Personen durchgeführt werden, die keine Active Directory-Administratoren sind.
Zugriffsteams sind eine spezielle Art von Team, das keine Datensätze besitzen und keine Sicherheitsrollenzuordnung haben kann. Wie Besitzerteams können Zugriffsteams jedoch gemeinsame Datensätze mit ihnen haben. Bei Aktivierung auf Tabellenebene können Zugriffsteams dem Mitglied des Datensatz-Zugriffsteams bestimmte Berechtigungen auf Datensatzebene erteilen. Diese Option ist eine Alternative zum manuellen Freigeben des Datensatzes für einen Benutzer oder ein Team. Bei Entitäten, die für Zugriffsteams konfiguriert sind, wird die Erstellung dieser Teams mithilfe von Vorlagen für Zugriffsteams automatisiert.
Wenn Sie einem Besitzerteam eine Sicherheitsrolle zuweisen (einschließlich Azure AD-Sicherheitsgruppenteams oder Microsoft Entra ID-Büro-Gruppenteams) sollte die Einstellung für die Vererbung von Berechtigungen des Mitglieds überprüft werden, um sicherzustellen, dass sie ordnungsgemäß festgelegt ist. Mit dieser Einstellung können Benutzer, die Mitglieder des Teams sind, Berechtigungen auf Benutzerebene erben, so als ob ihnen die Sicherheitsrolle direkt zugewiesen worden wäre. Diese Funktion ist nützlich, wenn Benutzer Datensätze in ihrem Namen besitzen können sollen, obwohl ihnen keine Sicherheitsrolle direkt zugewiesen wurde. Mit dieser Einstellung können Benutzer beispielsweise persönliche Ansichten erstellen. Bei Besitzerteams müssen Sicherheitsrollen nicht direkt einzelnen Benutzern zugewiesen werden, was dabei hilft, den Verwaltungsaufwand zu verringern.
Hierarchiesicherheit
Die Hierarchiesicherheit kann verwendet werden, um Sichtbarkeit für Datensätze zur Verwaltung und allgemeinen Hierarchie des Benutzers zu gewähren. Beispielsweise muss ein Vertriebsleiter mit einem Team von fünf Personen Datensätze anzeigen, die jemandem in seinem Team gehören. Die Hierarchiesicherheit kann diesen Zugriff ermöglichen. Die Hierarchiesicherheit unterstützt zwei verschiedene Hierarchiemodelle:
Managerhierarchie – Sie gewährt Zugriff basierend auf der Managerbeziehung. Mit dem Sicherheitsmodell der Managerhierarchie hat ein Manager Zugriff auf die Datensätze, die dem Benutzer oder dem Team gehören, dessen Mitglied der Benutzer ist, sowie auf die Datensätze, die direkt mit dem Benutzer oder dem Team geteilt werden, dessen Mitglied er ist.
Positionshierarchie – Sie gewährt Zugriff basierend auf definierbaren Positionsebenen. Dieses Modell ist nützlich, wenn ein Sicherheitszugriff basierend auf indirekten Berichtsstrukturen bereitgestellt werden muss. Mit dem Positionshierarchie-Sicherheitsmodell erhält ein Benutzer in einer höheren Position Zugriff auf die Datensätze, die einem Benutzer in einer untergeordneten Position oder dem Team gehören, dessen Mitglied der Besitzer ist, sowie auf die Datensätze, die direkt mit dem Benutzer oder dem Team geteilt werden, dessen Mitglied er ist.
Feldsicherheit
Mithilfe der Feldsicherheit können Sie Daten auf Feldebene sichern, z. B. wenn bestimmte Benutzer einen Datensatz anzeigen oder bearbeiten müssen, aber keine bestimmten Details sehen sollten. Diese Funktion ist in Situationen wichtig, in denen Daten wirklich sicher sein müssen, da sie auf Plattformebene geschützt sind. Mit anderen Worten: Unabhängig davon, ob sich ein Benutzer bei einer modellgesteuerten App oder einer Canvas-App anmeldet, Daten zu Microsoft Excel exportiert oder einen Bericht ausführt, werden Feldsicherheitsprofile die Daten schützen.
Nachdem ein Benutzer über ein Feldsicherheitsprofil Zugriff auf eine Reihe gesicherter Felder (z. B. Lesen) erhalten hat, erhält er Zugriff auf diese Felder in allen Datensätzen, auf die er mit seiner Sicherheitskonfiguration oder durch Freigabe Zugriff hat.
Freigabe
Durch die Freigabe kann bestimmten Benutzern und Teams ein bestimmter Zugriff auf Datensatzebene gewährt werden. Die Verwendung der Freigabe sollte nach Möglichkeit auf die Behandlung von Ausnahmen beschränkt werden. Bisher war es üblich, die Freigabe von Datensätzen für komplexe Datensatzzugriffsszenarien zu verwenden und zu automatisieren. Dies kann ein vorteilhafter Ansatz Funktion sein, da Administratoren und Benutzer mit den entsprechenden Berechtigungen die Möglichkeit erhalten, bestimmten Datensätzen bestimmte Berechtigungen zu erteilen. Zudem ist es für die Behandlung von Ausnahmen von der Regel nützlich. Wenn beispielsweise Verkäufer A die Konten von Verkäufer B verwalten soll, während dieser einen Monat unterwegs ist, kann diese Aufgabe mit einer Freigabe ermöglicht werden. Die Freigabe kann auch automatisiert werden. Wenn Sie eine bestimmte Bedingung benötigen, um Datensätze automatisch für einen Benutzer oder ein Team freizugeben, können dazu einfache Plug-Ins, Workflow-Assemblys oder ETL-Tools verwendet werden. Diese Funktion war in der Vergangenheit die Antwort auf die anspruchsvollen Sicherheitsanforderungen vieler Dynamics 365-Kunden.
Die Freigabe ist zwar eine nützliche Funktion, sie verursacht jedoch mehrere potenzielle Probleme, darunter:
Leistung – Die Freigabe wird durch die POA-Tabelle (Principal Object Access) vereinfacht. Wenn Sie einen Datensatz für einen Benutzer oder ein Team freigeben, wird in der POA-Tabelle ein Datensatz erstellt, der die ID des Benutzers, die ID des Datensatzes und die Berechtigung enthält, über die er verfügen sollte. Die Kaskadierung der Freigabe bedeutet, das beim Vorhandensein einer übergeordneten oder konfigurierbaren Kaskadenbeziehung, für die die Freigabe aktiviert ist, die untergeordneten Datensätze in diesen Beziehungen auch für den Benutzer oder das Team freigegeben werden (und weitere Datensätze zur POA-Tabelle hinzugefügt werden). Komplexe erneut übergeordnete oder geerbte Freigabeszenarien können zudem Datensätze erstellen, wodurch die POA-Tabelle schnell wächst. Dieses Szenario wird zu einem Leistungsproblem, wenn die Tabelle groß wird (irgendwo zwischen 20 Millionen und 2 Milliarden Datensätze). Wenn Sie Dynamics 365 abfragen, z. B. beim Öffnen einer Ansicht, erweiterten Suchen oder Anzeigen eines Diagramms, werden die Ergebnisse von der POA-Tabelle gefiltert. Wenn die Tabelle groß ist oder die Indizes nicht optimiert sind, kann dies zu einer verringerten Systemleistung führen.
Verwaltungsherausforderungen – Sie können nicht leicht identifizieren, welche Datensätze für einen Benutzer freigegeben sind. Sie können zwar einen Datensatz auswählen und anzeigen, für wen er direkt freigegeben ist, aber es ist keine Methode vorhanden, um dies für alle Datensätze durchzuführen. Kaskadierende oder geerbte Freigaben werden im Freigabedialog des Datensatzes nicht angezeigt. Ohne das Öffnen jedes Datensatzes im Kontext dieses Benutzers können Sie quasi unmöglich wissen, ob Ihre Freigabestrategie ordnungsgemäß funktioniert.
Vergessene Freigaben – Sie erinnern sich an das vorherige Szenario, bei dem Sie die Datensätze von Verkäufer B für Verkäufer A freigegeben haben, der die Konten von Verkäufer B in dessen Abwesenheit verwaltet hat? Es kann passieren, dass der Administrator vergisst, die Freigabe dieser Datensätze zu beenden, was wiederum zu Problemen führen kann, wenn Verkäufer B wieder Kontakt mit Personen in seinem Workflow aufnehmen muss.
Keine Lösung ist für immer – Nachdem der Kunde das System ein oder zwei Jahre lang verwendet hat, stellt er vielleicht fest, dass es nicht mehr gut funktioniert oder veraltet ist. Er könnte auch eine umfassende Änderung seiner Freigabestrategie vornehmen, sodass er einen Batchauftrag ausführen möchte, um alle Datensätze mit der entsprechenden Freigabeberechtigung festzulegen und zu aktualisieren. Mit der Freigabefunktion gibt es keine einfache Methode, um diese Aufgabe zu erledigen.
Alternativen zur Freigabe
Sie können die folgenden Schritte unternehmen, um Probleme bei der Freigabe zu vermeiden:
Teambesitz verwenden – Mit Teambesitz können Sie Benutzerteams in mehreren Konzernmandanten Datensätze zuweisen.
Mit Teams, nicht mit Benutzern teilen – Wenn Sie einen Datensatz für 10 Benutzer freigeben, werden 10 POA-Datensätze erstellt – mal 10 POA-Datensätze für jeden untergeordnete kaskadierenden freigegebenen Datensatz. Wenn Sie den Datensatz mit einem Team mit 10 Benutzern teilen, wird nur ein POA-Datensatz erstellt (zusammen mit einem POA-Datensatz für jede kaskadierende Freigabe). Mit diesem Ansatz wird die Größe Ihrer POA-Tabelle erheblich reduziert. Wenn Sie einem Benutzer die Berechtigungen entziehen möchten, können Sie ihn aus dem Team entfernen.
Zugriffsteams für die kontrollierte Freigabe verwenden – Nutzen Sie diesen Ansatz, wenn Sie keine Besitzerteams bilden können, aber dennoch bestimmten Benutzern speziellen Zugriff auf bestimmte Datensätze gewähren möchten. In diesem Szenario möchten Sie einigen Benutzern nur das Lesen des Datensatzes freigeben, während andere den Datensatz lesen oder schreiben können sollten. Zugriffsteams können mit dieser Situation umgehen, und Sie können über mehrere Zugriffsteam-Vorlagen verfügen, eine zum Lesen und eine zum Lesen/Schreiben. Zugriffsteams sind auf Leistung ausgelegt, sodass sie das Team erst dann erstellen und den Datensatz freigeben, wenn Sie das erste Mitglied des Teams hinzufügen. Wenn ein Datensatz für ein Zugriffsteam freigegeben wird, wird auch ein Datensatz in der POA-Tabelle erstellt.
Beispiel für ein Sicherheitsszenario
Im folgenden Szenario wird erklärt, wie diese Tools kombiniert werden können, um ein umfassendes Sicherheitsmodell bereitzustellen. In diesem Beispiel ist Contoso LTD ein Konsumgüterunternehmen, das sicherstellen möchte, dass Benutzer Zugriff auf Informationen haben, die für ihre Arbeit erforderlich sind, und gleichzeitig vertrauliche Daten schützen. Durch die Kombination der Sicherheitstools in Dynamics 365 kann das Unternehmen auf jedes dieser Szenarien eingehen.
Bob
Die Sicherheit auf Feldebene verhindert, dass Bob vertrauliche Informationen in einem Datensatz sieht, und die Sicherheit von Teams oder Konzernmandanten beschränkt seine Sicht nur auf die Probleme seines Unternehmens.
Fertigungsingenieur
Muss in der Lage sein, von Kunden gemeldete Qualitätsprobleme zu sehen
Sollte nicht in der Lage sein, E‑Mail-Adresse und Mobiltelefonnummer des Kunden zu sehen
Sollte keine Probleme für andere Unternehmen sehen können
Amy
Konzernmandanten-Sicherheit bedeutet, dass Amy Datensätze sehen kann, die einer anderen Person in der Abteilung gehören. Amy kann jedoch keine Datensätze in anderen Abteilungen sehen oder bearbeiten.
Kundenservicemitarbeiter
Erstellt Kundenservicefälle aufgrund von Benutzerbeschwerden
Sollte in der Lage sein, Kundeninformationen und Fallbeispiele für Kunden anzuzeigen, die die Produkte ihrer Abteilung verwenden
Sollte keine Kundendaten anderer Abteilungen sehen können
Roy
Durch die hierarchische Sicherheit kann Roy Datensätze anzeigen, die seinen ihm direkt oder indirekt unterstellten Mitarbeitern gehören, jedoch keinen anderen Benutzern.
Vertriebsmanager
Muss die Datensätze seiner ihm direkt unterstellten Mitarbeiter sehen können
Sollte keine Daten für andere Vertriebsleiter sehen
Linda
Lindas Sicherheitsrolle gibt ihr organisationsweite Sichtbarkeit für Daten in Dynamics 365.
Geschäftsführer
Benötigt Sichtbarkeit für alle Kundendaten und damit zusammenhängende Probleme
Sicherheitsmodell-Workshop
Der Sicherheitsmodell-Workshop sollte auf etwa eine Stunde begrenzt sein und wird häufig im Rahmen einer Microsoft Teams-Besprechung durchgeführt, wenn nicht alle zusammen vor Ort sind. Zu den Teilnehmern sollten wichtige Stakeholder aus den Kunden‑ und Partnerteams gehören. Lösungsarchitekten, funktionale und technische Führungskräfte sind obligatorisch.
Die Sicherheitsdetails aus der Vorlage für den Lösungsentwurf-Workshop sollten zur Vorbereitung des Sicherheitsmodell-Workshops referenziert werden.