Microsoft Dynamics CRM 2011 | Basics–Feldsicherheitsprofile

Früher oder später stellt sich in einem Projekt oder in Eurer Produktiv-Umgebung der Bedarf der Verwendung von Feldsicherheitsprofilen. Im heutigen Artikel möchte ich auf einige Basics eingehen, um sich dem Thema Feldsicherheitsprofile zu nähern. Grundsätzlich empfehle ich vorweg diesen Blog-Artikel durchzulesen.

Feldsicherheit_Profil_Mitglieder

Nachdem wir auf einer unserer Benutzerdefinierten Entitäten ein Attribut hinzugefügt haben, für dass wir die Feldsicherheit aktiviert haben, legen wir im Folgeschritt zwei neue Feldsicherheitsprofile an. Eines benennen wir Passwort-Schutz, das Andere Passwort-Administration. In meinem Beispiel füge ich meine beiden Benutzer im System dem Profil Passwort-Schutz als Mitglieder hinzu.

Feldsicherheit_Feldberechtigung_Edit

Im Anschluss daran bearbeiten wir unsere Feldberechtigung für das neu hinzugefügte Feld. In meinem Beispiel setze ich alle drei Berechtigungen auf “nein”.

TIPP: Wenn Ihr unterschiedliche Rechtekombinationen vergebt, solltet Ihr dies über die Namensvergabe des Profils kenntlich machen. Auf diese Weise verliert Ihr die Übersicht bei mehreren angelegten Feldsicher-heitsprofilen nicht so leicht.

Wir schauen uns nunmehr die Auswirkungen dieser Einstellungen an.

Feldsicherheit_Fossi_PW_nicht_sichtbar

Wir loggen uns als Fossi Bär ein und erstellen eine neue Aktivität in der ich das Passwort-Feld hinzugefügt habe.

Es stellt sich heraus, dass das Passwort-Feld nicht editierbar ist. Das Feldsicherheitsprofil greift also in diesem Fall.

Feldsicherheit_Admin_PW_sichtbar

Schauen wir uns die gleiche Entität im Nutzer-Kontext des Administrators an.

Wir stellen fest: Diese darf das Passwort editieren, obwohl wir auch dieses Benutzerkonto unserem Feldsicherheitsprofil hinzugefügt haben!

Feldsicherheit_PW_Admin_Feldberechtigung_Edit

Nehmen wir nunmehr unser 2. Profil der Passwort-Administration und bearbeiten auch hier für unser Feld die Feldberechtigung. In diesem Fall geben wir alle Berechtigungen mit “ja” frei.

Im Anschluss daran weisen wir als Mitglieder unseren Benutzer Fossi Bär diesem Feldsicherheitsprofil zu.

Feldsicherheit_Fossi_PW_editieren_ja

Nunmehr kann auch Fossi Bär das Passwort editieren & speichern.

Halten wir also fest, das höhere Recht gewinnt, denn wir haben unseren Nutzer nicht aus dem Feldsicherheitsprofil Passwort-Schutz entfernt.

 

Widmen wir uns jetzt der Tatsache, dass der Administrator trotz Hinzufügen zum Feldsicherheitsprofil Passwort-Schutz das Feld bearbeiten konnte.

Feldsicherheit_Fossi_SysAdmin_PW_edit_ja

Wir entfernen unseren Benutzer Fossi Bär aus dem Feldsicherheitsprofil der Passwort-Administration und geben Ihm die Rechterolle des Systemadministrators.

Danach öffnen wir erneut unsere Aktivitätsentität. Es stellt sich heraus, dass das Passwort jetzt bearbeitet werden kann, obwohl unser Benutzer immer noch im Feldsicherheitsprofil des Passwort-Schutzes als Mitglied gelistet ist.

Wir können also folgende Regeln aufstellen:

1.) Es gewinnt grundsätzlich das höhere Feldsicherheitsprofilrecht

2.) Handelt es sich um einen Nutzer mit der Rechterolle Systemadministrator, hat dieser grundsätzlich volle Rechte auf das Feld, unabhängig irgendwelcher Mitgliedschaften in Feldsicherheitsprofilen.

 

Gehen wir im nächsten Schritt noch etwas weiter und entfernen die Sicherheitsrolle Systemadministrator wieder vom Nutzer Fossi Bär. Gleichfalls entfernen wir Ihn aus allen Feldsicherheitsprofilen.

Feldsicherheit_Fossi_nicht_zugeordnet_kein_PW

Erneut öffnen wir unsere Aktivität und stellen fest: Das Passwort-Feld bleibt auch ohne Zuweisung zu einem Feldsicherheitsprofil Passwort-Schutz für diesen Nutzer nicht editierbar.

Sobald also ein Feld für die Feldsicherheit aktiviert wurde und mind. ein Feldsicherheitsprofil erstellt wurde und der Nutzer nicht die Rechterolle des Systemadministrators zugewiesen wurde, verlangt das System von uns die Zuweisung von Mitgliedern zu diesen Feldsicherheitsprofilen, sofern man das Feld für Profilmitglieder editierbar “schalten” möchte.

Abschließend sei noch die Frage beantwortet, ob auch Systemanpasser höhere Rechte auf die Feldsicherheit haben.

Feldsicherheit_Fossi_Systemanpasser_PW_no_edit

Wir geben unserem Benutzer Fossi Bär also die Rechterolle Systemanpasser und öffnen erneut unsere Aktivität.

Auch in diesem Fall bleibt unser Passwort-Feld für den Benutzer nicht editierbar.

Darum können wir festhalten: Die Rechterolle Systemanpasser reicht nicht aus, um vollen Zugriff auf Felder mit Feldsicherheitsprofil zu erhalten. Dieses Recht haben nur die Systemadministratoren.

Fazit: Wer in seinem Projekt sicherstellen soll, dass nur autorisierte Benutzer Zugriff auf geschützte Felder erhalten soll, der sollte tunlichst mit einem eigenständigen Systemadministrations-Konto arbeiten und auch nur diesem das Recht des Systemadministrators geben. Ich kenne viele Systeme, in denen dieser zusätzliche Nutzer nicht angelegt ist und kann hiervon aus der Praxis nur abraten.

 

So mit diesen Basics, solltet Ihr Eure Sicherheitskonzepte ggfs. neu überdenken. Wer tief-greifende Informationen zum Thema Security sucht, dem sei das Buch von Mitch Milam Dynamics CRM Deep Dive Security empfohlen.

 

Technorati Tags:

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s