CMDBs sind eine eher passive Inventarliste, die vor allem zeigt, welche Assets in einer bestimmten Umgebung vorhanden sind. Damit sie zu einer aktiven Orchestrierungsebene des Asset-Lebenszyklusmanagements und der automatisierten PKI-Integration werden können, muss zunächst betrachtet werden, was sie aktuell leisten und wo ihre Grenzen liegen.

Herausforderungen in der OT

In Operational-Technology-Umgebungen (OT) ist die Situation noch einmal komplexer. Da OT-Assets – von speicherprogrammierbaren Steuersystemen (SPS) bis hin zu Gateways – in der Regel eine Lebensdauer von zehn bis 20 Jahren haben, werden ihre Einträge in CMDBs selten aktualisiert und erfordern je nach Asset-Typ unterschiedliche Arten von Metadaten. Bei vielen OT-Assets handelt es sich zudem um ältere Legacy-Geräte, die häufig keine modernen Sicherheitsprotokolle unterstützen, einschließlich solcher, die für PKIs verwendet werden. Kurz gesagt: In der OT kommen CMDBs oftmals nicht oder nur in sehr geringem Maß zum Einsatz.

Im Purdue-Modell, einem Modellrahmen für die Segmentierung industrieller Steuerungssysteme, reichen klassische IT-CMDBs in der Praxis meist nur bis Ebene 3. Das Modell unterteilt Netzwerke in unterschiedliche Ebenen, von physischen Prozessen auf der untersten Ebene (0) bis hin zum Enterprise Business Network auf der höchsten Ebene (5). Ebene 3 des Modells umfasst in der Regel Fertigungsausführungssysteme oder OT-Server, aber die Ebene darunter (beispielsweise SPS, Sensoren oder Steuerungssysteme oder Feldbusse) ist in CMDBs üblicherweise "unsichtbar" oder abstrahiert, auch weil viele der Komponenten auf dieser Ebene nur über unzureichende Konnektivität, Schnittstellen und Möglichkeiten zur Vernetzung mit dem Rest des Netzwerks, einschließlich CMDBs, verfügen.

Dass genau diese Ebenen in CMDBs oftmals unsichtbar sind, kann zu konkreten Sicherheitslücken und damit zu Risiken führen, die weit über unvollständige Asset-Dokumentation hinausgehen. Vergessene, aber aktive Assets, deren Zertifikate, Anmeldedaten oder Berechtigungen nie widerrufen wurden und deshalb noch valide sind, können beispielsweise schnell zum unerkannten, weil unsichtbaren Einfallstor für Angreifer werden.

Ziel: CMDB als Orchestrierungsebene

Eine CMDB als Orchestrierungsebene für Ereignisse im Lebenszyklus von Assets ermöglicht, dass jede Änderung an einem Asset nicht nur einen Eintrag in der CMDB darstellt, sondern einen automatisierten Prozess auslösen kann. Mit diesem Ansatz könnte beispielsweise ein digitales Zertifikat automatisch angefordert und installiert werden, wenn ein neuer Server bereitgestellt wird, oder ein Zertifikat ließe sich automatisch widerrufen, wenn ein Asset außer Betrieb geht. Auch komplexere Automatisierungsprozesse sind auf diese Weise möglich, wie beispielsweise die Synchronisierung von Identitätsdatensätzen und die Aktualisierung von PKI-Metadaten, wenn sich ein Asset-Attribut wie der Hostname oder der Eigentümer ändert.

Dieser Ansatz macht eine CMDB zu einem zentralen Knotenpunkt der digitalen Identität von Unternehmensressourcen für das Management und schafft ein System, in dem das Zertifikat einer Ressource direkt mit dieser verknüpft ist und die Außerbetriebnahme einer Ressource automatisch die Angriffsfläche des Netzwerks und damit des gesamten Unternehmens reduziert. Dieser Ansatz beseitigt zwar Komplexität nicht komplett, reduziert sie jedoch deutlich, indem er den Lebenszyklus von Ressourcen und den Lebenszyklus von Zertifikaten enger aufeinander abstimmt.

Warum PKI und CLM unverzichtbar sind

Die Grundlage für diesen Ansatz bilden PKI und das Zertifikatslebenszyklusmanagement (CLM). In modernen Unternehmensumgebungen benötigen viele Assets eine digitale Identität, von der Transport-Layer-Security für die Kommunikation über Gerätezertifikate für die Authentifizierung, die JSON-Websignatur für die Datenintegrität bis hin zur Codesignierung. Manuelle Zertifikatsverwaltung lässt sich jedoch nicht ausreichend skalieren, um Umgebungen mit Zehntausenden von Assets abzubilden.

CLM-Werkzeuge finden in solchen Fällen Verwendung, um die Ausstellung, Erneuerung und Sperrung von Zertifikaten zu automatisieren. Kommt eine CLM-Software jedoch isoliert (ohne Integration in eine CMDB) zum Einsatz, besteht die Gefahr, dass Zertifikate ohne entsprechende Assets gelistet werden oder Assets nicht über gültige Zertifikate verfügen. Daher ist eine Integration von CLM in eine CMDB von entscheidender Bedeutung, da eine CMDB den notwendigen Kontext für die Automatisierungsprozesse bereitstellt, die ein CLM-Tool ermöglicht.

In der Praxis würde ein Zertifikatsmanagement-Workflow ohne Integration von CMDB und PKI beziehungsweise CLM größtenteils manuell ablaufen. Wenn ein vorhandenes Gerät dann beispielsweise ein neues Zertifikat benötigt, muss der Administrator dies durch regelmäßige Überprüfungen, oftmals in separaten Tools, erkennen und den Prozess manuell auslösen, manchmal durch Weiterleitung an ein anderes Team. Sobald das neue Zertifikat ausgestellt ist, muss es abgerufen, auf dem Gerät installiert und auf Funktionalität überprüft werden – ein repetitiver, fehleranfälliger Prozess, insbesondere wenn er auf große Geräteflotten ablaufen muss.

Mit einer Integration von CMDB und PKI beziehungsweise CLM wird derselbe Workflow transparent und verlässlich automatisierbar. Zertifikatsmetadaten, einschließlich der Informationen, wann ein Zertifikat abläuft, landen zusammen mit den Asset-Daten direkt in der CMDB. Administratoren müssen also nur noch ein zentrales Tool nutzen, um Geräte und Zertifikate zu verwalten. Läuft ein Zertifikat aus, kann die CMDB einen automatisierten Workflow anstoßen, der über die integrierte PKI- oder CLM-Plattform einen Certificate Signing Request erzeugt und an die zuständige Zertifizierungsstelle übermittelt. Ist das neue Zertifikat ausgestellt, wird die CMDB einschließlich Asset-Datensatz automatisch aktualisiert. Sind die Wartungsfenster des Geräts ebenfalls in der CMDB hinterlegt, wird dieser Prozess zudem automatisch so terminiert, dass er nur in diesem Zeitfenster stattfindet, was ungeplante oder längere Ausfallzeiten vermeidet.

Auswirkungen und Grenzen der Integration

Idealerweise ist jedes aktive Asset mit einem verwalteten digitalen Zertifikat verknüpft, und jedes Zertifikat lässt sich eindeutig einem Asset oder einem konkreten Dienst zuordnen. Auf diese Weise schaffen IT-Verantwortliche Transparenz über digitale Identitäten und stellen sicher, dass Zertifikate stets im Kontext der tatsächlich betriebenen Systeme und Services verwaltet werden. Damit sinkt die Wahrscheinlichkeit menschlicher Fehler, da automatisierte Prozesse diese durch den Verzicht auf manuelle Ticketing- oder Ad-hoc-Anfragen reduzieren.

Die allgemeine Ausfallsicherheit der Umgebung wird auch verbessert, da abgelaufene oder vergessene Zertifikate keine Störungen oder Ausfälle mehr verursachen können. Zudem vereinfacht sich die Einhaltung verschiedener Industriestandards wie NIS2, BaFin-Vorschriften oder IEC 62443, die ein starkes Identitätsmanagement erwarten.

Selbstverständlich bringt die Implementierung einer integrierten CMDB-CLM-Architektur eine Reihe von Herausforderungen mit sich. Zum einen die Datenqualität der CMDB: Eine erfolgreiche Automatisierung der entsprechenden Prozesse ist nur dann möglich, wenn die CMDB korrekt ist. Darüber hinaus handelt es sich bei OT-Assets häufig um ältere Geräte, die moderne digitale Zertifikate nicht unterstützen. In solchen Fällen muss die Integration Behelfslösungen ermöglichen. So können etwa vorgeschaltete Systeme oder Gateways die Zertifikatsfunktionen übernehmen, um auch nicht zertifikatsfähige Geräte in entsprechende Sicherheitsprozesse einzubinden.

Auch die Zuständigkeit für die entsprechenden Prozesse sollte im Voraus definiert werden, insbesondere die Frage, wer für die Asset-Lebenszyklusdaten verantwortlich ist: IT-, OT- oder Sicherheitsteams, denn Prozessautomatisierung ohne klar definierte Governance versagt üblicherweise bereits nach kurzer Zeit. Und nicht zuletzt kann eine API-basierte Integration einer CMDB und einer CLM-Software ein langwieriger und komplexer Prozess sein, der sowohl Investitionen als auch Anpassungen des Unternehmensnetzwerkes und der -systeme erfordert, weshalb sie vor Beginn sorgfältig geplant werden sollte.

Fazit – vom Inventar zur Orchestrierung

Durch die Verknüpfung von CMDB-Daten mit PKI und einer CLM-Plattform können Unternehmen sicherstellen, dass jedes aktive Asset in ihrem Netzwerk über eine entsprechende digitale Identität verfügt. Damit lässt sich der Lebenszyklus von Zertifikaten automatisieren. Auch Ausfälle und menschliche Fehler lassen sich so reduzieren und Regulierungsbehörden so mit konkreten Nachweisen für digitale Resilienz und nicht nur für Compliance beliefern. Im Bereich OT sind die Vorteile noch konkreter: Eine als Orchestrierungsebene implementierte CMDB kann hier zu weniger ungeplanten Betriebsunterbrechungen, sichererem Fernzugriff, effizienterer Produktion und insbesondere bei der Nutzung von vielen Legacy-Geräten zu weniger Angriffsfläche und damit mehr Sicherheit führen. (ln)

Über die Autorin: Létitia Combes ist Co-Gründerin und Managing Director bei BxC Security.