NetHSM Software Update 4.0: Skalierbares Clustering für hochverfügbare HSM

Wir freuen uns, das bisher größte Software-Update für NetHSM anzukündigen: Neben IPv6-Unterstützung bringt die NetHSM Software 4.0 natives Clustering. Mehrere NetHSM-Geräte lassen sich damit zu einem redundanten Verbund zusammenschalten, der Schlüsseldaten verteilt und konsistent hält und beim Ausfall einzelner Geräte weiter betriebsbereit bleibt. Dabei skaliert der Cluster sowohl in der Geräteanzahl als auch im Durchsatz beliebig groß – ohne technische Grenzen oder proprietäre Einschränkungen auf eine feste Anzahl von Geräten. Praktisch beliebig große Lasten lassen sich einfach auf das gesamte Cluster verteilen. Damit verfügt NetHSM über das leistungsfähigste Clustering unter allen uns bekannten HSMs. Dieses Software-Update steht allen NetHSM-Kunden ohne Zusatzkosten zur Verfügung. Wie immer als Open Source und Made in Germany für volle Souveränität.

Vorteile gegenüber proprietärem HSM-Clustering

Wer sich mit Hochverfügbarkeit von Hardware-Sicherheitsmodulen (HSM) beschäftigt hat, kennt die typischen Alternativen: proprietäre Cluster-Software der HSM-Hersteller, manuelle Schlüssel-Exports mit PKCS#11, oder externe Datenbanken als Synchronisations-Backend.

NetHSM-Clustering unterscheidet sich davon in mehreren Punkten:

Skalierbar ohne Architekturgrenze

Viele HSM-Hersteller beschränken ihre Cluster-Lösung auf zwei Knoten im Active/Passive-Betrieb. Das schützt vor dem Ausfall eines Geräts, skaliert aber weder den Durchsatz noch die Ausfalltoleranz. Der NetHSM-Cluster wächst hingegen mit den Anforderungen: Mehr Knoten erlauben mehr parallele Kryptographie-Operationen und höhere Fehlertoleranz. Die Knotenanzahl ist nicht durch die Architektur begrenzt und es lassen sich Cluster mit dutzenden oder hunderten NetHSM realisieren.

Keine künstliche Lizenzgrenze

Proprietäre HSMs bieten Clustering oft als teures Add-on, mit eigener Management-Software, mangelhafter Interoperabilität und häufig auf zwei Knoten begrenzt. Beim NetHSM ist Clustering inkludiert ohne zusätzliche Lizenzkosten oder künstliche Begrenzung.

Kein Schlüssel-Export für die Synchronisation

Herkömmliche Replikations-Ansätze erfordern oft, dass Schlüssel exportiert und auf anderen Knoten re-importiert werden. Das bedeutet, dass der Schlüssel – wenn auch nur kurz – in Software vorliegt. Beim NetHSM-Cluster repliziert etcd die verschlüsselten Schlüssel. Deren Entschlüsselung findet ausschließlich auf der Hardware statt und gewährleistet somit eine hohe Sicherheit.

Nachvollziehbare Konsistenzgarantien

Der verwendete Raft-Algorithmus (mehr Details unten) ist formal verifiziert und gut dokumentiert. Die Konsistenzgarantien sind keine Marketing-Versprechen, sondern Eigenschaften eines publizierten Algorithmus, den Sicherheitsforscher unabhängig analysieren können. Das ist ein erheblicher Unterschied zu proprietären Synchronisations-Protokollen, die kaum öffentlich spezifiziert sind.

Erprobte Implementierung

Die Integration im NetHSM ist zwar neu aber die zugrundeliegende Cluster-Implementierung etcd wird seit vielen Jahren u.a. in Kubernetes für Milliarden von Deployments erfolgreich verwendet. Somit kann von einer stabilen und fehlerarmen Implementierung ausgegangen werden.

Automatische Re-Synchronisation

Knoten die kurzzeitig vom Netz getrennt waren und sich wieder verbinden synchronisieren ihren Zustand ohne manuelle Intervention. Das vereinfacht Wartungsfenster, reduziert Administrationsaufwand und erhöht die Verfügbarkeit erheblich – auch in großen Deployments mit vielen Knoten.

etcd und Raft: Bewährte Konsistenz-Algorithmen für sicherheitskritische Daten

Das Herzstück des NetHSM-Clustering ist etcd, ein verteilter Key-Value-Store, der ursprünglich für Kubernetes-Cluster-Koordination entwickelt wurde und dort seit Jahren Milliarden von Deployments koordiniert. Die Wahl von etcd ist kein Zufall: Es ist eines der wenigen Systeme, das starke Konsistenzgarantien, horizontale Skalierbarkeit und einen formal verifizierten Konsensalgorithmus vereint.

etcd setzt auf den Raft-Konsensalgorithmus. Raft definiert zu jedem Zeitpunkt genau einen Leader-Knoten, der Schreiboperationen koordiniert. Ein Schreibvorgang – also etwa das Anlegen eines neuen Schlüssels – gilt erst dann als erfolgreich, wenn eine Mehrheit der Knoten (das sogenannte Quorum) ihn bestätigt hat. Das bedeutet, dass kein Knoten jemals einen Zustand sieht, der nicht von der Mehrheit des Clusters bestätigt wurde. Kein Split-Brain, keine Silent Data Corruption durch divergierende Zustände.

Für einen NetHSM-Cluster mit N Knoten müssen mindestens (N/2)+1 Knoten aktiv und erreichbar sein, damit der Cluster funktioniert. Die Ausfalltoleranz steigt linear mit der Knotenanzahl: Ein 3-Knoten-Cluster toleriert den Ausfall eines Knotens, ein 5-Knoten-Cluster den Ausfall von zwei Knoten gleichzeitig, ein 7-Knoten-Cluster drei – und so weiter. Wer höhere Verfügbarkeitsanforderungen hat, fügt weitere Knoten hinzu. Kein neues Protokoll, keine neue Lizenz, keine Änderung an der bestehenden Konfiguration.

Wenn ein isolierter Knoten sich nach einem Netzwerk-Ausfall wieder einfindet, synchronisiert er sich automatisch mit dem aktuellen Cluster-Zustand – keine manuelle Intervention nötig.

Das Besondere: Die in etcd gespeicherten Daten – Schlüssel, Nutzer, Konfigurationen – sind durchgehend mit dem gemeinsamen Domain Key der NetHSM-Instanzen verschlüsselt. Selbst ein vollständiger Dump des etcd-Stores gibt einem Angreifer ohne die Hardware-gebundenen Schlüssel keinen Zugriff auf die Klartextdaten.

Bereits während der ursprünglichen Entwicklung des NetHSM war das Clustering eingeplant. So bestand die interne Datenbank eines einzelnen NetHSM bereits aus einer isolierten etcd Instanz. Die Softwareversion 4.0 basiert auf dieser Architektur und ermöglicht nun das Verknüpfen mehrerer NetHSM und deren etcd-Instanzen. Das Clustering ist also kein Fremdkörper sondern eine Realisierung des bereits enthaltenen Leistungspotentials der modernen NetHSM-Architektur.

Witness ermöglicht Quorum ohne zusätzliche Hardware

Eine praktische Herausforderung beim Clustering ist die Anforderung nach einer ungeraden Knotenanzahl. Ein 2-Knoten-Cluster ist daher problematisch: Fällt ein Knoten aus, verliert der verbliebene Knoten das Quorum. Um trotzdem den Weiterbetrieb zu ermöglichen kann ein manueller Eingriff erforderlich sein – entweder zum Zeitpunkt des Ausfalls (um auf den verbliebenen Knoten umzuschalten) oder zum Reparatur-Zeitpunkt wenn der Cluster wieder den Normalbetrieb aufnimmt und ggf. divergierender Datenbestand zusammen geführt werden muss.

NetHSM bietet mit dem Witness-Konzept für dies Problem eine weitere Lösung. Ein Witness (Zeuge) ist eine einfache etcd-Instanz, die auf beliebiger Hardware – einer VM, einem Raspberry Pi, einem Container – betrieben werden kann. Sie nimmt am Raft-Konsens teil und trägt zum Quorum bei, führt aber selbst keine HSM-Operationen aus. Mit einem Witness lässt sich ein stabiler 3-Knoten-Cluster aus zwei NetHSM-Geräten und einer regulären Server-Instanz aufbauen – ohne das Budget für ein drittes NetHSM-Gerät zu erfordern. Dasselbe Prinzip funktioniert beim Skalieren: Wer von vier auf fünf Knoten wechseln möchte, kann zunächst einen kostengünstigen Witness als fünften Knoten einsetzen.

Der Witness empfängt dabei alle Clusterdaten, inklusive der verschlüsselten Schlüsseldaten. Da sämtliche sensiblen Werte mit den gerätegebundenen Keys verschlüsselt sind, stellt dies kein Sicherheitsproblem dar – der Witness ist ein vollwertiges Cluster-Mitglied auf etcd-Ebene aber ohne Zugriff auf kritische Klartextdaten.

Was der Cluster synchronisiert – und was nicht

Ein wichtiges Designprinzip: Nicht alles wird geteilt. NetHSM 4.0 unterscheidet präzise zwischen global geteilten Daten und gerätespezifischen Daten.

Über den Cluster hinweg synchronisiert werden alle HSM-Nutzdaten: kryptographische Schlüssel, Benutzerverwaltung, Namespaces sowie die Backup-Passphrase und die Cluster-CA. Das bedeutet, dass ein Schlüssel, der auf einem Gerät angelegt wird, sofort auf allen anderen Geräten verfügbar ist – ohne manuelle Replikation, ohne expliziten Export. Jedes weitere Geräte, das dem Cluster beitritt, erhält automatisch den vollständigen Datenbestand.

Gerätespezifisch bleiben dagegen Konfigurationsparameter wie TLS-Zertifikat, Netzwerkkonfiguration, Logging und – entscheidend – der Device Key selbst. Der Device Key verlässt die Hardware nie. Ebenfalls hat jedes Gerät eine individuelle Unlock-Passphrase.

Weitere Details finden sich in der technischen Dokumentation.