(0) exportieren Drucken
Alle erweitern

Modul 8 – ASP.NET-Sicherheit

Aktualisiert: 05. Mai 2004
Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
ASP.NET-Sicherheitsarchitektur ASP.NET-Sicherheitsarchitektur
Authentifizierungs- und Autorisierungsstrategien Authentifizierungs- und Autorisierungsstrategien
Konfigurieren der Sicherheit Konfigurieren der Sicherheit
Programmieren der Sicherheit Programmieren der Sicherheit
Windows-Authentifizierung Windows-Authentifizierung
Formularauthentifizierung Formularauthentifizierung
Passport-Authentifizierung Passport-Authentifizierung
Benutzerdefinierte Authentifizierung Benutzerdefinierte Authentifizierung
Prozessidentität für ASP.NET Prozessidentität für ASP.NET
Identitätswechsel Identitätswechsel
Zugreifen auf Systemressourcen Zugreifen auf Systemressourcen
Zugreifen auf COM-Objekte Zugreifen auf COM-Objekte
Zugreifen auf Netzwerkressourcen Zugreifen auf Netzwerkressourcen
Sichere Kommunikation Sichere Kommunikation
Speichern von vertraulichen Daten Speichern von vertraulichen Daten
Sichern von Sitzungs- und Ansichtsstatus Sichern von Sitzungs- und Ansichtsstatus
Überlegungen zur Webfarm Überlegungen zur Webfarm
Zusammenfassung Zusammenfassung

Modulübersicht

ASP.NET ist für die Entwicklung der in diesem Handbuch besprochenen verteilten Webanwendungen von entscheidender Bedeutung. Es stellt eine Reihe umfangreicher und leicht zugänglicher Sicherheitsfunktionen bereit, die das Erstellen sicherer Webanwendungen vereinfachen. ASP.NET ist flexibel und erweiterbar und arbeitet in Verbindung mit vorhandenen Sicherheitsfunktionen von Internetinformationsdiensten (IIS), Windows-Plattform und .NET Framework. Dadurch können Sie angepasste Sicherheitsmechanismen entwickeln, die sich nahtlos in Ihre Anwendungen integrieren lassen.

Dieses Modul enthält hilfreiche Anleitungen und Empfehlungen zu den Themen Authentifizierung, Autorisierung und sichere Kommunikation beim Erstellen sicherer ASP.NET-Webanwendungen.

Hinweis: Viele Anleitungen und Empfehlungen dieses Moduls gelten auch für die Entwicklung von ASP.NET-Webdiensten und .NET Remoting-Objekten, die von ASP.NET verwaltet werden (eine Beschreibung folgt jeweils in den Modulen 10 und 11).

Zielsetzung

Themenbereiche:

  • Sichern der ASP.NET-Anwendung

  • Sichern von vertraulichen Daten und Statusinformationen, die von ASP.NET-Anwendungen verwaltet werden

  • Einführung in die Sicherheitsarchitektur von ASP.NET-Anwendungen und Erläuterung, wie die Sicherheitsfunktionen von IIS, Windows, .NET Framework und ASP.NET zusammenarbeiten, damit Ihre Webanwendungen sicher gestaltet werden

  • Auswahl einer für Ihre Anwendung geeigneten Authentifizierungs- und Autorisierungsstrategie

  • Einführung in die Auswirkungen der ASP.NET-Prozessidentität und des Identitätswechsels auf die Fähigkeit Ihrer Anwendung, auf nachgeordnete Ressourcen wie Dateien und Datenbanken zuzugreifen

  • Implementieren des Sicherheitsentwurfs für Ihre ASP.NET-Webanwendung mithilfe einer Kombination aus Produktkonfigurationstools und Programmiertechniken

Betrifft

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

  • Windows XP oder Windows 2000 Server (mit Service Pack 3) und höhere Betriebssysteme

  • Microsoft Internetinformationsdienste (IIS) 5.0 und höher

  • Microsoft Active Directory

  • .NET Framework Version 1.0 (mit Service Pack 2)

  • Microsoft Visual Studio® 1.0 .NET und höhere Versionen

  • Visual C# .NET

  • SQL Server 2000 (mit Service Pack 2) und höhere Versionen

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Sie müssen über Erfahrung in der Programmierung mit Visual C# .NET und Visual Studio .NET verfügen.

  • Sie sollten über Erfahrung in der Entwicklung und Konfiguration von ASP.NET-Webanwendungen verfügen.

  • Sie sollten Erfahrung in der Konfiguration der IIS-Sicherheit besitzen.

  • Sie sollten über Erfahrung in der Konfiguration der Windows-Sicherheit und dem Erstellen von Benutzerkonten mithilfe der Windows-Verwaltungstools verfügen.

  • Sie müssen Erfahrung in der Konfiguration von Active Directory besitzen.

  • Sie müssen über Erfahrung bei der Entwicklung und Konfiguration von Enterprise Services-(COM+-)Anwendungen verfügen.

  • Lesen Sie Modul 1, "Einführung". Hier wird die Bedeutung von Authentifizierung, Autorisierung und sicherer Kommunikation für verteilte Webanwendungen erläutert.

  • Lesen Sie Modul 2, "Sicherheitsmodell für ASP.NET-Anwendungen". Hier finden Sie eine Übersicht der Architektur und Technologien, die bei der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Aspekte der Authentifizierung, Autorisierung und sicheren Kommunikation in diese Architektur integriert werden können.

  • Lesen Sie Modul 3, "Authentifizierung und Autorisierung". Es enthält eine Einführung in die Authentifizierungs- und Autorisierungsmechanismen, die Ihnen bei der Verwendung von ASP.NET zur Verfügung stehen.

  • Lesen Sie Modul 4, "Sichere Kommunikation". Es stellt eine Vielzahl von Technologien vor, mit denen Sie die Kommunikation zwischen ASP.NET und anderen Elementen einer verteilten Webanwendung sichern können.

  • Lesen Sie die nachfolgend angegebenen Module. Sie finden hier schrittweise Anleitungen zur Implementierung vieler in diesem Modul behandelten Techniken:

    • "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET"

    • "Vorgehensweise: Einrichten von SSL auf einem Webserver"

    • "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000"

    • "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern"

    • "Vorgehensweise: Implementieren von IPrincipal"

    • "Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000"

    • "Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory"

    • "Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung"

    • "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000"

ASP.NET-Sicherheitsarchitektur

Da ASP.NET mit IIS, .NET Framework sowie den vom Betriebssystem bereitgestellten Sicherheitsdiensten zusammenarbeitet, bietet es eine Reihe von Authentifizierungs- und Autorisierungsmechanismen. Diese Mechanismen sind in Abbildung 8.1 zusammengefasst.

ASP.NET-Sicherheitsdienste

Abbildung 8.1
ASP.NET-Sicherheitsdienste

In Abbildung 8.1 werden die Authentifizierungs- und Autorisierungsmechanismen veranschaulicht, die IIS und ASP.NET bereitstellen. Wenn ein Client eine Webanfrage startet, treten die folgenden Authentifizierungs- und Autorisierungsereignisse ein:

  1. Die HTTP(S)-Webanfrage wird vom Netzwerk empfangen. Sie können SSL verwenden, um die Serveridentität (mithilfe von Serverzertifikaten) und wahlweise die Clientidentität sicherzustellen.

    Hinweis: SSL bietet auch einen sicheren Kanal, um vertrauliche Daten zu schützen, die zwischen Client und Server (und umgekehrt) übertragen werden.

  2. IIS authentifiziert den Benutzer über die Standard-, Digest-, integrierte (NTLM oder Kerberos) oder Zertifikatsauthentifizierung. Wenn die gesamte oder ein Teil der Site keinen authentifizierten Zugriff erfordert, kann IIS für die anonyme Authentifizierung konfiguriert werden. IIS erstellt für jeden authentifizierten Benutzer ein Windows-Zugriffstoken. Wenn die anonyme Authentifizierung gewählt wurde, erstellt IIS für das anonyme Internetbenutzerkonto (standardmäßig IUSR_MACHINE) ein Zugriffstoken.

  3. IIS autorisiert den Benutzer für den Zugriff auf die angeforderte Ressource. Um den Zugriff zu autorisieren, werden durch Access Control Lists (ACLs oder Zugriffssteuerungslisten) definierte NTFS-Berechtigungen verwendet, die der angeforderten Ressource zugeordnet sind. IIS kann auch so konfiguriert werden, dass nur Anforderungen von Clientcomputern mit bestimmten IP-Adressen akzeptiert werden.

  4. IIS übergibt das authentifizierte Windows-Zugriffstoken des Benutzers an ASP.NET (hierbei kann es sich um das Zugriffstoken des anonymen Internetbenutzers handeln, wenn die anonyme Authentifizierung verwendet wird).

  5. Der Benutzer wird von ASP.NET authentifiziert.
    Wenn ASP.NET für die Windows-Authentifizierung konfiguriert ist, erfolgt an dieser Stelle keine weitere Authentifizierung. ASP.NET akzeptiert dann jedes von IIS erhaltene Token.

    Wenn ASP.NET für die Formularauthentifizierung konfiguriert ist, werden die vom Benutzer bereitgestellten Anmeldeinformationen (mithilfe eines HTML-Formulars) anhand eines Datenspeichers authentifiziert, bei dem es sich in der Regel um eine Microsoft® SQL Server-Datenbank oder einen Active Directory®-Verzeichnisdienst handelt. Wenn ASP.NET für die Passport-Authentifizierung konfiguriert ist, wird der Benutzer an eine Passport-Website weitergeleitet, wo er durch einen Passport-Authentifizierungsdienst authentifiziert wird.

  6. ASP.NET authentifiziert den Zugriff auf die angeforderte Ressource oder Operation.
    UrlAuthorizationModule (ein vom System bereitgestelltes HTTP-Modul) verwendet in der Datei web.config konfigurierte Autorisierungsregeln (insbesondere das <authorization>-Element), um sicherzustellen, dass der Benutzer auf die angeforderte Datei oder den Ordner zugreifen kann.

    Bei der Windows-Authentifizierung prüft FileAuthorizationModule (ein weiteres HTTP-Modul), ob der Benutzer über die erforderlichen Berechtigungen verfügt, um auf die angeforderte Ressource zugreifen zu können. Das Zugriffstoken des Benutzers wird mit der ACL verglichen, die diese Ressource schützt.

    Sie können .NET-Rollen verwenden (entweder deklarativ oder programmatisch), um sicherzustellen, dass der Benutzer für den Zugriff auf die angeforderte Ressource oder die Durchführung der angeforderten Operation autorisiert ist.

  7. Der Code in der Anwendung greift mithilfe einer bestimmten Identität auf lokale und/oder Remoteressourcen zu. ASP.NET führt standardmäßig keinen Identitätswechsel durch, weshalb das konfigurierte ASP.NET-Prozesskonto die Identität bereitstellt. Alternative Optionen umfassen die Identität des ursprünglichen Benutzers (falls der Identitätswechsel aktiviert ist) oder eine konfigurierte Dienstidentität.

Gatekeeper

Die Autorisierungspunkte (oder Gatekeeper) in einer ASP.NET-Webanwendung werden von IIS und ASP.NET bereitgestellt:

IIS

Bei deaktivierter anonymer Authentifizierung gestattet IIS nur Anforderungen von Benutzern, die entweder in einer eigenen oder in einer vertrauenswürdigen Domäne authentifiziert werden können.

Bei statischen Dateitypen (z. B. JPG, GIF- und HTM-Dateien, d. h. Dateien, die nicht einer ISAPI-Erweiterung zugeordnet sind) verwendet IIS die NTFS-Berechtigungen zur Zugriffssteuerung, die der angeforderten Datei zugeordnet sind.

ASP.NET

Zu den ASP.NET-Gatekeepern gehören UrlAuthorizationModule, FileAuthorizationModule sowie Hauptberechtigungen und Rollenüberprüfungen.

UrlAuthorizationModule

Sie können <authorization>-Elemente in der Datei web.config konfigurieren, um zu steuern, welche Benutzer und Benutzergruppen Zugriff auf die Anwendung erhalten sollen. Die Autorisierung basiert auf dem IPrincipal-Objekt, das in HttpContext.User gespeichert ist.

FileAuthorizationModule

Für Dateitypen, die von IIS der ASP.NET ISAPI-Erweiterung (Aspnet_isapi.dll) zugeordnet sind, werden anhand des authentifizierten Windows-Zugriffstokens des Benutzers (z. B. IUSR_MACHINE) automatische Zugriffsüberprüfungen mit der ACL durchgeführt, die der angeforderten ASP.NET-Datei zugeordnet ist.

Hinweis: Der Identitätswechsel ist für eine funktionierende Dateiautorisierung nicht erforderlich.

Die FileAuthorizationModule-Klasse führt Zugriffsüberprüfungen nur für die angeforderte Datei und nicht für Dateien durch, auf die der Code in der angeforderten Seite zugreift, obwohl für diese eine Zugriffsüberprüfung durch IIS erfolgt.

Wenn Sie z. B. die Datei Default.aspx anfordern und diese ein eingebettetes Benutzersteuerelement (Usercontrol.ascx) enthält, das wiederum ein Bildtag (Verweis auf Image.gif) einbezieht, führt FileAuthorizationModule eine Zugriffsüberprüfung für Default.aspx und Usercontrol.ascx durch, da IIS diese Dateitypen der ASP.NET ISAPI-Erweiterung zuordnet.

FileAuthorizationModule führt keine Überprüfung für Image.gif durch, da es sich hierbei um eine statische Datei handelt, die IIS intern behandelt. Da jedoch Zugriffsüberprüfungen für statische Dateien von IIS durchgeführt werden, ist dem authentifizierten Benutzer weiterhin mit einer ordnungsgemäß konfigurierten ACL die Leseberechtigung für die Datei zu erteilen.

Dieses Szenario ist in Abbildung 8.2 dargestellt.

Hinweis für Systemadministratoren: Der authentifizierte Benutzer muss für alle im Szenario einbezogenen Dateien die NTFS-Leseberechtigung besitzen. Die einzige Variable stellt der Gatekeeper dar, der zum Durchsetzen der Zugriffssteuerung gewählt wird. Das ASP.NET-Prozesskonto erfordert lediglich den Lesezugriff auf die in ASP.NET registrierten Dateitypen.

Zusammenarbeit der IIS und ASP.NET-Gatekeeper

Abbildung 8.2
Zusammenarbeit der IIS und ASP.NET-Gatekeeper

In diesem Szenario können Sie den Zugriff am Dateigate verhindern. Wenn Sie die der Datei Default.aspx zugeordnete ACL konfigurieren und den Zugriff für einen bestimmten Benutzer verweigern, werden weder das Benutzersteuerelement noch eingebettete Bilder über den Code in Default.aspx an den Client gesendet.

Hauptberechtigungen und explizite Rollenüberprüfungen

Zusätzlich zu den konfigurierbaren IIS- und ASP.NET-Gatekeepern können Sie auch Hauptberechtigungen (deklarativ oder programmatisch) als zusätzlichen feinstufigen Zugriffssteuerungsmechanismus verwenden. Hauptberechtigungsüberprüfungen (von der PrincipalPermissionAttribute-Klasse durchgeführt) ermöglichen es, basierend auf der Identität und Gruppenmitgliedschaft einzelner Benutzer den Zugriff auf Klassen, Methoden oder einzelne Codeblöcke gemäß der Definition des IPrincipal-Objekts zu steuern, das dem aktuellen Thread zugeordnet ist.

Hinweis: Die zum Anfordern der Rollenmitgliedschaft verwendeten PrincipalPermission-Befehle unterscheiden sich vom Aufrufen von IPrincipal.IsInRole zum Testen der Rollenmitgliedschaft. Ersteres führt zu einer Ausnahmebedingung, wenn der Benutzer kein Mitglied der angegebenen Rolle ist, während im letzteren Fall einfach ein Boole'scher Wert zurückgegeben wird, um die Rollenmitgliedschaft zu bestätigen.

Bei der Windows-Authentifizierung hängt ASP.NET automatisch das WindowsPrincipal-Objekt an, das den authentifizierten Benutzer für die aktuelle Webanforderung (unter Verwendung von HttpContext.User) darstellt. Bei der Formular- und der Passport-Authentifizierung wird ein GenericPrincipal-Objekt mit der entsprechenden Identität und ohne Rollen erstellt und HttpContext.User zugeordnet.

Weitere Informationen

  • Weitere Informationen zum Konfigurieren der Sicherheit erhalten Sie im Abschnitt "Konfigurieren der Sicherheit" weiter unten in diesem Modul.

  • Weitere Informationen zum Programmieren der Sicherheit (und zu IPrincipal-Objekten) erhalten Sie im Abschnitt "Programmieren der Sicherheit" weiter unten in diesem Modul.

Authentifizierungs- und Autorisierungsstrategien

ASP.NET bietet eine Reihe von deklarativen und programmatischen Autorisierungsmechanismen, die zusammen mit einer Vielzahl von Authentifizierungsschemata verwendet werden können. Dadurch können Sie eine ausführliche Autorisierungsstrategie entwickeln sowie eine Strategie, die zum Bereitstellen verschiedener Feinstufigkeitsgrade konfiguriert werden kann, z. B. auf Benutzer- oder Benutzergruppenbasis (rollenbasiert).

In diesem Abschnitt wird erläutert, welche Autorisierungsoptionen (sowohl konfigurierbar als auch programmatisch) für eine Reihe häufig verwendeter Authentifizierungsoptionen zur Verfügung stehen.

Die im Folgenden beschriebenen Optionen werden hier kurz zusammengefasst:

  • Windows-Authentifizierung mit Identitätswechsel

  • Windows-Authentifizierung ohne Identitätswechsel

  • Windows-Authentifizierung mit fester Identität

  • Formularauthentifizierung

  • Passport-Authentifizierung

Verfügbare Autorisierungsoptionen

In der folgenden Tabelle werden die verfügbaren Autorisierungsoptionen aufgeführt. Sie zeigt für jede Option an, ob Windows-Authentifizierung und/oder Identitätswechsel erforderlich sind. Wenn die Windows-Authentifizierung nicht erforderlich ist, steht die zugehörige Autorisierungsoption für alle anderen Authentifizierungstypen zur Verfügung. Verwenden Sie die Tabelle, um Ihre Authentifizierungs-/Autorisierungsstrategie zu optimieren.

Tabelle 8.1: Windows-Authentifizierung mit Identitätswechsel

Autorisierungsoption

Erfordert Windows-Authentifizierung

Erfordert Identitätswechsel

FileAuthorizationModule

Ja

Nein

UrlAuthorizationModule

Nein

Nein

PrincipalPermission-Befehle

Nein

Nein

.NET-Rollen

Nein

Nein

Enterprise Services-Rollen

Ja

Ja (innerhalb der ASP.NET-Webanwendung)

NTFS-Berechtigungen (für direkt angeforderte statische Dateitypen; ohne Zuordnung zu einer ISAPI-Erweiterung)

N/V – Diese Dateien werden nicht von ASP.NET
bearbeitet. Mit jedem (nicht anonymen) IIS-Authentifizierungsmechanismus sollten Berechtigungen für einzeln authentifizierte Benutzer konfiguriert werden.
Bei der anonymen Authentifizierung sollten Berechtigungen für IUSR_MACHINE konfiguriert werden.

Nein (IIS führt die Zugriffsüberprüfung durch)

NTFS-Berechtigungen (für Dateien, auf die Webanwendungscode zugreift)

Nein

Nein
Beim Identitätswechsel konfigurieren Sie die ACLs für die gewechselte Windows-Identität, bei der es sich entweder um den ursprünglichen Benutzer oder um die Identität handelt, die im <identity>-Element in der Datei web.config angegeben ist.

Windows-Authentifizierung mit Identitätswechsel

Die folgenden Konfigurationselemente zeigen, wie die Windows-Authentifizierung (IIS) und der Identitätswechsel deklarativ in der Datei web.config oder machine.config aktiviert werden.

Hinweis: Konfigurieren Sie die Authentifizierung auf Anwendungsbasis jeweils in der Datei web.config.

<authentication mode="Windows" />
<identity impersonate="true" />

Bei dieser Konfiguration nimmt der ASP.NET-Anwendungscode die Identität des für IIS authentifizierten Benutzers an.

Konfigurierbare Sicherheit

Wenn Sie die Windows-Authentifizierung zusammen mit dem Identitätswechsel verwenden, stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

  • Windows-ACLs

    • Vom Client angeforderte Ressourcen – Die FileAuthorizationModule-Klasse von ASP.NET führt Zugriffsüberprüfungen für angeforderte Dateitypen durch, die der ASP.NET ISAPI zugeordnet sind. Sie verwendet dazu das Zugriffstoken des ursprünglichen Benutzers sowie die ACL, die den angeforderten Ressourcen zugeordnet ist.
      Für statische Dateitypen (keiner ISAPI-Erweiterung zugeordnet) führt IIS Zugriffsüberprüfungen durch, wobei das Zugriffstoken des Benutzers sowie die der Datei zugeordnete ACL verwendet werden.

    • Ressourcen, auf die die Datei zugreift – Sie können Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel, Active Directory-Objekte usw.), anhand des ursprünglichen Benutzers konfigurieren.

  • URL-Autorisierung – Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Windows-Authentifizierung weisen Benutzernamen die Form DomainName\UserName auf, während Rollen den Windows-Gruppen 1:1 zugeordnet werden.

    <authorization>
      <deny user="DomainName\UserName" />
      <allow roles="DomainName\WindowsGroup" />
    </authorization>
    
  • Enterprise Services-(COM+-)Rollen – Rollen werden im COM+-Katalog verwaltet. Sie können Rollen mit dem Verwaltungsprogramm oder -skript für Komponentendienste verwenden.

Programmatische Sicherheit

Die programmatische Sicherheit bezieht sich auf Sicherheitsprüfungen, die sich im Webanwendungscode befinden. Die folgenden programmatischen Sicherheitsoptionen stehen Ihnen zur Verfügung, wenn Sie die Windows-Authentifizierung und den Identitätswechsel verwenden.

  • PrincipalPermission-Befehle

    • Imperativ (inline im Code einer Methode enthalten)

          PrincipalPermission permCheck = new PrincipalPermission(
                                             null, @"DomainName\WindowsGroup");
          permCheck.Demand();
      
    • Deklarativ (Attribute, die Schnittstellen, Klassen und Methoden voranstellen)

      [PrincipalPermission(SecurityAction.Demand, 
                        Role=@"DomainName\WindowsGroup)]
      
  • Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

    IPrincipal.IsInRole(@"DomainName\WindowsGroup");
    
  • Enterprise Services-(COM+-)Rollen – Sie können die Rollenüberprüfungen mithilfe der IPrincipal-Klasse programmatisch durchführen.

    ContextUtil.IsCallerInRole("Manager")
    
Verwendungshinweise

Verwenden Sie die Windows-Authentifizierung und den Identitätswechsel, wenn Folgendes zutrifft:

  • Die Benutzer Ihrer Anwendung verfügen über Windows-Konten, die vom Server authentifiziert werden können.

  • Sie müssen den Sicherheitskontext des ursprünglichen Benutzers an die mittlere und/oder die Datenebene der Webanwendung weitergeben, um eine feinstufige Autorisierung (auf Benutzerbasis) zu unterstützen.

  • Sie müssen den Sicherheitskontext des ursprünglichen Benutzers an die nachgeordneten Datenebenen weitergeben, um die Überwachung auf Betriebssystemebene zu unterstützen.

Bevor Sie den Identitätswechsel in Ihrer Anwendung verwenden, machen Sie sich mit den relativen Vor- und Nachteilen dieses Ansatzes im Vergleich zum Modell der vertrauenswürdigen Subsysteme vertraut. Diese Vor- und Nachteile werden in Modul 3, "Authentifizierung und Autorisierung", im Abschnitt "Autorisierungsansätze" unter "Auswählen eines Ressourcenzugriffsmodells" erläutert.

Folgendes zählt zu den Nachteilen des Identitätswechsels:

  • Verringerte Skalierbarkeit von Anwendungen, da man Datenbankverbindungen nicht effektiv zusammenfassen kann.

  • Erhöhter Verwaltungsaufwand, da ACLs für Back-End-Ressourcen für einzelne Benutzer konfiguriert werden müssen.

  • Die Delegierung erfordert eine Kerberos-Authentifizierung und eine entsprechend konfigurierte Umgebung.

Weitere Informationen

  • Weitere Informationen zur Windows-Authentifizierung finden Sie unter "Windows-Authentifizierung" weiter unten in diesem Modul.

  • Weitere Informationen zum Identitätswechsel finden Sie unter "Identitätswechsel" weiter unten in diesem Modul.

  • Weitere Informationen zur URL-Autorisierung erhalten Sie unter "Hinweise zur URL-Autorisierung" weiter unten in diesem Modul.

  • Weitere Informationen zu Enterprise Services-(COM+-)Rollen finden Sie in Modul 9, "Enterprise Services-Sicherheit".

Windows-Authentifizierung ohne Identitätswechsel

Die folgenden Konfigurationselemente zeigen, wie die Windows-Authentifizierung (IIS) und der Identitätswechsel deklarativ in der Datei web.config aktiviert werden.

<authentication mode="Windows" />
<!-- Die nachfolgende Einstellung entspricht dem Zustand, in dem kein Identity-Element vorhanden ist -->
<identity impersonate="false" />
Konfigurierbare Sicherheit

Wenn Sie die Windows-Authentifizierung ohne Identitätswechsel verwenden, stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

  • Windows-ACLs

    • Vom Client angeforderte Ressourcen – Die FileAuthorizationModule-Klasse von ASP.NET führt Zugriffsüberprüfungen für angeforderte Dateitypen durch, die der ASP.NET ISAPI zugeordnet sind. Sie verwendet dazu das Zugriffstoken des ursprünglichen Benutzers sowie die ACL, die den angeforderten Ressourcen zugeordnet ist. Der Identitätswechsel ist nicht erforderlich.
      Für statische Dateitypen (keiner ISAPI-Erweiterung zugeordnet) führt IIS Zugriffsüberprüfungen durch, wobei sie das Zugriffstoken des Benutzers sowie die der Datei zugeordnete ACL verwendet.

    • Ressourcen, auf die die Datei zugreift – Konfigurieren Sie Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel, Active Directory-Objekte usw.), anhand der ASP.NET-Prozessidentität.

  • URL-Autorisierung – Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Windows-Authentifizierung weisen Benutzernamen die Form DomainName\UserName auf, während Rollen den Windows-Gruppen 1:1 zugeordnet werden.

    <authorization>
      <deny user="DomainName\UserName" />
      <allow roles="DomainName\WindowsGroup" />
    </authorization>
    
Programmatische Sicherheit

Die folgenden programmatischen Sicherheitsoptionen sind verfügbar:

  • PrincipalPermission-Befehle

    • Imperativ

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

      [PrincipalPermission(SecurityAction.Demand, 
                        Role=@"DomainName\WindowsGroup")]
      
  • Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

    IPrincipal.IsInRole(@"DomainName\WindowsGroup");
    
Verwendungshinweise

Verwenden Sie die Windows-Authentifizierung ohne Identitätswechsel, wenn Folgendes zutrifft:

  • Die Benutzer Ihrer Anwendung verfügen über Windows-Konten, die vom Server authentifiziert werden können.

  • Sie möchten eine feste Identität für den Zugriff auf nachgeordnete Ressourcen verwenden (z. B. Datenbanken), um das Verbindungspooling zu unterstützen.

Weitere Informationen

Windows-Authentifizierung mit fester Identität

Das <identity>-Element in der Datei web.config unterstützt optionale Benutzernamen- und Kennwortattribute. Dadurch können Sie für Ihre Anwendung eine bestimmte feste Identität für den Identitätswechsel konfigurieren. Dies wird im folgenden Fragment der Konfigurationsdatei veranschaulicht.

<identity impersonate="true"
          userName="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,userName"
          password="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,password" />

Das Beispiel zeigt das <identity>-Element. Die Anmeldeinformationen sind in der Registrierung mithilfe des Dienstprogramms aspnet_setreg.exe verschlüsselt worden. Die Klartextwerte für die Attribute Benutzername und Kennwort wurden durch Zeiger ersetzt, die auf den gesicherten Registrierungsschlüssel und benannte Werte verweisen, die die verschlüsselten Anmeldeinformationen enthalten. Einzelheiten zu diesem Dienstprogramm und zum Download finden Sie im Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig), in der Microsoft Knowledge Base.

Verwendungshinweise

Der Wechsel zu festen Identitäten wird nicht empfohlen, wenn das .NET Framework 1.0 auf Servern unter Windows 2000 verwendet wird. Denn in diesem Fall müssten Sie dem ASP.NET-Prozesskonto das weitreichende Recht Als Teil des Betriebssystems handeln erteilen. Dieses Recht wird vom ASP.NET-Prozess benötigt, da er anhand der von Ihnen angegebenen Anmeldeinformationen einen LogonUser-Aufruf ausführt.

Hinweis: Das .NET Framework Version 1.1 stellt für dieses Szenario unter Windows 2000 eine Erweiterung bereit. Die Anmeldung wird vom IIS-Prozess durchgeführt, damit ASP.NET das Recht Als Teil des Betriebssystems handeln nicht erfordert.

Formularauthentifizierung

Die folgenden Konfigurationselemente zeigen, wie die Formularauthentifizierung deklarativ in der Datei web.config aktiviert wird.

<authentication mode="Formulare">
  <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/">
  </forms>
</authentication>
Konfigurierbare Sicherheit

Bei der Formularauthentifizierung stehen Ihnen die folgenden Autorisierungsoptionen zur Verfügung:

  • Windows-ACLs

    • Vom Client angeforderte Ressourcen – Angeforderte Ressourcen erfordern ACLs, die den Lesezugriff auf das anonyme Internetbenutzerkonto zulassen. (IIS sollte so konfiguriert sein, dass bei der Formularauthentifizierung der anonyme Zugriff ermöglicht wird).
      Die ASP.NET-Dateiautorisierung steht nicht zur Verfügung, da sie die Windows-Authentifizierung erfordert.

    • Ressourcen, auf die die Datei zugreift – Konfigurieren Sie Windows-ACLs von Ressourcen, auf die Ihre Anwendung zugreift (Dateien, Ordner, Registrierungsschlüssel und Active Directory-Objekte), anhand der ASP.NET-Prozessidentität.

  • URL-Autorisierung

    Konfigurieren Sie die URL-Autorisierung in der Datei web.config. Bei der Formularauthentifizierung wird das Format von Benutzernamen durch den benutzerdefinierten Datenspeicher bestimmt (eine SQL Server-Datenbank oder Active Directory).

    • Bei Verwendung eines SQL Server-Datenspeichers:

      <authorization>
      <deny users="?" />
        <allow users="Mary,Bob,Joe" roles="Manager,Verkauf" />
      </authorization>
      
    • Wenn Sie Active Directory als Datenspeicher verwenden, werden Benutzer- und Gruppennamen im X.500-Format angezeigt:

      <authorization>
        <deny users="someAccount@domain.corp.yourCompany.com" />
        <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users,
                      DC=domain,DC=corp,DC=yourCompany,DC=com" />
      </authorization>
      
Programmatische Sicherheit

Die folgenden programmatischen Sicherheitsoptionen sind verfügbar:

  • PrincipalPermission-Befehle

    • Imperativ

          PrincipalPermission permCheck = new PrincipalPermission(
                                               null, "Manager");
          permCheck.Demand();
      
    • Deklarativ

      [PrincipalPermission(SecurityAction.Demand, 
                        Role="Manager")]
      
  • Explizite Rollenüberprüfungen – Sie können die Rollenüberprüfungen mithilfe der Schnittstelle IPrincipal durchführen.

    IPrincipal.IsInRole("Manager");
    
Verwendungshinweise

Die Formularauthentifizierung ist am besten für Internetanwendungen geeignet. Verwenden Sie die Formularauthentifizierung für folgende Situationen:

  • Die Anwendungsbenutzer verfügen über keine Windows-Konten.

  • Die Benutzer sollen sich durch Eingabe von Anmeldeinformationen über ein HTML-Formular anmelden.

Weitere Informationen

Passport-Authentifizierung

Die folgenden Konfigurationselemente zeigen, wie die Passport-Authentifizierung deklarativ in der Datei web.config aktiviert wird.

<authentication mode="Passport" />
Verwendungshinweise

Die Passport-Authentifizierung wird im Internet verwendet, wenn Anwendungsbenutzer über keine Windows-Konten verfügen und Sie eine Lösung mit einer einzigen Anmeldung implementieren möchten. Benutzer, die sich zuvor bei einer teilnehmenden Passport-Site mit einem Passport-Konto angemeldet haben, müssen sich bei Ihrer Website nicht anmelden, wenn diese mit der Passport-Authentifizierung konfiguriert ist.

Konfigurieren der Sicherheit

In diesem Abschnitt werden die praktischen Schritte veranschaulicht, die zum Konfigurieren der Sicherheit für eine ASP.NET-Anwendung erforderlich sind. Diese Schritte sind in Abbildung 8.3 zusammengefasst.

Konfigurieren der ASP.NET-Anwendungssicherheit

Abbildung 8.3
Konfigurieren der ASP.NET-Anwendungssicherheit

Konfigurieren der IIS-Einstellungen

Zum Konfigurieren der IIS-Sicherheit müssen Sie die folgenden Schritte ausführen:

  1. Installieren Sie optional ein Webserverzertifikat (wenn SSL erforderlich ist).

    Weitere Informationen finden Sie unter "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch.

  2. Konfigurieren Sie die IIS-Authentifizierung.

  3. Konfigurieren Sie optional die Clientzertifikatszuordnung (bei Verwendung der Zertifikatsauthentifizierung).

    Weitere Informationen zur Clientzertifikatszuordnung finden Sie im Artikel 313070, "SO WIRD'S GEMACHT: Client-Zertifikatszuordnungen in Internet Information Services (IIS) 5.0 konfigurieren", in der Microsoft Knowledge Base.

  4. Legen Sie NTFS-Berechtigungen für Dateien und Ordner fest. IIS und die FileAuthorizationModule-Klasse von ASP.NET überprüfen, ob der authentifizierte Benutzer (oder das anonyme Internetbenutzerkonto) über die Rechte für den Zugriff auf die angeforderte Datei (basierend auf den Einstellungen für die ACLs) verfügt.

Konfigurieren der ASP.NET-Einstellungen

Die Einstellungen für die Konfiguration auf Anwendungsebene werden in den web.config-Dateien verwaltet, die sich im virtuellen Stammverzeichnis der Anwendung und optional in zusätzlichen Unterordnern befinden (diese Einstellungen können manchmal die Einstellungen für den übergeordneten Ordner außer Kraft setzen).

  1. Konfigurieren der Authentifizierung – Dies sollte auf Anwendungsbasis in der Datei web.config festgelegt werden (nicht in der Datei machine.config), die sich im virtuellen Stammverzeichnis der Anwendung befindet.

    <authentication mode="Windows|Formulare|Passport|Keine" />
    
  2. Konfigurieren des Identitätswechsels – Für ASP.NET-Anwendungen erfolgt standardmäßig kein Identitätswechsel. Die Anwendung wird mit der konfigurierten ASP.NET-Prozessidentität (in der Regel ASPNET) ausgeführt, und sämtliche Ressourcenzugriffe dieser Anwendung werden mit dieser Identität durchgeführt. Ein Identitätswechsel ist nur unter den folgenden Bedingungen erforderlich:

    • Sie verwenden Enterprise Services und möchten Enterprise Services-(COM+-)Rollen nutzen, um den Zugriff auf Funktionen zu autorisieren, die von Serviced Components bereitgestellt werden.

    • IIS wurde für die anonyme Authentifizierung konfiguriert, und Sie möchten das anonyme Internetkonto für Ressourcenzugriffe verwenden. Weitere Informationen zu diesem Ansatz finden Sie unter "Zugreifen auf Netzwerkressourcen" weiter unten in diesem Modul.

    • Sie müssen den Sicherheitskontext des authentifizierten Benutzers an die nächste Ebene weitergeben (z. B. die Datenbank).

    • Sie haben eine klassische ASP-Anwendung zu ASP.NET portiert und möchten beim Identitätswechsel dasselbe Verhalten erreichen. Das klassische ASP wechselt standardmäßig die Identität des Benutzers.

    Verwenden Sie das folgende <identity>-Element in der Datei web.config Ihrer Anwendung, um den ASP.NET-Identitätswechsel zu konfigurieren.

    <identity impersonate="true" />
    
  3. Konfigurieren der Autorisierung – Die URL-Autorisierung legt fest, ob ein Benutzer oder eine Rolle bestimmte HTTP-Begriffe (z. B. GET, HEAD oder POST) für eine bestimmte Datei verwenden kann. Zum Implementieren der URL-Autorisierung führen Sie die folgenden Aufgaben aus.

    1. Sie fügen ein <authorization>-Element zu der Datei web.config hinzu, die sich im virtuellen Stammverzeichnis der Anwendung befindet.

    2. Sie schränken den Zugriff ein, indem Sie die Attribute allow und deny verwenden. Das folgende Beispiel für die Datei web.config verwendet die Windows-Authentifizierung und erteilt ausschließlich "Bob" und "Mary" den Zugriff.

      <authorization>
        <allow users="DomainName\Bob, DomainName\Mary" />
        <deny users="*" />
      </authorization>
      

      Wichtig: Sie müssen am Ende des <authorization>-Elements entweder <deny users="?"/> oder <deny users="*"/> hinzufügen, da sonst allen authentifizierten Identitäten der Zugriff gewährt wird.

Hinweise zur URL-Autorisierung

Achten Sie beim Konfigurieren der URL-Autorisierung auf Folgendes:

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

  • "?" bezieht sich auf nicht authentifizierte Identitäten (d. h. die anonyme Identität)

  • Es ist kein Identitätswechsel erforderlich, damit die URL-Autorisierung funktioniert.

  • Die Autorisierungseinstellungen in der Datei web.config beziehen sich auf alle Dateien im aktuellen Verzeichnis und alle Unterverzeichnisse (es sei denn, ein Unterverzeichnis enthält eine eigene web.config-Datei mit einem <authorization>-Element. In diesem Fall setzen die Einstellungen im Unterverzeichnis die Einstellungen des übergeordneten Verzeichnisses außer Kraft).

    Hinweis: Die URL-Autorisierung gilt nur für Dateitypen, die von IIS der ASP.NET ISAPI-Erweiterung aspnet_isapi.dll zugeordnet werden.

    Sie können das <location>-Element verwenden, um die Autorisierungseinstellungen einer einzelnen Datei oder einem einzelnen Verzeichnis zuzuordnen. Das folgende Beispiel veranschaulicht, wie Sie die Autorisierung auf eine bestimmte Datei (Page.aspx) anwenden.

    <location path="page.aspx" />
      <authorization>
        <allow users="DomainName\Bob, DomainName\Mary" />
        <deny users="*" />
      </authorization>
    </location>
    
  • Die Benutzer und Rollen für die URL-Autorisierung werden durch Ihre Authentifizierungseinstellungen festgelegt:

    • Wenn <authentication mode="Windows" /> festgelegt ist, wird der Zugriff für Windows-Benutzer- und -Gruppenkonten erteilt.

      Benutzernamen besitzen die Form "DomainName\WindowsUserName".

      Rollennamen besitzen die Form "DomainName\WindowsGroupName".

      Hinweis: Auf die Gruppe der lokalen Administratoren wird über "VORDEFINIERT\Administratoren" Bezug genommen. Auf die Gruppe der lokalen Benutzer wird über "VORDEFINIERT\Benutzer" Bezug genommen.

    • Wenn <authentication mode="Formulare" /> festgelegt ist, erfolgt die Autorisierung für den Benutzer und die Rollen des IPrincipal-Objekts, das im aktuellen HTTP-Kontext gespeichert wurde. Wenn Sie z. B. Formulare für die Authentifizierung der Benutzer für eine Datenbank verwendet haben, erfolgt die Autorisierung für die aus der Datenbank abgerufenen Rollen.

    • Wenn Sie <authentication mode="Passport" /> festgelegt haben, erfolgt die Autorisierung für die Passport-Benutzer-ID (PUID) oder für Rollen, die aus einem Datenspeicher abgerufen werden. Sie können z. B. eine PUID einem bestimmten Konto und Rollengruppen zuordnen, die in einer SQL Server-Datenbank oder in Active Directory gespeichert sind.

      Hinweis: Diese Funktionalität wird in das Betriebssystem Microsoft Windows .NET Server 2003 integriert.

    • Wenn Sie <authentication mode="Keine" /> festlegen, führen Sie möglicherweise keine Autorisierung durch. "Keine" gibt an, dass Sie keine Autorisierung durchführen und keines der .NET-Authentifizierungsmodule verwenden möchten, sondern Ihren eigenen benutzerdefinierten Mechanismus.
      Wenn Sie jedoch die benutzerdefinierte Authentifizierung verwenden, sollten Sie ein IPrincipal-Objekt mit Rollen erstellen und es in HttpContext.User speichern. Wenn Sie anschließend eine URL-Autorisierung durchführen, wird diese mit dem Benutzer und den Rollen ausgeführt (unabhängig davon, wie diese abgerufen werden), die im IPrincipal-Objekt verwaltet werden.

Beispiele für die URL-Autorisierung

Die folgende Liste zeigt die Syntax für einige typische URL-Autorisierungsbeispiele:

  • Verweigern des Zugriffs auf das anonyme Konto

     <deny users="?" />
    
  • Verweigern des Zugriffs für alle Benutzer

    <deny users="*"/>
    
  • Verweigern des Zugriffs für die Manager-Rolle

    <deny roles="Manager"/>
    
  • Beispiel für die Formularauthentifizierung

    <configuration>
      <system.web>
          <authentication mode="Formulare">
            <forms name=".ASPXUSERDEMO" 
                   loginUrl="login.aspx" 
                   protection="Alle" timeout="60" />
          </authentication>
          <authorization>
            <deny users="jdoe@somewhere.com" />
            <deny users="?" />
          </authorization>
      </system.web>
    </configuration>
    

Hinweis: Das <authorization>-Element arbeitet mit dem aktuellen IPrincipal-Objekt, das in HttpContext.User gespeichert ist, und auch mit der HTTP-Datenübertragungsmethode, die in HttpContext.Request.RequestTypegespeichert ist.

Sichere Ressourcen

  1. Verwenden Sie Windows-ACLs zum Sichern von Ressourcen, die Dateien, Ordner und Registrierungsschlüssel enthalten.
    Wenn Sie keinen Identitätswechsel durchführen, muss jede Ressource, auf die die Anwendung zugreift, eine ACL besitzen, die zumindest den Lesezugriff auf das ASP.NET-Prozesskonto erteilt.

    Wenn Sie einen Identitätswechsel vornehmen, müssen die Dateien und Registrierungsschlüssel über eine ACL verfügen, die zumindest den Lesezugriff für den authentifizierten Benutzer erteilt (oder für das anonyme Internetbenutzerkonto, wenn die anonyme Authentifizierung aktiv ist).

  2. Sichern Sie die Dateien web.config und machine.config:

    • Verwenden Sie die richtigen ACLs – Wenn ASP.NET einen Identitätswechsel durchführt, erfordert die gewechselte Identität den Lesezugriff. Andernfalls erfordert die ASP.NET-Prozessidentität den Lesezugriff. Verwenden Sie das folgende Zugriffssteuerungselement für web.config und machine.config.

      System: Vollzugriff

      Administratoren: Vollzugriff

      Prozessidentität oder gewechselte Identität: Lesen

      Wenn Sie für das anonyme Internetbenutzerkonto (IUSR_MACHINE) keinen Identitätswechsel durchführen, sollten Sie den Zugriff auf dieses Konto verweigern.

      Hinweis: Wenn die Anwendung einer UNC-Freigabe zugeordnet ist, erfordert die UNC-Identität auch den Lesezugriff auf die Konfigurationsdateien.

    • Entfernen Sie unerwünschte HTTP-Module. Die Datei machine.config enthält eine Reihe von HTTP-Modulen (im <httpModules>-Element. Dabei handelt es sich um folgende Module:

      • WindowsAuthenticationModule

      • FormsAuthenticationModule

      • PassportAuthenticationModule

      • UrlAuthorizationModule

      • FileAuthorizationModule

      • OutputCacheModule

      • SessionStateModule

      Wenn die Anwendung ein bestimmtes Modul nicht verwendet, entfernen Sie es, um mögliche zukünftige Sicherheitsprobleme zu vermeiden, die mit einem bestimmten Modul verbunden sein können, wenn dieses in der Anwendung eingesetzt wird.

  3. Optional können Sie die Konfigurationseinstellungen mithilfe des <location>-Elements und des Attributs allowOverride="false" sperren (wie im Folgenden beschrieben).

Sperren von Konfigurationseinstellungen

Konfigurationseinstellungen sind hierarchisch aufgebaut. Die Einstellungen der Datei web.config in Unterverzeichnissen setzen die Einstellungen der Datei web.config in übergeordneten Verzeichnissen außer Kraft. Die Einstellungen von web.config setzen außerdem die Einstellungen von machine.config außer Kraft.

Sie können Konfigurationseinstellungen sperren, um zu verhindern, dass diese in untergeordneten Ebenen blockiert werden, indem Sie das <location>-Element zusammen mit dem allowOverride-Attribut verwenden. Beispiel:

<location path="somepath" allowOverride="false" />
 . . . beliebige Konfigurationseinstellungen . . .
</location>

Beachten Sie, dass der Pfad auf eine Website oder ein virtuelles Verzeichnis verweisen kann und auf das benannte Verzeichnis sowie alle Unterverzeichnisse angewendet wird. Wenn Sie für allowOverride den Wert false festlegen, verhindern Sie, dass die im <location>-Element angegebenen Einstellungen von einer Konfigurationsdatei außer Kraft gesetzt werden, die sich in einem untergeordneten Verzeichnis befindet. Die Möglichkeit, die Konfigurationseinstellungen zu sperren, besteht für alle Arten von Einstellungen und nicht nur für Sicherheitseinstellungen wie Authentifizierungsmodi.

Im Kontext von machine.config muss ein vollständiger Pfad angegeben sein, der die Website, den Namen des virtuellen Verzeichnisses und optional ein Unterverzeichnis und einen Dateinamen enthält. Beispiel:

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
 . . .
</location>

Im Kontext von machine.config handelt es sich um einen relativen Pfad vom virtuellen Verzeichnis der Anwendung. Beispiel:

<location path="SubDirName/PageName.aspx" >
. . .
</location>
Verhindern von Dateidownloads

Sie können mithilfe der HttpForbiddenHandler-Klasse verhindern, dass bestimmte Dateitypen über das Internet heruntergeladen werden. Diese Klasse wird intern von ASP.NET verwendet, um den Download bestimmter Systemebenendateien zu verhindern (z. B. von Konfigurationsdateien, die web.config einschließen). Eine vollständige Liste der Dateitypen, die auf diese Weise eingeschränkt werden, finden Sie im Abschnitt <httpHandlers> der Datei machine.config.

Verwenden Sie den HttpForbiddenHandler für Dateien, die Ihre Anwendung intern nutzt und die nicht für den Download gedacht sind.

Hinweis: Sie müssen die Dateien auch mit Windows-ACLs sichern, um zu steuern, welche Benutzer auf die Dateien zugreifen können, wenn sie am Webserver angemeldet sind.

  • So verwenden Sie "HttpForbiddenHandler", um den Download eines bestimmten Dateityps zu verhindern

    1. Erstellen Sie in IIS eine Anwendungszuordnung für den angegebenen Dateityp, um ihn der Datei Aspnet_isapi.dll zuzuordnen.

      1. Klicken Sie auf der Taskleiste auf Start, Programme, Verwaltung und wählen Sie dann Internetinformationsdienste.

      2. Wählen Sie das virtuelle Verzeichnis der Anwendung aus und klicken Sie mit der rechten Maustaste darauf. Klicken Sie dann auf Eigenschaften.

      3. Wählen Sie Anwendungseinstellungen und klicken Sie auf Konfiguration.

      4. Klicken Sie auf Hinzufügen, um eine neue Anwendungszuordnung zu erstellen.

      5. Klicken Sie auf Durchsuchen und wählen Sie dann
        c:\winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll aus.

      6. Geben Sie die Dateierweiterung für den am Download zu hindernden Dateityp (z. B. .abc) in das Feld Erweiterung ein.

      7. Stellen Sie sicher, dass die Optionen Alle Verben und Skriptmodul aktiviert sind und die Option Prüfen, ob Datei existiert deaktiviert ist.

      8. Klicken Sie auf OK, um das Dialogfeld Hinzufügen/Bearbeiten der Zuordnung von Anwendungserweiterungen zu schließen.

      9. Klicken Sie auf OK, um das Dialogfeld Anwendungskonfiguration zu schließen, und dann erneut auf OK, um das Dialogfeld Eigenschaften zu schließen.

    2. Fügen Sie der Datei web.config für den angegebenen Dateityp die Zuordnung <HttpHandler> hinzu.

      Im Folgenden sehen Sie ein Beispiel für den Dateityp ABC.

      <httpHandlers>
        <add verb="*" path="*.abc" 
          type="System.Web.HttpForbiddenHandler"/>
      </httpHandlers>
      

Sichere Kommunikation

Verwenden Sie eine Kombination aus SSL und IPSec (Internet Protocol Security), um die Kommunikationsverbindungen zu sichern.

Weitere Informationen
  • Weitere Informationen zur Verwendung von SSL zum Sichern der Verknüpfung zum Datenbankserver finden Sie unter "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000".

  • Weitere Informationen zur Verwendung von IPSec zwischen zwei Computern finden Sie unter "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern".

Programmieren der Sicherheit

Nachdem Sie die konfigurierbaren Sicherheitseinstellungen der Webanwendung eingerichtet haben, müssen Sie die Autorisierungsrichtlinie der Anwendung programmatisch erweitern und optimieren. Dazu gehören deklarative .NET-Attribute in den Assemblys und das Durchführen imperativer Autorisierungsüberprüfungen im Code.

In diesem Abschnitt werden die wesentlichen Programmierschritte veranschaulicht, die für die Autorisierung in einer ASP.NET-Webanwendung erforderlich sind.

Autorisierungsmuster

Im Folgenden wird die Standardvorgehensweise beim Autorisieren von Benutzern in der Webanwendung zusammengefasst:

  1. Abrufen von Anmeldeinformationen

  2. Überprüfen von Anmeldeinformationen

  3. Zuweisen von Benutzern zu Rollen

  4. Erstellen eines IPrincipal-Objekts

  5. Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

  6. Autorisieren anhand der Benutzeridentität/Rollenmitgliedschaft

Wichtig: ASP.NET führt die Schritte 1 bis 5 automatisch durch, wenn Sie die Windows-Authentifizierung konfiguriert haben. Bei den anderen Authentifizierungsmechanismen (Formularauthentifizierung, Passport-Authentifizierung und benutzerdefinierte Ansätze) müssen Sie den Code für diese Schritte schreiben (wie unten beschrieben).

Abrufen von Anmeldeinformationen

Sie müssen zuerst eine Reihe von Anmeldeinformationen (Benutzername und Kennwort) vom Benutzer abrufen. Wenn die Anwendung keine Windows-Authentifizierung verwendet, müssen Sie sicherstellen, dass unverschlüsselte Anmeldeinformationen im Netzwerk ordnungsgemäß über SSL gesichert werden.

Überprüfen von Anmeldeinformationen

Wenn Sie die Windows-Authentifizierung konfiguriert haben, werden Anmeldeinformationen automatisch durch die zugrunde liegenden Dienste des Betriebssystems überprüft.

Wenn Sie einen alternativen Authentifizierungsmechanismus verwenden, müssen Sie den Code schreiben, um Anmeldeinformationen anhand eines Datenspeichers (z. B. SQL Server-Datenbank oder Active Directory) zu überprüfen.

Weitere Informationen zum sicheren Speichern von Benutzeranmeldeinformationen in einer SQL Server-Datenbank finden Sie unter "Authentifizieren von Benutzern anhand einer Datenbank" in Modul 12, "Datenzugriffssicherheit".

Zuweisen von Benutzern zu Rollen

Der Benutzerdatenspeicher sollte auch eine Liste der Rollen für jeden Benutzer enthalten. Sie müssen den Code zum Abrufen der Rollenliste für den überprüften Benutzer schreiben.

Erstellen eines IPrincipal-Objekts

Die Autorisierung erfolgt anhand des authentifizierten Benutzers, dessen Identitäts- und Rollenliste im IPrincipal-Objekt verwaltet wird (das sich im Kontext der aktuellen Webanforderung befindet).

Wenn Sie die Windows-Authentifizierung konfiguriert haben, erstellt ASP.NET automatisch ein WindowsPrincipal-Objekt. Es enthält die Identität des authentifizierten Benutzers zusammen mit einer Rollenliste, die der Liste der Windows-Gruppen entspricht, denen der Benutzer angehört.

Wenn Sie die Formular-, Passport- oder benutzerdefinierte Authentifizierung verwenden, müssen Sie in der Datei Global.asax im Ereignishandler Application_AuthenticateRequest Code hinzufügen, um das IPrincipal-Objekt zu erstellen. Die GenericPrincipal-Klasse wird von .NET Framework bereitgestellt und sollte in den meisten Szenarios verwendet werden.

Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

Fügen Sie das IPrincipal-Objekt dem aktuellen HTTP-Kontext hinzu (mithilfe der Variablen HttpContext.User). ASP.NET führt dies automatisch durch, wenn Sie die Windows-Authentifizierung verwenden. Andernfalls müssen Sie das Objekt manuell hinzufügen.

Autorisieren anhand der Benutzeridentität und/oder Rollenmitgliedschaft

Verwenden Sie die .NET-Rollen entweder deklarativ (um die Autorisierung auf Klassen- oder Methodenebene zu erhalten) oder imperativ im Code, wenn die Anwendung eine feinstufige Autorisierungslogik erfordert.

Sie können deklarative oder imperative Hauptberechtigungen verwenden (mithilfe der PrincipalPermission-Klasse) oder explizite Rollenüberprüfungen durchführen, indem Sie die IPrincipal.IsInRole()-Methode aufrufen.

Das folgende Beispiel geht von einer Windows-Authentifizierung aus und veranschaulicht eine deklarative Hauptberechtigung. Die auf das Attribut folgende Methode wird nur ausgeführt, wenn der authentifizierte Benutzer ein Mitglied der Windows-Gruppe Manager ist. Wenn der Benutzer kein Mitglied dieser Gruppe ist, wird die Ausnahmebedingung SecurityException ausgelöst.

[PrincipalPermission(SecurityAction.Demand, 
                     Role=@"DomainName\Manager")]
public void SomeMethod()
{
}

Im folgenden Beispiel wird eine explizite Rollenüberprüfung innerhalb des Codes gezeigt. Dieses Beispiel geht von der Verwendung der Windows-Authentifizierung aus. Wird die Windows-Authentifizierung nicht verwendet, ist der Code dennoch sehr ähnlich. Anstatt für das User-Objekt eine Typumwandlung in ein WindowsPrincipal-Objekt durchzuführen, sollte es in ein GenericPrincipal-Objekt umgewandelt werden.

// Extrahieren Sie den authentifizierten Benutzer aus dem aktuellen HTTP-Kontext.
// Die User-Variable entspricht HttpContext.Current.
User, wenn Sie // eine ASPX- oder ASMX-Seite verwenden
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Hinweis: Verwenden Sie zum Abrufen des Benutzernamens des authentifizierten Benutzers
  // folgende Codezeile:
  // string username = authenticatedUser.Identity.Name;

  // Führen Sie eine Rollenüberprüfung durch
  if (authenticatedUser.IsInRole(@"DomainName\Manager") )
  {
    // Benutzer ist zur Durchführung von Managerfunktionen berechtigt
  }
}
else
{
  // Benutzer ist nicht zur Durchführung von Managerfunktionen berechtigt
}

Weitere Informationen

  • Eine praktische Implementierung des obigen Musters für die Formularauthentifizierung finden Sie im Abschnitt "Formularauthentifizierung" weiter unten in diesem Modul.

Erstellen einer benutzerdefinierten IPrincipal-Klasse

Die von .NET Framework bereitgestellte GenericPrincipal-Klasse sollte in den meisten Fällen verwendet werden, wenn Sie einen anderen Mechanismus als die Windows-Authentifizierung verwenden. Diese Klasse ermöglicht Rollenüberprüfungen mithilfe der IPrincipal.IsInRole-Methode.

Gelegentlich müssen Sie eine eigene GenericPrincipal-Klasse erstellen. Zu den Gründen für die Implementierung einer eigenen IPrincipal-Klasse gehören die folgenden:

  • Sie benötigen eine erweiterte Rollenüberprüfungsfunktionalität. Möglicherweise möchten Sie mit Methoden arbeiten, mit denen Sie prüfen können, ob ein bestimmter Benutzer mehreren Rollen angehört. Beispiel:

    CustomPrincipal.IsInAllRoles( "Rolle", "Rolle2", "Rolle3" )
    CustomPrincipal.IsInAnyRole( "Rolle1", "Rolle2", "Rolle3" )
    
  • Sie möchten eine zusätzliche Methode oder Eigenschaft implementieren, die eine Liste der Rollen in Form eines Arrays zurückgibt. Beispiel:

    string[] roles = CustomPrincipal.Roles;
    
  • Sie möchten, dass Ihre Anwendung eine Rollenhierarchielogik durchsetzt. Beispielsweise könnte ein "Senior Manager" als in der Hierarchie höher stehend als ein "Manager" betrachtet werden. Dies könnte mit Methoden wie den folgenden getestet werden.

    CustomPrincipal.IsInHigherRole("Manager");
    CustomPrincipal.IsInLowerRole("Manager");
    
  • Sie möchten eine verzögerte Initialisierung der Rollenlisten implementieren. Beispielsweise könnten Sie die Rollenliste nur dann dynamisch laden, wenn eine Rollenüberprüfung angefordert wird.

  • Sie möchten die Schnittstelle IIdentity implementieren, um den Benutzer durch ein X509ClientCertificate identifizieren zu lassen. Beispiel:

    CustomIdentity id = CustomPrincipal.Identity;
    X509ClientCertificate cert = id.ClientCertificate;
    

Weitere Informationen

Weitere Informationen zum Erstellen einer eigenen IPrincipal-Klasse finden Sie unter "Vorgehensweise: Implementieren von IPrincipal" in diesem Handbuch.

Windows-Authentifizierung

Verwenden Sie die Windows-Authentifizierung, wenn die Benutzer der Anwendung über Windows-Konten verfügen, die vom Server authentifiziert werden können (z. B. in Internetszenarios).

Wenn Sie ASP.NET für die Windows-Authentifizierung konfigurieren, führt IIS die Benutzerauthentifizierung mit dem konfigurierten IIS-Authentifizierungsmechanismus durch. Dies ist in Abbildung 8.4 dargestellt.

ASP.NET Windows-Authentifizierung verwendet IIS zum Authentifizieren von Benutzern

Abbildung 8.4
ASP.NET Windows-Authentifizierung verwendet IIS zum Authentifizieren von Benutzern

Das Zugriffstoken des authentifizierten Benutzers (bei dem es sich um das anonyme Internetbenutzerkonto handeln kann, wenn IIS für die anonyme Authentifizierung konfiguriert ist) wird für die ASP.NET-Anwendung zur Verfügung gestellt. Beachten Sie Folgendes:

  • Das ermöglicht dem ASP.NET FileAuthorizationModule, Zugriffsüberprüfungen anhand der angeforderten ASP.NET-Dateien durchzuführen, die das Zugriffstoken des ursprünglichen Benutzers verwenden.

    Wichtig: Die ASP.NET-Dateiautorisierung führt nur Zugriffsüberprüfungen für Dateitypen durch, die der Datei Aspnet_isapi.dll zugeordnet sind.

  • Die Dateiautorisierung erfordert keinen Identitätswechsel. Bei aktiviertem Identitätswechsel verwendet jeder von der Anwendung durchgeführte Ressourcenzugriff die Identität des Benutzers nach dem Identitätswechsel. Stellen Sie in diesem Fall sicher, dass die den Ressourcen zugeordneten ACLs einen Access Control Entry (ACE oder Zugriffssteuerungseintrag) enthalten, der zumindest den Lesezugriff für die Identität des ursprünglichen Benutzers erteilt.

Identifizieren des authentifizierten Benutzers

ASP.NET ordnet der aktuellen Webanforderung ein WindowsPrincipal-Objekt zu Dieses Objekt enthält die Identität des authentifizierten Windows-Benutzers zusammen mit einer Liste der Rollen, zu denen dieser Benutzer gehört. Bei diesen Objekten wird die Rollenliste automatisch aus der Reihe der Windows-Gruppen abgerufen, denen der Benutzer angehört.

Im folgenden Code wird veranschaulicht, wie die Identität des authentifizierten Windows-Benutzers abgerufen und ein einfacher Rollentest für die Autorisierung durchgeführt wird.

WindowsPrincipal user = User as WindowsPrincipal;
if (null != user)
{
  string username = user.Identity.Name;
  // Führen Sie eine Rollenüberprüfung durch
  if ( user.IsInRole(@"DomainName\Manager") )
  {
    // Benutzer ist zur Durchführung von Managerfunktionen berechtigt
  }
}
else
{
  // Sicherheitsausnahme auslösen, da kein WindowsPrincipal verfügbar ist
}  

Formularauthentifizierung

In Abbildung 8.5 wird die Reihenfolge der bei der Formularauthentifizierung von einem nicht authentifizierten Benutzer ausgelösten Ereignisse angezeigt, der versucht, auf eine gesicherte Datei oder Ressource zuzugreifen (wobei die URL-Autorisierung den Benutzerzugriff ablehnt).

Ereignisabfolge bei der Formularauthentifizierung

Abbildung 8.5
Ereignisabfolge bei der Formularauthentifizierung

Im Folgenden wird die in Abbildung 8.5 dargestellte Ereignisabfolge beschrieben:

  1. Der Benutzer startet eine Webanforderung für die Datei Default.aspx.

    IIS lässt die Anforderung zu, da der anonyme Zugriff aktiviert ist. ASP.NET überprüft die <authorization>-Elemente und findet ein <deny users=?" />-Element.

  2. Der Benutzer wird wie im loginUrl-Attribut des <Formulare>-Element angegeben zur Anmeldeseite (Login.aspx) weitergeleitet.

  3. Der Benutzer stellt die Anmeldeinformationen bereit und übermittelt das Anmeldeformular.

  4. Die Anmeldeinformationen werden anhand eines Datenspeichers (SQL Server oder Active Directory) überprüft, Rollen werden optional abgerufen. Sie müssen eine Rollenliste abrufen, wenn Sie die rollenbasierte Autorisierung verwenden möchten.

  5. Mit FormsAuthenticationTicket wird ein Cookie erstellt und an den Client zurückgesendet. Die Rollen werden optional im Ticket gespeichert. Durch das Speichern der Rollenliste im Ticket vermeiden Sie, dass Sie auf die Datenbank zugreifen müssen, um die Liste für folgende Webanforderungen desselben Benutzers erneut abzurufen.

  6. Der Benutzer wird mithilfe der clientseitigen Umleitung zur ursprünglich angeforderten Seite (Default.aspx) umgeleitet.

  7. Im Ereignishandler Application_AuthenticateRequest (in Global.asax) wird das Ticket zum Erstellen eines IPrincipal-Objekts verwendet und in HttpContext.User gespeichert.

    ASP.NET überprüft die <authorization> Elemente und findet ein <deny users=?" /> Element. Diesmal ist der Benutzer jedoch authentifiziert.

    ASP.NET überprüft die <authorization>-Elemente, um sicherzustellen, dass sich der Benutzer im <allow>-Element befindet.

    Dem Benutzer wird der Zugriff auf die Datei Default.aspx erteilt.

Entwicklungsschritte für die Formularauthentifizierung

In der folgenden Liste werden die wichtigsten Schritte hervorgehoben, die Sie zum Implementieren der Formularauthentifizierung durchführen müssen:

  1. Konfigurieren von IIS für den anonymen Zugriff.

  2. Konfigurieren von ASP.NET für die Formularauthentifizierung.

  3. Erstellen eines Webanmeldeformulars und Überprüfen der bereitgestellten Anmeldeinformationen.

  4. Abrufen einer Rollenliste aus dem benutzerdefinierten Datenspeicher.

  5. Erstellen eines Tickets für die Formularauthentifizierung (Rollen im Ticket speichern).

  6. Erstellen eines IPrincipal-Objekts.

  7. Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext.

  8. Autorisieren des Benutzers basierend auf dem Benutzernamen/der Rollenmitgliedschaft.

Konfigurieren von IIS für den anonymen Zugriff

Das virtuelle Verzeichnis der Anwendung muss in IIS für den anonymen Zugriff konfiguriert sein.

  • So konfigurieren Sie IIS für den anonymen Zugriff

    1. Starten Sie das Verwaltungsprogramm Internetinformationsdienste.

    2. Wählen Sie das virtuelle Verzeichnis der Anwendung aus und klicken Sie mit der rechten Maustaste darauf. Klicken Sie dann auf Eigenschaften.

    3. Klicken Sie auf Verzeichnissicherheit.

    4. Klicken Sie in der Gruppe Steuerung des anonymen Zugriffs und der Authentifizierung auf Bearbeiten.

    5. Wählen Sie Anonymer Zugriff.

Konfigurieren von ASP.NET für die Formularauthentifizierung.

Im Folgenden wird eine Beispielkonfiguration aufgeführt.

<authentication mode="Formulare">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="Verschlüsselung"
       timeout="20" 
       path="/" >
  </forms>
</authentication>
Erstellen eines Webanmeldeformulars und Überprüfen der bereitgestellten Anmeldeinformationen

Überprüfen Sie die Anmeldeinformationen anhand einer SQL Server-Datenbank oder mithilfe von Active Directory.

Weitere Informationen

  • Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

  • Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory" in diesem Handbuch.

Abrufen einer Rollenliste aus dem benutzerdefinierten Datenspeicher

Rufen Sie Rollen aus einer Tabelle einer SQL Server-Datenbank oder in Active Directory konfigurierte Gruppen-/Verteilerlisten ab. Weitere Informationen finden Sie in den oben aufgeführten Ressourcen.

Erstellen eines Tickets für die Formularauthentifizierung

Speichern Sie die abgerufenen Rollen im Ticket. Dies wird im folgenden Code veranschaulicht.

// Dieser Ereignishandler wird ausgeführt, wenn der Benutzer auf die Anmeldeschaltfläche klickt,
// nachdem ein Satz Anmeldeinformationen angegeben wurde
private void Logon_Click(object sender, System.EventArgs e)
{
  // Überprüfen Sie die Anmeldeinformationen anhand einer SQL Server-Datenbank
  // oder Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text, 
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Rufen Sie die Rollenliste für diesen Benutzer aus der SQL Server-
    // Datenbank oder aus Active Directory ab. Die Rollen werden als
    // Zeichenfolge zurückgegeben, in der die Rollennamen durch einen senkrechten Balken (Pipe) 
    //voneinander getrennt sind, beispielsweise "Manager|Mitarbeiter|Verkauf|"
    // Auf diese Weise können Sie problemlos im Authentifizierungsticket gespeichert werden

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Erstellen Sie das Authentifizierungsticket, und speichern Sie die Rollen in der
    // benutzerdefinierten UserData-Eigenschaft des Authentifizierungstickets
    FormsAuthenticationTicket authTicket = new 
       FormsAuthenticationTicket(
                    1,                          // Version
                    txtUserName.Text,           // Benutzername
                    DateTime.Now,               // Erstellung
                    DateTime.Now.AddMinutes(20),// Ablauf
                    false,                      // Permanent
                    roles );                    // Benutzerdaten
     // Verschlüsseln Sie das Ticket.
     string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
     // Erstellen Sie ein Cookie, und fügen Sie das verschlüsselte Ticket dem 
     // Cookie in Form von Daten hinzu.
     HttpCookie authCookie = 
               new HttpCookie(FormsAuthentication.FormsCookieName,
                              encryptedTicket);

     // Fügen Sie das Cookie der Sammlung ausgehender Cookies hinzu. 
     Response.Cookies.Add(authCookie); 
     // Leiten Sie den Benutzer auf die ursprünglich angeforderte Seite um.
     Response.Redirect( FormsAuthentication.GetRedirectUrl(
                        txtUserName.Text, 
                        false ));
  }
}
Erstellen eines IPrincipal-Objekts

Erstellen Sie das IPrincipal-Objekt im Ereignishandler Application_AuthenticationRequest der Datei Global.asax. Verwenden Sie die GenericPrincipal-Klasse, wenn Sie die erweiterten rollenbasierten Funktionen nicht benötigen. Wenn doch, erstellen Sie eine benutzerdefinierte Klasse, die IPrincipal implementiert.

Einfügen des IPrincipal-Objekts in den aktuellen HTTP-Kontext

Im Folgenden wird das Erstellen des GenericPrincipal-Objekts veranschaulicht.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extrahieren Sie das Formularauthentifizierungs-Cookie
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // Es ist kein Authentfizierungscookie vorhanden.
    return;
  } 
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Protokollieren Sie Ausnahmedetails (aus Gründen der Überschaubarkeit ausgelassen)
    return;
  }
  if (null == authTicket)
  {
    // Cookie konnte nicht entschlüsselt werden.
    return; 
  }
  // Bei der Erstellung des Tickets wurde der UserData-Eigenschaft eine
  // durch einen senkrechten Balken (Pipe) getrennte Zeichenfolge der Rollennamen zugewiesen.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Erstellen Sie ein Identitätsobjekt
  FormsIdentity id = new FormsIdentity( authTicket ); 
  // Dieser Prinzipal wird über die gesamte Anforderung hinweg übertragen.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Fügen Sie das neue Prinzipalobjekt an das aktuelle HttpContext-Objekt an
  Context.User = principal;
}
Autorisieren des Benutzers basierend auf dem Benutzernamen/der Rollenmitgliedschaft

Verwenden Sie deklarative Hauptberechtigungen, um den Zugriff auf Methoden einzuschränken. Verwenden Sie die imperativen Hauptberechtigungen und/oder expliziten Rollenüberprüfungen (IPrincipal.IsInRole), um innerhalb der Methoden eine feinstufige Autorisierung durchzuführen.

Richtlinien für die Formularimplementierung

  • Verwenden Sie SSL beim Erfassen der Anmeldeinformationen mit einem HTML-Formular.
    Sie sollten SSL neben der Anmeldeseite auch für andere Seiten verwenden, wenn die Anmeldeinformationen oder das Authentifizierungscookie über das Netzwerk gesendet werden. Dadurch wird die Gefahr verringert, die mit Angriffen verbunden ist, bei denen Cookies wiedergegeben werden.

  • Authentifizieren Sie Benutzer anhand eines benutzerdefinierten Datenspeichers. Verwenden Sie SQL Server oder Active Directory.

  • Rufen Sie eine Rollenliste aus dem benutzerdefinierten Datenspeicher ab und speichern Sie eine Liste mit durch Trennzeichen getrennten Rollen in der UserData-Eigenschaft der FormsAuthenticationTicket-Klasse. Dadurch wird die Leistung verbessert, da nicht mehr für jede Webanforderung wiederholt auf den Datenspeicher zugegriffen werden muss. Außerdem müssen Sie die Anmeldeinformationen des Benutzers nicht im Authentifizierungscookie speichern.

  • Wenn die Liste der Rollen sehr umfangreich ist und die Gefahr besteht, den Grenzwert für die Cookiegröße zu überschreiten, speichern Sie die Rollendetails im ASP.NET-Cacheobjekt oder der ASP.NET-Datenbank und rufen Sie diese dann für jede folgende Anforderung ab.

  • Gehen Sie für jede Anforderung nach der ersten Authentifizierung wie folgt vor:

    • Rufen Sie die Rollen aus dem Ticket im Ereignishandler Application_AuthenticateRequest ab.

    • Erstellen Sie ein IPrincipal-Objekt und speichern Sie es im HTTP-Kontext (HttpContext.User). Es wird von .NET Framework ebenfalls zum aktuellen .NET-Thread (Thread.CurrentPrincipal) zugeordnet.

    • Verwenden Sie die GenericPrincipal-Klasse, außer es besteht ein bestimmter Grund dafür, eine IPrincipal-Implementierung zu erstellen (z. B. um erweiterte rollenbasierte Operationen zu unterstützen).

  • Verwenden Sie zwei Cookies, eines für die Personalisierung und das andere für die sichere Authentifizierung und Autorisierung. Legen Sie das Personalisierungscookie als persistent fest (stellen Sie sicher, dass es keine Daten enthält, die eine Anforderung zum Durchführen einer eingeschränkten Operation zulassen, z. B. das Ablegen einer Anforderung im sicheren Teil einer Site).

  • Verwenden Sie für jede Webanwendung einen separaten Cookienamen (mithilfe des Formulare-Attributs des <Formulare>-Elements) und Pfad. Dadurch wird sichergestellt, dass Benutzer, die für eine Anwendung authentifiziert sind, nicht auch als für andere Anwendungen authentifiziert eingestuft werden, die auf demselben Webserver verwaltet werden.

  • Stellen Sie sicher, dass Cookies in den Clientbrowsern aktiviert sind. Informationen zu einem Ansatz, der die Formularauthentifizierung verwendet und keine Cookies erfordert, finden Sie unter "Formularauthentifizierung ohne Cookies" weiter unten in diesem Modul.

Weitere Informationen

  • Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit SQL Server 2000" in diesem Handbuch.

  • Weitere Informationen finden Sie unter Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory" in diesem Handbuch.

  • Weitere Informationen finden Sie unter Vorgehensweise: Erstellen von GenericPrincipal-Objekten bei der Formularauthentifizierung" in diesem Handbuch.

Verwalten mehrerer Anwendungen mithilfe der Formularauthentifizierung

Wenn Sie mehrere Webanwendungen verwalten, die die Formularauthentifizierung auf demselben Webserver verwenden, ist es möglich, dass ein für eine Anwendung authentifizierter Benutzer eine Anforderung an eine andere Anwendung stellen kann, ohne zur Anmeldeseite dieser Anwendung umgeleitet zu werden. Die Regeln der URL-Autorisierung der zweiten Anwendung verweigern möglicherweise den Zugriff für den Benutzer, ohne ihm die Möglichkeit zu bieten, Anmeldeinformationen über das Anmeldeformular bereitzustellen.

Dies geschieht nur, wenn die Attribute für Name und Pfad im <Formulare>-Element für mehrere Anwendungen dieselben sind und alle Anwendung ein gemeinsames <machineKey>-Element in der Datei web.config verwenden.

Weitere Informationen

Weitere Informationen zu diesem Thema und zu Lösungsverfahren finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

Formularauthentifizierung ohne Cookies

Wenn Sie eine Lösung für die Formularauthentifizierung suchen, die keine Cookies erfordert, sollten Sie den Ansatz in Erwägung ziehen, der von Microsoft Mobile Internet Toolkit verwendet wird. Die Authentifizierung über mobile Formulare baut auf der Formularauthentifizierung auf, verwendet jedoch die Abfragezeichenfolge, um anstatt eines Cookies das Authentifizierungsticket zu übermitteln.

Weitere Informationen

Weitere Informationen zur Authentifizierung über mobile Formulare finden Sie im Artikel Q311568, "HOWTO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit" (englischsprachig), in der Microsoft Knowledge Base.

Passport-Authentifizierung

Verwenden Sie die Passport-Authentifizierung, wenn die Benutzer Ihrer Anwendung über Passport-Konten verfügen und Sie eine Lösung mit einer einzigen Anmeldung für andere Sites implementieren möchten, die für Passport aktiviert sind.

Wenn Sie ASP.NET für die Passport-Authentifizierung konfigurieren, wird der Benutzer zum Anmelden aufgefordert und dann zur Passport-Site umgeleitet. Nach erfolgreicher Überprüfung der Anmeldeinformationen wird der Benutzer wieder zu Ihrer Website zurückgeleitet.

Konfigurieren von ASP.NET für die Passport-Authentifizierung

Verwenden Sie die folgenden Einstellungen für die Datei web.config, um ASP.NET für die Passport-Authentifizierung zu konfigurieren.

<authentication mode="Passport">
  <passport redirectUrl="intern" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Zuordnen einer Passport-Identität zu Rollen in "Global.asax"

Implementieren Sie den Ereignishandler PassportAuthentication_OnAuthentication in der Datei Global.asax wie unten gezeigt, um eine Passport-Identität zu Rollen zuzuordnen.

void PassportAuthentication_OnAuthenticate(Object sender, 
                                           PassportAuthenticationEventArgs e)
{
  if(e.Identity.Name == "0000000000000001")
  {
    string[] roles = new String[]{"Entwickler", "Admin", "Tester"};
    Context.User = new GenericPrincipal(e.Identity, roles);
  }
}

Testen der Rollenmitgliedschaft

Das folgende Codefragment zeigt, wie die authentifizierte Passport-Identität abgerufen und die Rollenmitgliedschaft in einer ASPX-Seite überprüft wird.

PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
  Response.Write("Keine PassportIdentity<br>");
  return;
}
Response.Write("IsInRole: Entwickler? " + Context.User.IsInRole("Entwickler"));

Benutzerdefinierte Authentifizierung

Wenn keines der im .NET Framework bereitgestellten Authentifizierungsmodule Ihren konkreten Authentifizierungsanforderungen entspricht, können Sie die benutzerdefinierte Authentifizierung verwenden und einen eigenen Authentifizierungsmechanismus implementieren. Ihr Unternehmen könnte z. B. schon über eine benutzerdefinierte Authentifizierungsstrategie verfügen, die von anderen Anwendungen ausgiebig genutzt wird.

So implementieren Sie die benutzerdefinierte Authentifizierung in ASP.NET:

  • Konfigurieren Sie den Authentifizierungsmodus in der Datei web.config wie im Folgenden gezeigt. Dadurch wird ASP.NET darüber informiert, dass keine integrierten Authentifizierungsmodule aufgerufen werden sollen.

    <authentication mode="Keine" />
    
  • Erstellen Sie eine Klasse, die die Schnittstelle System.Web.IHttpModule integriert, um ein benutzerdefiniertes HTTP-Modul zu erstellen. Dieses Modul sollte einen Hook im HttpApplication.AuthenticateRequest-Ereignis implementieren und einen Delegate bereitstellen, der bei jeder Anforderung für die Anwendung aufgerufen wird, wenn die Authentifizierung erforderlich ist.

    Folgende Kriterien müssen von einem Authentifizierungsmodul erfüllt werden:

    • Abrufen der Anmeldeinformationen vom Benutzer.

    • Überprüfen der Anmeldeinformationen anhand eines Speichers.

    • Erstellen eines IPrincipal-Objekts und Speichern in HttpContext.User.

    • Erstellen und Schützen eines Authentifizierungstokens und Rücksendung an den Benutzer (normalerweise in einer Abfragezeichenfolge, einem Cookie oder einem verborgenen Formularfeld).

    • Abrufen des Authentifizierungstokens bei nachfolgenden Anforderungen, anschließende Überprüfung und erneutes Ausstellen.

Weitere Informationen

Weitere Informationen zum Implementieren eines benutzerdefinierten HTTP-Moduls finden Sie im Artikel 307996, "SO WIRD'S GEMACHT: Erstellen eines ASP.NET-HTTP-Moduls mit Visual C# .NET", in der Microsoft Knowledge Base.

Prozessidentität für ASP.NET

Führen Sie ASP.NET (insbesondere den Workerprozess Aspnet_wp.exe) mithilfe eines Kontos aus, das minimale Rechte besitzt.

Verwenden eines Kontos mit minimalen Rechten

Verwenden Sie ein Konto mit minimalen Rechten, um die Bedrohung durch Angriffe auf Prozesse zu verringern. Wenn es einem entschlossenen Angreifer gelingt, den ASP.NET-Prozess anzugreifen, der Ihre Webanwendung ausführt, kann er die Rechte und Zugriffsrechte, die dem Prozesskonto gewährt wurden, problemlos übernehmen und ausnutzen. Ein Konto, das mit minimalen Rechten konfiguriert wurde, schränkt den potenziell angerichteten Schaden ein.

Vermeiden der Ausführung als SYSTEM

Verwenden Sie zum Ausführen von ASP.NET nicht das mit vielen Rechten versehene Konto SYSTEM und erteilen Sie dem ASP.NET-Prozesskonto nicht das Recht Als Teil des Betriebssystems handeln. Möglicherweise spielen Sie mit dem Gedanken, die eine oder andere Variante zu verwenden, damit Sie es dem Code ermöglichen, die API LogonUser aufzurufen, um eine feste Identität zu erhalten (normalerweise für den Zugriff auf Netzwerkressourcen). Alternative Ansätze finden Sie unter "Zugreifen auf Netzwerkressourcen" weiter unten in diesem Modul.

Die folgenden Gründe sprechen gegen eine Ausführung als SYSTEM oder das Erteilen des Rechts Als Teil des Betriebssystems handeln:

  • Der Schaden, den ein Angreifer anrichten kann, wird erheblich erhöht, jedoch nicht die Möglichkeit, das System anzugreifen.

  • Das Prinzip der minimalen Rechte wird nicht befolgt. Das Konto ASPNET wurde speziell als Konto mit minimalen Rechten konfiguriert, um mit ASP.NET-Webanwendungen ausgeführt zu werden.

Weitere Informationen

Weitere Informationen zum Recht Als Teil des Betriebssystems handeln finden Sie im Microsoft Systems Journal, Ausgabe August 1999, in der Spalte Security Briefs (englischsprachig).

Domänencontroller und das ASP.NET-Prozesskonto

Im Allgemeinen wird nicht empfohlen, den Webserver auf einem Domänencontroller auszuführen, da eine Gefährdung des Servers auch eine Gefährdung der Domäne darstellt. Wenn Sie ASP.NET auf einem Domänencontroller ausführen müssen, sollte das ASP.NET-Prozesskonto die entsprechenden Rechte erhalten, wie im Artikel 315158, "UPDATE: ASP.NET funktioniert nicht mit einem Domänenkonto ohne Administratorberechtigungen auf einem Domänencontroller", der Microsoft Knowledge Base beschrieben.

Verwenden des ASPNET-Standardkontos

Das lokale ASPNET-Konto wurde speziell für die Ausführung von ASP.NET-Webanwendungen mit minimalen Rechten konfiguriert. Verwenden Sie, wenn irgend möglich, immer ASPNET.

ASP.NET-Webanwendungen werden standardmäßig mit diesem Konto ausgeführt, wie in der Datei machine.config durch das <processModel>-Element konfiguriert.

<processModel userName="Computer" password="AutoGenerate" />

Hinweis: Der Benutzername Computer gibt das ASPNET-Konto an. Das Konto wird beim Installieren des .NET Framework mit einem stark verschlüsselten Kennwort erstellt. Das Kennwort wird in der SAM-Datenbank (Security Account Manager) und darüber hinaus auf dem lokalen Computer in der Local Security Authority (LSA) gespeichert. Das System ruft das Kennwort von der LSA ab, wenn der ASP.NET-Workerprozess gestartet wird.

Wenn Ihre Anwendung auf Netzwerkressourcen zugreift, muss das ASPNET-Konto vom Remotecomputer authentifiziert werden. Sie haben zwei Möglichkeiten:

  • Setzen Sie das Kennwort des ASPNET-Kontos auf einen bekannten Wert zurück und erstellen Sie dann ein Duplikat des Kontos (mit demselben Namen und demselben Kennwort) auf dem Remotecomputer. Dieser Ansatz stellt unter den folgenden Umständen die einzige Option dar:

    • Der Webserver und der Remotecomputer befinden sich in separaten Domänen ohne Vertrauensstellung.

    • Der Webserver und der Remotecomputer sind durch eine Firewall voneinander getrennt, und Sie möchten die erforderlichen Anschlüsse zum Unterstützen der Windows-Authentifizierung nicht öffnen.

  • Wenn Sie vor allem Wert auf eine einfache Verwaltung legen, verwenden Sie ein Domänenkonto mit minimalen Rechten.
    Sie können ein Domänenkonto mit minimalen Rechten zum Ausführen von ASP.NET verwenden, um das manuelle Aktualisieren und Synchronisieren von Kennwörtern zu vermeiden. Es ist äußerst wichtig, dass das Domänenkonto vollständig gesperrt wird, um die Bedrohung für Prozesse zu verringern. Wenn es einem Angreifer gelingt, den ASP.NET-Workerprozess anzugreifen, besitzt diese Person die Möglichkeit, auf die Domänenressourcen zuzugreifen, wenn das Konto nicht vollständig gesperrt ist.

Hinweis: Wenn Sie ein lokales Konto verwenden und dieses erfolgreich angegriffen wird, können nur die Computer weiter angegriffen werden, auf denen Sie Duplikate des Kontos erstellt haben. Wenn Sie ein Domänenkonto verwenden, ist das Konto für jeden Computer in der Domäne sichtbar. Das Konto muss jedoch weiterhin über die entsprechende Berechtigung verfügen, um auf diese Computer zugreifen zu können.

Das <processModel>-Element

Das <processModel>-Element in der Datei machine.config enthält die Attribute Benutzername und Kennwort, die das Konto festlegen, das zum Ausführen des ASP.NET-Workerprozesses Aspnet_wp.exe verwendet werden soll.

Hinweis: Im Gegensatz zur Ausführungsweise der klassischen ASP-Anwendungen wird der ASP.NET-Code niemals im Prozess der Datei dllhost.exe oder als IWAM_MACHINENAME-Konto ausgeführt, wenn die Schutzebene der Anwendung in IIS den Wert Hoch (isoliert) erhält.

An IIS gesendete ASP.NET-Anforderungen werden direkt zum ASP.NET-Workerprozess (Aspnet_wp.exe) umgeleitet. Die ASP.NET ISAPI-Erweiterung (Aspnet_isapi.dll) wird im Prozessadressraum von IIS (Inetinfo.exe) ausgeführt. (Dieser wird durch den Metabasiseintrag InProcessIsapiApps gesteuert, der nicht geändert werden sollte.) Die ISAPI-Erweiterung ist für das Umleiten von Anforderungen an den ASP.NET-Workerprozess verantwortlich. ASP.NET-Anwendungen werden dann im ASP.NET-Workerprozess ausgeführt, wobei Anwendungsdomänen die Isolationsgrenzen bereitstellen.

In IIS 6 haben Sie die Möglichkeit, ASP.NET-Anwendungen durch Konfigurieren von Anwendungspools zu isolieren, wobei jeder Pool eine eigene Anwendungsinstanz besitzt.

Es stehen Ihnen einer Reihe von Optionen zum Konfigurieren des Benutzername-Attributs von <processModel> zur Verfügung. Beispiel:

  • "Computer" – Der Workerprozess wird als ASPNET-Standardkonto mit minimalen Rechten ausgeführt. Das Konto verfügt über Netzwerkzugriff, kann jedoch nicht für andere Computer im Netzwerk authentifiziert werden, da das Konto für den Computer lokal verfügbar und somit keine Autorität vorhanden ist, die sich für das Konto verbürgen kann. Im Netzwerk wird dieses Konto als "Computername\ASPNET" dargestellt.

  • "system" – Der Workerprozess wird als lokales Konto SYSTEM ausgeführt. Dieses Konto verfügt über umfangreiche Rechte auf dem lokalen Computer und kann mithilfe der Anmeldeinformationen des Computers auf das Netzwerk zugreifen. Im Netzwerk wird dieses Konto als "DomainName\MachineName$" dargestellt.

  • Bestimmte Anmeldeinformationen Wenn Sie Anmeldeinformationen für die Attribute Benutzername und Kennwort bereitstellen, denken Sie an das Prinzip der minimalen Rechte. Wenn Sie ein lokales Konto angeben, kann die Webanwendung erst dann im Netzwerk authentifiziert werden, wenn Sie ein Duplikat des Kontos auf dem Remotecomputer erstellen. Wenn Sie sich dafür entscheiden, ein Domänenkonto mit minimalen Rechten zu verwenden, stellen Sie sicher, dass es sich nicht um ein Konto handelt, das für den Zugriff auf mehr Computer im Netzwerk berechtigt ist als notwendig.

Speichern verschlüsselter <processModel>-Anmeldeinformationen

Wenn Sie benutzerdefinierte Anmeldeinformationen verwenden, speichern Sie verschlüsselte Anmeldeinformationen mithilfe des Dienstprogramms aspnet_setreg.exe in der Registrierung. Vermeiden Sie unverschlüsselte Anmeldeinformationen in der Datei machine.config.

Einzelheiten zu diesem Dienstprogramm und zum Download finden Sie im Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig), in der Microsoft Knowledge Base.

Das folgende Beispiel zeigt das Format der Benutzernamen- und Kennwort-Attribute vor und nach der Verwendung des Dienstprogramms. Beachten Sie den Verweis der Attributwerte auf den gesicherten Registrierungsschlüssel und die benannten Werte, die die verschlüsselten Anmeldeinformationen enthalten.

<!-- Before -->
<processModel userName="SomeCustomAccount"
              password="ClearTextPassword" . . ./>

<!-- After -->
<processModel
        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,password" . . ./>
   

Weitere Informationen

  • Weitere Informationen über das Zugreifen auf Netzwerkressourcen von ASP.NET-Webanwendungen finden Sie unter "Zugreifen auf Netzwerkressourcen" weiter unten in diesem Modul.

  • Ausführliche Informationen über das Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET finden Sie unter "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET" in diesem Handbuch.

Identitätswechsel

Durch die Einführung von FileAuthorizationModule und die effiziente Verwendung von Gatekeepern und Vertrauensgrenzen kann sich der Identitätswechsel in ASP.NET eher als Nachteil denn als Vorteil erweisen.

Identitätswechsel und lokale Ressourcen

Wenn Sie den Identitätswechsel verwenden und über Ihren Webanwendungscode auf lokale Ressourcen zugreifen, müssen Sie die jeder gesicherten Ressource zugeordneten ACLs so konfigurieren, dass diese einen ACE enthalten, der dem authentifizierten Benutzer zumindest den Lesezugriff gewährt.

Ein besserer Ansatz ist es jedoch, den Identitätswechsel zu vermeiden, dem ASP.NET-Prozesskonto Berechtigungen zu erteilen und die URL-Autorisierung, die Dateiautorisierung sowie eine Kombination aus deklarativen und imperativen rollenbasierten Überprüfungen zu verwenden.

Identitätswechsel und Remoteressourcen

Wenn Sie den Identitätswechsel verwenden und dann über Ihren Webanwendungscode auf Remoteressourcen zugreifen, schlägt dieser Zugriff fehl, sofern Sie nicht die Standard-, Formular- oder Kerberos-Authentifizierung verwenden. Wenn Sie die Kerberos-Authentifizierung verwenden, müssen die Benutzerkonten ordnungsgemäß für die Delegierung konfiguriert sein. Sie müssen in Active Directory als Konto ist vertraulich und kann nicht delegiert werden gekennzeichnet sein.

Weitere Informationen

Weitere Informationen zum Konfigurieren der Kerberos-Delegierung finden Sie unter "Vorgehensweise:

  • "Übermitteln des ursprünglichen Benutzers an die Datenbank in Modul 5, "Intranetsicherheit".

  • "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

Identitätswechsel und Threading

Wenn ein Thread, der einen Identitätswechsel durchgeführt hat, einen neuen Thread erstellt, erbt der neue Thread den Sicherheitskontext des ASP.NET-Prozesskontos und nicht das gewechselte Konto.

Zugreifen auf Systemressourcen

ASP.NET führt standardmäßig keinen Identitätswechsel durch. Wenn die Webanwendung daher auf lokale Systemressourcen zugreift, erfolgt dies über den Sicherheitskontext, der dem Workerprozess Aspnet_wp.exe zugeordnet ist. Der Sicherheitskontext wird von dem Konto bestimmt, das zum Ausführen des Workerprozesses verwendet wird.

Zugreifen auf das Ereignisprotokoll

Konten mit minimalen Rechten verfügen über ausreichende Berechtigungen, um Datensätze mithilfe vorhandener Ereignisquellen in das Ereignisprotokoll zu schreiben. Sie verfügen jedoch nicht über ausreichend Berechtigungen, um neue Ereignisquellen zu erstellen. Dies erfordert einen neuen Eintrag, der unter der folgenden Registrierungsstruktur eingefügt wird.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Erstellen Sie bei Verfügbarkeit von Administratorrechten die von der Anwendung bei der Installation verwendeten Ereignisquellen, um dieses Problem zu vermeiden. Ein guter Ansatz ist es, eine .NET-Installationsklasse zu verwenden, die vom Windows Installer (wenn Sie die MSI-Bereitstellung verwenden) oder vom Systemdienstprogramm InstallUtil.exe (wenn Sie sie nicht verwenden) instanziiert werden kann.

Wenn Sie keine Ereignisquellen bei der Installation erstellen können, müssen Sie die Berechtigung zum folgenden Registrierungsschlüssel hinzufügen und dem ASP.NET-Prozesskonto (eines beliebigen gewechselten Kontos, wenn Ihre Anwendung den Identitätswechsel verwendet) den Zugriff erteilen.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

Die Konten müssen die folgenden minimalen Rechte besitzen:

  • Abfragen von Schlüsselwerten

  • Festlegen von Schlüsselwerten

  • Erstellen von Unterschlüsseln

  • Auflisten von Unterschlüsseln

  • Benachrichtigen

  • Lesen

Folgender Code kann zum Schreiben von ASP.NET in das Anwendungsereignisprotokoll verwendet werden, nachdem die Berechtigungen auf die Registrierung angewendet wurden:

string source = "Your Application Source";
string logToWriteTo = "Application";
string eventText = "Sample Event";

if (!EventLog.SourceExists(source))
{
  EventLog.CreateEventSource(source, logToWriteTo);
}
EventLog.WriteEntry(source, eventText, EventLogEntryType.Warning, 234);

Zugreifen auf die Registrierung

Jeder Registrierungsschlüssel, auf den Ihre Anwendung zugreift, erfordert einen ACE in der ACL, die (zumindest) den Lesezugriff auf das ASP.NET-Prozesskonto erteilt.

Weitere Informationen

Weitere Informationen zu Installationsklassen und dem Dienstprogramm "InstallUtil.exe" finden Sie im Abschnitt ".NET Framework Tools" des .NET Framework SDK in MSDN (englischsprachig).

Zugreifen auf COM-Objekte

Beim klassischen ASP werden Anforderungen mithilfe von Threads aus dem STA-Threadpool (Single Threaded Apartment) verarbeitet. ASP.NET verarbeitet Anforderungen über Threads aus dem MTA-Threadpool (Multithreaded Apartment). Dies hat Auswirkungen auf ASP.NET-Webanwendungen, die Apartmentmodellobjekte aufrufen.

Apartmentmodellobjekte

Wenn eine ASP.NET-Webanwendung ein Apartmentmodellobjekt aufruft (z. B. ein Visual Basic 6 COM-Objekt), sind zwei Details zu beachten:

  • Sie müssen die ASP.NET-Seite durch die Direktive AspCompat kennzeichnen, wie im Folgenden gezeigt.

    <%@ Page Language="C#" AspCompat="True" %>
    
  • Erstellen Sie die COM-Objekte nicht außerhalb bestimmter Seitenereignishandler. Erstellen Sie die COM-Objekte immer in Seitenereignishandlern (z. B.Page_Load und Page_Init). Erstellen Sie die COM-Objekte nicht im Konstruktor der Seite.

Erforderliche Direktive "AspCompat"

Standardmäßig verwendet ASP.NET MTA-Threads zum Verarbeiten von Anforderungen. Dies führt zu einem Threadwechsel, wenn ein Apartmentmodell von ASP.NET aufgerufen wird, da die MTA-Threads nicht direkt auf das Apartmentmodellobjekt zugreifen können (COM verwendet stattdessen einen STA-Thread).

Das Festlegen von AspCompat führt dazu, dass die Seite von einem STA-Thread verarbeitet wird. Dadurch wird der Threadwechsel von MTA zu STA vermieden. Dies ist aus Sicherheitsgründen von Bedeutung, wenn Ihre Webanwendung einen Identitätswechsel durchführt, da ein Threadwechsel zu einem verlorenen Identitätswechseltoken führt. Das neue Identitätswechseltoken wird dem neuen Thread nicht zugeordnet.

Die Direktive AspCompat wird für ASP.NET-Webdienste nicht unterstützt. Das bedeutet, dass beim Aufrufen von Apartmentmodellobjekten über den Webdienstcode ein Threadwechsel eintritt und Sie dann das Token für den Identitätswechsel verlieren. Dies führt normalerweise zu einer Ausnahmebedingung, bei der der Zugriff verweigert wird.

Weitere Informationen

Keine COM-Objekte außerhalb bestimmter Seitenereignisse erstellen

Erstellen Sie keine COM-Objekte außerhalb bestimmter Seitenereignishandler. Das folgende Codefragment zeigt, was nicht durchgeführt werden sollte.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
  // COM object created outside of Page events
  YourComObject obj = new apartmentObject();
  public void Page_Load()
  {
    obj.Foo()
  }
</script>

Wenn Sie Apartmentmodellobjekte verwenden, ist es wichtig, das Objekt, wie nachfolgend dargestellt, innerhalb bestimmter Seitenereignisse wie Page_Load zu erstellen.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
public void Page_Load()
{
  YourComObject obj  = new apartmentObject();
  obj.Foo()
}
</script>

Weitere Informationen

Weitere Informationen finden Sie im Artikel Q308095, "PRB: Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance" (englischsprachig), in der Microsoft Knowledge Base.

C#- und VB .NET-Objekte in COM+

Das Entwicklungstool Microsoft C#® und das Entwicklungssystem Microsoft Visual Basic® .NET unterstützen sämtliche Threadingmodelle (Free-Thread, Neutral, Beide und Apartment). Standardmäßig werden C#- und Visual Basic .NET-Objekte als Beide gekennzeichnet, wenn sie in COM+ verwaltet werden. Daher erfolgt der Zugriff direkt, und es wird kein Threadwechsel verursacht, wenn sie von ASP.NET aufgerufen werden.

Zugreifen auf Netzwerkressourcen

Ihre Anwendung muss möglicherweise auf Netzwerkressourcen zugreifen. Dabei ist es wichtig, dass Folgendes identifiziert werden kann:

  • Die Ressource, auf die Ihre Anwendung zugreifen muss.

    Beispielsweise Dateien in Dateifreigaben, Datenbanken, DCOM-Server, Active Directory-Objekte usw.

  • Die zum Durchführen des Ressourcenzugriffs verwendete Identität.

    Wenn Ihre Anwendung auf Remoteressourcen zugreift, muss diese Identität vom Remotecomputer authentifiziert werden können.

Hinweis: Weitere Informationen zum Zugreifen auf SQL Server-Remotedatenbanken finden Sie in Modul 12, "Datenzugriffssicherheit."

Sie können über eine ASP.NET-Anwendung auf Remoteressourcen zugreifen, indem Sie eines der folgenden Verfahren verwenden:

  • Verwenden der ASP.NET-Prozessidentität

  • Verwenden einer Serviced Component.

  • Verwenden des anonymen Internetbenutzerkontos (z. B. IUSR_MACHINE).

  • Verwenden der API LogonUser und Durchführen eines Identitätswechsels für eine bestimmte Windows-Identität.

  • Verwenden des ursprünglichen Benutzers.

Verwenden der ASP.NET-Prozessidentität

Wenn die Anwendung nicht für den Identitätswechsel konfiguriert wurde, stellt die ASP.NET-Prozessidentität die Standardidentität bereit, wenn die Anwendung versucht, auf Remoteressourcen zuzugreifen. Wenn Sie das ASP.NET-Prozesskonto für den Zugriff auf Remoteressourcen verwenden möchten, haben Sie drei Möglichkeiten:

  • Verwenden von gespiegelten Konten.
    Die ist der einfachste Ansatz. Sie erstellen auf dem Remotecomputer ein lokales Konto mit übereinstimmendem Benutzernamen und Kennwort. Sie müssen das Kennwort des ASPNET-Kontos im Benutzer-Manager in einen bekannten Wert ändern (verwenden Sie ein sicheres Kennwort). Sie müssen dieses dann explizit für das <processModel>-Element in der Datei machine.config ändern und den vorhandenen Wert AutoGenerate ersetzen. Vermeiden Sie unverschlüsselte Anmeldeinformationen. Verwenden Sie das Dienstprogramm aspnet_setreg.exe, um verschlüsselte Anmeldeinformationen in der Registrierung zu speichern (wie oben erläutert).

    Wichtig: Wenn Sie das ASPNET-Kennwort in einen bekannten Wert ändern, stimmt das Kennwort in der LSA nicht länger mit dem Kennwort des SAM-Kontos überein. Wenn Sie zum Standardwert AutoGenerate zurückkehren möchten, müssen Sie Folgendes tun:

    Führen Sie Aspnet_regiis.exe aus, um ASP.NET auf seine Standardkonfiguration zurückzusetzen. Weitere Informationen finden Sie im Artikel 306005, "SO WIRD'S GEMACHT: Reparieren der IIS-Zuordnung nach dem Entfernen und erneuten Installieren von IIS", in der Microsoft Knowledge Base.

  • Erstellen Sie ein benutzerdefiniertes Konto mit minimalen Rechten zum Ausführen von ASP.NET, und erstellen Sie ein dupliziertes Konto auf dem Remotecomputer.

  • Führen Sie ASP.NET mithilfe eines Domänenkontos mit minimalen Rechten aus.

    Voraussetzung dabei ist, dass sich Client- und Servercomputer in derselben oder in vertrauten Domänen befinden.

Weitere Informationen

Weitere Informationen zum Konfigurieren eines ASP.NET-Prozesskontos finden Sie unter "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET" in diesem Handbuch.

Verwenden einer Serviced Component

Sie können eine prozessexterne Serviced Component für den Zugriff auf Netzwerkressourcen verwenden, die für die Ausführung als feste Identität konfiguriert ist. Dieser Ansatz wird in Abbildung 8.6 dargestellt.

Verwenden einer prozessexternen Serviced Component, um eine feste Identität für den Zugriff auf Netzwerkressourcen bereitzustellen

Abbildung 8.6
Verwenden einer prozessexternen Serviced Component, um eine feste Identität für den Zugriff auf Netzwerkressourcen bereitzustellen

Das Verwenden einer prozessexternen Serviced Component (in einer Enterprise Services-Serveranwendung) hat folgende Vorteile:

  • Flexibilität hinsichtlich der verwendeten Identität. Keine ausschließliche Abhängigkeit von der ASP.NET-Identität.

  • Vertrauenswürdiger Code oder Code mit umfangreicheren Rechten kann von der zentralen Webanwendung isoliert werden.

  • Ein zusätzlicher Prozesshop erhöht die Sicherheit. Es wird für einen Angreifer wesentlich schwieriger, die Grenzen zu einem Prozess mit erhöhten Rechten zu durchbrechen.

  • Wenn Sie den Identitätswechsel manuell durch Aufrufen der API LogonUser durchführen möchten, können Sie das mithilfe eines Prozesses tun, der von der Haupt-Webanwendung getrennt ist.

    Hinweis: Um LogonUser aufrufen zu können, müssen Sie dem Prozesskonto für die Enterprise Services das Recht Als Teil des Betriebssystems handeln zuweisen. Das Erhöhen der Rechte für einen Prozess, der von der Webanwendung getrennt ist, erweist sich in geringerem Maße als Sicherheitsproblem.

Verwenden des anonymen Internetbenutzerkontos

Sie können das anonyme Internetbenutzerkonto für den Zugriff auf Netzwerkressourcen verwenden, wenn IIS für die anonyme Authentifizierung konfiguriert wurde. Dies ist der Fall, wenn eine der folgenden Optionen zutrifft:

  • Ihre Anwendung unterstützt den anonymen Zugriff.

  • Ihre Anwendung verwendet die Formular-, Passport- oder benutzerdefinierte Authentifizierung (wobei IIS für den anonymen Zugriff konfiguriert ist).

  • So verwenden Sie das anonyme Konto für den Zugriff auf Remoteressourcen

    1. Konfigurieren Sie IIS für die anonyme Authentifizierung. Sie können den ASP.NET-Authentifizierungsmodus je nach den Authentifizierungsanforderungen der Anwendung auf Windows, Formular, Passport oder Keine festlegen.

    2. Konfigurieren Sie ASP.NET für den Identitätswechsel. Verwenden Sie die folgende Einstellung in der Datei web.config:

      <identity impersonate="true" />
      
    3. Konfigurieren Sie das anonyme Konto als Domänenkonto mit minimalen Rechten.

      – oder –

      Duplizieren Sie das anonyme Konto, indem Sie denselben Benutzernamen und dasselbe Kennwort auf dem Remotecomputer verwenden. Dieser Ansatz ist erforderlich, wenn Sie Aufrufe über nicht vertrauenswürdige Domänen oder über Firewalls hinweg ausführen, bei denen die zum Unterstützen der integrierten Windows-Authentifizierung erforderlichen Ports nicht geöffnet sind.

      Um diesen Ansatz zu unterstützen, führen Sie außerdem Folgendes durch:

      1. Verwenden Sie den Internetdienste-Manager, um das Kontrollkästchen Kennwortsteuerung durch IIS zulassen für das anonyme Konto zu deaktivieren.

        Wenn Sie diese Option aktivieren, erhält die mit dem angegebenen anonymen Konto erstellte Anmeldesitzung KEINE Netzwerkanmeldeinformationen (und kann daher nicht für den Zugriff auf Netzwerkressourcen verwendet werden). Wenn Sie diese Option nicht aktivieren, wird die Anmeldesitzung zu einer interaktiven Anmeldesitzung mit Netzwerkanmeldeinformationen.

      2. Legen Sie die Anmeldeinformationen des Kontos sowohl im Benutzer-Manager als auch im Internetdienste-Manager fest.

Wichtig: Wenn Sie die Identität für das anonyme Konto wechseln (z. B. IUSR_MACHINE), müssen die Ressourcen mithilfe entsprechend konfigurierter ACLs vor diesem Konto geschützt werden. Ressourcen, auf die Ihre Anwendung zugreifen muss, müssen dem anonymen Konto (mindestens) Lesezugriff erteilen. Alle anderen Ressourcen sollten dem anonymen Konto den Zugriff verweigern.

Hosten mehrerer Webanwendungen

Sie können für jedes virtuelle Stammverzeichnis Ihrer Website ein separates anonymes Internetbenutzerkonto verwenden. Dadurch können Sie in einer Hostumgebung Anforderungen, die von separaten Webanwendungen stammen, getrennt autorisieren, nachverfolgen und überprüfen. Dieser Ansatz wird in Abbildung 8.7 dargestellt.

Identitätswechsel für separate anonyme Internetbenutzerkonten über eine Anwendung durchführen (v-dir)

Abbildung 8.7
Identitätswechsel für separate anonyme Internetbenutzerkonten über eine Anwendung durchführen (v-dir)

  • So konfigurieren Sie das anonyme Internetbenutzerkonto für ein bestimmtes virtuelles Verzeichnis

    1. Starten Sie in der Programmgruppe Verwaltung den Internetdienste-Manager.

    2. Wählen Sie das zu konfigurierende virtuelle Verzeichnis aus und klicken Sie mit der rechten Maustaste darauf. Klicken Sie dann auf Eigenschaften.

    3. Klicken Sie auf die Registerkarte Verzeichnissicherheit.

    4. Klicken Sie in der Gruppe Steuerung des anonymen Zugriffs und der Authentifizierung auf Bearbeiten.

    5. Wählen Sie Anonymer Zugriff und klicken Sie dann auf Bearbeiten.

    6. Geben Sie den Benutzernamen und das Kennwort für das Konto ein, das IIS verwenden soll, wenn anonyme Benutzer eine Verbindung zur Site herstellen.

    7. Stellen Sie sicher, dass die Option Kennwortsteuerung durch IIS zulassen NICHT aktiviert ist.

Verwenden von "LogonUser" und Durchführen des Identitätswechsels für eine bestimmte Windows-Identität

Sie können für eine bestimmte Identität einen Identitätswechsel durchführen, indem Sie die Attribute für Benutzernamen und Kennwort des <identity>-Elements in der Datei web.config konfigurieren oder die Win32®-API LogonUser im Anwendungscode aufrufen.

Wichtig: Wie in diesem Modul bereits erwähnt, ist die Verwendung von LogonUser oder ein Identitätswechsel zu festen Identitäten nicht zu empfehlen, wenn Sie das .NET Framework 1.0 auf Servern unter Windows 2000 nutzen. Denn in beiden Fällen wären Sie gezwungen, dem ASP.NET-Prozesskonto das Recht Als Teil des Betriebssystems handeln zu erteilen.

Windows Server 2003 hebt diese Einschränkung auf. Darüber hinaus stellt das .NET Framework Version 1.1 für dieses Szenario unter Windows 2000 eine Erweiterung bereit. Die Anmeldung wird vom IIS-Prozess durchgeführt, damit ASP.NET das Recht Als Teil des Betriebssystems handeln nicht erfordert.

Verwenden des ursprünglichen Benutzers

Damit Sie die Identität des ursprünglichen Benutzers für den Zugriff auf Remoteressourcen verwenden können, müssen Sie den Sicherheitskontext des Benutzers vom Webserver an den Remotecomputer delegieren können.

Skalierbarkeitswarnung: Wenn Sie auf die Datendienstebene der Anwendung mithilfe der gewechselten Identität des ursprünglichen Benutzers zugreifen, beeinflussen Sie die Skalierbarkeit der Anwendung erheblich, da das Datenbankverbindungspooling ineffektiv wird. Der Sicherheitskontext für Datenbankverbindungen ist für jeden Benutzer verschieden.

Die folgenden Authentifizierungsschemata unterstützen die Delegierung:

  • Kerberos – Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

  • Windows-Konten zugeordnete Clientzertifikate – Die Zuordnung muss von IIS durchgeführt werden.

  • Standard – Die Standardauthentifizierung unterstützt den Zugriff auf Remoteressourcen, da die Anmeldeinformationen des ursprünglichen Benutzers unverschlüsselt auf dem Webserver zur Verfügung stehen. Diese können dazu verwendet werden, auf Authentifizierungsherausforderungen von Remotecomputern zu reagieren.
    Die Standardauthentifizierung muss zusammen mit einer interaktiven oder Batchanmeldesitzung verwendet werden. Der Typ der Anmeldesitzung, der sich durch die Standardauthentifizierung ergibt, kann in der IIS-Metabasis konfiguriert werden. Weitere Informationen finden Sie in MSDN in Platform SDK: Internet Information Services 5.1.

    Wichtig: Die Standardauthentifizierung stellt den unsichersten Ansatz dar, der die Delegierung unterstützt. Der Grund: Der Browser übergibt Benutzername und das Kennwort unverschlüsselt über das Netzwerk an den Server und speichert diese dann auf dem Webserver zwischen. Sie können SSL verwenden, um die Anmeldeinformationen bei der Übertragung zu schützen, aber Sie sollten nach Möglichkeit vermeiden, unverschlüsselte Anmeldeinformationen auf dem Webserver zwischenzuspeichern.

  • So verwenden Sie den ursprünglichen Benutzer für den Zugriff auf Remoteressourcen

    1. Konfigurieren Sie IIS für die integrierte Windows-Authentifizierung (Kerberos), die Zertifikatsauthentifizierung (mit der IIS-Zertifikatszuordnung) oder die Standardauthentifizierung.

    2. Konfigurieren Sie ASP.NET für die Windows-Authentifizierung und den Identitätswechsel.

      <authentication mode="Window" />
      <identity impersonate="true" />
      
    3. Wenn Sie die Kerberos-Delegierung verwenden, konfigurieren Sie die Active Directory-Konten für die Delegierung.

Weitere Informationen

Zugreifen auf Dateien auf einer UNC-Dateifreigabe

Wenn Ihre Anwendung über ASP.NET auf Dateien zugreifen muss, die sich auf einer UNC-Freigabe (Universal Naming Convention) befinden, ist es wichtig, dass Sie dem Ordner der Freigabe die NTFS-Berechtigungen hinzufügen. Sie müssen auch die Berechtigungen der Freigabe so festlegen, dass entweder dem ASP.NET-Prozesskonto oder der gewechselten Identität (wenn die Anwendung für den Identitätswechsel konfiguriert ist) zumindest der Lesezugriff erteilt wird.

Zugreifen auf Netzwerkressourcen, die nicht auf Windows basieren

Wenn die Anwendung auf Ressourcen zugreifen muss, die nicht auf Windows basieren, z. B. Datenbanken, die sich nicht auf Windows-Plattformen befinden, oder Großrechneranwendungen, sollten Sie die folgenden Fragen bedenken:

  • Welche Gatekeeper und Vertrauensgrenzen sind dieser Ressource zugeordnet?

  • Welche Anmeldeinformationen sind für die Authentifizierung erforderlich?

  • Muss der Ressource die Identität des ursprünglichen Benutzers bekannt sein, oder vertraut sie der Anwendung (unter Verwendung eines festen Prozesses oder einer Dienstidentität)?

  • Welche Leistungseinbußen sind mit dem Einrichten von Verbindungen verbunden? Wenn damit erhebliche Einbußen verbunden sind, müssen Sie möglicherweise das Verbindungspooling implementieren, indem Sie z. B. das Objektpooling von Enterprise Services verwenden.

Wenn die Ressource in der Lage sein muss, den ursprünglichen Benutzer zu authentifizieren (und die Windows-Authentifizierung keine Option darstellt), stehen Ihnen die folgenden Optionen zur Verfügung:

  • Übergeben der Anmeldeinformationen mithilfe von Parametern (für den Methodenaufruf).

  • Übergeben von Anmeldeinformationen in einer Verbindungszeichenfolge. Verwenden von SSL oder IPSec, um über ein Netzwerk gesendete unverschlüsselte Anmeldeinformationen zu schützen.
    Speichern Sie die Anmeldeinformationen sicher in Ihrer Anwendung, z. B. durch Verwenden von DPAPI. Weitere Informationen zum sicheren Speichern von Datenbank-Verbindungszeichenfolgen finden Sie unter "Sicheres Speichern von Datenbank-Verbindungszeichenfolgen" in Modul 12, "Datenzugriffssicherheit".

  • Verwenden eines zentralen Datenspeichers für die Authentifizierung, auf den beide Plattformen zugreifen können, z. B. ein LDAP-Verzeichnis.

Sichere Kommunikation

Verwenden Sie SSL, um die Kommunikation zwischen dem Browser und dem Webserver zu sichern. SSL ermöglicht die Vertraulichkeit und die Integrität von Nachrichten. Verwenden Sie SSL und/oder IPSec, um einen sicheren Kanal vom Webserver zum Anwendungs- oder Datenbankserver bereitzustellen.

Weitere Informationen

Weitere Informationen zur sicheren Kommunikation finden Sie in Modul 4, "Sichere Kommunikation".

Speichern von vertraulichen Daten

Webanwendungen müssen häufig vertrauliche Daten speichern. Diese Daten müssen vor unberechtigten Administratoren und böswilligen Webbenutzern geschützt werden:

  • Unberechtigte Administratoren – Unberechtigte Administratoren oder gewissenlose Benutzer sollten nicht in der Lage sein, durch Rechte geschützte Informationen anzuzeigen. Der Administrator des Webservers sollte z. B. nicht das Kennwort eines Anmeldekontos für einen SQL Server lesen können, der sich auf einem Computer im Netzwerk befindet.

  • Böswillige Webbenutzer – Obwohl Komponenten vorhanden sind (z. B. FileAuthorizationModule), die Benutzern den Zugriff auf durch Rechte geschützte Dateien verwehren, sollten die vertraulichen Daten in der Datei nicht unverschlüsselt enthalten sein, falls ein Angreifer Zugang zu einer Konfigurationsdatei erlangt.

Typische Beispiele für vertrauliche Daten sind:

  • SQL-Verbindungszeichenfolgen – Ein häufiger Fehler ist es, den Benutzernamen und das Kennwort unverschlüsselt zu speichern. Es wird empfohlen, die Windows-Authentifizierung statt der SQL-Authentifizierung zu verwenden. Wenn Sie die Windows-Authentifizierung nicht verwenden können, lesen Sie die folgenden Abschnitte im Modul 12, "Datenzugriffssicherheit", die sichere Alternativen beschreiben.

    • "Sicheres Speichern von Datenbank-Verbindungszeichenfolgen

    • "Sichere Kommunikation"

  • Anmeldeinformationen für SQL-Anwendungsrollen – SQL-Anwendungsrollen müssen über eine gespeicherte Prozedur aktiviert werden, die den Rollennamen und das zugehörige Kennwort erfordert. Weitere Informationen finden Sie unter "Autorisierung" in Modul 12, "Datenzugriffssicherheit".

  • Feste Identitäten in der Datei "web.config" – Beispiel:

    <identity impersonate="true" userName="Bob" password="inClearText"/>
    

    Mit dem Dienstprogramm aspnet_setreg.exe können Sie unverschlüsselte Anmeldeinformationen durch einen Zeiger auf einen gesicherten Registrierungsschlüssel ersetzen, der die verschlüsselten Anmeldeinformationen enthält.

  • Prozessidentität in der Datei "machine.config" – Beispiel:

    <process userName="cUsTuMUzerName" password="kUsTumPazzWerD" >
    

    Verwenden Sie in Bezug auf das <identity>-Element das Dienstprogramm aspnet_setreg.exe, um verschlüsselte Anmeldeinformationen in der Registrierung zu speichern.

  • Schlüssel, die zum sicheren Speichern von Daten verwendet werden – Es ist unmöglich, Schlüssel in der Software sicher zu speichern. Bestimmte Maßnahmen können dieses Risiko jedoch verringern. Ein Beispiel stellt das Erstellen eines Abschnittshandlers für benutzerdefinierte Konfigurationen dar, der Sitzungsschlüssel asymmetrisch verschlüsselt. Der Sitzungsschlüssel kann dann in einer Konfigurationsdatei gespeichert werden.

  • SQL Server-Sitzungsstatus – Verwenden Sie die folgenden Einstellungen für die Datei web.config, um den Sitzungsstatus von ASP.NET-Webanwendungen mithilfe von SQL Server zu verwalten.

    <sessionState ... stateConnectionString="tcpip=127.0.0.1:42424"
                    sqlConnectionString="data source=127.0.0.1;
                    user id=UserName;password=MyPassword" />
    

    Das Dienstprogramm aspnet_setreg.exe unterstützt die Attribute stateConnectionString und sqlConnectionString für das <sessionState>-Element. Damit können Sie diese Werte verschlüsselt in der Registrierung speichern.

  • Kennwörter, die für die Formularauthentifizierung anhand einer Datenbank verwendet werden

    Wenn die Anwendung Anmeldeinformationen für die Authentifizierung anhand einer Datenbank überprüft, sollten Sie Kennwörter nicht in der Datenbank speichern. Verwenden Sie einen Hash des Kennworts mit einem Salt-Wert, und vergleichen Sie dann die Hashes.

    Weitere Informationen finden Sie unter "Authentifizieren von Benutzern anhand einer Datenbank" in Modul 12, "Datenzugriffssicherheit".

Optionen zum Speichern von vertraulichen Daten in ASP.NET

Entwicklern von .NET-Webanwendungen bietet sich eine Reihe von Ansätzen zum Speichern von vertraulichen Daten. Dabei handelt es sich um die folgenden:

  • .NET-Kryptografieklassen – .NET Framework umfasst Klassen, die zum Verschlüsseln und Entschlüsseln verwendet werden können. Diese Ansätze erfordern, dass Sie den Verschlüsselungsschlüssel sicher speichern.

  • Data Protection API (DPAPI) – Die DPAPI besteht aus einem Paar Win32-APIs, die Daten mithilfe eines Schlüssels ver- und entschlüsseln, der vom Kennwort des Benutzers abgeleitet wird. Wenn Sie die DPAPI verwenden, müssen Sie sich nicht um die Schlüsselverwaltung kümmern. Das Betriebssystem verwaltet den Schlüssel, bei dem es sich um das Kennwort des Benutzers handelt.

  • COM+-Konstruktorzeichenfolgen – Wenn die Anwendung Serviced Components verwendet, können Sie die vertraulichen Daten in einer Zeichenfolge zur Objektkonstruktion speichern. Die Zeichenfolge wird in unverschlüsselter Textform im COM+-Katalog gespeichert.

  • CAPICOM – Dies ist ein Microsoft COM-Objekt, das COM-basierten Zugriff für die zugrunde liegende Crypto API bereitstellt.

  • Crypto API – Dies sind Win32-APIs auf unterer Ebene, die die Verschlüsselung und Entschlüsselung durchführen.

Weitere Informationen

Weitere Informationen finden Sie unter dem Eintrag "Cryptography, CryptoAPI and CAPICOM" im Platform SDK in MSDN (englischsprachig).

Speichern vertraulicher Daten in Dateien auf separaten logischen Datenträgern

Erwägen Sie die Installation von Webanwendungsverzeichnissen auf einem vom Betriebssystem getrennten logischen Datenträger (z. B. E: anstelle von C:). Das bedeutet, dass sich die Datei machine.config (Speicherort C:\WINNT\Microsoft.NET) und möglicherweise andere Dateien, die vertrauliche Daten enthalten (z. B. UDL-Dateien), auf einem von den Webanwendungsverzeichnissen getrennten logischen Datenträger befinden.

Der Hintergrund für diesen Ansatz liegt im Schutz vor möglichen Fehlern bei der Dateivereinheitlichung und Verzeichnisdurchquerung. Begründung:

  • Fehler bei der Dateivereinheitlichung können Dateien in Ordnern von Webanwendungen offen legen.

    Hinweis: Routinen für die Dateivereinheitlichung geben die kanonische Form eines Dateipfades zurück. Hierbei handelt es sich normalerweise um den absoluten Pfadnamen, in dem alle relativen Verweise und alle Verweise auf das aktuelle Verzeichnis vollständig aufgelöst wurden.

  • Fehler bei der Verzeichnisdurchquerung können Dateien in anderen Ordnern auf demselben logischen Datenträger offen legen.

Bis jetzt wurden keine Fehler der oben beschriebenen Art veröffentlicht, die Dateien auf anderen logischen Datenträgern offen gelegt hätten.

Sichern von Sitzungs- und Ansichtsstatus

Webanwendungen müssen verschiedene Statusarten verwalten, einschließlich Ansichts- und Sitzungsstatus. In diesem Abschnitt wird die sichere Statusverwaltung für ASP.NET-Webanwendungen beschrieben.

Sichern des Ansichtsstatus

Gehen Sie wie folgt vor, wenn Ihre ASP.NET-Webanwendungen den Ansichtsstatus verwenden:

  • Stellen Sie die Integrität des Ansichtsstatus sicher (und damit, dass dieser bei der Übertragung nicht verändert wird), indem Sie für enableViewStateMac den Wert true festlegen (wie im Folgenden veranschaulicht). Dies führt dazu, dass ASP.NET einen Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) für den Ansichtsstatus der Seite generiert, wenn die Seite wieder vom Client zurückübermittelt wird.

    <% @ Page enableViewStateMac=true >
    
  • Konfigurieren Sie in der Datei machine.config das validation-Attribut für das <machineKey>-Element, um den für die Datenüberprüfung und Verschlüsselung zu verwendenden Verschlüsselungstyp festzulegen. Berücksichtigen Sie hinsichtlich des validation-Attributs Folgendes:

    • Der SHA1 (Secure Hash Algorithm) erzeugt einen größeren Hash als MD5 (Message Digest 5) und wird daher als sicherer erachtet. Ein durch SHA1 oder MD5 geschützter Ansichtsstatus kann jedoch bei der Übertragung oder auf der Clientseite entschlüsselt und möglicherweise unverschlüsselt angezeigt werden.

    • Verwenden Sie 3DES (Dreifach-DES, 3 Data Encryption Standard), um Änderungen am Ansichtsstatus zu ermitteln und diesen während der Übertragung zu verschlüsseln. Wenn er sich in diesem Zustand befindet, kann er auch dann nicht unverschlüsselt angezeigt werden, wenn der Ansichtsstatus decodiert wurde.

Sichern von Cookies

Cookies, die Authentifizierungs- oder Autorisierungsdaten oder andere vertrauliche Daten enthalten, sollten bei der Übertragung mithilfe von SSL gesichert werden. Bei der Formularauthentifizierung kann die FormsAuthentication.Encrypt-Methode verwendet werden, um das Authentifizierungsticket zu verschlüsseln, das in einem Cookie zwischen Client und Server übergeben wird.

Sichern des SQL-Sitzungsstatus

Der Standardhandler für den (prozessinternen) ASP.NET-Sitzungsstatus unterliegt bestimmten Einschränkungen. Er kann z. B. in einer Webfarm nicht computerübergreifend arbeiten. ASP.NET ermöglicht das Speichern des Sitzungsstatus in einer SQL Server-Datenbank, um diese Einschränkung zu umgehen.

Der SQL-Sitzungsstatus kann entweder in der Datei machine.config oder in der Datei web.config konfiguriert werden. Die Standardeinstellung in der Datei machine.config wird nachfolgend veranschaulicht.

<sessionState mode="InProc" 
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10"
              sqlConnectionString="data source=127.0.0.1;user id=sa;password="
              cookieless="false" timeout="20"/>

Standardmäßig wird das SQL-Skript InstallSqlState.sql, mit dem die für den SQL-Sitzungsstatus verwendete Datenbank erstellt wird, an der folgenden Stelle installiert.

C:\WINNT\Microsoft.NET\Framework\v1.0.3705

Wenn Sie den SQL-Sitzungsstatus verwenden, sollten Sie zwei Probleme bedenken:

  • Sie müssen die Datenbank-Verbindungszeichenfolge sichern.

  • Sie müssen den Sitzungsstatus beim Durchqueren des Netzwerks sichern.

Sichern der Datenbank-Verbindungszeichenfolge

Wenn Sie die SQL-Authentifizierung zum Herstellen der Verbindung zum Server verwenden, enthält die im sqlConnectionString-Attribut angegebene Verbindungszeichenfolge einen Benutzernamen und ein Kennwort. Speichern Sie eine verschlüsselte Zeichenfolge mithilfe des Dienstprogramms aspnet_setreg.exe in der Registrierung. Das folgende Beispiel zeigt das <sessionState>-Element vor und nach der Verwendung von aspnet_setreg.exe.

<!-- Before -->
<sessionState 
    mode="SQLServer", 
    sqlConnectionString="data source=Server;user id=userID;password=pwd" . . . />
<!-- After -->
<sessionState mode="SQLServer"
              sqlConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
              sessionState\ASPNET_SETREG,sqlConnectionString" />

Hinweis: Wenn Sie den ASP.NET-Statusdienst verwenden, können Sie mit aspnet_setreg.exe auch das stateConnectionString-Attribut verschlüsseln.

Verwenden Sie nach Möglichkeit die Windows-Authentifizierung für die SQL Server-Statusdatenbank. Dies bietet den zusätzlichen Vorteil, dass die Verbindungszeichenfolge keine Anmeldeinformationen enthält, die über das Netzwerk an den Datenbankserver weitergegeben werden.

  • Für die Windows-Authentifizierung können Sie die ASP.NET-Prozessidentität (normalerweise ASPNET) verwenden.

    1. Erstellen Sie auf dem Datenbankserver ein Duplikat des Kontos (mit demselben Benutzernamen und Kennwort).

    2. Erstellen Sie einen SQL Server-Benutzernamen für das Konto.

    3. Erstellen Sie in der Datenbank ASPState einen Datenbankbenutzer und ordnen Sie den SQL Server-Benutzernamen dem neuen Benutzer zu.
      Die Datenbank ASPState wird von dem Skript InstallSQLState.sql erstellt.

    4. Erstellen Sie eine benutzerdefinierte Datenbankrolle und fügen Sie den Datenbankbenutzer zu dieser Rolle hinzu.

    5. Konfigurieren Sie in der Datenbank Berechtigungen für die Datenbankrolle.

Sie können dann die Verbindungszeichenfolge ändern, damit diese eine Verbindung verwendet, wie im Folgenden dargestellt:

sqlConnectionString="server=127.0.0.1;
                     database=StateDatabase;
                     Integrierte Sicherheit=SSPI;"
Sichern des Sitzungsstatus im Netzwerk

Sie müssen den Sitzungsstatus möglicherweise sichern, während dieser das Netzwerk auf dem Weg zur SQL Server-Datenbank durchquert. Dies hängt davon ab, wie sicher das Netzwerk ist, das den Webserver und die Datenserver verwaltet. Wenn die Datenbank in einer vertrauenswürdigen Umgebung physisch gesichert ist, können Sie auf diese zusätzliche Sicherheitsmaßnahme möglicherweise verzichten.

Sie können IPSec verwenden, um den gesamten IP-Verkehr zwischen den Webservern und SQL Server zu schützen, oder Sie verwenden SSL, um die Verknüpfung zu SQL Server zu sichern. Bei diesem Ansatz bietet sich Ihnen die Möglichkeit, nur die für den Sitzungsstatus verwendete Verbindung und nicht sämtlichen Verkehr zwischen den Computern zu verschlüsseln.

Weitere Informationen

  • Weitere Informationen zum Einrichten des SQL-Sitzungsstatus finden Sie im Artikel Q317604, "HOW TO: Configure SQL Server to Store ASP.NET Session State" (englischsprachig), in der Microsoft Knowledge Base.

  • Weitere Informationen zum Verwenden von SSL für SQL Server finden Sie unter "Vorgehensweise: Verwenden von SSL zum Sichern der Kommunikation mit SQL Server 2000" in diesem Handbuch.

  • Weitere Informationen zum Verwenden von IPSec finden Sie unter "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch.

Überlegungen zur Webfarm

In einem Webfarmszenario gibt es keine Garantie, dass aufeinander folgende Anforderungen desselben Clients auch von demselben Webserver bearbeitet werden. Dies hat Auswirkungen auf die Statusverwaltung und auf sämtliche Verschlüsselungen, die von Attributen abhängen, die vom <machineKey>-Element in der Datei machine.config verwaltet werden.

Sitzungsstatus

Die prozessinterne Standardbehandlung für den ASP.NET-Sitzungsstatus (die frühere ASP-Funktionen widerspiegelt) führt zu Serveraffinität und kann nicht in einem Webfarmszenario verwendet werden. Bei der Webfarmbereitstellung muss der Sitzungsstatus prozessextern entweder im ASP.NET-Statusdienst oder in einer SQL Server-Datenbank gespeichert werden (wie bereits erläutert).

Hinweis: Sie können sich beim Verwalten globaler Indikatoren oder eindeutiger Werte in Webfarm- (zum Ausführen auf mehreren Servern konfigurierte Webanwendung) oder Webgartenszenarios (zum Ausführen auf mehreren Prozessoren konfigurierte Webanwendung) nicht auf den Anwendungsstatus verlassen, da dieser nicht prozess- oder computerübergreifend freigegeben ist.

DPAPI

Die DPAPI kann entweder mit dem Computerspeicher oder mit dem Benutzerspeicher arbeiten (was ein geladenes Benutzerprofil voraussetzt). Wenn Sie die DPAPI mit dem Computerspeicher verwenden, ist die verschlüsselte Zeichenfolge für den jeweiligen Computer spezifisch, daher müssen die verschlüsselten Daten auf jedem Computer erzeugt werden. Sie können die verschlüsselten Daten nicht auf andere Computer in einer Webfarm oder in einem Cluster kopieren.

Wenn Sie DPAPI mit dem Benutzerspeicher verwenden, können die Daten auf jedem Computer mit einem servergespeicherten Benutzerprofil entschlüsselt werden.

Weitere Informationen

Weitere Informationen zu DPAPI finden Sie in Module 12, "Datenzugriffssicherheit".

Verwenden der Formularauthentifizierung in einer Webfarm

Wenn Sie die Formularauthentifizierung verwenden, ist es von größter Bedeutung, dass alle Server in der Webfarm einen gemeinsamen Computerschlüssel nutzen, der für die Verschlüsselung, Entschlüsselung und zur Überprüfung des Authentifizierungstickets verwendet wird.

Der Computerschlüssel wird in der Datei machine.config vom <machineKey>-Element verwaltet. Im Folgenden sehen Sie die Standardeinstellung.

<machineKey validationKey="AutoGenerate" 
            decryptionKey="AutoGenerate" 
            validation="SHA1"/> 

Diese Einstellung führt dazu, dass jeder Computer einen anderen Überprüfungs- und Entschlüsselungsschlüssel generiert. Sie müssen das <machineKey>-Element ändern und gemeinsame Schlüsselwerte auf allen Servern in der Webfarm speichern.

Das <machineKey>-Element

Das in der Datei machine.config enthaltene <machineKey>-Element wird dazu verwendet, die Schlüssel zu konfigurieren, die zum Verschlüsseln und Entschlüsseln von Cookiedaten und des Ansichtsstatus der Formularauthentifizierung verwendet werden.

Wenn die Methode FormsAuthentication.Encrypt oder FormsAuthentication.Decrypt aufgerufen und der Ansichtsstatus erstellt oder abgerufen wird, werden die Werte im <machineKey>-Element herangezogen.

<machineKey validationKey="autogenerate|Wert"
            decryptionKey="autogenerate|Wert"
            validation="SHA1|MD5|3DES" />
validationKey-Attribut

Der Wert für das validationKey-Attribut wird verwendet, um Message Authentication Codes (MACs oder Nachrichtenauthentifizierungscodes) für Ansichtsstatus- und Formularauthentifizierungstickets zu erstellen und zu überprüfen. Das Überprüfungsattribut kennzeichnet den für die MAC-Generierung zu verwendenden Algorithmus. Beachten Sie Folgendes:

  • Bei der Formularauthentifizierung arbeitet dieser Schlüssel in Verbindung mit dem <Formulare> protection-Attribut. Wenn das protection-Attribut den Wert Validation erhält und dann die FormsAuthentication.Encrypt-Methode aufgerufen wird, erfolgt die Berechnung eines Nachrichtenauthentifizierungscodes, der an das Cookie angehängt wird, anhand des Ticketwerts und des validationKey-Elements. Wenn die FormsAuthentication.Decrypt-Methode aufgerufen wird, wird der Nachrichtenauthentifizierungscode berechnet und mit dem Nachrichtenauthentifizierungscode verglichen, der an das Ticket angehängt ist.

  • Beim Ansichtsstatus wird der Nachrichtenauthentifizierungscode aus dem Wert vom Ansichtsstatus eines Steuerelements und aus validationKey berechnet und an den Ansichtsstatus angehängt. Wenn der Ansichtsstatus wieder vom Client zurückübermittelt wird, wird der Nachrichtenauthentifizierungscode erneut berechnet und mit dem Nachrichtenauthentifizierungscode verglichen, der an den Ansichtsstatus angehängt ist.

decryptionKey-Attribut

Der Wert für das decryptionKey-Attribut wird verwendet, um Formularauthentifizierungstickets und den Ansichtsstatus zu ver- und entschlüsseln. Dazu wird der Algorithmus DES oder Dreifach-DES (3DES) verwendet. Der genaue Algorithmus hängt davon ab, ob das Windows 2000 High Encryption Pack auf dem Server installiert ist. Wenn es installiert ist, wird 3DES verwendet, andernfalls DES. Beachten Sie Folgendes:

  • Bei der Formularauthentifizierung arbeitet der Schlüssel in Verbindung mit dem <Formulare> protection-Attribut. Wenn für das protection-Attribut der Wert Verschlüsselung festgelegt ist und die Methode FormsAuthentication.Encrypt oder Decrypt aufgerufen wird, erfolgt die Verschlüsselung oder Entschlüsselung des Ticketwerts mit dem angegebenen Wert für decryptionKey.

  • Beim Ansichtsstatus wird der Wert vom Ansichtsstatus eines Steuerelements mit dem Wert von decryptionKey verschlüsselt und an den Client gesendet. Er wird wieder entschlüsselt, wenn der Client die Daten an den Server zurückübermittelt.

Validation-Attribut

Dieses Attribut legt fest, welcher Algorithmus zum Überprüfen, Verschlüsseln oder Entschlüsseln verwendet wird. Es kann die Werte SHA1, MD5 oder 3DES annehmen. Diese Werte werden im Folgenden beschrieben:

  • SHA1 – Der Algorithmus HMACSHA1 wird verwendet, wenn die Einstellung SHA1 ausgewählt wurde. Er erzeugt einen 160-Bit-Hash (20 Byte) oder Digest der Eingabe. HMACSHA1 ist ein verschlüsselter Hashalgorithmus. Der für diesen Algorithmus als Eingabe verwendete Schlüssel wird vom validationKey-Attribut festgelegt.
    SHA1 ist ein gebräuchlicher Algorithmus, da er im Vergleich zu anderen Algorithmen einen größeren Digest verwendet.

  • MD5 – Erzeugt mit dem MD5-Algorithmus einen Hash mit einer Größe von 20 Byte.

  • 3DES – Verschlüsselt Daten mit dem Dreifach-DES-Algorithmus (3DES).

    Hinweis: Wenn das Überprüfungsattribut den Wert 3DES erhält, wird dieser Algorithmus nicht bei der Formularauthentifizierung verwendet. Stattdessen wird SHA1 verwendet.

Weitere Informationen

Zusammenfassung

In diesem Kapitel wurde eine Vielzahl von Verfahren und Ansätzen zum Sichern von ASP.NET-Webanwendungen beschrieben. Viele der in diesem Modul bereitgestellten Anleitungen und Empfehlungen gelten auch für die Entwicklung von ASP.NET-Webdiensten und .NET Remoting-Objekten, die von ASP.NET verwaltet werden. Zusammengefasst:

  • Wenn Ihre Anwendung die Formularauthentifizierung verwendet und die Leistung bei der Authentifizierung des Benutzers von Bedeutung ist, rufen Sie eine Liste mit Rollen ab und speichern diese im Authentifizierungsticket.

  • Wenn Sie die Formularauthentifizierung verwenden, erstellen Sie immer einen Prinzipal und speichern diesen im Kontext jeder Anforderung.

  • Wenn in einem Authentifizierungscookie zu viele Rollen gespeichert werden müssen, verwenden Sie den globalen Anwendungscache, um die Rollen zu speichern.

  • Verwenden Sie zum Ausführen von ASP.NET kein benutzerdefiniertes Konto mit minimalen Rechten. Ändern Sie stattdessen das Kennwort des ASPNET-Kontos und erstellen Sie auf jedem Windows-Remoteserver, auf den die Anwendung zugreifen muss, ein Duplikat des Kontos.

  • Wenn Sie ein benutzerdefiniertes Konto erstellen müssen, um ASP.NET auszuführen, verwenden Sie das Prinzip der minimalen Rechte. Beispiel:

    • Verwenden Sie ein Domänenkonto mit minimalen Rechten, wenn der Verwaltung das Hauptinteresse gilt.

    • Wenn Sie ein lokales Konto verwenden, müssen Sie auf allen Remotecomputern, auf die die Webanwendung zugreifen muss, ein Duplikat des Kontos erstellen. Sie müssen lokale Konten verwenden, wenn die Anwendung auf Ressourcen in nicht vertrauenswürdigen Domänen zugreifen muss oder wenn eine Firewall die Windows-Authentifizierung verhindert.

    • Führen Sie ASP.NET nicht unter Verwendung des lokalen Kontos SYSTEM aus.

    • Erteilen Sie dem ASPNET-Konto nicht das Recht Als Teil des Betriebssystems handeln.

  • Verwenden Sie unter den folgenden Bedingungen SSL:

    • Zwischen dem Browser und dem Webserver werden sicherheitsrelevante Daten ausgetauscht.

    • Die Standardauthentifizierung wird verwendet (zum Schützen von Anmeldeinformationen).

    • Die Formularauthentifizierung wird für die Authentifizierung verwendet (im Gegensatz zur Personalisierung).

  • Vermeiden Sie es, vertrauliche Daten unverschlüsselt zu speichern.

    • Speichern Sie keine unverschlüsselten Anmeldeinformationen in der Datei machine.config oder web.config. Verwenden Sie das Dienstprogramm aspnet_setreg.exe, um verschlüsselte Anmeldeinformationen für die Elemente <identity>, <processModel> und <sessionState> in der Registrierung zu speichern.


Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft