Themen des Sicherheitsworkshops
Diese Einheit konzentriert sich auf die empfohlenen Themen, die im Workshop zum Sicherheitsmodell behandelt werden sollen.
Übersicht über das Sicherheitsmodell
Im Abschnitt Übersicht über das Sicherheitsmodell der Vorlage sollte ein allgemeiner Überblick über das Sicherheitsmodell bereitgestellt werden. Die Details müssen nicht sehr ausführlich sein, da die einzelnen Bereiche später in der Vorlage genauer erklärt werden.
Beantworten Sie als Nächstes die Frage, wie Sie den Zugriff auf Datensätze verwalten. Diese Information ist hilfreich, um festzustellen, ob bestimmte Datenbeschränkungen (z. B. dass Verkäufer nur ihre eigenen Kundendaten anzeigen dürfen) oder andere spezielle Datenzugriffsinformationen vorliegen, die sich auf das Sicherheitsmodell auswirken. Zudem kann dieser Abschnitt auch technische Details umfassen, wie z. B. die Notwendigkeit der mehrstufigen Authentifizierung, um auf Systemdaten zuzugreifen.
Grundlagen
Zwei Folien der Vorlage enthalten grundlegende Informationen zum Sicherheitsmodell. Die folgenden Fragen sind auf diesen Folien enthalten.
Wie viele Benutzer haben Sie (Ziel)? ‑ Die Anzahl der Benutzer hat einen erheblichen Einfluss auf die Skalierbarkeit Ihres Sicherheitsmodells. Wenn sich der Kunde beispielsweise darauf verlässt, Datensätze freizugeben, um Zugriff zu gewähren, sollte er sich der möglichen Auswirkungen auf die Leistung bewusst sein, wenn viele Datensätze von vielen Benutzern gemeinsam genutzt werden. Einige Sicherheitsmodelle, die für kleine Benutzerzahlen akzeptabel sind, werden mit zunehmender Benutzerzahl ungeeignet. Aus diesem Grund ist es wichtig, das aktuelle und das erwartete zukünftige Benutzerwachstum zu berücksichtigen.
Wie viele unterschiedliche Sicherheitsmuster oder ‑konfigurationen haben Sie in Ihrem Modell und wie viele Benutzer gibt es in jeder Musterkonfiguration? ‑ Unter Sicherheitsmustern verstehen wir die verschiedenen Sicherheitskonfigurationen, die der Kunde implementieren möchte, um die Anforderungen zu erfüllen. Beispielsweise verwenden Personen in der Verkaufsabteilung die Standardnutzung von Benutzersicherheitsrollen, Personen im Kundenservice nutzen eine Kombination aus Benutzerrollen und Managerhierarchie, und Personen im Marketing nutzen nur Zugriffsteams. Durch das Bestimmen der erwarteten Anzahl von Mustern ermitteln Sie, ob das Sicherheitsmodell zu kompliziert oder langfristig schwer aufrechtzuerhalten ist.
Wie viel Prozent der Benutzer haben möglicherweise komplexere Sicherheitsanforderungen als die anderen? ‑ Kunden verkomplizieren ihre Sicherheitsmodelle manchmal zu sehr, indem sie Nischenausnahmen zum Standardprozess entwickeln. Wenn Sie viele verschiedene nicht-standardmäßige Anforderungen antreffen, sollten Sie die Anforderung in Frage stellen und empfehlen, den Hauptprozess zu standardisieren.
Müssen Sie den Zugriff auf Daten einschränken oder filtern? ‑ Diese Frage unterscheidet zwischen Komfortfiltern und tatsächlichen Sicherheitsanforderungen. Es ist ein gutes Ziel, den Benutzern eine vereinfachte Ansicht der Daten zu bieten, die für sie am wichtigsten sind. Sicherheit sollte jedoch nicht eingesetzt werden, um dieses Ziel zu erreichen. Verwenden Sie Ansichten, um Daten zu filtern, während der Zugriff auf andere Datensätze verfügbar bleibt.
Welche Anzahl von Sicherheitsrollen benötigen Sie? ‑ Wenn Sie die Anzahl der Sicherheitsrollen auf ein Minimum beschränken, werden die Verwaltungsaufgaben einfacher. Dynamics 365 enthält viele Standardsicherheitsrollen für Standardbenutzertypen wie Vertriebsleiter, Kundenservicemitarbeiter und Systemadministrator. Diese Rollen sollten als Grundlage für die Sicherheitsrollen des Kunden verwendet werden.
Wenn sich die Anforderungen von den Standardrollen unterscheiden, sollten Sie Kopien von Standardrollen erstellen und daraus iterieren.
Haben Sie neue Sicherheitsrollen erstellt, anstatt vorhandene anzupassen? ‑ Es wird empfohlen, eine Kopie einer der Standardsicherheitsrollen zu speichern, anstatt eine neue zu erstellen.
Zu den Sicherheitsrollen gehören viele Berechtigungen, die erforderlich sind, um in die Anwendung zu gelangen. Das Erstellen einer neuen Rolle ist problematisch, da der Kunde wahrscheinlich nicht über alle erforderlichen Basisberechtigungen verfügt.
Erinnern Sie den Kunden daran, dass mithilfe regelmäßiger Anwendungsaktualisierungen häufig neue Berechtigungen zu den Standardsicherheitsrollen hinzugefügt werden und diese neuen Berechtigungen nicht automatisch zu vorhandenen benutzerdefinierten Sicherheitsrollen hinzugefügt werden. Wenn benutzerdefinierte Sicherheitsrollen verwendet werden, muss jemand daran denken, die neu hinzugefügten Berechtigungen zu identifizieren und die benutzerdefinierten Sicherheitsrollen nach jedem Update zu aktualisieren, um die Kontinuität des Systemzugriffs nach Updates sicherzustellen.
Haben Sie versucht, die Anzahl der Sicherheitsrollen so weit wie möglich zu reduzieren? ‑ Je mehr Sicherheitsrollen eine Dynamics 365-Bereitstellung verwendet, desto schwieriger wird die Verwaltung langfristig. Wenn 25 separate Sicherheitsrollen vorhanden sind und neue Funktionen hinzugefügt werden, die von allen benötigt werden, muss der Hersteller 25 Sicherheitsrollen aktualisieren, um Zugriff auf die neue Funktion zu erhalten.
Eine beliebte Strategie besteht darin, eine Basisrolle zu nutzen, die die Basis der zur Anmeldung bei der Anwendung erforderlichen Funktionen und für alle Tabellen bietet, die allen Benutzern zur Verfügung stehen. Fügen Sie dieser Rolle als Nächstes zusätzliche Rollen mit den rollenspezifischen Funktionen hinzu, die für diese Rolle benötigt werden.
Wenn beispielsweise alle Benutzer Konten lesen müssen, aber nur die Vertriebsleiter in der Lage sein sollten, neue Konten zu erstellen, enthält Ihre Basisrolle die Leseberechtigung für Konten auf Organisationsebene, und die Vertriebsmanagerrolle enthält lediglich die Berechtigung zum Erstellen von Konten. Wenn dann eine neue Funktion hinzugefügt wurde, die alle Benutzer benötigen, kann sie nur der Basisrolle hinzugefügt werden.
Wie viele Sicherheitsrollen benötigt eine einzelne Person? ‑ Je mehr Sicherheitsrollen zu einem einzelnen Benutzer hinzugefügt werden müssen, desto komplizierter wird das Onboarding von Benutzern und desto wahrscheinlicher wird jemand Fehler machen. Wenn viele erforderliche Rollen vorhanden sind, sollten diese Rollen konsolidiert werden, um die laufende Verwaltung zu vereinfachen.
Ein weiterer Ansatz, der hier Abhilfe schaffen kann, ist die Nutzung der Microsoft Entra ID-Sicherheitsgruppe oder von Microsoft Entra ID-Büro-Gruppenteams, damit Sie dem Team die Rollen einmal zuweisen können, und die Benutzer erben dann automatisch die Rollen für das Team (also im Kontext des Konzernmandanten des Teams), nachdem sie zur entsprechenden Microsoft Entra ID-Gruppe hinzugefügt wurden.
Werden die Sicherheitsrollen auf der Ebene des Stammkonzernmandanten oder der untergeordneten Ebene erstellt? ‑ Sie können zwar Rollen erstellen, die spezifisch für einen untergeordneten Konzernmandanten sind. Wir empfehlen allerdings, Sicherheitsrollen auf der Ebene des Stammkonzernmandanten zu erstellen und zu bearbeiten.
Durch das Erstellen von Rollen auf der Ebene des Stammkonzernmandanten steht die Rolle allen Konzernmandanten zur Verfügung, während untergeordnete Konzernmandantenrollen nur auf einer einzelnen Konzernmandantenebene verfügbar sind. Wenn Sie eine konzernmandantenspezifische Rolle haben und einen Benutzer in einen anderen Konzernmandanten verschieben, ist diese Rolle nicht verfügbar. Andernfalls erhalten Sie unterschiedliche Versionen derselben Rolle in einem anderen Konzernmandanten, wodurch das System schwer zu verwalten wird.
Welche Strategie verfolgen Sie, um die Sicherheitsrollen zu aktualisieren, wenn Sie neue Tabellen und Funktionen einführen? ‑ In einer sich schnell ändernden Umgebung mit kontinuierlicher Entwicklung kann es vorkommen, dass Sie die Aktualisierung der Rollen vergessen, sie nur mit Systemadministratorzugriff testen und die Aktualisierung der Sicherheitsrollen verpassen, um die neuen Funktionen aufzunehmen. Die Strategie des Kunden sollte einen Prozess zum Aktualisieren von Sicherheitsrollen und Testen mit dem Rollenmix jeder Person beinhalten, wenn eine neue Konfigurationsversion eingeführt wird.
Warum nach diesen Informationen gefragt wird
Aus den folgenden Gründen sollten Sie Ihre Teilnehmer um die oben Informationen bitten:
Es ist selten, dass ein Sicherheitsmuster allen Benutzeranforderungen und ‑rollen entspricht. Sie müssen verstehen, wie viele verschiedene Muster Sie im Projekt implementieren müssen.
Häufig werden komplexe Sicherheitsmodelle so konzipiert, dass sie den Anforderungen eines Bruchteils der Benutzer entsprechen, die nicht zum Hauptmodell gehören. In diesem Fall könnte vorgeschlagen werden, dass diese Benutzer auf andere Weise oder anderswo auf die gewünschten Daten zugreifen können, z. B. durch Berichterstellung.
Konzernmandanten
In diesem Abschnitt liefern Sie eine Beschreibung der hierarchischen Struktur der internen Organisation des Kunden und der Struktur des Konzernmandanten in Dynamics 365. Zwischen der Konzernmandantenstruktur und der Organisationsstruktur sollte eine gewisse Beziehung bestehen, aber die Konzernmandantenstruktur sollte nicht so detailliert sein wie die Organisationsstruktur. Nur weil sich zwei Gruppen in unterschiedlichen Unternehmensbereichen befinden, müssen Sie nicht die Sichtbarkeit von Datensätzen zwischen den beiden Gruppen einschränken. Häufig können sich mehrere Abteilungen denselben Konzernmandanten teilen.
Verwenden Sie ein Tool wie Microsoft Visio oder eine andere visuelle Diagrammanwendung, um eine visuelle Darstellung der Struktur zu erstellen. Wenn Sie bereits über ein Dokument verfügen, das die Organisationshierarchie des Unternehmens visualisiert, können Sie einen Screenshot dieses Diagramms in das Dokument einfügen.
Bedenken Sie zwei potenzielle Problembereiche: zu viele Konzernmandanten oder zu wenige Konzernmandanten.
Zu viele Konzernmandanten
Wenn das vorgeschlagene Sicherheitsmodell feststellt, dass Hunderte oder Tausende von Konzernmandanten verfügbar sein werden, sollte dies als Risiko gekennzeichnet werden. Konzernmandanten sind wie große Granitfelsen: Sie sind für eine lange Verweildauer konzipiert und sollten nur selten bewegt werden. Während Benutzer zwischen Konzernmandanten verschoben werden können, ist dies keine triviale Angelegenheit, insbesondere wenn sie viele Datensätze besitzen.
Wenn Sie einen Benutzer von Konzernmandant 1 zu Konzernmandant 2 verschieben, ändert sich die Konzernmandantenzuordnung jedes Datensatzes, den der Benutzer besitzt. Dieser Aspekt kann für andere Benutzer, die Mitglieder des ursprünglichen Konzernmandanten des Benutzers sind, einige Überraschungen bereiten, wenn sie über eine Leseberechtigung auf Konzernmandantenebene verfügen. Die Datensätze, die dem verschobenen Benutzer gehören, stehen ihnen nicht mehr zur Verfügung. Wenn sie jedoch untergeordnete Datensätze dieser Datensätze besitzen, z. B. Aktivitäten, kann dies zu seltsamen Szenarien führen. Wenn der Benutzer viele Datensätze besitzt, kann das Verschieben von Benutzern zwischen Konzernmandanten zeitaufwändig sein.
Eine weitere mögliche Auswirkung großer Mengen von Konzernmandanten sind extrem langsame Aktualisierungen der Sicherheitsrollen. Jede Rolle ist nicht nur ein Datensatz. Jedem Konzernmandanten wird eine Kopie jeder Rolle hinzugefügt. Wenn Sie also Tausende von Konzernmandanten erstellen, könnte eine kleine Änderung an einer Sicherheitsrolle also einige Stunden dauern.
Es wird empfohlen, Ihre Konzernmandanten auf ein Minimum zu beschränken. Verwenden Sie nur die minimale Anzahl, um echte Sicherheitsanforderungen für Konzernmandanten zu erfüllen. Ziehen Sie für eine detailliertere Benutzersegmentierung die Verwendung von Teams in Erwägung. Teams sind flexibler, können zur Steuerung des Sicherheitszugriffs auf Datensätze verwendet werden, und Benutzer können Mitglieder mehrerer Teams sein.
Nicht genug Konzernmandanten
Wenn Sie für eine einzelne Gruppe implementieren, möchten Sie normalerweise nur den Stammkonzernmandanten für alle Benutzer verwenden.
Während der Ansatz „einfach halten“ großartig ist, ist gut möglich, dass der Kunde irgendwann über einige Daten verfügen könnte, die er vor einem Teil der Benutzer geheim halten möchte.
Betrachten Sie die folgenden Szenarien:
Sie weiten die Verwendung von Dynamics 365 auf andere Teile des Unternehmens aus.
Ihr Unternehmen wird von einem großen multinationalen Unternehmen übernommen.
Der CEO beschließt, E‑Mails zu verfolgen, und möchte nicht, dass jeder sie liest.
Der Vertriebsleiter entdeckt mehrere Kontakte in seinem Adressbuch, die in Dynamics 365 enthalten sein müssen, aber für den Rest des Unternehmens besser nicht einsehbar sein sollten.
Das Verschieben von Personen zwischen Konzernmandanten ist schwierig und Sie sollten dies nur tun, wenn es wirklich nötig ist. Wenn der Kunde mit allen Benutzern in dem Basiskonzernmandanten beginnt und eine Änderung eintritt, bei der eine Teilmenge der Daten separiert werden muss, muss der Kunde viele oder alle vorhandenen Benutzer migrieren, da der Stammkonzernmandant nicht neu übergeordnet werden kann.
Um dieser Möglichkeit entgegenzuwirken, wäre es ratsam, zunächst einen untergeordneten Konzernmandanten zu erstellen und dann alle Benutzer in diesen Konzernmandanten einzubeziehen. Sollte aufgrund von Änderungen im Unternehmen eine weitere Segmentierung der Daten erforderlich sein, kann dieser Ansatz diese Änderungen vereinfachen, da der Konzernmandant mit dem Großteil der Benutzer neu übergeordnet werden kann oder ausgewählte Benutzer wie der CEO in den Basiskonzernmandanten verschoben werden können. Ein vollständiger Umzug der Konzernmandanten aller Benutzer kann vermieden werden.
Teams
Im Abschnitt „Teams“ der Sicherheitsmodellvorlage werden Details zur geplanten Verwendung von Teamdatensätzen für die Sicherheit in Dynamics 365 erfasst.
In diesem Abschnitt der Vorlage beantworten Sie die folgenden Fragen:
Verwenden Sie Besitzerteams, um Benutzern Rollen zuzuweisen? ‑ Besitzerteams (einschließlich Microsoft Entra ID-Sicherheitsgruppen und Microsoft Entra ID-Büro-Gruppenteams) stellen eine hervorragende Möglichkeit dar, Benutzern Sicherheitsrollen zuzuweisen und den Verwaltungsaufwand zu reduzieren. Wenn einem Team eine Sicherheitsrolle zugewiesen wird, wird diese von den Mitgliedsbenutzern geerbt, gilt jedoch für den Konzernmandanten des Teams.
Verwenden Sie Besitzerteams, um Aufzeichnungen zu besitzen? ‑ Teambesitz für Datensätze kann verwendet werden, um die Zuordnung eines Datensatzes zu einem Konzernmandanten getrennt vom Konzernmandanten des ansonsten standardmäßig zuständigen Benutzers zu verwalten. Dieser Ansatz kann hilfreich sein, wenn sich die funktionale Zuordnung von einem Datensatz und einem Konzernmandanten von der Zuordnung des Benutzers zu einem Konzernmandanten unterscheidet.
Es gibt einige Nachteile und Risiken beim Teambesitz von Datensätzen, die Sie kennen sollten. Allgemein muss er automatisiert werden, um konsistent und benutzerfreundlich zu sein. Einige Funktionen, wie Ziele und Prognosen, hängen vom Besitz des Benutzers an Datensätzen ab. Die Möglichkeit, die Datensätze eines Benutzers in großen Mengen neu zuzuweisen (z. B. wenn ein neuer Verkäufer einen aus dem Unternehmen ausscheidenden Verkäufer ersetzt und sein Kundenportfolio erbt), steht den Besitzerteams nicht zur Verfügung.
Die Teamverantwortung für Datensätze kann verwendet werden, um komplexe Sicherheitsmodelle zu vereinfachen und die Notwendigkeit einer übermäßigen gemeinsamen Nutzung von Datensätzen zu verringern. Besitzerteamrollen gewähren spezielle Sicherheitsberechtigungen im Zusammenhang mit Datensätzen, die dem Team gehören. Wenn Mitglieder eines Verkaufsteams also Verkaufschancen bearbeiten können sollten, denen sie zugeordnet sind, aber nur eine Leseberechtigung für Verkaufschancen haben sollen, denen sie nicht zugeordnet sind, können Besitzersicherheitsteams diese Ausnahme aktivieren, ohne komplexe Freigaben verwenden zu müssen.
Automatisieren Sie die Datensatzzuweisung – und wie geht das? ‑ Wenn ein neues Konto erstellt wird, müssen Sie festlegen, wie der Datensatz zugewiesen wird. Darüber hinaus sollten Sie berücksichtigen, ob der Vertriebskoordinator daran denken wird, den Datensatz manuell korrekt zuzuweisen. Wir empfehlen für wichtige Datensatztypen, z. B. Konten, einen automatisierten Prozess, der Datensätze beim Erstellen automatisch zuweist, um die laufende Verwaltung des Systems zu vereinfachen. Ein Ansatz könnte darin bestehen, die Zuweisung von Vertriebsmitarbeitern nach Bundesland im Gebietsdatensatz in Dynamics 365 zu speichern. Wenn ein neues Konto erstellt wird, wird ein Microsoft Power Automate-Flow ausgeführt. Dieser vergleicht einen Adressstatus mit dem Feld für den Gebietsstatus und weist das Konto dann dem entsprechenden Gebiet und Verkäufer zu. Anschließend wird eine Benachrichtigungs-E‑Mail an den Verkäufer gesendet, um ihn aufzufordern, seinen neuen potenziellen Kunden zu kontaktieren.
Verwenden Sie Zugriffsteams (vom System oder manuell verwaltet)? ‑ Zugriffsteams sind eine hervorragende Lösung für die Verwaltung von speziellen Datensatzberechtigungen. Wenn ein Vertriebsassistent beispielsweise Bearbeitungsberechtigungen für 25 verschiedene Konten haben muss, müssen Sie die Konten nicht manuell für ihn freigeben, sondern können sie zu einem Unterraster des Zugriffsteams im Datensatz hinzufügen, und er erbt Bearbeitungsberechtigungen basierend auf den Zugriff auf die dem Raster zugeordnete Teamvorlage. Zugriffsteams sind eine hervorragende Lösung, da in der POA-Tabelle nur ein Freigabedatensatz für das gesamte Zugriffsteam erstellt wird und nicht wie bei der Datensatzfreigabe einzelne Datensätze für jede Person (siehe auch den vorherigen Abschnitt zu Freigabe in diesem Modul). Mit diesem Ansatz können Administratoren auch erkennen, wer Zugriff auf den Datensatz hat.
Wenn dieselbe Personengruppe Zugriff auf mehrere Datensätze benötigt, können Zugriffsteams auch verwendet werden, um die Datensätze für dieses Team freizugeben. Beachten Sie jedoch, dass das Zugriffsteam keine Datensätze besitzen und ihnen keine Sicherheitsrollen zugewiesen werden können.
Automatisieren Sie die Mitgliedschaft im Zugriffsteam? ‑ Es ist üblich, eine Matrix von Personen zu verwalten, die Zugriff auf Datensätze benötigen. Für ein Fertigungsprojekt sind beispielsweise ein Ingenieur, ein Elektriker und ein Sicherheitsingenieur erforderlich. Oft werden diese Zuordnungen in einem anderen System verwaltet.
In diesem Fall sollte das Zugriffsteam verwendet werden, da die Mischung der einzelnen Personen je nach Datensatz unterschiedlich ist und für die Mitglieder des Teams ein Sicherheitszugriff erforderlich ist. Sie können die Mitgliedschaft im Zugriffsteam mithilfe von Ansätzen wie Integration, Aktionen oder Plug-Ins automatisieren.
Wie stellen Sie Vorlagen für Zugriffsteams in verschiedenen Umgebungen bereit? ‑ Zugriffsberechtigungen für Zugriffsteams werden durch eine Vorlage für Zugriffsteams festgelegt. Die Vorlage bestimmt, welche Berechtigungen für die Mitglieder des Teams freigegeben werden.
Eine Herausforderung besteht darin, dass Zugriffsteam-Vorlagendatensätze nicht lösungsorientiert sind und daher nicht zu Lösungen hinzugefügt werden können. Wenn Anpassungen zwischen Umgebungen verschoben werden, muss die Vorlage für das Zugriffsteam auch verschoben oder manuell in der Zielumgebung neu erstellt werden. Wenn Sie die Mitgliedschaft in einem Zugriffsteam automatisieren, müssen die Vorlagen in allen Umgebungen identische GUIDs aufweisen, auf die in Ihrer Logik verwiesen wird.
Zum Migrieren von Zugriffsteamvorlagen sind mehrere Ansätze verfügbar, einschließlich des Dienstprogramms zur Migration von Konfigurationsdaten, ETL-Tools wie Scribe bzw. SSIS oder Dienstprogramme in der XrmToolBox.
Verwenden Sie synchronisierte Microsoft Entra ID-Gruppen zur Verwaltung der Zugriffsrechte? ‑ Microsoft Entra ID-Sicherheitsgruppenteams oder Microsoft Entra ID-Büro-Gruppenteams sind eine gute Wahl zum Automatisieren der Zuweisung von Rollenberechtigungen an Benutzer und sie sollten für größere oder komplexere Bereitstellungen in Betracht gezogen werden.
Mit Microsoft Entra ID können Sie Berechtigungen vollständig an einer zentralen Stelle steuern.
Haben Sie Anforderungen, die nicht in das Standardmodell passen? ‑ Identifizieren Sie nicht-standardmäßige Sicherheitsanforderungen. Im Abschnitt zu Ergebnissen und Empfehlungen können Sie Ansätze zur Standardisierung nicht-standardisierter Anforderungen vermitteln.
Implementierte Sicherheitsmechanismen
In diesem Abschnitt identifizieren Sie, welche Methoden zur Automatisierung der Sicherheit verwendet werden, einschließlich automatisierter Freigabe, Sicherheit auf Feldebene, Hierarchiesicherheit, Plug-Ins und Beziehungsverhalten. Weitere Informationen finden Sie im Abschnitt zu den Sicherheitstools dieses Moduls, wenn Sie mit einem dieser Ansätze nicht vertraut sind.
Warum nach diesen Informationen gefragt wird:
Bei der Automatisierung der Freigabe im großem Maßstab kann es zu Leistungsproblemen kommen. Die PrincipalObjectAccess‑ oder POA-Tabelle wird mit Ausnahmen vom Standardsicherheitsmodell gefüllt.
Die Freigabe sollte in der Regel ein manueller Prozess bleiben, um Ausnahmen für das vorhandene Sicherheitsmodell zu gewähren, und sollte nicht im großem Maßstab eingesetzt werden.
Es ist zwar einfach, den Konzernmandanten, die Teams und die Rollen des Benutzers anzupassen, aber es kann komplex sein, nach einer Reorganisation eine Datenmigration für benutzerdefinierte Freigaberegeln durchzuführen.
Die Sicherheit auf Feldebene ist weder an Benutzern noch an Konzernmandanten orientiert.
Hierarchiesicherheit kann in komplexen Konfigurationen zu Leistungsproblemen führen, wenn die Tiefe der Hierarchie zu viele Ebenen enthält.
Das Kaskadieren von Verhalten in Beziehungen ist praktisch, kann jedoch manchmal unbeabsichtigte Konsequenzen haben (z. B. das Neuzuweisen geschlossener Aktivitäten, wenn ein Konto neu zugewiesen wird). Die kaskadierende Zuweisung oder Freigabe kann auf Beziehungsbasis oder mithilfe der ORG DB-Einstellung DisableImplicitSharingOfCommunicationActivities deaktiviert oder geändert werden.
Benutzeroberfläche
Viele Komponenten von Dynamics 365 sind für Sicherheitsrollen aktiviert. Dies bedeutet, dass der Zugriff auf dieses Element auf eine oder mehrere Sicherheitsrollen beschränkt werden kann. Diese Funktion ist wichtig, da unterschiedliche Benutzer verschiedene Erfahrungen bei der Verwendung gemeinsamer Tabellen benötigen. Indem Sie den Zugriff auf App-Komponenten einschränken, die von Benutzern nicht benötigt werden, bieten Sie dem Benutzer eine einfachere und individuellere Erfahrung.
Zu den Elementen in Dynamics 365, die rollenaktiviert werden können, gehören:
Modellgesteuerte Apps
Dashboards
Formulare
Geschäftsprozessflows
Siteübersicht-Teilbereiche
Befehlsleistenschaltflächen
Dokumentvorlagen
In diesem Abschnitt der Vorlage identifizieren Sie, ob Rollen verwendet werden, um den Zugriff auf diese Bereiche zu vereinfachen.
Warum nach diesen Informationen gefragt wird:
Sicherheitsrollen und Tabellenberechtigungen können verwendet werden, um die Erfahrung für Ihre Benutzer anzupassen und zu optimieren.
Je weniger Elemente die Benutzer sehen, desto einfacher wird die Erfahrung.
Modellgesteuerte Apps können Sicherheitsrollen zugeordnet werden und die Benutzererfahrung insgesamt vereinfachen, indem die Liste der Ansichten, Diagramme, Dashboards, Formulare und Geschäftsprozessabläufe gekürzt wird.
Kunden ohne Strategie in diesem Bereich können unerwartete Probleme haben. Beispielsweise steuern die gängigen Microsoft-Apps wie Vertriebshub, Kundenservicehub und App für Outlook den Zugriff mithilfe von Sicherheitsrollen für den App-Zugriff. Wenn ein Kunde Tests nur mit einer Systemadministratorrolle durchführt, könnte er die Tatsache übersehen, dass Benutzer ohne diese Rolle die App-Zugriffsrolle benötigen, um die App zu verwenden (oder die App muss für ihre benutzerdefinierten Sicherheitsrollen freigegeben werden). Dieses Szenario kann dazu führen, dass Benutzer während der Bereitstellung keinen Zugriff auf die Apps haben, die sie benötigen.
Skalierbarkeit, Leistung und Verwaltbarkeit
In diesem Abschnitt der Vorlage behandeln Sie Fragen, mit denen festgestellt werden kann, ob potenzielle Probleme auftreten können, wenn die Anwendung für zusätzliche Benutzer skaliert wird und die Datenmenge zunimmt.
Wartungsfragen und warum sie wichtig sind
Beantworten Sie in der Vorlage die folgenden Wartungsfragen.
Haben Sie Szenarien identifiziert, in denen der Datensatz nicht zwingend einem Benutzer oder Team gehören muss? ‑ Wenn Sie neue Tabellen erstellen, die unternehmensübergreifende Referenzdaten darstellen, und die niemals Granularität für jeden Konzernmandant, jedes Team oder jeden Benutzer benötigen, sollten Sie sie als unternehmenseigene Tabellen erstellen.
Die Verantwortung über die Datensätze ist wichtig, wenn verschiedenen Benutzern eine variable Sichtbarkeit oder Bearbeitungsberechtigung erteilt werden muss. Wenn jedoch allgemeine Datensätze vorhanden sind, die für alle Benutzer sichtbar sein sollten und alle Benutzer dieselbe Bearbeitungsberechtigung haben (z. B. Datensätze, die mithilfe einer Integration generiert wurden), sollte eine Strategie wie das Zuweisen von Datensätzen zum Team der Konzernmandant in Betracht gezogen werden. Auf diese Weise müssen die Datensätze nicht neu zugewiesen werden, wenn jemand das Unternehmen verlässt.
Haben Sie potenzielle Herausforderungen für die Skalierbarkeit Ihres Sicherheitsdesigns bei größeren Datenmengen festgestellt? ‑ Strategien wie die gemeinsame Nutzung von Datensätzen können in kleineren Bereitstellungen reibungslos funktionieren, werden jedoch schnell ineffizient, wenn sie auf eine große Anzahl von Benutzern skaliert werden.
In Bezug auf Leistung und Skalierbarkeit kann es außerdem eine Herausforderung sein, Benutzer in Tausenden von Teams in Tausenden von Konzernmandanten zu haben.
Haben Sie die Auswirkungen Ihrer Daten‑ und Sicherheitsmodelle auf die POA-Tabelle berücksichtigt? ‑ Übermäßiges Teilen führt zu einer großen POA-Tabelle und kann die Systemleistung beeinträchtigen.
Aktualisieren Sie regelmäßig Benutzer-, Team‑ oder Geschäftsbereichsdatensätze? ‑ In der Regel sollten regelmäßige Aktualisierungen von Benutzer-, Team‑ oder Konzernmandanttabellen vermieden werden. Das Aktualisieren eines Attributs für eine Benutzertabelle kann beispielsweise dazu führen, dass der Sicherheitscache geleert und dadurch möglicherweise auch die Leistung beeinträchtigt wird.
Haben Sie die Auswirkungen einer umfassenden Umstrukturierung auf Benutzer, Teams, Konzernmandanten und Datensätze in Erwägung gezogen? ‑ Unternehmensstrukturen ändern sich. Neue Unternehmen werden akquiriert, Geschäftsbereiche veräußert und Mitarbeiter verlassen das Unternehmen oder wechseln in andere Abteilungen. Ihre Struktur sollte flexibel genug sein, damit Sie Benutzer, Teams oder Konzernmandanten problemlos hinzufügen oder entfernen können, ohne dass eine vollständige Neugestaltung des Sicherheitsmodells erforderlich ist.
Haben Sie für Benutzer, die bereits Zugriff auf einen großen Prozentsatz der Datensätze haben, in Betracht gezogen, einen globalen Zugriff für eine bessere Leistung bereitzustellen? ‑ Durch die Bereitstellung eines organisatorischen/globalen Lesezugriffs auf Datensätze kann die Leistung für die Bereitstellung einer Ansicht optimiert werden, da das System die für einen Benutzer geltenden Sicherheitsprinzipien (einzelne Rollen, Teamrollen, gemeinsam genutzte Datensätze, Hierarchie) beim Abrufen von Datensätzen nicht berücksichtigen muss.
Während ein Benutzer unter Sicherheitsgesichtspunkten möglicherweise Zugriff auf alle Datensätze hat, sollten Sie Systemansichten anpassen, die die Anzahl der Datensätze filtern, um nur das darzustellen, was für die Arbeit relevant ist.
Weisen Sie Datensätze in Massen neu zu, wenn ein Benutzer das Unternehmen verlässt? Haben Sie die Auswirkungen einer kaskadierenden Beziehung berücksichtigt? ‑ Einstellungen für die Kaskadierung von Beziehungen für Aktivitäten und andere allgemeine Datensätze können zu unerwarteten Ergebnissen führen, wenn Sie Datensätze neu zuweisen. Dieses Verhalten sollte geändert werden, wenn geschlossene Aktivitäten nicht neu zugewiesen werden sollen, wenn Sie Kundenkonto‑ und Kontaktdatensätze neu zuweisen.
Sicherheitstests
Das Sicherheitsmodell besteht aus mehreren Teilen, die zusammenarbeiten, und es enthält mehrere Bereiche, in denen es fehlschlagen kann. In diesem Abschnitt der Vorlage erläutern Sie den Ansatz zum Testen der Sicherheit, ermitteln den laufenden Plan zur Überwachung des Zugriffs auf Dynamics 365 und stellen sicher, dass das Design der Sicherheitsrollen gut dokumentiert und langfristig einfach zu warten ist.
Sicherheitsfragen und warum sie wichtig sind
Beantworten Sie im Abschnitt zu den Sicherheitstests der Sicherheitsmodellvorlage die folgenden Fragen.
Haben Sie Testumgebungen, um die Daten im Kontext Ihrer Sicherheitsanforderungen zu validieren? ‑ Um Sicherheitsrollen angemessen zu testen, benötigt Ihr Kunde eine Umgebung ohne Produktionstätigkeit mit identischer Konfiguration wie die Produktionsumgebung sowie einer engen Annäherung an den Produktionsdatensatz. Auch wenn Sie nicht 100 Prozent der Daten aus der Produktion benötigen, müssen die Daten ähnlich genug sein, um das Verhalten von Sicherheitsrollen genau zu testen. Es ist auch wichtig, unterschiedliche Testbenutzer zu haben und Rollen nicht denselben Testbenutzern zuzuweisen. Der Grund dafür ist, dass Benutzer mit einer ursprünglich höheren Berechtigung möglicherweise Zugriff auf bestimmte Datensätze behalten, wenn diese Rolle mithilfe von Datensatzbesitz oder Freigabe entfernt wird.
Haben Sie die Sicherheitsmatrix-Excel-Tabelle mit Zugriffsebenen und Berechtigungen, die von Ihrem Unternehmen oder Kunden definiert wurden? Es ist wichtig, eine Dokumentation des Sicherheitsdesigns außerhalb der Sicherheitsrolle von Dynamics 365 zu haben, falls jemand die Sicherheitsrolle in Dynamics 365 ändert und Sie sich daran erinnern möchten, wie sie entworfen wurde. Dieses Dokument kann eine Excel-Tabelle sein, die die entsprechende Berechtigungsstufe nach Tabelle angibt.
Haben Sie Testfälle rund um die Sicherheitsmatrix für alle Sicherheitsrollen? ‑ Die Sicherheitsanforderungen des Kunden ergaben sich wahrscheinlich aus den Anforderungen, die in den vorherigen Workshops des Projekts gesammelt wurden, und diese Anforderungen bilden die Grundlage für Sicherheitstestfälle. Jede Sicherheitsbeschränkung sollte einen Testfall haben und vor der Liveschaltung gründlich getestet werden. Anschließend sollten die Beschränkungen im Kontext jeder betroffenen Sicherheitsrolle oder Person getestet werden.
Haben Sie negative Tests in Sicherheitsbereichen und Teams auf Feldebene in Betracht gezogen? ‑ Es ist wichtig zu testen, ob jemand mit einer Rolle gesicherte Felder sehen und auf Datensätze zugreifen kann, die seinem Team zugewiesen sind. Außerdem sollten Sie sicherstellen, dass Benutzer ohne diese Rollen oder Teamzuweisungen nicht auf diese Elemente zugreifen können.
Führen Sie Penetrationstests auf der Plattform durch? ‑ In hochsicheren Umgebungen sind Penetrationstests eine Option. Beachten Sie, dass Penetrationstests den Microsoft Cloud-Regeln für Penetrationstests entsprechen müssen. Weitere Informationen finden Sie in den Einsatzregeln für Penetrationstests.
Weitere Sicherheitsfragen zu Dynamics 365
In diesem Abschnitt der Sicherheitsmodellvorlage untersuchen Sie die Sicherheit in Bezug auf die verwandten Funktionen in Dynamics 365.
Dynamics 365-Sicherheitsfragen und warum sie wichtig sind
Geben Sie Antworten auf die folgenden Fragen.
Haben Sie die Berechtigung „Nach Excel exportieren“ in Betracht gezogen? ‑ „Nach Excel exportieren“ ist eine großartige Komfort‑ und Berichtsfunktion, kann jedoch auch ein Risiko darstellen, da Mitarbeiter einiger Kunden beim Ausscheiden aus dem Unternehmen Kundendaten mitgenommen haben.
Die nicht erteilte Berechtigung „Nach Excel exportieren“ hindert einige Benutzer möglicherweise daran, Daten mit der Schaltfläche Nach Excel exportieren einfach aus Dynamics 365 herunterzuladen. Sie müssen aber bedenken, dass jeder Benutzer mit Leseberechtigung für einen Datensatz trotzdem mit APIs auf diese Daten zugreifen und sie auch exportieren kann.
Wie planen Sie gegebenenfalls, die Sicherheit im Datenexportdienst, in Azure SQL oder „In Data Lake und Power BI exportieren“ zu steuern? ‑ Wenn Daten Microsoft Dataverse zur Berichterstellung oder Integration verlassen, sind sie nicht mehr durch die Dynamics 365-Sicherheit geschützt. Unternehmen müssen sich dessen bewusst sein und die Sicherheit planen, wenn Daten das System verlassen.
Welche Sicherheitsmodellstrategie haben Sie ggf. für Power Pages und Unified Service Desk? ‑ Power Pages helfen Ihnen dabei, Daten extern verfügbar zu machen und externen Parteien die Aktualisierung von Dynamics 365-Daten zu ermöglichen. Es ist jedoch wichtig, die Auswirkungen dieser Funktion auf die Sicherheit zu berücksichtigen und sicherzustellen, dass sichere und vertrauliche Daten nicht an die falschen Personen geraten können.
Wenn Ihre Benutzer ihre Sicherheitsrollen ausschließlich von Teams erben, haben Sie erwogen, die Einstellung Vererbung für direkten Benutzer bei Sicherheitsrollen zu nutzen? Wenn Sie einem Besitzerteam eine Sicherheitsrolle zuweisen (einschließlich Microsoft Entra ID-Sicherheitsgruppenteams oder Azure AD-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 (und nicht auf Konzernmandantenebene oder höher) erben, als ob ihnen die Sicherheitsrolle direkt zugewiesen worden wäre.
Diese Funktion ist nützlich, da sie Benutzer ermöglicht, Datensätze in ihrem Namen zu besitzen, 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.
Wenn Sie vorhaben, virtuelle Tabellen zu verwenden, haben Sie das Erstellen eines Sicherheitsmodells für sie in Betracht gezogen? ‑ Virtuelle Tabellen ermöglichen die Erstellung von Tabellen, in denen keine Daten in Dataverse gespeichert sind, sondern auf eine externe Datenquelle verweisen. Diese Funktion ist zwar praktisch und in vielen Fällen der Überladung von Dynamics 365 mit Daten vorzuziehen. Sie sollten jedoch berücksichtigen, dass die Verbindung zur virtuellen Tabelle eine einzige Datenquelle verwendet. Dies bedeutet, dass alle Benutzer, die Zugriff auf die virtuelle Tabelle haben, dieselben Datensätze sehen. Wenn Sie vertrauliche Datensätze haben, die nicht für alle Benutzer sichtbar sein sollten, wird die Datenintegration empfohlen.
Sicherheitsüberwachung
In diesem Abschnitt der Vorlage überprüfen Sie die Strategie des Kunden zur Überwachung geeigneter Zugriffsrechte und ermitteln einen Missbrauch der Anwendung. Wenn Aktivitätsprüfungen in Dynamics 365 aktiviert sind, werden viele Benutzeraktivitäten im Microsoft 365 Admin Center protokolliert. Mithilfe dieser Protokolle können Sie ungewöhnliche oder potenziell böswillige Aktivitäten im System identifizieren, einschließlich allgemeiner Aktionen wie:
Veröffentlichungen der Anpassungen
Hinzufügungen zum Team
Hinzufügen einer Lösung
Veröffentlichungen der Anpassungen
Exportieren nach Excel
Anzeigen eines Berichts
Exportieren eines Berichts
Standardüberwachungsprotokolle überwachen, wann Benutzer auf das System zugreifen. Tools wie Microsoft Power Automate können Sie darüber benachrichtigen, wenn bestimmte Aktivitäten stattfinden, und Microsoft Entra ID kann Sie darauf hinweisen, wenn Personen außerhalb der regulären Regionen versuchen, auf das System zuzugreifen.
In diesem Abschnitt der Vorlage des Sicherheitsmodell-Workshops fassen Sie die Strategie zur Überwachung und Warnung vor ungewöhnlichem Verhalten zusammen und planen die regelmäßige Überprüfung der die Benutzerberechtigungen in Dynamics 365.
Bestimmungen und Compliance
In diesem Abschnitt der Vorlage ermitteln Sie, ob behördliche Vorschriften oder Compliance-Bestimmungen vorliegen, die sich auf das Sicherheitsmodell für Dynamics 365 auswirken könnten. Zu diesen Bestimmungen zählen Verbraucherschutzbestimmungen wie HIPAA und SEC sowie Bedenken von Wirtschaftsprüfern wie die Geschäftssegmentierung. Vervollständigen Sie die Informationen in der Folie zu Vorschriften und Konformität.
Sicherheit, die über Dynamics 365 hinausgeht
In diesem Vorlagenabschnitt befassen Sie sich über Dynamics hinaus mit anderen Systemen, die in Dynamics 365 und die damit verbundene Sicherheit integriert sind. Dynamics 365 ist nicht autonom. Es gibt andere Systeme, die damit interagieren oder darin integriert sind. Daher ist es wichtig, die Sicherheit ganzheitlich zu betrachten, nicht nur die Sicherheit für die einzelnen Teile. Aktualisieren Sie die Folien zu Sicherheit, die über Dynamics 365 hinausgeht zur Beantwortung der folgenden Fragen.
Haben Sie Ihre Umgebungen einer Sicherheitsgruppe zugeordnet, um Benutzer zu steuern, die Zugriff darauf haben? ‑ Durch die Zuordnung einer Dynamics 365-Umgebung zu einer Microsoft Entra ID-Sicherheitsgruppe wird der Zugriff auf die Umgebung für Benutzer außerhalb der Gruppe beschränkt und schränkt die Benutzer ein, die im System als aktiviert angezeigt werden. Dies vereinfacht auch die Benutzererfahrung, da in der Umgebungsliste nur Umgebungen angezeigt werden, auf die sie Zugriff haben.
Verwenden Sie den bedingten Zugriff in Microsoft Entra ID, um zu steuern, wie Benutzer auf Ihre Daten in Office 365/Dynamics 365 zugreifen? ‑ Der bedingte Zugriff in Microsoft Entra ID kann verwendet werden, um zu beschränken, von wo und von welchem Gerät aus die Umgebung verwendet werden kann und welche Dienste und Konnektoren verwendet werden können.
Verwenden Sie die mobile Geräteverwaltung, um eine Flotte von Geräten (Mobiltelefone usw.) zu verwalten? ‑ Durch die Verwendung von Lösungen für die mobile Geräteverwaltung (MDM), z. B. Microsoft Intune, können Sie Sicherheit erzwingen, die Bereitstellung von Dynamics 365 Mobile-Apps aus der Ferne verwalten und Daten aus der Ferne löschen, falls das Gerät verloren geht oder gestohlen wird.
Nutzen Sie die SharePoint-Integration? Wenn ja, wie gehen Sie mit der Sicherheit in SharePoint gegenüber der Sicherheit in Dynamics 365 um? ‑ SharePoint-Dokumentintegration automatisiert die Erstellung von Dokumentbibliotheken in SharePoint aus Dynamics 365-Datensätzen und bietet Dynamics 365-Benutzern schnellen Zugriff auf Dokumente, die in SharePoint gespeichert sind. Sicherheit kann ein Problem sein, da die SharePoint-Dokumentbibliothek nicht die Sicherheit von Dynamics 365 widerspiegelt. Wenn jemand Zugriff auf die SharePoint-Site hat, auf der die Dynamics 365-Dokumente gespeichert sind, können diese Benutzer sich die Dokumente in der Bibliothek anzeigen lassen, auch wenn sie keinen Zugriff auf den zugehörigen Dynamics 365-Datensatz haben. Wenn diese Situation ein Problem darstellt, sollten Sie Alternativen in Betracht ziehen, um die Zugriffsrechte auf der SharePoint-Seite einzuschränken (z. B. durch mehrere SharePoint-Sites, OneDrive for Business-Integration oder Teams-Integration).
Nutzen Sie die Microsoft Power BI-Integration? Wenn ja, wie gehen Sie mit der Sicherheit in Power BI gegenüber der Sicherheit in Dynamics 365 um? ‑ Wenn Power BI direkt aus Dataverse unter Verwendung des Standard-Microsoft Dataverse-Konnektors Berichte erstellt, werden nur die Daten wiedergegeben, auf die der Benutzer im System Zugriff hat. Wenn dieser Power BI-Bericht allerdings freigegeben wird, sehen andere Benutzer, für die der Bericht freigegeben ist, die Daten des Berichtsbesitzers.
Sicherheit auf Zeilenebene kann implementiert werden, um die Sicherheit auf der Power BI-Seite zu erzwingen. Eine andere Option ist jedoch das Erstellen eines SQL DirectQuery-Berichts in Power BI, der im verbundenen Benutzerkontext gerendert wird. Die Freigabe eines Berichts führt dann nur zur Freigabe der Darstellung der Daten, nicht der Daten selbst, und das Dynamics 365-Sicherheitsmodell wird vollständig durchgesetzt.
Verwenden Sie andere Sicherheitsmechanismen? ‑ Andere Sicherheitsmechanismen könnten die mehrstufige Authentifizierung, die Authentifizierung durch externe Authentifizierungsanbieter wie OKTA und andere umfassen.
Umfasst Ihr Sicherheitsmodell Abhängigkeiten von Lösungen unabhängiger Softwarehersteller (ISV)? Wenn ja, welche? ‑ ISVs bieten wertvolle Lösungen, die die Bereitstellung von Dynamics 365 verbessern, aber auch Sicherheitsrisiken und ‑abhängigkeiten mit sich bringen können. Es ist wichtig zu verstehen, wie diese Lösung bereitgestellt wird, wie sie aktualisiert wird und welche Art von Sicherheitszugriff der ISV benötigt.
Was sind Ihre Anforderungen an Sicherheitsmuster für die Datenintegration? ‑ Wenn Daten zwischen Systemen fließen, ist es wichtig zu verstehen, wann die Sicherheit auf Flowebene kontrolliert werden muss. Stellen Sie sicher, dass Sie bestimmen, welchen Sicherheitszugriff die Integration zum Quellsystem benötigt, welchen Sicherheitszugriff die Integration in Dynamics 365 benötigt und unter welchem Konto der Integrationsprozess ausgeführt wird. Wir empfehlen, dass Sie (nicht interaktive) Anwendungsbenutzer zu nutzen, um den Zugriff für Integrationskonten zu steuern.
Für den Fall, dass Sie andere Microsoft Power Platform-Funktionen wie Power Automate und Power Apps nutzen: Welche Sicherheitsanforderungen haben Sie und wie sieht das Design aus? ‑ Power Apps und Power Automate nutzen Konnektoren für die Integration in Hunderte verschiedene Systeme. Diese Tools sind Teil derselben Plattform wie Dynamics 365. Canvas-Apps in Power Apps und Power Automate-Flows nutzen Dataverse, genau wie Dynamics 365, und Apps und Flows können zusammen mit anderen Dynamics 365-Komponenten in Lösungen verwaltet werden. Die Einführung anderer Konnektoren in den Prozess führt zu einer Reihe zusätzlicher Sicherheitsbedenken, einschließlich Datenzugriff und Sicherheit dieser Systeme und Umgebungsstrategien für die Erstellung von Apps und Flows, die in Dynamics 365 in der Produktion zum Einsatz kommen. Weitere Sicherheitsbedenken beinhalten den Zugriff für Hersteller, die eine Verbindung zu Ihrer Dataverse-Produktionsumgebung herstellen, sowie Richtlinien zur Verhinderung von Datenverlust (DLP), die bestimmen, welche Konnektoren zusammen verwendet werden können. Der Lösungsarchitekt sollte klärende Fragen zur Microsoft Power Platform-Umgebungsstrategie und DLP-Strategie stellen und dann ermitteln, welche Berechtigungen Benutzer zum Erstellen von Apps und Flows benötigen.
Haben Sie spezielle Sicherheitsanforderungen für die Infrastruktur (Verschlüsselung usw.)? ‑ Dynamics 365 bietet erweiterte Verschlüsselungsoptionen, einschließlich vom Kunden verwaltete Schlüssel für geeignete Szenarien. Stellen Sie fest, ob diese Optionen verwendet werden und ob der Kunde eine Strategie zur langfristigen Aufrechterhaltung dieser Methoden festgelegt hat.