Schlüssel verwalten. Zugriff begrenzen.

Ein neuer Schlüssel bedeutet nicht, dass der alte sofort gelöscht werden kann. Wir erfassen, welche Daten, Signaturen oder Sicherungen noch von früheren Versionen abhängen. Anwendungen benötigen eine eindeutige Zuordnung zur Schlüsselversion. Erzeugung, Aktivierung, Sperrung, Archivierung und Löschung erhalten getrennte Zustände und Freigaben. Fehler wie erschöpfte Sitzungen, abgelaufene Anmeldungen oder unterbrochene Verbindungen werden sichtbar behandelt. Wiederholungen dürfen keine ungewollten Schlüsselduplikate oder fachlich doppelte Vorgänge erzeugen.

Im Test prüfen wir neben erfolgreichen Aufrufen auch abgewiesene Rollen und nicht erlaubte Operationen. Zugangsmittel und Geheimnisse dürfen nicht in Quellcode, Logs oder allgemeine Backups gelangen. Ihr Team erhält Konfiguration, Beispielszenarien und einen Ablauf zur Diagnose. Wichtig für den Einstieg sind die verwendeten Bibliotheken, Laufzeitumgebungen und vorhandenen Schlüsselbestände.

PKCS #11 beschreibt den Zugriff auf kryptografische Token und deren Funktionen. KMIP adressiert die Verwaltung kryptografischer Objekte zwischen Client und Schlüsselmanagementsystem. Ein Cloud-Dienst kann wiederum eine eigene REST-API anbieten. Daraus folgt keine automatische Austauschbarkeit. OTOKO® dokumentiert, wo eine Operation ausgeführt wird, welches Schlüsselmaterial eine Schnittstelle tatsächlich überträgt und welche Attribute erhalten bleiben. So wird aus einer Protokollliste ein nachvollziehbarer Integrationsweg.

Bei einer hierarchischen Verschlüsselung können Datenschlüssel die eigentlichen Daten schützen, während ein übergeordneter Schlüssel diese Datenschlüssel schützt. Das vermeidet, dass jeder große Datenblock durch ein HSM verarbeitet werden muss. Entscheidend ist, wo ein Datenschlüssel im Klartext benötigt wird und wie lange er dort verfügbar bleibt. Wir klären Cache-Verhalten, Rotation und Zugriff in der Anwendung. Der Satz „Der Schlüssel bleibt im HSM“ ist nur für die konkret betrachtete Schlüsselrolle und ihre Attribute belastbar.

Mehrere Dienste nutzen bislang eigene Schlüsseldateien. OTOKO® ordnet zunächst Eigentümer, Zwecke und Datenabhängigkeiten zu. Anschließend erproben wir die unterstützte Integration eines repräsentativen Dienstes und definieren Berechtigungen je Anwendung. Die Umstellung erfolgt schrittweise mit kontrolliertem Lesen bestehender Daten und Schreiben neuer Daten. Alte Schlüssel werden erst entfernt, wenn Aufbewahrung, Backups und Wiederherstellung berücksichtigt sind. Das Ergebnis ist ein dokumentierter Schlüsselbestand mit getesteten Nutzungs- und Wechselverfahren.