CMDB als Orchestrierungsplattform: PKI und Zertifikate im Griff

In vielen Unternehmen dienen CMDBs heute vor allem als passive Inventarlisten. Sie liefern einen Überblick darüber, welche Assets in einer Umgebung vorhanden sind, bleiben jedoch in ihrer Funktion häufig auf die reine Dokumentation beschränkt.

Für moderne Sicherheitsanforderungen reicht das nicht aus.

Um einen echten Mehrwert zu schaffen, müssen sich CMDBs weiterentwickeln – von statischen Verzeichnissen hin zu aktiven Orchestrierungsebenen, die Asset-Lebenszyklen steuern und automatisiert mit PKI-Systemen interagieren. Dafür ist es jedoch notwendig, sowohl ihre aktuellen Fähigkeiten als auch ihre Grenzen genauer zu betrachten.

Komplexität in OT-Umgebungen

Besonders deutlich werden diese Herausforderungen in der Operational Technology (OT).

OT-Assets – etwa speicherprogrammierbare Steuerungen (SPS), Gateways oder industrielle Steuerungssysteme – haben in der Regel Lebenszyklen von zehn bis zwanzig Jahren. Entsprechend sind ihre Einträge in CMDBs häufig veraltet oder unvollständig. Zudem unterscheiden sich die benötigten Metadaten je nach Asset-Typ erheblich, was eine Standardisierung erschwert.

Hinzu kommt der hohe Anteil an Legacy-Systemen. Viele OT-Geräte unterstützen keine modernen Sicherheitsprotokolle – insbesondere keine, die für PKI-basierte Identitätsmechanismen erforderlich sind. Entsprechend ist der Einsatz von CMDBs in OT-Umgebungen oft eingeschränkt oder uneinheitlich.

Begrenzte Sichtbarkeit im Purdue-Modell

Die strukturellen Grenzen von CMDBs werden besonders im Kontext des Purdue-Modells deutlich, das industrielle Netzwerke in verschiedene Ebenen unterteilt.

Während klassische IT-CMDBs in der Praxis meist bis Ebene 3 reichen – also etwa bis zu Manufacturing Execution Systems oder OT-Servern – bleiben darunterliegende Ebenen häufig unberücksichtigt. Komponenten wie SPS, Sensoren oder Feldgeräte sind oft entweder abstrahiert oder gar nicht erfasst.

Diese fehlende Sichtbarkeit ist nicht nur ein Dokumentationsproblem, sondern birgt konkrete Sicherheitsrisiken. Assets, die nicht mehr aktiv verwaltet werden, aber weiterhin in Betrieb sind, können über gültige Zertifikate, Zugangsdaten oder Berechtigungen verfügen. Ohne entsprechende Transparenz entstehen so potenzielle, unerkannte Angriffsflächen.

Von der Dokumentation zur Orchestrierung

Wird eine CMDB zur Orchestrierungsplattform weiterentwickelt, verändert sich ihre Rolle grundlegend.

Anstatt Änderungen lediglich zu dokumentieren, kann sie Prozesse aktiv anstoßen. So kann beispielsweise bei der Bereitstellung eines neuen Assets automatisch ein digitales Zertifikat angefordert und installiert werden. Ebenso lässt sich bei der Außerbetriebnahme eines Assets das zugehörige Zertifikat automatisch widerrufen.

Darüber hinaus sind weitergehende Automatisierungen möglich, etwa die Synchronisierung von Identitätsdaten oder die Aktualisierung von PKI-Metadaten bei Änderungen von Asset-Attributen wie Hostnamen oder Eigentümern.

Die CMDB wird damit zu einem zentralen Knotenpunkt für die Verwaltung digitaler Identitäten. Zertifikate sind direkt mit Assets verknüpft, und deren Lebenszyklen werden konsistent abgebildet. Die Komplexität verschwindet dadurch nicht vollständig, wird jedoch deutlich reduziert, da Asset- und Zertifikatslebenszyklen enger miteinander verzahnt sind.

Die Rolle von PKI und CLM

Eine solche Architektur setzt eine enge Integration mit PKI und Zertifikatslebenszyklusmanagement (CLM) voraus.

In modernen IT- und OT-Umgebungen kommen digitale Zertifikate vielfältig zum Einsatz – etwa zur Absicherung von Kommunikation über TLS, zur Geräteauthentifizierung, zur Sicherstellung der Datenintegrität oder beim Code Signing. Eine manuelle Verwaltung dieser Zertifikate ist bei großen Asset-Beständen jedoch nicht mehr praktikabel.

CLM-Lösungen ermöglichen die automatisierte Ausstellung, Erneuerung und Sperrung von Zertifikaten. Ohne Integration in eine CMDB fehlt ihnen jedoch der notwendige Kontext. Dies kann dazu führen, dass Zertifikate ohne zugehörige Assets existieren oder Assets nicht über gültige Zertifikate verfügen.

Die Integration von CLM und CMDB schafft hier Abhilfe: Die CMDB liefert den Kontext, während CLM die Automatisierung ermöglicht.

Von manuellen Prozessen zur Automatisierung

Ohne Integration verlaufen Zertifikatsmanagement-Prozesse weitgehend manuell.

Administratoren müssen regelmäßig den Status von Zertifikaten prüfen, oft über mehrere Tools hinweg, und Erneuerungen selbst anstoßen. Dies kann zusätzliche Abstimmungen zwischen Teams erfordern sowie die manuelle Installation und Überprüfung von Zertifikaten – ein zeitaufwendiger und fehleranfälliger Prozess.

Durch eine integrierte CMDB- und PKI/CLM-Architektur lassen sich diese Abläufe vollständig automatisieren.

Zertifikatsmetadaten – etwa Ablaufdaten – werden direkt in der CMDB zusammen mit den Asset-Daten gespeichert. Bei drohendem Ablauf kann die CMDB automatisch einen Erneuerungsprozess starten, einen Certificate Signing Request (CSR) erzeugen und an die zuständige Zertifizierungsstelle übermitteln. Nach Ausstellung wird das Zertifikat automatisch bereitgestellt und der Asset-Datensatz aktualisiert.

Sind Wartungsfenster definiert, können diese Prozesse entsprechend eingeplant werden, um Betriebsunterbrechungen zu vermeiden.

Vorteile und praktische Grenzen

Im Idealfall ist jedes aktive Asset mit einem verwalteten digitalen Zertifikat verknüpft, und jedes Zertifikat lässt sich eindeutig einem Asset oder einem Dienst zuordnen. Dadurch entsteht Transparenz über digitale Identitäten und eine konsistente Verwaltung.

Die Vorteile liegen auf der Hand:

• Reduzierung menschlicher Fehler
• Vermeidung von Ausfällen durch abgelaufene Zertifikate
• Erleichterte Einhaltung von Standards wie NIS2, IEC 62443 oder BaFin
  

Gleichzeitig sind auch Herausforderungen zu berücksichtigen.

Die Datenqualität der CMDB ist entscheidend: Automatisierung funktioniert nur auf Basis korrekter und vollständiger Daten. Zudem unterstützen viele OT-Altgeräte keine zertifikatsbasierte Sicherheit. In solchen Fällen müssen Zwischenlösungen, etwa Gateways, eingesetzt werden.

Ebenso wichtig ist eine klare Governance. Zuständigkeiten für Asset-Lebenszyklusdaten müssen eindeutig geregelt sein – zwischen IT, OT und Security. Ohne klare Verantwortlichkeiten sind automatisierte Prozesse langfristig nicht stabil.Nicht zuletzt stellt die Integration von CMDB und CLM über APIs einen technisch anspruchsvollen und oft aufwendigen Prozess dar, der sorgfältige Planung erfordert.

Fazit: Vom Inventar zur Orchestrierung

Durch die Integration von CMDB, PKI und CLM können Unternehmen ihre Asset-Verwaltung grundlegend weiterentwickeln.

Jedes Asset erhält eine digitale Identität, und der Lebenszyklus von Zertifikaten wird automatisiert gesteuert. Dadurch lassen sich Risiken reduzieren, manuelle Aufwände minimieren und die betriebliche Resilienz erhöhen.

Gerade in OT-Umgebungen sind die Effekte besonders deutlich: Weniger ungeplante Ausfälle, sicherer Fernzugriff und eine stabilere Produktion – insbesondere in Infrastrukturen mit hohem Legacy-Anteil.