Sicherheitstransparenter Code, Ebene 2

Transparenz der Ebene 2 wurde in .NET Framework, Version 4 eingeführt. Die drei Grundsätze dieses Modells sind transparenter Code, sicherheitsgeschützter Code und sicherheitskritischer Code.

• In transparentem Code, einschließlich Code, der mit vollständiger Vertrauenswürdigkeit ausgeführt wird, kann nur anderer transparenter Code oder sicherheitsgeschützter Code aufgerufen werden. Es können nur Aktionen ausgeführt werden, die gemäß dem Berechtigungssatz für teilweise Vertrauenswürdigkeit der Domäne (sofern vorhanden) zulässig sind. Transparenter Code ist nicht für die folgenden Vorgänge vorgesehen:

  • Ausführen einer Assert-Methode oder Berechtigungserweiterung.

  • Der Code darf keinen unsicheren oder nicht überprüfbaren Code enthalten.

  • Direktes Aufrufen von wichtigem Code.

  • Aufrufen von systemeigenen Code oder von Code mit dem SuppressUnmanagedCodeSecurityAttribute-Attribut.

  • Aufrufen eines Members, der von einem LinkDemand-Feld geschützt wird.

  • Erben von wichtigen Typen.

  Außerdem können transparente Methoden keine wichtigen virtuellen Methoden überschreiben oder wichtige Schnittstellenmethoden implementieren.

• Sicherheitsgeschützter Code ist vollständig vertrauenswürdig, kann aber durch transparenten Code aufgerufen werden. Der Code machte einen beschränkten Oberflächenbereich mit vollständig vertrauenswürdigen Code verfügbar; Korrektheits- und Sicherheitsüberprüfungen geschehen in sicherheitsgeschütztem Code.

• Mit sicherheitskritischem Code kann jeder Code aufgerufen werden, und er ist vollständig vertrauenswürdig, kann jedoch nicht von transparentem Code aufgerufen werden.

Dieses Thema enthält folgende Abschnitte:

• Verwendungsbeispiele und Verhalten

• Überschreiben von Mustern

• Vererbungsregeln

• Zusätzliche Informationen und Regeln

Verwendungsbeispiele und Verhalten

Verwenden Sie zum Angeben von .NET Framework 4-Regeln (Transparenz der Ebene 2) die folgende Anmerkung für eine Assembly:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Um die .NET Framework 2.0-Regeln (Transparenz der Ebene 1) zu sperren, verwenden Sie die folgende Anmerkung:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Wenn Sie keine Assembly kommentieren, werden die .NET Framework 4-Regeln standardmäßig verwendet. Die empfohlene bewährte Methode besteht jedoch darin, das SecurityRulesAttribute-Attribut anstelle des Standardwerts zu verwenden.

Assemblyweite Anmerkung

Die folgenden Regeln gelten für die Verwendung von Attributen auf Assemblyebene:

• Keine Attribute: Wenn keine Attribute angegeben werden, interpretiert die Laufzeit den gesamten Code als sicherheitskritisch, es sei denn, dass durch sicherheitskritischen Code eine Vererbungsregel verletzt wird (zum Beispiel beim Überschreiben oder Implementieren einer transparenten virtuellen oder schnittstellenbezogenen Methode). In diesen Fällen sind die Methoden sicherheitsgeschützt. Wird kein Attribut angegeben, bestimmt die Common Language Runtime die Transparenzregeln für Sie.

• SecurityTransparent: Der gesamte Code ist transparent; die gesamte Assembly führt keine Berechtigungen erfordernden oder unsicheren Schritte aus.

• SecurityCritical: Der gesamte Code, der von Typen in dieser Assembly eingeführt wird, ist wichtig; der gesamte andere Code ist transparent. Dieses Szenario ist damit vergleichbar, wenn keine Attribute angegeben werden; die Common Language Runtime bestimmt die Transparenzregeln jedoch nicht automatisch. Wenn Sie zum Beispiel eine virtuelle oder abstrakte Methode überschreiben oder eine Schnittstellenmethode implementieren, ist diese Methode standardmäßig transparent. Die Methode muss als SecurityCritical oder SecuritySafeCritical explizit kommentiert werden; andernfalls wird während der Ladezeit ein TypeLoadException-Objekt ausgelöst. Diese Regel gilt auch, wenn sich sowohl die Basisklasse als auch die abgeleitete Klasse in der gleichen Assembly befinden.

• AllowPartiallyTrustedCallers (nur Ebene 2): Der gesamte Code ist standardmäßig transparent. Einzelne Typen und Member können jedoch über andere Attribute verfügen.

In der folgenden Tabelle wird das Assemblyebenenverhalten für Ebene 2 mit dem für Ebene 1 verglichen.

Assemblyattribut	Ebene 2	Ebene 1
Kein Attribut in einer teilweise vertrauenswürdigen Assembly	Typen und Member sind standardmäßig transparent, können jedoch sicherheitskritisch oder sicherheitsgeschützt sein.	Alle Typen und Member sind transparent.
Kein Attribut	Wird kein Attribut angegeben, bestimmt die Common Language Runtime die Transparenzregeln für Sie. Alle Typen und Member sind sicherheitskritisch, sofern ein sicherheitskritischer Zustand gegen eine Vererbungsregel verstößt.	In einer voll vertrauenswürdigen Assembly (im globalen Assemblycache oder als vollständige Vertrauenswürdigkeit in AppDomain identifiziert) sind alle Typen transparent, und alle Member sind sicherheitsgeschützt.
SecurityTransparent	Alle Typen und Member sind transparent.	Alle Typen und Member sind transparent.
SecurityCritical(SecurityCriticalScope.Everything)	Nicht zutreffend.	Alle Typen und Member sind sicherheitsrelevant.
SecurityCritical	Der gesamte Code, der von Typen in dieser Assembly eingeführt wird, ist wichtig; der gesamte andere Code ist transparent. Wenn Sie eine virtuelle oder abstrakte Methode überschreiben oder eine Schnittstellenmethode implementieren, müssen Sie die Methode als SecurityCritical oder SecuritySafeCritical explizit kommentieren.	Der gesamte Code ist standardmäßig transparent. Einzelne Typen und Member können jedoch über andere Attribute verfügen.

Typ- und Memberanmerkung

Die Sicherheitsattribute, die für einen Typ übernommen werden, gelten auch für die Member, die vom Typ eingeführt werden. Sie gelten jedoch nicht für virtuelle oder abstrakte Überschreibungen der Basisklasse oder der Schnittstellenimplementierungen. Die folgenden Regeln gelten für die Verwendung von Attributen auf der Typ- und Memberebene:

• SecurityCritical: Der Typ oder Member ist wichtig und kann nur von vollständig vertrauenswürdigem Code aufgerufen werden. Methoden, die in einen sicherheitskritischen Typ eingeführt werden, sind wichtig.

  Wichtig
  Virtuelle und abstrakte Methoden, die in Basisklassen oder Schnittstellen eingeführt werden und in einer sicherheitskritischen Klasse überschrieben oder implementiert werden, sind standardmäßig transparent.Sie müssen entweder als SecuritySafeCritical oder SecurityCritical identifiziert werden.

• SecuritySafeCritical: Der Typ oder Member ist sicherheitsgeschützt. Der Typ oder Member kann jedoch von transparentem (teilweise vertrauenswürdigem) Code aufgerufen werden und besitzt die gleichen Funktionen wie beliebiger anderer wichtiger Code. Der Code muss hinsichtlich Sicherheit überwacht werden.

Zurück nach oben

Überschreiben von Mustern

In der folgenden Tabelle werden die für Transparenz der Ebene 2 zulässigen Methodenüberschreibungen angezeigt.

Virtueller/Schnittstellenbezogener Basismember	Überschreiben/Schnittstelle
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

Zurück nach oben

Vererbungsregeln

In diesem Abschnitt wird die folgende Reihenfolge auf Grundlage von Zugriff und Funktionen den folgenden Codetypen zugewiesen: Transparent, Critical und SafeCritical.

Transparent < SafeCritical < Critical

• Regeln für Typen: Von links nach rechts unterliegt Zugriff stärkeren Einschränkungen. Für abgeleitete Typen müssen mindestens genau so starke Einschränkungen gelten wie für den Basistyp.

• Regeln für Methoden: Abgeleitete Methoden können keine Barrierefreiheit von der Basismethode ändern. Für das Standardverhalten sind alle abgeleiteten Methoden, die nicht kommentiert werden, Transparent. Ableitungen wichtiger Typen bewirken, dass eine Ausnahme ausgelöst wird, wenn die überschriebene Methode nicht explizit als SecurityCritical kommentiert wird.

In der folgenden Tabelle werden die zulässigen Typvererbungsmuster angezeigt.

Basisklasse	Eine abgeleitete Klasse kann die folgenden Eigenschaften besitzen:
Transparent	Transparent
Transparent	SafeCritical
Transparent	Critical
SafeCritical	SafeCritical
SafeCritical	Critical
Critical	Critical

In der folgenden Tabelle werden die unzulässigen Typvererbungsmuster angezeigt.

Basisklasse	Eine abgeleitete Klasse kann nicht folgende Eigenschaften besitzen:
SafeCritical	Transparent
Critical	Transparent
Critical	SafeCritical

In der folgenden Tabelle werden die zulässigen Methodenvererbungsmuster angezeigt.

Basismethode	Eine abgeleitete Methode kann folgende Eigenschaften besitzen:
Transparent	Transparent
Transparent	SafeCritical
SafeCritical	Transparent
SafeCritical	SafeCritical
Critical	Critical

In der folgenden Tabelle werden die unzulässigen Methodenvererbungsmuster angezeigt.

Basismethode	Eine abgeleitete Methode kann nicht die folgenden Eigenschaften besitzen:
Transparent	Critical
SafeCritical	Critical
Critical	Transparent
Critical	SafeCritical

Hinweis
Diese Vererbungsregeln gelten für Typen und Member der Ebene 2.Typen in Assemblys der Ebene 1 können von sicherheitskritischen Typen und Membern der Ebene 2 erben.Daher müssen Typen und Member der Ebene 2 gesonderte Vererbungsanforderungen für Erben der Ebene 1 besitzen.

Zurück nach oben

Zusätzliche Informationen und Regeln

LinkDemand-Unterstützung

Das Transparenzmodell der Ebene 2 ersetzt das LinkDemand-Attribut durch das SecurityCriticalAttribute-Attribut. In Legacycode (Ebene 1) wird LinkDemand automatisch als Demand behandelt.

Reflektion

Durch Aufrufen einer wichtigen Methode oder Lesen eines wichtigen Felds wird eine Anforderung nach voller Vertrauenswürdigkeit ausgelöst (dies entspricht dem Aufruf einer privaten Methode oder eines privaten Felds). Daher kann mit vollständig vertrauenswürdigem Code eine wichtige Methode aufgerufen werden, was mit teilweise vertrauenswürdigem Code nicht möglich ist.

Die folgenden Eigenschaften wurden dem System.Reflection-Namespace hinzugefügt, um zu bestimmen, ob der Typ, die Methode oder das Feld SecurityCritical, SecuritySafeCritical oder SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical und IsSecurityTransparent ist. Verwenden Sie diese Eigenschaften, um Transparenz mithilfe von Reflektion zu bestimmen, anstatt zu prüfen, ob das Attribut vorhanden ist. Die Transparenzregeln sind komplex, und die Suche nach dem Attribut ist möglicherweise nicht ausreichend.

Hinweis
Eine SafeCritical-Methode gibt true sowohl für IsSecurityCritical als auch für IsSecuritySafeCritical zurück, da SafeCritical tatsächlich wichtig ist (es besitzt die gleichen Funktionen wie kritischer Code, kann jedoch von transparentem Code aufgerufen werden).

Dynamische Methoden erben die Transparenz der Module, denen sie zugeordnet sind. Sie erben nicht die Transparenz des Typs (wenn sie einem Typ zugeordnet werden).

Überspringen der Überprüfung bei vollständiger Vertrauenswürdigkeit

Sie können die Überprüfung für vollständig vertrauenswürdige transparente Assemblys überspringen, indem Sie die SkipVerificationInFullTrust-Eigenschaft im SecurityRulesAttribute-Attribut auf true festlegen:

[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]

Die SkipVerificationInFullTrust-Eigenschaft ist standardmäßig false, sodass die Eigenschaft auf true festgelegt werden muss, um die Überprüfung zu überspringen. Dies wird nur zu Optimierungszwecken empfohlen. Stellen Sie sicher, dass der transparente Code in der Assembly mit der transparent-Option im PEVerify-Tool überprüfbar ist.

Zurück nach oben

Siehe auch

Konzepte

Sicherheitstransparenter Code, Ebene 1

Änderungen der Sicherheit in .NET Framework 4