Das passende HSM. Bevor Sie investieren.

Die Architektur trennt Anwendungen, Administration, Backup und Schlüsselverwahrung. Eine Partition ist eine logische Trennung, ersetzt aber nicht jede organisatorische oder physische Separierung. Wir klären, welche Schlüssel repliziert werden dürfen, wer einen Cluster erweitern kann und welche Abhängigkeiten zwischen Standorten bestehen. Fällt das HSM aus, darf eine Anwendung nicht unbemerkt auf ungeschützte Schlüsseldateien wechseln. Zertifikatsstatus und Security Policy werden für das konkrete Modul geprüft; ein Produktname oder Algorithmusnachweis genügt dafür nicht.

Vor der endgültigen Freigabe testen wir typische Operationen mit der vorgesehenen Clientanbindung. Gemessen werden Durchsatz, Latenz und Fehlerbehandlung im vereinbarten Profil. Das Ergebnis enthält Annahmen zu Wachstum, Lizenzen und Betrieb. Für den Einstieg benötigen wir Anwendungsübersicht, vorhandene Schlüsseltypen, Standortanforderungen und die Nachweise, die Ihre Organisation tatsächlich erfüllen muss.

Ein Netzwerk-HSM kann mehreren Anwendungen eine zentrale kryptografische Funktion bereitstellen. Dabei werden Netzpfad, Authentisierung und Mandantentrennung Teil der Architektur. Eine PCIe-Karte bindet die Funktion enger an den Host; ein zweiter Rechner benötigt ein eigenes Verfügbarkeitskonzept. Bei einem verwalteten Dienst prüfen wir die verfügbaren APIs und die Aufteilung der Administration. Diese Entscheidung treffen wir nicht allein anhand des Anschaffungspreises: Betriebsaufwand, erreichbare Standorte, Wartungsfenster und ein späterer Wechsel gehören in den Vergleich.

Für den Pilot beschreiben wir einen vollständigen Geschäftsvorgang: Welcher Aufruf erreicht das HSM, wie viele Aufrufe entstehen pro Vorgang und wann gilt die Antwort als zu spät? Neben Durchschnittswerten erfassen wir hohe Latenzperzentile und das Verhalten bei Lastspitzen. Ein Test mit einer einzelnen Signatur bildet weder parallele Clients noch Verbindungsaufbau oder einen Knotenausfall ab. Sie erhalten die gemessenen Bedingungen und die verbleibende Reserve, damit die Beschaffung auf einem nachvollziehbaren Lastprofil beruht.

Mehrere Anwendungen sollen künftig über eine gemeinsame Infrastruktur signieren. OTOKO® ordnet Schlüssel und Verantwortlichkeiten den Anwendungen zu, prüft die benötigten Mechanismen und vergleicht eine gemeinsame Plattform mit getrennten Instanzen. Im Pilot testen wir nicht nur erfolgreiche Signaturen, sondern auch fehlende Rechte, volle Sitzungsressourcen und die Abschaltung eines Knotens. Das Ergebnis ist eine belastbare Architekturentscheidung mit Integrationsaufwand, Lizenzbedarf und offenen Abhängigkeiten – keine pauschale Empfehlung für das größte Gerät.