Änderungen der Sicherheit in .NET Framework 4

In .NET Framework, Version 4 wurden zwei umfassende Änderungen vorgenommen. Die computerweite Sicherheitsrichtlinie wurde ausgeschlossen, obwohl das Berechtigungssystem in Kraft bleibt, und Sicherheitstransparenz wurde zum Standarderzwingungsmechanismus. (Weitere Informationen finden Sie unter Sicherheitstransparenter Code, Ebene 2.) Außerdem sind einige Berechtigungsvorgänge, die potenzielle Sicherheitslücken verursachten, nun veraltet.

Wichtig
Die Codezugriffssicherheit (CAS) wurde nicht, Sicherheitsrichtlinien wurden jedoch aus der CAS entfernt, jedoch sind Beweise und Berechtigungen weiterhin aktiv.Einige Berechtigungen werden entfernt, und durch Transparenz wurde die Erzwingung der Sicherheit vereinfacht.Eine kurze Übersicht über die Änderungen finden Sie unter Zusammenfassung der Änderungen in Bezug auf die Codezugriffssicherheit.

Dabei sollten die folgenden wesentlichen Punkte beachtet werden:

• Transparenz trennt Code, der als Teil der Anwendung von Code ausgeführt wird, der wiederum als Teil der Infrastruktur ausgeführt wird. Sie wurde in .NET Framework, Version 2.0 eingeführt und erweitert, um die Eignung als Mechanismus für die Erzwingung von Codezugriffssicherheit sicherzustellen. Im Gegensatz zur Sicherheitsrichtlinie werden Regeln für Transparenz der Ebene 2 zur Laufzeit und zur Assemblyladezeit erzwungen. Diese Regeln sind immer gültig, auch für Assemblys, die standardmäßig mit voller Vertrauenswürdigkeit ausgeführt werden. Allerdings wirkt sich Transparenz der Ebene 2 nicht auf voll vertrauenswürdigen Code aus, der nicht kommentiert ist, z. B. Desktopanwendungen. Assemblys (einschließlich Desktopassemblys), die mit SecurityTransparentAttribute markiert werden und die Methoden aufrufen, die mit dem SecurityCriticalAttribute-Objekt markiert werden, empfangen ein MethodAccessException-Objekt. Dieses Verhalten können Sie ändern, indem Sie das SecurityRulesAttribute anwenden und die SecurityRulesAttribute.RuleSet-Eigenschaft auf Level1 festlegen. Allerdings sollte dies nur aus Gründen der Abwärtskompatibilität erfolgen. Sie müssen eine Desktopanwendung explizit als sicherheitstransparent markieren, um Transparenzeinschränkungen auf diese anwenden zu können.

• In Code, in dem Sicherheitsrichtlinien-APIs aufgerufen werden, wird zur Laufzeit ein NotSupportedException-Objekt zusätzlich zu Compilerwarnungen empfangen. Die Richtlinie kann mit dem <NetFx40_LegacySecurityPolicy>- Konfigurationselement neu aktiviert werden. Wenn die Richtlinie aktiviert wird, ist die Sicherheitstransparenz nach wie vor in Kraft. Die Sicherheitsrichtlinie wird zur Assemblyladezeit angewendet und hat keine Auswirkungen auf Transparenz, die von der Laufzeit erzwungen wird.

• Die veralteten Anforderungsberechtigungen (RequestMinimum, RequestOptional und RequestRefuse) empfangen Compilerwarnungen und funktionieren in .NET Framework 4 nicht. Allerdings sorgen sie nicht für das Auslösen einer Ausnahme. Deny-Anforderungen bewirken, dass ein NotSupportedException-Objekt zur Laufzeit ausgelöst wird.

• Die LinkDemand-Sicherheitsaktion ist nicht veraltet, sollte jedoch nicht zum Überprüfen von Berechtigungen verwendet werden. Verwenden Sie das SecurityCriticalAttribute-Objekt stattdessen für Typen und Methoden, die volle Vertrauenswürdigkeit erfordern, oder verwenden Sie die Demand-Methode für Typen und Methoden, die einzelne Berechtigungen erfordern.

• Wenn die Anwendung mit Visual Studio 2010 erstellt wird, können Sie sie ohne diese Änderungen ausführen, indem Sie eine .NET Framework-Zielversion angeben, die älter als die Version .NET Framework 4 in den Visual Studio-Projekteinstellungen ist. Sie können jedoch keine neuen .NET Framework 4-Typen und -Member verwenden. Sie können auch eine frühere Version von .NET Framework angeben, indem Sie das <supportedRuntime>-Element im Starteinstellungsschema in der Anwendungskonfigurationsdatei verwenden.

In den folgenden Abschnitten werden diese und andere Änderungen in .NET Framework 4 erläutert: 

• Sicherheitsrichtlinienvereinfachung

• Sicherheitstransparenz der Ebene 2

• Veraltete Berechtigungsanforderungen

• Bedingtes APTCA

• Beweisobjekte

• Beweisauflistungen

Sicherheitsrichtlinienvereinfachung

An .NET Framework 4 ist es nicht mehr die Aufgabe der CLR (Common Language Runtime), Sicherheitsrichtlinien für Computer bereitzustellen. Früher wurde von .NET Framework eine Codezugriffssicherheitsrichtlinie (CAS) als Mechanismus bereitgestellt, um die Funktionen von verwaltetem Code genau zu steuern und zu konfigurieren. Obwohl die CAS-Richtlinie leistungsfähig ist, kann sie kompliziert und restriktiv sein. Weiterhin ist die CAS-Richtlinie nicht auf systemeigene Anwendungen anwendbar, sodass Sicherheitsgarantien beschränkt sind. Systemadministratoren wird die Verwendung von Lösungen auf Betriebssystemebene empfohlen, wie zum Beispiel Windows Software Restriction Policies (SRP) oder AppLocker unter Windows 7 und Windows Server 2008 R2 als Ersatz für die CAS-Richtlinie. SRP- und AppLocker-Richtlinien stellen einfache Vertrauensmechanismen bereit, die sowohl für verwalteten als auch für systemeigenen Code gelten. Als Sicherheitsrichtlinienlösung sind SRP und AppLocker einfacher und bieten bessere Sicherheitsgarantien als CAS.

In .NET Framework 4 werden computerweite Sicherheitsrichtlinien standardmäßig deaktiviert. Anwendungen, die nicht gehostet werden (das heißt, Anwendungen, die über Windows-Explorer oder von einer Eingabeaufforderung ausgeführt werden) werden nun mit voller Vertrauenswürdigkeit ausgeführt. Dies schließt alle Anwendungen ein, die sich auf Freigaben im lokalen Netzwerk befinden. Gehostete Anwendungen oder Sandkastenanwendungen werden weiterhin mit Vertrauensrichtlinien ausgeführt, die von ihren Hosts festgelegt werden (z. B. von Internet Explorer, ClickOnce oder ASP.NET). Anwendungen oder Steuerelemente, die in Sandkästen ausgeführt werden, gelten als teilweise vertrauenswürdig.

Zur Vereinfachung der Sicherheitsrichtlinie wurde das Transparenzmodell für .NET Framework übernommen. Anwendungen und Steuerelemente, die in einem Host oder einem Sandkasten mit dem beschränkten Berechtigungssatz ausgeführt werden, der durch den Sandkasten gewährt wurde, werden als transparent betrachtet. Transparenz bedeutet, dass Sie beim Ausführen von teilweise vertrauenswürdigen Anwendungen nicht auf die Überprüfung der CAS-Richtlinie achten müssen. Transparente Anwendungen werden nur mit ihrem Berechtigungssatz ausgeführt. Als Programmierer sollte ihr Augenmerk nur darauf liegen, dass die Anwendungen auf den Berechtigungssatz für den Sandkasten abzielen, und dass sie keinen Code aufrufen, der volle Vertrauenswürdigkeit erfordert (sicherheitskritischer Code).

Wichtig

Aufgrund dieser Sicherheitsrichtlinienänderungen treten unter Umständen Kompilierungswarnungen oder Laufzeitausnahmen auf, wenn Sie die veralteten CAS-Richtlinientypen und Member entweder explizit oder implizit (durch andere Typen oder Member) aufrufen.Eine Liste veralteter Typen und Member und deren jeweiligen Ersatz finden Sie unter Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit. Sie können die Warnungen und Fehler vermeiden, indem Sie das <NetFx40_LegacySecurityPolicy>-Konfigurationselement im Laufzeiteinstellungsschema verwenden, um das alte CAS-Richtlinienverhalten zu aktivieren.Die Verwendung der älteren Sicherheitsrichtlinie anzugeben schließt jedoch keine benutzerdefinierte CAS-Richtlinie für diese Version ein, sofern sie nicht zu .NET Framework 4 migriert wird. Sie können auch ältere CAS-Richtlinien aktivieren, indem Sie die .NET Framework-Zielversion des Visual Studio-Projekts auf eine frühere Version als .NET Framework 4 festlegen. Damit können ältere CAS-Richtlinien und sämtliche benutzerdefinierten CAS-Richtlinien verwendet werden, die Sie für diese Version angegeben haben.Sie können jedoch keine neuen .NET Framework 4-Typen und -Member verwenden.Sie können auch eine frühere Version von .NET Framework angeben, indem Sie das <supportedRuntime>-Element im Starteinstellungsschema verwenden.

Zurück nach oben

Sicherheitstransparenz der Ebene 2

Sicherheitstransparenz wurde in .NET Framework, Version 2.0 eingeführt, bot jedoch nur sehr eingeschränkte Funktionen und diente in erster Linie zur Verbesserung der Codevalidierungseffizienz. In .NET Framework 4 ist Transparenz ein Erzwingungsmechanismus, mit dem Code getrennt wird, der als Teil der Anwendung von Code ausgeführt wird, der wiederum als Teil der Infrastruktur ausgeführt wird. Transparenz unterscheidet zwischen Code, in dem privilegierte Aktionen wie das Aufrufen von systemeigenem Code ausgeführt werden können (sicherheitsrelevanter Code), und Code, in dem dies nicht möglich ist (transparenter Code). In transparentem Code können Befehle in den Grenzen des Berechtigungssatzes, in denen der Code verwendet wird, ausgeführt werden. Es ist jedoch nicht möglich, dass mit transparentem Code wichtiger Code ausgeführt, aufgerufen und davon abgeleitet wird bzw. er darf keinen wichtigen Code enthalten.

Das primäre Ziel der Transparenzerzwingung besteht darin, einen einfachen, effektiven Mechanismus für die Isolation verschiedener Codegruppen auf Grundlage von Rechten bereitzustellen. Im Sandkastenmodell sind diese Rechtegruppen entweder voll vertrauenswürdig (das heißt, sie unterliegen keine Einschränkungen) oder teilweise vertrauenswürdig (das heißt, sie sind auf den Berechtigungssatz beschränkt, der dem Sandkasten gewährt wurde).

Desktopanwendungen werden als voll vertrauenswürdig ausgeführt; daher sind sie nicht vom Transparenzmodell betroffen. Weitere Informationen über Änderungen hinsichtlich der Sicherheitstransparenz finden Sie unter Sicherheitstransparenter Code, Ebene 2.

Zurück nach oben

Veraltete Berechtigungsanforderungen

Laufzeitunterstützung wurde für die Erzwingung der Berechtigungsanforderungen Deny, RequestMinimum, RequestOptional und RequestRefuse entfernt. Im Allgemeinen lagen keine genauen Kenntnisse dieser Anforderungen vor, und sie stellten mögliche Sicherheitslücken dar, wenn sie nicht ordnungsgemäß verwendet wurden:

• Eine Deny-Aktion konnte problemlos durch eine Assert-Aktion überschrieben werden. Der Code in einer Assembly war in der Lage, eine Assert-Aktion für eine Berechtigung auszuführen, wenn die Berechtigung im Berechtigungssatz für die Assembly enthalten war. Das Assert-Feld verhinderte, dass das Deny-Feld im Stapel sichtbar war, wodurch es ineffektiv wurde.

• RequestMinimum konnte nicht effektiv außerhalb des Anwendungsbereichs verwendet werden. Wenn RequestMinimum in einer ausführbaren Datei (.exe) angezeigt wurde und der Berechtigungssatz nicht gefunden wurde, haben Endbenutzer der Datei eine nicht behandelte FileLoadException-Ausnahme empfangen, die keine Informationen zum Beheben des Problems enthielt. Sie kann kein einzelner minimaler Anforderungssatz für Bibliotheken (DLL-Dateien) verwendet werden, da unterschiedliche Typen und Member in der Assembly im Allgemeinen über andere Berechtigungsanforderungen verfügen.

• RequestOptional war verwirrend und wurde oftmals falsch verwendet, was zu unerwarteten Ergebnissen führte. Entwickler konnten Berechtigungen problemlos in der Liste weglassen, ohne zu bemerken, dass dadurch implizit die ausgelassen Berechtigungen verweigert wurden.

• RequestRefuse stellte kein effektives Modell für die geringsten Berechtigungen bereit, da anstelle der erforderlichen Berechtigungen nicht erwünschte Berechtigungen explizit identifiziert werden mussten. Zudem würden neue Berechtigungen bei Verfügbarkeit nicht in die Liste aufgenommen. Darüber hinaus war eine Ablehnung nicht für alle Berechtigungen sinnvoll. Sie können z. B. einen Wert für die UserQuota-Eigenschaft im IsolatedStoragePermission-Objekt ablehnen.

  Schließlich entstand dadurch, dass nur die nicht erwünschten Berechtigungen angegeben wurden, die Gefahr von Sicherheitslücken, wenn nicht alle potenziell schädlichen Berechtigungen identifiziert werden konnten.

• RequestOptional und RequestRefuse ermöglichten Entwicklern die Unterbrechung von homogenen Domänen durch Erstellen mehrerer Berechtigungssätze innerhalb der Domäne.

.NET Framework 4 entfernt Laufzeiterzwingung dieser Enumerationswerte. Assemblys mit Attributen, die diese SecurityAction-Werte verwenden, werden weiterhin geladen; die CLR verweigert jedoch nicht das Laden der Assemblys, auf die verwiesen wird, oder das Ändern des Berechtigungssatzes auf Basis der Berechtigungssätze.

Zurück nach oben

Bedingtes APTCA

Die bedingte Verwendung des AllowPartiallyTrustedCallersAttribute (APTCA)-Attributs ermöglicht es Hosts festzustellen, welche Assemblys für teilweise vertrauenswürdige Aufrufer verfügbar gemacht werden sollen, die innerhalb des Kontexts des Hosts geladen werden. Die entsprechenden Assemblys müssen bereits für teilweise Vertrauenswürdigkeit vorgesehen sein, d. h. es muss sich um APTCAs (sicherheitsrelevant im Transparenzmodell) oder um vollständig transparente Assemblys handeln. Ein neuer Konstruktor für die AllowPartiallyTrustedCallersAttribute-Klasse aktiviert den Host, um die Sichtbarkeitsebene für eine APTCA-Assembly mit der PartialTrustVisibilityLevel-Enumeration im Konstruktoraufruf anzugeben.

Zurück nach oben

Beweisobjekte

Vor der Version .NET Framework 4 konnte nahezu jedes Objekt als Beweisobjekt verwendet werden, falls es vom Hostcode als Beweis verwendet werden sollte. Zum Beispiel erkannten einige .NET Framework-Codes System.Uri-Objekte als Beweis an. Die Laufzeit betrachtete Beweisobjekte als System.Object-Verweise und stellte keine Typsicherheit dafür bereit.

Dies stellte ein Problem dar, da von .NET Framework implizite Einschränkungen bezüglich der als Beweisobjekte verwendbaren Typen festgelegt wurden. Insbesondere musste jedes als Beweis verwendete Objekt serialisierbar sein, und es durfte nicht NULL sein. Wurden diese Anforderungen nicht erfüllt, löste die CLR eine Ausnahme aus, wenn ein Vorgang ausgeführt wurde, für den eine dieser Annahmen erforderlich war.

Um Einschränkungen für die als Beweis verwendbaren Objekttypen festzulegen, und um neue Funktionen und Anforderungen für alle Beweisobjekte hinzufügen zu können, wird in .NET Framework 4 eine neue Basisklasse eingeführt (System.Security.Policy.EvidenceBase), von der alle Beweisobjekte abgeleitet werden müssen. Die EvidenceBase-Klasse stellt bei der Instanziierung sicher, dass das Beweisobjekt serialisierbar ist. Außerdem können neue Beweisanforderungen in Zukunft erstellt werden, indem der Basisklasse neue Standardimplementierungen hinzugefügt werden.

Abwärtskompatibilität

Alle Typen, die von der CLR als Beweisobjekte verwendet wurden, wurden in .NET Framework 4 aktualisiert und werden nun von EvidenceBase abgeleitet. Jedoch werden die von Drittanbieteranwendungen verwendeten benutzerdefinierten Beweistypen nicht erkannt und können nicht aktualisiert werden. Deshalb können diese Beweistypen nicht mit den neuen Membern verwendet werden, die von EvidenceBase abgeleitete Beweise erwarten.

Zurück nach oben

Beweisauflistungen

Vor der Version .NET Framework 4 hat die CLR den vollständigen Satz von Beweisobjekten generiert, der für eine Assembly verwendet wurde, als diese geladen wurde. Diese Objekte wurden in einer Liste gespeichert, die Consumer anschließend durchliefen, um nach einem bestimmten Objekt zu suchen. Daher wurden alle Beweise verfügbar gemacht, unabhängig davon, ob sie verwendet wurden oder nicht. Für die meisten Beweisobjekte war dieses Verhalten kein Problem; für Beweisobjekte wie z. B.System.Security.Policy.Publisher (das Authenticode-Überprüfung erfordert) war dieses Verhalten jedoch ineffizient.

Zur Verbesserung des Verhaltens wurde die Interaktion mit der Beweisauflistung in .NET Framework 4 umgestaltet. Eine Beweisauflistung verhält sich nun wie ein Wörterbuch und nicht wie eine Liste. Anstatt die Beweisauflistung zu durchlaufen, um festzustellen, ob ein erforderliches Beweisobjekt vorhanden ist, können Consumer nun einen bestimmten Beweistyp anfordern, und die Auflistung gibt den Beweis zurück, wenn er gefunden wird. Zum Beispiel wird beim Aufruf StrongName name = evidence.GetHostEvidence<StrongName>(); ein StrongName-Objekt zurückgegeben (sofern vorhanden), andernfalls wird NULL zurückgegeben.

Dieses Wörterbuchmodell verzögert die Generierung von Beweisobjekten bis zu deren Anforderung. Im Publisher-Beweisbeispiel wird der Verwaltungsaufwand für die Überprüfung der Authenticode-Signatur einer Assembly so lange verzögert, bis diese Informationen benötigt werden. Im am häufigsten vorkommenden Fall, in dem für voll vertrauenswürdige Anwendungen kein Publisher-Beweis benötigt wird, wird der Überprüfungsprozess generell vermieden.

Zurück nach oben

Siehe auch

Konzepte

Sicherheitstransparenter Code, Ebene 2

Weitere Ressourcen

Sicherheitstransparenter Code

Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit