IIS 7: Modularer Web-Baukasten

Während IIS früher vor allem durch zahlreiche Sicherheitslücken und Viren wie Code Red und Nimda von sich Reden machte, ist es seit dem Erscheinen des Windows Server 2003 mit dem in der Version 6.0 enthaltenen Webserver diesbezüglich sehr ruhig geworden. Der Grund hierfür liegt in zwei Prinzipien, die Microsoft bei der Entwicklung der 6.0er Ausgabe sehr konsequent und letztlich auch mit Erfolg angewandt hat – «Security by design» und «Security by
default».
Während ersteres vor allem eine Umstellung des Entwicklungsprozesses bedeutete, um potentielle Sicherheitslücken bereits vor der Auslieferung zu entdecken, äusserte sich letzteres in einer funktional minimalisierten Standard­installation. War es in früheren Ausgaben des IIS üblich, alle verfügbaren Funktionen sowohl zu installieren wie auch zu aktivieren, muss bei der Version 6.0 jedes Feature einzeln hinzugeschaltet und aktiviert werden, so dass möglichst wenig Angriffsfläche geboten wird.

Konfiguration des IIS 7

Die Konfiguration des IIS 6.0 wurde bislang in einer zentralen XML-Datei gespeichert, der sogenannten Metabase. Allerdings hat die Metabase insgesamt nicht viel mit XML zu tun, weshalb sie als äusserst schlecht wartbar, schlecht replizierbar und umständlich zu bearbeiten gilt.
In IIS 7 wird es die Metabase nun nicht mehr geben. Statt dessen wird dort auf ein echtes XML-Format gesetzt, das aus ASP.NET bereits bekannt ist – zum Einsatz kommen die Web.Config-Dateien, die bereits für die Konfiguration von ASP.NET-Webapplikationen dienen. Zukünftig wird neben der Konfiguration der Anwendung an sich auch die Einstellungen des Webservers in dieser Datei gespeichert und an die Applikation weitergereicht.

Dadurch verringert sich der Aufwand für die Migration einer Anwendung auf einen anderen Webserver auf ein simples Kopieren der entsprechenden Dateien. Da Web.Config-Dateien auch in Unterordnern einer Applikation abgelegt werden können, lassen sich auch einzelne Subfolder eigenständig konfigurieren. Zudem kann die Web.Config auch an zentraler Stelle, beispielsweise auf einen Fileshare, abgelegt werden, so dass sich mehrere Server eine Konfiguration teilen und problemlos auf einen Schlag aktualisiert werden können.
Ein weiterer Vorteil dieser Vorgehensweise ist, dass die Web.Config im Kontext der Applikation liegt und daher von dem Benutzer bearbeitet werden kann, der Zugriff auf die Applikation hat. So verringert sich der administrative Aufwand ganz erheblich, was insbesondere für Webhoster interessant sein dürfte.

Im IIS 6.0 war es bislang wenn überhaupt, dann nur umständlich möglich, programmatisch Änderungen an der Konfiguration vorzunehmen. Der IIS 7 soll nun eine entsprechende .NET-Assembly enthalten und bietet über den neuen Namensraum Microsoft.Web.Administration einen sehr einfachen und komfortablen Zugriff auf alle relevanten Einstellungen, was die Erstellung von webbasierten Konfigurationsmanagern wie beispielsweise Plesk äusserst einfach macht.

IIS 7 Admin Tool

Seit der Version 4.0 des IIS gibt es ein Snapin für die Microsoft Management Console (MMC) zu dessen Konfiguration – den IIS-Manager. Auch diese Applikation teilte einige der Probleme der Metabase, so war beispielsweise Zugriff auf das Administratorkonto notwendig und es liessen sich bei weitem nicht alle Einstellungen des IIS über die grafische Oberfläche modifizieren.
In IIS 7 wird es den IIS-Manager nun nicht mehr geben. An seine Stelle tritt eine neue Applikation, das sogenannte IIS 7 Admin-Tool, das sich optisch an Visual Studio 2005 und das SQL Server 2005 Management-Studio anlehnt und daher sowohl den meisten Entwicklern wie auch Administratoren sehr vertraut vorkommen dürfte.
Doch das IIS 7 Admin-Tool bietet mehr als nur den grafischen Zugriff auf die Konfiguration des Webservers im klassischen Sinne. Da der IIS 7 sehr eng mit ASP.NET 2.0 verzahnt ist, lassen sich über das neue Admin-Tool beispielsweise auch die integrierte Benutzer- und Profilverwaltung von ASP.NET 2.0 nutzen und konfigurieren.

Äusserst praktisch an dieser Stelle ist, dass dies nicht nur für Webapplikationen funktioniert, die in ASP.NET geschrieben sind, sondern für beliebige Webapplikationen. So lassen sich mit IIS 7 etwa die Benutzerverwaltung oder die Sicherheitsfeatures von ASP.NET 2.0 auch für eine PHP-basierte Website einsetzen. Wie schon für den Zugriff auf die Web.Config ist auch für das IIS 7 Admin-Tool kein Administratorkonto mehr notwendig. Statt dessen kann jeder Benutzer alle Webapplikationen konfigurieren, für die er über entsprechende Rechte verfügt. Einstellungen, die manuell in der Web.Config vorgenommen werden, übernimmt das IIS 7 Admin-Tool dabei automatisch, ebenso spiegeln sich Änderungen, die in der grafischen Oberfläche vorgenommen werden, direkt in der Web.Config wider.
Da das IIS 7 Admin-Tool zudem durch Drittanbieter um eigene Konfigurationsabschnitte erweiterbar ist, gestaltet sich das Konzept der Konfiguration und Administration des IIS 7 als sehr flexibel. Da diese Erweiterungen über entsprechende XML-Schemata verfügen müssen, wird zudem die Konformität der Web.Config sichergestellt.

Ausbaufähig

Eigene Erweiterungen in IIS 6.0 vorzunehmen, war bislang über die ISAPI-Schnittstelle möglich, die allerdings weder einfach zu handhaben noch sonderlich flexibel war. Statt dessen waren gute Kenntnisse in C++ nötig, um Add-ons für den IIS bereitzustellen.
In IIS 7 wird es nun ISAPI nicht mehr geben – wobei bestehende ISAPI-Module über eine Kompatibilitätskomponente nach wie vor eingebunden und ausgeführt werden können. In IIS 7 ist der empfohlene Weg aber, die Erweiterung in .NET entweder als ASP.NET-Handler oder als ASP.NET-Modul zu schreiben. Dank der oben bereits erwähnten Verzahnung des IIS 7 mit ASP.NET 2.0 lassen sich diese in .NET geschriebenen Erweiterungen aber nicht mehr wie bislang nur für ASP.NET-Webapplikationen nutzen, sondern für beliebige Webseiten. Um beispielsweise in den Request einer PHP-basierten Webseite einen ASP.NET-Handler einzuhängen, reicht es aus, in IIS 7 zu registrieren und der entsprechenden Webseite zuzuweisen.

Total modular

Doch nicht nur Erweiterungen sind als eigenständige Module realisiert. Bestand der IIS 6.0 bislang aus einer einzigen DLL, die entweder ganz oder gar nicht geladen wurde, existiert im IIS 7 nun für jedes einzelne Modul (HTTP-Logging, Tracing, Authentication, Compression etc.) eine eigene DLL, die jeweils einzeln aktiviert oder deaktiviert werden kann. Besonders interessant ist hierbei, dass sich auf diese Weise auch einzelne Module durch selbstgeschriebene austauschen lassen.
Möchte man beispielsweise eine eigene Komponente zur Verfügung stellen, die den Ordnerinhalt grafisch anspruchsvoll aufbereitet als Standardindexseite ausgibt, so kann man eine solche als ASP.NET-Modul entwickeln, die bestehende Standardinhaltsseite deaktivieren und durch das eigene Modul ersetzen.

Ausserdem lässt sich ein IIS 7 durch die Abschaltbarkeit einzelner Module auch wesentlich besser an konkrete Anforderungen anpassen. Das wirkt sich nicht nur positiv auf die Leistung aus, sondern auch auf die Sicherheit, da zum einen nur das ausgeführt wird, was auch tatsächlich benötigt wird, und zum anderen nur die aktivierten Module Angriffsfläche bieten. Die Modularität könnte ebenfalls ein interessanter Aspekt auch für Webhoster sein, die ihr Angebot nach Funktionen preislich staffeln können.

Monitoring und Health

Ein wesentliches Problem des IIS 6.0 war die Diagnose von Fehler­ursachen. Trieb beispielsweise eine in ASP Classic geschriebene Webseite die Prozessorlast nach oben, so war es quasi unmöglich, diese einzelne Webseite zu identifizieren und anzuhalten. Es war nötig, den gesamten Code schrittweise und mühsam zu analysieren, um dem Fehler auf die Spur zu kommen.

In IIS 7 soll sich dies nun ändern, denn das neue Admin-Tool bringt zahlreiche Statistiken und Hilfsmittel zur Überwachung und Analyse des laufenden Webservers mit. Diese Möglichkeiten beziehen sich dabei nicht nur auf den Webserver als ganzes, sondern auch auf einzelne Webapplikationen, die überwacht und analysiert werden können. Insbesondere die Fähigkeit des IIS 7, ausführliche Logdateien im XML-Format zu schreiben, ist an dieser Stelle äusserst interessant.
In diesen Dateien wird nicht nur – wie bislang – jeder Request einzeln protokolliert, sondern auf Wunsch wird auch die exakte Route des Requests durch den IIS 7 und die diversen Module protokolliert, so dass sich beispielsweise genau nachvollziehen lässt, an welcher Stelle ein Fehler aufgetreten ist.

Fazit

Während IIS 6.0 einen grossen Fortschritt bezüglich der Sicherheit darstellte, ist der IIS 7 in jeder Hinsicht ein Quantensprung. Auch wenn sich bis zur endgültigen Version noch das eine oder andere Detail ändern könnte, dürfte die Basis stehen. Und diese verspricht einen von Grund auf überarbeiteteten und durchdachten Webserver, der sich wunderbar in Microsofts .NET-Strategie integriert.

Als einziger Wermutstropfen bleibt, dass der IIS 7 nur in Windows Vista und «Longhorn» Server (Nachfolger von Windows 2003 Server) verfügbar sein wird, so dass für Interessierte ein Serverupdate unumgänglich bleibt. Allerdings dürften die Vorteile eines Umstieges das Update auf alle Fälle rechtfertigen.