Sicherheitsforderungen

Um sicherzustellen, dass nur Aufrufer mit einer angegebenen Berechtigung den Code aufrufen können, können Sie deklarativ oder imperativ fordern, dass Aufrufer des Codes über eine bestimmte Berechtigung oder einen bestimmten Berechtigungssatz verfügen. Eine Forderung weist die Laufzeit an, eine Sicherheitsüberprüfung auszuführen, um Einschränkungen für aufrufenden Code zu erzwingen. Bei einer Sicherheitsüberprüfung durchläuft die Laufzeit die Aufrufliste, wobei sie die Berechtigungen der einzelnen Aufrufer in der Liste untersucht und bestimmt, ob den einzelnen Aufrufern die geforderte Berechtigung gewährt wurden. Wenn ein Aufrufer ohne die geforderte Berechtigung gefunden wird, schlägt die Sicherheitsüberprüfung fehl, und es wird eine SecurityException ausgelöst. Die einzigen Forderungen, die keinen Stackwalk hervorrufen, sind Linkforderungen, bei denen jeweils nur der direkte Aufrufer überprüft wird.

Sie können festlegen, dass bei jedem Aufruf einer bestimmten Methode oder vor der Ausführung eines bestimmten Codeblocks eine Sicherheitsüberprüfung stattfindet. Wenn die Sicherheitsüberprüfung beim Aufruf eines Members einer bestimmten Klasse stattfinden soll, können Sie eine Forderung vor der Klasse platzieren, sodass diese auf jeden Member der betreffenden Klasse angewendet wird. Im weiteren Verlauf dieses Themas wird erläutert, wie Sicherheitsforderungen vorgenommen werden, wann diese ausgeführt werden sollen und weshalb ein bestimmter Typ einer Sicherheitsforderung anstelle einer anderen ausgewählt werden kann.

Wenn Sie eine Bibliothek schreiben, die direkt auf eine geschützte Ressource zugreift und dieser Zugriff für den Aufrufer verfügbar gemacht wird, müssen Sie eine Sicherheitsforderung in der Bibliothek vornehmen, um sicherzustellen, dass alle Aufrufer in der Aufrufliste über die Berechtigung für den Zugriff auf diese Ressource verfügen. Ihre Forderungen können deklarativ oder imperativ sein. Beachten Sie, dass Forderungen nie in einem Klassenkonstruktor vorgenommen werden dürfen, da Code des Klassenkonstruktors nicht unbedingt an jedem bestimmten Punkt oder in jedem bestimmten Kontext ausgeführt wird. Da der Zustand der Aufrufliste in einem Klassenkonstruktor nicht genau definiert ist, können Forderungen in Klassenkonstruktoren unerwartete und unerwünschte Ergebnisse haben.

Halten Sie sich ungeachtet des Typs von Forderung an die folgenden Richtlinien:

  • Stellen Sie sicher, dass ein Objekt nur von Aufrufern mit einer bestimmten Berechtigung erstellt werden kann, indem Sie die Forderung auf der Klassenebene des betreffenden Objekts platzieren. Angenommen, Sie verfügen über die Klasse myFileStream, die von der FileStream-Klasse abgeleitet ist. Sie möchten sicherstellen, dass nur berechtigte Aufrufer Instanzen von myFileStream erstellen können. Dazu platzieren Sie auf der Klassenebene der myFileStream-Klasse die deklarative Anforderung eines FileIOPermission-Objekts, das die Berechtigung zum Zugriff auf den von myFileStream erstellten Stream darstellt.

  • Sie können Forderungen auch zum Festlegen oder Abrufen einer Eigenschaft in Code ablegen. Grundsätzlich legen Sie Forderungen für weniger strikte Berechtigungen für den get-Accessor und nicht für den set-Accessor fest, sofern die Eigenschaft keine vertraulichen Informationen enthält, z. B. ein Kennwort.

    HinweisHinweis

    Rollenbasierte Sicherheitsüberprüfungen weisen eine etwas andere Semantik als Sicherheitsüberprüfungen des Codezugriffs auf.Weitere Informationen finden Sie unter Rollenbasierte Sicherheit.

    HinweisHinweis

    Forderungen können nur auf Klassen-, Methoden-, Ereignis- und Eigenschaftsebene angewendet werden; Assemblys und einzelne, nicht private Variablenmember werden durch Forderungen nicht geschützt.Forderungen, die auf der Ebene von Assemblys oder nicht privaten Variablen platziert werden, erzeugen keine Compilerwarnungen.Daher müssen Eigenschaften anstelle von öffentlichen Membern verwendet werden, wenn der durch Forderungen ermöglichte Schutz auch tatsächlich gewährleistet werden soll.

Siehe auch

Referenz

SecurityException

Konzepte

Codezugriffssicherheit

Erstellen von sicheren Klassenbibliotheken

Änderungsprotokoll

Datum

Versionsgeschichte

Grund

Juli 2010

Veraltete Informationen entfernt.

Korrektur inhaltlicher Fehler.