TL;DR: ILM führt Signing und RFC-3161-Zeitstempel jetzt selbst durch – mit Signing-Profilen, Datensätzen pro Vorgang und authentifizierten Zeitstempel-Endpunkten. Das bedeutet ein Inventar, ein Autorisierungsmodell und einen Audit-Trail für Zertifikate, Schlüssel, Secrets, Signaturen und Zeitstempel.
Signing und Zeitstempel gehören normalerweise zu einem anderen System. Deshalb kann niemand mit einer einzigen Abfrage beantworten, welche kryptografischen Vorgänge eine Organisation im letzten Monat durchgeführt hat.
Fragen Sie ein Security-Team, wo seine Zertifikate liegen, und Sie erhalten meist eine klare Antwort. Fragen Sie, wo die Signierschlüssel liegen, wer sie letzte Woche verwendet hat und welche Zeitstempelinstanz das Ergebnis gestempelt hat, und die Antwort kommt in Fragmenten. Zertifikate liegen auf einer Plattform. Signing läuft anderswo. Timestamping ist eine URL, die vor Jahren jemand konfiguriert hat.
Keines dieser Systeme ist für sich genommen falsch. Doch an den Übergängen zwischen ihnen scheitert Governance unbemerkt. Jedes System hat sein eigenes Identitätsmodell, sein eigenes Logformat und seine eigene Vorstellung davon, was ein Operator tun darf.
ILM schließt diese Lücken bereits seit mehreren Releases. Zuerst kamen Zertifikate, dann kryptografische Schlüssel, dann Secrets und danach Cryptographic Bills of Materials. Signing und Timestamping sind die neuesten Funktionen – und genau diese liegen am häufigsten außerhalb der Plattform.
Signing-Profile definieren das Wie, Signing-Datensätze belegen das Was
Signing in ILM beginnt mit einem Signing-Profil. Dort liegt die Konfiguration: welcher Schlüssel, unter welchem Token-Profil und mit welchen Einschränkungen. Da das Profil ein verwaltetes Objekt ist, übernimmt es das Autorisierungsmodell der Plattform, statt ein eigenes zu definieren.
Dann kommt der Teil, der den Betrieb ermöglicht. Jeder Signiervorgang erzeugt einen Signing-Datensatz. Jedes Signing-Profil stellt einen Endpunkt bereit, der seine Datensätze auflistet, und das Plattform-Dashboard zeigt Signing-Statistiken neben den bereits vorhandenen Zertifikats- und Schlüsselkennzahlen an.
Damit wird aus „wer hat was, wann und mit welchem Schlüssel signiert?“ eine Abfrage statt einer Untersuchung. Dieser Unterschied zählt bei einem Audit – und noch mehr bei einem Sicherheitsvorfall. In der Praxis ist eine Signing-Funktion, die ihre eigene Historie nicht liefern kann, eine Funktion, die Sie nicht verteidigen können.
ILM implementiert außerdem die Cloud Signature Consortium API als separate Komponente, sodass Remote-Signing-Clients mit CSC-Unterstützung einen standardisierten Zugang haben.
Zeitstempel, die denselben Standard sprechen wie Ihre vorhandenen Werkzeuge
Eine Signatur ohne vertrauenswürdige Zeitangabe ist schwächer, als sie aussieht. Sobald das Signaturzertifikat abläuft, wird es schwierig nachzuweisen, dass die Signatur zu einem Zeitpunkt existierte, als das Zertifikat noch gültig war. Timestamping ist daher keine optionale Ergänzung zum Signing, sondern ein Bestandteil dauerhafter Signaturen.
ILM verarbeitet Timestamping über TSP-Profile und eine verwaltete Zeitstempel-Engine. Die Engine führt den Vorgang aus und aufrufbare RFC-3161-Endpunkte stellen ihn bereit. Da diese Endpunkte dem Standard entsprechen, funktionieren vorhandene Clients und Build-Tools ohne Änderungen.
Der Zugriff wird korrekt kontrolliert und nicht nur über die Netzwerkposition. TSP-Profile enthalten Authentifizierungsmethoden und Basic-Credentials, und vor den Zeitstempel-Endpunkten sitzt ein eigener Authentifizierungsfilter. Außerdem hält ein TSP-Profil-Cache die Profilsuche vom Request-Pfad fern – wichtig, wenn eine Pipeline Tausende Artefakte stempelt.
Was Konsolidierung Ihnen tatsächlich bringt
Plattformkonsolidierung lässt sich leicht behaupten und ebenso leicht überverkaufen. Deshalb hier die konkrete Version – als Unterschiede statt als Adjektive.
| Aspekt | Getrennte Systeme | Eine Plattform |
|---|---|---|
| Inventar | Zertifikate hier, Signierschlüssel dort, Zeitstempel-Konfiguration anderswo | Ein Inventar für Zertifikate, Schlüssel, Secrets, Signaturen und Zeitstempel |
| Autorisierung | Jedes System hat eigene Rollen und eine eigene Definition eines Operators | Ein Autorisierungsmodell, einschließlich einer schreibgeschützten Auditor-Rolle |
| Audit-Trail | Mehrere Logformate, die im Nachhinein manuell korreliert werden | Signing-Datensätze und Ereignisverlauf am selben Ort wie der Zertifikatsverlauf |
| Schlüsselverwahrung | Schlüssel werden dupliziert oder exportiert, um den Signing-Service zu erreichen | Schlüssel bleiben unter ihrem Token-Profil; das Signing referenziert sie |
| Reporting | Teilantworten je System | Dashboard-Statistiken über mehrere Vorgänge hinweg |
Bei der Zeile zur Schlüsselverwahrung lohnt sich ein genauerer Blick. Sobald ein Signing-Service außerhalb des Systems lebt, das die Schlüssel verwaltet, muss etwas die Grenze überschreiten. Meist ist dieses Etwas der Schlüssel oder eine Kopie davon. Wenn Signing direkt neben dem Schlüsselmanagement bleibt, entfällt diese Reise.
Wo die ehrlichen Grenzen liegen
Konsolidierung ist nicht dasselbe wie Ersatz, und wir wollen das klar benennen.
ILM ersetzt kein Hardware Security Module. Schlüssel bleiben dort, wo Ihre Richtlinie es vorsieht, und ILM referenziert sie über ein Token-Profil. Ebenso entscheidet ILM weder über Ihre Signing-Richtlinie noch über die Wahl kryptografischer Algorithmen. Es gibt diesen Entscheidungen einen zentralen Konfigurationsort und einen Nachweis darüber, dass sie angewendet wurden.
Auch das Verschieben des Signings in die Plattform beseitigt nicht die Notwendigkeit qualifizierter Vertrauensdienste, wenn Vorschriften sie verlangen. Erfordert ein Anwendungsfall einen qualifizierten Zeitstempel von einem qualifizierten Anbieter, ändert sich diese Anforderung nicht, nur weil Ihre Plattform ebenfalls Zeitstempel erzeugen kann.
Ein Regenschirm ist nützlich, weil er alles auf einmal abdeckt – nicht weil er den Himmel ersetzt.
Erste Schritte
Wenn Sie ILM bereits betreiben, sind beide Funktionen Konfiguration und keine neue Bereitstellung. Erstellen Sie ein Signing-Profil auf Basis eines vorhandenen Token-Profils und ein TSP-Profil mit einer Authentifizierungsmethode. Richten Sie anschließend einen Client auf den RFC-3161-Endpunkt und prüfen Sie, ob ein Signing-Datensatz erscheint.
Wenn Sie ILM evaluieren, sind Signing und Timestamping gerade deshalb ein sinnvoller Einstieg, weil sie üblicherweise getrennt sind. Konfigurieren Sie beides zusammen mit einigen Zertifikaten und prüfen Sie, ob ein einziges Dashboard Fragen beantworten kann, für die zuvor drei Systeme erforderlich waren.
Wichtigste Erkenntnisse
- Signing-Profile enthalten die Konfiguration; Signing-Datensätze enthalten die Nachweise, können pro Profil aufgelistet werden und erscheinen zusammengefasst im Dashboard.
- Timestamping läuft auf einer verwalteten Engine hinter aufrufbaren RFC-3161-Endpunkten, sodass vorhandene Tools unverändert funktionieren.
- TSP-Profile enthalten Authentifizierungsmethoden und Basic-Credentials; vor den Endpunkten sitzt ein Authentifizierungsfilter.
- Wenn Signing direkt neben dem Schlüsselmanagement liegt, müssen Schlüssel nicht verschoben werden, um einen Signing-Service zu erreichen.
- ILM ersetzt kein HSM, legt Ihre kryptografische Richtlinie nicht fest und beseitigt keine regulatorischen Anforderungen an qualifizierte Vertrauensdienste.
Signing und Timestamping kamen mit den Releases 2.18.0 und 2.19.0 – lesen Sie, was sich außerdem in 2.19.0 geändert hat. Für einen breiteren Überblick über die Plattform lesen Sie 10 Dinge, die Sie mit ILM aufbauen können und warum Trust Lifecycle Management auch Secrets umfassen muss. Wenn Sie eine Signing- oder Timestamping-Bereitstellung besprechen möchten, kontaktieren Sie uns.
