Beim Konfigurationsmanagement gibt es unterschiedliche Ansätze und Bedürfnisse, deswegen gibt es auch sehr viele Produkte, die man stellenweise miteinander kombinieren kann.
Als Beispiel das iTop von Combodo, welches eher einen Dokumentationsansatz hat. Es unterstützt Problem-, Incident- und Changemanagement sowie Helpdesk nach ITIL mit der CMDB (Configuration Management Database) als Grundlage und Workflows für Tickets.
Auf der anderen Seite stehen dann zum Beispiel „Puppet“ oder „Ansible“, welche eher die aktive Administration durch (teil)-automatisiertes Ausrollen einer zentral vorgegebenen Konfiguration unterstützen. Mit den Tools kann dann die in der CMDB definierte Baseline vollautomatisch auf allen Systemen implementiert werden, was nach Auswertung in der Configuration Management Database in den Assets nachgetragen werden muss.
Es sollten beide CM Arten genutzt werden, die Dokumentation und die automatische Konfiguration, die gibt es teilweise auch von einem Hersteller als Komplettpaket.
Damit auch neue Mitarbeiter schneller und auch einfacher in die IT-Administration integriert werden können, ist es sinnvoll, für das meiste eine Vorlage zu haben. Als Beispiel sind Berechtigungen auf Dateisystemen für spezielle Nutzergruppen oder Absicherungsmaßnahmen für Webdienste mit einer Webapplication Firewall.
Auch Regelwerke für Firewalls lassen sich zu Vorlagen konvertieren. Diese müssen dokumentiert werden, mit dem entsprechenden Vermerk mit welcher Baseline sie auf welchem Produkt funktionieren.
Die Historie eines Produktes oder Systems ist genauso wichtig, wie die Vorlage, aus der die entsprechende Konfiguration stammte.
Anhand des Lebenszyklus des Systems lassen sich Verbesserungen via CSI (Continual Service Improvement / Kontinuierliches Verbesserungsprogramm) für die nachfolgende Produktgeneration erfassen.
Auch bekannte vorangegangene Probleme (Issue/Incident) lassen sich im Problem Management zusammenfassen und hilft eventuelle Produktions- oder Konfigurationsfehler zu vermeiden oder zu erkennen und zu beheben.
Wenn die Konfiguration auf einem Testsystem wie gewünscht funktioniert hat, kann sie genauso auf gleiche Systeme angewendet werden. Das sollte automatisiert erfolgen um eventuelle (menschliche) Fehlerquellen so gering wie möglich zu halten.
Es können Absicherungsmaßnahmen (z.B. Patche oder Firewall Konfigurationen) in kleinen Testumgebungen überprüft werden, ohne das gesamte Netzwerk einer eventuellen Gefahr oder einem Ausfall durch Inkompatibilität auszusetzen.
Bei der Dokumentation sollten alle Konfigurationsmöglichkeiten erfasst werden, damit es nicht nur ein Windows Server 2019 ist, sondern eine VM auf einem ESXi 7.0 mit der Kompatibilitätsstufe 6.7 usw. Alles was veränderbar ist sollte dokumentiert sein, damit gleiche Systeme identifizierbar sind und einheitliche Vorgehen beschrieben werden können.
