Das Thema «Change and Configuration Management» ist vor allem im Kontext von ITIL in den Blickpunkt gerückt. Die Zielsetzung ist eine Datenbank (CMDB, Configuration Management Database), in der sich Informationen zu CIs (Configuration Items) finden, die miteinander verknüpft sind. Ausserdem sollen ergänzende Informationen wie Tickets aus dem Service Desk oder Definitionen von SLAs (Service Level Agreements) dort abgelegt werden. Mit den Ansätzen von ITIL und der darauf basierenden Lösungen wird einerseits erkennbar, welche Abhängigkeiten es gibt, und andererseits nachvollziehbar, welche Änderungen auf welche CIs zu welchen Wirkungen führen.
Die Items werden allerdings typischerweise auf einem relativ hohen Abstraktionsniveau definiert. Rechnerdaten kommen aus der Inventarisierung, Software wird als Paket beschrieben und in einer Definitive Software Library (DSL) abgelegt. Gebäude, Mitarbeiter, Prozesse und so weiter werden ebenfalls definiert.
Unter dem Blickwinkel von ITIL als einem übergeordneten Ansatz macht das auch Sinn. Wenn man aber in die Details geht, wird deutlich, dass man doch schnell an die Grenzen stösst. Denn Konfigurationsmanagement hat auch viel mit der Detailkonfiguration von Systemen zu tun, bei denen es unzählige Parameter gibt, die gesetzt werden müssen. Das ist in dem Modell zwar grundsätzlich abbildbar. Schon bei den Tools stösst man aber zumindest heute an die Grenzen.
Dass ein Konfigurationsmanagement auf Systemebene erforderlich ist, wird spätestens deutlich, wenn man sich mit den konkreten Aktivitäten von Systemadministratoren beschäftigt. Die Erstellung und Anpassung von Konfigurationsdateien für
Systemfunktionen und Anwendungen im Linux- oder Unix-Umfeld ist eine der Standardaufgaben, ebenso wie die Anpassung von Gruppenrichtlinien oder gar die direkte Modifikation von Systemeinstellungen im Windows-Umfeld.
Hier stellen sich nun drei Herausforderungen. Die erste ist, dass man solche Konfigurationsanpassungen überhaupt in einer definierten, nachvollziehbaren Weise durchführt. Die zweite ist die Einbindung in übergeordnete Konzepte des Change and Configuration Management. Und die dritte ist ein systemübergreifender Ansatz, mit dem man im Idealfall gleichartige Änderungen auf unterschiedlichen Betriebssystemen in einheitlicher Weise durchführen kann.
Der erste Punkt ist zunächst einmal eine organisatorische Herausforderung. Grundsätzlich kann man alle Änderungen in Konfigurationsdateien wie in Gruppenrichtlinien, aber auch von nur direkt über grafische Oberflächen modifizierbaren Parametern in definierten Prozessen durchführen, bei denen einen Freigabe und Dokumentation der Änderungen erforderlich ist. Und da Konfigurationsanpassungen auch Auswirkungen auf die Sicherheit haben, sollte man das auch so machen.
Allerdings zeigt die Realität auch, dass man spätestens in Krisensituationen, in denen beispielsweise ein Server oder ein wichtiger Arbeitsplatzrechner nicht mehr korrekt arbeitet, Ad-hoc-Lösungen verwendet, bei denen genau diese Dokumentation nicht erfolgt.
Die zweite Herausforderung ist die Einbindung der Konfigurationsprozesse auf Systemebene in übergeordnete Konzepte des Change and Configuration Management. Das ist sowohl in Linux-/Unix- als auch in Windows-Umgebungen mit relativ wenig Aufwand lösbar. Denn während im Linux- und Unix-Umfeld typischerweise über Konfigurationsdateien gearbeitet wird, lassen sich die meisten Anpassungen im Windows-Umfeld über Gruppenrichtlinien durchführen.
Konfigurationsdateien kann man aber letztlich einfach als Teil eines Softwarepakets interpretieren und entsprechend beschreiben. Und auch Gruppenrichtlinien lassen sich, wenn auch technisch nicht ganz so einfach, als zentrale Objekte behandeln, die nach durchgängigen definierten Prozessen verändert und aktiviert respektive deaktiviert werden. Allerdings ist die technische Integration von Gruppenrichtlinien in Werkzeuge für das Change and Configuration Management insgesamt deutlich verbesserungswürdig.
Kritisch sind vor allem die Änderungen, die nicht über solche zentralen Mechanismen durchgeführt werden, sondern die einzeln in den Systemen und Anwendungen beispielsweise über grafische Schnittstellen konfiguriert werden müssen. Das sind allerdings nicht so viele. So kann man beispielsweise bei Linux so ziemlich alles, was man über YaST machen kann, auch direkt in Konfigurationsdateien beschreiben. Und bei Windows lassen sich auch die Konfigurationseinstellungen für Anwendungen in Gruppenrichtlinien abbilden, soweit sie als Registry-Parameter abgelegt werden. Und sonst gibt es meistens einige anwendungsspezifische Konfigurationsdateien, die man ebenfalls anpassen kann.
Dieses Problem ist also, wenn auch nicht reibungslos, so doch lösbar. Die grössere Herausforderung ist – wie generell beim Change and Configuration Management –, dass man überhaupt mit solchen zentralen Ansätzen arbeitet. Das zeigt sich schon daran, dass die Gruppenrichtlinien im Windows-Umfeld immer noch in erschreckend geringem Umfang genutzt werden.
Schwach sieht es dagegen bei systemübergreifenden Ansätzen aus, wenn man Konfigurationseinstellungen beispielsweise auf Systemebene einheitlich lösen möchte. Ein Beispiel dafür könnte die Deaktivierung bestimmter aktiver Komponenten bei den verschiedenen Browsern auf unterschiedlichen Systemplattformen sein. Hier und in vielen anderen Fällen – beispielsweise bei der Konfiguration von Ports, speziellen TCP/IP-Einstellungen für eine bessere Performance oder der Deaktivierung des Zugriffs auf bestimmte Funktionen der Systemkonfiguration – würde es sich anbieten, in einer zentralen Richtlinie festzulegen, was erlaubt sein soll und was nicht.
Solche Ansätze werden allerdings derzeit von kaum einer Lösung im Systemmanagement angeboten. Eine Ausnahme sind die Enterprise-Versionen der Change-and-Configuration-Management-Produkte von HP, die in diese Richtung gehen. Allerdings wird hier auch deutlich, dass man von einer differenzierten Steuerung, wie man sie auf der Windows- oder Linux-Ebene vornehmen könnte, doch ein gutes Stück entfernt ist.
Anders formuliert: Hier haben die Hersteller ihre Hausaufgaben noch nicht gemacht. Vielleicht wäre es aber auch eine gute Idee, wenn sich die Entwickler von Betriebssystemen von Dogmen verabschieden und nach gemeinsamen Konzepten für das Konfigurationsmanagement suchen würden. Denn letztlich sind weder die Konfigurationsdateien aus dem Linux- und Unix-Umfeld noch die Gruppenrichtlinien der Weisheit letzter Schluss. Das beginnt schon damit, dass Zugriffsberechtigungen für Konfigurationsdateien nur auf Dateiebene, aber nicht pro Parameter gesetzt werden können. Und Gruppenrichtlinien sind zwar leistungsfähig, aber auch reichlich komplex und einigermassen unübersichtlich.
Teilansätze zur Lösung der im vorangegangenen Abschnitt beschriebenen Herausforderung finden sich im Bereich des Sicherheitsmanagements, also bei Herstellern, die spezifisch Probleme im Bereich der Sicherheit adressieren. Hier gibt es beispielsweise für die Network Access Control (NAC) teilweise einheitliche Schnittstellen, mit denen man unterschiedliche Systeme konfigurieren kann.
Ein Problem dabei ist aber, dass solche Einzellösungen schwer in übergeordnete Ansätze für das Change and Configuration Management einzubinden sind. Eine zweite Schwachstelle ist der Fokus auf einen kleinen, wenn auch wichtigen Ausschnitt der Konfigurationseinstellungen. Das reicht aber nicht aus, um eine durchgängige Lösung zu realisieren, sondern sorgt sogar noch für Überschneidungen bei der Anpassung von Konfigurationsdateien und Gruppenrichtlinien.
Auch die Anbieter von Client-Lifecycle-Management-Lösungen haben diese Aufgabenstellung nicht wirklich gelöst. Zwar sind die meisten in der Lage, auch Registry-Parameter anzupassen und, soweit sie Linux unterstützen, können alle auch Konfigurationsdateien verteilen. Wer aber schon einmal versucht hat, eine grössere Zahl von Registry-Parametern über Client-Lifecycle-Management-Produkte zu konfigurieren, weiss, dass man hier schnell an die Grenzen stösst. Die Gruppenrichtlinien sind zwar komplex. Durch ihren viel höheren Abstraktionsgrad sind sie aber für die Aufgabenstellung einer durchgängigen, umfassenden und einheitlichen Systemkonfiguration von Windows-Systemen deutlich besser geeignet.
Zudem lassen die Werkzeuge eben auch die plattformübergreifende Abstraktion von Konfigurationseinstellungen vermissen, wie sie oben angesprochen wurde. Selbst wenn man Linux und Windows mit einem Produkt verwalten kann, hat man doch innerhalb des Produkts praktisch immer zwei getrennte Ansätze für das Konfigurationsmanagement.
Bleibt also das Fazit, dass beim Change and Configuration Management noch einiges an Arbeit für die Hersteller zu leisten ist. Das gilt auf der abstrakten Ebene von ITIL, um die Detailkonfiguration von Systemen ebenfalls sauber und reibungslos in die übergeordneten Konzepte einzubinden.
Und das gilt auf der Ebene des Managements einzelner Systeme, um vielleicht einmal an den Punkt zu gelangen, an dem man Konfigurationseinstellungen abstrakt auch für verschiedene Systemplattformen in einheitlichen Richtlinien beschreiben kann. Das würde die System- und Sicherheitskonfiguration deutlich vereinfachen. Einstweilen bleibt nur, die Möglichkeiten übergeordneter Systeme und von spezifischen Funktionen wie den Gruppenrichtlinien auf technischer und organisatorischer Ebene so gut wie möglich zu kombinieren, um die Übersicht über Konfigurationen und die Nachvollziehbarkeit von Änderungen auf ein möglichst hohes Niveau zu bringen.
Grafik
