Tickende Zeitbombe: Excel erkennt keine Zertifikatsrisiken

Noch immer verwalten viele Banken ihre digitalen Zertifikate mit Excel-Listen, obwohl die regulatorische Sprengkraft längst bekannt ist. Das ist nicht nur ineffizient – es ist riskant. Fakt ist: Ohne ein zentrales Certificate Lifecycle Management (CLM) lassen sich weder Verfügbarkeiten garantieren noch Schlüsselwechsel sauber orchestrieren. Die technische Integration solcher Lösungen ist durchaus komplex – und erfordert mehr als ein paar REST-Calls.

Autor: Dirk Strauch, Managing Consultant Cyber Security bei NTT Data DACH  

In modernen Bankarchitekturen stützen sich zentrale Geschäftsprozesse, APIs und Anwendungen auf sichere Kommunikation per TLS. Hunderte, teils Tausende Zertifikate sorgen dafür, dass Verbindungen verschlüsselt und Maschinen identifiziert werden können. Doch der Überblick fehlt vielerorts. Der Lebenszyklus eines Zertifikats – von der Beantragung über die Ausstellung und Verlängerung bis zur Stilllegung – wird häufig manuell gesteuert, oft mithilfe von Excel-Listen. Was das bedeutet, kann sich jeder ausmalen. Werden Zertifikate manuell erfasst und verwaltet, sind Fehler quasi vorprogrammiert. Auch das Handling über Lösungen für das IT-Service-Management oder andere Ticketsysteme bieten keine zufriedenstellende Lösung. Die Folge: Zertifikate laufen unbemerkt ab, Services fallen aus, SLAs werden verletzt.

DORA macht damit Schluss. Und die BaFin ebenfalls: Sie hat der „individuellen Datenverarbeitung“ (IDV) im Zusammenhang mit kritischen Infrastrukturen den Kampf angesagt. Hinzu kommt: Im Laufe dieses Jahres werden TLS-Zertifikate nur noch mit einer Gültigkeit von 90 Tagen statt wie bisher 13 Monaten ausgestellt. Damit steigt der Druck auf IT-Abteilungen, denn das Risiko von Betriebsunterbrechungen, Systemausfällen und Sicherheitsrisiken durch menschliches Versagen nimmt analog dazu zu.

Ein CLM deckt blinde Flecke auf

Hier kommt ein zentrales Certificate Lifecycle Management (CLM) ins Spiel. Es ersetzt keine PKI (Public Key Infrastructure), sondern ergänzt diese – als zentrale Plattform zur Verwaltung aller Zertifikate unabhängig von Aussteller, System oder Anwendung. Drei zentrale Aspekte sind dabei wichtig: Inventarisierung, Monitoring und (Teil-)Automatisierung. Im ersten Schritt geht es darum, Transparenz zu schaffen. Welche Zertifikate sind im Einsatz, an welchen Stellen und mit welchen Eigenschaften? Ein CLM-System ermöglicht dies über dedizierte Scans. In netzwerkbasierten Szenarien werden Agenten in den relevanten Segmenten installiert. Diese scannen definierte IP-Bereiche auf den üblichen Zertifikats-Ports wie 443, 8443 oder 636. Dabei zeigt sich oft, dass deutlich mehr Zertifikate im Umlauf sind als ursprünglich angenommen – nicht selten ein Vielfaches der geschätzten Anzahl. Besonders kritisch sind selbstsignierte Zertifikate, die in Testszenarien entstehen und später ungeplant produktiv gehen. Solche „vergessenen“ Zertifikate gefährden im Ernstfall den Betrieb unternehmenskritischer Systeme.

Bei selbst entwickelten Anwendungen müssen lediglich bestimmte IP-Adressen gescannt werden, dies ist von Bank zu Bank sehr individuell. Aber auch Zertifikate, die nicht über das Netzwerk erreichbar sind – zum Beispiel innerhalb lokaler Applikationen –, lassen sich mit einem CLM erfassen. Hier kommen agentenbasierte Verfahren oder Service-Accounts zum Einsatz, die lokale Zertifikatspeicher wie Java Keystores auslesen.

Automatisierter Austausch je nach Kritikalität

Auf Basis der Inventarisierung lassen sich dann Regeln für das Monitoring definieren. Im einfachsten Fall bedeutet das: rechtzeitige Benachrichtigungen vor Ablauf eines Zertifikats – beispielsweise 90, 30 und fünf Tage vorher, per E-Mail oder über ein Ticket-System wie ServiceNow.

Darüber hinaus erkennt ein CLM auch kryptografische Schwachstellen, etwa veraltete Algorithmen oder zu kurze Schlüssellängen, die nicht mehr BSI-konform sind.”

Welche Ereignisse wie gemeldet werden, lässt sich individuell definieren – ebenso wie die Eskalationsstufen. Verwaltung und Austausch können auf Wunsch auch mit Approval-Prozessen kombiniert werden, zum Beispiel bei kostenpflichtigen Zertifikaten, für die ein Kostenstellenverantwortlicher zustimmen muss.

Ob ein Zertifikat automatisch erneuert wird, hängt von der Kritikalität der Anwendung und den Vorgaben des Unternehmens ab. Viele Banken erledigen bei den Core-Applikationen die Erneuerung lieber manuell, um Probleme sofort zu erkennen. CLM-Systeme ermöglichen jedenfalls je nach Policy eine vollständige oder teilautomatisierte Erneuerung – entweder einzeln oder gruppenbasiert. Die Umsetzung erfolgt auf Basis gängiger Standards wie ACME (zum Beispiel Let’s Encrypt), SCEP oder CMP/EST. Bei Standardlösungen wie Load-Balancern, Firewalls oder Applikationen bekannter Hersteller bieten viele CLMs direkte Integrationen. In komplexeren Fällen kommen REST-APIs oder Skriptintegration zum Einsatz – insbesondere dann, wenn Eigenentwicklungen im Spiel sind.

Wichtig ist zudem die zeitliche Steuerung: Viele Finanzinstitute definieren sogenannte Change Windows, zum Beispiel am ersten Samstag im Monat von 23 bis 3 Uhr, wenn ohnehin größere Upgrades anstehen. Ein automatisierter Zertifikatsaustausch sollte sich diesen Wartungsfenstern anpassen lassen, um Kontrollverlust und Betriebsrisiken zu vermeiden.

Excel hat ausgedient – und das ist auch gut so

Die technische Integration eines CLM-Systems ist nicht trivial. Die meisten Anbieter liefern sowohl On-Premises- als auch SaaS-Varianten, die in allen Fällen Agenten im Zielnetzwerk benötigen – auch aus Sicherheitsgründen. Der Zugriff erfolgt dabei nicht vom zentralen System auf die Agenten, sondern umgekehrt – über herstellerspezifische Protokolle. Neben der technischen Einrichtung braucht es auch prozessuale Erfahrung insbesondere bei der Feinjustierung von Regeln, der Definition von Workflows und der Schulung des Betriebspersonals. Eine grafische Oberfläche allein reicht nicht aus, um komplexe Konfigurationen wie Zertifikatsgruppen, Genehmigungsprozesse oder Ausnahmebehandlungen sauber umzusetzen.

Die Definition sinnvoller Monitoring- und Automatisierungsregeln ist in der Regel ein iterativer Prozess mit steiler Lernkurve.”

Wird die finale Warnmeldung beispielsweise rund um Brückentage verschickt, geht sie oft unter.

Die Zeiten, in denen man Zertifikate in Tabellen pflegte, sind vorbei. Mit Vorgaben wie DORA wird das strukturierte Management digitaler Identitäten zur Pflichtdisziplin in der IT. Banken, die das erkannt haben, setzen auf CLM-Systeme, die sich tief in ihre Infrastruktur einfügen – und Excel endlich in Rente schicken. Angesichts der bevorstehenden Änderung, dass SSL/TLS-Zertifikate nur noch 90 Tage gültig sind, ist die Implementierung eines automatisierten Prozesses relevanter denn je.Dirk Strauch, NTT Data