17.8 Sonstiges zum Thema »Sicherheit«

In den folgenden Abschnitten sind einige weiterführende Aspekte zum Thema »Sicherheit« beschrieben.

17.8.1 SSL-Verschlüsselung

Eine professionelle Webanwendung, die mit Unternehmensdaten umgeht, muss diese verschlüsselt übertragen. Das gilt selbstverständlich für Daten, die durch das Internet transportiert werden, aber sensible Daten sollten auch ein LAN nicht unverschlüsselt durchqueren. Denken Sie daran, dass die Mehrzahl der Angriffe »von innen« kommt!

Der HTTP-Datenverkehr zwischen Webserver und Client kann sehr einfach mittels SSL verschlüsselt werden. Es entsteht dann eine HTTPS-Verbindung. Die genaue Funktionsweise einer HTTPS-Verbindung habe ich in Kapitel 12, »Active Directory-Zertifikatdienste«, beschrieben. Lesen Sie also im Zweifelsfall dort nochmals nach.

Zur Realisierung der SSL-Verschlüsselung ist ein Zertifikat auf dem Webserver erforderlich. Dieses bringt übrigens einen weiteren Vorteil: Der Webserver kann zuverlässig authentifiziert werden. Der Client weiß also, dass er wirklich mit dem gewünschten Server kommuniziert und nicht mit einem, der sich nur als das »Original« ausgibt, in Wahrheit aber eine Fälschung ist.

Wer bereits mit IIS6 (oder früheren Versionen) eine SSL-Verschlüsselung konfiguriert hat, wird sich ein wenig umstellen müssen, denn bei den älteren Versionen wurde die Konfiguration der Zertifikate ausschließlich in den Dialogen der Website vorgenommen. Bei IIS7 (und höher) ist das Feature Zertifikate auf der Ebene des Servers angesiedelt. Bei Websiten und Webanwendungen ist zwar jeweils eine Konfigurationsoption SSL-Verschlüsselung enthalten, dort können aber keine Zertifikate importiert werden.

Ein Zertifikat beschaffen und auf dem Server installieren

Der erste Schritt ist also, das Zertifikat auf den Server zu bekommen. Hier sind mehrere Wege möglich:

• Es besteht die Möglichkeit, ein als Datei vorhandenes Zertifikat einzulesen.
• Es kann eine Anforderung an eine Offline-Zertifizierungsstelle erstellt werden.
• Es kann eine Anforderung an eine im Active Directory veröffentlichte Online-Zertifizierungsstelle gestellt werden (siehe auch die Ausführungen über Active Directory-Zertifikatdienste).

In den Aktionen in der Serverzertifikate-Konfiguration finden Sie die Funktionen zum Erlangen des Zertifikats (Abbildung 17.105):

• Importieren dient zum Einlesen eines Zertifikats, das als Datei vorhanden ist (*.pfx).
• Zertifikatanforderung erstellen wird verwendet, wenn Sie von einer Offline-Zertifizierungsstelle ein Zertifikat anfordern (z. B. von VeriSign). Die Funktion Zertifikatanforderung abschliessen gehört unmittelbar dazu.
• Domänenzertifikat erstellen dient zum Anfordern eines Zertifikats von einer Online-Zertifizierungsstelle, die im Active Directory registriert ist.
• Selbstsigniertes Zertifikat erstellen generiert ein Zertifikat, das aber in keiner PKI-Hierarchie eingebettet ist.

Abbildung 17.105 Sofern das Zertifikat von einer im AD vorhandenen Zertifizierungsstelle erstellt werden soll, lassen Sie ein »Domänenzertifikat erstellen«.

Am einfachsten ist es, wenn Sie das Zertifikat bei einer Zertifizierungsstelle anfordern können, die in das Active Directory integriert ist. In diesem Fall wählen Sie Domänenzertifikat erstellen und können in dem Dialog aus Abbildung 17.106 die Daten für die Erstellung des Zertifikats angeben. Hierbei sind zwei Aspekte zu beachten:

• Unter Gemeinsamer Name muss exakt der Name eingetragen werden, der von den Clients zum Zugriff auf diesen Server verwendet wird. Wenn die Benutzer den FQDN (hier: extranet.ubinf.intra) eingeben, muss dieser hier eingetragen werden. Rufen die Benutzer die Webapplikation unter Eingabe des Computernamens (ubinfWebNlb1) auf, wird es eine Zertifikatswarnung geben. Beachten Sie, dass Applikationen, die beispielsweise auf einen Webservice zugreifen, die Verarbeitung abbrechen, wenn das Zertifikat nicht korrekt ist, also etwa der Name nicht passt.
• Im Textfeld Land/Region müssen Sie die offizielle Abkürzung für Ihr Land eintragen, beispielsweise DE für Deutschland. Ansonsten wird die Zertifizierungsstelle die Zertifikatanforderung ablehnen.

Abbildung 17.106 Anfordern eines Domänenzertifikats

Im nächsten Dialog des Assistenten wählen Sie die Zertifizierungsstelle, die Sie verwenden wollen (Abbildung 17.107). Diese Informationen werden aus dem Active Directory gelesen (siehe auch die Beschreibung des AD-Zertifikatdienstes). Der Anzeigename ist beliebig. Sie sollten bei der Auswahl bedenken, dass vielleicht mehrere Zertifikate auf Ihrem Server vorhanden sein könnten. Das ist beispielsweise dann der Fall, wenn mehrere Websites mit unterschiedlichen Hostheadern betrieben werden. Sinnvolle Namen erlauben später eine einfache Zuordnung.

Bei der Anforderung eines Domänenzertifikats wird dieses, sofern die Zertifizierungsstelle für automatische Ausstellung konfiguriert ist, wenige Sekunden später installiert sein.

Falls Sie bei einer »fremden« Zertifizierungsstelle, also beispielsweise bei VeriSign, Thawte & Co., ein Zertifikat beziehen möchten, erstellen Sie zunächst eine Zertifikatanforderung.

Abbildung 17.107 Online-Zertifizierungsstelle wählen

Wenn Sie das angeforderte Zertifikat erhalten, wählen Sie die Funktion Zertifikatanforderung abschliessen.

Wie auch immer das Zertifikat zu Ihnen bzw. Ihrem IIS gekommen sein mag – am Ende muss es in der Liste der Serverzertifikate angezeigt werden (Abbildung 17.108).

Abbildung 17.108 Das neue Zertifikat erscheint in der Liste der Serverzertifikate.

SSL-Verbindungen für die Website bzw. Webanwendung aktivieren

Im nächsten Schritt geht es nun darum, die einzelnen Websites für die SSL-Verschlüsselung zu aktivieren. Das IIS-Manager-Symbol SSL-Einstellungen sieht zunächst gar nicht so falsch aus, der dahinterliegende Dialog bietet in der Tat die gewünschten Einstellmöglichkeiten – ist aber leider komplett deaktiviert. Es findet sich der Hinweis, dass die Site noch nicht über eine sichere Bindung verfügt und demzufolge keine SSL-Verbindungen akzeptieren kann (Abbildung 17.109).

Abbildung 17.109 Ein erster Blick auf die SSL-Einstellungen ist eher ernüchternd. Zunächst müssen die Bindungen für SSL-Verbindungen erstellt werden.

Die Konfiguration der Bindungen findet sich beispielsweise im Kontextmenü des Eintrags der Website (Bindungen bearbeiten). Hier wird letztendlich festgelegt, auf welche Kombinationen aus IP-Adresse, Port und Hostheader die Website nebst den darunterliegenden Anwendungen reagieren soll.

Fügen Sie also (wie in Abbildung 17.110 gezeigt) eine Sitebindung hinzu. Bei der Konfiguration einer HTTPS-Verbindung kann zwar kein Eintrag in der Hostname-Textbox (Hostheader) erfolgen, allerdings wird dieser aus dem Namen ermittelt, für den das Zertifikat ausgestellt ist.

Die Option SNI (Server Name Indication) wird benötigt, wenn mehrere Hostnamen mit unterschiedlichen Zertifikaten gebunden sind (neu in Server 2012).

Abbildung 17.110 Das Erstellen einer neuen Bindung unter Nutzung des SSL-Zertifikats

Wenn eine HTTPS-Bindung zu der Website hinzugefügt ist, können auch die SSL-Einstellungen konfiguriert werden. Die dortigen Einstellmöglichkeiten dürften selbsterklärend sein (Abbildung 17.111).

Abbildung 17.111 Nachdem die HTTPS-Bindung vorhanden ist, kann hier beispielsweise konfiguriert werden, dass eine SSL-Verbindung erforderlich ist.

Falls Sie SSL erforderlich machen (siehe Abbildung 17.111) und ein Anwender dann die Website über eine Nicht-SSL-Verbindung aufruft, erscheint eine 403-Fehlermeldung (Abbildung 17.112). Die Meldung, nämlich Zugriff verweigert, ist letztendlich natürlich richtig, nur erfährt der Anwender leider nicht den tatsächlichen Grund, nämlich dass er vielleicht schon berechtigt wäre, allerdings die Seite über einen sicheren Kanal anzeigen müsste.

Abbildung 17.112 Versucht man ohne SSL auf die Webanwendung zuzugreifen, gibt es eine »403«.

17.8.2 .NET-Vertrauensebenen

In einer »klassischen« Umgebung (also ohne .NET Framework) sind die Berechtigungen des Benutzerkontos die einzige »Kontrollinstanz« in Sachen Sicherheit. Mit anderen Worten: Code wird ausgeführt, wenn er in einem Benutzerkontext läuft, der hinreichende Berechtigungen hat. Vereinfacht gesagt: Jeder Code, den ein Benutzer startet, wird – ausreichende Berechtigung vorausgesetzt – ausgeführt. Grundsätzlich ist das auf dem Webserver nicht anders: Wenn Code in der Webapplikation gestartet wird, wird er mit den Rechten der Identität des Anwendungspools ausgeführt, in dem die Webapplikation läuft. Um größeres Übel zu verhindern, wird (hoffentlich) der Anwendungspool unter einer Identität mit sehr wenigen Rechten (am besten NetworkService) laufen, aber trotzdem gibt es auch dann noch Verbesserungsbedarf.

Es ist eigentlich nicht einzusehen, warum man die Möglichkeiten, die Code hat, nicht stärker einschränken kann, sondern nur die Rechte der Identität, unter der er ausgeführt wird, als einziges Kriterium herangezogen werden. Wenn eine Webapplikation keinen Zugriff auf das Filesystem, eine SQL-Datenbank oder den DNS-Server haben muss, wäre es doch gut, diese Rechte von vornherein nicht zur Verfügung zu stellen. Möchte der Code auf diese Ressourcen dann doch zugreifen (z. B. weil der Code korrumpiert wurde, der Programmierer ein Hintertürchen eingebaut hat oder dergleichen mehr), sollte dies unterbunden werden.

Die .NET-Laufzeitumgebung stellt mit dem Konstrukt der Code Access Security (CASpol) genau diese Möglichkeiten zur Verfügung.

Wie Sie in Abbildung 17.113 sehen, läuft eine .NET-Applikation nicht direkt auf dem Betriebssystem, sondern als »ManagedApplication« in der .NET-Laufzeitumgebung (CLR, Common Language Runtime). Die Laufzeitumgebung ist in der Lage, gemäß den gewählten Einstellungen Zugriffe auf bestimmte Komponenten (z. B. Dateisystem, SQL Server etc.) zu erlauben oder nicht. Die Darstellung ist natürlich sehr stark vereinfacht, sollte aber für ein erstes Verständnis genügen.

Abbildung 17.113 Managed Code, wie der von ASP.NET-Anwendungen, greift nicht direkt auf das Betriebssystem zu, sondern wird von der Laufzeitumgebung des .NET Frameworks »gemanagt« – und kontrolliert.

Bei der Konfiguration einer Webapplikation kann die .NET-Vertrauensebene konfiguriert werden. Sie können also festlegen, welche Einschränkungen durch die Code Access Security für die jeweilige Webapplikation gelten sollen. In Abbildung 17.114 ist die Konfiguration der .NET-Vertrauensebenen zu sehen. Sie stellen die gewünschte Vertrauensebene für die Webapplikation ein, übernehmen die Änderungen – fertig!

Abbildung 17.114 Diese fünf Vertrauensebenen sind standardmäßig vorhanden.

Standardmäßig ist die Vertrauensebene Full gewählt. Wie unschwer zu erraten ist, gibt es bei dieser Stufe keinerlei Einschränkungen. Hinter der Bezeichnung Full befindet sich der Vermerkt (internal). Dies bedeutet, dass diese Vertrauensebene nicht auf einer Richtliniendatei basiert, sondern vom IIS eben »intern« umgesetzt wird. Die Alternative, nämlich die Einstellung Keine Einschränkungen vorzunehmen, bedarf verständlicherweise auch keiner großartigen Feinkonfiguration. Ob es so nun günstig ist, in der Standardeinstellung keine Einschränkungen vorzunehmen, ist sicherlich zu diskutieren. Es gibt allerdings zwei Gründe, die Microsoft zu diesem Schritt bewogen haben dürften:

• Der Standard-Anwendungspool läuft unter der Identität NetworkService mit sehr geringen Berechtigungen.
• Die Konfiguration der Code Access Security jenseits der in der Abbildung gezeigten Einstellmöglichkeit ist nicht ganz trivial. Würde zunächst eine genaue Konfiguration der Codezugriffsrechte erforderlich sein, würden viele Administratoren vermutlich verzweifeln. Für eine ganz detaillierte Anpassung der Code-Access-Rechte müssen XML-Dateien angepasst werden – das ist machbar, aber eben ohne grafische Oberfläche.

Die vorgefertigten Policy-Dateien, die Sie im Internetinformationsdienste-Manager auswählen können, gehören zum .NET Framework und finden sich in einer Standardinstallation im Verzeichnis c:\windows\Microsoft.NET\Framework64\v4.0.30319\config, das in Abbildung 17.115 gezeigt ist. Neben den Konfigurationsdateien, die Sie im Dialog .NET-Vertrauensebenen auswählen können, befindet sich in diesem Verzeichnis eine Datei namens web.config, auf die ich ein wenig später eingehen werde.

Abbildung 17.115 In diesem Verzeichnis liegen die ».config«-Dateien, in denen die Sicherheitsrichtlinien definiert sind.

Eine Beschreibung, welche Rechte einer Webapplikation durch die jeweilige Sicherheitskonfiguration gewährt werden, finden Sie in Tabelle 17.2. In ihr verweist beispielsweise High auf die Konfigurationsdatei web_hightrust.config. Sie können in dieser Tabelle etwa erkennen, dass eine Anwendung, die nur mit den Rechten von web_lowtrust.config läuft, keinen Zugriff auf den SQL Server bekommt (genauer gesagt: dass sie Funktionen des Namespaces System.Data.SQLClient nicht nutzen kann).

Die auswählbaren Richtliniendateien sind in der zentralen Datei web.config (C:\Windows\ Microsoft.NET\Framework64\v4.0.30319\Config) gespeichert. Falls Sie eine eigene zusätzliche (spezielle) Richtliniendatei kreieren möchten, können Sie diese einfach dort als zusätzliche Richtlinie eintragen – und sie kann ausgewählt und verwendet werden.

Ich würde empfehlen, eine vorhandene Datei, die Ihrer Zielkonfiguration einigermaßen ähnlich ist, zu kopieren, umzubenennen, in der web.config einzutragen und dann gemäß Ihren Anforderungen zu modifizieren. Diese Vorgehensweise ist deutlich einfacher, als mit einer leeren Datei zu starten.

Ein Beispiel für den Abschnitt aus der web.config sehen Sie in Listing 17.3. Die zusätzlich eingetragene Richtliniendatei ist fett hervorgehoben.

<system.web>
    <securityPolicy>
        <trustLevel name="Full" policyFile="internal" />
        <trustLevel name="High" policyFile="web_hightrust.config" />
        <trustLevel name="Medium"
        policyFile="web_mediumtrust.config" />
        <trustLevel name="Low"  policyFile="web_lowtrust.config" />
        <trustLevel name="Minimal"
        policyFile="web_minimaltrust.config" />
       
       <trustLevel name="BoddSpecial"
        policyFile="web_BoddSpecial.config" />
      
    </securityPolicy>
    <trust level="Full" originUrl="" />
</system.web>

Listing 17.3 Auszug aus der »web.config« im Verzeichnis »c:\windows\Microsoft.NET \Framework\v2.0.50727\config«

Das Ändern der Richtliniendateien in aller Ausführlichkeit zu besprechen erscheint mir für ein allgemeines Buch über Windows Server 2008/2012 zu speziell – die wenigsten Administratoren werden das wirklich tun. Wenn Sie tiefer in das Thema einsteigen möchten, können Sie mit folgender Webseite aus der Microsoft-Entwicklerdokumentation starten: http://msdn2.microsoft.com/de-de/library/wyts434y(VS.80).aspx

Wenn Sie Richtliniendateien anpassen, ist es wichtig, sehr genau zu wissen, welche Codezugriffsrechte die Webapplikationen benötigen, die ausgeführt werden sollen. Ansonsten ist ein fehlerfreier Betrieb nicht möglich. Hier sollte der Entwickler bzw. Hersteller qualifiziert helfen können, ansonsten bliebe Ihnen nur das Ausprobieren.

17.8.3 IP- und Domäneneinschränkungen

Falls Sie den Zugriff auf den Server, eine Website oder eine Anwendung einschränken möchten, können Sie auch mit IP-Adressbereichen arbeiten. Der zu installierende Rollendienst heißt IP- und Domäneneinschränkungen. Somit können Sie also nicht nur IP-Adressen, sondern auch Domänennamen eingeben, die dann aber per Reverse Lookup wieder auf IP-Adressen »zurückgeführt« werden. Abbildung 17.116 zeigt das Eintragen einer Ablehnungseinschränkungsregel (geniales Wort, wirklich) und dürfte wohl kaum Fragen offen lassen.

Abbildung 17.116 Erstellen einer Ablehnungseinschränkungsregel

Zwei erwähnenswerte Aspekte gibt es beim Dialog Featureeinstellungen bearbeiten (Abbildung 17.117):

• Zunächst wird die Frage »Was passiert mit nicht aufgeführten Systemen?« beantwortet. Sie können wählen, ob alle nicht explizit genannten IP-Adressen zugelassen oder verweigert werden sollen.
• Außerdem können Sie die Einschränkungen nach Domänennamen aktivieren. Dies ist nicht standardmäßig aktiviert, weil in diesem Fall für jede eingehende IP-Adresse ein Reverse Lookup ausgeführt werden müsste, um zu prüfen, ob die Adresse zufällig einer der genannten Domänen zuzuordnen ist. Das ist sehr zeitaufwendig und sollte daher nur genutzt werden, wenn Sie sicher sind, dass die auszuführenden Reverse-Lookup-Vorgänge die Gesamt-Performance nicht negativ beeinflussen.

Abbildung 17.117 Das Verhalten gegenüber nicht zugelassenen Clients kann entweder »Zulassen« oder »Verweigern« sein.

Greift ein Client von einer »verbotenen« IP-Adresse aus zu, reagiert der Server mit einem 403er-Fehler (Abbildung 17.118). Auch hier gilt, dass die Fehlermeldung (wahrscheinlich bewusst) sehr allgemein gehalten ist.

Abbildung 17.118 Greift man von einer verweigerten IP-Adresse aus zu, reagiert der Server mit einer »403«.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.