Modul 5 – Intranetsicherheit:

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 Vorbereitung
 ASP.NET zu SQL Server
 ASP.NET über Enterprise Services zu SQL Server
 ASP.NET über Webdienste zu SQL Server
 ASP.NET über Remoting zu SQL Server
 Übermitteln des ursprünglichen Benutzers an die Datenbank
 Zusammenfassung

Modulübersicht

Die Sicherheit einer intranetbasierten Webanwendung ist keinesfalls zu vernachlässigen, auch wenn die Anwendung innerhalb der Grenzen eines gesteuerten Netzwerks ausgeführt wird und nur einer begrenzten Anzahl von Benutzern zur Verfügung steht. Die verschiedenen Personen und Abteilungen benötigen unterschiedliche Zugriffsebenen auf die Funktionen und Daten der Anwendung, und vertrauliche Daten müssen in jedem Fall bei der Übertragung gesichert werden. Hinzu kommt, dass die Sicherheitsarchitektur der Anwendung alle sicherheitsbezogenen Probleme kompensieren muss, die sich aus den vorhandenen infrastrukturellen und betrieblichen Merkmale des Intranets ergeben, in dem die Anwendung bereitgestellt werden soll.

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

Zielsetzung

Themenbereiche:

• Sichern Ihrer .NET-Intranetanwendung

• Einführung in die Sicherheitsrisiken und empfohlenen Lösungen in einer ASP.NET-Webanwendung zur Kommunikation mit SQL Server 2000 in den folgenden Szenarios:

  • Direkte Kommunikation

  • Verwenden von Enterprise Services als Zwischensystem

  • Verwenden von Webdiensten als Zwischensystem

  • Verwenden von .NET-Remoting als Zwischensystem

• Festlegen des optimalen Ansatzes zur Implementierung von Authentifizierung, Autorisierung und sicherer Kommunikation in einer intranetbasierten 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 und Active Directory 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 der Erstellung verteilter ASP.NET-Webanwendungen zum Einsatz kommen. Außerdem wird hervorgehoben, wo Aspekte hinsichtlich Authentifizierung, Autorisierung und sicherer Kommunikation in diese Architektur integriert werden können.

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

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

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

  • "Vorgehensweise: Erstellen einer DPAPI-Bibliothek"

  • "Vorgehensweise: Verwenden von DPAPI (Computerspeicher) von ASP.NET aus"

  • "Vorgehensweise: Verwenden von DPAPI (Benutzerspeicher) von ASP.NET aus mit Enterprise Services"

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

  • "Vorgehensweise: Einrichten von SSL auf einem Webserver"

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

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

Vorbereitung

Der Zugriff auf Intranetanwendungen ist auf eine begrenzte Gruppe autorisierter Benutzer beschränkt (wie z. B. Mitarbeiter, die zu einer Domäne gehören). Obwohl eine Intraneteinstellung die Offenlegung der Anwendung begrenzt, müssen Sie bei der Entwicklung von Strategien für Authentifizierung, Autorisierung und sichere Kommunikation mehrere Anforderungen berücksichtigen. Eventuell sind nicht vertrauenswürdige Domänen vorhanden, die die Übermittlung des Sicherheitskontexts und der Identität eines Benutzers an die Back-End-Ressource im System erschweren. Möglicherweise arbeiten Sie auch in einer heterogenen Umgebung mit verschiedenen Browsertypen, was die Verwendung eines allgemeinen Authentifizierungsmechanismus weiter erschwert.

In einem homogenen Intranet, in dem auf allen Computern das Betriebssystem Microsoft® Windows® 2000 oder höher installiert ist, und bei Existenz einer Domäne, in der den Benutzern im Hinblick auf eine Delegierung vertraut wird, stellt die Delegierung des Sicherheitskontexts des ursprünglichen Benutzers an das Back-End eine Möglichkeit dar.

Berücksichtigt werden muss auch die sichere Kommunikation. Trotz der Tatsache, dass die Anwendung in einer Intranetumgebung ausgeführt wird, können Sie die über das Netzwerk gesendeten Daten nicht als sicher betrachten. Wahrscheinlich müssen Sie zusätzlich zu den Daten, die zwischen den Anwendungsservern und den Datenbanken gesendet werden, auch die Daten sichern, die zwischen den Browsern und dem Webserver gesendet werden.

In diesem Modul werden die wesentlichen Techniken für Authentifizierung, Autorisierung und sichere Kommunikation anhand der folgenden Szenarien veranschaulicht:

• ASP.NET zu SQL Server

• ASP.NET über Enterprise Services zu SQL Server

• ASP.NET über Webdienste zu SQL Server

• ASP.NET über Remoting zu SQL Server

Zusätzlich wird in diesem Modul ein Windows 2000-Delegierungsszenario (Übermitteln des ursprünglichen Benutzers an die Datenbank) beschrieben, in dem der Sicherheitskontext und die Identität des ursprünglichen Benutzers auf Betriebssystemebene vom Browser über die dazwischen liegenden Web- und Anwendungsserver an die Datenbank übermittelt werden.

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 zu SQL Server

In diesem Szenario stellt eine Personaldatenbank in einem homogenen Intranet auf sichere Weise benutzerbezogene Daten bereit. Die Anwendung verwendet ein Modell mit vertrauenswürdigen Subsystemen und führt Aufrufe im Namen der ursprünglichen Benutzer aus. Die Anwendung authentifiziert die Benutzer mithilfe der integrierten Windows-Authentifizierung und ruft die Datenbank über die ASP.NET-Prozessidentität auf. Aufgrund der Vertraulichkeit der Daten wird zwischen dem Webserver und den Clients SSL verwendet.

Das Basismodell für dieses Anwendungsszenario ist in Abbildung 5.1 dargestellt.

Abbildung 5.1
ASP.NET zu SQL Server

Merkmale

Dieses Szenario weist folgende Merkmale auf:

• Die Clients verfügen über den Internet Explorer.

• Die Benutzerkonten befinden sich im Verzeichnisdienst Microsoft Active Directory®.

• Die Anwendung stellt vertrauliche, benutzerbezogene Daten bereit.

• Nur authentifizierte Clients dürfen auf die Anwendung zugreifen.

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

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

Sichern des Szenarios

In diesem Szenario authentifiziert der Webserver den Benutzer und beschränkt den Zugriff auf lokale Ressourcen anhand der Identität des Benutzers. In der Webanwendung muss kein Identitätswechsel durchgeführt werden, um den Ressourcenzugriff für den ursprünglichen Benutzer einzuschränken. 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 5.1: Sicherheitsmaßnahmen

Das Ergebnis

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

Abbildung 5.2
Empfohlene Sicherheitskonfiguration für das Intranetszenario "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 von IIS

Konfigurieren von ASP.NET

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

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

  <authentication mode="Windows" />

  <identity impersonate="false" />

Konfigurieren von SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• Für dieses Szenario ist die integrierte Windows-Authentifizierung in IIS optimal geeignet, da alle Benutzer über Windows-Konten verfügen und den Internet Explorer verwenden. Der Vorteil der integrierten Windows-Authentifizierung: Das Kennwort des Benutzers wird niemals über das Netzwerk gesendet. Die Anmeldung ist außerdem für den Benutzer transparent, da Windows die Anmeldesitzung des aktuellen interaktiven Benutzers verwendet.

• ASP.NET wird als Konto mit minimalen Rechten ausgeführt, die potenzielle Gefährdung einer Offenlegung wird also so gering als möglich gehalten.

• In ASP.NET müssen Sie für den ursprünglichen Benutzer keinen Identitätswechsel durchführen, um .NET-Rollenüberprüfungen zu starten oder die Ressourcen in Windows-ACLs zu sichern. Bei .NET-Rollenüberprüfungen für den ursprünglichen Benutzer wird das WindowsPrincipal -Objekt, das den ursprünglichen Benutzer repräsentiert, wie folgt aus dem HTTP-Kontext abgerufen:

    WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
    if ( wp.IsInRole("Manager") )
    {
      // Benutzer ist zur Durchführung managerspezifischer Funktionen berechtigt
    }
  

  Das FileAuthorizationModule von ASP.NET ermöglicht bei ASP.NET-Dateitypen, die in IIS aspnet_isapi.dll zugeordnet sind, ACL-Prüfungen für den ursprünglichen Benutzer. Bei statischen Dateitypen wie JPG-, GIF- und HTM-Dateien fungiert IIS als Gatekeeper und führt, basierend auf den mit der Datei verbundenen NTFS-Berechtigungen, anhand der Identität des ursprünglichen Benutzers Zugriffsüberprüfungen durch.

• Bei der Windows-Authentifizierung für SQL Server müssen die Anmeldeinformationen nicht in Dateien gespeichert und nicht über das Netzwerk an den Datenbankserver übertragen werden.

• Die Verwendung eines duplizierten Windows-Kontos auf dem Datenbankserver (das mit dem lokalen Konto ASPNET ü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 Szenarios besteht die Möglichkeit, den Verwaltungsaufwand mithilfe eines Domänenkontos mit minimalen Rechten zu reduzieren.

• Die Vorgehensweise mithilfe eines duplizierten lokalen Kontos ist auch bei Vorhandensein einer Firewall geeignet, wenn die für die Windows-Authentifizierung erforderlichen Ports nicht offen sind. Die Verwendung der Windows-Authentifizierung und von Domänenkonten ist in diesem Szenario nicht möglich.

• Sie müssen sicherstellen, dass Ihre Windows-Gruppen genauso fein abgestuft sind wie Ihre Sicherheitsanforderungen. Da die rollenbasierte Sicherheit in .NET auf der Windows-Gruppenmitgliedschaft basiert, ist es für diese Lösung erforderlich, dass Windows-Gruppen korrekt in derjenigen Granularitätsebene eingerichtet werden, die den Kategorien von Benutzern (mit denselben Sicherheitsberechtigungen) entspricht, die auf die Anwendung zugreifen. Die hier für die Verwaltung von Rollen verwendeten Windows-Gruppen können lokale Gruppen auf dem betreffenden Computer oder Domänengruppen sein.

• Benutzerrollen der SQL Server-Datenbank sind SQL Server-Anwendungsrollen vorzuziehen, um die mit SQL-Anwendungsrollen verbundenen Probleme bei der Kennwortverwaltung und dem Verbindungspooling zu vermeiden.
  Anwendungen aktivieren die SQL-Anwendungsrollen, indem sie mit einem Rollennamen und einem Kennwort eine integrierte gespeicherte Prozedur aufrufen. Das Kennwort muss daher sicher gespeichert werden. Das Datenbankverbindungspooling muss bei SQL-Anwendungsrollen ebenfalls deaktiviert werden, so dass die Skalierbarkeit der Anwendung erheblich beeinträchtigt wird.

  Weitere Informationen zu SQL Server-Datenbankbenutzerrollen und SQL Server-Anwendungsrollen finden Sie in Modul 12, "Datenzugriffssicherheit".

• Der Datenbankbenutzer wird zu einer Datenbankbenutzerrolle hinzugefügt. Der Rolle werden Berechtigungen zugewiesen, so dass bei Änderungen des Datenbankkontos nicht die Berechtigungen aller Datenbankobjekte geändert werden müssen.

Fragen & Antworten

• Warum kann für die Webanwendung kein Identitätswechsel aktiviert werden, damit die Ressourcen, auf die die Webanwendung zugreift, mit ACLs gesichert werden, die für den ursprünglichen Benutzer konfiguriert sind?
  Wenn Sie den Identitätswechsel aktivieren, enthält der Sicherheitskontext, dessen Identität gewechselt wurde, keine Netzwerkanmeldeinformationen (unter der Annahme, dass keine Delegierung aktiviert ist und die integrierte Windows-Authentifizierung verwendet wird). Der Remoteaufruf an den SQL Server verwendet daher eine NULL-Sitzung, sodass der Aufruf fehlschlägt. Bei deaktiviertem Identitätswechsel verwendet die Remoteanforderung die ASP.NET-Prozessidentität.

  Das obige Szenario verwendet das FileAuthorizationModule von ASP.NET, das bei Windows-ACLs die Identität des ursprünglichen Benutzers autorisiert und keinen Identitätswechsel erfordert.

  Wenn Sie anstelle der integrierten Windows-Authentifizierung (NTLM) die Standardauthentifizierung verwenden und keine Identitätswechsel aktivieren, wird bei jedem Aufruf der Datenbank der Sicherheitskontext des ursprünglichen Benutzers verwendet. Jedes Benutzerkonto (bzw. die Windows-Gruppen, zu denen der Benutzer gehört) würde SQL Server-Benutzernamen benötigen. Die Berechtigungen für Datenbankobjekte müssten gegenüber der Windows-Gruppe (bzw. dem ursprünglichen Benutzer) gesichert werden.

• Der Datenbank ist nicht bekannt, wer der ursprüngliche Benutzer ist. Wie kann ich eine Überwachungsliste erstellen?
  Überwachen Sie die Aktivität des Endbenutzers in der Webanwendung oder übergeben Sie die Identität des Benutzers explizit als Parameter des Aufrufs für den Datenzugriff.

Verwandte Szenarios

Andere Browser als Internet Explorer

Für die integrierte Windows-Authentifizierung bei IIS ist der Internet Explorer erforderlich. In einer Umgebung mit unterschiedlichen Browsertypen stehen normalerweise die folgenden Optionen zur Verfügung:

• Standardauthentifizierung und SSL. Die Standardauthentifizierung wird von den meisten Browsern unterstützt. Da die Anmeldeinformationen des Benutzers über das Netzwerk übertragen werden, muss das Szenario mit SSL gesichert werden.

• Clientzertifikate. Die einzelnen Clientzertifikate werden jeweils einem eindeutigen Windows-Konto zugeordnet, oder alle Clients werden mit einem einzigen Windows-Konto dargestellt. Clientzertifikate erfordern ebenfalls SSL.

• Formularauthentifizierung. Bei der Formularauthentifizierung überprüfen Sie die Anmeldeinformationen anhand eines benutzerdefinierten Datenspeichers, z. B. einer Datenbank, oder anhand der Active Directory.
  Bei einer Authentifizierung über die Active Directory müssen Sie sicherstellen, dass nur die erforderlichen Gruppen abgerufen werden, die zu der Anwendung gehören. Genauso, wie Sie Abfragen an eine Datenbank nicht mit SELECT *-Klauseln vornehmen sollten, sollten Sie nicht pauschal alle Gruppen der Active Directory abrufen.
  Bei der Authentifizierung anhand einer Datenbank müssen Sie die Eingabe, die in SQL-Befehlen verwendet wird, zum Schutz vor SQL Injection-Angriffen sorgfältig analysieren. Anstelle von unverschlüsselten oder verschlüsselten Kennwörtern sollten Sie Kennworthashes (mit Salt-Werten) in der Datenbank speichern.
  Weitere Informationen zur Verwendung von SQL Server als Speicher für Anmeldeinformationen und zum Speichern von Kennwörtern in der Datenbank finden Sie in Modul 12, "Datenzugriffssicherheit".

Beachten Sie, dass in allen Fällen letztlich SSL verwendet werden muss, wenn Sie nicht die integrierte Windows-Authentifizierung verwenden, bei der die Plattform die Anmeldeinformationen verwaltet. Dieser Vorteil betrifft jedoch ausschließlich den Authentifizierungsvorgang. Für die Übertragung sicherheitsrelevanter Daten über das Netzwerk müssen Sie weiterhin IPSec oder SSL verwenden.

SQL-Authentifizierung bei der Datenbank

In einigen Szenarios sind Sie gezwungen, die SQL-Authentifizierung anstelle der bevorzugten Windows-Authentifizierung zu verwenden. Möglicherweise befindet sich zwischen der Webanwendung und der Datenbank eine Firewall, oder der Webserver ist aus Sicherheitsgründen nicht Mitglied der Domäne. Dadurch wird ebenfalls eine Windows-Authentifizierung verhindert. In diesem Fall können Sie zwischen der Datenbank und dem Webserver die SQL-Authentifizierung verwenden. Um dieses Szenario zu sichern, sollten Sie folgendermaßen vorgehen:

• Verwenden der Data Protection API (DPAPI), um Datenbankverbindungszeichenfolgen zu sichern, die Benutzernamen und Kennwörter enthalten. Weitere Informationen hierzu finden Sie in den folgenden Ressourcen:

  • "" in Modul 12, "Datenzugriffssicherheit".

  • "Vorgehensweise: Verwenden von DPAPI (Computerspeicher) von ASP.NET aus" in diesem Handbuch

  • "Vorgehensweise: Verwenden von DPAPI (Benutzerspeicher) von ASP.NET aus mit Enterprise Services" in diesem Handbuch

  • "Vorgehensweise: Erstellen einer DPAPI-Bibliothek" in diesem Handbuch

• Verwenden von IPSec oder SSL zwischen Webserver und Datenbankserver, um die unverschlüsselten Anmeldeinformationen zu schützen, die über das Netzwerk übertragen werden.

Übermitteln des ursprünglichen Benutzers an die Datenbank

In diesem Szenario werden die Aufrufe von der Webanwendung an die Datenbank mit dem Sicherheitskontext des ursprünglichen Benutzers durchgeführt. Bei dieser Vorgehensweise ist Folgendes zu beachten:

• Wenn Sie sich für dieses Verfahren entscheiden, müssen Sie entweder die Kerberos-Authentifizierung (mit für die Delegierung konfigurierten Konten) oder die Standardauthentifizierung verwenden.
  Ein Delegierungsszenario wird weiter unten in diesem Modul im Abschnitt "Übermitteln des ursprünglichen Benutzers an die Datenbank" behandelt.

• Darüber hinaus müssen in ASP.NET Identitätswechsel aktiviert werden, damit der Zugriff auf lokale Systemressourcen mit dem Sicherheitskontext des ursprünglichen Benutzers erfolgt. Die ACLs für lokale Ressourcen wie Registrierung und Ereignisprotokoll müssen entsprechend konfiguriert werden.

• Das Datenbankverbindungspooling ist eingeschränkt, da die ursprünglichen Benutzer Verbindungen nicht gemeinsam nutzen können. Jeder Verbindung wird der Sicherheitskontext des Benutzers zugeordnet.

• Sie können den Sicherheitskontext des Benutzers auch übermitteln, indem Sie die Identität des ursprünglichen Benutzers auf Anwendungsebene übertragen (z. B. über Methodenparameter und Parameter von gespeicherten Prozeduren).

ASP.NET über Enterprise Services zu SQL Server

In diesem Szenario rufen ASP.NET-Seiten Unternehmenskomponenten auf, die in einer Enterprise Services-Anwendung enthalten sind, die wiederum mit einer Datenbank verbunden ist. Stellen Sie sich als Beispiel ein internes Bestellsystem vor, das Transaktionen über das Intranet durchführt und den internen Abteilungen Bestellungen ermöglicht. Dieses Szenario ist in Abbildung 5.3 dargestellt.

Abbildung 5.3
ASP.NET ruft eine Komponente in Enterprise Services auf, die ihrerseits die Datenbank aufruft

Merkmale

Dieses Szenario weist folgende Merkmale auf:

• Die Benutzer verfügen über den Internet Explorer.

• Die Komponenten werden auf dem Webserver bereitgestellt.

• Die Anwendung verarbeitet vertrauliche Daten, die bei der Übertragung gesichert werden müssen.

• Die Unternehmenskomponenten stellen über die Windows-Authentifizierung die Verbindung zu SQL Server her.

• Die Unternehmensfunktionalität in diesen Komponenten wird basierend auf der Identität des Benutzers beschränkt.

• Die Serviced Components sind als Serveranwendung (prozessextern) konfiguriert.

• Die Komponenten stellen die Verbindung zur Datenbank mit der Prozessidentität der Serveranwendung her.

• In ASP.NET sind Identitätswechsel aktiviert (um die rollenbasierte Sicherheit von Enterprise Services zu vereinfachen).

Sichern des Szenarios

In diesem Szenario authentifiziert der Webserver den ursprünglichen Benutzer und übermittelt den Sicherheitskontext des Benutzers an die Serviced Component. Die Serviced Component autorisiert den Zugriff auf die Unternehmensfunktionalität basierend auf der Identität des ursprünglichen Benutzers. Die Datenbankauthentifizierung erfolgt anhand der Prozessidentität der Enterprise Services-Anwendung (d. h. die Datenbank vertraut den Serviced Components in der Enterprise Services-Anwendung). Wenn die Serviced Component die Datenbank aufruft, wird die Identität des Benutzers auf Anwendungsebene (unter Verwendung vertrauenswürdiger Abfrageparameter) übergeben.

Tabelle 5.2: Sicherheitsmaßnahmen

Das Ergebnis

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

Abbildung 5.4
Empfohlene Sicherheitskonfiguration für das Intranetszenario "ASP.NET über lokale 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 von IIS

Konfigurieren von ASP.NET

  <authentication mode="Windows" />

  <identity impersonate="true" />

  <processModel
      comImpersonationLevel="Identität annehmen"

Konfigurieren von Enterprise Services

  [assembly:
  ApplicationActivation(ActivationOption.Server)]

Konfigurieren von SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• ASP.NET und Enterprise Services werden als Konten mit minimalen Rechten ausgeführt, die Gefahr einer Offenlegung wird also so gering wie möglich gehalten. Ist eine der beiden Prozessidentitäten offen, wird der Schaden durch die begrenzten Rechte des Kontos reduziert. Im Falle von ASP.NET wird auch der mögliche Schaden begrenzt, der durch die Einschleusung eines böswilligen Skripts entstehen kann.

• Die ASP.NET-Anwendung muss für Identitätswechsel konfiguriert werden, damit der Sicherheitskontext des ursprünglichen Benutzers an die Enterprise Services-Komponenten übermittelt wird (zur Unterstützung der Enterprise Services-(COM+-)Rollen-basierten Autorisierung). Wenn kein Identitätswechsel erfolgt, werden die Rollen anhand der Prozessidentität (des ASP.NET-Workerprozesses) überprüft. Der Identitätswechsel wirkt sich darauf aus, für welche Identität der Ressourcenzugriff autorisiert wird.
  Ohne Identitätswechsel werden die Systemressourcen anhand der ASP.NET-Prozessidentität überprüft. Mit Identitätswechsel werden die Systemressourcen anhand des ursprünglichen Benutzers überprüft. Weitere Informationen zum Zugriff auf Systemressourcen über ASP.NET finden Sie unter "Zugreifen auf Systemressourcen" in Modul 8, "ASP.NET-Sicherheit".

• Aufgrund der Enterprise Services-(COM+-)Rollen werden die Zugriffsüberprüfungen in die mittlere Ebene verlagert, auf der sich die Geschäftslogik befindet. In diesem Fall werden die Benutzer am Gate überprüft und den Rollen zugeordnet. Aufrufe der Geschäftslogik basieren dann auf den Rollen. Dadurch werden unnötige Aufrufe an das Back-End vermieden. Ein weiterer Vorteil von Enterprise Services-(COM+-)Rollen: Sie können die Rollen zum Zeitpunkt der Bereitstellung mit der Komponentendienstverwaltung erstellen und verwalten.

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

• Ein lokales Konto für die Ausführung der Enterprise Services-Anwendung zusammen mit einem duplizierten Konto auf dem Datenbankserver ist auch bei Existenz einer Firewall geeignet, wenn die für die Windows-Authentifizierung erforderlichen Ports nicht offen sind. Die Verwendung der Windows-Authentifizierung und von Domänenkonten ist in diesem Szenario nicht möglich.

Nachteile

• Ein dupliziertes Windows-Konto auf dem Datenbankserver (das mit dem Enterprise Services-Prozesskonto übereinstimmt) führt zu einem höheren Verwaltungsaufwand. Kennwörter sollten regelmäßig manuell aktualisiert und synchronisiert werden.

• Da die rollenbasierte Sicherheit in .NET auf der Windows-Gruppenmitgliedschaft basiert, müssen für diese Lösung die Windows-Gruppen so eingerichtet werden, dass sie exakt den Benutzerkategorien (mit denselben Sicherheitsberechtigungen) entsprechen, die auf die Anwendung zugreifen.

ASP.NET über Webdienste zu SQL Server

In diesem Szenario stellt ein Webserver, auf dem ASP.NET-Seiten ausgeführt werden, Verbindungen zu einem Webdienst auf einem Remoteserver her. Dieser Server wiederum stellt Verbindungen zu einem Remotedatenbankserver her. Nehmen Sie als Beispiel eine Personalwebanwendung, die vertrauliche benutzerbezogene Daten bereitstellt. Die Anwendung benötigt den Webdienst für den Abruf der Daten. Das Basismodell für dieses Anwendungsszenario ist in Abbildung 5.5 dargestellt.

Abbildung 5.5
ASP.NET über Remotewebdienst zu SQL Server

Der Webdienst stellt eine Methode bereit, über die ein einzelner Mitarbeiter seine persönlichen Daten abrufen kann. Auf die Daten dürfen über die Webanwendung nur authentifizierte Personen zugreifen. Der Webdienst bietet außerdem eine Methode, die den Abruf der Daten beliebiger Mitarbeiter unterstützt. Diese Funktionalität darf nur den Mitgliedern der Personal- oder Gehaltsabteilung zur Verfügung stehen. In diesem Szenario werden die Mitarbeiter in drei Windows-Gruppen kategorisiert:

• HRDept (Mitglieder der Personalabteilung)
  Die Mitglieder dieser Gruppe können Details zu allen Mitarbeitern abrufen.

• PayrollDept (Mitglieder der Gehaltsabteilung)
  Die Mitglieder dieser Gruppe können Details zu allen Mitarbeitern abrufen.

• Mitarbeiter (alle Mitarbeiter)
  Die Mitglieder dieser Gruppe können nur ihre eigenen Details abrufen.

Aufgrund der Vertraulichkeit der Daten muss der Datenverkehr zwischen allen Knoten gesichert werden.

Merkmale

• Die Benutzer verfügen über den Internet Explorer 5.x oder höher.

• Auf allen Computern ist Windows 2000 oder höher installiert.

• Die Benutzerkonten befinden sich in der Active Directory in einer einzigen Gesamtstruktur.

• Die Anwendung übermittelt den Sicherheitskontext des ursprünglichen Benutzers bis zur Datenbank.

• Auf allen Ebenen wird die Windows-Authentifizierung verwendet.

• Die Domänenbenutzerkonten sind für eine Delegierung konfiguriert.

• Die Datenbank unterstützt keine Delegierung.

Sichern des Szenarios

In diesem Szenario authentifiziert der Webserver, der als Host für die ASP.NET-Webanwendung fungiert, die Identität des ursprünglichen Benutzers und übermittelt dann den Sicherheitskontext an den Remoteserver, auf dem sich der Webdienst befindet. Dadurch sind Autorisierungsprüfungen für Webmethoden möglich, um dem ursprünglichen Benutzer den Zugriff zu gestatten oder zu verweigern. Die Datenbankauthentifizierung erfolgt anhand der Prozessidentität des Webdienstes (die Datenbank vertraut dem Webdienst). Der Webdienst wiederum ruft die Datenbank auf und übergibt auf Anwendungsebene die Identität des Benutzers über Parameter von gespeicherten Prozeduren.

Tabelle 5.3: Sicherheitsmaßnahmen

Das Ergebnis

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

Abbildung 5.6
Empfohlene Sicherheitskonfiguration für das Intranetszenario "ASP.NET über Webdienst zu SQL Server"

Schritte zum Konfigurieren der Sicherheit

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

• 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 (Host der Webanwendung)

  <authentication mode="Windows" />

  <identity impersonate="true" />

Konfigurieren des Anwendungsservers (Host des Webdienstes)

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

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

Konfigurieren von SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• Für dieses Szenario ist die integrierte Windows-Authentifizierung in IIS optimal geeignet, da alle Benutzer Windows 2000 oder höher sowie Internet Explorer 5.x oder höher verwenden und die Konten in Active Directory enthalten sind, sodass das Kerberos-Authentifizierungsprotokoll (das die Delegierung unterstützt) verwendet werden kann. Der Sicherheitskontext des Benutzers kann so über Computergrenzen hinweg übertragen werden.

• Die Konten der Endbenutzer dürfen in der Active Directory NICHT als "Konto ist vertraulich und kann nicht delegiert werden" gekennzeichnet werden. Das Konto für den Webservercomputer muss in der Active Directory als "Für Delegierungszwecke vertraut" gekennzeichnet werden. Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

• ASP.NET wird auf dem Webserver und dem Anwendungsserver als lokales Konto mit minimalen Rechten ausgeführt (das lokale Konto ASPNET).

• Webdienst und Webanwendung sind für die Windows-Authentifizierung konfiguriert. IIS ist auf beiden Computern für die integrierte Windows-Authentifizierung konfiguriert.

• Wenn der Webdienst von der Webanwendung aufgerufen wird, werden standardmäßig keine Anmeldeinformationen übergeben. Diese werden jedoch benötigt, um auf dem nachgeschalteten Webserver auf die Netzwerkauthentifizierungsabfrage zu reagieren, die von IIS ausgegeben wird. Dies muss explizit angegeben werden, indem die Anmeldeinformationen-Eigenschaft des Webdienstproxys wie folgt eingestellt wird:

    wsproxy.Credentials = CredentialCache.DefaultCredentials;
  

  Weitere Informationen zum Aufrufen von Webdiensten mit Anmeldeinformationen finden Sie in Modul 10, "Webdienstesicherheit".

• Die Webanwendung ist für Identitätswechsel konfiguriert. Daher wird bei Aufrufen der Webanwendung an den Webdienst der Sicherheitskontext des ursprünglichen Benutzers übergeben, sodass der Webdienst den ursprünglichen Benutzer authentifizieren (und autorisieren) kann.

• Die Benutzer werden im Webdienst mit .NET-Rollen autorisiert, die auf der Windows-Gruppe basieren, zu der die Benutzer gehören (HRDept, PayrollDept und Mitarbeiter). Die Mitglieder von HRDept und PayrollDept können Mitarbeiterdetails für alle Mitarbeiter abrufen, während die Mitglieder der Gruppe Mitarbeiter lediglich ihre eigenen Details abrufen können.
  Die Webmethoden können wie im folgenden Codebeispiel mit der PrincipalPermissionAttribute-Klasse erweitert werden, um eine bestimmte Rollenmitgliedschaft zu fordern. Beachten Sie, dass PrincipalPermission anstelle von PrincipalPermissionAttribute verwendet werden kann. Hierbei handelt es sich um ein allgemeines Feature aller .NET-Attributtypen.

    [WebMethod]
    [PrincipalPermission(SecurityAction.Demand,
                      Role=@"Domainname\HRDept)]
    public DataSet RetrieveEmployeeDetails()
    {
    }
  

  Das in dem obigen Code gezeigte Attribut legt fest, dass nur Mitglieder der Windows-Gruppe Domainname\HRDept die RetrieveEmployeeDetails-Methode aufrufen dürfen. Wenn ein Nichtmitglied versucht, die Methode aufzurufen, wird eine Sicherheitsausnahmebedingung ausgelöst.

• Die ASP.NET-Dateiautorisierung (in der Webanwendung und im Webdienst) führt für den Benutzer eine ACL-Prüfung für alle Dateitypen durch, die in der IIS-Metabasis den Dateityp zur Aspnet_isapi.dll zuordnen. Statische Dateitypen (wie JPG, GIF, HTM usw.), für die keine ISAPI-Zuordnung vorhanden ist, werden von IIS (ebenfalls anhand der ACL für die jeweilige Datei) geprüft.

• Da die Webanwendung für Identitätswechsel konfiguriert ist, müssen die Ressourcen, auf die die Anwendung selbst zugreift, mit einer ACL konfiguriert sein, die dem ursprünglichen Benutzer zumindest Lesezugriff gewährt.

• Der Webdienst führt keinen Identitätswechsel und keine Delegierung durch. Der Zugriff auf die lokalen Systemressourcen und die Datenbank erfolgt daher mit der ASP.NET-Prozessidentität. Alle Aufrufe werden folglich nur mit einem Prozesskonto durchgeführt. Dadurch wird Datenbankverbindungspooling ermöglicht. Wenn die Datenbank keine Delegierung unterstützt (wie z. B. SQL Server 7.0 oder früher), stellt dieses Szenario eine gute Alternative dar.

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

• Zwischen dem ursprünglichen Benutzer und dem Webserver schützt SSL die Daten, die zu und von der Webanwendung übertragen werden.

• Zwischen dem nachgeordneten Webserver und der Datenbank schützt IPSec die zu und von der Datenbank übertragenen Daten.

Nachteile

• Ein dupliziertes Windows-Konto auf dem Datenbankserver (das mit dem ASP.NET-Prozesskonto übereinstimmt) führt zu einem höheren Verwaltungsaufwand. Kennwörter sollten regelmäßig manuell aktualisiert und synchronisiert werden.
  Eine Alternative sind Domänenkonten mit minimalen Rechten. Weitere Informationen zum Auswählen einer ASP.NET-Prozessidentität finden Sie in Modul 8, "ASP.NET-Sicherheit".

• Da die rollenbasierte Sicherheit in .NET auf der Windows-Gruppenmitgliedschaft basiert, setzt diese Lösung voraus, dass Windows-Gruppen mit der Granularitätsstufe eingerichtet werden, die den Kategorien von Benutzern (mit denselben Sicherheitsberechtigungen) entspricht, die auf die Anwendung zugreifen.

• Da die Kerberos-Delegierung keinen Einschränkungen unterliegt, muss sorgfältig gesteuert werden, welche Anwendungsidentitäten auf dem Webserver ausgeführt werden. Um die Sicherheit zu erhöhen, können Sie den Gültigkeitsbereich des Domänenkontos begrenzen, indem Sie das Konto aus der Gruppe Domänenbenutzer entfernen und den Zugriff nur von den entsprechenden Computern aus zulassen. Weitere Informationen finden Sie im Whitepaper "Default Access Control Settings" (englischsprachig) auf der Microsoft Website unter https://technet.microsoft.com/windowsserver/2000/default.aspx.

Fragen & Antworten

Der Datenbank ist nicht bekannt, wer der ursprüngliche Benutzer ist. Wie kann ich eine Überwachungsliste erstellen?

Überwachen Sie die Aktivität des Endbenutzers im Webdienst oder übergeben Sie die Identität des Benutzers explizit als Parameter des Aufrufs für den Datenzugriff.

Verwandte Szenarios

Wenn Sie Verbindungen zu anderen Datenbanken als SQL Server herstellen müssen oder momentan die SQL-Authentifizierung verwenden, müssen Sie die Anmeldeinformationen des Datenbankkontos explizit in der Verbindungszeichenfolge übergeben. In diesem Fall müssen Sie sicherstellen, dass die Verbindungszeichenfolge sicher gespeichert wird.

Weitere Informationen finden Sie unter "Sicheres Speichern von Datenbank-Verbindungszeichenfolgen" in Modul 12, "Datenzugriffssicherheit".

ASP.NET über Remoting zu SQL Server

In diesem Szenario stellt ein Webserver, auf dem ASP.NET-Seiten ausgeführt werden, sichere Verbindungen zu einer Remotekomponente auf einem Remoteanwendungsserver her. Der Webserver kommuniziert mithilfe von .NET Remoting über den HTTP-Kanal mit der Komponente. Die Remotekomponente wird von ASP.NET gehostet (siehe Abbildung 5.7).

Abbildung 5.7
ASP.NET über Remoting mithilfe von .NET-Remoting zu SQL Server

Merkmale

• Die Benutzer verfügen über unterschiedliche Typen von Webbrowsern.

• Die Remotekomponente wird von ASP.NET gehostet.

• Die Webanwendung kommuniziert über den HTTP-Kanal mit der Remotekomponente.

• Die ASP.NET-Anwendung ruft die .NET-Remotekomponente auf und übergibt die Anmeldeinformationen des ursprünglichen Benutzers zur Authentifizierung. Die Anmeldeinformationen stehen aus der Standardauthentifizierung zur Verfügung.

• Die Daten sind vertraulich und müssen daher zwischen den Prozessen und Computern gesichert werden.

Sichern des Szenarios

In diesem Szenario authentifiziert der Webserver, der als Host für die ASP.NET-Webanwendung dient, die ursprünglichen Benutzer. Die Webanwendung kann die Anmeldeinformationen des Benutzers für die Authentifizierung (Benutzername und Kennwort) aus HTTP-Servervariablen abrufen. Diese Informationen können anschließend durch Konfigurieren des Proxys der Remotekomponente zum Herstellen der Verbindung zum Anwendungsserver verwendet werden, auf dem sich die Remotekomponente befindet. Die Datenbank nutzt die Windows-Authentifizierung zur Authentifizierung der ASP.NET-Prozessidentität (d. h. die Datenbank vertraut der Remotekomponente). Die Remotekomponente wiederum ruft die Datenbank auf und übergibt die Identität des Benutzers auf Anwendungsebene über Parameter von gespeicherten Prozeduren.

Tabelle 5.4: Sicherheitsmaßnahmen

Das Ergebnis

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

Abbildung 5.8
Empfohlene Sicherheitskonfiguration für das Intranetszenario "ASP.NET über Remotewebdienst 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 des Webservers

  <authentication mode="Windows" />

Konfigurieren des Anwendungsservers

  <authentication mode="Windows" />

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

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

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

processModel\ASPNET_SETREG,password" -->

<identity impersonate="false" />

Konfigurieren des SQL Server

Konfigurieren sicherer Kommunikationsvorgänge

Analyse

• ASP.NET wird auf dem Webserver und dem Anwendungsserver als lokales Konto mit minimalen Rechten ausgeführt. In beiden Fällen wird das Standardkonto ASPNET verwendet.
  Durch die Verwendung des lokalen Kontos ASPNET (dupliziert auf dem SQL Server-Computer) werden mögliche Sicherheitsrisiken weiter reduziert. Ein dupliziertes Windows-Konto auf dem Datenbankserver ermöglicht die Ausführung der Remotekomponente auf dem Anwendungsserver mit einem ASP.NET-Konto mit möglichst geringen Rechten.

• Durch die Standardauthentifizierung am Webserver kann die Webanwendung die Windows-Authentifizierungsanfrage des Anwendungsservers mit den Anmeldeinformationen des Benutzers beantworten.
  Um die Remotekomponente mit den Anmeldeinformationen des Benutzers aufzurufen, konfiguriert die Webanwendung den Proxy der Remotekomponente wie im folgenden Codefragment.

    string pwd = Request.ServerVariables["AUTH_PASSWORD"];
    string uid = Request.ServerVariables["AUTH_USER"];
    IDictionary channelProperties =
                        ChannelServices.GetChannelSinkProperties(proxy);
    NetworkCredential credentials;
    credentials = new NetworkCredential(uid, pwd);
    ObjRef objectReference = RemotingServices.Marshal(proxy);
    Uri objectUri = new Uri(objectReference.URI);
    CredentialCache credCache = new CredentialCache();
    credCache.Add(objectUri, "Aushandeln", credentials);
    channelProperties["Anmeldeinformationen"] = credCache;
    channelProperties["Vorauthentifizierung durchführen"] = true;
  

  Weitere Informationen zum Übertragen der Sicherheitsanmeldeinformationen an eine Remotekomponente finden Sie in Modul 11, ".NET Remoting-Sicherheit".

• In der ASP.NET-Webanwendung sind keine Identitätswechsel aktiviert, da der Remoteproxy über die Anmeldeinformationen des Benutzers, die aus der Standardauthentifizierung stammen, speziell konfiguriert ist. Alle anderen Ressourcen, auf die die Webanwendung zugreift, verwenden den Sicherheitskontext, der durch das ASP.NET-Prozesskonto bereitgestellt wird.

• Durch SSL zwischen dem Benutzer und dem Webserver werden die Daten geschützt, die zu und vom Webserver gesendet werden, sowie die Anmeldeinformationen der Standardauthentifizierung, die während des Authentifizierungsvorgangs unverschlüsselt übertragen werden.

• Die integrierte Windows-Authentifizierung am Anwendungsserver führt .NET-Rollenüberprüfungen für den ursprünglichen Benutzer durch. Die Rollen entsprechen Windows-Gruppen.

  Rollenbasierte Überprüfungen sind auch ohne Identitätswechsel möglich.

• Die ASP.NET-Dateiautorisierung führt für den Benutzer eine ACL-Prüfung für alle Dateitypen durch, die in der IIS-Metabasis der Aspnet_isapi.dll zuordnet sind. Die Zugriffsüberprüfungen für statische Dateien (die in IIS keiner ISAPI-Erweiterung zugeordnet sind) werden von IIS durchgeführt.

• Da auf dem Anwendungsserver keine Identitätswechsel aktiviert sind, erfolgt jeder Zugriff auf lokale oder Remoteressourcen durch die Remotekomponente im Sicherheitskontext von ASPNET. Die ACLs sollten entsprechend festgelegt werden.

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

Nachteile

• Die Verwendung eines duplizierten Windows-Kontos auf dem Datenbankserver (das mit dem ASP.NET-Prozesskonto übereinstimmt) führt zu einem höheren Verwaltungsaufwand. Kennwörter sollten regelmäßig manuell aktualisiert und synchronisiert werden.

• Da die rollenbasierte Sicherheit in .NET auf der Windows-Gruppenmitgliedschaft basiert, wird bei dieser Lösung vorausgesetzt, dass Windows-Gruppen mit der Granularitätsstufe eingerichtet werden, die den Kategorien von Benutzern (mit denselben Sicherheitsberechtigungen) entspricht, die auf die Anwendung zugreifen.

Verwandte Szenarios

Der Webserver verwendet Kerberos, um die Benutzer zu authentifizieren. Mithilfe der Kerberos-Delegierung wird der Sicherheitskontext des ursprünglichen Benutzers an die Remotekomponente auf dem Anwendungsserver übermittelt.

Bei dieser Vorgehensweise müssen alle Benutzerkonten für die Delegierung konfiguriert sein. Die Webanwendung muss auch für Identitätswechsel konfiguriert werden und die Standardanmeldeinformationen verwenden, um den Proxy der Remotekomponente zu konfigurieren. Dieses Verfahren wird unter "Übermitteln des ursprünglichen Benutzers" in Modul 11, ".NET Remoting-Sicherheit", näher erläutert.

Übermitteln des ursprünglichen Benutzers an die Datenbank

In den oben beschriebenen Szenarios wurde das Modell der vertrauenswürdigen Subsysteme verwendet. In allen Fällen vertraute die Datenbank dem Anwendungsserver bzw. dem Webserver dahin gehend, dass die Benutzer ordnungsgemäß authentifiziert und autorisiert wurden. Obwohl das Modell der vertrauenswürdigen Subsysteme viele Vorteile bietet, müssen Sie bei einigen Szenarios (möglicherweise aus Gründen einer Überwachung) eventuell das Modell mit Identitätswechsel/Delegierung verwenden und den Sicherheitskontext des ursprünglichen Benutzers über Computergrenzen hinweg zur Datenbank übertragen.

Häufig ist es aus folgenden Gründen erforderlich, den ursprünglichen Benutzer an die Datenbank zu übermitteln:

• Sie benötigen einen abgestuften Zugriff in der Datenbank, die Berechtigungen sind auf Objektebene eingeschränkt. Bestimmte Benutzer und Gruppen dürfen einzelne Objekte lesen, während andere in einzelne Objekte schreiben können.
  Dies steht im Widerspruch zur weniger stark abgestuften aufgabenorientierten Autorisierung, bei der die Lese- und Schreibeigenschaften für bestimmte Objekte durch die Rollenmitgliedschaft festgelegt sind.

• Unter Umständen empfiehlt es sich, die Überwachungsmöglichkeiten der Plattform zu nutzen, anstatt die Identität zu übertragen und die Überwachung auf Anwendungsebene durchzuführen.

Sollten Sie sich dennoch für ein Modell mit Identitätswechsel/Delegierung entscheiden (oder aufgrund von Unternehmenssicherheitsrichtlinien dazu gezwungen sein) und den Kontext des ursprünglichen Benutzers durch die Ebenen der Anwendung an das Back-End übermitteln, müssen Sie bei Ihrer Planung die Delegierung und den Netzwerkzugriff berücksichtigen (was bei mehreren Computern mit einem größeren Aufwand verbunden ist). Das Pooling gemeinsam genutzter Ressourcen (z. B. Datenbankverbindungen) stellt ebenfalls ein Kernproblem dar und kann die Skalierbarkeit der Anwendung erheblich reduzieren.

In diesem Abschnitt wird gezeigt, wie Sie Identitätswechsel/Delegierung für die beiden gebräuchlichsten Anwendungsszenarios implementieren:

• ASP.NET zu SQL Server

• ASP.NET über Enterprise Services zu SQL Server

Weitere Informationen zu den Modellen mit vertrauenswürdigen Subsystemen und Identitätswechsel/Delegierung sowie den damit verbundenen Vorteilen finden Sie in Modul 3, "Authentifizierung und Autorisierung".

ASP.NET zu SQL Server

In diesem Szenario werden die Aufrufe an die Datenbank mit dem Sicherheitskontext des ursprünglichen Benutzers durchgeführt. Zu den in diesem Abschnitt beschriebenen Authentifizierungsoptionen gehören die Standardauthentifizierung und die integrierte Windows-Authentifizierung. Ein Szenario mit Kerberos-Delegierung wird im Abschnitt "ASP.NET über Enterprise Services zu SQL Server" beschrieben.

Verwenden der Standardauthentifizierung im Webserver

Die folgenden Konfigurationseinstellungen für die Standardauthentifizierung ermöglichen die Übermittlung des ursprünglichen Benutzers bis zur Datenbank.

Tabelle 5.5: Sicherheitsmaßnahmen

Bei dieser Vorgehensweise sind die folgenden Punkte zu beachten:

• Bei der Standardauthentifizierung wird ein Popup-Dialogfeld angezeigt, in dem der Benutzer zur Eingabe der Anmeldeinformationen (Benutzername und Kennwort) aufgefordert wird.

• Die Datenbank muss den ursprünglichen Benutzer erkennen. Wenn sich Webserver und Datenbank in verschiedenen Domänen befinden, müssen geeignete Vertrauensbeziehungen aktiviert sein, um eine Authentifizierung des ursprünglichen Benutzers zu ermöglichen.

Verwenden der integrierten Windows-Authentifizierung im Webserver

Die integrierte Windows-Authentifizierung führt abhängig von der Konfiguration der Client- und Servercomputer zu einer NTLM- oder Kerberos-Authentifizierung.

Die NTLM-Authentifizierung unterstützt keine Delegierung. Daher kann der Sicherheitskontext des ursprünglichen Benutzers nicht vom Webserver an eine physisch entfernte Datenbank übermittelt werden. Der einzige Netzwerkhop, der bei der NTLM-Authentifizierung zulässig ist, wird zwischen Browser und Webserver benötigt. Wenn die NTLM-Authentifizierung verwendet werden soll, muss SQL Server auf dem Webserver installiert werden, was in der Regel nur bei sehr kleinen Intranetanwendungen sinnvoll ist.

ASP.NET über Enterprise Services zu SQL Server

In diesem Szenario rufen ASP.NET-Seiten Unternehmenskomponenten in einer Enterprise Services-Remoteanwendung auf, die wiederum mit einer Datenbank kommuniziert. Der Sicherheitskontext des ursprünglichen Benutzers wird vom Browser bis zur Datenbank übertragen. Dieses Szenario ist in Abbildung 5.9 dargestellt.

Abbildung 5.9
ASP.NET ruft eine Komponente in Enterprise Services auf, die ihrerseits die Datenbank aufruft

Merkmale

• Die Benutzer verfügen über Internet Explorer 5.x oder höher.

• Auf allen Computern wird Windows 2000 oder höher ausgeführt.

• Die Benutzerkonten befinden sich in der Active Directory in einer einzigen Gesamtstruktur.

• Die Anwendung übermittelt den Sicherheitskontext des ursprünglichen Benutzers (auf Betriebssystemebene) bis hin zur Datenbank.

• Auf allen Ebenen wird die Windows-Authentifizierung verwendet.

• Die Domänenbenutzerkonten sind für eine Delegierung konfiguriert. Das Konto, mit dem die Enterprise Services-Anwendung ausgeführt wird, muss in der Active Directory als Für Delegierungszwecke vertraut gekennzeichnet sein.

Sichern des Szenarios

In diesem Szenario authentifiziert der Webserver den Benutzer. Sie müssen dann ASP.NET für Identitätswechsel konfigurieren, damit der Sicherheitskontext des ursprünglichen Benutzers an die Enterprise Services-Remoteanwendung übermittelt wird. In der Enterprise Services-Anwendung muss der Komponentencode explizit die Identität des Benutzers wechseln (mit CoImpersonateClient), damit der Kontext des Benutzers an die Datenbank übermittelt wird.

Tabelle 5.6: Sicherheitsmaßnahmen

Das Ergebnis

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

Abbildung 5.10
ASP.NET ruft eine Komponente in Enterprise Services auf, die ihrerseits die Datenbank aufruft. Der Sicherheitskontext des ursprünglichen Benutzers wird an die Datenbank übermittelt.

Schritte zum Konfigurieren der Sicherheit

Bevor Sie beginnen, sollten Ihnen die folgenden Punkte im Zusammenhang mit der Konfiguration bewusst sein:

• Das Enterprise Services-Prozesskonto muss in Active Directory als Für Delegierungszwecke vertraut gekennzeichnet sein. Die Konten der Endbenutzer dürfen nicht als Konto ist vertraulich und kann nicht delegiert werden gekennzeichnet sein. Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

• Auf allen Computern ist Windows 2000 oder höher erforderlich. Dies gilt für die Clientcomputer (Browser) und alle Server.

• Alle Computer müssen sich in der Active Directory befinden und zu einer einzigen Gesamtstruktur gehören.

• Auf dem Anwendungsserver, auf dem sich die Enterprise Services befinden, muss Windows 2000 mit Service Pack 3 installiert sein.

• Wenn Sie den Internet Explorer 6.0 unter Windows 2000 verwenden, wird standardmäßig die NTLM-Authentifizierung anstelle der erforderlichen Kerberos-Authentifizierung verwendet. Informationen zum Aktivieren der Kerberos-Delegierung finden Sie im Artikel Q299838, "Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6" (englischsprachig), in der Microsoft Knowledge Base.

  <authentication mode="Windows" />

  <identity impersonate="false" />

<processModel comImpersonationLevel="Delegieren"

<processModel
comAuthenticationLevel="PktPrivacy"

class COMSec
{
[DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
public static extern long CoImpersonateClient();
[DllImport("OLE32.DLL", CharSet=CharSet.Auto)]
public static extern long CoRevertToSelf();
}

COMSec.CoImpersonateClient();
COMSec.CoRevertToSelf();

[assembly:
ApplicationActivation(ActivationOption.Server)]

[assembly: ApplicationAccessControl(
Authentication =
AuthenticationOption.Privacy)]

 [assembly:
ApplicationAccessControl(AccessChecksLevel=
AccessChecksLevelOption. ApplicationComponent)]

 [ComponentAccessControl(true)]

Analyse

• Der Schlüssel für die Übermittlung des Sicherheitskontexts des ursprünglichen Benutzers liegt in der Kerberos-Authentifizierung, die ein Token auf der Ebene Delegieren erzeugt. Nachdem der Serverprozess (IIS) das Token auf der Ebene Delegieren empfangen hat, kann es an andere Prozesse übergeben werden, die auf demselben Computer unter einem beliebigen Konto ausgeführt werden, ohne dass die Delegierungsebene geändert wird. Dabei spielt es keine Rolle, ob der Prozess als lokales Konto oder als Domänenkonto ausgeführt wird. Es ist jedoch von Bedeutung, unter welchem Konto IIS ausgeführt wird. Wenn IIS unter einem anderen Konto als LocalSystem ausgeführt wird, muss das betreffende Konto in der Active Directory als Für Delegierungszwecke vertraut gekennzeichnet sein.
  Wird IIS als LocalSystem ausgeführt, muss das Computerkonto als Für Delegierungszwecke vertraut gekennzeichnet werden. Weitere Informationen finden Sie unter "Vorgehensweise: Implementieren der Kerberos-Delegierung unter Windows 2000" in diesem Handbuch.

• Für dieses Szenario ist die integrierte Windows-Authentifizierung (mit Kerberos) in IIS optimal geeignet, da alle Benutzer über Windows-Konten verfügen und den Internet Explorer 5.x oder höher verwenden. Der Vorteil der integrierten Windows-Authentifizierung: Sie sendet das Kennwort des Benutzers niemals über das Netzwerk. Die Anmeldung ist außerdem transparent, da Windows die Anmeldesitzung des aktuellen interaktiven Benutzers verwendet.

• ASP.NET erstellt ein WindowsPrincipal-Objekt und verbindet es mit dem Kontext der aktuellen Webanforderung (HttpContext.User). Wenn Sie in der Webanwendung Autorisierungsprüfungen durchführen müssen, können Sie dafür den folgenden Code verwenden:

    WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
    if ( wp.IsInRole("Manager") )
    {
      // Benutzer ist zur Durchführung managerspezifischer Funktionen berechtigt
    }
  

  Das FileAuthorizationModule von ASP.NET führt bei ASP.NET-Dateitypen, die in IIS zur aspnet_isapi.dll zugeordnet sind, ACL-Prüfungen für den ursprünglichen Benutzer durch. Bei statischen Dateitypen wie JPG-, GIF- und HTM-Dateien fungiert IIS als Gatekeeper und führt anhand der Identität des ursprünglichen Benutzers Zugriffsüberprüfungen durch.

• Die Verwendung der Windows-Authentifizierung für SQL bedeutet, dass keine Anmeldeinformationen in Dateien auf dem Anwendungsserver gespeichert und über das Netzwerk übertragen werden müssen. Fügen Sie beispielsweise das Trusted_Connection-Attribut in die Verbindungszeichenfolge ein:

    ConStr="server=YourServer; database=yourdatabase; Trusted_Connection=Yes;"
  

• Der Kontext des ursprünglichen Benutzers wird über alle Ebenen übertragen, wodurch eine Überwachung erheblich vereinfacht wird. Sie können eine Überwachung auf Plattformebene verwenden (z. B. die von Windows und SQL Server bereitgestellten Überwachungsfeatures).

Nachteile

• Wenn Sie den Internet Explorer 6.0 unter Windows 2000 verwenden, wird standardmäßig der Authentifizierungsmechanismus NTLM (und nicht Kerberos) eingesetzt. Weitere Informationen finden Sie im Artikel Q299838, "Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6" (englischsprachig), in der Microsoft Knowledge Base.

• Das Delegieren von Benutzern über die Ebenen hinweg beeinträchtigt die Systemleistung und die Skalierbarkeit der Anwendung. Sie können die Vorteile eines Verbindungspoolings zur Datenbank nicht nutzen, da Verbindungen zur Datenbank an den Sicherheitskontext des ursprünglichen Benutzers gebunden sind und daher nicht effizient gepoolt werden können.

• Diese Vorgehensweise hängt auch davon ab, wie genau die Windows-Gruppen auf die Sicherheitsanforderungen der Anwendung abgestimmt sind. Die Windows-Gruppen müssen so eingerichtet werden, dass sie exakt den Benutzerkategorien (Benutzer mit den gleichen Sicherheitsrechten) entsprechen, die auf die Anwendung zugreifen.

Zusammenfassung

In diesem Modul wurde beschrieben, wie mehrere gängige Intranetanwendungsszenarios gesichert werden.

Informationen zu Extranet- und Internetanwendungsszenarios finden Sie in Modul 6, "Extranetsicherheit", und Modul 7, "Internetsicherheit".