Wie Feldicherheit verwendet werden kann, um Zugriff auf Feldwerte in Microsoft Dynamics 365 zu steuern

 

Veröffentlicht: Januar 2017

Gilt für: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

In Microsoft Dynamics 365 und Microsoft Dynamics 365 (online) verwenden Sie die Sicherheit auf Feldebene, um den Zugriff auf Felder mit hoher Auswirkung auf das Unternehmen auf bestimmte Benutzer und Teams zu beschränken. Sie verwenden das z. B., damit nur bestimmte Benutzer den Kreditscore für einen Kunden lesen oder aktualisieren können. Für diese Version kann die Sicherheit auf Feldebene sowohl für benutzerdefinierten Felder als auch viele vordefinierte (OOB)- Felder angewendet werden.

Im Folgenden wird beschrieben, wie der Zugriff auf ein Feld begrenzt wird:

  1. Aktivierung der Sicherheit auf Feldebene für ein Attribut

  2. Erstellen eines Feldebenensicherheitsprofils

  3. Weisen dem Profil Benutzer oder Teams zu.

  4. Fügen Sie dem Profil bestimmte Feldberechtigungen hinzu, z. B. Erstellen, Aktualisieren oder Lesen für ein spezifisches Attribut.

Das folgende Diagramm zeigt die Interaktion zwischen rollenbasierter Sicherheit, datensatzbasierter Sicherheit und Sicherheit auf Feldebene.

Rollenbasierte Sicherheit im Vergleich zu Sicherheit auf Feldebene

Mit rollenbasierter Sicherheit können Sie einen bestimmten Entitätstyp anzeigen,mit datensatzbasierter Sicherheit können Sie einzelne Datensätze anzeigen und mit Sicherheit auf Feldebene können Sie bestimmte Felder anzeigen.

Video: Sicherheit auf Feldebene in Microsoft Dynamics CRM 2015

Häufig gestellte Fragen

  • Welche Attribute können gesichert werden?

  • Welche Sicherheitsrollen ermöglichen Ihnen, gesicherte Felder anzuzeigen?

  • Wie verhalten sich gesicherte Felder bei für Retrieve und RetrieveMultiple?

  • Wie verhalten sich sichere Felder beim Erstellen oder Aktualisieren?

  • Wie verhalten sich gesicherte Felder, wenn Datensätze freigegeben werden?

  • Wie verhalten sich gesicherte Felder bei gefilterten Ansichten?

  • Wie verhalten sich sichere Felder bei offline Synchronisation?

Welche Attribute können gesichert werden?

Um festzustellen, welche Attribute gesichert werden können, können Sie für die folgenden Entitätsmetadaten Eigenschaften abfragen:

Es gibt tausenden von Attributen, die gesichert werden können, daher gibt es zwei einfachere Möglichkeiten, nach diesen Informationen zu suchen.Zum Anzeigen der Entitätsmetadaten für Ihre Organisation installieren Sie die Metadatenbrowserlösung, die in Durchsuchen der Metadaten für die Organisation beschrieben ist. Sie können auch die Metadaten für ein nicht angepasstes Unternehmen in einer Excel-Tabellenkalkulation mit der Bezeichnung EntityMetadata.xlsx anzeigen, die im obersten Ordner des SDK-Downloads enthalten ist.

Es gibt einige zusätzliche Regeln, die für bestimmte Attributdatentypen gelten:

  • Die booleschen Attribute können zum Erstellungs- und Aktualisierungsvorgänge gesichert werden, aber nicht für Lesen.

  • Optionssatzattribute können für Erstellen, Aktualisieren und Lesen gesichert werden, wenn ein Standardwert nicht angegeben ist.

Welche Sicherheitsrollen ermöglichen Ihnen, gesicherte Felder anzuzeigen?

Das Feldsicherheitsprofil Systemadministrator ermöglicht den vollständigen Zugriff auf alle gesicherten Felder in Microsoft Dynamics 365. Standardmäßig haben alle Benutzer, die die Sicherheitsrolle "Systemadministrator" besitzen, dieses Profil. Das Profil wird vom System verwaltet und kann nicht aktualisiert oder gelöscht werden.

Wie verhalten sich gesicherte Felder bei für Retrieve und RetrieveMultiple?

Wenn Sie Retrieve oder RetrieveMultiple Methoden oder Meldungen anrufen, bewertet Microsoft Dynamics 365, ob der Anrufer und der imitierte Benutzer Zugriff auf jeden abgerufenen Datensatz (dies ist der reguläre Sicherheitsprozess) und jedes gesicherte Feld haben. Der Anruf löst keine Ausnahme aus, wenn die Kriterien sichere Felder enthalten, auf die der Aufrufer keinen Zugriff hat. Stattdessen werden in gesicherten Feldern NULL-Werte zurück gegeben, wenn sie Teil des Ausgabespaltensatzes sind.

Im Folgenden wird mehr über die Verhaltensweisen von mehrfachem Abrufen für sichere Felder beschrieben.

Wenn ein geschütztes Attribut im Spaltensatz ist

Wenn der Anrufer (oder der imitierte Benutzer) keinen Lesezugriff auf die gesicherten Felder hat, die in einem Spaltensatz enthalten sind, wird der Wert als NULL zurückgegeben. Sie können den Unterschied zwischen einem zurückgegebenen NULL-Wert, der nicht von Daten oder durch nicht genügend Zugriff verursacht wird, nicht feststellen.

Wenn ein geschütztes Attribut in der Filterbedingung ist

Wenn der Anrufer (oder der imitierte Benutzer) keinen Zugriff auf gesicherte Felder hat,die in den Filterkriterien enthalten sind, wird der Feldwert während der Auswertung des Filters durch NULL ersetzt.

In der folgenden Tabelle verfügt der Anrufer über Vollzugriff auf alle Attribute außer denen, die durch ein Sternchen (*) gekennzeichnet sind.

Datensatznummer

Wert des Namenattributs

Wert des Beschreibungsattributs

Wert des Attributs "Kann kontaktiert werden"

1

A

AAA

True

2

F

BBB

False

3

C

CCC

Wahr*

4

D

DDD

Null

5*

E*

EEE*

Null*

Wenn der Filter CanbeContacted == True ist, wird nur Datensatz eins zurückgegeben.

Wenn der Filter IsNULL (CanbeContacted) ist, werden Datensätze 3 und 4 zurückgegeben. Da Datensatz 3 vom Benutzer verborgen ist, wird er während der Bedingungsauswertung als NULL behandelt und wird für ISNull als True ausgewertet.

Aggregieren bei gesicherten Attributen

Gesicherte Werte werden durch einen NULL-Wert ersetzt, damit ein normales SQL-Aggregationsverhalten gilt.

Gruppieren bei gesicherten Attributen

Wenn der Anrufer (oder der imitierte Benutzer) keinen Zugriff auf das Attribut hat, das zum Gruppieren verwendet wird, wird der Wert als NULL behandelt und die Ergebnisse werden mit allen NULL-Werten zusammen gruppiert.

Im folgenden Beispiel hat der Anrufer Zugriff auf einige Attribute.Fett zeigt an: kein Zugriff auf Attribute, auch mit * angegeben.Kursiv zeigt einen Datensatz, für den der Anrufer keine Zugriffsberechtigung vom Typ Lesen hat, auch mit ** angegeben.

Name

Beschreibung

Anzahl der Sortierungen

Bundesland

A

AAA

1

WA

F

BBB

4

WA

C

CCC

4

CA

D**

DDD**

3**

MA**

E

EEE

0

CA

F

FFF

0

WA*

G

GGG

2

CA*

Select State, Total(orders) Group by (STATE) führt zu Folgendem:

WA–5

CA–4

NULL–2

Sortieren bei gesicherten Attributen

Wenn der Anrufer (oder der imitierte Benutzer) keinen Lesezugriff auf die gesicherten Felder hat, die in einem Sortierung nach Bedingung enthalten sind, werden die Werte als ob sie NULL sind.

Im folgenden Beispiel hat der Anrufer Zugriff auf Attribute in nur Text.Fett zeigt an: kein Zugriff auf Attribute, auch mit einem Sternchen (*) angegeben.Kursiv zeigt einen Datensatz, für den der Anrufer keine Zugriffsberechtigung vom Typ Lesen hat, auch mit ** angegeben.

Name

Beschreibung

CanbeContacted

A

AAA

True

F

BBB

False

C

CCC*

Wahr*

D

DDD

Null

E

EEE*

Null*

F**

FFF**

Wahr**

G

Null

True

Select Name order by Description ascending führt zu Folgendem:

{G,E,C},A, B, D wird zurückgegeben.

Wie verhalten sich sichere Felder beim Erstellen oder Aktualisieren?

Ein Programmierer kann einen Client erstellen, der Create und Update Methoden verwendet, die mit gesicherten Feldern interagieren. Wenn Sie Create oder Update Methoden anrufen und Daten an das gesicherte Feld übergeben und der Anrufer nicht über ausreichende Berechtigungen verfügt, wird eine Ausnahme ausgelöst.

Wie verhalten sich gesicherte Felder, wenn Datensätze freigegeben werden?

Ein Benutzer mit Zugriff auf ein gesichertes Feld in einem Datensatz es für einen anderen Benutzer oder Team freigeben. Der Benutzer kann nur den Zugriff geben, den er auf den Datensatz hat. Um den Datensatz freizugeben und beispielsweise Update-Berechtigung zu vergeben, muss der Benutzer über Update-Berechtigung verfügen.

Sie können ein gesichertes Feld in einem bestimmten Datensatz mit Lese- und/oder Update mit Sicherheitsprinzipal (Benutzer oder Team) freigeben.  Der Benutzer bzw. die Teammitglieder, für den der Datensatz freigegeben wurde, haben jetzt den Typ des gesicherten Feldzugriffs nur bei den freigegebenen Feldern nur bei dem bestimmten Datensatz, selbst wenn der Benutzer oder das Teammitglied, für den er freigegeben wurde, kein Feldsicherheitsprofil hat, das ihm Zugriff gewährt.

Wie verhalten sich gesicherte Felder bei gefilterten Ansichten?

Ein Administrator sichert eine Anzahl von Feldern für Zugriff in der Anwendung und möchte, dass die Felder in Berichten nicht verfügbar sind. Damit kann der gleiche Satz von Berichten für alle Benutzer beibehalten werden. Gefilterte Ansichten geben keine Daten für gesicherte Felder zurück, wenn der aufrufende Benutzer nicht über die Autorisierung für diese Felder verfügt. Wenn keine Feldsicherheit für die Attribute der Ansicht gelten, geben die gefilterten Ansichten komplette Daten zurück.

Wie verhalten sich sichere Felder bei offline Synchronisation?

Wenn Sie Microsoft Dynamics 365 für Microsoft Office Outlook mit Offlinezugriff verwenden, replizieren nur die gesicherten Feldwerte, auf die Sie Zugriff haben, in die Offlinedatenbank. Wenn Sie keinen Zugriff auf die Daten haben, werden sie nicht offline gespeichert.

Siehe auch

Video: Sicherheit auf Feldebene in Microsoft Dynamics CRM 2015
Das Sicherheitsmodell von Microsoft Dynamics 365
So kann die rollenbasierte Sicherheit verwendet werden, um den Zugriff auf Entitäten in Microsoft Dynamics 365 zu steuern
So kann die datensatzbasierte Sicherheit verwendet werden, um den Zugriff auf Datensätze in Microsoft Dynamics 365 zu steuern

Microsoft Dynamics 365

© 2017 Microsoft. Alle Rechte vorbehalten. Copyright