Das Grundproblem
NIS2 verlangt nicht den Kauf eines bestimmten Werkzeugs. Gefordert ist der Nachweis von Kontrolle über Cyberrisiken, Governance, Incident-Qualifikation und Reaktionsfähigkeit.
Dieser Nachweis ist ohne verlässliche Kenntnis des Netzwerkperimeters schwierig. Teams müssen wissen, welche Assets existieren, wo sie angeschlossen sind, wer verantwortlich ist, welche Services abhängen und was zuletzt geändert wurde.
IPAM und CMDB: komplementäre Repositorys
Die CMDB beschreibt Configuration Items, Services, Beziehungen und Verantwortlichkeiten. IPAM beschreibt die Netzwerkrealität: Präfixe, Subnetze, Bereiche, IP-Adressen, DNS/DHCP-Dokumentation und Nutzungsstatus.
Sind beide verbunden, kann eine IP aus SIEM, Firewall-Log oder Schwachstellenbericht mit Service, Verantwortlichem, Standort und Business Impact verknüpft werden. Aus technischem Rohdatum wird Governance-Nachweis.
Was IPAM + CMDB für NIS2 leisten
NIS2-Programme benötigen ein Inventar, das nicht nur theoretisch ist. IPAM ergänzt die CMDB mit Netzwerknachweisen und zeigt vergessene Segmente, unverwaltete Geräte oder Bereiche ohne Verantwortlichen.
Der Wert ist praktisch: Ist ein Subnetz kritisch, exponiert oder einem sensiblen Service zugeordnet, steuert diese Information Logging, Zugriffskontrolle, Monitoring und Incident-Priorisierung.
Logging und Incident Response.
Logs sind nützlicher, wenn IP-Adressen Kontext tragen. Während eines Incidents muss schnell klar sein, ob eine IP zu Arbeitsplatz, Server, Management-Interface, Partnerverbindung oder sensibler Anwendung gehört.
Durch die Verbindung von IPAM und CMDB verkürzt teemIP die Zeit zwischen Erkennung und Qualifikation. Das ist relevant, wenn Meldefristen und Eskalationsprozesse unter Druck stehen.
IPAM ergänzt die CMDB um die Netzwerkrealität: jede Adresse, jeder Bereich und jedes Segment wird mit Asset, Verantwortlichem und Kritikalität verknüpft.
Netzwerklogs erhalten IPAM/CMDB-Metadaten: welche IP, welches Segment, welcher Service und welcher Verantwortliche.
Aus einer SIEM-IP gelangt das Team schneller zum Präfix, betroffenen Service, Owner-Team und zur Exposition.
Änderungshistorie, Zugriffsrechte, versionierte Exporte und IP-CMDB-Verknüpfungen dokumentieren die Nachweiskette.
Wo IPAM und CMDB nicht ausreichen
IPAM und CMDB ersetzen nicht EDR, NDR, Vulnerability Management, Backup, Identity Governance oder Security Monitoring. Sie liefern die strukturierte Referenz, mit der diese Kontrollen besser interpretierbar werden.
Auch ein Repository braucht Disziplin. Ohne Ownership Reviews, Synchronisation, Audit-Historie und Betriebsregeln veralten selbst gute Werkzeuge. Der Prozess ist so wichtig wie die Software.
Vier blinde Flecken bleiben zu behandeln.
Zielarchitektur
Eine robuste Zielarchitektur verbindet IPAM, CMDB, DNS/DHCP-Daten, Monitoring, Ticketing und Security-Werkzeuge. Jedes System behält seine Rolle, aber zentrale Kennungen werden geteilt.
teemIP kann die Adressierungsschicht dieser Architektur bilden. Das offene Modell und die API ermöglichen schrittweise Integration statt eines riskanten Big Bang.
Operative Checkliste
Beginnen Sie mit kritischen Subnetzen, Verantwortlichen, DNS/DHCP-Quellen und CMDB-Objekten. Definieren Sie anschließend Status, Namensregeln, Change-Validierung, regelmäßige Reviews und Audit-Exporte.
Testen Sie die Kette mit einem realen Szenario: IP aus einem Log nehmen, Subnetz finden, Service, Verantwortlichen, Exposition und letzte Änderungen identifizieren. Ist der Weg schnell und dokumentiert, wird Governance konkret.
Ein praktischer Implementierungsweg.
Eine realistische Umsetzung beginnt mit einem kleinen kontrollierten Umfang: kritische Subnetze, exponierte Services, Managementnetze und Assets, die häufig in Security-Untersuchungen auftauchen. Dieser erste Bereich liefert Wert, ohne auf ein perfektes Gesamtmodell warten zu müssen.
Ist der erste Umfang verlässlich, können Teams die Methode auf weniger kritische Zonen ausweiten, Importe automatisieren, Ticketing anbinden und regelmäßige Reviews definieren. Wichtig ist, jede neue Datenquelle verantwortlich zu machen und keinen Datenlärm zu importieren.
Was Auditoren meist benötigen.
Auditoren brauchen selten nur ein schönes Diagramm. Sie brauchen Nachweise, dass Verantwortlichkeiten bekannt sind, Änderungen verfolgt werden, Zugriffe kontrolliert sind und die Organisation erklären kann, wie ein technisches Asset einen Service unterstützt.
Ein verbundenes IPAM/CMDB-Repository hilft mit Exporten, Historie, Ownership und Beziehungen. Es reduziert die manuelle Rekonstruktion von Nachweisen in anspruchsvollen Prüfungsphasen.
- Den relevanten IPAM-Umfang abdecken: On-Premise, Niederlassungen, Cloud und entfernte Standorte.
- Jedes Netzobjekt mit einem CMDB-Asset verknüpfen: Owner, Klassifizierung und Geschäftskritikalität.
- IPAM mit DNS, DHCP, Verzeichnissen und Cloud-APIs synchronisieren, damit das Inventar aktuell bleibt.
- Netzwerkänderungen mit Antrag, Freigabe, Umsetzung und Nachweis nachverfolgen.
- SIEM-Meldungen mit IPAM/CMDB-Metadaten anreichern, um IPs schneller Services zuzuordnen.
- Den Kreis protokollierter Assets definieren und regelmäßig mit dem IPAM-Repository abgleichen.
- RBAC, MFA und regelmäßige Zugriffsreviews für IPAM- und CMDB-Administration anwenden.
- Eine vollständige Incident-Übung durchführen: SIEM-Alarm, Qualifikation über IPAM/CMDB und NIS2-Meldeweg.
Möchten Sie Ihren IPAM/CMDB-Umfang mit Blick auf NIS2 bewerten?
Ein Scoping-Workshop kann Lücken in wenigen Stunden sichtbar machen.
Scoping-Workshop anfragen