Sicherheitstransparenter Code
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. 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.
.gif "Wichtiger Hinweis") Wichtig |
|---|
Die Sicherheitsrichtlinie war ein Schlüsselelement in früheren Versionen von .NET Framework.Ab .NET Framework, Version 4 ist die Sicherheitsrichtlinie veraltet.Die Beseitigung der Sicherheitsrichtlinie geschieht getrennt von der Sicherheitstransparenz.Informationen zu den Auswirkungen dieser Änderung und Empfehlungen zum Ausgleich finden Sie unter Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit. |
In diesem Thema wird das Transparenzmodell genauer beschrieben. Sie enthält die folgenden Abschnitte:
Zweck des Transparenzmodells
Angeben der Transparenzebene
Transparenzerzwingung
Zweck des Transparenzmodells
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).
| Wichtig |
|---|
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.
.gif "Hinweis") Hinweis |
|---|
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
Angeben der Transparenzebene
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.
| Wichtig |
|---|
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
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.
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.
Transparenz der Ebene 1
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
Transparenzerzwingung
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 eher als in .NET Framework 2.0. Es ist lediglich sichergestellt, dass die Transparenzberechnung vorliegt, 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.
Zurück nach oben