Hierarchiesicherheit

 

Veröffentlicht: November 2016

Gilt für: Dynamics CRM 2015

Das Hierarchiensicherheitsmodell ist eine Erweiterung der vorhandenen Microsoft Dynamics 365-Sicherheitsmodelle, die Unternehmenseinheiten, Sicherheitsrollen und Teams verwenden. Es kann mit allen anderen Sicherheitsmodellen zusammen verwendet werden. Die Hierarchiensicherheit bietet einen präziseren Zugriff auf Datensätze für eine Organisation und hilft, die Wartungskosten zu senken. Beispielsweise können Sie in komplexen in den Szenarien mit dem Erstellen meherer Unternehmenseinheiten beginnen, und siie dann der Hierarchiensicherheit hinzufügen. dadurch wird ein präziserer Zugriff auf Daten mit wesentlich geringeren Wartungskosten erreicht, den viele Unternehmenseinheiten benötigen.

In diesem Thema

Sicherheitsmodelle für Managerhierarchie und Positionshierarchie

Hierarchiesicherheit einrichten

Manager- und Positionshierarchien einrichten

Leistungsüberlegungen

Sicherheitsmodelle für Managerhierarchie und Positionshierarchie

Zwei Sicherheitsmodelle können für Hierarchien verwendet werden, die Managerhierarchie und die Positionshierarchie. Mit der Managerhierarchie muss sich ein Manager innerhalb derselben Unternehmenseinheit befinden wie der Untergebene, oder in der übergeordneten Unternehmenseinheit der Unternehmenseinheit des Untergebenen, um Zugriff auf Daten des Untergebenen zu haben. Die Positionshierarchie erlaubt Datenzugriff über Unternehmenseinheiten hinweg. Wenn Sie eine Finanzorganisation sind, bevorzugen Sie möglicherweise das Managerhierarchienmodell, um zu verhindern, dass Manager auf Daten zaußerhalb ihrer Unternehmenseinheiten zugreifen. Wenn Sie jedoch Bestandteil einer Kundendienstorganisation sind, und möchten, dass Manager auf serviceanfragen zugreifen, die in verschiedenen Unternehmenseinheiten behandelt werden, funktioniert unter Umständen die Positionshierarchie besser für Sie.

Hinweis

Während das Hierarchiensicherheitsmodell eine bestimmte Zugriffsebene auf Daten bietet, kann weiterer Zugriff erhalten werden, indem andere Sicherheitsformen verwendet werden, z. B. Sicherheitsrollen.

Manager-Hierarchie

Das Managerhierarchien-Sicherheitsmodell basiert auf der Verwaltungskette oder Direktuntergebenen-Struktur, in der die Beziehung zwischen Manager und Untergebenen eingerichtet wird, indem sie das Managerfeld auf der Systembenutzerentität verwendet wird. Bei diesem Sicherheitsmodell können Manager auf daten zugreifen, auf die ihre Untergebenen Zugriff haben. Sie können Arbeit im Namen ihrer direkten Untergebenen ausführen, oder auf Informationen zugreifen, für die Genehmigung erforderlich ist.

Hinweis

Mit dem Managerhierarchien-Sicherheitsmodell hat ein Manager Zugriff auf die Datensätze im Besitz des Benutzers oder des Teams, dessen Mitglied der Benutzer ist, und auf Datensätze, die direkt für den Benutzer oder das Team freigegeben sind, dessen Mitglied der Benutzer ist.

Zusätzlich zum Managerhierarchie-Sicherheitsmodell muss ein Manager mindestens über die Leseberechtigung in einer Entität verfügen, um die Daten des Untergebenen anzuzeigen. Wenn zum Beispiel ein Manager nicht über Lesezugriff für die Anfrageentität verfügt, kann der Manager die Anfragen, auf die seine Untergebenen Zugriff haben, nicht anzeigen.

Für einen nicht-direkten Untergebenen hat ein Manager nur schreibgeschützten Zugriff auf die Daten des Untergebenen. Für einen direkten Untergebenen hat der Manager Lese-, Schreib-, Aktualisierungs- Anfügen-Zugriff auf die Daten des Untergebenen. Um das Managerhierarchie-Sicherheitsmodell zu illustrieren, sehen wir uns das Diagramm folgende an. Der CEO kann das VP von Umsatzdaten und das VP von Servicedaten lesen oder aktualisieren. Jedoch hat der CEO für die Vertriebsmanagerdaten und die Serviceleiterdaten sowie die Vertriebs- und Supportdaten nur Lesezugriff. Sie können die Menge der Daten weiter einschränken, auf die Manager mit "Tiefe" zugreifen kann. Tiefe wird verwendet, um zu begrenzen, wie viele Ebenen tief ein Manager schreibgeschützten Zugriff auf die Daten seiner Untergebenen hat. Wenn die Tiefe z. B. auf 2 festgelegt wurde, kann der CEO die Daten des VP des Vertriebs, VP des Services und Servicemanager anzeigen. Allerdings sieht der CEO nicht die Umsatzdaten oder die Supportdaten.

Es ist wichtig, festzustellen, dass, wenn ein direkter Untergebener tieferen Sicherheitszugriff auf eine Entität hat als der Manager, dieser möglicherweise nicht in der Lage ist, alle Datensätze anzuzeigen, für die der direkte Untergebene Zugriff besitzt. Das folgende Beispiel zeigt dieses Problem.

• Eine einzelne Unternehmenseinheit hat drei Benutzer: Benutzer 1, Benutzer 2 und Benutzer 3.

• Benutzer 2 ist ein direkter Untergebener von Benutzer 1.

• Benutzer 1 und Benutzer 3 haben Benutzerebenen-Lesezugriff für die Entität "Konto". Diese Zugriffsebene gewährt einem Benutzer Zugriff auf Datensätze, deren Besitzer er ist, sowie Datensätze, die für den Benutzer selbst oder für ein Team freigegeben sind, deren Mitglied er ist.

• Benutzer 2 hat Unternehmenseinheit-Lesezugriff auf die Entität "Konto". Dadurch kann Benutzer 2 alles Konten für die Unternehmenseinheit anzeigen, einschließlich aller Konten im Besitz von Benutzer 1 und Benutzer 3.

• Benutzer 1 als direkter Vorgesetzter von Benutzer 2, hat Zugriff auf die Konten, die im Besitz von Benutzer 2 oder mit ihm geteilt sind, und alle Konten, im Besitz eines Teams sind, dessen Mitglied Benutzer 2 ist, oder die mit diesem geteilt werden. Benutzer 1 hat jedoch keinen Zugriff Konten von Benutzer 3, obwohl sein direkter Untergebener Zugriff auf die Konten des Benutzers 3 hat.

Positionshierarchie

Die Positionshierarchie basiert nicht auf der Direktuntergebenen-Struktur, wie die von Managerhierarchie. Ein Benutzer muss kein tatsächlicher Manager eines anderen Benutzers sein, um auf die Daten des Benutzers zuzugreifen. Als Administrator definieren Sie verschiedene Positionen in der Organisation und ordnen sie in der Positionshierarchie an. Dann fügen Sie jeder gegebenen Position Benutzer hinzu, oder, wie wir auch sagen, Sie "markieren" einen Benutzer mit einer bestimmten Position. Ein Benutzer kann nur mit einer Position in einer gegebenen Hierarchie etikettiert werden, jedoch kann eine Position für mehrere Benutzer verwendet werden. Benutzer in höheren Positionen in der Hierarchie haben Zugriff auf Daten der Benutzer in niedrigeren Positionen, im direkten Vorgängerpfad. Die direkten höheren Positionen haben Lese-, Schreib-, Anfügen-, Aktualisieren-Zugriff auf Daten der niedrigeren Positionen im direkten Vorgängerpfad. Die nicht-direkten höheren Positionen haben Lese-Zugriff auf Daten der niedrigeren Positionen im direkten Vorgängerpfad.

Um das Konzept des direkten Vorgängerpfads vorzuführen, lassen Sie uns zunächst das Diagramm unten beachten. Die Vertriebsmanagerposition hat Zugriff auf die Verteibsdaten, jedoch nicht auf die anderen Supportdaten, die im Vorgängerpfad sind. Dasselbe gilt für die Servicemanagerposition. Sie hat keinen Zugrif auf die Vertriebsdaten, die im Vertriebspfad sind. Wie in der Managerhierarchie können Sie den Umfang der daten beschränken, die für höhere Positionen mit "Tiefe" verfügbar sind. Die Tiefe beschränkt, wie viele Ebenen tief eine höhere Position schreibgeschützten Zugriff auf Daten der niedrigeren Positionen im direkten Vorgängerpfad hat. Wenn die Tiefe auf 3 festgelegt ist, kann die CEO-Position die Daten aus dem VP für Vertrieb und VP für Kundenservicepositionen, bis hinab zu den den Vertriebs- und Supportpositionen anzeigen.

Hinweis

Mit dem Positionhierarchie-Sicherheitsmodell hat ein Benutzer in einer höheren Position Zugriff auf die Datensätze im Besitz eines Benutzers in niedrigerer oder des Teams, dessen Mitglied der Benutzer ist, und auf Datensätze, die direkt für den Benutzer oder das Team freigegeben sind, dessen Mitglied der Benutzer ist.

Zusätzlich zum Positionshierarchiensicherheitsmodell besitzen die Benutzer auf einer höheren Ebene mindestens die Leseberechtigung der Benutzerebene für eine Entität, um die Datensätze anzuzeigen, auf die die Benutzer in den niedrigeren Positionen Zugriff haben. Wenn zum Beispiel ein Benutzer auf einer höheren Ebene nicht über Lesezugriff für die Anfrageentität verfügt, kann dieser Benutzer die Anfragen, auf die Benutzer auf niedrigeren Positionen Zugriff haben, nicht anzeigen.

Hierarchiesicherheit einrichten

Um die Sicherheitshierarchie einzurichten, müssen Sie die Sicherheitsrolle "Administrator" besitzen.

Die Hierarchiesicherheit ist standardmäßig deaktiviert. Zum Aktivieren:

1. Gehen Sie zu Einstellungen > Sicherheit.

2. Wählen Sie Hierarchiensicherheit aus und wählen Sie Hierarchiemodellierung aktivieren aus.

Wichtig

Um Änderungen in Hierarchiensicherheit vorzunehmen, müssen Sie über die Berechtigung Hierarchie-Sicherheitseinstellungen ändern verfügen.

Nachdem Sie die Hierarchiemodellierung aktiviert haben, wählen Sie das gewünschte Modell aus, indem Sie die Manager-Hierarchie oder Benutzerdefinierte Positions-Hierarchie auswählen. Alle Systementitäten sind standardmäßig für Hierarchiesicherheits aktiviert, aber Sie können ausgewählte Entitäten aus der Hierarchie ausschließen. Das Fenster Hierarchie-Sicherheit, unten angezeigt:

Legen Sie die Tiefe auf einen gewünschten Wert fest, um zu begrenzen, wie viele Ebenen tief ein Manager schreibgeschützten Zugriff auf die Daten seiner Untergebenen hat. Wenn z. B. die Tiefe gleich 2 ist, kann ein Manager nur auf seine Konten und die Konten der Untergebenen zwei ebenen tief zugreifen. Wenn Sie sich in unserem in Dynamics 365 nicht als Administrator anmelden, der alle Konten anzeigen kann, sondern als VP Vertrieb, können Sie lediglich die aktiven Konten der Benutzer anzeigen, die im roten Rechteck angezeigt werden, wie unten veranschaulicht:

Hinweis

Während die Hierarchiensicherheit, dem VP Vertrieb Zugriffs auf die Datensätze im roten Rechteck erteilt, kann zusätzlicher Zugriff basierend auf der Sicherheitsrolle verfügbar sein, die der VP Vertrieb hat.

Manager- und Positionshierarchien einrichten

Die Managerhierarchie wird einfach erstellt, indem die Managerbeziehung im Systembenutzerdatensatz verwendet wird. Sie verwenden das Manager (ParentsystemuserID)-Suchfeld, um den Manager des Benutzers anzugeben. Wenn Sie die Positionshierarchie bereits erstellt haben, können Sie den Benutzer mit einer bestimmten Position in der Positionshierarchie markieren. Im folgenden Beispiel ist der Vertriebsmitarbeiter Untergebener des Vertriebsmanagers in der Managerhierarchie und hat auch die Vertriebsposition in der Positionshierarchie:

Um einen Benutzer einer bestimmten Position in der Positionshierarchie hinzuzufügen, verwenden Sie das Suchfeld namens Position im Formular des Benutzerdatensatzes, wie unten gezeigt:

Wichtig

Um einen Benutzer einer Position hinzufügen oder die Position des Benutzers zu ändern, müssen Sie über das Recht Position für einen Benutzer zuweisen verfügen.

Um die Position auf dem Formular des Benutzerdatensatzes zu ändern, wählen Sie auf der Navigationsleiste Mehr (…) und wählen Sie eine andere Position aus, wie unten gezeigt:

Um eine Positionshierarchie zu erstellen:

1. Gehen Sie zu Einstellungen > Sicherheit.

2. Wählen Sie Positionen aus.

Für jede Position geben Sie den Namen der Position, die Übergeordnung der Position und die Beschreibung an. Fügen Sie Benutzer zu der Position hinzu, indem Sie das Suchfeld namens Benutzer in dieser Position verwenden. Folgendes ist ein Beispiel der Positionshierarchie mit aktiven Positionen.

Das Beispiel der aktivierten Benutzer mit den entsprechenden Positionen wird unten angezeigt:

Leistungsüberlegungen

Um die Leistung zu steigern, empfehlen wir:

• Beschränken Sie die effektive Hierarchiensicherheit auf 50 oder weniger Benutzer unter einem Manager/einer Position. Die Hierarchie kann mehr als 50 Benutzer unter einem Manager/einer Position haben, aber Sie können die Tiefe verwenden, um die Anzahl der Ebenen für schreibgeschützten Zugriff zu beschränken und mit dieser Beschränkung die Anzahl von Benutzern unter einem Manager/einer Position auf 50 oder weniger Benutzer beschränken.

• Verwenden Sie Hierarchiensicherheitsmodelle zusammen mit anderen vorhandenen Sicherheitsmodellen für komplexere Szenarien. Vermeiden Sie es, eine große Anzahl von Unternehmenseinheiten zu erstellen, erstellen Sie stattdessen weniger Unternehmenseinheiten und fügen Sie Hierarchiensicherheit hinzu.

Siehe auch

Sicherheitskonzepte für Microsoft Dynamics CRM
Hierarchische Daten abfragen und visualisieren
Video: Hierarchische Sicherheitsmodellierung in Microsoft Dynamics CRM 2015
Video: Hierarchien-Visualisierung in Microsoft Dynamics CRM 2015

© 2016 Microsoft Corporation. Alle Rechte vorbehalten. Copyright