Freigeben über

Modul 6 – Extranetsicherheit

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Vorbereitung Vorbereitung
Bereitstellen eines Webdienstes Bereitstellen eines Webdienstes
Bereitstellen einer Webanwendung Bereitstellen einer Webanwendung
Zusammenfassung Zusammenfassung

Modulübersicht

Ein Extranet ist ein logisches Netzwerk, das es zwei oder mehr Organisationen ermöglicht, Ressourcen und Anwendungen über (sogar öffentliche) physikalische Netzwerke hinweg freizugeben. Durch die Beteiligung mehrerer Organisationen gestaltet sich die Sicherheitsarchitektur einer Extranetanwendung schwieriger, da Anwendungen in die verschiedenen Systeme und Standards aller Organisationen integriert werden müssen. Da die Anwendung freigegebene oder öffentliche Netzwerke nutzt, muss zwischen vertrauenswürdigen und nicht vertrauenswürdigen Benutzern unterschieden werden. Außerdem muss sichergestellt sein, dass eine vertrauenswürdige Organisation keinen Einblick in die geheimen Informationen einer anderen Organisation hat. Wenn die Anwendung vertrauliche oder kommerziell wertvolle Informationen verarbeitet, sind sichere Kommunikationskanäle unerlässlich.

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

 

Zielsetzung

Themenbereiche:

  • Sichern Ihrer .NET-Extranetanwendung

  • Erläutern der Sicherheitsprobleme und empfohlener Lösungen im Zusammenhang mit der Implementierung einer extranetbasierten Anwendung als:

    • ASP.NET-Webdienst

    • ASP.NET-Webanwendung

  • Festlegen des optimalen Ansatzes zur Implementierung von Authentifizierung, Autorisierung und sicherer Kommunikation in einer extranetbasierten 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:

 

Vorbereitung

Bei Extranetanwendungen handelt es sich um Anwendungen, für die Ressourcen via Internet über zwei unterschiedliche Unternehmen oder Abteilungen hinweg freigegeben wurden. Eine der größten Herausforderungen bei Extranetanwendungen ist die Ausarbeitung eines Authentifizierungsansatzes, dem beide Parteien zustimmen. Ihre Möglichkeiten sind in diesem Fall eventuell beschränkt, da die Zusammenarbeit mit bestehenden Authentifizierungsmechanismen erforderlich ist.

Extranetanwendungen weisen in der Regel einige gemeinsame Merkmale auf:

  • Im Vergleich zu Internetszenarios ist eine genauere Steuerung von Benutzerkonten möglich.

  • Hinsichtlich der Benutzerkonten ist möglicherweise ein höherer Vertrauensgrad gegeben als bei Anwendungen mit Internetbenutzern.

Zu den in diesem Modul erläuterten Szenarios zählen folgende:

  • Bereitstellen eines Webdienstes

  • Bereitstellen einer Webanwendung

Hinweis: In den in diesem Modul beschriebenen Szenarios wird das Kennwort des standardmäßigen ASPNET-Kontos geändert, über das ASP.NET-Anwendungen ausgeführt werden, um doppelte Konten zu Authentifizierungszwecken auf Remotecomputern erstellen zu 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 in Artikel Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (englischsprachig) in der Microsoft Knowledge Base.

 

Bereitstellen eines Webdienstes

Stellen Sie sich ein Austauschszenario mit Business-to-Business-Partnern vor, in dem ein Verleger seine Dienste über das Internet zur Verfügung stellt und verkauft. Sie stellt ausgewählten Partnerfirmen über einen Webdienst Informationen zur Verfügung. Die Benutzer innerhalb der einzelnen Partnerfirmen greifen über eine intranetbasierte interne Webanwendung auf den Webdienst zu. Dieses Szenario ist in Abbildung 6.1 dargestellt.

Austausch zwischen Business-to-Business-Partnern über den Extranet-Webdienst

Abbildung 6.1
Austausch zwischen Business-to-Business-Partnern über den Extranet-Webdienst

Merkmale

Dieses Szenario weist folgende Merkmale auf:

  • Der Verleger stellt einen Webdienst über das Internet bereit.

  • Die Anmeldeinformationen (X.509-Clientzertifikate) der Partnerfirma (nicht eines einzelnen Benutzers) werden durch den Herausgeber geprüft, um den Zugriff auf Ressourcen zu autorisieren. Dem Herausgeber müssen die einzelnen Anmeldungen des Benutzers in der Partnerfirma nicht bekannt sein.

  • Clientzertifikate werden Konten des Active Directory®-Verzeichnisdienstes innerhalb des Verlagsunternehmens zugeordnet.

  • Das Extranet enthält eine Active Directory-Version, die von der (internen) Active Directory-Firmenversion unabhängig ist. Diese Active Directory-Extranetversion befindet sich in einer separaten Gesamtstruktur, die eine eigene Vertrauensgrenze aufweist.

  • Die Webdienstautorisierung basiert auf dem zugeordneten Active Directory-Konto. Sie können separate Autorisierungsentscheidungen nutzen, basierend auf der Identität der Partnerfirma (die durch separate Active Directory-Konten pro Firma dargestellt werden).

  • Der Zugriff auf die Datenbank erfolgt über eine einzelne vertrauenswürdige Verbindung, die der ASP.NET-Webdienst-Prozessidentität entspricht.

  • Die vom Webdienst abgerufenen Daten sind vertraulich und müssen während der Übertragung (intern innerhalb des Verlagsunternehmens und extern bei der Übermittlung über das Internet) gesichert werden.

Sichern des Szenarios

In diesem Szenario ruft die interne Webanwendung der jeweiligen Partnerfirma Daten über den Webdienst vom Verlagsunternehmen ab und stellt diese dann den jeweiligen Benutzern zur Verfügung. Der Verleger benötigt zur Authentifizierung von Partnerfirmen einen sicheren Mechanismus, obwohl die Identität einzelner Benutzer in Partnerfirmen nicht von Bedeutung ist.

Da die Daten, die zwischen den beiden Firmen über das Internet ausgetauscht werden, vertraulich sind, müssen sie bei der Übertragung durch SSL (Secure Socket Layer) gesichert werden.

Eine Firewall, die nur eingehende Verbindungen von den IP-Adressen von Extranetpartnerfirmen zulässt, wird eingesetzt, um zu verhindern, dass andere unbefugte Internetbenutzer Netzwerkverbindungen zum Webdienstserver öffnen.

Tabelle 6.1: Sicherheitsmaßnahmen

Kategorie

Detail

Authentifizierung
  • Partneranwendungen verwenden bei jeder an den Webdienst übermittelten Anforderung Clientzertifikate.
  • Clientzertifikate von Partnerfirmen werden einzelnen Active Directory-Konten zugeordnet.
  • In der Datenbank kommt die Windows®-Authentifizierung zum Einsatz. Die Prozessidentität des ASP.NET-Webdienstes wird zum Verbindungsaufbau verwendet. Die Datenbank vertraut dem Webdienst.

Autorisierung
  • Der Webdienst verwendet die rollenbasierte Autorisierung in .NET, um zu überprüfen, ob authentifizierte Active Directory-Konten Mitglied einer Partnergruppe sind.

Sichere Kommunikation
  • SSL wird verwendet, um die Kommunikation zwischen der Webanwendung des Partners und dem Webdienst des Verlegers zu sichern.
  • IPSec wird verwendet, um sämtliche Kommunikationsvorgänge zwischen dem Webdienst und der Datenbank zu sichern.

Das Ergebnis

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

Die empfohlene Sicherheitskonfiguration für das Austauschszenario mit Business-to-Business-Partnern des Webdienstes

Abbildung 6.2
Die empfohlene Sicherheitskonfiguration für das Austauschszenario mit Business-to-Business-Partnern des Webdienstes

Schritte zur Sicherheitskonfiguration

Als Vorbereitung empfiehlt es sich, folgende Punkte zu bedenken:

Konfigurieren der Partneranwendung

In diesem Modul wird nicht auf Details der Partneranwendung und ihrer Sicherheitskonfiguration eingegangen. Folgende Punkte müssen jedoch berücksichtigt werden, um die Kommunikation zwischen der Partneranwendung und dem Webdienst zu ermöglichen:

  • Die Webanwendung der Partnerfirma kann einen Authentifizierungsmechanismus wählen, mit dem die internen Benutzer authentifiziert und autorisiert werden. Diese Benutzer werden nicht zur weiteren Authentifizierung an den Webdienst übergeben.

  • Die Webanwendung der Partnerfirma führt im Namen ihrer Benutzer Aufrufe des Webdienstes durch. Die Benutzer sind nicht in der Lage, den Webdienst direkt aufzurufen.

  • Die Webanwendung der Partnerfirma verwendet ein Clientzertifikat, um sich beim Webdienst zu identifizieren.

  • Wenn es sich bei der Partneranwendung um eine ASP.NET-Webanwendung handelt, muss eine "Out of Process"-Zwischenkomponente (eine Enterprise Services-Anwendung bzw. ein Windows-Dienst) verwendet werden, um das Zertifikat zu laden und es an den Webdienst weiterzuleiten.
    Weitere Informationen dazu, warum dies erforderlich ist und mit welchen Schritten dies erreicht werden kann, finden Sie unter "Vorgehensweise: Aufrufen eines Webdienstes mit Clientzertifikaten von ASP.NET" in diesem Handbuch.

Konfigurieren des Extranet-Webservers
IIS konfigurieren

Schritt

Weitere Informationen

Anonymen Zugriff für das virtuelle Stammverzeichnis des Webdienstes deaktivieren



Zertifikatsauthentifizierung für das virtuelle Stammverzeichnis Ihrer Webanwendung und Ihres Webdienstes aktivieren

Verwenden Sie das IIS-MMC-Snap-In, um mit IIS-Authentifizierungseinstellungen zu arbeiten. Wählen Sie das virtuelle Verzeichnis Ihrer Anwendung aus, klicken Sie mit der rechten Maustaste und wählen Sie dann Eigenschaften.
Klicken Sie auf die Registerkarte Verzeichnissicherheit und dann in der Gruppe Steuerung des anonymen Zugriffs und der Authentifizierung auf Bearbeiten.

Siehe "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch.
Siehe "Vorgehensweise: Aufrufen eines Webdienstes mit Clientzertifikaten von ASP.NET" in diesem Handbuch.
Active Directory konfigurieren (Extranet)

Schritt

Weitere Informationen

Active Directory-Konten zur Darstellung von Partnerfirmen einrichten

Es wird eine separate Active Directory-Extranetversion verwendet. Diese befindet sich in ihrer eigenen Gesamtstruktur und ist vollkommen unabhängig von der Active Directory-Firmenversion.

Zertifikatszuordnung konfigurieren

Siehe "Step-by-Step Guide to Mapping Certificates to User Accounts" (englischsprachig) im Microsoft TechNet.
Ziehen Sie auch Artikel 313070, "SO WIRD'S GEMACHT: Client-Zertifikatszuordnungen in Internet Information Services (IIS) 5.0 konfigurieren" in der Microsoft Knowledge Base zurate.
ASP.NET konfigurieren (Webdienst)

Schritt

Weitere Informationen

ASP.NET-Webdienst für die Windows-Authentifizierung konfigurieren

Web.config im virtuellen Stammverzeichnis des Webdienstes konfigurieren
Festlegen des <authentication>-Elements auf: 

<authentication mode="Windows" />

Kennwort des ASPNET-Kontos (das zur Ausführung von ASP.NET verwendet wird) auf ein bekanntes sicheres Kennwort zurücksetzen

Hierdurch ist die Erstellung eines doppelten lokalen Kontos (mit demselben Benutzernamen und Kennwort) auf dem Datenbankserver möglich. Dieser Schritt ist erforderlich, damit das ASPNET-Konto auf Netzwerk-Authentifizierungsanforderungen vom Datenbankserver antworten kann, wenn über die Windows-Authentifizierung eine Verbindung hergestellt wird.

Als Alternative kann in diesem Fall ein Domänenkonto mit minimalen Rechten verwendet werden (wenn die Windows-Authentifizierung durch die Firewall zulässig ist). Weitere Informationen finden Sie unter "Prozessidentität für ASP.NET" in Modul 8, "ASP.NET-Sicherheit."

Machine.config bearbeiten in %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Attribute für benutzerdefinierten Kontobenutzernamen und Kennwort für das <processModel>-Element festlegen

Standard

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

Wird zu

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

Beachten Sie, dass das Dienstprogramm aspnet_setreg.exe zur Speicherung eines verschlüsselten Kennworts in der Registrierung verwendet wurde.

Konfigurieren von SQL Server

Schritt

Weitere Informationen

Windows-Konto auf dem Microsoft SQL Server™-Computer erstellen, das dem ASP.NET-Prozesskonto des Webdienstes entspricht (Standard: ASPNET)

Der Benutzername und das Kennwort müssen Ihrem ASP.NET-Prozesskonto entsprechen.

Dem Konto folgende Rechte zuweisen:
– Auf diesen Computer vom Netzwerk aus zugreifen
– Lokale Anmeldung verweigern
– Anmelden als Stapelverarbeitungsauftrag

SQL Server für Windows-Authentifizierung konfigurieren

SQL Server-Anmeldung für das ASPNET-Konto erstellen

Hiermit wird der Zugriff auf SQL Server ermöglicht.

Neuen Datenbankbenutzer erstellen und den Anmeldenamen dem Datenbankbenutzer zuordnen

Hiermit wird der Zugriff auf die angegebene Datenbank ermöglicht.

Neue benutzerdefinierte Datenbankrolle in der Datenbank erstellen und den Datenbankbenutzer in die Rolle einfügen

Datenbankberechtigungen für die Datenbankrolle einrichten

Minimale Rechte gewähren
Siehe Modul 12, "Datenzugriffssicherheit".
Konfigurieren sicherer Kommunikationsvorgänge

Schritt

Weitere Informationen

Website auf dem Webserver für SSL konfigurieren

Siehe "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch.

IPSec zwischen Webserver und Datenbankserver konfigurieren

Siehe "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch.

Analyse

  • ASP.NET wird auf dem Webserver als lokales Konto mit minimalen Rechten ausgeführt (standardmäßiges ASPNET-Konto).

  • Von den ASP.NET-Webanwendungen in den Partnerfirmen wird die integrierte Windows-Authentifizierung verwendet, um zu ermitteln, wer auf den Webdienst zugreifen kann.

  • Von der ASP.NET-Webanwendung in der Partnerfirma wird eine Enterprise Services-Zwischenanwendung verwendet, um Clientzertifikate abzurufen und an den Webdienst gerichtete Aufrufe vorzunehmen.

  • Das Verlagsunternehmen verwendet den im Zertifikat enthaltenen Namen der Partnerorganisation, um die Zertifikatszuordnung innerhalb von IIS durchzuführen.

  • Der Webdienst verwendet das zugeordnete Active Directory-Konto für die Autorisierung. Hierbei kommen PrincipalPermission-Forderungen und Rollenüberprüfungen in .NET zum Einsatz.

  • Durch die Windows-Authentifizierung bei SQL Server werden die Anmeldeinformationen nicht auf dem Webserver gespeichert sowie nicht über das interne Netzwerk an den SQL Server-Computer übermittelt. Wenn Sie mit der SQL-Authentifizierung arbeiten, muss die Verbindungszeichenfolge (bestehend aus Benutzername und Kennwort) sowohl in der Anwendung als auch bei der Übermittlung über das Netzwerk gesichert werden. Verwenden Sie DPAPI oder eine der in Modul 12, "Datenzugriffssicherheit", erläuterten Alternativstrategien für die sichere Speicherung, um Verbindungszeichenfolgen zu speichern und IPSec zum Schützen der Verbindungszeichenfolge (und vertraulicher Anwendungsdaten) bei der Übertragung zwischen Webdienst und Datenbank einzusetzen.

  • SSL zwischen Partnerfirmen und dem Webdienst schützt die über das Internet übermittelten Daten.

  • IPSec zwischen dem Webdienst und der Datenbank schützt die Daten bei der Übertragung an die bzw. von der Datenbank im Firmennetzwerk. In einigen Szenarios, in denen der Partner und der Verleger über ein privates Netzwerk kommunizieren, ist IPSec neben dem Sichern der Kommunikation möglicherweise auch für die Computerauthentifizierung zu verwenden.

Nachteile

  • Ein dupliziertes Windows-Konto auf dem Datenbankserver (ein Konto, das dem lokalen ASP.NET-Prozesskonto in IIS entspricht) führt zu höherem Verwaltungsaufwand. Kennwörter müssen regelmäßig manuell aktualisiert und synchronisiert werden.

  • Da die rollenbasierte Sicherheit in .NET auf der Windows-Gruppenmitgliedschaft basiert, setzt diese Lösung voraus, dass Windows-Gruppen korrekt in derjenigen Granularitätsebene eingerichtet werden, die den Kategorien von Benutzern (mit denselben Sicherheitsberechtigungen) entspricht, die auf die Anwendung zugreifen. In diesem Szenario müssen Active Directory-Konten Mitglied einer Partnergruppe sein.

Fragen & Antworten

  • Der Datenbank ist nicht bekannt, wer der ursprüngliche Aufrufer ist. Wie kann ich eine Überwachungsliste erstellen?
    Überwachen Sie die Aktivität des Endbenutzers (Partnerfirma) im Webdienst. Übermitteln Sie die Identität der Partnerfirma auf Anwendungsebene an die Datenbank. Verwenden Sie hierzu gespeicherte Prozedurparameter.
Verwandte Szenarios

Das Verlagsunternehmen stellt möglicherweise nicht vertrauliche Daten zur Verfügung, beispielsweise Softcopys von Zeitschriften, Zeitungen usw. In diesem Szenario kann der Verleger jedem Partner einen eindeutigen Benutzernamen und ein eindeutiges Kennwort zur Verfügung stellen, mit denen man eine Verbindung herstellen und die Daten vom Webdienst abrufen kann.

In diesem verwandten Szenario wird die Website des Verlegers zur Authentifizierung von Benutzern über die Standardauthentifizierung konfiguriert. Die Partneranwendung verwendet den Benutzernamen und das Kennwort, um die Anmeldeinformationen für den Webdienst-Proxy explizit festzulegen.

Weitere Informationen

Weitere Informationen zur Konfiguration von Webdienst-Proxys finden Sie in Modul 10, "Webdienstesicherheit".

 

Bereitstellen einer Webanwendung

In diesem Szenario gewährt das Verlagsunternehmen seinen Partnern exklusiven Zugriff auf ihre Anwendungen über das Internet und macht eine Partnerportalanwendung verfügbar, um Dienstleistungen anzubieten, Partnern aktuelle Produktinformationen zur Verfügung zu stellen, die Onlinezusammenarbeit zu ermöglichen usw. Dieses Szenario ist in Abbildung 6.3 dargestellt.

Szenario mit Partnerportal

Abbildung 6.3
Szenario mit Partnerportal

Szenariomerkmale

Dieses Szenario weist folgende Merkmale auf:

  • In der Webanwendung des Partners können Anmeldeinformationen entweder über eine Formularanmeldeseite oder über ein Anmeldedialogfeld eingegeben werden. Hierbei kommt in IIS die Standardauthentifizierung zum Einsatz.

  • Die Anmeldeinformationen werden anhand einer separaten Active Directory-Version innerhalb des Extranet-Perimeternetzwerks (auch als Demilitarized Zones (DMZ), also "demilitarisierte Zonen" oder überwachte Subnetze bezeichnet) geprüft. Diese Active Directory-Extranetversion befindet sich in einer separaten Gesamtstruktur, die eine eigene Vertrauensgrenze aufweist.

  • Der Zugriff auf die Datenbank erfolgt über eine einzelne vertrauenswürdige Verbindung, die der ASP.NET-Webanwendungs-Prozessidentität entspricht.

  • Die Autorisierung von Webanwendungen basiert entweder auf einem GenericPrincipal-Objekt (das im Rahmen der Prozesses für die Formularauthentifizierung erstellt wurde) oder auf einem WindowsPrincipal-Objekt (wenn die Standardauthentifizierung zum Einsatz kommt).

  • Die von der Webanwendung abgerufenen Daten sind vertraulich und müssen während der Übertragung (intern innerhalb des Verlagsunternehmens und extern bei der Übermittlung über das Internet) gesichert werden.

Sichern des Szenarios

Da die Daten, die zwischen den beiden Firmen über das Internet ausgetauscht werden, vertraulich sind, müssen sie bei der Übertragung durch SSL (Secure Socket Layer) gesichert werden.

Eine Firewall, die nur eingehende Verbindungen von den IP-Adressen von Extranetpartnerfirmen zulässt, verhindert, dass andere unbefugte Internetbenutzer Netzwerkverbindungen zum Webserver öffnen.

Tabelle 6.2: Sicherheitsmaßnahmen

Kategorie

Detail

Authentifizierung
  • Benutzer in Partnerfirmen werden über die Webanwendung authentifiziert. Hierbei kommt entweder die Standard- oder die Formularauthentifizierung durch die Active Directory-Extranetversion zum Einsatz.
  • In der Datenbank kommt die Windows-Authentifizierung zum Einsatz. Die Prozessidentität der ASP.NET-Webanwendung wird zum Verbindungsaufbau verwendet. Die Datenbank vertraut der Webanwendung.

Autorisierung
  • Die Webanwendung verwendet die rollenbasierte Autorisierung in .NET, um zu überprüfen, ob die authentifizierten Benutzer Mitglied einer Partnergruppe sind (die Benutzer werden durch ein GenericPrincipal-Objekt bzw. ein WindowsPrincipal-Objekt dargestellt, abhängig davon, ob die Formular- oder Standardauthentifizierung verwendet wird).

Sichere Kommunikation
  • SSL wird verwendet, um die Kommunikation zwischen dem Webbrowser des Partners und der Webanwendung des Verlegers zu sichern.
  • IPSec wird verwendet, um sämtliche Kommunikationsvorgänge zwischen der Webanwendung und der Datenbank zu sichern.

Das Ergebnis

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

Empfohlene Sicherheitskonfiguration für das Szenario mit Partnerportal

Abbildung 6.4
Empfohlene Sicherheitskonfiguration für das Szenario mit Partnerportal

Konfigurieren des Extranet-Webservers
IIS konfigurieren

Schritt

Weitere Informationen

Aktivieren Sie für die Formularauthentifizierung den anonymen Zugriff für das virtuelle Stammverzeichnis der Webanwendung
– oder –
Deaktivieren Sie für die Standardauthentifizierung den anonymen Zugriff und wählen Sie die Standardauthentifizierung aus

Active Directory konfigurieren (Extranet)

Schritt

Weitere Informationen

Active Directory-Konten zur Darstellung von Partnerbenutzern einrichten

Es wird eine separate Active Directory-Extranetversion verwendet. Diese befindet sich in ihrer eigenen Gesamtstruktur und ist vollkommen unabhängig von der Active Directory-Firmenversion.
ASP.NET konfigurieren

Schritt

Weitere Informationen

ASP.NET-Webanwendung zur Verwendung der Windows-Authentifizierung konfigurieren (für IIS-Standardauthentifizierung)
– oder –
ASP.NET zur Verwendung der Formularauthentifizierung konfigurieren

Web.config im virtuellen Stammverzeichnis des Webdienstes konfigurieren
Festlegen des <authentication>-Elements auf eine der beiden Möglichkeiten:

<authentication mode="Windows" />

    

  • or -
    • 



<authentication mode="Formulare" />

Kennwort des ASPNET-Kontos (das zur Ausführung von ASP.NET verwendet wird) auf ein bekanntes sicheres Kennwort zurücksetzen

Hierdurch können Sie ein doppeltes lokales Konto (mit demselben Benutzernamen und Kennwort) auf dem Datenbankserver erstellen. Dieser Schritt ist erforderlich, damit das ASPNET-Konto auf Netzwerk-Authentifizierungsanforderungen vom Datenbankserver antworten kann, wenn über die Windows-Authentifizierung eine Verbindung hergestellt wird.

Als Alternative kann in diesem Fall ein Domänenkonto mit minimalen Rechten verwendet werden (wenn die Windows-Authentifizierung durch die Firewall zulässig ist).

Weitere Informationen finden Sie unter "Prozessidentität für ASP.NET" in Modul 8, "ASP.NET-Sicherheit". Machine.config bearbeiten, in %windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG

Attribute für benutzerdefinierten Kontobenutzernamen und Kennwort für das <processModel>-Element festlegen

Standard

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

Wird zu

<!--
userName="registry:HKLM\SOFTWARE\YourSecureApp

processModel\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourSecureApp

processModel\ASPNET_SETREG,password" -->

Beachten Sie, dass das Dienstprogramm aspnet_setreg.exe zur Speicherung eines verschlüsselten Kennworts in der Registrierung verwendet wurde.

Konfigurieren von SQL Server

Schritt

Weitere Informationen

Windows-Konto auf dem Microsoft SQL Server™-Computer erstellen, das dem ASP.NET-Prozesskonto des Webdienstes entspricht (Standard: ASPNET)

Der Benutzername und das Kennwort müssen Ihrem ASP.NET-Prozesskonto entsprechen.

Dem Konto folgende Rechte zuweisen:
– Auf diesen Computer vom Netzwerk aus zugreifen
– Lokale Anmeldung verweigern
– Anmelden als Stapelverarbeitungsauftrag

SQL Server für Windows-Authentifizierung konfigurieren

SQL Server-Anmeldung für das ASPNET-Konto erstellen

Hiermit wird der Zugriff auf SQL Server ermöglicht.

Neuen Datenbankbenutzer erstellen und den Anmeldenamen dem Datenbankbenutzer zuordnen

Hiermit wird der Zugriff auf die angegebene Datenbank ermöglicht.

Neue benutzerdefinierte Datenbankrolle in der Datenbank erstellen und den Datenbankbenutzer in die Rolle einfügen

Datenbankberechtigungen für die Datenbankrolle einrichten

Minimale Rechte gewähren
Siehe Modul 12, "Datenzugriffssicherheit".
Konfigurieren sicherer Kommunikationsvorgänge

Schritt

Weitere Informationen

Website auf dem Webserver für SSL konfigurieren

Siehe "Vorgehensweise: Einrichten von SSL auf einem Webserver" in diesem Handbuch.

IPSec zwischen Webserver und Datenbankserver konfigurieren

Siehe "Vorgehensweise: Verwenden von IPSec zum Sichern der Kommunikation zwischen zwei Servern" in diesem Handbuch.

Analyse

  • ASP.NET wird auf dem Webserver als lokales Konto mit minimalen Rechten ausgeführt (standardmäßiges ASPNET-Konto).

  • SSL wird zwischen Browser und Webanwendung verwendet, um die Anmeldeinformationen der Formular- bzw. Standardauthentifizierung zu schützen (die Übermittlung erfolgt in beiden Fällen in Klartext, obwohl bei der Standardauthentifizierung die Base64-Verschlüsselung zum Einsatz kommt). SSL dient außerdem zum Schutz der von der Webanwendung zurückgegebenen anwendungsspezifischen Daten.

  • Bei der Formularauthentifizierung wird SSL für sämtliche Seiten (nicht nur die Anmeldeseite) verwendet, um den Authentifizierungs-Cookie zu schützen, der im Anschluss an die erstmalige Authentifizierung bei allen nachfolgenden Webanforderungen übermittelt wird.

  • Wenn SSL nur auf der ersten Anmeldeseite zur Verschlüsselung der Anmeldeinformationen verwendet wird, die zu Authentifizierungszwecken übermittelt werden, sollte sichergestellt werden, dass das Formularauthentifizierungsticket (Bestandteil des Cookies) geschützt ist, da es bei allen nachfolgenden Webanforderungen zwischen Client und Server übermittelt wird. Um das Formularauthentifizierungsticket zu verschlüsseln, konfigurieren Sie das protection-Attribut des <Formulare>-Elements gemäß nachfolgender Darstellung und verwenden die Verschlüsseln -Methode der FormsAuthentication-Klasse, um das Ticket zu verschlüsseln.

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

    Ü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".

  • Ebenso wird SSL bei der Standardauthentifizierung für sämtliche Seiten verwendet, da die Standardanmeldeinformationen bei allen Webseitenanforderungen übermittelt werden, nicht nur bei der ersten, bei der der Benutzer die Standardanmeldeinformationen angibt.

  • Für die Standardauthentifizierung erstellt ASP.NET automatisch ein WindowsPrincipal-Objekt, das für den authentifizierten Aufrufer steht, und verknüpft es mit der aktuellen Webanforderung (HttpContext.User), wo es durch die .NET-Autorisierung verwendet wird (einschließlich PrincipalPermission-Forderungen und .NET-Rollen).

  • Für die Formularauthentifizierung muss Code entwickelt werden, mit dem die angegebenen Anmeldeinformationen anhand Active Directory geprüft werden. Außerdem muss ein GenericPrincipal-Objekt erstellt werden, das den authentifizierten Benutzer darstellt.

  • Durch die Windows-Authentifizierung beim SQL Server werden die Anmeldeinformationen nicht auf dem Webserver gespeichert und nicht über das interne Netzwerk an den SQL Server-Computer übermittelt.

  • Durch IPSec zwischen dem Webdienst und der Datenbank werden die Daten bei der Übertragung an die bzw. von der Datenbank im Firmennetzwerk geschützt.

Nachteile

  • Die Verwendung eines duplizierten Windows-Kontos auf dem Datenbankserver (ein Konto, das dem lokalen ASP.NET-Prozesskonto in IIS entspricht) führt zu höherem Verwaltungsaufwand. Kennwörter müssen regelmäßig manuell aktualisiert und synchronisiert werden.

  • Bei der Standardauthentifizierung wird im Browser ein Popup-Dialogfeld eingeblendet. Um den Anmeldevorgang nahtloser zu gestalten, empfiehlt sich die Verwendung der Formularauthentifizierung.

Verwandte Szenarios

Keine Konnektivität zwischen Extranet und Firmennetzwerk

Um die Sicherheit zusätzlich zu erhöhen, kann die Extranetanwendung so eingerichtet werden, dass keine Konnektivität zurück zum Firmennetzwerk erforderlich ist. In diesem Szenario gilt Folgendes:

  • Eine separate SQL Server-Datenbank befindet sich im Extranet, die Replizierung von Daten erfolgt von der internen Datenbank in die Extranetdatenbank.

  • Router werden eingesetzt, um Verbindungen vom Extranet zum Firmennetzwerk zu unterbinden. Andere Verbindungen können über bestimmte hohe Ports hergestellt werden.

  • Verbindungen vom Firmennetzwerk zum Extranet sollten über einen dedizierten Server mit starken Überwachungs- und Protokollierungsfunktionen hergestellt werden. Bei diesem Server müssen sich Benutzer authentifizieren, bevor sie auf das Extranet zugreifen.

Weitere Informationen

 

Zusammenfassung

In diesem Kapitel wurde erläutert, wie zwei häufige Extranetanwendungsszenarios gesichert werden.

Intranet- und Internetanwendungsszenarios werden in Modul 5, "Intranetsicherheit", und Modul 7, "Internetsicherheit", erläutert.