Freigeben über

Entwerfen einer Berechtigung

  • Artikel

Aktualisiert: November 2007

Eine Berechtigung stellt die Fähigkeit zum Zugreifen auf eine geschützte Ressource oder zum Ausführen einer geschützten Operation dar. Wenn Sie eine eigene Berechtigungsklasse implementieren, müssen Sie eine Reihe wichtiger Entwurfsentscheidungen treffen. Einer der ersten Schritte besteht darin, genau zu bestimmen, welche Ressource durch die benutzerdefinierte Berechtigung geschützt werden soll.

Anschließend sollten Sie bestimmen, ob einander überschneidende Berechtigungen zu beachten sind. Obwohl dieselbe Ressource nicht durch zwei Berechtigungen geschützt werden soll, lässt sich dies in einigen Situationen nicht vermeiden. Die Berechtigung für den Zugriff auf nicht verwalteten Code kann z. B. andere Berechtigungen umfassen, da Code mit der Berechtigung zum Zugriff auf nicht verwalteten Code über eine nicht verwaltete API nahezu jede Aktivität ausführen kann. Wenn jedoch die Berechtigung für den Zugriff auf nicht verwalteten Code nicht erteilt wird, müssen Sie dennoch Berechtigungen für den Zugriff auf andere Ressourcen erteilen. Daher empfiehlt es sich, Berechtigungen für den Zugriff auf nicht verwalteten Code von anderen Berechtigungen zu trennen.

Wie kann festgestellt werden, ob einander überschneidende Berechtigungen verwaltet werden können? Auf diese Frage gibt es keine endgültige Antwort. Es sollte allerdings bedacht werden, ob eine der Berechtigungen einen genauer definierten Zugriff als die andere Berechtigung darstellt, sodass sie i. d. R. schneller als die andere gewährt wird. Wenn dies der Fall ist, ist das Erteilen von Zugriffsrechten häufig ein einfacher Vorgang, wodurch die Arbeit des Administrators erleichtert wird.

Nachdem Sie festgelegt haben, welche Ressource durch die Berechtigung geschützt wird, und alle Probleme hinsichtlich sich überschneidender Berechtigungen gelöst haben, müssen Sie entscheiden, wie genau die Zugriffssteuerung definiert werden soll. Die Antwort auf diese Frage wirkt sich auf das Entwerfen der Variablen aus, die den Zustand der Berechtigung darstellen, und sie bestimmt, ob der Zugriff auf die geschützte Ressource vom Administrator konfiguriert werden kann. Darüber hinaus kann sie sich auf die Leistung, die Benutzerfreundlichkeit und andere Faktoren auswirken.

Studieren Sie zur Veranschaulichung dieser Entwurfsaspekte einige der Entwürfe, die für die von .NET Framework bereitgestellte FileIOPermission-Klasse hätten ausgewählt werden können. Jede Entwurfsentscheidung hat Auswirkungen auf die Variablen, die den Zustand der Berechtigung darstellen.

  • Ein einziges Bit, das je nach Wert "alle Dateien verwenden" oder "keine Dateien verwenden" bedeutet.

  • Zwei Bits bedeuten "alle Dateien lesen" und "alle Dateien schreiben" oder je nach ihren Werten jeweils das Gegenteil.

  • 26 Bits bedeuten "alle Dateien auf dem angegebenen Laufwerk verwenden".

  • Ein Array von Zeichenfolgen, in dem alle Dateien aufgelistet werden, auf die der Zugriff gewährt wird.

Natürlich müssen verschiedene abwägende Entscheidungen getroffen werden. Die Berechtigung durch ein einziges Bit ist z. B. sehr einfach, schnell und leicht zu handhaben. Sie bietet Administratoren jedoch wenig Auswahlmöglichkeiten und ist u. U. nicht wünschenswert. Andere Entscheidungen, die eine komplexere Darstellung des Berechtigungszustandes bieten, können zu einem gewissen Leistungsabfall führen. Sie müssen daher zwischen den Vor- und Nachteilen einen sinnvollen Kompromiss finden und dabei berücksichtigen, dass nur eine Berechtigung zum Schützen ein und derselben Ressource erstellt werden sollte. Im Allgemeinen sollten Sie eine Berechtigungsklasse so erstellen, dass der Zustand der Berechtigung so komplex wie nötig ist, ohne dass die Leistung wesentlich beeinträchtigt wird.

Obwohl auch andere Entwürfe möglich sind, folgen die meisten Berechtigungen einem der folgenden Standardentwurfsmuster oder einer Kombination von diesen:

  • Boolesche Berechtigungen. Diese einfachste Art von Berechtigungsobjekten enthält ein oder mehr Bits, von denen jedes einer "Berechtigung zum Ausführen von X" entspricht. Entweder Sie verfügen über die Berechtigung, oder Sie verfügen nicht über die Berechtigung. Ein Beispiel für diese Berechtigungsart ist die SecurityPermission-Klasse. Deren Zustand enthält boolesche Variablen, die das Recht zum Ausführen verschiedener, jeweils zulässiger oder unzulässiger Aktionen darstellen, z. B. die Berechtigung zum Aufrufen von nicht verwaltetem Code.

  • Berechtigungsebenen. Diese detailliertere Form der Berechtigung weist Variablen auf, die jede Art des Zugriffs als eine Zahl von 0 (kein Zugriff) bis zu einer höheren Zahl (uneingeschränkter Zugriff) mit einigen Ebenen dazwischen darstellen. Beispielsweise können Sie mit der UIPermission-Klasse verschiedene Ebenen der Berechtigung zum Verwenden von Fenstern ausdrücken. Diese reichen von Verweigerung der Zugriffsberechtigung für die Benutzeroberfläche bis hin zu uneingeschränkter Gewährung, wobei es einige Zwischenstufen gibt.

  • Berechtigungen mit Objektlisten. Diese Art der Berechtigung bietet eine sehr genaue Spezifikation der zulässigen und der unzulässigen Aktionen. Ein gutes Beispiel für diese Art der Berechtigung ist die FileIOPermission-Klasse, da ihr Zustand durch Listen von Dateien dargestellt wird, für die bestimmte Arten des Zugriffs zulässig sind. Berechtigungen mit Listen sind besonders für den Schutz von Ressourcen geeignet, die eine große Anzahl benannter Objekte enthalten.

Im Allgemeinen empfiehlt sich das Minimieren externer Abhängigkeiten in der benutzerdefinierten Berechtigungsklasse, da jede Assembly für die jeweilige Berechtigung geladen werden muss, wenn das Sicherheitssystem die Berechtigungsklasse benötigt. Abhängigkeiten sollten auch deshalb minimiert werden, weil jede von der benutzerdefinierten Berechtigungsklasse verwendete Assembly (ausschließlich Mscorlib) der Liste vollständig vertrauenswürdiger Assemblys hinzugefügt werden muss. (Weitere Informationen finden Sie unter Aktualisieren der Sicherheitsrichtlinien.) Platzieren Sie nach Möglichkeit die benutzerdefinierte Berechtigung sowie alle zugeordneten Attributklassen in einer separaten Assembly. Dies verringert die Wahrscheinlichkeit, dass andere Assemblys unnötig geladen werden.

Hinweis:

Benutzerdefinierte Berechtigungen müssen als versiegelt markiert werden (NotInheritable in Visual Basic), oder es muss eine Vererbungsforderung in ihnen platziert werden. Andernfalls können bösartige Aufrufer von Ihrer Berechtigung Ableitungen erstellen, was u. U. zu Sicherheitsrisiken führt.

Siehe auch

Konzepte

Erstellen von eigenen Codezugriffsberechtigungen

Weitere Ressourcen

Codezugriffssicherheit