Was ist Konfigurationsmanagement?
Konfigurationsmanagement beantwortet zwei Fragen: Wie soll ein System eingestellt sein, und ist es das noch? Der Begriff stammt aus zwei Fachwelten. Im IT-Service-Management nach ITIL geht es darum, die Konfigurationselemente (Configuration Items, CIs) eines Services und ihre Beziehungen zu kennen, geführt in einer CMDB. In der Informationssicherheit steht der sichere Soll-Zustand im Vordergrund.
Beide brauchen dasselbe Fundament. Eine sichere Konfiguration lässt sich nur für Systeme festlegen und prüfen, die bekannt sind, und eine Bestandsliste ohne Soll-Zustand sagt nichts darüber, ob ein System richtig eingestellt ist. Wie Konfigurationsmanagement in ein ISMS eingebettet wird, beschreibt der Leitfaden ISMS einführen.
Was verlangen ISO 27001, NIS2 und DORA?
ISO/IEC 27001 führt Konfigurationsmanagement als Maßnahme 8.9, die NIS2-Durchführungsverordnung schreibt es ihren Adressaten vor, und DORA verlangt, die Konfiguration der IKT-Assets zu erfassen:
| Vorgabe | Fundstelle | Was verlangt wird |
|---|---|---|
| ISO/IEC 27001:2022 | Anhang A 8.9 | Konfigurationen, auch sicherheitsrelevante, über den Lebenszyklus festlegen, umsetzen und überwachen; Umsetzungshinweise, etwa zu Härtungsvorlagen und zum Schutz vor unbefugter Änderung, gibt ISO/IEC 27002 |
| NIS2-Durchführungsverordnung | Anhang Nr. 6.3 der Durchführungsverordnung (EU) 2024/2690 | für Einrichtungen der in § 30 Abs. 3 BSIG genannten Arten, etwa Cloud-Computing-Dienstleister: Konfigurationen einschließlich Sicherheitskonfigurationen festlegen, dokumentieren, umsetzen und überwachen. Sie werden bei neu installierten und laufenden Systemen durchgesetzt und in geplanten Abständen sowie nach erheblichen Vorfällen oder wesentlichen Änderungen überprüft |
| BSIG | § 30 Abs. 2 Satz 2 Nr. 5 BSIG | Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Systemen für besonders wichtige und wichtige Einrichtungen. Nach § 28 Abs. 5 und 6 BSIG gilt § 30 grundsätzlich nicht für bestimmte Telekommunikations- und Energieunternehmen und nicht für Finanzunternehmen nach DORA |
| DORA | Art. 8 Abs. 4 der Verordnung (EU) 2022/2554 | Finanzunternehmen erfassen die Konfiguration ihrer Informations- und IKT-Assets sowie die Verbindungen und Interdependenzen zwischen ihnen |
Die Baseline als Soll-Zustand
Eine Baseline ist der dokumentierte, freigegebene Soll-Zustand für eine Klasse von Systemen, etwa alle Windows-Server, alle Firewalls oder alle Datenbanken eines Typs. Ausgangspunkt sind Herstellerempfehlungen und veröffentlichte Härtungsleitfäden, angepasst an die eigene Risikobeurteilung.
| Bestandteil | Beispiel |
|---|---|
| Geltungsbereich | alle Linux-Server der Produktionsumgebung |
| Sicherheitseinstellungen | deaktivierte Standardkonten, Passwort- und Sperrrichtlinien, Protokollierung |
| deaktivierte Dienste und Protokolle | keine unverschlüsselten Verwaltungszugänge |
| Freigabe | verantwortliche Rolle, Datum, Version |
| begründete Abweichungen | Ausnahme je System mit Risikobewertung und Ablaufdatum |
| Überprüfung | Turnus und Anlässe, zu denen die Baseline selbst überprüft wird |
Setzen Sie die Baseline bei Neuinstallation und Wiederherstellung durch, möglichst über Vorlagen oder Automatisierungswerkzeuge. Jede Änderung an Systemen und an der Baseline selbst läuft über das Change-Management.
Konfigurationsdrift messen: ein Abgleich
Konfigurationsdrift ist die schleichende Abweichung der tatsächlichen Konfiguration von der Baseline. Sie entsteht durch Notfallkorrekturen, die nie zurückgenommen wurden, manuelle Eingriffe zur Fehlersuche, Updates, die Einstellungen zurücksetzen, und Systeme, die außerhalb des regulären Prozesses aufgebaut wurden. Ohne regelmäßigen Abgleich bleibt sie unsichtbar.
Beispiel (fiktiv): Die Zahlen sind frei gewählt. Ein Abgleich der Baseline „Linux-Server Produktion“ über 120 Systeme ergibt:
| Ergebnis | Systeme | Anteil |
|---|---|---|
| entspricht der Baseline | 102 | 85 % |
| weicht ab, mit genehmigter und gültiger Ausnahme | 9 | 7,5 % |
| weicht ab, ohne Ausnahme | 9 | 7,5 % |
Konform sind damit 111 von 120 Systemen (92,5 %), 102 davon ohne Ausnahme. Für die neun Abweichungen ohne Ausnahme suchen Sie den Änderungsdatensatz. Gibt es keinen, ist das ein Befund im Change-Management, nicht nur im Konfigurationsmanagement. Dann entscheidet der Verantwortliche je System: zurücksetzen oder eine befristete Ausnahme mit Risikobewertung beantragen.
Bewahren Sie den Abgleich mit Datum, Baseline-Version und Entscheidungen auf. Mit diesem Nachweis lässt sich im Audit belegen, dass Soll-Konfigurationen festgelegt, umgesetzt und überwacht werden. Neue Systeme, die ohne Baseline in Betrieb gegangen sind, und abgelaufene Ausnahmen sind die nächsten Prüfpunkte.
Worin unterscheiden sich Konfigurationsmanagement, Change-Management und CMDB?
Konfigurationsmanagement legt den Soll-Zustand fest und prüft ihn, Change-Management entscheidet über einzelne Änderungen, und die CMDB hält fest, welche Komponenten es gibt.
| Kriterium | Konfigurationsmanagement | Change-Management | CMDB |
|---|---|---|---|
| Art | Disziplin | Prozess | Werkzeug und Datenbestand |
| Leitfrage | Wie soll ein System eingestellt sein, und ist es das? | Darf diese Änderung durchgeführt werden? | Welche Komponenten gibt es, und wie hängen sie zusammen? |
| Ergebnis | Baselines, Konfigurationsstände, Abweichungsberichte | genehmigte und dokumentierte Änderungen | CIs mit Attributen und Beziehungen |
| Bezug in ISO/IEC 27002:2022 | Maßnahme 8.9 | eigene Maßnahme 8.32 zum Änderungsmanagement | keine eigene Maßnahme, mögliche Quelle für das Asset-Inventar |
Sichere Konfiguration in Rizzqo
In Rizzqo hängen die Anforderungen zur sicheren Konfiguration aus Frameworks wie ISO 27002 an jedem relevanten System. Die verantwortliche Person lädt Nachweise hoch, etwa den letzten Abgleich gegen die Baseline. Fehlt eine Härtung, bewerten Sie das Risiko in Euro und planen die Härtung als Aufgabe, die sich in beide Richtungen mit Jira synchronisiert.