Asset-Management5. August 2026 · 6 Min. Lesezeit

CMDB light: Minimales Asset-Register aufbauen und dauerhaft pflegen

Einleitung

„CMDB“ klingt nach ServiceNow, sechsmonatigem Projekt und permanenter Pflege-Schuld. Für KMU ist das Quatsch. Was du brauchst, ist ein minimales Asset-Register: eine Liste mit Hosts, Owner, Kritikalität – mehr nicht. Dieser Artikel zeigt, wie du in einem halben Tag ein „CMDB light“ mit SQLite oder einem Git-Repo aufbaust, das im Incident sofort hilft und dauerhaft gepflegt bleibt, weil die Pflege automatisch passiert.

Warum das Thema wichtig ist

Im Incident ist die erste Frage nie „welcher Host“ – das siehst du im Log. Die ersten Fragen sind: „Wem gehört der?“, „Was läuft drauf?”, „Wie kritisch ist der?“, „Wer entscheidet, ob wir abschalten?”. Ohne Asset-Register: 30 Minuten Telefonate, niemand weiß genau Bescheid, falsche Entscheidungen unter Zeitdruck. Mit Asset-Register: 30 Sekunden Lookup. Die volle ITIL-CMDB ist Overkill – das Asset-Register ist kein Compliance-Artefakt, sondern ein operatives IR-Werkzeug. Genau das macht den Unterschied zwischen Theorie und Praxis.

Was minimal wirklich heißt

Ein gutes Asset-Register hat pro Host genau diese Felder:

Feld Beispiel Pflicht
hostname auth-prod-01 ja
ip_primary 10.20.30.40 ja
mac_primary aa:bb:cc:dd:ee:ff ja
os Ubuntu 24.04 ja
owner_team Plattform-Team ja
owner_person karl.mueller@example.com ja
criticality 1=hoch, 2=mittel, 3=niedrig ja
data_class internal / confidential / public ja
network_zone dmz / internal / management ja
purpose OAuth-Provider ja
last_seen 2026-05-03 ja (aus Discovery)
decommission_date null optional

Mehr nicht. Software-Inventory, Patch-Status, Scan-Ergebnisse leben in den jeweiligen Tools – nicht im Asset-Register. Sonst wird die Pflege zur Hauptaufgabe.

Variante 1: Git-Repo mit YAML

Für sehr kleine Umgebungen (< 200 Hosts) der einfachste Weg. Pro Host eine Datei oder ein Eintrag in einer Sammeldatei:

# assets/auth-prod-01.yaml
hostname: auth-prod-01
ip_primary: 10.20.30.40
mac_primary: aa:bb:cc:dd:ee:ff
os: Ubuntu 24.04
owner_team: Plattform-Team
owner_person: karl.mueller@example.com
criticality: 1
data_class: confidential
network_zone: dmz
purpose: OAuth-Provider
decommission_date: null

Vorteile:

Nachteile:

Variante 2: SQLite + CSV-Export

Robuster und join-fähig:

CREATE TABLE assets (
    hostname TEXT PRIMARY KEY,
    ip_primary TEXT,
    mac_primary TEXT,
    os TEXT,
    owner_team TEXT,
    owner_person TEXT,
    criticality INTEGER CHECK(criticality IN (1, 2, 3)),
    data_class TEXT,
    network_zone TEXT,
    purpose TEXT,
    last_seen DATE,
    decommission_date DATE
);

CREATE INDEX idx_owner ON assets(owner_team);
CREATE INDEX idx_zone ON assets(network_zone);

Pflege als CSV im Git, Import in SQLite per Cron:

sqlite3 assets.db <<EOF
.mode csv
.import --skip 1 assets.csv assets
EOF

Reports per SQL:

-- Wer ist Owner für DMZ-Hosts?
SELECT hostname, owner_person FROM assets
WHERE network_zone='dmz' AND decommission_date IS NULL;

-- Top-Kritikalität ohne Owner?
SELECT hostname FROM assets
WHERE criticality=1 AND owner_person IS NULL;

Im Incident: ein einziger Query, sofort klar wer informiert werden muss.

Variante 3: GLPI / Snipe-IT als Light-CMDB

Wenn du eine UI willst:

Tool Stärken Schwächen
GLPI OSS, breit, Asset + Ticketing Komplex, viele Felder
Snipe-IT Hardware-fokussiert Wenig IT-Service-Kontext
Nautobot / NetBox Network-zentrisch Steile Lernkurve
OCS Inventory Discovery + Inventory UI altertümlich

Empfehlung KMU: erst Variante 1 oder 2 produktiv haben, dann ggf. später migrieren. „Tool zuerst“ scheitert meistens.

Discovery-Pflege automatisieren

Manuell pflegen scheitert. Stattdessen mehrere Quellen automatisch in das Register kippen und Diff-Alerts auf Veränderungen schalten.

Quelle 1 – AD-Computer-Objekte

Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate `
  | Select-Object Name, IPv4Address, OperatingSystem, LastLogonDate `
  | Export-Csv -Path ad-hosts.csv -NoTypeInformation

Quelle 2 – DHCP-Leases

Get-DhcpServerv4Scope | Get-DhcpServerv4Lease `
  | Where-Object {$_.AddressState -eq 'ActiveReservation' -or $_.AddressState -eq 'Active'} `
  | Export-Csv -Path dhcp-hosts.csv -NoTypeInformation

Quelle 3 – Nmap-Scan

nmap -sn 10.20.30.0/24 -oX nmap-scan.xml

Quelle 4 – Wazuh-Agents / Defender-Devices / EDR-Inventory

API-Abfrage, JSON parsen, in CSV.

Konsolidierung

Python-Skript, das alle Quellen einliest, per IP/MAC mergt und Diff zum letzten Stand speichert. Diff-Output ist zugleich das Audit-Log.

import sqlite3, csv

con = sqlite3.connect("assets.db")
cur = con.cursor()
cur.execute("CREATE TABLE IF NOT EXISTS discovery_diff (date TEXT, change TEXT, hostname TEXT, ip TEXT)")

# pseudo
new = load_csv_sources()
old = current_assets(cur)
for change in diff(old, new):
    cur.execute("INSERT INTO discovery_diff VALUES (date('now'), ?, ?, ?)",
                (change.type, change.hostname, change.ip))
con.commit()

Alert ans IT-Team bei: neuer Host (unbekannt!), fehlender Host (decommissioned ohne Ticket?), IP-Wechsel auf kritischem Host.

Owner-Zuordnung: das schwerste Feld

owner_person ist das wichtigste Feld – und das, was am häufigsten leer bleibt. Tipps:

Kritikalität: drei Stufen reichen

Mehr als drei Stufen führt zu endlosen Diskussionen.

Stufe Definition Beispiel
1 hoch Ausfall trifft Kerngeschäft binnen 1h DC, ERP, Mail-Gateway
2 mittel Ausfall stört, aber überbrückbar Test-Stage, interner Wiki
3 niedrig Ausfall fällt erst nach Tagen auf Lab-VM, alter Print-Server

Wer die Kritikalität nicht entscheiden kann, fragt: „Geht morgens um 8 ohne den Host gar nichts mehr?“ → wahrscheinlich Stufe 1.

Asset-Register im IR nutzen

Konkretes Beispiel: SIEM-Alert auf WIN-COMP-042. IR-Verantwortlicher tippt:

SELECT hostname, owner_person, criticality, data_class, network_zone, purpose
FROM assets WHERE hostname='WIN-COMP-042';

Antwort:

WIN-COMP-042 | sara.weiss@... | 1 | confidential | internal | Finance-Workstation (DATEV)

In 5 Sekunden weiß der IR-Verantwortliche: hochkritisch, Finance-Daten, intern, Owner ist Sara, sofort anrufen.

Stolperfallen

Praxis-Checkliste

Fazit

CMDB light heißt: nicht „komplett“, sondern „nützlich“. Ein einfaches Register mit Owner und Kritikalität – automatisch via AD, DHCP und Nmap gepflegt – ist im Incident wertvoller als jede ausgefüllte ITIL-CMDB, die niemand vertraut. Die Investition ist ein halber Tag, der Gewinn dauerhaft. Wenn du heute nur eine Sache anfangen willst: ein SQLite-File mit zehn Spalten, gefüllt aus drei Discovery-Quellen, plus ein Owner-Mapping pro Subnetz. Der Rest ergibt sich.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Discovery-Skripte, SQL-Queries und CMDB-light-Workflows für KMU. Trag dich ein.

← Zurück zur Übersicht