Zertifikatsüberwachung war als Produktkategorie schon immer ein herausfordernder Markt. Zum einen, weil ein Großteil dieser Funktionalität in Netzwerküberwachungs-Tools eingebettet ist, und zum anderen, weil Unternehmen oft jemanden im Team haben, der schnell ein oder zwei Skripte schreibt und die Aufgabe damit als erledigt betrachtet. Zumindest ist das die Absicht.
In der Praxis funktionieren diese Ansätze nie wirklich gut, selbst wenn sie einige Bedürfnisse abdecken. Die Ursache liegt darin, dass Zertifikatsüberwachung eines dieser Probleme ist, die von außen einfach aussehen; aber bei Public Key Infrastructures (PKIs) ist nichts einfach, und die meisten Organisationen lernen das immer wieder neu, während sie mit ihren Skripten experimentieren.
Red Sift bietet eine dedizierte Plattform für Zertifikatsüberwachung und wir werden oft gebeten zu erklären, was unser Produkt besser kann als der Status quo. Ziel dieses Blogbeitrags ist es, den aktuellen Stand der Zertifikatsüberwachung zu diskutieren, damit klarer wird, wie viel Aufwand in die Entwicklung eines guten Produkts fließt.
Kann Certificate Lifecycle Management bei der Zertifikatsüberwachung helfen?
Zertifikatsüberwachung wird oft als Teil der Kategorie Certificate Lifecycle Management (CLM) betrachtet, die in den letzten Jahren zunehmend an Popularität gewonnen hat. CLM-Tools sind für die Zertifikatsorchestrierung konzipiert. Anbieter solcher Produkte behaupten ebenfalls, Überwachungsfunktionen zu bieten, aber meiner Erfahrung nach lassen auch diese viel zu wünschen übrig. Es ist kontraintuitiv, aber man würde erwarten, dass CLM-Tools gute Zertifikatsüberwachungsfunktionen haben, oder?
Im Fall von CLM liegt die Ursache darin, dass der primäre Zweck dieser Tools darin besteht, Zertifikate zu verwalten. Das ist keine leichte Aufgabe, denn es gibt eine enorme Vielfalt an Produkten, die Zertifikate nutzen. CLM-Entwickler verbringen den Großteil ihrer Zeit damit, Automatisierungsintegrationen zu implementieren, wodurch ihnen weniger Zeit bleibt, sich auf die Überwachung zu konzentrieren, die dann oft nur als Zusatz zum Hauptprodukt hinzugefügt wird.
In der Praxis bieten CLMs möglicherweise Einblick in die Zertifikate unter ihrer Kontrolle, aber das ist nur ein Bruchteil aller Zertifikate, die eine Organisation verwendet.
Wie sieht Zertifikatsautomatisierung in der Praxis aus?
Der Traum von CLM ist, dass man ein einziges Produkt einsetzt, das volle Kontrolle über alle Zertifikate bietet. In der Praxis ist das sehr schwer zu erreichen. Ein Grund dafür ist, dass Automatisierung die Integration mit vielen verschiedenen Plattformen erfordert, und kein CLM kann Unterstützung für alles beanspruchen. Ein kleines Unternehmen kommt vielleicht mit einem einzigen, genau passenden CLM aus, aber ein größeres Unternehmen wird unweigerlich mehrere CLMs haben, entweder weil sie für ihre besten Funktionen benötigt werden (z. B. Integration mit einer bestimmten wichtigen privaten PKI) oder aufgrund von Fusionen und Übernahmen. Hinzu kommen CDNs und ausgelagerte Server. Und dann noch ACME, das mittlerweile in vielen Fällen standardmäßig bereitgestellt wird und im großen Maßstab zu teuer ist, um es mit einem CLM zu verbinden, selbst wenn dies unterstützt wird.
Das Ergebnis ist, dass man am Ende mehrere CLMs und mehrere ACME-Bereitstellungen hat, aber trotzdem nicht näher an voller Sichtbarkeit und einheitlicher Überwachung ist. Wenn überhaupt, machen mehrere CLMs dies noch schwieriger.
Die Lösung liegt in einer dedizierten Zertifikatsüberwachung
Unser Ansatz besteht darin, eine dedizierte Plattform für Zertifikatsüberwachung bereitzustellen, bei der wir unsere Entwicklungszeit darauf verwenden, sehr gut in unserem Kernfunktionsumfang zu sein. Wie sieht das konkret aus? Betrachten wir folgende übergeordnete Aspekte:
- Automatisierte Infrastrukturerkennung und tiefgehende Infrastrukturüberwachung; diese Aspekte sind notwendig, um nicht auf manuelle Arbeit angewiesen zu sein, die zeitaufwendig ist und in ihrem Ergebnis begrenzt bleibt. Wir haben einen separaten Blogbeitrag mit weiteren Informationen zu diesem Thema.
- Certificate-Transparency-Überwachung für umfassende Sichtbarkeit aller ausgestellten Zertifikate, die sowohl bestehende Zertifikate als auch neue Ausstellungen in Echtzeit abdeckt. Weitere Details in diesem früheren Blogbeitrag.
- Kryptografie und PKI als Kernkompetenzen, was die Unterstützung wichtiger Protokolle und deren Konfiguration sicherstellt, mit dem Ziel, ein kryptografisches Inventar aufzubauen. Angesichts der vielen Veränderungen in diesem Bereich erfordert allein das Schritthalten erheblichen Entwicklungsaufwand, für Funktionalität, die genau in unserem Kernbereich liegt.
- DevOps-Tools für Ad-hoc-Prüfungen und Empfehlungen zu einer Vielzahl von Konfigurationsoptionen, einschließlich TLS, PKI, HSTS, CAA, DNSSEC, DANE und weiteren.
Es geht uns hier nicht darum, eine Reihe von Funktionen aufzuzählen, sondern hervorzuheben, wie ein gutes Tool für diesen komplexen Anwendungsfall von Grund auf konzipiert und entwickelt werden muss. Unsere Erkennungsfähigkeiten konzentrieren sich beispielsweise zunächst auf die Infrastruktur, und darauf aufbauend fügen wir eine Zertifikatserkennung hinzu, die nahtlos über alle CAs hinweg funktioniert, ganz ohne manuellen Aufwand. Anschließend schichten wir aktive Netzwerküberwachung darüber, um feststellen zu können, was wo verwendet wird, sowie um Beziehungen zu Drittanbietern zu entdecken.
Was wir von unseren Kunden hören, ist, dass sie unsere Sichtbarkeit schätzen, nicht nur wegen der Informationen, die sie liefert, sondern auch als Möglichkeit, ihre Bestände zu verstehen, um andere Aufgaben planen zu können, etwa die Beschaffung von CLMs, die Bereitstellung privater PKIs sowie die Bewertung ihrer Automatisierungs- und Post-Quanten-Bereitschaft. Es schadet auch nicht, dass sich unsere Plattform sehr einfach bereitstellen lässt und schnell Ergebnisse liefert.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.




