CMDB und Asset-Management: der Unterschied

Was eine CMDB ist

Die Grundlagen des IT-Asset-Managements stellen ITAM, Inventarisierung und CMDB in einer Tabelle nebeneinander. Diese Seite geht einen Schritt weiter und betrachtet die beiden Bestände selbst: was hineingehört, wo sie sich treffen und wie Daten zwischen ihnen fließen.

Die Configuration Management Database gehört zur Konfigurationsverwaltung, die ITIL 4 als eigene Praxis unter dem Namen Service Configuration Management beschreibt. Ihr Zweck ist, dass verlässliche Angaben über die Konfiguration der Dienste und der Bausteine, die sie stützen, dort verfügbar sind, wo sie gebraucht werden. Dazu gehören ausdrücklich die Beziehungen zwischen den Bausteinen. Die Anfang 2026 vorgestellte Version 5 von ITIL führt diese Praxis weiter.

Ein solcher Baustein heißt Configuration Item. ITIL versteht darunter jeden Bestandteil, der gesteuert werden muss, damit ein IT-Dienst erbracht werden kann, etwa einen Server, eine Anwendung, eine virtuelle Maschine oder den Vertrag mit einem Anbieter. Kurze Definitionen aller Begriffe stehen im ITAM-Glossar.

Den Wert einer CMDB machen die Beziehungen aus. Eine Liste von Servern ohne Beziehungen beantwortet nur Fragen, die auch ein Inventar beantwortet. Vier Arten von Beziehungen decken in kleinen und mittleren Umgebungen die meisten Fälle ab.

Die Norm ISO/IEC 20000-1 für Servicemanagementsysteme trennt beide Aufgaben ebenfalls. In der Ausgabe 2018 stehen Asset-Management und Konfigurationsmanagement als eigene Abschnitte 8.2.5 und 8.2.6 nebeneinander.

Was ein Asset-Inventar ist

Das Gegenstück ist die Praxis IT Asset Management. ITIL beschreibt ihren Zweck als Planung und Steuerung des gesamten Lebenslaufs aller IT-Assets, damit ein Haus den Wert ausschöpft, Kosten und Risiken beherrscht und über Kauf, Weiterverwendung und Aussonderung begründet entscheidet. Ein Asset ist dabei ein Bestandteil mit finanziellem Wert.

Das Asset-Inventar ist der Bestand, mit dem diese Praxis arbeitet. Es führt je Gerät Inventarnummer, Seriennummer, Kategorie, Modell, Kaufdatum, Preis, Vertrag, Status, Person und Standort, dazu die Vorgänge Ausgabe, Rücknahme, Inventur und Aussonderung. Welche sieben Felder davon Pflicht sind, begründet die IT-Inventarverwaltung.

Das Inventar enthält viele Objekte, die in keiner CMDB auftauchen, etwa Geräte im Lager, Zubehör, ausgesonderte Geräte mit ihren Nachweisen und Lizenzen ohne technische Beziehung. Der IT-Grundschutz des BSI sieht in der Anforderung OPS.1.1.1.A6 vor, dass die Übersicht auch Test-Instanzen, Reservegeräte und nicht mehr genutzte Assets erfasst. Den ersten Datensatz legt das Inventar beim Wareneingang an, lange bevor ein Gerät in Betrieb geht, wie Vom Wareneingang bis zum Rollout zeigt.

Wo sich beide Bestände treffen

Die Schnittmenge umfasst Geräte, die einen Wert haben und zugleich einen Dienst stützen. Die Tabelle ordnet typische Objekte zu.

Drei Kennungen verbinden die Bestände

Für jedes Objekt der Schnittmenge brauchen beide Bestände dieselbe Kennung. Fehlt sie, entsteht beim ersten Abgleich eine Dublette, und zwei Datensätze beschreiben dasselbe Gerät mit verschiedenen Angaben.

1. Seriennummer. Sie stammt vom Hersteller und bleibt gleich, solange das Gerät dasselbe bleibt. Sie ist deshalb der erste Schlüssel des Abgleichs.
2. Inventarnummer. Sie vergibt das eigene Haus beim Wareneingang. Sie dient als zweiter Schlüssel, wenn eine Seriennummer fehlt oder falsch ausgelesen wurde.
3. Hostname. Er ändert sich bei einer Neuinstallation und bei jeder Umbenennung. Er dient deshalb nur als Hinweis und wird allein nie als Schlüssel verwendet.

Zusätzlich hilft ein Feld für die Kennung des jeweils anderen Systems. Warum eine externe Kennung am Datensatz eine Umbenennung übersteht, erklären die Schnittstellen im IT-Asset-Management.

Wie Daten zwischen beiden fließen

Jede Anbindung braucht eine Regel: Jedes Feld hat genau ein führendes System, und Angaben fließen nur in eine Richtung. Kaufmännische Angaben entstehen im Inventar und gehen an die CMDB, darunter Eigentümer, Kostenstelle, Standort, Vertrag und das Ende der Garantie.

Technische Angaben entstehen in der Discovery oder in einer Geräteverwaltung und gehen ebenfalls an die CMDB, darunter Hostname, Betriebssystem, installierte Software und erkannte Verbindungen. Wie solche Daten in ein Inventar gelangen, beschreibt Geräte aus Intune, Jamf oder einem Netzwerkscan übernehmen.

Zwei Ereignisse verdienen eine feste Regel. Findet die Discovery ein Gerät ohne Inventardatensatz, entsteht ein Klärfall, und das Asset legt der Wareneingang an, sobald Beleg und Preis vorliegen. Bei der Aussonderung setzt das Inventar den Status mit Löschnachweis und Verwertungsnachweis, und die CMDB legt das CI still und behält seine Historie. Welche Nachweise dazugehören, steht unter Geräte aussondern.

Wann sich eine CMDB lohnt

Drei Größen entscheiden, ob sich der Aufwand einer CMDB auszahlt: die Reife des Servicemanagements, die Zahl der Dienste auf gemeinsamer Infrastruktur und die Änderungsrate. Eine vierte Größe kommt von außen, wenn eine Aufsicht oder ein Prüfer die Abbildung von Abhängigkeiten verlangt.

Für Finanzunternehmen ist die Frage zum Teil beantwortet. Artikel 8 Absatz 4 der Verordnung (EU) 2022/2554, kurz DORA, verlangt, alle Informations- und IKT-Assets zu ermitteln, die kritischen zu erfassen und ihre Konfiguration sowie die Verbindungen und Abhängigkeiten zwischen ihnen festzuhalten. Nach Absatz 6 sind diese Inventare regelmäßig und bei jeder wesentlichen Änderung zu aktualisieren. Die Verordnung gilt seit dem 17. Januar 2025.

Wer nach IT-Grundschutz arbeitet, dokumentiert ohnehin, welche Geschäftsprozesse von welchen Anwendungen abhängen, wie es der BSI-Standard 200-2 im Abschnitt 8.1.2 verlangt. Gleichartige Clients fasst derselbe Standard im Abschnitt 8.1.1 zu Gruppen zusammen. Diese Tabelle der Abhängigkeiten ist der kleinste sinnvolle Vorläufer einer CMDB und kommt ohne Datenbank aus. Welche Bestandsangaben die NIS-2-Regeln voraussetzen, behandelt NIS2 und das Asset-Management.

Warum viele CMDB-Projekte veralten

Eine CMDB veraltet selten auf einen Schlag. Sie verliert Monat für Monat an Genauigkeit, bis niemand mehr ihren Angaben traut. Sechs Muster wiederholen sich dabei, und alle liegen in der Organisation.

• Der Zuschnitt ist zu breit. Wer jeden Monitor als CI anlegt, pflegt Tausende Einträge ohne Beziehung. Die wichtigen Abhängigkeiten gehen darin unter.
• Niemand ist für eine CI-Klasse zuständig. Ohne benannte Person je Klasse, etwa für Netz, Server oder Anwendungen, veralten die Einträge, sobald die Person wechselt, die sie angelegt hat.
• Änderungen laufen am Bestand vorbei. Lässt sich eine Änderung abschließen, bevor die betroffenen CIs aktualisiert sind, stimmt die CMDB nach wenigen Monaten nicht mehr.
• Die Discovery schreibt ohne Abgleichsregeln. Jeder Scan legt dann neue Einträge an, sobald sich ein Hostname ändert, und die Zahl der Dubletten wächst.
• Die Datenqualität wird nicht gemessen. Drei Kennzahlen genügen: der Anteil der CIs mit verantwortlicher Person, der Anteil der im letzten Quartal bestätigten Beziehungen und die Zahl der Dubletten.
• Die CMDB soll das Inventar ersetzen. Dann fehlen ihr Preis, Vertrag, Lager und Aussonderung, und das Inventar entsteht nebenher in einer Tabelle neu.

Allen sechs Mustern ist gemeinsam, dass die Pflege als Projekt geplant wurde. Aktuell bleibt eine CMDB, wenn Änderungs- und Störungsprozesse sie laufend fortschreiben.

150 Beschäftigte: was zuerst kommt und was später

Angenommen ist ein Unternehmen mit 150 Beschäftigten an einem Standort, von denen ein Teil regelmäßig im Homeoffice arbeitet. Im Bestand stehen 165 Notebooks, 160 Monitore, 120 Dockingstationen, 4 physische Server mit 10 virtuellen Maschinen, 22 Netzwerkkomponenten und 11 Fachanwendungen. Die IT besteht aus drei Personen. Ein Ticketsystem ist vorhanden, ein festes Änderungsverfahren gibt es noch nicht.

Eine CMDB, die zusätzlich jedes Notebook, jeden Monitor und jede Dockingstation als CI führt, käme zum Vergleich auf 445 weitere Einträge. Sie hätte damit mehr als elfmal so viele Einträge wie die Liste aus Stufe 2, und die zusätzlichen Einträge hätten kaum Beziehungen. Jede Ausgabe und Rücknahme müsste außerdem in zwei Systemen gepflegt werden.

Stufe 3 lohnt sich in diesem Haus erst, wenn einer von drei Auslösern eintritt. Das Unternehmen führt ein Änderungsverfahren mit Freigabe ein, die Zahl der Dienste auf gemeinsamer Infrastruktur wächst deutlich, oder ein Kunde oder Prüfer verlangt die Abbildung der Abhängigkeiten. Bis dahin genügen für Stufe 2 eine gepflegte Tabelle und für Stufe 1 ein Inventar, das bewusst ohne CMDB auskommt und den Standort jedes Geräts als Referenz auf den Grundriss führt.

Häufige Fragen