Planung Schritt 4: Planen der Anwendungssicherheit

von Keith Newman und Robert McMurray

Überlegen Sie sich in dieser Phase der Erstellung Ihrer Website, welche Sicherheitsanforderungen Ihre ASP.NET-Anwendung erfordert. In den folgenden Abschnitten werden die in IIS 8 verfügbaren Anwendungssicherheitseinstellungen beschrieben:

4.1. Isolieren von Webanwendungen

Eine der effektivsten Möglichkeiten zur Verbesserung der Sicherheit für Ihre Webanwendung ist es, sie von anderen Anwendungen auf Ihrem Webserver zu isolieren. Ein Anwendungspool verfügt über einen eigenen Arbeitsprozess, der Anforderungen verarbeitet und Anwendungscode ausführt. Der Arbeitsprozess hat eine Sicherheits-ID (SID). Jeder Anwendungspool verfügt über eine eindeutige Identität. Beim Erstellen einer Webanwendung wird standardmäßig auch ein neuer Anwendungspool mit dem Namen der Anwendung erstellt. Wenn Sie Webanwendungen in separaten Anwendungspools lassen, können Sie sie voneinander isolieren.

Das Isolieren von Webanwendungen umfasst Folgendes:

• Website-Isolation: Teilen Sie unterschiedliche Anwendungen auf verschiedene Websites mit verschiedenen Anwendungspools auf.
• Geringste Rechte: Führen Sie den Arbeitsprozess als Identität mit geringen Privilegien (virtuelle Anwendungspoolidentität) aus, die für jede Website eindeutig ist.
• Vorübergehende Isolation: Richten Sie für jede Site einen separaten temporären ASP.NET-Ordner ein, und gewähren Sie nur Zugriff auf die entsprechende Prozess-ID.
• Isolation von Inhalten: Stellen Sie sicher, dass eine Zugriffssteuerungsliste (Access Control List) für jedes Stammverzeichnis festgelegt ist, die nur Zugriff auf die entsprechende Prozess-ID gewährt.

4.2. .NET-Vertrauensebenen

Eine Vertrauensebene einer Anwendung bestimmt die Berechtigungen, die die Richtlinie für die Codezugriffssicherheit (CAS) für ASP.NET gewährt. CAS definiert zwei Vertrauenskategorien: vollständige und teilweise Vertrauenswürdigkeit. Eine Anwendung, die über volle Vertrauenswürdigkeit verfügt, kann auf alle Ressourcentypen auf einem Server zugreifen und privilegierte Vorgänge ausführen. Anwendungen mit voller Vertrauenswürdigkeit sind nur durch die Sicherheitseinstellungen des Betriebssystems betroffen.

Teilweise vertrauenswürdige Webanwendungen sind Anwendungen, die nicht die volle Vertrauenswürdigkeit haben und über eingeschränkte Berechtigungen zum Codezugriff verfügen. Daher sind teilweise vertrauenswürdige Anwendungen in ihrer Fähigkeit beschränkt, auf geschützte Ressourcen zuzugreifen und andere privilegierte Vorgänge auszuführen. Bestimmte Berechtigungen werden teilweise vertrauenswürdigen Anwendungen verweigert, damit auf Ressourcen, die diese Berechtigungen erfordern, nicht direkt zugegriffen werden kann. Andere Berechtigungen werden auf eingeschränkte Weise gewährt, damit auf Ressourcen, die diese Berechtigungen erfordern, nur auf eingeschränkte Weise zugegriffen werden kann. Beispielsweise ermöglicht es die beschränkte Datei-E/A-Berechtigung der Anwendung, auf das Dateisystem zuzugreifen, aber nur auf Verzeichnisse unterhalb des virtuellen Verzeichnisstamms der Anwendung.

Durch Konfigurieren einer Webanwendung oder eines Webdienstes für teilweise Vertrauenswürdigkeit können Sie den Zugriff der Anwendung auf wichtige Systemressourcen oder Ressourcen, die zu anderen Webanwendungen gehören, einschränken. Indem Sie nur Berechtigungen erteilen, die für die Anwendung erforderlich sind, können Sie Webanwendungen mit einem Minimum an Privilegien erstellen und potenzielle Schäden eingrenzen, wenn die Sicherheit durch einen Angriff durch Codeinjektion in die Anwendung gefährdet ist.

Die folgende Liste enthält die mit jeder Vertrauensebene verbundenen Einschränkungen:

• Die Anwendungen mit der vollen Vertrauensstellung haben uneingeschränkten Zugriff auf alle Ressourcentypen und können privilegierte Vorgänge ausführen.
• Anwendungen mit hoher, mittlerer, niedriger oder minimaler Vertrauensstellung sind nicht in der Lage, nicht verwalteten Code oder verarbeitete Komponenten aufzurufen, in das Ereignisprotokoll zu schreiben sowie auf Message Queuing-Warteschlangen oder OLE DB-Datenquellen zuzugreifen.
• Anwendungen mit hoher Vertrauensstellung haben uneingeschränkten Zugriff auf das Dateisystem.
• Anwendungen mit mittlerer Vertrauensstellung haben eingeschränkten Zugriff auf das Dateisystem und können nur auf Dateien in der Hierarchie ihres eigenen Verzeichnisses zugreifen.
• Anwendungen mit niedriger oder minimaler Vertrauensstellung können nicht auf SQL Server-Datenbanken zugreifen.
• Anwendungen mit minimaler Vertrauensstellung können nicht auf Ressourcen zugreifen.

4.3. .NET-Authentifizierung

Mithilfe der Authentifizierung können Sie die Identität von Clients überprüfen, die Zugriff auf Ihre Sites und Anwendungen anfordern. Wenn die Authentifizierung aktiviert ist, verwendet IIS 8 die vom Benutzer bereitgestellten Anmeldeinformationen, um zu bestimmen, welche Berechtigungen dem Benutzer erteilt wurden und auf welche Ressourcen er zugreifen kann.

Dieser Abschnitt beschreibt die Authentifizierungsmodi, die spezifisch für ASP.NET-Anwendungen sind.

1. ASP.NET-Formularauthentifizierung
2. ASP.NET-Identitätswechselauthentifizierung

ASP.NET-Formularauthentifizierung

Bei der Formularauthentifizierung wird eine clientseitige Umleitung für die Weiterleitung nicht authentifizierter Benutzer zu einem HTML-Formular verwendet, in dem sie ihre Anmeldeinformationen eingeben können, die i. d. R. aus einem Benutzernamen und einem Kennwort bestehen. Nach dem Überprüfen der Anmeldeinformationen werden die Benutzer auf die Seite umgeleitet, die sie ursprünglich angefordert hatten. Die Formularauthentifizierung setzt häufig Cookies ein, um Benutzeranmeldeinformationen zwischen dem Server und dem Clientbrowser zu übermitteln.

In den folgenden Abschnitten wird beschrieben, was Sie wissen müssen, um das Hinzufügen von Formularauthentifizierung zu Ihrer Site zu planen:

1. Grundlagen der Formularauthentifizierung
2. Authentifizierungscookies

Grundlagen der Formularauthentifizierung

Die formularbasierte Authentifizierung in ASP.NET eignet sich für Sites oder Anwendungen auf öffentlichen Webservern, die viele Anforderungen empfangen. Mit diesem Authentifizierungsmodus können Sie die Registrierung und Authentifizierung eines Clients auf Anwendungsebene verwalten, anstatt sich auf die Authentifizierungsmechanismen des Betriebssystems zu verlassen.

Die Formularauthentifizierung ermöglicht es dem Benutzer, sich mit den Identitäten aus einer ASP.NET-Mitgliedschaftsdatenbank anzumelden. Diese Authentifizierungsmethode verwendet die Umleitung zu einer HTML-Anmeldeseite, um die Identität des Benutzers zu bestätigen. Sie können die Formularauthentifizierung auf der Site- oder Anwendungsebene konfigurieren.

Die Formularauthentifizierung eignet sich aus folgenden Gründen:

• Sie können entweder einen benutzerdefinierten Datenspeicher, z. B. eine SQL Server-Datenbank, oder Active Directory für die Authentifizierung verwenden.
• Es kann problemlos in eine Web-Benutzeroberfläche integriert werden.
• Clients können einen beliebigen Browser verwenden.

Wenn Sie Mitgliedschaftsrollen für die Autorisierung verwenden möchten, verwenden Sie Formularauthentifizierung oder eine ähnliche benutzerdefinierte Authentifizierungsmethode.

Die standardmäßige Anmelde-URL für die Formularauthentifizierung ist Login.aspx. Sie können eine eindeutige Anmeldeseite für Clients erstellen, die eine Site oder Anwendung besuchen. So können Sie beispielsweise bestimmte Informationen von Besuchern sammeln oder eine Mitgliedschaft bei ausgewählten Seiten der Site oder ausgewählten Anwendungen anbieten.

Der Timeout-Standardwert für die Formularauthentifizierung ist 30 Minuten. Erwägen Sie, den Timeoutwert zu verringern, um die Gültigkeitsdauer der Sitzung zu verkürzen und Cookie-Replay-Angriffe zu vermeiden.

Authentifizierungscookies

Authentifizierungscookies werden als Token verwendet, um sicherzustellen, dass ein Client Zugriff auf einige oder alle Seiten einer Anwendung hat. Im Gegensatz dazu enthalten Personalisierungscookies benutzerspezifische Einstellungen, die die Benutzererfahrung auf einer bestimmten Site oder Anwendung bestimmen.

Wichtig: Da in Verbindung mit jeder Anforderung Authentifizierungscookies zwischen Client und Server übergeben werden, verwenden Sie immer sichere Authentifizierungscookies mit Secure Sockets Layer (SSL). Weitere Informationen zu SSL finden Sie unter 4.5. TLS/SSL-Kommunikation.

Cookies sind eine effizientere Methode als Abfragezeichenfolgen, Sitebesuchern zu folgen, da sie keine Umleitung erfordern. Sie sind allerdings browserabhängig und ihre Verwendung wird von einigen Browsern nicht unterstützt. Darüber hinaus ist die Verwendung von cookiebasierender Authentifizierung nicht immer sinnvoll, da einige Benutzer die Unterstützung von Cookies in ihrem Browser deaktivieren.

Standardmäßig ist der Name des Cookies für ASP.NET-Anwendungen .ASPXAUTH. Sie können stattdessen einen eindeutigen Cookienamen und -Pfad für jede Anwendung verwenden. Auf diese Weise können Sie verhindern, dass Benutzer, die für eine Anwendung authentifiziert sind, für andere Anwendungen auf einem Webserver authentifiziert werden.

Sie können einen der folgenden Cookiemodi für Ihre Site oder Anwendung auswählen:

Der Cookie-Schutzmodus definiert die Funktion, die ein Formularauthentifizierungs-Cookie für eine bestimmte Anwendung ausführt. Die folgende Tabelle zeigt die Cookie-Schutzmodi, die Sie definieren können:

Wenn eine Anwendung Objekte enthält, die häufig durch die Clients angefordert werden, verbessern Sie die Leistung der Anwendung durch Zwischenspeichern dieser Objekte. Wenn der Benutzer vor dem Timeout des Authentifizierungscookies auf das zwischengespeicherte Objekt zugreift, ermöglicht es IIS 8, dass das zwischengespeicherte Objekt im Cache bleibt, und der Zeitgeber wird zurückgesetzt. Wenn der Benutzer jedoch während dieser Zeit nicht auf das zwischengespeicherte Objekt zugreift, entfernt IIS 8 das zwischengespeicherte Objekt aus dem Cache.

Ziehen Sie diese Einstellung in den folgenden Situationen in Betracht:

• Sie haben eine begrenzte Menge an Arbeitsspeicher zum Zwischenspeichern.
• Sie haben viele Objekte für den Cache, denn diese Einstellung lässt nur die am häufigsten angeforderten Objekte im Cache.

ASP.NET-Identitätswechselauthentifizierung

Verwenden Sie ASP.NET-Identitätswechsel, wenn Sie die ASP.NET-Anwendung in einem anderen als dem standardmäßigen Sicherheitskontext für ASP.NET-Anwendungen ausführen möchten.

Wenn Sie Identitätswechsel für eine ASP.NET-Anwendung aktivieren, kann diese in einem von zwei unterschiedlichen Kontexten ausgeführt werden: entweder als der von IIS 8 authentifizierte Benutzer oder als ein beliebiges von Ihnen eingerichtetes Konto. Wenn Sie z. B. die anonyme Authentifizierung verwenden und die ASP.NET-Anwendung als authentifizierter Benutzer ausführen, würde die Anwendung unter einem Konto ausgeführt werden, das für anonyme Benutzer (normalerweise IUSR) festgelegt ist. Wenn Sie die Anwendung unter einem beliebigen Konto ausführen möchten, wird sie entsprechend unter dem für das Konto festgelegten Sicherheitskontext ausgeführt.

ASP.NET-Identitätswechsel ist standardmäßig deaktiviert. Wenn Sie den Identitätswechsel aktivieren, wird die ASP.NET-Anwendung im Sicherheitskontext des durch IIS 8 authentifizierten Benutzers ausgeführt.

4.4. Computerschlüsseleinstellungen

Computerschlüssel schützen Cookiedaten der Formularauthentifizierung und Ansichtsstatusdaten auf Seitenebene. Sie überprüfen auch die Statusidentifizierung von Out-of-Process-Sitzungen. ASP.NET verwendet die folgenden Typen von Computerschlüsseln:

• Ein Validierungsschlüssel berechnet einen Message Authentication Code (MAC), um die Integrität der Daten zu überprüfen. Dieser Schlüssel wird dem Cookie zur Formularauthentifizierung oder dem Ansichtsstatus für eine bestimmte Seite angefügt.
• Ein Entschlüsselungsschlüssel dient zum Ver- und Entschlüsseln von Formularauthentifizierungstickets und des Ansichtsstatus.

IIS 8 ermöglicht das Konfigurieren der Einstellungen für die Überprüfung und Verschlüsselung und das Generieren von Computerschlüsseln zur Verwendung mit ASP.NET-Anwendungsdiensten wie Ansichtsstatus, Formularauthentifizierung, Mitgliedschaft, Rollen und anonyme Identifikation.

Treffen Sie vor dem Generieren der Computerschlüssel für die Anwendung die folgenden Entwurfsentscheidungen:

• Entscheiden Sie, welche Überprüfungsmethode Sie verwenden möchten: AES, MD5, SHA1 (Standard), TripleDES, HMACSHA256, HMACSHA384 oder HMACSHA512.
• Entscheiden Sie, welche Verschlüsselungsmethode Sie verwenden möchten: Automatisch (Standardeinstellung), AES, TripleDES oder DES.
• Entscheiden Sie, ob der Schlüssel für die Überprüfung automatisch zur Laufzeit generiert werden soll.
• Entscheiden Sie, ob für jede Anwendung ein eindeutiger Validierungsschlüssel generiert werden soll.
• Entscheiden Sie, ob der Schlüssel für die Entschlüsselung automatisch zur Laufzeit generiert werden soll.
• Entscheiden Sie, ob für jede Anwendung ein eindeutiger Entschlüsselungsschlüssel generiert werden soll.

4.5. TLS/SSL-Kommunikation

Transport Layer Security (TLS) und der Vorgänger Secure Sockets Layer (SSL) sind Protokolle, die Kommunikationssicherheit für Ihre Website bereitstellen. Sie können TLS/SSL zur Authentifizierung von Servern und Clients verwenden und damit anschließend Nachrichten zwischen den authentifizierten Parteien verschlüsseln.

Im Zuge der Authentifizierung sendet ein TLS/SSL-Client eine Nachricht an einen TLS/SSL-Server, der daraufhin mit den für die Serverauthentifizierung erforderlichen Informationen antwortet. Client und Server tauschen zusätzlich Sitzungsschlüssel aus, und der Authentifizierungsdialog wird beendet. Nach Abschluss der Authentifizierung kann die SSL-gesicherte Kommunikation zwischen dem Server und dem Client mithilfe der symmetrischen Verschlüsselungsschlüssel, die während des Authentifizierungsprozesses eingerichtet werden, beginnen.

Führen Sie folgende Schritte aus, um TSL/SSL für Ihre Website zu konfigurieren:

1. Fordern Sie ein Zertifikat von einer Zertifizierungsstelle (CA) an. Siehe Serverzertifikate.
2. Fügen Sie SSL-Bindung zur Site hinzu. Siehe SSL-Bindung.
3. Legen Sie IIS so fest, dass SSL auf der Site erforderlich ist. Siehe SSL für Ihre Site erforderlich machen.
4. Ziehen Sie die Verwendung von Clientzertifikaten für Ihre Site in Betracht. Siehe Clientzertifikate.

Serverzertifikate

Sie können ein Serverzertifikat von einer Zertifizierungsstelle (CA) abrufen. Das Anfordern eines Serverzertifikats von einer Zertifizierungsstelle ist ein Schritt bei der Konfiguration von Secure Sockets Layer (SSL) oder Transport Layer Security (TLS). Sie können Zertifikate von einer Drittanbieter-Zertifizierungsstelle abrufen. Eine Drittanbieter-Zertifizierungsstelle fordert von Ihnen möglicherweise einen Identitätsnachweis, bevor das Zertifikat ausgegeben wird. Mit einer Online-CA wie z. B. Microsoft Certificate Services können Sie Serverzertifikate auch selbst ausstellen.

Digitale Zertifikate sind elektronische Dateien, die wie ein Online-Kennwort zum Überprüfen der Identität eines Benutzers oder Computers funktionieren. Sie dienen dazu, den SSL-verschlüsselten Kanal zu erstellen, der für die Clientkommunikation verwendet wird. Ein Zertifikat ist eine digitale Anweisung, die von einer Zertifizierungsstelle (CA) ausgestellt wird, die für die Identität des Zertifikatinhabers bürgt und den Parteien eine sichere Kommunikation durch Verschlüsselung ermöglicht.

Digitale Zertifikate gehen folgendermaßen vor:

• Sie prüfen, dass sich hinter ihren Inhabern – Personen, Websites und sogar Netzwerkressourcen wie z. B. Router – wirklich diejenigen verbergen, die sie zu sein vorgeben.
• Sie schützen Daten, die online ausgetauscht werden, vor Diebstahl oder Manipulation.

Digitale Zertifikate werden von einer vertrauenswürdigen Drittanbieter-Zertifizierungsstelle oder einer Microsoft Windows Public-Key-Infrastruktur (PKI) mit den Zertifikatdiensten ausgestellt, oder sie werden selbst signiert. Jedes Zertifikat verfügt über Vor- und Nachteile. Jeder digitale Zertifikat ist vor Manipulationen sicher und kann nicht gefälscht werden.

Zertifikate können für verschiedene Zwecke ausgestellt werden. Zu diesen Verwendungsarten gehören Web-Benutzerauthentifizierung, Webserver-Authentifizierung, Secure/Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPsec), Transport Layer Security (TLS) und Codesignatur.

Ein Zertifikat enthält einen öffentlichen Schlüssel und fügt diesen öffentlichen Schlüssel an die Identität einer Person, eines Computers oder eines Dienstes an, der den entsprechenden privaten Schlüssel enthält. Die öffentlichen und privaten Schlüssel werden vom Client und Server verwendet, um die Daten zu verschlüsseln, bevor sie übertragen werden. Für Windows-basierte Benutzer, Computer und Dienste wird die Vertrauensstellung in einer Zertifizierungsstelle hergestellt, wenn eine Kopie des Stammzertifikats im Zertifikatspeicher vertrauenswürdiger Stammzertifizierungsstellen vorhanden ist und das Zertifikat einen gültigen Zertifizierungspfad enthält. Damit das Zertifikat gültig ist, darf es nicht widerrufen worden sein und die Gültigkeitsdauer darf nicht abgelaufen sein.

SSL-Bindung

Sie können einer Site mehrere Bindungen zuweisen, wenn der Inhalt der Site verschiedenen Zwecken dient oder Sie dafür ein anderes Protokoll verwenden müssen. Eine geschäftliche Site verfügt z. B. möglicherweise über eine Anwendung, die erfordert, dass sich Benutzer bei einem Konto anmelden, um Waren zu erwerben. Das Unternehmen hostet die Site über HTTP, die Benutzer müssen sich jedoch über eine HTTPS-Seite bei ihrem Konto anmelden. In diesem Beispiel hätte die Site zwei Bindungen: eine für den HTTP-Bereich und eine für den HTTPS-Bereich.

Standardmäßig können Sie die Bindungen für andere Protokolle als HTTP und HTTPS nicht mit IIS-Manager hinzufügen. Wenn Sie eine Bindung für ein anderes Protokoll, z. B. ein von Windows Communication Foundation (WCF) unterstütztes Protokoll, hinzufügen möchten, verwenden Sie eines der anderen Verwaltungsprogramme. Wenn Sie jedoch den IIS File Transfer Protokoll (FTP)-Server installieren, können Sie FTP-Bindungen mit dem IIS-Manager hinzufügen. Möglicherweise können Sie auch andere Module oder Funktionen von Drittanbietern herunterladen, um die Benutzeroberfläche zu erweitern.

Erfordern von SSL für Ihre Site

Secure Sockets Layer (SSL)-Verschlüsselung schützt vertrauliche oder persönliche Informationen, die zwischen einem Client und einem Server gesendet wird. Ist SSL aktiviert, greifen Remoteclients mithilfe von URLs, die mit https:// beginnen, auf Ihre Site zu.

Konfigurieren Sie zunächst ein Serverzertifikat und erstellen Sie eine HTTPS-Bindung, um SSL-Einstellungen zu aktivieren. Fordern Sie dann SSL-Verschlüsselung in einem oder mehreren der folgenden Fälle:

1. Wenn vertrauliche oder persönliche Inhalte auf Ihrem Server durch einen verschlüsselten Kanal geschützt werden müssen.
2. Wenn Benutzer in der Lage sein sollen, die Identität des Servers zu prüfen, bevor sie persönliche Informationen übertragen.
3. Wenn Sie Clientzertifikate verwenden möchten, um Clients zu authentifizieren, die auf den Server zugreifen.

Clientzertifikate

Wenn Sie möchten, dass Clients ihre Identität bestätigen, bevor sie auf Inhalte Ihres Webservers zugreifen, konfigurieren Sie Clientzertifikate. Standardmäßig werden Clientzertifikate ignoriert.

Bevor Sie Clientzertifikate auf Ihrer Website konfigurieren, konfigurieren Sie ein Serverzertifikat und erstellen Sie eine HTTPS-Bindung, um SSL-Einstellungen zu aktivieren.

Wenn alle Clients ihre Identität bestätigen sollen, geben Sie an, dass Clientzertifikate erforderlich sind. Wenn einige Clients auf Inhalte zugreifen können sollen, ohne erst ihre Identität zu bestätigen, geben Sie an, dass Clientzertifikate akzeptiert werden.