.NET-Sicherheit - Überblick

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 Vorzüge von verwaltetem Code
 Benutzersicherheit im Vergleich zu Codesicherheit
 Rollenbasierte Sicherheit des .NET Framework
 .NET Framework-Namespaces für Sicherheit
 Zusammenfassung
 Weitere Informationen

Modulübersicht

Mithilfe der zahlreichen Methoden und Sicherheitstypen für Namespaces in Microsoft .NET Framework können Sie sicheren Code und sichere Webanwendungen erstellen. In diesem Modul wird die .NET Framework-Sicherheitslandschaft vorgestellt, indem kurz die Vorteile für die Sicherheit bei der Entwicklung von verwaltetem Code erläutert werden. Zudem werden die beiden komplementären Formen von Sicherheit beschrieben, die für .NET Framework-Anwendungen zur Verfügung stehen: Benutzersicherheit und Codesicherheit. Schließlich wird kurz dargestellt, wie Sie Namespaces für Sicherheit verwenden, um .NET Framework-Sicherheit zu programmieren.

Dieses Modul zeigt, wie Sie .NET Framework-Sicherheit für ASP.NET-Webanwendungen und Webdienste anwenden können.

 

Zielsetzung

Themenbereiche:

• Einführung in die .NET Framework-Sicherheitslandschaft.

• Vorteile für die Sicherheit durch verwalteten Code.

• Vergleich und Gegenüberstellung von rollenbasierter Sicherheit und Codezugriffsicherheit.

• Richtige Verwendung von rollenbasierter Sicherheit und von Codezugriffssicherheit.

• Überprüfen der .NET Framework-Namespaces für Sicherheit.

 

Betrifft

Die Informationen in diesem Modul gelten für folgende Produkte und Technologien:

• Microsoft Windows Server 2000 und 2003

• Microsoft .NET Framework 1.1

• ASP.NET 1.1

 

Verwendung dieses Moduls

In diesem Modul erhalten Sie Hintergrundinformationen zu den wesentlichen Begriffen hinsichtlich .NET-Sicherheit und den beiden Sicherheitsformen, die für .NET Framework-Anwendungen zur Verfügung stehen: Rollenbasierte Sicherheit und Codezugriffsicherheit. Stellen Sie sicher, dass Sie dieses Modul gelesen und diese Konzepte verstanden haben, bevor Sie Modul 8, "Codezugriffssicherheit in der Praxis", und Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET", lesen.

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

• Verständnis der beiden Verteidigungsebenen von .NET Framework. Rollenbasierte Sicherheit ermöglicht Ihnen die Steuerung des Benutzerzugriffs auf Ressourcen und Vorgänge von Anwendungen. Codezugriffssicherheit ermöglicht Ihnen zu steuern, welcher Code auf Ressourcen zugreifen und privilegierte Vorgänge ausführen kann. Codezugriffssicherheit ist abhängig von der Identität des Codes beziehungsweise davon, wer den Code veröffentlicht hat.

• Erstellen Sie Anwendungen, die die in diesem Modul beschriebenen Sicherheitskonzepte verwenden. In diesem Modul erfahren Sie, wann Sie die benutzerbasierte Sicherheit und wann Sie die codebasierte Sicherheit verwenden sollten. Nachdem Sie dieses Modul gelesen haben, sind Sie in der Lage, Ihre Anwendungen durch den Einsatz rollenbasierter oder codebasierter Sicherheit noch sicherer zu gestalten.

 

Vorzüge von verwaltetem Code

Obwohl beim Entwickeln von .NET Framework-Anwendungen einige Sicherheitsvorzüge unmittelbar zur Verfügung stehen, gibt es immer noch viele Aspekte, die gründlich durchdacht müssen. Diese Aspekte werden in Teil III dieses Handbuchs in den Modulen, deren Titel mit "Erstellen" beginnen, besprochen.

.NET Framework-Assemblys werden mit verwaltetem Code erstellt. Compiler für Programmiersprachen, wie das Entwicklungsprogramm Microsoft Visual C#® und das .NET-Entwicklungssystem Microsoft Visual Basic®, erzeugen MSIL-Anweisungen (Microsoft Intermediate Language), die in den standardmäßigen PE-Dateien (Portable Executable) von Microsoft Windows im Format .dll oder .exe enthalten sind. Wird die Assembly geladen und eine Methode aufgerufen, wird der MSIL-Code der Methode von einem JIT-Compiler (Just-in-Time) in systemeigene Maschinenanweisungen kompiliert, die anschließend ausgeführt werden. Methoden, die niemals aufgerufen werden, werden nicht JIT-kompiliert.

Durch Verwenden einer Zwischensprache in Verbindung mit der Laufzeitumgebung, die die CLR (Common Language Runtime) zur Verfügung stellt, können Assemblyentwickler unmittelbare Sicherheitsvorteile nutzen.

• Überprüfung von Dateiformat und Metadaten. Die CLR (Common Language Runtime) überprüft die PE-Datei auf Gültigkeit des Formats und darauf, dass keine Adressen aus der PE-Datei heraus verweisen. Dadurch lässt sich die Assembly leichter isolieren. Die CLR überprüft auch die Integrität der Metadaten, die in der Assembly enthalten sind.

• Codeüberprüfung. Der MSIL-Code wird auf Typensicherheit und JIT-Kompilierzeit geprüft. Dies ist aus Perspektive der Sicherheit ein wesentlicher Vorteil, da so zum Beispiel Manipulationen am Zeigegerät vermieden und Typkonvertierungen oder Arraygrenzen überprüft werden können. Dadurch wird die Anfälligkeit für Pufferüberläufe in verwaltetem Code praktisch eliminiert. Allerdings muss dennoch sorgfältig jeder Code, der nicht verwaltete APIs (Application Programming Interfaces) aufruft, auf möglichen Pufferüberlauf geprüft werden.

• Integritätsprüfung. Die Integrität von Assemblys mit starkem Namen wird mit einer digitalen Signatur überprüft. So wird gewährleistet, dass die Assembly seit ihrer Erstellung und Signatur in keiner Weise geändert wurde. Das bedeutet, dass Angreifer Ihren Code nicht durch direkte Manipulation der MSIL-Anweisungen ändern können.

• Codezugriffssicherheit. Aufgrund der virtuellen Ausführungsumgebung der CLR (Common Language Runtime) können zusätzliche Sicherheitsüberprüfungen während der Laufzeit ausgeführt werden. Insbesondere können durch Codezugriffssicherheit mehrere Sicherheitsentscheidungen während der Laufzeit, abhängig von der Identität des aufrufenden Codes, getroffen werden.

 

Benutzersicherheit im Vergleich zu Codesicherheit

Benutzersicherheit und Codesicherheit sind zwei sich ergänzende Sicherheitsformen, die für .NET Framework-Anwendungen zur Verfügung stehen. Benutzersicherheit beantwortet die Fragen "Wer ist der Benutzer, und was kann der Benutzer tun?", während Codesicherheit die Fragen beantwortet, "Woher stammt der Code, wer hat den Code geschrieben, und was kann der Code tun?" Codesicherheit umfasst die Autorisierung für den Zugriff der Anwendung (nicht des Benutzers) auf Ressourcen auf Systemebene einschließlich Dateisystem, Registrierungsdatei, Netzwerk, Verzeichnisdienste und Datenbanken. In diesem Fall ist es unerheblich, wer Endbenutzer ist, oder welches Benutzerkonto den Code ausführt. Ausschlaggebend ist, wozu der Code berechtigt ist und wozu nicht.

Die .NET Framework-Benutzersicherheitsimplementierung heißt rollenbasierte Sicherheit. Die Codesicherheitsimplementierung heißt Codezugriffssicherheit.

Rollenbasierte Sicherheit

Mithilfe der rollenbasierten Sicherheit des .NET Framework kann eine Webanwendung Sicherheitsentscheidungen abhängig von der Identität oder Rollenmitgliedschaft des Benutzers treffen, der mit der Anwendung interagiert. Wenn die Anwendung die Windows-Authentifizierung verwendet, ist eine Rolle eine Windows-Gruppe. Wenn die Anwendung andere Formen der Authentifizierung verwendet, wird die Rolle von der Anwendung festgelegt, und die Einzelheiten für Benutzer und Rolle werden in der Regel in SQL Server verwaltet oder vom Benutzer gespeichert, je nach Active Directory.

Die Identität des authentifizierten Benutzers und der zugewiesenen Rollenmitgliedschaft wird Webanwendungen durch Principal-Objekte zur Verfügung gestellt, die der aktuellen Webanforderung angehängt sind.

Abbildung 6.1 zeigt, wie die Benutzersicherheit in einer Webanwendung üblicherweise verwendet wird, um den Benutzerzugriff auf Webseiten zu begrenzen und Geschäftslogik, Vorgänge und Datenzugriff einzuschränken.

Abbildung 6.1
Eine logische Darstellung von (Benutzer-) rollenbasierter Sicherheit

Codezugriffssicherheit

Codezugriffssicherheit autorisiert Code beim Versuch, auf geschützte Ressourcen wie Dateisystem, Registrierungsdatei und Netzwerk zuzugreifen, oder beim Versuch, andere privilegierte Vorgänge auszuführen, zum Beispiel verwalteten Code aufzurufen oder Reflektion zu verwenden.

Codezugriffssicherheit ist ein wichtiger zusätzlicher Verteidigungsmechanismus, der zum Einschränken von Codeelementen verwendet werden kann. Ein Administrator kann eine Richtlinie für die Codezugriffssicherheit konfigurieren, um einzuschränken, auf welche Ressourcentypen der Code zugreifen und welche anderen privilegierten Vorgänge er ausführen kann. Die zusätzlichen Einschränkungen der Codezugriffssicherheit können das Ausmaß des Schadens für eine Webanwendung im Falle eines gefährdeten Prozesses begrenzen, wenn ein Angreifer die Kontrolle über einen Webanwendungsprozess übernimmt oder Code einfügt, der innerhalb des Prozesses ausgeführt wird.

Abbildung 6.2 zeigt, wie die Codezugriffssicherheit in einer Webanwendung verwendet wird, um den Zugriff der Anwendung auf Systemressourcen, Ressourcen von anderen Anwendungen und privilegierte Vorgänge, zum Beispiel Aufrufen von nicht verwaltetem Code, einzuschränken.

Abbildung 6.2
Logische Darstellung von codebasierter Sicherheit

Die Authentifizierung (Identifikation) von Code basiert auf eindeutigen Codemerkmalen, zum Beispiel auf dessen starken Namen, Herausgeber oder Installationsverzeichnis. Die Autorisierung basiert auf den Codezugriffsgenehmigungen, die in der Sicherheitsrichtlinie für den Code gewährt werden. Weitere Informationen zur .NET Framework-Codezugriffssicherheit finden Sie in Modul 8, "Codezugriffssicherheit in der Praxis".

 

Rollenbasierte Sicherheit des .NET Framework

Die rollenbasierte Sicherheit des .NET Framework ist eine Schlüsseltechnologie, die zum Autorisieren der Benutzeraktionen in einer Anwendung verwendet wird. Rollen werden oft genutzt, um Geschäftsregeln Nachdruck zu verleihen. In einer Finanzanwendung zum Beispiel können Überweisungen ab einem bestimmten Wert nur von Managern durchgeführt werden.

Rollenbasierte Sicherheit besteht aus den folgenden Elementen:

• Prinzipale und Identitäten

• PrincipalPermission-Objekte

• Rollenbasierte Sicherheitsüberprüfungen

• URL-Autorisierung

Prinzipale und Identitäten

Rollenbasierte Sicherheit wird mit Principal und Identity-Objekten implementiert. Identität und Rollenmitgliedschaft des authentifizierten Benutzers werden durch ein Principal-Objekt ausgedrückt, das der aktuellen Webanforderung angehängt wird. Zum Abrufen des Objekts wird die HttpContext.Current.User-Eigenschaft verwendet. Wenn die Authentifizierung eines Benutzers in der Anwendung nicht erforderlich ist, zum Beispiel wenn der Benutzer einen öffentlich zugänglichen Teil der Site durchsucht, stellt das Principal-Objekt den anonymen Internetbenutzer dar.

Es gibt viele Typen von Principal-Objekten. Der genaue Typ ist vom Authentifizierungsmechanismus abhängig, der von der Anwendung verwendet wird. In allen Principal-Objekten ist jedoch die System.Security.Principal.IPrincipal-Schnittstelle implementiert, so dass immer eine Liste aller Rollen verwaltet wird, denen der Benutzer angehört.

Principal-Objekte enthalten außerdem Identity-Objekte, die neben dem Benutzernamen auch Flags enthalten, die den Authentifizierungstyp angeben und aus denen hervorgeht, ob der Benutzer authentifiziert wurde oder nicht. Auf diese Weise kann zwischen authentifizierten und anonymen Benutzern unterschieden werden. Je nach Authentifizierungstyp gibt es verschiedene Typen von Identity-Objekten, in denen allerdings immer die System.Security.Principal.IIdentity-Schnittstelle implementiert ist.

In der folgenden Tabelle sind die möglichen Authentifizierungstypen und die unterschiedlichen Typen der Principal- und Identity-Objekte dargestellt, die von ASP.NET-Webanwendungen verwendet werden.

Tabelle 6.1: "Principal"- und "Identity"-Objekte nach Authentifizierungstyp

Authentifizierungstyp	Principal- und Identity-Typ	Bemerkungen
Windows	WindowsPrincipal + WindowsIdentity	Die Überprüfung der Anmeldeinformationen erfolgt automatisch mithilfe von Security Accounts Manager (SAM) oder Active Directory. Windows-Gruppen werden für Rollen verwendet.
Formulare	GenericPrincipal + FormsIdentity	Zum Überprüfen der Anmeldeinformationen und zum Abrufen der Rollenmitgliedschaft aus dem Benutzerspeicher muss entsprechender Code hinzugefügt werden.
Passport	GenericPrincipal + PassportIdentity	Verwendet Microsoft Passport SDK. Der Zugriff auf das Passport-Authentifizierungsticket erfolgt über PassportIdentity.

PrincipalPermission-Objekte

Das PrincipalPermission-Objekt stellt die Identität und die Rolle dar, über die der aktuelle Prinzipal verfügen muss, um den Code auszuführen. PrincipalPermission-Objekte können deklarativ oder imperativ im Code verwendet werden.

Deklarative Sicherheit

Sie können genau steuern, welche Benutzer die Berechtigung zum Zugriff auf eine Klasse oder auf eine Methode erhalten, indem Sie der Definition der Klasse oder Methode ein PrincipalPermissionAttribute hinzufügen. Ein Attribut für die Klassenstufe findet automatisch Anwendung auf alle Klassenmitglieder, sofern es nicht durch ein Attribut der Mitgliederstufe überschrieben wird. Der PrincipalPermissionAttribute-Typ wird im System.Security.Permissions-Namespace festgelegt.

Hinweis: Mithilfe von PrincipalPermissionAttribute können Sie auch den Zugriff auf Strukturen und andere Mitgliedertypen einschränken, zum Beispiel Eigenschaften und Delegierungen.

Im folgenden Beispiel wird gezeigt, wie der Zugriff auf eine bestimmte Klasse für Mitglieder der Gruppe Managers eingeschränkt wird. Beachten Sie, dass in diesem Beispiel die Windows-Authentifizierung vorausgesetzt wird, das heißt, das Format des Rollennamens entspricht dem Format MachineName\RoleName oder DomainName\RoleName. Bei anderen Authentifizierungstypen ist das Format des Rollennamens anwendungsspezifisch und von den Zeichenfolgen des Rollennamens im Benutzerspeicher abhängig.

[PrincipalPermissionAttribute(SecurityAction.Demand, Role=@"DOMAINNAME\Managers")]
public sealed class OnlyManagersCanCallMe
{
}

Hinweis: Das nachgestellte Attribut kann in der Liste der Typnamen der Attribute weggelassen werden. Dadurch erscheint der Typenname des Attributs mit dem Typennamen der zugewiesenen Genehmigung identisch zu sein, in diesem Fall PrincipalPermission. Es handelt sich um verschiedene (aber logisch verwandte) Typen.

Im nächsten Beispiel wird gezeigt, wie der Zugriff auf eine bestimmte Methode oder Klasse beschränkt wird. In diesem Beispiel wird der Zugriff auf die Mitglieder der lokalen Administratorengruppe beschränkt, die durch die besondere "BUILTIN\Administrators"-Kennung identifiziert wird.

[PrincipalPermissionAttribute(SecurityAction.Demand, 
                              Role=@"BUILTIN\Administrators")]
public void SomeMethod()
{
}

Zum Verwenden weiterer vordefinierter Windows-Gruppennamen kann dem Gruppennamen ein entsprechendes "BUILTIN\"-Präfix vorangestellt werden (zum Beispiel "BUILTIN\Users" und "BUILTIN\Power Users").

Imperative Sicherheit

Wenn die Sicherheit auf der Methodenebene nicht feinstufig genug für Ihre Sicherheitsanforderungen ist, können Sie mithilfe des System.Security.Permissions.PrincipalPermission-Objekts imperative Sicherheitsüberprüfungen im Code durchführen.

Im folgenden Beispiel wird die Syntax für imperative Sicherheit mithilfe des PrincipalPermission-Objekts dargestellt.

PrincipalPermission permCheck = new PrincipalPermission(
                                    null, @"DomainName\WindowsGroup");
permCheck.Demand();

Um eine lokale Variable zu vermeiden, kann obiger Code auch folgendermaßen geschrieben werden:

(new PrincipalPermission(null, @"DomainName\WindowsGroup")).Demand();

Der Code erstellt ein PrincipalPermission-Objekt, der Benutzername bleibt leer, der Rollenname wird angegeben. Anschließend wird die Demand-Methode aufgerufen. Dadurch wird von der CLR (Common Language Runtime) das aktuelle Principal-Objekt abgefragt, das mit dem aktuellen Thread verbunden ist, und daraufhin überprüft, ob die zugewiesene Identität ein Mitglied der angegebenen Rolle ist. Da in diesem Beispiel die Windows-Authentifizierung verwendet wird, verwendet die Rollenprüfung eine Windows-Gruppe. Wenn die aktuelle Identität kein Mitglied der angegebenen Rolle ist, wird eine SecurityException ausgelöst.

Im folgenden Beispiel wird gezeigt, wie der Zugriff auf einen einzelnen Benutzer beschränkt wird.

(new PrincipalPermission(@"DOMÄNENNAME\Jakob", null)).Demand();

Deklarative Sicherheit im Vergleich mit imperativer Sicherheit

Rollenbasierte Sicherheit (und Codezugriffssicherheit) kann entweder deklarativ mithilfe von Attributen oder imperativ im Code verwendet werden. Im Allgemeinen bietet deklarative Sicherheit die meisten Vorteile. Manchmal muss jedoch imperative Sicherheit verwendet werden (wenn Sie zum Beispiel Variablen verwenden müssen, die nur während der Laufzeit zur Verfügung stehen), um eine Sicherheitsentscheidung zu treffen.

Vorteile von deklarativer Sicherheit

Wesentliche Vorteile der deklarativen Sicherheit:

• Administratoren oder Assemblybenutzer können genau erkennen, welche Sicherheitsberechtigungen von bestimmten Klassen und Methoden ausgeführt werden müssen. Diese Informationen können zum Beispiel mithilfe von permview.exe angezeigt werden. Wenn diese Informationen während der Entwicklung zur Verfügung stehen, können Sicherheitsaspekte gelöst werden, und Administratoren können Richtlinien für die Codezugriffssicherheit konfigurieren.

• Die Leistung wird verbessert. Deklarative Befehle werden nur einmal während des Ladevorgangs ausgewertet. Imperative Befehle innerhalb von Methoden werden bei jedem Aufruf der Methode ausgewertet, die den Befehl enthält.

• Sicherheitsattribute gewährleisten, dass die Berechtigungsanforderung ausgeführt wird, bevor irgendein anderer Code gestartet werden kann, der in der Methode enthalten ist. Dadurch werden potenzielle Fehler durch zu spätes Ausführen von Sicherheitsprüfungen beseitigt.

• Deklarative Überprüfungen auf der Klassenebene werden auf alle Mitglieder der Klasse angewendet. Imperative Überprüfungen werden am Standort des Benutzers angewendet.

Vorteile von imperativer Sicherheit

Wesentliche Vorteile der imperativen Sicherheit und Gründe, warum sie manchmal verwendet werden muss:

• Der Befehl kann dynamisch geformt werden durch Verwenden von Werten, die nur während der Laufzeit zur Verfügung stehen.

• Durch Implementieren von bedingter Logik im Code kann die Autorisierung wesentlich feinstufiger ausgeführt werden.

Rollenbasierte Sicherheitsüberprüfungen

Für feinstufige Autorisierungsentscheidungen können auch explizite Rollenprüfungen mithilfe der IPrincipal.IsInRole-Methode durchgeführt werden. Im folgenden Beispiel wird die Windows-Authentifizierung vorausgesetzt. Der Code für eine Formularauthentifizierung ist jedoch ähnlich, lediglich das User-Objekt muss als Objekt vom GenericPrincipal-Typ verwendet werden.

// Extrahieren Sie den authentifizierten Benutzer aus dem aktuellen HTTP-Kontext.
// Die Benutzervariable entspricht HttpContext.Current.User, wenn Sie 
// eine ".aspx"- oder ".asmx"-Seite verwenden
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Hinweis: Wenn bestimmte Benutzer nach ihrer Identität autorisiert werden müssen
  // und nicht nach ihrer Rollenmitgliedschaft, kann der Benutzername des authentifizierten Benutzers 
  // mit der folgenden Codezeile abgerufen werden (normalerweise sollten Sie jedoch
  // eine rollenbasierte Autorisierung durchführen).
  // string username = authenticatedUser.Identity.Name;

  // Führen Sie eine Rollenprüfung durch.
  if (authenticatedUser.IsInRole(@"DomainName\Manager") )
  {
    // Benutzer ist berechtigt, Managerfunktionen auszuführen
  }
}
else
{
  // Benutzer ist nicht berechtigt, Managerfunktionen auszuführen
  // Lösen Sie eine Sicherheitsausnahme aus
}

URL-Autorisierung

Administratoren können mithilfe des <authorization>-Elements rollenbasierte Sicherheit in Machine.config oder Web.config konfigurieren. Mit diesem Element wird das ASP.NET UrlAuthorizationModule konfiguriert, das das mit der aktuellen Webanforderung verbundene principal-Objekt verwendet, um Autorisierungsentscheidungen zu treffen.

Das Autorisierungselement enthält untergeordnete <allow>- und <deny>-Elemente, die verwendet werden, um festzustellen, welchen Benutzern oder Gruppen der Zugriff auf bestimmte Verzeichnisse oder Seiten gewährt oder verweigert wurde. Sofern das <authorization>-Element nicht in einem <location>-Element enthalten ist, steuert das <authorization>-Element in Web.config den Zugriff auf das Verzeichnis, in dem die Datei Web.config enthalten ist. Normalerweise handelt es sich um das virtuelle Stammverzeichnis der Webanwendung.

Im folgenden Beispiel aus Web.config wird Windows-Authentifizierung verwendet. Lediglich Robert und Marie wird Zugriff gewährt, allen anderen Benutzern wird der Zugriff verweigert:

<authorization>
  <allow users="Domänenname\Robert, Domänenname\Marie" />
  <deny users="*" />
</authorization>

Die folgende Syntax und Semantik wird zur Konfiguration des <authorization>-Elements angewendet:

• "*" bezieht sich auf alle Identitäten.

• "?" bezieht sich auf nicht authentifizierte Identitäten (das heißt, die anonyme Identität).

• Zum Ausführen der URL-Autorisierung ist kein Identitätswechsel erforderlich.

• Benutzer und Rollen für die URL-Autorisierung sind in den Authentifizierungseinstellungen festgelegt:

  • Mit <authentication mode="Windows" /> wird der Zugriff für Windows-Benutzer und Gruppenkonten autorisiert.

    Benutzernamen entsprechen der Form "DomainName\WindowsUserName".

    Rollennamen entsprechen der Form "DomainName\WindowsGroupName".

    Hinweis: Die Gruppe der lokalen Administratoren wird als "BUILTIN\Administrators" bezeichnet. Die Gruppe der lokalen Benutzer wird als "BUILTIN\Users" bezeichnet.

  • Mit <authentication mode="Forms" /> erfolgt die Autorisierung anhand der Benutzer und der Rollen des IPrincipal-Objekts, das im aktuellen HTTP-Kontext gespeichert ist. Wenn zum Beispiel Formulare verwendet werden, um Benutzer anhand einer Datenbank zu authentifizieren, erfolgt die Autorisierung anhand der Rollen, die aus der Datenbank abgerufen werden.

  • Mit <authentication mode="Passport" /> erfolgt die Autorisierung anhand der PUID (Passport User ID) oder anhand der Rollen, die aus einem Speicher abgerufen werden. Sie können zum Beispiel eine PUID auf einem bestimmten Konto oder einer Reihe von Rollen abbilden, die in einer Microsoft SQL Server-Datenbank oder in Active Directory gespeichert sind.

  • Mit <authentication mode="None" /> kann keine Autorisierung durchgeführt werden. "None" bedeutet, dass keine Authentifizierung durchgeführt beziehungsweise keines der ASP.NET-Authentifizierungsmodule verwendet werden soll, sondern ein eigener, benutzerdefinierter Mechanismus.

    Wenn Sie eine benutzerdefinierte Authentifizierung verwenden möchten, müssen Sie ein IPrincipal-Objekt mit Rollen erstellen und in der HttpContext.Current.User-Eigenschaft speichern. Wenn später eine URL-Autorisierung durchgeführt wird, erfolgt sie gegenüber dem Benutzer und den Rollen, die im IPrincipal-Objekt verwaltet werden (unabhängig davon, wie sie abgerufen wurden).

Konfigurieren des Zugriffs auf eine bestimmte Datei

Zum Konfigurieren des Zugriffs auf eine bestimmte Datei platzieren Sie das <authorization>-Element in einem <location>-Element wie unten dargestellt.

<location path="somepage.aspx" />
  <authorization>
    <allow users="Domänenname\Robert, Domänenname\Marie" />
    <deny users="*" >
  <authorization>
</location>

Wahlweise können Sie im Attribut path auf einen bestimmten Ordner verweisen, um die Zugriffssteuerung für alle Dateien in diesem Ordner zu übernehmen. Weitere Informationen über das Element <location> finden Sie in Modul 19, "Schützen der ASP.NET-Anwendung und -Webdienste".

 

.NET Framework-Namespaces für Sicherheit

Zum Programmieren der .NET Framework-Sicherheit verwenden Sie die Sicherheitstypen in den .NET Framework-Namespaces für Sicherheit. In diesem Abschnitt werden die Namespaces und die Sicherheitstypen beschrieben, die Sie zum Entwickeln von sicheren Webanwendungen verwenden können. Eine vollständige Liste aller Sicherheitstypen finden Sie in der .NET Framework-Dokumentation. Die Namespaces für Sicherheit sind unten aufgelistet und werden in Abbildung 6.3 beschrieben.

• System.Security

• System.Web.Security

• System.Security.Cryptography

• System.Security.Principal

• System.Security.Policy

• System.Security.Permissions

Abbildung 6.3
.NET Framework-Namespaces für Sicherheit

System.Security

Dieser Namespace enthält die CodeAccessPermission-Basisklasse, von der alle anderen Typen der Codezugriffsberechtigung abgeleitet werden. Eine direkte Verwendung der Basisklasse ist unwahrscheinlich. Üblicherweise werden bestimmte Berechtigungstypen verwendet, die die Zugriffsrechte für den Code darstellen, um auf bestimmte Ressourcentypen zugreifen oder andere privilegierte Vorgänge ausführen zu können. Durch FileIOPermission zum Beispiel werden die Rechte zum Ausführen von Dateieingabe/-ausgabe dargestellt, während EventLogPermission die Rechte für den Code zur Zugriffsberechtigung auf das Ereignisprotokoll darstellt und so weiter. Eine vollständige Liste aller Typen der Codezugriffsberechtigung enthält die Tabelle 6.2 weiter unten in diesem Modul.

Der System.Security-Namespace enthält auch Klassen, die Berechtigungsgruppen kapseln. Dazu gehören die Klassen PermissionSet und NamedPermissionSet. Beim Erstellen von sicheren Webanwendungen verwenden Sie in der Regel die folgenden Typen:

• SecurityException. Der Ausnahmetyp, der zum Darstellen von Sicherheitsfehlern verwendet wird.

• AllowPartiallyTrustedCallersAttribute. Ein Attribut auf Assemblyebene, das mit Assemblys mit starkem Namen verwendet wird, die teilweise vertrauenswürdige Benutzer unterstützen müssen. Ohne dieses Attribut kann eine Assembly mit starkem Namen nur durch vollständig vertrauenswürdige Aufrufe aufgerufen werden (Benutzer mit nicht eingeschränkten Berechtigungen.)

• SupressUnmanagedSecurityAttribute. Wird verwendet, um die Leistung zu optimieren und den Bedarf nach Berechtigungen für nicht verwalteten Code zu beseitigen, der durch P/Invoke (Platform Invocation Services)- und COM (Component Object Model)-Interoperabilitätsebenen ausgelöst wird. Dieses Attribut muss mit Sorgfalt verwendet werden, da es ein potenzielles Sicherheitsrisiko offenbart. Wenn ein Angreifer die Kontrolle über nicht verwalteten Code gewinnt, unterliegt er nicht mehr den Einschränkungen der Codezugriffssicherheit. Weitere Informationen zur sicheren Verwendung dieses Attributs finden Sie in Modul 8, "Codezugriffssicherheit in der Praxis", unter "Nicht verwalteter Code".

System.Web.Security

Dieser Namespace enthält die Klassen, die zum Verwalten der Authentifizierung und Autorisierung einer Webanwendung verwendet werden. Dazu gehören Windows-, Formular- und Passport-Authentifizierung sowie URL- und Dateiautorisierung, die mithilfe der Klassen UrlAuthorizationModule beziehungsweise FileAuthorizationModule gesteuert werden. Bei der Erstellung von sicheren Webanwendungen verwenden Sie in der Regel die folgenden Typen:

• FormsAuthentication. Bietet statische Methoden, die bei der Formularauthentifizierung und der Manipulation von Authentifizierungstickets hilfreich sind.

• FormsIdentity. Wird verwendet, um die Benutzeridentität zu kapseln, die mithilfe von Formularauthentifizierung authentifiziert wird.

• PassportIdentity. Wird verwendet, um die Benutzeridentität zu kapseln, die mithilfe von Passport-Authentifizierung authentifiziert wird.

System.Security.Cryptography

Dieser Namespace enthält Typen, die zum Durchführen von Verschlüsselung und Entschlüsselung, zum Hashing und zur Erzeugung von Zufallszahlen verwendet werden. Dieser Namespace ist sehr groß und enthält viele Typen. Viele Verschlüsselungsalgorithmen werden in verwaltetem Code implementiert, andere dagegen werden durch die Typen in diesem Namespace offen gelegt und umschließen die zugrunde liegende Kryptographiefunktion von CryptoAPI auf der Basis von Microsoft Win32®.

System.Security.Principal

Dieser Namespace enthält Typen, die zur Unterstützung der rollenbasierten Sicherheit verwendet werden. Sie schränken ein, welche Benutzer auf Klassen und Klassenmitglieder zugreifen können. Der Namespace beinhaltet die Schnittstellen IPrincipal und IIdentity. Beim Erstellen von sicheren Webanwendungen verwenden Sie üblicherweise die folgenden Typen:

• GenericPrincipal und GenericIdentity. Damit können Sie eigene Rollen und Benutzeridentitäten definieren. Sie werden üblicherweise mit benutzerdefinierten Authentifizierungsmechanismen verwendet.

• WindowsPrincipal und WindowsIdentity. Stellt einen Benutzer dar, der mithilfe von Windows-Authentifizierung und der zugewiesenen Windows-Gruppenliste (Rolle) des Benutzers authentifiziert wird.

System.Security.Policy

Dieser Namespace enthält Typen, die verwendet werden, um das Richtliniensystem der Codezugriffssicherheit zu implementieren. Es umfasst Typen zum Darstellen von Codegruppen, Zugehörigkeitsbedingungen, Richtlinienebenen und Eindeutigkeit.

System.Security.Permissions

Dieser Namespace enthält die Mehrzahl der Berechtigungstypen, die zum Kapseln der Zugriffsrechte für den Code verwendet werden, um auf Ressourcen zugreifen und privilegierte Vorgänge ausführen zu können. In der folgenden Tabelle werden die in diesem Namespace definierten Berechtigungstypen in alphabetischer Reihenfolge dargestellt.

Tabelle 6.2
Berechtigungstypen im System.SecurityPermissions-Namespace

Berechtigung	Beschreibung
DirectoryServicesPermission	Erforderlich für den Zugriff auf Active Directory.
DNSPermission	Erforderlich für den Zugriff auf DNS-Server (Domain Name System) im Netzwerk.
EndpointPermission	Definiert einen Endpunkt, der durch ein SocketPermission-Objekt autorisiert wird.
EnvironmentPermission	Steuert Lese- und Schreibzugriff auf einzelne Umgebungsvariablen. Kann auch verwendet werden, um den Zugriff auf Umgebungsvariablen vollständig einzuschränken.
EventLogPermission	Erforderlich für den Zugriff auf das Ereignisprotokoll.
FileDialogPermission	Ermöglicht nur dann schreibgeschützten Zugriff auf Dateien, wenn der Dateiname vom interaktiven Benutzer in einem vom System bereitgestellten Dateidialogfeld angegeben wird. Es wird normalerweise verwendet, wenn FileIOPermission nicht gewährt wird.
FileIOPermission	Steuert Lese-, Schreib- und Datenanhängezugriff auf Dateien und Verzeichnisstrukturen. Kann auch verwendet werden, um den Zugriff auf das Dateisystem vollständig einzuschränken.
IsolatedStorageFilePermission	Steuert die Verwendung des privaten virtuellen Dateisystems einer Anwendung (durch isolierte Speicherung). Die isolierte Speicherung erstellt einen eindeutigen privaten Speicherbereich zur alleinigen Verwendung durch eine Anwendung oder Komponente.
MessageQueuePermission	Erforderlich für den Zugriff auf Microsoft Message Queuing-Warteschlangen.
OdbcPermission	Erforderlich zum Verwenden des ADO.NET ODBC-Datenproviders. (Vollständige Vertrauenswürdigkeit ist ebenfalls erforderlich.)
OleDbPermission	Erforderlich zum Verwenden des ADO.NET OLE DB-Datenproviders. (Vollständige Vertrauenswürdigkeit ist ebenfalls erforderlich.)
OraclePermission	Erforderlich zum Verwenden des ADO.NET Oracle-Datenproviders. (Vollständige Vertrauenswürdigkeit ist ebenfalls erforderlich.)
PerformanceCounterPermission	Erforderlich für den Zugriff auf Systemleistungsindikatoren.
PrincipalPermission	Wird verwendet, um den Zugriff auf Klassen und Methoden nach Benutzeridentität und Rollenmitgliedschaft einzuschränken.
PrintingPermission	Erforderlich für den Zugriff auf Drucker.
ReflectionPermission	Steuert den Zugriff auf Metadaten. Code mit der entsprechenden ReflectionPermission kann Informationen über die öffentlichen, geschützten und privaten Mitglieder eines Typs erhalten.
RegistryPermission	Steuert Lese-, Schreib- und Erstellzugriff auf Registrierungsschlüssel (einschließlich Unterschlüssel). Kann auch verwendet werden, um den Zugriff auf die Registrierungsdatei vollständig einzuschränken.
SecurityPermission	Dies ist eine Metaberechtigung, die das Verwenden der Sicherheitsinfrastruktur steuert.
ServiceControllerPermission	Kann verwendet werden, um den Zugriff auf den Windows Service Control Manager und die Möglichkeit zum Starten, Anhalten und Unterbrechen von Diensten einzuschränken.
SocketPermission	Kann verwendet werden, um die Möglichkeit zum Herstellen oder Akzeptieren einer Verbindung mit einer Transportadresse einzuschränken.
SqlClientPermission	Kann verwendet werden, um den Zugriff auf SQL Server-Datenquellen einzuschränken.
UIPermission	Kann verwendet werden, um den Zugriff auf die Zwischenablage, das Verwenden von Fenstern sowie das "Speichern" von Fenstern einzuschränken. Auf diese Weise können Angriffe vermieden werden, die Dialogfelder des Systems nachahmen und über eine Eingabeaufforderung vertrauliche Daten abfragen, zum Beispiel Kennwörter.
WebPermission	Kann verwendet werden, um den Zugriff auf HTTP-Ressourcen im Internet einzuschränken.

Die Klasse SecurityPermission erfordert besondere Aufmerksamkeit, da in ihr die Rechte für den Code definiert sind, die zum Ausführen von privilegierten Vorgängen erforderlich sind, zum Beispiel Geltend machen von Codezugriffsberechtigungen, Aufrufen von nicht verwaltetem Code, Verwenden von Reflektion oder Steuern von Richtlinien und Eindeutigkeit. Das genaue Recht wird in der Klasse SecurityPermission über die Eigenschaft Flags festgelegt. Für diese Eigenschaft muss einer der aufgelisteten Typen verwendet werden, die in SecurityPermissionFlags definiert sind (zum Beispiel SecurityPermissionFlags.UnmanagedCode).

 

Zusammenfassung

In diesem Modul erhielten Sie eine Einführung in die .NET Framework-Sicherheitslandschaft, indem Benutzersicherheit und Codesicherheit gegenübergestellt und Namespaces für Sicherheit untersucht wurden. Diese beiden Typen von Sicherheit in .NET Framework werden als rollenbasierte Sicherheit beziehungsweise Codezugriffssicherheit bezeichnet. Beide Typen von Sicherheit gehören zur obersten Ebene der Windows-Sicherheit.

Rollenbasierte Sicherheit betrifft die Genehmigung des Benutzerzugriffs auf Ressourcen (zum Beispiel Webseiten) und Vorgänge (zum Beispiel Geschäfts- und Datenzugriffslogik), die von Anwendungen verwaltet werden. Codezugriffssicherheit betrifft die Einschränkung von privilegiertem Code und die präzise Steuerung, welcher Code auf Ressourcen zugreifen und privilegierte Vorgänge ausführen kann. Durch diesen leistungsstarken zusätzlichen Sicherheitsmechanismus für Webanwendungen wird der Handlungsspielraum eines Angreifers erheblich eingeschränkt, selbst wenn es einem Angreifer gelingt, die Ausführung der Webanwendung zu beeinträchtigen. Diese äußerst leistungsfähige Funktion kann auch zur Anwendungsisolierung verwendet werden. Dies ist besonders hilfreich, wenn ein Host von mehreren Unternehmen verwendet wird oder mehrere Webanwendungen eines Unternehmens auf demselben Webserver ausgeführt werden.

 

Weitere Informationen

Weitere Informationen finden Sie in folgenden Quellen:

• Weitere Informationen über Codezugriffssicherheit und rollenbasierte Sicherheit enthält der MSDN-Artikel ".NET Framework Security" unter https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnetframeworksecurity.asp (englischsprachig).