• 30.03.2017
• 6 Minuten zu lesen
• • g
  • D
  • m
  • Y
  • s
  • +8

Sicherheit umfasst drei interagierende Teile: Sandboxing, Berechtigungen und Durchsetzung. Sandboxing bezieht sich auf die Praxis, isolierte Domänen zu erstellen, in denen ein Teil des Codes als vollständig vertrauenswürdig behandelt wird und ein anderer Teil auf die Berechtigungen im Grant-Set für die Sandbox beschränkt ist. Der Anwendungscode, der innerhalb des Berechtigungssatzes der Sandbox ausgeführt wird, gilt als transparent, d. h. er kann keine Operationen durchführen, die die Sicherheit beeinträchtigen könnten. Der Berechtigungssatz für die Sandbox wird durch Beweise (Klasse Evidence) bestimmt. Evidence gibt an, welche spezifischen Berechtigungen für Sandboxen erforderlich sind und welche Arten von Sandboxen erstellt werden können. Die Durchsetzung bezieht sich darauf, dass transparenter Code nur innerhalb seines Berechtigungssatzes ausgeführt werden darf.

Zweck des Transparenzmodells

Transparenz ist ein Durchsetzungsmechanismus, der Code, der als Teil der Anwendung ausgeführt wird, von Code trennt, der als Teil der Infrastruktur ausgeführt wird. Transparenz zieht eine Barriere zwischen Code, der privilegierte Dinge tun kann (kritischer Code), wie z.B. der Aufruf von nativem Code, und Code, der dies nicht kann (transparenter Code). Transparenter Code kann Befehle innerhalb der Grenzen des Berechtigungssatzes, in dem er operiert, ausführen, aber keinen kritischen Code ausführen, von ihm ableiten oder ihn enthalten.

Das Hauptziel der Durchsetzung von Transparenz besteht darin, einen einfachen, effektiven Mechanismus zur Isolierung verschiedener Codegruppen auf der Grundlage von Berechtigungen bereitzustellen. Im Rahmen des Sandboxing-Modells sind diese Berechtigungsgruppen entweder vollständig vertrauenswürdig (d.h. nicht eingeschränkt) oder teilweise vertrauenswürdig (d.h. eingeschränkt auf die der Sandbox gewährte Berechtigung).

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

Spezifizieren der Transparenzstufe

Das SecurityRulesAttribute auf Baugruppenebene wählt explizit die SecurityRuleSet-Regeln aus, denen die Baugruppe folgen soll. Die Regeln sind in einem numerischen Levelsystem organisiert, wobei höhere Level eine strengere Durchsetzung der Sicherheitsregeln bedeuten.

Die Level sind wie folgt:

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

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

Der Hauptunterschied zwischen den beiden Transparenzstufen besteht darin, dass Stufe 1 keine Transparenzregeln für Aufrufe von außerhalb der Assembly erzwingt und nur für die Kompatibilität gedacht ist.

Transparenz der Stufe 2

Transparenz der Stufe 2 wurde mit dem .NET Framework 4 eingeführt. Die drei Grundsätze dieses Modells sind transparenter Code, sicherheitskritischer Code und sicherheitskritischer Code.

• Transparenter Code kann, unabhängig von den ihm gewährten Berechtigungen (einschließlich vollständigem Vertrauen), nur anderen transparenten Code oder sicherheitskritischen Code aufrufen. Wenn der Code teilweise vertrauenswürdig ist, kann er nur Aktionen ausführen, die durch den Berechtigungssatz der Domäne erlaubt sind. Transparenter Code kann Folgendes nicht tun:

  • Assert-Operation oder Privilegienerweiterung durchführen.

  • unsicheren oder nicht verifizierbaren Code enthalten.

  • Direkt kritischen Code aufrufen.

  • Nativen Code oder Code mit dem Attribut SuppressUnmanagedCodeSecurityAttribute aufrufen.

  • Aufrufen eines Mitglieds, das durch eine LinkDemand geschützt ist.

  • Erben von kritischen Typen.

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

• Security-safe-kritischer Code ist vollständig vertrauenswürdig, kann aber von transparentem Code aufgerufen werden. Er legt eine begrenzte Oberfläche von voll vertrauenswürdigem Code frei. Korrektheits- und Sicherheitsüberprüfungen finden in sicherheitskritischem Code statt.

• Sicherheitskritischer Code kann jeden Code aufrufen und ist voll vertrauenswürdig, kann aber nicht von transparentem Code aufgerufen werden.

Transparenz der Stufe 1

Das Transparenzmodell der Stufe 1 wurde im .NET Framework Version 2.0 eingeführt, um Entwicklern die Möglichkeit zu geben, die Menge an Code zu reduzieren, die einer Sicherheitsüberprüfung unterliegt. Obwohl die Transparenz der Stufe 1 in Version 2.0 öffentlich verfügbar war, wurde sie in erster Linie nur innerhalb von Microsoft zu Zwecken der Sicherheitsüberprüfung verwendet. Mit Hilfe von Anmerkungen können Entwickler angeben, welche Typen und Mitglieder Sicherheitserhöhungen und andere vertrauenswürdige Aktionen durchführen können (sicherheitskritisch) und welche nicht (sicherheitstransparent). Code, der als transparent gekennzeichnet ist, erfordert kein hohes Maß an Sicherheitsüberprüfung. Transparenzstufe 1 besagt, dass die Durchsetzung der Transparenz auf die Baugruppe selbst beschränkt ist. Mit anderen Worten, alle öffentlichen Typen oder Member, die als sicherheitskritisch identifiziert werden, sind nur innerhalb der Assembly sicherheitskritisch. Wenn Sie die Sicherheit für diese Typen und Mitglieder erzwingen wollen, wenn sie von außerhalb der Baugruppe aufgerufen werden, müssen Sie Link-Anforderungen für volles Vertrauen verwenden. Wenn Sie dies nicht tun, werden öffentlich sichtbare sicherheitskritische Typen und Member als sicherheitskritisch behandelt und können von teilweise vertrauenswürdigem Code außerhalb der Assembly aufgerufen werden.

Das Transparenzmodell der Stufe 1 hat die folgenden Einschränkungen:

• Sicherheitskritische Typen und Member, die öffentlich sind, sind von sicherheitstransparentem Code aus zugänglich.

• Die Transparenzanmerkungen werden nur innerhalb einer Assembly durchgesetzt.

• Sicherheitskritische Typen und Mitglieder müssen Link-Anforderungen verwenden, um Sicherheit für Aufrufe von außerhalb der Assembly zu erzwingen.

• Vererbungsregeln werden nicht erzwungen.

• Es besteht die Möglichkeit, dass transparenter Code schädliche Dinge tut, wenn er im vollen Vertrauen ausgeführt wird.

Transparenzdurchsetzung

Transparenzregeln werden nicht durchgesetzt, bis Transparenz berechnet wird. Zu diesem Zeitpunkt wird eine InvalidOperationException ausgelöst, wenn eine Transparenzregel verletzt wird. Der Zeitpunkt, zu dem die Transparenz berechnet wird, hängt von mehreren Faktoren ab und kann nicht vorhergesagt werden. Er wird so spät wie möglich berechnet. Im .NET Framework 4 erfolgt die Transparenzberechnung auf Baugruppenebene früher als im .NET Framework 2.0. Die einzige Garantie ist, dass die Transparenzberechnung zu dem Zeitpunkt erfolgt, zu dem sie benötigt wird. Dies ist vergleichbar mit der Art und Weise, wie der Just-in-Time-Compiler (JIT) den Zeitpunkt ändern kann, zu dem eine Methode kompiliert wird und alle Fehler in dieser Methode erkannt werden. Die Transparenzberechnung ist unsichtbar, wenn Ihr Code keine Transparenzfehler aufweist.

Siehe auch

• Sicherheits-Transparenter Code, Stufe 1
• Sicherheits-Transparenter Code, Stufe 2