Modul 2 – Sicherheitsmodell für ASP.NET-Anwendungen

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 .NET-Webanwendungen
 Implementierungstechnologien
 Sicherheitsarchitektur
 Einführung in die .NET Framework-Sicherheit
 Zusammenfassung

Modulübersicht

Eine funktionelle ASP.NET-Anwendung basiert auf der erfolgreichen Zusammenarbeit zwischen unterschiedlichen Elementen und Technologien. Jede Lösungskomponente bietet Sicherheitsfunktionen, die dazu dienen, ihre eigenen Anforderungen zu erfüllen. Es reicht jedoch nicht aus, nur die Sicherheit der einzelnen Komponenten zu betrachten. Um Sicherheit für die gesamte Lösung bereitzustellen, müssen Sie auch die Interaktion der verschiedenen Komponenten berücksichtigen.

Dieses Modul enthält eine Einführung in die Architektur und Sicherheit der .NET-Webanwendung und bietet eine Grundlage, auf der die anderen Module in diesem Handbuch aufbauen. Zudem bietet es einen Überblick über die Sicherheitsfunktionen und -dienste, die die Ebenen einer gängigen .NET-Webanwendung umfassen. Ferner enthält es eine Einführung in die Sicherheit des .NET Framework und Erklärungen zu den wichtigsten Elementen für Entwickler von ASP.NET-Anwendungen.

 

Zielsetzung

Themenbereiche:

• Einblick in die Architektur von .NET-Webanwendungen und in das Konzept der logischen und physischen Anwendungsebenen

• Vermittlung der durch die einzelnen Implementierungstechnologien bereitgestellten Sicherheitsfunktionen für .NET-Webanwendungen und der Zusammenarbeit dieser Technologien

• Einführung in die Sicherheitsfunktionen des .NET Framework und in die wichtigsten Elemente für die Sicherheit von Webanwendungen

• Vergleich und Gegenüberstellung der Autorisierungs- und Authentifizierungsmechanismen, die in Ihrer Webanwendung zur Verfügung stehen

• Einführung in die Verwendung von Prinzipal- und Identity-Objekten in .NET-Webanwendungen

• Identifizieren von Gatekeepern und Gates, die verwendet werden können, um Vertrauensgrenzen in Ihrer Anwendung durchzusetzen

 

Betrifft

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

• Betriebssysteme Windows XP oder Windows 2000 Server oder höher

• Internetinformationsdienste (IIS)

• .NET Framework Version 1.0 oder höher

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

• Sie sollten über Erfahrung in der Entwicklung von ASP.NET-Webanwendungen verfügen. Dadurch können Sie besser verstehen, wo die unterschiedlichen in diesem Modul beschriebenen Sicherheitselemente in Ihre Anwendung integriert werden.

• Lesen Sie Modul 1, "Einführung". Hier wird die Bedeutung von Authentifizierung, Autorisierung und sicherer Kommunikation für die Erstellung von sicheren verteilten Webanwendungen hervorgehoben. Zudem werden die Hauptprinzipien und praktischen Vorgänge erläutert, die bei der Entwicklung von sicheren Webanwendungen zu berücksichtigen sind.

 

.NET-Webanwendungen

Dieser Abschnitt bietet eine kurze Einführung in .NET-Webanwendungen und eine Beschreibung ihrer Eigenschaften unter logischen und physischen Gesichtspunkten. Zudem enthält er eine Einführung in die unterschiedlichen Implementierungstechnologien, die für die Erstellung von .NET-Webanwendungen verwendet werden.

Logische Ebenen

In der logischen Anwendungsarchitektur werden alle Systeme als eine Reihe von zusammenarbeitenden Diensten angesehen, die in folgende Schichten eingeteilt sind:

• Benutzerdienste

• Geschäftsdienste

• Datendienste

Der Vorteil der Betrachtung dieser logischen Architektur ist die Identifizierung der generischen Diensttypen, die in jedem System vorhanden sind, um eine ordnungsgemäße Segmentierung zu gewährleisten und die Definition der Schnittstellen zwischen den Ebenen zu steuern. Mithilfe dieser Segmentierung können Sie bei der Implementierung der einzelnen Schichten sinnvollere Entscheidungen für die Architektur und den Entwurf treffen und eine Anwendung erstellen, die sich leichter warten lässt.

Die Schichten können wie folgt beschrieben werden:

• Benutzerdienste sind verantwortlich für die Interaktion zwischen den Clients und dem System und bieten eine allgemeine Brücke zur Kerngeschäftslogik, die durch Komponenten innerhalb der Geschäftsdiensteschicht eingekapselt sind. In der Regel sind Benutzerdienste interaktiven Benutzern zugeordnet. Sie führen jedoch auch die erste Verarbeitung programmatischer Anforderungen anderer Systeme aus, wobei keine sichtbare Benutzerschnittstelle beteiligt ist. Die Authentifizierung und Autorisierung werden in der Regel auf der Benutzerdiensteschicht vorgenommen. Dabei kann die genaue Art dieser Vorgänge je nach Clienttyp variieren.

• Geschäftsdienste bieten die Kernfunktionalität eines Systems und kapseln die Geschäftslogik ein. Sie sind unabhängig von Bereitstellungskanal, Back-End-Systemen oder Datenquellen. Dadurch wird die zur Entwicklung des Systems erforderliche Stabilität und Flexibilität für die Unterstützung neuer und unterschiedlicher Kanäle und Back-End-Systeme bereitgestellt. In der Regel umfasst die Verarbeitung einer bestimmten Geschäftsanforderung mehrere zusammenarbeitende Komponenten innerhalb der Geschäftsdiensteschicht.

• Datendienste bieten über generische Schnittstellen Zugriff auf Daten (deren Host sich innerhalb der Grenzen des Systems befindet) und auf andere (Back-End-)Systeme, die über Komponenten innerhalb der Geschäftsdiensteschicht leicht verwendet werden können. Datendienste dienen der Abstraktion der zahlreichen Back-End-Systeme und Datenquellen sowie der Einkapselung spezifischer Zugriffsregeln und Datenformate.

Die logische Einteilung der Diensttypen innerhalb eines Systems kann mit der möglichen physischen Verteilung der Komponenten übereinstimmen, durch die die Dienste implementiert werden, wobei sie jedoch unabhängig voneinander arbeiten.

Sie müssen berücksichtigen, dass die logischen Ebenen auf jeder Aggregationsstufe identifiziert werden können. Dies bedeutet, dass die Ebenen für das System insgesamt (im Kontext seiner Umgebung und seiner externen Interaktionen) und für alle enthaltenen Subsysteme bestimmt werden können. So besteht beispielsweise jeder Remoteknoten, der als Host für einen Webdienst fungiert, aus Benutzerdiensten (die eingehende Anforderungen und Nachrichten verarbeiten), Geschäftsdiensten und Datendiensten.

Physische Bereitstellungsmodelle

Die drei logischen Dienstschichten geben keinerlei Hinweis auf die spezielle Anzahl der physischen Ebenen. Alle drei logischen Dienste können sich physisch auf demselben Computer befinden, aber auch über mehrere Computer verteilt sein.

Der Webserver als Anwendungsserver

Ein häufig verwendetes Bereitstellungsmuster für .NET-Webanwendungen ist die Platzierung von Geschäfts- und Datenzugriffskomponenten auf dem Webserver. Dadurch werden Netzwerkhops minimiert, um die Leistung zu steigern. Dieses Modell ist in Abbildung 2.1 dargestellt.

Abbildung 2.1
Der Webserver als Anwendungsserver

Remote-Anwendungsebene

Bei der Remote-Anwendungsebene handelt es sich um ein häufig verwendetes Bereitstellungsmuster, insbesondere für Internetszenarios, in denen die Webebene sich innerhalb eines Perimeternetzwerks (auch als Demilitarized Zones (DMZ), also "demilitarisierte Zonen" oder überwachte Subnetze bezeichnet) befindet und von den Endbenutzern und der Remote-Anwendungsebene durch Firewalls für die Paketfilterung getrennt ist. Die Remote-Anwendungsebene wird in Abbildung 2.2 dargestellt.

Abbildung 2.2
Die Einführung einer Remote-Anwendungsebene

 

Implementierungstechnologien

Durch .NET-Webanwendungen werden in der Regel ein oder mehrere logische Dienste mithilfe der folgenden Technologien implementiert:

• ASP.NET
  ASP.NET wird normalerweise für die Implementierung der Benutzerdienste verwendet. ASP.NET bietet eine austauschbare Architektur, die für die Erstellung von Webseiten verwendet werden kann. Die ASP.NET-Sicherheit wird in Modul 8, "ASP.NET-Sicherheit", genauer beschrieben.

• Enterprise Services
  Enterprise Services stellen Anwendungen Dienste auf Infrastrukturebene bereit. Dazu zählen verteilte Transaktionen und Ressourcenverwaltungsdienste wie Objektpooling für .NET-Komponenten. Die Enterprise Services-Sicherheit wird in Modul 9, "Enterprise Services-Sicherheit", genauer beschrieben.

• Webdienste
  Webdienste ermöglichen den Datenaustausch und den Remoteaufruf von Anwendungslogik mithilfe SOAP-basierter Nachrichtenaustauschvorgänge, um Daten durch Firewalls und zwischen heterogenen Systemen zu übertragen. Die Sicherheit von Webdiensten wird in Modul 10, "Webdienstesicherheit", genauer beschrieben.

• .NET Remoting
  .NET Remoting bietet ein Framework für den Zugriff auf verteilte Objekte über Prozess- und Computergrenzen hinweg. Die NET Remoting-Sicherheit wird in Modul 11, "NET Remoting-Sicherheit", genauer beschrieben.

• ADO.NET and Microsoft® SQL Server™ 2000
  ADO.NET stellt Datenzugriffsdienste bereit. Es wurde von Grund auf für verteilte Webanwendungen entwickelt und unterstützt getrennte Szenarios, die Webanwendungen zugeordnet sind. SQL Server stellt eine integrierte Sicherheit bereit, bei der die Authentifizierungsmechanismen des Betriebssystems (Kerberos oder NTLM) verwendet werden. Die Autorisierung erfolgt über Anmeldungen und differenzierte Berechtigungen, die auf einzelne Datenbankobjekte angewendet werden können. Die Datenzugriffssicherheit wird in Modul 12, "Datenzugriffssicherheit", genauer beschrieben.

• IPSec
  IPSec bietet Point-to-Point-Verschlüsselung auf Transportebene und Authentifizierungsdienste. Weitere Informationen zu IPSec erhalten Sie in Modul 4, "Sichere Kommunikation".

• SSL
  SSL bietet einen sicheren Kanal für die Point-to-Point-Kommunikation. Daten, die über den Kanal gesendet werden, sind verschlüsselt. Weitere Informationen zu SSL erhalten Sie in Modul 4, "Sichere Kommunikation".

 

Sicherheitsarchitektur

In Abbildung 2.3 ist das Modell der Remote-Anwendungsebenen zusammen mit den Sicherheitsdiensten dargestellt, die durch die oben beschriebenen Technologien bereitgestellt werden. Die Authentifizierung und Autorisierung erfolgt an mehreren einzelnen Punkten auf diesen Ebenen. Diese Dienste werden hauptsächlich durch Internetinformationsdienste (IIS), ASP.NET, Enterprise Services und SQL Server bereitgestellt. Zudem werden sichere Kommunikationskanäle ebenenübergreifend angewendet. Sie erstrecken sich vom Clientbrowser oder -gerät bis hin zur Datenbank. Die Kanäle werden durch eine Kombination aus SSL und IPSec gesichert.

Abbildung 2.3
Sicherheitsarchitektur

Ebenenübergreifende Sicherheit

Die Funktionen der Authentifizierung, Autorisierung und sicheren Kommunikation werden in Tabelle 2.1 zusammengefasst.

Tabelle 2.1: Sicherheitsfunktionen

Technologie	Authentifizierung	Autorisierung	Sichere Kommunikation
IIS	Anonyme Basis- Digest- integrierte Windows- (Kerberos/NTLM-)Zertifikate	IP/DNS-Adress- einschränkungen Webberechtigungen NTFS-Berechtigungen; Windows-Zugriffs- steuerungslisten (ACLs) für angeforderte Dateien	SSL
ASP.NET	Keine (benutzerdefiniert) Windows Formulare Passport	Dateiautorisierung URL-Autorisierung Hauptberechtigungen .NET-Rollen
Webdienste	Windows Keine (benutzerdefiniert) Authentifizierung auf Nachrichtenebene	Dateiautorisierung URL-Autorisierung Hauptberechtigungen .NET-Rollen	Verschlüsselung auf SSL- und Nachrichtenebene
Remoting	Windows	Dateiautorisierung URL-Autorisierung Hauptberechtigungen .NET-Rollen	Verschlüsselung auf SSL- und Nachrichtenebene
Enterprise Services	Windows	Enterprise Services- (COM+-)Rollen NTFS-Berechtigungen	Verschlüsselung durch Remote Procedure Call (RPC oder Remoteprozeduraufruf)
SQL Server 2000	Windows- (Kerberos/NTLM-) SQL-Authentifizierung	Serveranmeldungen Datenbankanmeldungen Feste Datenbankrollen Benutzerdefinierte Rollen Anwendungsrollen Objektberechtigungen	SSL
Windows 2000	Kerberos NTLM	Windows-ACLs	IPSec

Authentifizierung

.NET Framework unter Windows 2000 bietet die folgenden Authentifizierungsoptionen:

• ASP.NET-Authentifizierungsmodi

• Enterprise Services-Authentifizierung

• SQL Server-Authentifizierung

ASP.NET-Authentifizierungsmodi

Die ASP.NET-Authentifizierungsmodi umfassen Windows, Formulare, Passport und keine.

• Windows-Authentifizierung. Bei diesem Authentifizierungsmodus setzt ASP.NET auf IIS, um Benutzer zu authentifizieren und ein Windows-Zugriffstoken zu erstellen, um die authentifizierte Identität darzustellen. IIS stellt folgende Authentifizierungsmechanismen bereit:

  • Standardauthentifizierung. Bei der Standardauthentifizierung muss der Benutzer die Anmeldeinformationen in Form eines Benutzernamens und eines Kennworts angeben, um seine Identität nachzuweisen. Hierbei handelt es sich um einen empfohlenen, auf RFC 2617 basierenden Internetstandard: http://www.faqs.org/rfcs/rfc2617.html. Die Standardauthentifizierung wird sowohl in Netscape Navigator als auch in Microsoft Internet Explorer unterstützt. Die Benutzeranmeldeinformationen werden im nicht verschlüsselten Base64-codierten Format vom Browser an den Webserver übertragen. Da der Webserver die Benutzeranmeldeinformationen im unverschlüsselten Format erhält, kann er mit diesen Anmeldeinformationen Remoteaufrufe ausgeben (z. B. um auf Remotecomputer und -ressourcen zuzugreifen).

    Hinweis: Die Standardauthentifizierung sollten Sie ausschließlich in Verbindung mit einem sicheren Kanal (wird in der Regel über SSL eingerichtet) verwenden. Anderenfalls lassen sich Benutzernamen und Kennwörter illegal mithilfe von Netzwerküberwachungssoftware abrufen. Falls Sie die Standardauthentifizierung verwenden, sollten Sie auf allen Seiten (nicht nur auf der Anmeldeseite) SSL verwenden, da die Anmeldeinformationen bei nachfolgenden Anforderungen weitergeleitet werden. Weitere Informationen zur Verwendung der Standardauthentifizierung mit SSL finden Sie in Modul 8, "ASP.NET-Sicherheit".

  • Digestauthentifizierung. Die mit IIS 5.0 eingeführte Digestauthentifizierung ähnelt der Standardauthentifizierung mit dem Unterschied, dass anstelle der Benutzeranmeldeinformationen in unverschlüsselter Form ein Hashwert der Anmeldeinformationen vom Browser an den Webserver übertragen wird. Daher ist diese Art der Authentifizierung sicherer, wobei ein Client mit Internet Explorer 5.0 oder höher und eine spezifische Serverkonfiguration erforderlich sind.

  • Integrierte Windows-Authentifizierung. Bei der integrierten Windows-Authentifizierung (Kerberos oder NTLM, je nach Client und Serverkonfiguration) erfolgt ein kryptografischer Austausch mit dem Internet Explorer des Benutzers, um dessen Identität nachzuweisen. Diese Funktion wird nur in Internet Explorer (und nicht in Netscape Navigator) unterstützt und daher eher in Intranetszenarios verwendet, in denen die Clientsoftware gesteuert werden kann. Sie wird nur vom Webserver verwendet, wenn entweder der anonyme Zugriff deaktiviert ist oder über Dateisystemberechtigungen in Windows verweigert wird.

  • Zertifikatsauthentifizierung. Bei der Zertifikatsauthentifizierung werden Clientzertifikate für die positive Identifikation von Benutzern verwendet. Das Clientzertifikat wird vom Browser des Benutzers (oder von der Clientanwendung) an den Webserver weitergeleitet. (Im Fall von Webdiensten wird das Zertifikat durch den Webdienstclient über die Eigenschaft ClientCertificates des Objekts HttpWebRequest weitergeleitet.) Anschließend extrahiert der Webserver die Identität des Benutzers aus dem Zertifikat. Dieser Ansatz rechnet mit der Installation eines Clientzertifikats auf dem Computer des Benutzers. Daher wird er meistens in Intranet- oder Extranetszenarios verwendet, in denen die Anzahl der Benutzer bekannt ist und leicht gesteuert werden kann. Nach dem Empfang eines Clientzertifikats kann IIS das Zertifikat einem Windows-Konto zuordnen.

  • Anonyme Authentifizierung. Wenn Sie Ihre Clients nicht authentifizieren müssen (oder ein benutzerdefiniertes Authentifizierungsschema implementieren), kann IIS für die anonyme Authentifizierung konfiguriert werden. In diesem Fall erstellt der Webserver ein Windows-Zugriffstoken, um alle anonymen Benutzer mit demselben anonymen Konto (oder Gastkonto) darzustellen. Das anonyme Standardkonto lautet IUSR_MACHINENAME, wobei MACHINENAME der NetBIOS-Name Ihres Computers ist, der zum Zeitpunkt der Installation angegeben wurde.

• Passport-Authentifizierung. In diesem Authentifizierungsmodus verwendet ASP.NET die zentralisierten Authentifizierungsdienste von Microsoft Passport. ASP.NET bietet einen geeigneten Wrapper für die Funktionalitäten, die von Microsoft Passport Software Development Kit (SDK) bereitgestellt werden und auf dem Webserver installiert werden müssen.

• Formularauthentifizierung. Bei diesem Ansatz wird die clientseitige Umleitung verwendet, um nicht authentifizierte Benutzer zu einem angegebenen HTML-Formular weiterzuleiten, in das sie ihre Anmeldeinformationen (in der Regel Benutzername und Kennwort) eingeben können. Diese Anmeldeinformationen werden geprüft, ein Authentifizierungsticket wird erstellt und an den Client zurückgesandt. Das Authentifizierungsticket enthält die Benutzeridentität und optional eine Liste von Rollen, denen der Benutzer während der Benutzersitzung angehört.
  Die Formularauthentifizierung wird teilweise ausschließlich für die Personalisierung von Websites verwendet. In diesem Fall müssen Sie nur wenig benutzerdefinierten Code schreiben, da ASP.NET den Prozess hauptsächlich automatisch mit einer einfachen Konfiguration verarbeitet. Für Personalisierungsszenarios muss das Cookie nur den Benutzernamen enthalten.

  Hinweis: Bei der Formularauthentifizierung werden der Benutzername und das Kennwort als unverschlüsselter Text an den Webserver gesendet. Daher sollten Sie die Formularauthentifizierung in Verbindung mit einem durch SSL gesicherten Kanal verwenden. Um den weiteren Schutz des Authentifizierungscookies bei der Übertragung bei nachfolgenden Anforderungen zu gewährleisten, sollten Sie SSL für alle Seiten innerhalb Ihrer Anwendung und nicht nur für die Anmeldeseite verwenden.

• Keine. "Keine" deutet darauf hin, dass Sie entweder keine Authentifizierung von Benutzern vornehmen möchten oder dass Sie ein benutzerdefiniertes Authentifizierungsprotokoll verwenden.

Weitere Informationen

Weitere Informationen zur ASP.NET-Authentifizierung finden Sie in Modul 8, "ASP.NET-Sicherheit".

Enterprise Services-Authentifizierung

Die Enterprise Services-Authentifizierung wird anhand der Transportinfrastruktur des zugrunde liegenden Remoteprozeduraufrufs (RPC) ausgeführt, der wiederum SSPI verwendet. Clients der Enterprise Services-Anwendungen können mithilfe der Kerberos- oder NTLM-Authentifizierung authentifiziert werden.

Als Host für eine Serviced Component kann eine Bibliotheksanwendung oder eine Serveranwendung fungieren. Da Clientprozesse als Host für Bibliotheksanwendungen fungieren, übernehmen sie die Identität des Clients. Serveranwendungen werden mit eigener Identität in separaten Serverprozessen ausgeführt. Weitere Informationen zur Identität erhalten Sie im Abschnitt "Identitäten und Prinzipale" weiter unten in diesem Modul.

Die eingehenden Aufrufe für eine Serviced Component können auf folgenden Ebenen authentifiziert werden:

• Standard: Die Standardauthentifizierungsebene für das Sicherheitspaket wird verwendet.

• Keine: Es findet keine Authentifizierung statt.

• Verbinden: Die Authentifizierung erfolgt nur dann, wenn eine Verbindung hergestellt wird.

• Aufruf: Die Authentifizierung erfolgt zu Beginn jedes Remoteprozeduraufrufs.

• Paket: Authentifiziert und prüft, ob alle Aufrufdaten empfangen wurden.

• Paketintegrität: Authentifiziert und stellt sicher, dass keine Daten bei der Übertragung geändert wurden.

• Paketdatensicherheit: Authentifiziert und verschlüsselt das Paket einschließlich der Daten, der Identität und der Signatur des Absenders.

Weitere Informationen

Weitere Informationen zur Enterprise Services-Authentifizierung finden Sie in Modul 9, "Enterprise Services-Sicherheit".

SQL Server-Authentifizierung

SQL Server kann Benutzer unter Verwendung der Windows-Authentifizierung (NTLM oder Kerberos) authentifizieren oder das eigene integrierte Authentifizierungsschema verwenden, auch SQL-Authentifizierung genannt. Die folgenden Optionen sind verfügbar:

• SQL Server und Windows. Clients können eine Verbindung zu einer Instanz von Microsoft SQL Server herstellen, indem sie entweder die SQL Server-Authentifizierung oder die Windows-Authentifizierung verwenden. Dies wird gelegentlich auch als Authentifizierung im gemischten Modus bezeichnet.

• Nur Windows. Der Benutzer muss eine Verbindung zur Instanz des Microsoft SQL-Servers über die Windows-Authentifizierung herstellen.

Weitere Informationen

Die Vorzüge der einzelnen Ansätze werden in Modul 12, "Datenzugriffssicherheit", näher beschrieben.

Autorisierung

Das .NET Framework bietet unter Windows 2000 die folgenden Autorisierungsoptionen:

• ASP.NET-Autorisierungsoptionen

• Enterprise Services-Autorisierung

• SQL Server-Autorisierung

ASP.NET-Autorisierungsoptionen

Die ASP.NET-Autorisierungsoptionen können von ASP.NET-Webanwendungen, Webdiensten und Remotekomponenten verwendet werden. ASP.NET bietet die folgenden Autorisierungsoptionen:

• URL-Autorisierung. Hierbei handelt es sich um einen Autorisierungsmechanismus, der durch die Einstellungen in Computer- und Anwendungskonfigurationsdateien konfiguriert wird. Mit der URL-Autorisierung können Sie den Zugriff auf spezielle Dateien und Ordner innerhalb des URL-Namespace Ihrer Anwendung beschränken. Sie können den Zugriff auf spezielle Dateien oder Ordner (die durch eine URL adressiert werden) beispielsweise für nominierte Benutzer selektiv verweigern oder gewähren. Darüber hinaus haben Sie die Möglichkeit, den Zugriff anhand der Rollenmitgliedschaft des Benutzers und des Typs des HTTP-Verbs einzuschränken, das verwendet wurde, um eine Anforderung auszugeben (GET, POST usw.).
  Für die URL-Autorisierung ist eine authentifizierte Identität erforderlich. Diese kann über ein Windows- oder ticketbasiertes Authentifizierungsschema abgerufen werden.

• Dateiautorisierung. Die Dateiautorisierung gilt nur, wenn Sie einen der von IIS bereitgestellten Windows-Authentifizierungsmechanismen verwenden, um Aufrufer zu authentifizieren, und wenn ASP.NET für die Windows-Authentifizierung konfiguriert ist.
  Sie kann verwendet werden, um den Zugriff auf bestimmte Dateien auf einem Webserver einzuschränken. Zugriffsberechtigungen werden durch die an die Dateien angefügten Windows-ACLs bestimmt.

• Hauptberechtigungen erforderlich. Erforderliche Hauptberechtigungen sind (deklarativ oder programmatisch) als zusätzlicher feinabgestimmter Mechanismus für die Zugriffssteuerung zu nutzen. Dadurch können Sie den Zugriff auf Klassen, Methoden oder einzelne Codeblöcke anhand der Identität und Gruppenmitgliedschaft einzelner Benutzer steuern.

• .NET-Rollen. .NET-Rollen werden verwendet, um Benutzer, die innerhalb Ihrer Anwendung über dieselben Berechtigungen verfügen, in einer Gruppe anzuordnen. Ihr Konzept ähnelt den vorherigen rollenbasierten Implementierungen, beispielsweise Windows-Gruppen und COM+-Rollen. Im Gegensatz zu diesen Ansätzen sind für .NET-Rollen jedoch keine authentifizierten Windows-Identitäten erforderlich, sie können zusammen mit ticketbasierten Authentifizierungsschemata, wie der Formularauthentifizierung, verwendet werden.
  .NET-Rollen können verwendet werden, um den Zugriff auf Ressourcen und Operationen zu steuern. Sie können sowohl deklarativ als auch programmatisch konfiguriert werden.

Weitere Informationen

Weitere Informationen zur ASP.NET-Autorisierung finden Sie in Modul 8, "ASP.NET-Sicherheit".

Enterprise Services-Autorisierung

Der Zugriff auf Funktionalitäten innerhalb der Serviced Components in Enterprise Services-Anwendungen wird durch die Enterprise Services-Rollenmitgliedschaft gesteuert. Diese unterscheidet sich von .NET-Rollen und kann Windows-Gruppen oder Benutzerkonten enthalten. Die Rollenmitgliedschaft ist im COM+-Katalog definiert und wird mithilfe des Tools für Komponentendienste verwaltet.

Weitere Informationen

Weitere Informationen zur Enterprise Services-Autorisierung finden Sie in Modul 9, "Enterprise Services-Sicherheit".

SQL Server-Autorisierung

Mit SQL Server können Sie differenzierte Berechtigungen für einzelne Datenbankobjekte anwenden. Berechtigungen können auf Rollenmitgliedschaften basieren (SQL Server bietet feste Datenbankrollen, benutzerdefinierte Rollen und Anwendungsrollen) oder einzelnen Windows-Benutzern bzw. Gruppenkonten gewährt werden.

Weitere Informationen

Weitere Informationen zur SQL Server-Autorisierung finden Sie in Modul 12, "Datenzugriffssicherheit".

Gatekeeper und Gates

In den nachfolgenden Abschnitten dieses Handbuches wird der Ausdruck Gatekeeper verwendet, um die Technologie zu identifizieren, die für ein Gate verantwortlich ist. Ein Gate stellt den Zugriffssteuerungspunkt (zum Schutz einer Ressource) innerhalb einer Anwendung dar. Bei einer Ressource kann es sich beispielsweise um eine Operation (dargestellt durch eine Methode oder ein Objekt) oder um eine Datenbank- oder Dateisystemressource handeln.

Alle oben aufgelisteten Kerntechnologien stellen Gatekeeper für die Zugriffsautorisierung dar. Anforderungen müssen eine Reihe von Gates passieren, bevor ihnen der Zugriff auf die angeforderte Ressource oder Operation gewährt wird. Im Folgenden werden die Gates beschrieben, die die Anforderungen passieren müssen:

• IIS stellt ein Gate bereit, wenn Sie Benutzer authentifizieren (das heißt, wenn Sie die anonyme Authentifizierung deaktivieren). IIS-Webberechtigungen können als Zugriffssteuerungsmechanismus verwendet werden, um die Möglichkeit des Zugriffs auf bestimmte Dateien und Ordner für Webbenutzer einzuschränken. Im Gegensatz zu NTFS-Dateiberechtigungen gelten Webberechtigungen für alle Webbenutzer und nicht für einzelne Benutzer oder Gruppen. NTFS-Dateiberechtigungen bieten weitere Einschränkungen für Webressourcen wie Webseiten, Bilder, Dateien usw. Diese Einschränkungen gelten für einzelne Benutzer oder Gruppen.
  IIS überprüft die Webberechtigungen und anschließend die NTFS-Dateiberechtigungen. Ein Benutzer muss durch beide Mechanismen autorisiert werden, damit er auf die betreffende Datei oder auf den betreffenden Ordner zugreifen kann. Bei einer fehlgeschlagenen Überprüfung der Webberechtigungen gibt IIS die Meldung "HTTP 403 – Zugriff verboten" aus, wobei IIS bei einer fehlerhaften Überprüfung der NTFS-Berechtigungen die Meldung "HTTP 401 – Zugriff verweigert" ausgibt.

• ASP.NET bietet unterschiedliche konfigurierbare und programmatische Gates. Dazu zählen die URL-Autorisierung, die Dateiautorisierung, die erforderlichen Hauptberechtigungen und .NET-Rollen.

• Der Enterprise Services-Gatekeeper verwendet Enterprise Services-Rollen für die Autorisierung des Zugriffs auf Geschäftsfunktionalitäten.

• SQL Server 2000 enthält eine Reihe von Gates, zu denen Serveranmeldungen, Datenbankanmeldungen und Datenbankobjektberechtigungen zählen.

• Windows 2000 stellt Gates bereit, bei denen angefügte ACLs zum Sichern von Ressourcen verwendet werden.

Im Endeffekt führen Gatekeeper die Autorisierung anhand der Identität des Benutzers oder Dienstes aus, der einen Aufruf an das Gate richtet und versucht, auf bestimmte Ressourcen zuzugreifen. Der Vorteil mehrerer Gates ist die vertiefte Sicherheit durch mehrere Verteidigungslinien. In Tabelle 2.2 werden die Gatekeeper zusammengefasst und ihre jeweiligen Gates angegeben, für die sie verantwortlich sind.

Tabelle 2.2: Verantwortlichkeiten der Gatekeeper und die dadurch bereitgestellten Gates

Gatekeeper	Gates
Windows-Betriebssystem	Anmelderechte (positive und negative, z. B. "Lokale Anmeldung verweigern") Andere Rechte (z. B. "Als Teil des Betriebssystems handeln") Zugriffsprüfung für gesicherte Ressourcen wie die Registrierung und das Dateisystem. Bei Zugriffsprüfungen werden an die sicheren Ressourcen angefügte ACLs verwendet, in denen angegeben ist, welche Personen berechtigt sind, auf die Ressource zuzugreifen, und welche Art von Operationen ausgeführt werden dürfen. TCP/IP-Filterung IP-Sicherheit
IIS	Authentifizierung (Anonym, Standard, Digest, Integriert, Zertifikat) IP-Adress-und Domänennameneinschränkungen (können zur zusätzlichen Verteidigung verwendet werden, Sie sollten jedoch nicht vollständig darauf vertrauen, da das Spoofing von IP-Adressen relativ leicht ist). Webberechtigungen NTFS-Berechtigungen
ASP.NET	URL-Autorisierung Dateiautorisierung Hauptberechtigungen .NET-Rollen
Enterprise Services	Windows-Authentifizierung (NTLM/Kerberos) Enterprise Services- (COM+-)Rollen Identitätswechselstufen
Webdienste	Verwendet die von IIS und ASP.NET bereitgestellten Gates
Remoting	Verwendet vom Host bereitgestellte Gates. Wenn ASP.NET als Host fungiert, werden die durch IIS und ASP.NET bereitgestellten Gates verwendet. Wenn ein Windows-Dienst als Host fungiert, müssen Sie eine benutzerdefinierte Lösung entwickeln.
ADO.NET	Verbindungszeichenfolgen. Die Anmeldeinformationen können explizit sein, oder Sie können die Windows-Authentifizierung verwenden (wenn Sie beispielsweise eine Verbindung zu SQL Server herstellen).
SQL Server	Serveranmeldungen Datenbankanmeldungen Datenbankobjektberechtigungen

Durch die Verwendung unterschiedlicher Gates auf den Ebenen Ihrer Anwendungen können Sie Benutzer herausfiltern, denen der Zugriff auf Ihre Back-End-Ressourcen gewährt werden soll. Der Umfang des Zugriffs wird durch aufeinander folgende Gates eingeschränkt, die mit Fortschreiten der Anforderungen durch die Anwendung bis hin zu den Back-End-Ressourcen immer feiner werden.

Berücksichtigen Sie das Beispiel für eine internetbasierte Anwendung mit IIS, das in Abbildung 2.4 dargestellt wird.

Abbildung 2.4
Filtern von Benutzern mit Gatekeepern

In Abbildung 2.4 wird Folgendes dargestellt:

• Sie können die anonyme Authentifizierung in IIS deaktivieren. Dann wird nur Konten, die IIS authentifizieren kann, der Zugriff gewährt. Dadurch wird die potenzielle Anzahl der Benutzer auf 10.000 reduziert.

• Als Nächstes verwenden Sie in ASP.NET die URL-Autorisierung, durch die das Benutzerkonto auf 1.000 Benutzer beschränkt werden kann.

• Durch die Dateiautorisierung kann der Zugriff noch weiter auf bis zu 100 Benutzer eingeschränkt werden.

• Schließlich kann der Code Ihrer Webanwendung nur 10 Benutzern den Zugriff auf die eingeschränkten Ressourcen anhand einer spezifischen Rollenmitgliedschaft gewähren.

 

Einführung in die .NET Framework-Sicherheit

Die .Net Framework-Sicherheit ist eine Stufe oberhalb der Windows-Sicherheit angesiedelt. Diese wird dadurch jedoch in keiner Weise ersetzt, Sie erhalten lediglich zusätzliche Sicherheitsfunktionen. Der Erfolg oder Misserfolg des Ressourcenzugriffs durch Ihre .NET-Anwendungen wird letztendlich durch die Betriebssystemsicherheit bestimmt.

Wenn beispielsweise versucht wird, über eine ASP.NET-Webanwendung eine Datei zu öffnen, unterliegt der Zugriffsversuch den Windows-ACLs, die der Datei zugeordnet sind. Die für den Zugriff auf Ressourcen verwendete Identität ist entweder die Prozessidentität der ASP.NET-Anwendung oder die Wechselidentität der Anwendung, falls die Anwendung aktuell einen Identitätswechsel vornimmt.

Codezugriffssicherheit

.NET Framework bietet einen zusätzlichen Sicherheitsmechanismus, der auch als Codezugriffssicherheit (Code Access Security, CAS) bezeichnet wird. Die herkömmliche Sicherheit, wie beispielsweise die unter Windows bereitgestellte, ist Prinzipal-orientiert, und die Autorisierungsentscheidungen basieren auf der Identität eines authentifizierten Prinzipals, beispielsweise des Benutzers, der den Code ausführt, oder des Benutzers, der bei einer Webanwendung angemeldet ist.

CAS fügt der Sicherheit eine weitere Stufe hinzu, da die Autorisierungsentscheidungen unterstützt werden, die auf der Identität des Codes basieren und nicht auf der des Benutzers, der den Code ausführt. Dies ist besonders wichtig für mobile Codes wie Steuerelemente und Anwendungen, die über Internet Explorer aus dem Internet heruntergeladen werden. Möchten Sie wirklich, dass ein solcher Code über Administratorrechte verfügt, nur weil Sie möglicherweise bei Ihrem Computer als Administrator angemeldet sind? – Wenn Ihnen die Integrität und Sicherheit Ihres Computers wichtig sind, bestimmt nicht.

Beweis- und Sicherheitsrichtlinie

Der Code wird authentifiziert und seine Identität anhand von Attributen des Codes bestimmt, der auch als Beweis bezeichnet wird. Der Beweis kann einen öffentlichen Schlüssel einer Assembly enthalten, der Bestandteil des zugehörigen starken Namens, des Download-URLs, des installierten Anwendungsverzeichnisses usw. ist. Sobald die Codeidentität erstellt wurde, wird der gesammelte Beweis über die Sicherheitsrichtlinie weitergeleitet, durch die die Möglichkeiten des Codes und dessen Berechtigungen für den Zugriff auf sichere Ressourcen letztendlich gesteuert werden.

Die Standardrichtlinie stellt sicher, dass alle auf einem lokalen Computer installierten Codes vollkommen vertrauenswürdig sind, und gewährt uneingeschränkte Zugriffsberechtigungen auf sichere Ressourcen. So unterliegt jeglicher Ressourcenzugriff lediglich der Betriebssystemsicherheit. Der auf dem lokalen Computer installierte Code gilt als vollkommen vertrauenswürdig, da bei der Installation der Software zunächst eine bewusste Entscheidung durch einen Administrator getroffen werden muss.

CAS- und ASP.NET-Webanwendungen

ASP.NET-Webanwendungen werden auf dem lokalen Webserver installiert. Aus diesem Grund werden die Webanwendungen durch die Standardrichtlinie auf dem Server als vollständig vertrauenswürdig eingestuft. Dies bedeutet für die Entwickler der serverseitigen Webanwendung, dass die Verwendung der CAS eingeschränkt ist. ASP.NET-Webanwendungen, die auf der ersten Version von .NET Framework basieren, müssen als vollständig vertrauenswürdige Anwendungen ausgeführt werden.

Hinweis: Version 1.1 von .NET Framework unterstützt Webanwendungen, denen teilweise vertraut wird. Dadurch wird die CAS für serverseitige Webanwendungen aktiviert. Der wichtigste hierdurch entstehende Vorteil ist, dass die Isolation von Anwendungen untereinander und von wichtigen Systemressourcen einfacher wird. Dies ist ein wichtiger Faktor für Internet Service Provider (ISPs oder Internetdienstanbieter) und Application Service Provider (ASPs oder Anwendungsdienstanbieter), die als Hosts für mehrere, von unterschiedlichen Unternehmen entwickelte Webanwendungen fungieren.

Prinzipale und Identitäten

Während bei der CAS der Code im Mittelpunkt steht, stehen bei anderen Aspekten der .NET Framework-Sicherheit Prinzipale im Mittelpunkt. Dieser Prinzipal-basierte Aspekt der .NET Framework-Sicherheit spielt eine wichtige Rolle bei der ASP.NET-Anwendungssicherheit.

Das benutzerbasierte Konzept der Windows-Sicherheit beruht auf dem durch eine Anmeldesitzung bereitgestellten Sicherheitskontext, wobei die .NET-Sicherheit auf Prinzipal- und Identity-Objekten basiert.

Bei der herkömmlichen Windows-Programmierung wird die Identität des Prozesseigentümers oder des aktuell ausgeführten Threads herangezogen, wenn Sie den Sicherheitskontext herausfinden möchten, in dem der Code ausgeführt wird. Bei der .NET-Programmierung rufen Sie das aktuelle Prinzipal-Objekt ab, das dem aktuellen Thread zugeordnet ist und über Thread.CurrentPrincipal aufgerufen wird, wenn Sie den Sicherheitskontext des aktuellen Benutzers abfragen möchten.

Im .NET Framework werden Prinzipal-Objekte verwendet, die Identity-Objekte enthalten, um Benutzer bei der Ausführung des .NET-Codes darzustellen. Zusammen bilden sie den Backbone für die rollenbasierte .NET-Autorisierung. In ASP.NET-Webanwendungen wird der authentifizierte Benutzer durch ein Prinzipal- und ein Identity-Objekt dargestellt, die an den aktuellen Tread und an die Webanforderung angefügt sind.

Die Schnittstellen IPrincipal und IIdentity

Identity- und Prinzipalobjekte müssen die Schnittstellen IIdentity bzw. IPrincipal implementieren. Diese Schnittstellen sind innerhalb des Namespace System.Security.Principal definiert. Allgemeine Schnittstellen ermöglichen es dem .NET Framework, Identity- und Prinzipalobjekte unabhängig von den zugrunde liegenden Implementierungsdetails auf polymorphe Weise zu behandeln.

Mithilfe der IPrincipal-Schnittstellen können Sie die Rollenmitgliedschaft über eine IsInRole-Methode testen. Zudem bietet sie Zugriff auf das zugehörige IIdentity-Objekt.

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

Die IIdentity-Schnittstelle bietet zusätzliche Authentifizierungdetails, wie den Namen und den Authentifizierungstyp.

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

.NET Framework stellt konkrete Implementierungen von IPrincipal und IIdentity bereit, wie in Abbildung 2.5 dargestellt und in den folgenden Abschnitten beschrieben.

Abbildung 2.5
Implementierungsklassen für IPrincipal und IIdentity

WindowsPrincipal und WindowsIdentity

Die .NET-Version eines Windows-Sicherheitskontexts ist in zwei Klassen eingeteilt:

• WindowsPrincipal. In dieser Klasse werden die dem aktuellen Windows-Benutzer zugeordneten Rollen gespeichert. Bei der WindowsPrincipal-Implementierung werden Windows-Gruppen als Rollen behandelt. Die IPrincipal.IsInRole-Methode gibt entweder "true" oder "false" entsprechend der Gruppenmitgliedschaft des Benutzers aus.

• WindowsIdentity. Diese Klasse enthält den Identitätsteil des Sicherheitskontexts des aktuellen Benutzers und kann über die statische WindowsIdentity.GetCurrent() -Methode abgerufen werden. Dadurch wird ein WindowsIdentity-Objekt zurückgegeben, das über eine Token-Eigenschaft verfügt, durch die ein IntPtr ausgegeben wird, welches ein Windows-Handle für den Zugriff auf das dem aktuell ausgeführten Thread zugeordnete Token darstellt. Dieses Token kann anschließend an die Funktionen der systemeigenen Win32®-Anwendungsprogrammierungsschnittstelle (API) wie GetTokenInformation, SetTokenInformation, CheckTokenMembership usw. weitergeleitet werden, um die Sicherheitsinformationen für das Token abzurufen.

  Hinweis: Die statische WindowsIdentity.GetCurrent()-Methode gibt die Identität des aktuellen ausgeführten Threads zurück, der gegebenenfalls einen Identitätswechsel vornimmt. Dies ähnelt der Win32-API GetUserName.

"GenericPrincipal" und zugeordnete "Identity"-Objekte

Diese Implementierungen sind ganz einfach und werden von Anwendungen verwendet, die keine Windows-Authentifizierung vornehmen und für die keine komplexen Darstellungen eines Prinzipals erforderlich sind. Sie können im Code ganz einfach erstellt werden. Daher muss ein bestimmter Vertrauensgrad vorhanden sein, wenn eine Anwendung ein GenericPrincipal verarbeitet.

Wenn Sie sich auf die IsInRole-Methode für das GenericPrincipalverlassen, um Autorisierungsentscheidungen zu treffen, müssen Sie der Anwendung vertrauen, die Ihnen das GenericPrincipal sendet. Dies stellt einen Gegensatz zu WindowsPrincipal -Objekten dar, bei denen Sie darauf vertrauen müssen, dass das Betriebssystem ein gültiges WindowsPrincipal-Objekt mit einer authentifizierten Identität und gültigen Gruppen-/Rollennamen bereitstellt.

Die folgenden Arten von Identity-Objekten können der GenericPrincipal-Klasse zugeordnet werden:

• FormsIdentity. Diese Klasse stellt eine Identität dar, die über die Formularauthentifizierung authentifiziert wurde. Sie enthält ein FormsAuthenticationTicket, das Informationen zur Authentifizierungssitzung des Benutzers enthält.

• PassportIdentity. Diese Klasse stellt eine Identität dar, die über die Passport-Authentifizierung authentifiziert wurde. Sie enthält Informationen zum Passport-Profil.

• GenericIdentity. Diese Klasse stellt einen logischen Benutzer dar, der nicht an eine bestimmte Betriebssystemtechnologie gebunden ist und in der Regel in Verbindung mit benutzerdefinierten Authentifizierungs- und Autorisierungsmechanismen verwendet wird.

ASP.NET und HttpContext.User

In der Regel wird Thread.CurrentPrincipal im .NET-Code überprüft, bevor über die Autorisierung entschieden wird. ASP.NET stellt jedoch den Sicherheitskontext des authentifizierten Benutzers durch HttpContext.User bereit.

Diese Eigenschaft akzeptiert und gibt eine IPrincipal-Schnittstelle zurück. Die Eigenschaft enthält einen authentifizierten Benutzer für die aktuelle Anforderung. ASP.NET ruft HttpContext.User auf, wenn Autorisierungsentscheidungen getroffen werden sollen.

Wenn Sie die Windows-Authentifizierung verwenden, erstellt das Windows-Authentifizierungsmodul automatisch ein WindowsPrincipal-Objekt und speichert es in HttpContext.User. Falls Sie andere Authentifizierungsmechanismen wie Formulare oder Passport verwenden, müssen Sie ein GenericPrincipal -Objekt erstellen und es in HttpContext.User speichern.

ASP.NET-Identitäten

Bei der Ausführung einer ASP.NET-Webanwendung können zu einem bestimmten Zeitpunkt mehrere Identitäten während einer einzelnen Anforderung vorhanden sein. Zu diesen Identitäten zählen:

• HttpContext.User gibt ein IPrincipal-Objekt zurück, das Sicherheitsinformationen für die aktuelle Webanforderung enthält. Hierbei handelt es sich um den authentifizierten Webclient.

• WindowsIdentity.GetCurrent() gibt die Identität des Sicherheitskontexts des aktuell ausgeführten Win32-Threads zurück. Diese Identität ist standardmäßig ASPNET, das Standardkonto, das für die Ausführung von ASP.NET-Anwendungen verwendet wird. Wenn in der Webanwendung jedoch ein Identitätswechsel konfiguriert wurde, stellt die Identität den authentifizierten Benutzer dar (wenn die anonyme Authentifizierung in IIS authentifiziert ist, ist dies IUSR_MACHINE).

• Thread.CurrentPrincipal gibt den Prinzipal des aktuell oberhalb des Win32-Threads ausgeführten .NET-Threads zurück.

Weitere Informationen

• Eine detaillierte Analyse der ASP.NET-Identität für eine Kombination von Webanwendungskonfigurationen (sowohl mit als auch ohne Identitätswechsel) finden Sie unter "ASP.NET-Identitätsmatrix" im Abschnitt "Referenz" dieses Handbuches.

• Weitere Informationen zur Erstellung Ihrer eigenen IPrincipal-Implementierung finden Sie in Modul 8, "ASP.NET-Sicherheit" und unter "Implementieren von IPrincipal" im Abschnitt "Referenz" dieses Handbuches.

Remoting und Webdienste

In der aktuellen Version von .NET Framework verfügen Remoting und Webdienste nicht über ein eigenes Sicherheitsmodell. Für beide wird die Sicherheitsfunktion von IIS und ASP.NET übernommen.

Obgleich die Sicherheit nicht in die Remoting-Architektur integriert ist, wurde sie unter Berücksichtigung der Sicherheit entworfen. Der Entwickler bzw. Administrator trägt die Verantwortung, bestimmte Sicherheitsstufen in Remoting-Anwendungen zu integrieren. Ob Prinzipal-Objekte über Remoting-Grenzen hinweg übertragen werden, ist vom Standort des Client und des Remoteobjekts abhängig. Beispiel:

• Remoting innerhalb desselben Prozesses. Wenn Remoting zwischen Objekten in derselben Anwendungsdomäne oder in separaten Anwendungsdomänen verwendet wird, wird durch die Remoting-Infrastruktur ein Verweis auf das IPrincipal-Objekt in den Kontext des Empfängers kopiert, das dem Kontext des Aufrufers zugeordnet ist.

• Prozessübergreifendes Remoting. In diesem Fall werden IPrincipal-Objekte nicht zwischen Prozessen übertragen. Die für die Erstellung des ursprünglichen IPrincipal verwendeten Anmeldeinformationen müssen an den Remoteprozess übertragen werden, der sich möglicherweise auf einem separaten Computer befindet. Dann kann der Remotecomputer ein geeignetes IPrincipal-Objekt anhand der bereitgestellten Anmeldeinformationen erstellen.

 

Zusammenfassung

In diesem Modul wurden alle Authentifizierungs- und Autorisierungsoptionen vorgestellt, die in den unterschiedlichen .NET-bezogenen Technologien zur Verfügung stehen. Zudem wurde eine Einführung in die .NET Framework-Sicherheit sowie in die Prinzipal- und Identity-Objekte gegeben, die bei der ASP.NET-Autorisierung eine wichtige Rolle spielen.

Durch die Verwendung mehrerer Gatekeeper in Ihrer .NET-Webanwendung können Sie eine Sicherheitsstrategie zur Tiefenverteidigung implementieren. Zusammengefasst:

• In ASP.NET-Anwendungen können die von Windows und IIS bereitgestellten vorhandenen Sicherheitsfunktionen verwendet werden.

• Zur Bereitstellung der sicheren Kommunikation zwischen den Ebenen einer .NET-Webanwendung, beispielsweise zwischen einem Browser und einer Datenbank, ist eine Kombination aus SSL und IPSec anzuraten.

• Verwenden Sie SSL, um die in Klartext vorliegenden Anmeldeinformationen zu schützen, die bei der Standard- oder Formularauthentifizierung über das Netzwerk weitergeleitet werden.

• ASP.NET-Webanwendungen, die auf der ersten Version von .NET Framework basieren, müssen als vollständig vertrauenswürdige Anwendungen ausgeführt werden. Dabei ist die Codezugriffssicherheit für die Entwickler der serverseitigen Webanwendung eingeschränkt. Durch Version 1.1 des .NET Framework werden Webanwendungen aktiviert, denen teilweise vertraut wird. Dadurch erhält die Codezugriffssicherheit eine größere Bedeutung.

• .NET stellt Benutzer dar, die durch die Windows-Authentifizierung und unter Verwendung einer Kombination aus den Klassen WindowsPrincipal und WindowsIdentity identifiziert wurden.

• Die Klassen GenericPrincipal und GenericIdentity oder FormsIdentity werden zur Darstellung von Benutzern verwendet, die anhand von Nicht-Windows-Authentifizierungsschemata, wie der Formularauthentifizierung, identifiziert wurden.

• Sie können eigene Prinzipal- und Identitätsimplementierungen bauen, indem Sie Klassen erstellen, in denen IPrincipal und IIdentity implementiert sind.

• In ASP.NET-Webanwendungen wird das IPrincipal-Objekt, das den authentifizierten Benutzer darstellt, mit der Eigenschaft HttpContext.User der aktuellen HTTP-Webanforderung zugeordnet.

• Bei Gates handelt es sich um Zugriffskontrollpunkte innerhalb Ihrer Anwendung, über die autorisierte Benutzer Ressourcen oder Dienste aufrufen können. Gatekeeper sind für die Steuerung des Zugriffs auf Gates verantwortlich.

• Verwenden Sie mehrere Gatekeeper, um eine Strategie zur Tiefenverteidigung bereitzustellen.

• Webdienste und .NET-Remoting setzen auf die zugrunde liegenden Sicherheitsdienste, die durch AS.NET und IIS bereitgestellt werden.

Im nächsten Modul, Modul 3, "Authentifizierung und Autorisierung", erhalten Sie weitere Informationen zur Auswahl der am besten geeigneten Authentifizierungs- und Autorisierungsstrategie für ein bestimmtes Anwendungsszenario.