Das Wichtigste in Kürze
- CMDB steht für Configuration Management Database, auf Deutsch Konfigurationsmanagementdatenbank.
- Der Begriff stammt aus ITIL: In ITIL v3 gehörte die CMDB zum Prozess Service Asset and Configuration Management (SACM), ITIL 4 führt die Aufgabe als Praxis Service Configuration Management.
- Eine CMDB führt Configuration Items und ihre Beziehungen, damit der IT-Betrieb Störungen und Änderungen analysieren kann.
- ISO/IEC 27001:2022 verlangt in Anhang A 5.9 ein Inventar der Informationen und zugehörigen Werte mit Eigentümern, schreibt aber keine CMDB vor.
- Für Finanzunternehmen nennt DORA in Artikel 8 Absatz 4 ausdrücklich die Konfiguration der IKT-Assets und die Verbindungen zwischen ihnen.
Was ist eine CMDB?
Eine CMDB ist der Datenbestand, in dem eine Organisation ihre IT-Komponenten als Konfigurationselemente (Configuration Items, CIs) erfasst und die Beziehungen zwischen ihnen abbildet. Sie beschreibt die IT-Landschaft so, wie der Betrieb sie braucht. Ein CI ist jedes Element, das verwaltet werden muss, damit ein IT-Service erbracht werden kann. Die Beziehungen sind der eigentliche Wert: „Anwendung A läuft auf Server B“, „Server B steht im Rechenzentrum C“, „Service D nutzt Datenbank E“. Erst sie erlauben die Frage, welche Services eine Störung oder eine geplante Änderung berührt.
Inhalt einer CMDB: Configuration Items in fünf Klassen
Eine CMDB enthält CIs aus mehreren Klassen, jede mit eigenen Attributen:
| CI-Klasse | Beispiele | Typische Attribute |
|---|---|---|
| Hardware | Server, Clients, Netzkomponenten, Speichersysteme | Seriennummer, Standort, Modell, Firmwarestand |
| Software und Anwendungen | Betriebssysteme, Fachanwendungen, Datenbanken | Version, Lizenzbezug, Installationsort |
| Cloud-Ressourcen | virtuelle Maschinen, verwaltete Datenbanken, Speicher | Konto, Region, Kennung beim Anbieter |
| Services | E-Mail, ERP, Kundenportal | technischer Verantwortlicher, Servicezeiten, Abhängigkeiten |
| Dokumentation | Betriebshandbücher, Verträge, Konfigurationsstände | Version, Gültigkeit, Ablageort |
Herkunft aus ITIL: SACM und Service Configuration Management
Der Begriff stammt aus ITIL, dem Rahmenwerk für IT-Service-Management. In ITIL v3 gehörte die CMDB zum Prozess Service Asset and Configuration Management (SACM); ITIL 4 führt dieselbe Aufgabe als Praxis Service Configuration Management. ITIL unterscheidet dabei die einzelne Datenbank vom Configuration Management System (CMS), das mehrere Datenquellen zusammenführen kann. In der Praxis ist „die CMDB“ deshalb oft ein Verbund: ein ITSM-Werkzeug als Kern, gespeist aus Verzeichnisdienst, Virtualisierung, Cloud-Konten und Netzerkennung.
Die CMDB ist das Werkzeug, das Konfigurationsmanagement im Betrieb nutzbar macht. Ohne den Prozess dahinter, also klare Zuständigkeiten für Anlage, Pflege und Stilllegung von CIs, wird sie zur nächsten veralteten Liste.
Wie wird eine CMDB befüllt und aktuell gehalten?
Eine CMDB wird über drei Wege befüllt, die sich kombinieren lassen:
- Automatische Erkennung (Discovery): Werkzeuge durchsuchen Netze, Hypervisoren und Cloud-Konten und legen gefundene Objekte an oder aktualisieren sie.
- Import aus führenden Systemen: Verzeichnisdienst, Endgeräteverwaltung, Beschaffung und Cloud-Schnittstellen liefern Objekte und Attribute.
- Manuelle Pflege: Alles, was keine Maschine erkennen kann, etwa fachliche Zuordnung, Servicebezug oder Verantwortliche.
Entscheidend ist der Abgleich (Reconciliation): Wenn zwei Quellen dasselbe Objekt liefern, muss feststehen, welche für welches Attribut führt. Ohne diese Regel entstehen Dubletten, und das Vertrauen in die Daten geht schneller verloren, als es aufgebaut wurde.
CMDB oder Asset-Inventar: Was ist der Unterschied?
Eine CMDB beantwortet die Frage, wie die IT zusammenhängt. Ein Asset-Inventar für das ISMS beantwortet die Frage, was schützenswert ist, wem es gehört und welche Pflichten daran hängen. Die Bestände überschneiden sich, die Zwecke nicht. Wie sich beide zusätzlich vom kaufmännischen IT-Asset-Management unterscheiden, zeigt der Ratgeber IT-Asset-Management.
| Kriterium | CMDB | Asset-Inventar des ISMS |
|---|---|---|
| Zweck | Störungs-, Problem- und Änderungsanalyse im IT-Betrieb | Grundlage für Schutzbedarf, Risiken, Maßnahmen und Nachweise |
| Ausgangspunkt | technische Komponenten und Services | Informationen und Geschäftsprozesse, darunter die tragenden Werte |
| Typische Objekte | Server, Anwendungen, Netzkomponenten, Cloud-Ressourcen | zusätzlich Informationen, Prozesse, Standorte, Dienstleister, Personal mit Schlüsselwissen |
| Verantwortung | technischer Betreuer je CI | fachlicher Eigentümer je Wert |
| Kernattribute | Version, Standort, Abhängigkeiten, Status | Schutzbedarf je Schutzziel, Eigentümer, Kritikalität, Bezug zu Risiken und Maßnahmen |
| Pflegende Stelle | IT-Betrieb, ITSM-Team | Informationssicherheit gemeinsam mit den Fachbereichen |
| Was die Prüfung fragt | selten Gegenstand eines ISMS-Audits | Vollständigkeit, Eigentümer, Aktualität, Verknüpfung mit Risiken |
Was verlangt ISO 27001 Anhang A 5.9 vom Asset-Inventar?
ISO/IEC 27001:2022 verlangt in Anhang A unter 5.9 sinngemäß, die Informationen und die übrigen zugehörigen Werte der Organisation zu ermitteln, ein Inventar darüber zu führen und jedem Eintrag einen Eigentümer zuzuordnen. Eine bestimmte Form schreibt die Norm nicht vor. Eine CMDB kann also Teil der Antwort sein, wenn sie liefert, was das ISMS braucht:
- Die primären Werte sind erfasst: Informationen und Geschäftsprozesse, nicht nur Technik.
- Jeder Eintrag hat einen fachlichen Eigentümer, nicht nur einen technischen Betreuer.
- Der Schutzbedarf ist je Schutzziel eingestuft und an die tragenden Systeme weitergegeben.
- Abhängigkeiten zwischen Prozessen, Anwendungen und Infrastruktur sind nachvollziehbar.
- Jeder Wert ist mit seinen Risiken und Maßnahmen verknüpft.
- Neue, geänderte und stillgelegte Werte erreichen das Inventar zeitnah, mit Datum und verantwortlicher Person.
Was eine CMDB davon abdeckt
Eine CMDB ist für die Punkte vier und sechs gebaut; für die Punkte eins bis drei und fünf ist sie es nicht von sich aus. Für Finanzunternehmen geht DORA weiter: Artikel 8 Absatz 4 der Verordnung (EU) 2022/2554 nennt bei der Ermittlung der IKT-Assets ausdrücklich auch deren Konfiguration und die Verbindungen zwischen ihnen. Hier wird die CMDB zur wichtigen Quelle, aber nicht zum Ersatz für die Einstufung und Eigentümerschaft. Welche Spalten ein Asset-Inventar darüber hinaus braucht, zeigt die Vorlage für das Asset-Inventar.
Die CMDB als Quelle für das ISMS in 5 Schritten
In fünf Schritten wird die CMDB zur verlässlichen Quelle für das Asset-Inventar, ohne es zu ersetzen:
- Objektgrenze festlegen: Bestimmen Sie, welche CI-Klassen für das ISMS relevant sind. Nicht jede Netzwerkdose gehört ins Asset-Inventar.
- Eindeutige Kennung übernehmen: Führen Sie die CI-Kennung im Asset-Inventar mit, damit beide Bestände abgleichbar bleiben.
- Führung je Attribut regeln: Technische Attribute führt die CMDB, Schutzbedarf und Eigentümer führt das ISMS. Doppelte Pflege desselben Felds endet in Widersprüchen.
- Regelmäßig abgleichen: Ein CI ohne Gegenstück im Inventar ist ein Befund, kein Nachtrag. Er zeigt einen Zufluss, der nicht funktioniert.
- Stilllegung beidseitig abschließen: Ein außer Betrieb genommenes System wird in beiden Beständen beendet, nicht gelöscht, damit der Nachweis erhalten bleibt.
Vier typische Fehler in CMDB-Projekten
Die typischen Fehler bei CMDB-Projekten liegen in Prozess und Zuständigkeit, nicht in der Technik:
- Vollständigkeit vor Nutzen: Wer alles erfassen will, bevor ein Prozess die Daten nutzt, pflegt eine Datenbank, die niemand abfragt.
- Discovery als Ersatz für Verantwortung: Automatische Erkennung findet Objekte, aber keine Eigentümer und keinen Geschäftszweck.
- Keine Kopplung an das Change-Management: Wenn Änderungen die CMDB nicht nachziehen, veraltet sie mit jeder Freigabe.
- Die CMDB als ISMS-Inventar ausgeben: Im Audit fällt das spätestens bei der Frage auf, wem eine bestimmte Information gehört.
Warum Bestände ohne festen Zufluss veralten, beschreibt der Beitrag Warum Asset-Inventare veralten; wie das Inventar in den Aufbau eines ISMS passt, der Ratgeber ISMS einführen.
Wo Rizzqo neben der CMDB steht
Rizzqo bildet die Compliance-Sicht ab, für die eine CMDB nicht gebaut ist: Prozesse und Dienste tragen eine Einstufung nach Vertraulichkeit, Integrität und Verfügbarkeit, Informationen eine Vertraulichkeitseinstufung. Unterstützende Assets hängen darunter und erben von ihnen die Vertraulichkeitseinstufung und die Kennzeichnung personenbezogener Daten, auch über mehrere Stufen. Asset-Kategorie und -Unterkategorie sind der Schlüssel, über den die Anforderungen der Regelwerke am Asset erscheinen; Eigentümer und Bearbeiter lassen sich zuordnen. Der Erfüllungsgrad rechnet sich aus abschließend beantworteten Anforderungen, Risiken aus Wahrscheinlichkeit in Prozent und Auswirkung in Euro. Bestände lassen sich per Excel-Import übernehmen.