Sicherheitstransparenter Code, Ebene 1
Transparenz ermöglicht Entwicklern, sicherere .NET Framework-Bibliotheken zu erstellen, die die Funktion für teilweise vertrauenswürdigen Code verfügbar machen. Transparenz der Ebene 1 wurde in .NET Framework, Version 2.0, eingeführt und wurde hauptsächlich nur bei Microsoft verwendet. Ab .NET Framework, Version 4 kann Transparenz der Ebene 2 verwendet werden. Allerdings wurde Transparenz der Ebene 1 beibehalten, damit Legacycode identifiziert werden kann, der mit den früheren Sicherheitsregeln ausgeführt werden muss.
.gif "Wichtiger Hinweis") 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-Objekt 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. |
Dieses Thema enthält folgende Abschnitte:
Das Transparenzmodell der Ebene 1
Transparenzattribute
Beispiele für Sicherheitstransparenz
Das Transparenzmodell der Ebene 1
Wenn Sie Transparenz der Ebene verwenden, verwenden Sie ein Sicherheitsmodell, das Code in sicherheitstransparente und sicherheitsrelevante Methoden unterteilt.
Sie können eine gesamte Assembly, einige Klassen in einer Assembly oder einige Methoden in einer Klasse als sicherheitstransparent markieren. In sicherheitstransparentem Code können Berechtigungen nicht ausgeweitet werden. Diese Einschränkung hat drei Folgen:
Mit sicherheitskritischem Code können keine Assert-Aktionen ausgeführt werden.
Eine Linkanforderung, die von sicherheitstransparentem Code erfüllt würde, wird zu einer vollständigen Anforderung.
Jeder unsichere (nicht überprüfbare) Code, der in sicherheitstransparentem Code ausgeführt werden muss, führt zu einer vollständigen Anforderung für die UnmanagedCode-Sicherheitsberechtigung.
Diese Regeln werden während der Ausführung von der Common Language Runtime (CLR) erzwungen. Sicherheitstransparenter Code gibt alle Sicherheitsanforderungen des Codes, den er aufruft, an die Aufrufer zurück. Anforderungen, die durch den sicherheitstransparenten Code laufen, können keine Berechtigungen erweitern. Wenn eine Anwendung mit niedriger Vertrauenswürdigkeit sicherheitstransparenten Code aufruft und eine Anforderung für ein erweiterte Berechtigung auslöst, läuft die Anforderung zurück zum Code mit der niedrigen Vertrauenswürdigkeit und führt zu einem Fehler. Der sicherheitstransparente Code kann die Anforderung nicht anhalten, da er keine Assertionsaktionen ausführen kann. Wird der gleiche sicherheitstransparente Code von Code mit voller Vertrauenswürdigkeit aufgerufen, wird die Anforderung erfolgreich ausgeführt.
Sicherheitsrelevant ist das Gegenteil von sicherheitstransparent. Sicherheitsrelevanter Code wird mit voller Vertrauenswürdigkeit ausgeführt und ermöglicht die Ausführung aller privilegierten Operationen. Sicherheitsrelevanter Code ist privilegierter Code, für den eine umfassende Sicherheitsüberprüfung durchgeführt wurde, um zu bestätigen, dass teilweise vertrauenswürdige Aufrufer keine Möglichkeit haben, ohne entsprechende Berechtigungen auf Ressourcen zuzugreifen.
Transparenz muss explizit angewendet werden. Der meiste Code, mit dem Datenbearbeitung durchgeführt und Logik behandelt wird, kann in der Regel als sicherheitstransparent markiert werden. Weniger Code führt eine Berechtigungserweiterung durch und kann als sicherheitsrelevant markiert werden.
| Wichtig |
|---|
Die Transparenz der Ebene 1 ist auf den Assemblybereich beschränkt und wird nicht zwischen Assemblys erzwungen.Die Transparenz der Ebene 1 wurde hauptsächlich für Sicherheitsüberprüfungen von Microsoft verwendet.Sicherheitstransparenter Code in anderen Assemblys kann auf sicherheitsrelevante Typen und Member in einer Assembly der Ebene 1 zugreifen.Es ist wichtig, Verknüpfungsaufrufe für vollständige Vertrauenswürdigkeit für alle sicherheitsrelevanten Typen und Member der Ebene 1 auszuführen.Sicherheitsrelevante Typen und Member müssen auch bestätigen, dass Aufrufer Berechtigungen für geschützte Ressourcen haben, auf die vom Typ oder Member zugegriffen wird. |
Aus Gründen der Abwärtskompatibilität mit älteren Versionen von .NET Framework werden alle Member, die nicht durch Transparenzattribute gekennzeichnet sind, als sicherheitsrelevant eingestuft. Alle Typen ohne Kennzeichnung werden als transparent eingestuft. Es gibt keine statischen Analyseregeln, mit denen Transparenz überprüft werden kann. Daher müssen Sie mögliche Transparenzfehler zur Laufzeit debuggen.
Transparenzattribute
In der folgenden Tabelle werden die drei Attribute beschrieben, die Sie zum Markieren des Codes als transparent verwenden.
Attribut |
Beschreibung |
|---|---|
Ist nur auf Assemblyebene zulässig. Kennzeichnet alle Typen und Member in der Assembly als sicherheitstransparent. Die Assembly kann keinen sicherheitsrelevanten Code enthalten. |
|
Kennzeichnet bei Verwendung auf Assemblyebene ohne die Scope-Eigenschaft den gesamten Code in der Assembly standardmäßig als sicherheitstransparent, weist jedoch darauf hin, dass die Assembly sicherheitsrelevanten Code enthalten kann. Bei Verwendung auf Klassenebene wird hierdurch die Klasse oder Methode als sicherheitsrelevant gekennzeichnet, nicht jedoch die Member der Klasse. Um alle Member als sicherheitsrelevant festzulegen, legen Sie die Scope-Eigenschaft auf Everything fest. Bei Verwendung auf Memberebene wirkt sich das Attribut nur auf diesen Member aus. Klassen oder Member, die als sicherheitsrelevant gekennzeichnet sind, können Berechtigungen ausweiten. Wichtig
Im Hinblick auf Transparenz der Ebene 1 werden sicherheitsrelevante Typen und Member als sicherheitsrelevant behandelt, wenn sie von außerhalb der Assembly aufgerufen werden.Sicherheitsrelevante Typen und Member sollten mit einem Linkaufruf für vollständige Vertrauenswürdigkeit geschützt werden, um das unberechtigte Ausweiten von Berechtigungen zu verhindern.
|
|
Kennzeichnet sicherheitsrelevanten Code, auf den von sicherheitstransparentem Code in der Assembly zugegriffen werden kann. Andernfalls kann sicherheitstransparenter Code nicht private oder interne sicherheitsrelevante Mitglieder in derselben Assembly zugreifen. Dies würde sich auf den sicherheitsrelevanten Code auswirken und unerwartete Berechtigungsausweitungen ermöglichen. Sicherheitsrelevanter Code sollte einer strengen Sicherheitsüberprüfung unterzogen werden. .gif "Hinweis") Hinweis
Sicherheitsrelevante Typen und Member müssen die Berechtigungen von Aufrufern überprüfen, um zu ermitteln, ob diese berechtigt sind, auf geschützte Ressourcen zuzugreifen.
|
Mit dem SecuritySafeCriticalAttribute-Attribut wird sicherheitstransparentem Code ermöglicht, auf sicherheitsrelevante Member in derselben Assembly zuzugreifen. Betrachten Sie sicherheitstransparenten und sicherheitsrelevanten Code in der Assembly so, als wäre er in zwei einzelne Assemblys unterteilt. Der sicherheitstransparente Code könnte die privaten oder internen Member des sicherheitsrelevanten Codes dann nicht sehen. Darüber hinaus wird der sicherheitsrelevante Code normalerweise hinsichtlich des Zugriffs auf die öffentliche Schnittstelle überwacht. Sie würden nicht erwarten, dass auf einen privaten oder internen Status von außerhalb der Assembly zugegriffen werden kann, sondern dass dieser Status isoliert bleibt. Das SecuritySafeCriticalAttribute-Attribut behält die Isolation des Status zwischen dem sicherheitstransparenten und sicherheitsrelevanten Code bei und bietet gleichzeitig die Möglichkeit, die Isolation bei Bedarf zu überschreiben. Sicherheitstransparenter Code kann nicht auf privaten oder internen sicherheitsrelevanten Code zugreifen, wenn die Member nicht durch das SecuritySafeCriticalAttribute-Objekt markiert wurden. Überwachen Sie den Member so, als sei er öffentlich verfügbar, bevor Sie das SecuritySafeCriticalAttribute anwenden.
Assemblyweite Anmerkung
In der folgenden Tabelle werden die Auswirkungen der Verwendung von Sicherheitsattributen auf Assemblyebene beschrieben.
Assemblyattribut |
Assemblyzustand |
|---|---|
Kein Attribut in einer teilweise vertrauenswürdigen Assembly |
Alle Typen und Member sind transparent. |
Kein Attribut in einer vollständig vertrauenswürdigen Assembly (im globalen Assemblycache oder in der AppDomain als vollständig vertrauenswürdig identifiziert) |
Alle Typen sind transparent, und alle Member sind sicherheitsrelevant. |
SecurityTransparent |
Alle Typen und Member sind transparent. |
SecurityCritical(SecurityCriticalScope.Everything) |
Alle Typen und Member sind sicherheitsrelevant. |
SecurityCritical |
Der gesamte Code ist standardmäßig transparent. Einzelne Typen und Member können jedoch über andere Attribute verfügen. |
Beispiele für Sicherheitstransparenz
Verwenden Sie die folgende Assemblyanmerkung, um die .NET Framework 2.0-Transparenzregeln verwenden zu können (Transparenz der Ebene 1):
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Wenn Sie eine gesamte Assembly transparent machen möchten, um so zu kennzeichnen, dass die Assembly keinen wichtigen Code enthält und auf keine Weise Berechtigungen erhöhen kann, können Sie der Assembly mit dem folgenden Attribut explizit Transparenz hinzufügen:
[assembly: SecurityTransparent]
Wenn Sie sicherheitsrelevanten und sicherheitstransparenten Code in derselben Assembly verwenden möchten, markieren Sie die Assembly zunächst wie folgt mit dem SecurityCriticalAttribute-Attribut, um so zu kennzeichnen, dass die Assembly wichtigen Code enthalten kann:
[assembly: SecurityCritical]
Wenn Sie sicherheitsrelevante Aktionen durchführen möchten, müssen Sie den Code, der die entsprechende Aktion durchführen soll, explizit mit einem weiteren SecurityCriticalAttribute-Attribut markieren, wie im folgenden Beispielcode dargestellt:
[assembly: SecurityCritical]
Public class A
{
[SecurityCritical]
private void Critical()
{
// critical
}
public int SomeProperty
{
get {/* transparent */ }
set {/* transparent */ }
}
}
public class B
{
internal string SomeOtherProperty
{
get { /* transparent */ }
set { /* transparent */ }
}
}
Der vorhergehende Code ist transparent, mit Ausnahme der Critical-Methode, die explizit als sicherheitsrelevant markiert ist. Transparenz ist die Standardeinstellung, auch beim SecurityCriticalAttribute-Attribut auf Assemblyebene.