Security-Transparent Code
 

System_CAPS_cautionAchtung

Codezugriffssicherheit und teilweise vertrauenswürdiger Code

.NET Framework bietet einen Mechanismus namens Codezugriffssicherheit (Code Access Security, CAS) zur Erzwingung verschiedener Vertrauensebenen für anderen Code, der in der gleichen Anwendung ausgeführt wird.  Die Codezugriffssicherheit sollte in .NET Framework nicht als Mechanismus zum Erzwingen von Sicherheitsbegrenzungen verwendet werden, die auf dem Codeursprung oder anderen Identitätsaspekten beruhen. Wir aktualisieren unsere Leitfäden, um darauf hinzuweisen, dass die Codezugriffssicherheit und sicherheitstransparenter Code als Sicherheitsbegrenzung bei teilweise vertrauenswürdigem Code nicht unterstützt werden, insbesondere bei Code mit unbekannter Herkunft. Wir raten davon ab, Code unbekannter Herkunft zu laden und auszuführen, ohne alternative Sicherheitsmaßnahmen zu treffen.

Diese Richtlinie gilt für alle Versionen von .NET Framework, außer für die in Silverlight enthaltene .NET Framework-Version.

Sicherheit schließt drei interagierende Elemente ein: Sandkasten, Berechtigungen und Erzwingung. Unter einem Sandkasten versteht man das Erstellen isolierter Domänen, in denen bestimmter Code als vollständig vertrauenswürdig und sonstiger Code auf die Berechtigungen im Berechtigungssatz für den Sandkasten beschränkt ist. Der Anwendungscode, der innerhalb des Berechtigungssatzes des Sandkastens ausgeführt wird, wird als transparent betrachtet, das heißt, es können keine Vorgänge ausgeführt werden, die sich auf die Sicherheit auswirken können. Der Berechtigungssatz für den Sandkasten wird durch Beweis bestimmt ( Evidence-Klasse). Beweise geben Aufschluss darüber, welche bestimmten Berechtigungen von Sandkästen benötigt werden, und welche Arten von Sandkästen erstellt werden. Erzwingung bedeutet, dass transparenter Code nur innerhalb seines Berechtigungssatzes ausgeführt werden darf.

System_CAPS_importantWichtig

Die Sicherheitsrichtlinie war ein Schlüsselelement in früheren Versionen von .NET Framework. Ab .NET Framework 4 ist die Sicherheitsrichtlinie veraltet. Die Beseitigung der Sicherheitsrichtlinie geschieht getrennt von der Sicherheitstransparenz. Informationen zu den Auswirkungen dieser Änderung finden Sie unter Code Access Security Policy Compatibility and Migration.

In diesem Thema wird das Transparenzmodell genauer beschrieben. Es enthält die folgenden Abschnitte:

  • Zweck des Transparenzmodells

  • Angeben der Transparenzebene

  • Transparenzerzwingung

Transparenz ist ein Erzwingungsmechanismus, mit dem Code, 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 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. Innerhalb des Kontexts des Sandkastenmodells 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).

System_CAPS_importantWichtig

Das Transparenzmodell geht über Codezugriffssicherheit hinaus. Transparenz wird vom Just-In-Time-Compiler erzwungen und bleibt unabhängig vom Berechtigungssatz für eine Assembly in Kraft, einschließlich vollständiger Vertrauenswürdigkeit.

Transparenz wurde in .NET Framework, Version 2.0, eingeführt, um das Sicherheitsmodell zu vereinfachen und das Schreiben und Bereitstellen von sicheren Bibliotheken und Anwendungen zu erleichtern. Transparenter Code wird auch in Microsoft Silverlight verwendet, um die Entwicklung von teilweise vertrauenswürdigen Anwendungen zu vereinfachen.

System_CAPS_noteHinweis

Wenn Sie eine teilweise vertrauenswürdige Anwendung entwickeln, beachten Sie die Berechtigungsanforderungen für die Zielhosts. Sie können eine Anwendung entwickeln, die Ressourcen verwendet, die von einigen Hosts nicht zugelassen werden. Diese Anwendung wird ohne Fehler kompiliert, schlägt jedoch fehl, wenn sie in die gehostete Umgebung geladen wird. Wenn Sie die Anwendung mit Visual Studio entwickelt haben, können Sie in der Entwicklungsumgebung das Debuggen in teilweiser Vertrauenswürdigkeit oder in einem eingeschränkten Berechtigungssatz aktivieren. Weitere Informationen finden Sie unter Gewusst wie: Debuggen einer ClickOnce-Anwendung mit eingeschränkten Berechtigungen. Die für ClickOnce-Anwendungen bereitgestellte Funktion zur Berechnung von Berechtigungen ist auch für jede beliebige teilweise vertrauenswürdige Anwendung verfügbar.

Zurück nach oben

Das SecurityRulesAttribute-Attribut auf Assemblyebene wählt explizit die SecurityRuleSet-Regeln aus, nach denen sich die Assembly richtet. Die Regeln werden unter einem System mit numerischen Ebenen organisiert, wobei höhere Ebenen eine strengere Erzwingung von Sicherheitsregeln bedeuten.

Die Ebenen lauten folgendermaßen:

  • Ebene 2 ( Level2) – die .NET Framework 4-Transparenzregeln.

  • Ebene 1 ( Level1) – die .NET Framework 2.0-Transparenzregeln.

Der primäre Unterschied zwischen den zwei Transparenzebenen besteht darin, dass auf Ebene 1 keine Transparenzregeln für Aufrufe von außerhalb der Assembly erzwungen werden und dass diese Ebene nur für Kompatibilität vorgesehen ist.

System_CAPS_importantWichtig

Geben Sie Transparenz der Ebene 1 nur für Kompatibilität an, das heißt, geben Sie Ebene 1 nur für Code an, der mit .NET Framework 3.5 oder niedriger entwickelt wurde und für den das AllowPartiallyTrustedCallersAttribute-Attribut verwendet bzw. für den das Transparenzmodell nicht verwendet wird. Verwenden Sie Transparenz der Ebene 1 z. B. für .NET Framework 2.0-Assemblys, die Aufrufe von teilweise vertrauenswürdigen Aufrufern (APTCA) ermöglichen. Verwenden Sie für Code, der für .NET Framework 4 entwickelt wird, immer Transparenz der Ebene 2.

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

  • Transparenter Code kann unabhängig von den Berechtigungen, die er erhält (einschließlich vollständiger Vertrauenswürdigkeit), nur anderen transparenten Code oder sicherheitsgeschützten Code aufrufen. Wenn der Code teilweise vertrauenswürdig ist, können nur Aktionen ausgeführt werden, die gemäß dem Berechtigungssatz der Domäne zulässig sind. Transparenter Code ist nicht für die folgenden Vorgänge vorgesehen:

    • Ausführen eines Assert-Vorgangs oder einer Berechtigungserweiterung.

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

    • Direktes Aufrufen von wichtigem Code.

    • Aufrufen von systemeigenen Code oder von Code, der das SuppressUnmanagedCodeSecurityAttribute-Attribut besitzt.

    • 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. Es macht einen beschränkten Oberflächenbereich mit vollständig vertrauenswürdigen Codes verfügbar. Korrektheits- und Sicherheitsüberprüfungen werden in sicherheitsgeschütztem Code ausgeführt.

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

Das Transparenzmodell der Ebene 1 wurde in .NET Framework, Version 2.0, eingeführt, um es Entwicklern zu ermöglichen, die Codemenge zu reduzieren, die Sicherheitsüberwachung unterliegt. Obwohl Transparenz der Ebene 1 in Version 2.0 öffentlich verfügbar war, wurde sie hauptsächlich nur bei Microsoft für Sicherheitsüberwachungszwecke verwendet. Mit Anmerkungen können Entwickler deklarieren, welche Typen und Member Sicherheitserweitungen und andere vertrauenswürdige Aktionen ausführen können (sicherheitsrelevant) und welche nicht (sicherheitstransparent). Code, der als transparent gekennzeichnet ist, erfordert keine umfassende Sicherheitsüberwachung. Transparenz der Ebene 1 gibt an, dass die Transparenzerzwingung auf die Assembly beschränkt ist. Anders ausgedrückt sind alle öffentlichen Typen oder Member, die als sicherheitskritisch eingestuft werden, nur innerhalb der Assembly sicherheitskritisch. Wenn Sie Sicherheit für diese Typen und die Member erzwingen möchten, wenn sie von außerhalb der Assembly aufgerufen werden, müssen Sie Linkaufrufe für volle Vertrauenswürdigkeit verwenden. Wenn dies nicht der Fall ist, werden öffentlich sichtbare sicherheitskritische Typen und Member als sicherheitsgeschützt behandelt und von teilweise vertrauenswürdigem Code außerhalb der Assembly aufgerufen.

Für das Transparenzmodell der Ebene 1 gelten die folgenden Einschränkungen:

  • Auf sicherheitskritische Typen und Member, die öffentlich sind, kann von sicherheitstransparentem Code zugegriffen werden.

  • Die Transparenzanmerkungen werden nur innerhalb einer Assembly erzwungen.

  • Sicherheitskritische Typen und Member müssen Sicherheit für Aufrufe von außerhalb der Assembly mithilfe von Linkaufrufen erzwingen.

  • Vererbungsregeln werden nicht erzwungen.

  • Es besteht die Möglichkeit, dass durch transparenten Code schädliche Vorgänge ausgeführt werden, wenn er mit voller Vertrauenswürdigkeit ausgeführt wird.

Zurück nach oben

Transparenzregeln werden erst erzwungen, wenn Transparenz berechnet wird. Zu diesem Zeitpunkt wird eine InvalidOperationException ausgelöst, wenn gegen eine Transparenzregel verstoßen wird. Die Zeit zur Berechnung der Transparenz hängt von mehreren Faktoren ab und kann nicht vorhergesagt werden. Sie wird so spät wie möglich berechnet. In .NET Framework 4 erfolgt die Berechnung der Transparenz auf Assemblyebene früher als in .NET Framework 2.0.  Es ist nur garantiert, dass die Transparenzberechnung ausgeführt wird, wenn sie benötigt wird. Dies ist vergleichbar mit der Änderung des Punkts durch den Just-In-Time-Compiler, an dem eine Methode kompiliert wird und Fehler in dieser Methode erkannt werden. Die Transparenzberechnung ist unsichtbar, wenn der Code keine Transparenzfehler enthält.