Modul 7 – Internetsicherheit

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 Vorbereitung
 ASP.NET zum SQL Server
 ASP.NET über Remote Enterprise Services zum SQL Server
  Zusammenfassung

Modulübersicht

Internetanwendungen zeichnen sich durch eine große Zielgruppe, viele potenzielle Einsatzbereiche und unterschiedliche Sicherheitsanforderungen aus. Das Spektrum reicht von Portalanwendungen, die keine Benutzerauthentifizierung erfordern, über Webanwendungen, die Inhalte für registrierte Benutzer bereitstellen, bis hin zu großen E-Commerce-Anwendungen, die eine umfassende Authentifizierung, Autorisierung, Kreditkartenüberprüfung und sichere Übertragung vertraulicher Daten über öffentliche und interne Netzwerke erfordern.

In diesem Modul werden die Ansätze zur Behebung von Problemen hinsichtlich Authentifizierung, Autorisierung und sicherer Kommunikation für internetbasierte Webanwendungen erläutert. Der Schwerpunkt liegt dabei auf den Anforderungen von zwei häufig verwendeten Architekturen von verteilten Anwendungen.

Zielsetzung

Themenbereiche:

• Sichern Ihrer .NET-Internetanwendung

• Erläutern der Sicherheitsrisiken und empfohlenen Lösungen in Verbindung mit einer ASP.NET-Webanwendung zur Kommunikation mit SQL Server 2000 in den folgenden Szenarios:

  • Direkte Kommunikation

  • Verwenden von Enterprise Services als Zwischensystem

• Bestimmen der optimalen Vorgehensweise zur Implementierung von Authentifizierung, Autorisierung und sicherer Kommunikation in einer internetbasierten verteilten Webanwendung.

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) und höhere Versionen

• 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 Entwicklung mit ASP.NET, SQL Server und IIS sowie deren Konfiguration verfügen.

• Sie müssen über Erfahrung in der Konfiguration von Windows-Sicherheit verfügen.

• Sie müssen über Erfahrung in der 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 verteilten ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Sie Authentifizierung, Autorisierung und sichere Kommunikation in diese Architektur integrieren können.

• Verwenden Sie das aktuelle Modul in Kombination mit folgenden Modulen:

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

  • Vorgehensweise: Einrichten von SSL auf einem Webserver"

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

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

  • "Vorgehensweise: Verwenden der Formularauthentifizierung mit Active Directory"

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

  • "Vorgehensweise: Verwenden von rollenbasierter Sicherheit mit Enterprise Services"

  • "Vorgehensweise: Aufrufen eines Webdienstes unter Verwendung von SSL"

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

Vorbereitung

Als Entwickler von Internetanwendungen müssen Sie sicherstellen, dass die Anwendung geeignete Verteidigungsmechanismen verwendet sowie skalierbar, hochleistungsfähig und sicher ist. Hierzu zählen die folgenden Aufgaben:

• Auswählen eines geeigneten Speichers für die Anmeldeinformationen der Benutzer, z. B. einer benutzerdefinierten Datenbank oder des Verzeichnisdienstes Active Directory®

• Sicherstellen der Funktionsfähigkeit der Anwendung mithilfe von Firewalls

• Übermitteln von Sicherheitsanmeldeinformationen über mehrere Ebenen der Anwendung hinweg

• Durchführen von Autorisierungen

• Sicherstellen der Datenintegrität und des Datenschutzes bei der Übertragung über öffentliche und interne Netzwerke

• Sichern des Anwendungsstatus mit einer Datenbank

• Sicherstellen der Integrität der Anwendungsdaten

• Implementieren einer Lösung, die sich bei Bedarf für eine hohe Anzahl von Benutzern skalieren lässt

In diesem Modul werden die empfohlenen Techniken für Authentifizierung, Autorisierung und sichere Kommunikation anhand von zwei üblichen Internetanwendungsszenarios veranschaulicht:

• ASP.NET zum SQL Server

• ASP.NET über Remote Enterprise Services zum SQL Server

Hinweis: In einigen in diesem Modul beschriebenen Szenarios wird das Kennwort des Standardkontos ASPNET geändert, damit auf den Remotecomputern duplizierte Konten zu Netzwerk-Authentifizierungszwecken erstellt werden können. Hierfür ist eine Aktualisierung des <processModel>-Elements von Machine.config erforderlich. <processModel>-Anmeldeinformationen sollten in machine.config nicht als unverschlüsselter Text gespeichert werden. Verwenden Sie stattdessen das Dienstprogramm aspnet_setreg.exe, um verschlüsselte Anmeldeinformationen in der Registrierung zu speichern. Weitere Informationen finden Sie in Modul 8, "ASP.NET-Sicherheit", sowie im Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig), in der Microsoft Knowledge Base.

ASP.NET zum SQL Server

In diesem Szenario mit zwei physischen Ebenen melden sich registrierte Benutzer mit einem Webbrowser sicher bei der webbasierten Anwendung an. Die ASP.NET-basierte Webanwendung stellt für den Datenabruf sichere Verbindungen zu einer Microsoft® SQL Server™-Datenbank her. Ein Beispiel dafür ist eine Portalanwendung, die registrierten Abonnenten Newsinhalte bereitstellt. Dieses Szenario ist in Abbildung 7.1 dargestellt.

Abbildung 7.1
Internetszenario "ASP.NET-Webanwendung zu SQL Server"

Merkmale

Dieses Szenario weist folgende Merkmale auf:

• Die Benutzer verwenden unterschiedliche Browsertypen.

• Anonyme Benutzer können die nicht eingeschränkten Seiten der Anwendung aufrufen.

• Die Benutzer müssen sich registrieren oder anmelden (über ein HTML-Formular), bevor sie eingeschränkte Seiten anzeigen können.

• Die Anmeldeinformationen der Benutzer werden anhand einer SQL Server-Datenbank überprüft.

• Alle in Datenbankabfragen verwendeten Benutzereingaben (z. B. die Anmeldeinformationen der Benutzer) werden überprüft, um die Gefahr von SQL Injection-Angriffen zu reduzieren.

• Die Front-End-Webanwendung befindet sich in einem Perimeternetzwerk (auch als Demilitarized Zone (DMZ), also "demilitarisierte Zone" oder überwachtes Subnetz bezeichnet), das durch Firewalls vom Internet und dem internen Firmennetzwerk (sowie der SQL Server-Datenbank) getrennt ist.

• Die Anwendung erfordert strenge Sicherheit, eine hohe Skalierbarkeit und eine detaillierte Überwachung.

• Die Datenbank vertraut der Anwendung, dass die Benutzer ordnungsgemäß authentifiziert werden (d. h. die Anwendung führt die Datenbankaufrufe im Namen der Benutzer durch).

• Die Webanwendung stellt die Verbindungen zur Datenbank unter Verwendung des ASP.NET-Prozesskontos her.

• In SQL Server wird für die Datenbankautorisierung eine einzige benutzerdefinierte Datenbankrolle verwendet.

Sichern des Szenarios

In diesem Szenario zeigt die Webanwendung eine Anmeldeseite an, auf der die Anmeldeinformationen eingegeben werden können. Erfolgreich überprüfte Benutzer dürfen fortfahren, allen anderen wird der Zugriff verweigert. Die Datenbank führt die Authentifizierung anhand der ASP.NET-Standardprozessidentität durch. Dabei handelt es sich um ein Konto mit minimalen Rechten (d. h. die Datenbank vertraut der ASP.NET-Anwendung).

Tabelle 7.1: Übersicht über die Sicherheit

Das Ergebnis

Aus Abbildung 7.2 geht die empfohlene Sicherheitskonfiguration für dieses Szenario hervor.

Abbildung 7.2
Empfohlene Sicherheitskonfiguration für das Internetszenario "ASP.NET zu SQL Server"

Schritte zum Konfigurieren der Sicherheit

Bevor Sie beginnen, sollten Sie sich über folgende Themen informieren:

• Erstellen von benutzerdefinierten ASP.NET-Konten (siehe "Vorgehensweise: Erstellen eines benutzerdefinierten Kontos zum Ausführen von ASP.NET" in diesem Handbuch)

• Erstellen eines Datenbankkontos mit minimalen Rechten (siehe Modul 12, "Datenzugriffssicherheit")

• Konfigurieren von SSL auf einem Webserver (siehe "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch)

• Konfigurieren von IPSec (siehe "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch)

Konfigurieren des Webservers

<!-- userName="Computer" password="AutoGenerate"
 -->

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

<authentication mode="Formulare" >  
	<forms name="MyAppFormsAuth"
          loginUrl="login.aspx"
          protection="Alle"  
          timeout="20"         
          path="/" &gt;  
      </forms>
</authentication>

Konfigurieren des SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• Die Formularauthentifizierung ist in diesem Szenario optimal, da die Benutzer über keine Windows-Konten verfügen. Die Anmeldeinformationen der Benutzer werden auf der Formularanmeldeseite erfasst. Der Anwendungscode muss die Anmeldeinformationen überprüfen. Es kann jeder beliebige Datenspeicher verwendet werden. Meist wird für die Speicherung der Anmeldeinformationen eine SQL Server-Datenbank verwendet, obwohl auch Active Directory eine Alternative sein kann.

• Bei der Formularauthentifizierung müssen Sie die ersten Anmeldeinformationen mit SSL schützen. Das Formularauthentifizierungsticket (das bei nachfolgenden Webanforderungen vom authentifizierten Client als Cookie übertragen wird) muss ebenfalls geschützt werden. Sie können für alle Seiten SSL verwenden, um das Ticket zu schützen. Alternativ können Sie das Formularauthentifizierungsticket verschlüsseln, indem Sie das protection-Attribut des <Formulare>-Elements (Alle oder Verschlüsseln) konfigurieren und das Ticket mit der Verschlüsseln-Methode der FormsAuthentication-Klasse verschlüsseln.
  Über das protection="Alle"-Attribut wird festgelegt, dass beim Aufruf von FormsAuthentication.Encrypt durch die Anwendung das Ticket überprüft (Integritätsprüfung) und verschlüsselt werden soll. Rufen Sie diese Methode auf, wenn Sie das Authentifizierungsticket erstellen (normalerweise unter Verwendung des Ereignishandlers der Anmeldeschaltfläche der Anwendung).

    string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
  

  Weitere Informationen zur Formularauthentifizierung und zur Ticketverschlüsselung finden Sie in Modul 8, "ASP.NET-Sicherheit".

• ASP.NET wird unter dem lokalen Konto ASPNET mit minimalen Rechten ausgeführt.

• Die URL-Autorisierung im Webserver ermöglicht nicht authentifizierten Benutzern, nicht eingeschränkte Webseiten aufzurufen, erzwingt jedoch bei eingeschränkten Seiten eine Authentifizierung.

• Da keine Identitätswechsel aktiviert sind, erfolgt jeder Zugriff auf lokale oder Remoteressourcen durch die webbasierte Anwendung im Sicherheitskontext des Kontos ASPNET. Die Windows-ACLs für sichere Ressourcen sind entsprechend festzulegen.

• Die Anmeldeinformationen der Benutzer werden anhand einer benutzerdefinierten SQL Server-Datenbank überprüft. In der Datenbank werden Kennworthashs mit Salt-Werten gespeichert. Weitere Informationen finden Sie unter "Datenzugriffssicherheit" in Modul 12, "Datenzugriffssicherheit".

• Die Windows-Authentifizierung für SQL bedeutet, dass keine Anmeldeinformationen in Dateien auf dem Webserver gespeichert und über das Netzwerk übertragen werden müssen.

• Wenn die Anwendung zurzeit die SQL-Authentifizierung verwendet, müssen Sie die Datenbankverbindungszeichenfolge sicher speichern, da sie Benutzernamen und Kennwörter enthält. Ziehen Sie DPAPI in Erwägung. Weitere Informationen finden Sie unter "Sicheres Speichern von Datenbank-Verbindungszeichenfolgen" in Modul 12, "Datenzugriffssicherheit".

• Ein dupliziertes Windows-Konto auf dem Datenbankserver (das mit dem ASP.NET-Prozesskonto übereinstimmt) führt zu einem höheren Verwaltungsaufwand. Wenn ein Kennwort auf einem Computer geändert wird, muss es auf dem anderen Computer synchronisiert und aktualisiert werden. In einigen Szenarien können Sie den Verwaltungsaufwand mithilfe eines Domänenkontos mit minimalen Rechten reduzieren.

• IPSec zwischen Webserver und Datenbankserver stellt den Schutz der Daten sicher, die von und zu der Datenbank gesendet werden.

• SSL zwischen Browser und Webserver schützt die Anmeldeinformationen und andere sicherheitsrelevanter Daten wie Kreditkartennummern.

• Wenn Sie eine Webfarm verwenden, müssen Sie sicherstellen, dass die Verschlüsselungsschlüssel, z. B. diejenigen, mit denen das Formularauthentifizierungsticket verschlüsselt wird (und die durch das <machineKey>-Element in Machine.config angegeben werden), auf allen Servern in der Farm übereinstimmen. Weitere Details zur Verwendung von ASP.NET in einem Webfarmszenario finden Sie in Modul 8, "ASP.NET-Sicherheit".

Nachteile

Die Anwendung muss zur Unterstützung von Überwachungsanforderungen die Identität des ursprünglichen Benutzers an die Datenbank übertragen. Die Identität des Benutzers kann mithilfe von Parametern gespeicherter Prozeduren übergeben werden.

Verwandte Szenarios

Formularauthentifizierung anhand der Active Directory

Die auf der Formularanmeldeseite erfassten Anmeldeinformationen der Benutzer können anhand einer Vielzahl von Speichern authentifiziert werden. Active Directory stellt eine Alternative zur Verwendung einer SQL Server-Datenbank dar.

Weitere Informationen

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

.NET-Rollen für die Autorisierung

In dem oben beschriebenen Szenario werden nicht die verschiedenen Benutzertypen berücksichtigt, die auf die Anwendung zugreifen. So können z. B. auf einem Portalserver verschiedene Abonnementebenen eingerichtet sein, wie Standard, Premier oder Enterprise.

Wenn die Rolleninformationen im Benutzerspeicher (SQL Server-Datenbank) verwaltet werden, kann die Anwendung ein GenericPrincipal-Objekt erstellen, in dem Rollen- und Identitätsinformationen gespeichert werden können. Nachdem das GenericPrincipal-Objekt erstellt und (mit HttpContext.User) in den Kontext der Webanforderung eingefügt wurde, können Sie programmgesteuerte Rollenüberprüfungen zum Methodencode hinzufügen oder Methoden und Seiten mit PrincipalPermission-Attributen erweitern, um eine Rollenmitgliedschaft zu fordern.

Weitere Informationen

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

• Weitere Informationen zu PrincipalPermission-Forderungen und programmgesteuerten Rollenüberprüfungen finden Sie in Modul 8, "ASP.NET-Sicherheit".

Verwenden eines anonymen Domänenkontos auf dem Webserver

In dieser Szenariovariante wird das standardmäßige anonyme Internetbenutzerkonto (ein lokales Konto namens IUSR_MACHINE) durch ein Domänenkonto ersetzt. Das Domänenkonto wird mit den zum Ausführen der Anwendung minimal erforderlichen Rechten konfiguriert (Sie können ohne Rechte beginnen und schrittweise Rechte hinzufügen). Sind mehrere webbasierte Anwendungen vorhanden, können Sie unterschiedliche Domänenkonten verwenden (für jede webbasierte Anwendung oder jedes virtuelle Verzeichnis ein separates Konto).

Aktivieren Sie mithilfe der folgenden Einstellung in der Datei web.config Identitätswechsel für die webbasierte Anwendung, damit der Sicherheitskontext des anonymen Domänenkontos von IIS an ASP.NET übermittelt wird:

<identity impersonate="true" />

Wenn die webbasierte Anwendung mit einer Remoteressource kommuniziert, z. B. einer Datenbank, müssen Sie dem Domänenkonto die erforderlichen Berechtigungen für die Ressource erteilen. Wenn die Anwendung beispielsweise auf ein Remotedateisystem zugreift, müssen die ACLs so konfiguriert werden, dass das Domänenkonto mindestens Lesezugriff erhält. Wenn die Anwendung auf eine SQL Server-Datenbank zugreift, muss das Domänenkonto mit einem SQL-Benutzernamen einem Datenbankanmeldenamen zugeordnet werden.

Da der Sicherheitskontext, der die Anwendung durchläuft, vom anonymen Konto stammt, muss die Identität des ursprünglichen Benutzers (die durch die Formularauthentifizierung erfasst wurde) auf Anwendungsebene von Ebene zu Ebene übertragen werden, beispielsweise über Parameter von Methoden und gespeicherten Prozeduren.

Weitere Informationen

• Weitere Informationen zu diesem Verfahren finden Sie unter "Verwenden des anonymen Internetbenutzerkontos" im Abschnitt "Zugreifen auf Netzwerkressouren" in Modul 8, "ASP.NET-Sicherheit".

• Bevor Sie dieses Szenario implementieren, sollten Sie den Artikel Q259353, "Must Enter Password Manually After You Set Password Synchronization" (englischsprachig), in der Microsoft Knowledge Base lesen.

ASP.NET über Remote Enterprise Services zum SQL Server

In diesem Szenario stellt ein Webserver, auf dem ASP.NET-Seiten ausgeführt werden, sichere Verbindungen zu Serviced Components her, die sich auf einem Remoteanwendungsserver befinden, der wiederum eine Verbindung zu einer SQL Server-Datenbank herstellt. Wie bei vielen Infrastrukturen von Internetanwendungen üblich, sind Webserver und Anwendungsserver durch eine Firewall getrennt, der Webserver befindet sich in einem Perimeternetzwerk. Die Serviced Components stellen sichere Verbindungen zu SQL Server her.

Betrachten Sie als Beispiel eine Internetbanking-Anwendung, die Benutzern vertrauliche Daten (z. B. ihren Kontostand) bereitstellt. Alle Banktransaktionen vom Client zur Datenbank müssen gesichert werden, die Datenintegrität ist von entscheidender Bedeutung. Es muss nicht nur der Datenverkehr vom und zum Benutzer gesichert werden, sondern auch der Datenverkehr von und zu der Datenbank. Dieses Szenario ist in Abbildung 7.3 dargestellt.

Abbildung 7.3
Internetszenario "ASP.NET über Remote Enterprise Services zu SQL Server"

Merkmale

• Die Benutzer verwenden unterschiedliche Browsertypen.

• Anonyme Benutzer können die nicht eingeschränkten Seiten der Anwendung aufrufen.

• Die Benutzer müssen sich registrieren oder anmelden (über ein HTML-Formular), bevor sie eingeschränkte Seiten anzeigen können.

• Die Front-End-Webanwendung befindet sich in einem Perimeternetzwerk, das durch Firewalls vom Internet und dem internen Firmennetzwerk (sowie dem Anwendungsserver) getrennt ist.

• Die Anwendung erfordert strenge Sicherheit, eine hohe Skalierbarkeit und eine detaillierte Überwachung.

• Die webbasierte Anwendung verwendet SOAP für die Verbindung zu einer Webdienstschicht, die eine Schnittstelle zu den Serviced Components bereitstellt, die in einer Enterprise Services-Anwendung auf dem Anwendungsserver ausgeführt werden. SOAP wird aufgrund von Firewalleinschränkungen gegenüber DCOM bevorzugt.

• SQL Server verwendet für die Autorisierung eine einzige benutzerdefinierte Datenbankbenutzerrolle.

• Die Daten sind sicherheitsrelevant. Datenintegrität und Datenschutz müssen über das Netzwerk und in allen persistenten Datenspeichern gewährleistet sein.

• Die Datenintegrität wird mithilfe von Enterprise Services-(COM+-)Transaktionen erzwungen.

Sichern des Szenarios

In diesem Szenario übernimmt der Webdienst die Anmeldeinformationen von einer Formularanmeldeseite und authentifiziert dann den Benutzer anhand einer SQL Server-Datenbank. Die Anmeldeseite verwendet SSL, um die über das Internet übertragenen Anmeldeinformationen der Benutzer zu schützen.

Die webbasierte Anwendung kommuniziert mit einem Webdienst, der eine Schnittstelle zu den in den Serviced Components implementierten Unternehmensdiensten bereitstellt. Der Webdienst vertraut der webbasierten Anwendung (im Perimeternetzwerk) und authentifiziert die ASP.NET-Prozessidentität. Die Identität des Benutzers wird mithilfe von Parametern von Methoden und gespeicherten Prozeduren durch alle Ebenen auf der Anwendungsebene weitergegeben. Diese Informationen werden zur Überwachung der Aktionen des Benutzers in allen Ebenen verwendet.

Tabelle 7.2: Sicherheitsmaßnahmen

Das Ergebnis

Aus Abbildung 7.4 geht die empfohlene Sicherheitskonfiguration für dieses Szenario hervor.

Abbildung 7.4
Empfohlene Sicherheitskonfiguration für das Internetszenario "ASP.NET über Remote Enterprise Services zu SQL Server"

Schritte zum Konfigurieren der Sicherheit

Bevor Sie beginnen, sollten Sie sich über folgende Themen informieren:

• Erstellen eines Datenbankkontos mit minimalen Rechten (siehe Modul 12, "Datenzugriffssicherheit")

• Konfigurieren von SSL auf einem Webserver (siehe "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch)

• Konfigurieren von IPSec (siehe "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch)

• Konfigurieren der Enterprise Services-Sicherheit (siehe "Vorgehensweise: Verwenden von rollenbasierter Sicherheit mit Enterprise Services" in diesem Handbuch)

Konfigurieren des Webservers

<!-- userName="Computer" password="AutoGenerate" 
-->

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

 
<authentication mode="Formulare" >  
	<forms name="MyAppFormsAuth"         
                loginUrl="login.aspx"          
	       protection="Alle"        
	       timeout="20"         
	       path="/" >  
         </forms>
 </authentication>

Konfigurieren des Anwendungsservers

<authentication mode="Windows" />

Konfigurieren von SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• Die Formularauthentifizierung ist in diesem Szenario optimal, da die Benutzer über keine Windows-Konten verfügen. Die Anmeldeinformationen der Benutzer werden auf der Formularanmeldeseite erfasst. Der Anwendungscode muss die Anmeldeinformationen überprüfen. Es kann jeder beliebige Datenspeicher verwendet werden. Meist wird für die Speicherung der Anmeldeinformationen eine SQL Server-Datenbank verwendet, obwohl auch Active Directory eine Alternative sein kann.

• Die webbasierte Anwendung wird unter dem lokalen Konto ASPNET mit minimalen Rechten ausgeführt.

• Die URL-Autorisierung im Webserver ermöglicht nicht authentifizierten Benutzern, nicht eingeschränkte Webseiten aufzurufen, erzwingt jedoch bei eingeschränkten Seiten eine Authentifizierung.

• Da keine Identitätswechsel aktiviert sind, erfolgt jeder Zugriff auf lokale oder Remoteressourcen durch die webbasierte Anwendung im Sicherheitskontext des Kontos ASPNET. Die ACLs müssen entsprechend konfiguriert werden.

• Die Anmeldeinformationen der Benutzer werden anhand einer benutzerdefinierten SQL Server-Datenbank überprüft. In der Datenbank werden Kennworthashs mit Salt-Werten gespeichert. Weitere Informationen finden Sie unter "Authentifizieren von Benutzern anhand einer Datenbank" in Modul 12, "Datenzugriffssicherheit".

• Die Windows-Authentifizierung für den SQL Server bedeutet, dass keine Anmeldeinformationen in Dateien auf dem Anwendungsserver gespeichert und über das Netzwerk übertragen werden müssen.

• Ein dupliziertes Windows-Konto auf dem Datenbankserver (das mit dem Enterprise Services-Prozesskonto übereinstimmt) führt zu einem höheren Verwaltungsaufwand. Wenn ein Kennwort auf dem einen Computer geändert wird, muss es auf dem anderen Computer synchronisiert und aktualisiert werden. In einigen Szenarios besteht u. U. die Möglichkeit, den Verwaltungsaufwand mithilfe eines Domänenkontos mit minimalen Rechten zu reduzieren.

• Wenn die Webanwendung den Webdienst aufruft, muss der Webdienstproxy mithilfe von DefaultCredentials (d. h. dem ASP.NET-Prozesskonto ASPNET) konfiguriert werden.

    proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
  

  Weitere Informationen finden Sie unter "Übergeben von Anmeldeinformationen an Webdienste zur Authentifizierung" in Modul 10, "Webdienstesicherheit".

• SSL zwischen dem Webserver und der Webdienstschicht (die vor den Serviced Components auf dem Anwendungsserver liegt) stellt den Schutz der zwischen den beiden Servern gesendeten Daten sicher.

• Die Enterprise Services-Anwendung ist für eine rollenbasierte Sicherheit auf Anwendungsebene konfiguriert. Die Konfiguration lässt nur den Zugriff durch das lokale ASPNET-Konto (mit dem der Webdienst ausgeführt wird) auf die Serviced Components zu.

• IPSec zwischen Anwendungsserver und Datenbankserver stellt den Schutz der Daten sicher, die von und zu der Datenbank gesendet werden.

• SSL zwischen Browser und Webserver schützt die Anmeldeinformationen und Bankkontendetails.

Nachteile

Die Anwendung muss die Identität des ursprünglichen Benutzers an die Datenbank übertragen, damit Überwachungsanforderungen unterstützt werden. Die Identität des Benutzers kann über Parameter gespeicherter Prozeduren übergeben werden.

Verwandte Szenarios

Formularauthentifizierung anhand der Active Directory

Die auf der Formularanmeldeseite erfassten Anmeldeinformationen der Benutzer können anhand einer Vielzahl von Speichern authentifiziert werden. Active Directory stellt eine Alternative zur Verwendung einer SQL Server-Datenbank dar.

Weitere Informationen

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

Verwenden von DCOM

Windows 2000 (SP3 oder SP2 mit QFE 18.1) oder Windows Server 2003 ermöglichen die Konfiguration von Enterprise Services-Anwendungen für die Verwendung eines statischen Endpunktes. Wenn der Client durch eine Firewall vom Server getrennt ist, bedeutet das, dass in der Firewall nur zwei Ports geöffnet werden müssen: Port 135 für RPC und ein Port für die Enterprise Services-Anwendung.

Diese Erweiterung von DCOM ermöglicht die Auswahl von DCOM als Kommunikationsprotokoll zwischen dem Webserver und dem Anwendungsserver. Eine Webdienstschicht ist in diesem Fall nicht erforderlich.

Wichtig: Wenn die Anwendung die Übertragung verteilter Transaktionen zwischen den beiden Servern erfordert, muss DCOM verwendet werden. Transaktionen können nicht über SOAP laufen. Im SOAP-Szenario müssen die Transaktionen durch die Serviced Components auf dem Anwendungsserver initiiert werden.

Weitere Informationen

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

Verwenden von .NET Remoting

Remoting ist eine Alternative, wenn keine von Enterprise Services bereitgestellten Dienste benötigt werden, wie z. B. Transaktionen, Warteschlangenkomponenten, Objektpooling usw. .NET Remoting-Lösungen unterstützen auch den Netzwerklastenausgleich auf der mittleren Ebene. Beachten Sie Folgendes, wenn Sie .NET Remoting verwenden:

• Optimale Leistung erreichen Sie, wenn Sie den TCP-Kanal und Host in einem Windows-Dienst verwenden. Beachten Sie, dass dieser Kanal standardmäßig keinen Authentifizierungs- und Autorisierungsmechanismus bereitstellt. Der TCP-Kanal ist für Szenarios mit vertrauenswürdigen Subsystemen konzipiert. Sie können mithilfe einer IPSec-Richtlinie einen sicheren Kanal einrichten und sicherstellen, dass nur der Webserver mit dem Anwendungsserver kommuniziert.

• Wenn Authentifizierungs- und Autorisierungsprüfungen mit IPrincipal-Objekten erforderlich sind, sollten Sie die Remoteobjekte in ASP.NET verwalten und den HTTP-Kanal verwenden. Dadurch können Sie die Sicherheitsfunktionen von IIS und ASP.NET verwenden.

• Das Remoteobjekt kann über die Windows-Authentifizierung Verbindungen zur Datenbank herstellen und die Prozessidentität des Hosts verwenden (entweder ASP.NET oder eine Windows-Dienstidentität).

Weitere Informationen

Weitere Informationen zur .NET Remoting-Sicherheit finden Sie in Modul 11, "Enterprise Services-Sicherheit".

Zusammenfassung

In diesem Modul wurde beschrieben, wie häufig vorkommende Internetanwendungsszenarios gesichert werden.

Informationen zu Intranet- und Extranetanwendungsszenarios finden Sie in Modul 5, "Intranetsicherheit", und Modul 7, "Extranetsicherheit".