Schlüsseldienst in schlau

von Dr. Christian Knermann

Mit CloudHSM bietet Securosys seine Primus-Hardware-Security-Module als vollständig aus der Cloud verwalteten Dienst an. So sind Administratoren in der Lage, kryptografische Schlüssel sicher zu verwalten, ohne selbst Hardware dafür installieren und betreiben zu müssen. Im Test konnte der Schlüsselmeister in der Cloud durch seine einfache Inbetriebnahme, gute Dokumentation und die Mannigfaltigkeit an Verschlüsselungsmethoden überzeugen. Darüber hinaus können IT-Verantwortliche über die Lizenzpakete CloudHSM genau so nutzen, wie es die eigenen Ansprüche und die regulatorischen Vorgaben verlangen.

Mit der zunehmenden Verlagerung von IT-Umgebungen in die Cloud und der steigenden Komplexität hybrider Architekturen gewinnt der Einsatz von Kryptografie weiter an Bedeutung. Gilt es doch, zahlreiche Applikationen und Dienste über verschiedene Provider, Rechenzentren und Standorte hinweg zu orchestrieren. Die Informationssicherheit steht und fällt dabei mit dem Schutz der verwendeten kryptografischen Keys. Gerät das Schlüsselmaterial in die falschen Hände, hebelt dies auch die stärkste Verschlüsselung aus.

Genau hier setzt ein Hardware-Security-Modul (HSM) an. Es schafft eine sichere Umgebung zum Erzeugen, Speichern und Nutzen kryptografischer Schlüssel, gekapselt von potenziell unsicheren Betriebssystemen, Anwendungen und Netzwerken. Ein HSM bietet damit gerade bei der Nutzung von Diensten in der Public Cloud entscheidende Vorteile gegenüber der Schlüsselverwaltung durch die Provider der Cloudplattformen selbst.

Ein HSM bietet optimalen Schutz von Schüsseln, wird damit aber zur geschäftskritischen Komponente, ohne die alle darauf aufbauenden Prozesse ausfallen können. Entsprechend sollten mehrere HSMs in einer redundanten Konfiguration zum Einsatz kommen. Ebenso gilt es, rund um die HSMs Administrationsprozesse mit rollenbasierter Zugriffskontrolle, lückenloser Audit-Protokollierung und Vier- oder gar Mehr-Augen-Prinzip zu etablieren. Dies erfordert umfangreiche Fachkenntnisse, Ressourcen und die Einhaltung strenger Sicherheitsprotokolle – ein Aufwand, vor dem viele Unternehmen aufgrund von Kosten oder auch fehlenden Fachkräften zurückschrecken. Doch an dieser Stelle kommt nun der Schweizer Hersteller Securosys ins Spiel, der sich auf digitale Sicherheit spezialisiert hat.

Passende HSM-Pakete für jede Anforderung

Mit der Primus-HSM-Produktfamilie bietet Securosys mehrere Serien physischer HSMs für Unternehmen nahezu jeder Größenordnung an. Basierend auf dieser hauseigenen Hardware betreibt der Hersteller mit CloudHSM zudem einen vollständig verwalteten Dienst, den die Schweizer auch als HSM-as-a-Service bezeichnen. Somit können auch Unternehmen, die keine dedizierte Hardware anschaffen und betreiben möchten, von den Vorteilen eines HSM profitieren.

CloudHSM steht in verschiedenen Plänen je nach Größe und Sicherheitsanforderungen zur Verfügung. So haben Organisationen die Wahl zwischen partitionierten Multi-Tenant-HSMs, deren Hardware sie sich mit mehreren Kunden teilen oder alternativ dedizierten HSMs pro Kunde. Die HSMs betreibt Securosys als globale oder regionale Cluster in insgesamt sieben eigenen Rechenzentren weltweit, drei davon in der Schweiz, eines in Deutschland, zwei weitere jeweils an der West- und Ostküste der USA sowie zu guter Letzt einem in Singapur für den asiatisch-pazifischen Raum. Den Betrieb erbringt der Anbieter zentral von seinem Hauptsitz in der Schweiz aus.

Unternehmen, die aufgrund regulatorischer Anforderungen, interner Richtlinien oder auch aus Gründen der Performance dedizierte Hardware wünschen, greifen zum Platinum-Plan und erhalten damit mindestens zwei aktive HSMs in Securosys-Rechenzentren ihrer Wahl, je nach Vertragsgestaltung auch mehr aktive sowie optional zusätzlich ein oder mehrere inaktive HSMs zwecks Backup und Disaster Recovery.

Mit dem Transaction Security Broker (TSB) steht zudem eine optionale Middleware-Komponente zur Verfügung, die komplexe Autorisierungsprozesse beim Umgang mit kryptografischen Schlüsseln abbildet – insbesondere in Verbindung mit Genehmigungsprozessen von Smart Key Attributes (SKA). Der TSB fungiert als Vermittler zwischen einer Applikation und dem HSM. Er koordiniert mehrstufige Autorisierungen, bevor das HSM eine kryptografische Operation ausführt. Dies ist besonders relevant, wenn Vorgänge mit Regeln wie einem Quorum, also etwa der Freigabe durch drei von fünf Berechtigten, Zeitfenstern oder anderen Bedingungen verknüpft sind.

TSB ergänzt damit die Funktionalität von CloudHSM um eine feingranulare, regelbasierte Kontrolle der Schlüsselverwendung. Er hilft damit insbesondere in sicherheitskritischen Umgebungen, die nicht nur nach technischer, sondern auch organisatorischer Absicherung von kryptografischen Operationen verlangen. Weiterhin bietet der Hersteller mit dem HSM Operation Service (HOS) noch ein Betriebsmodell für dedizierte HSMs, bei dem die Hardware in den Besitz des Kunden übergeht und Securosys den Betrieb übernimmt.

Einfaches Testen mit der Sandbox

Auch im Bereich der Multi-Tenant-HSMs, mit dem sich Kunden eine physische Hardware teilen, legt der Hersteller größten Wert auf Sicherheit. Auf Wunsch erfolgt auch dies mit einem komplett vom Anbieter verwalteten TSB-as-a-Service. Weiterhin verwaltet Securosys in den Economy-Plänen seine Systeme und Dienste grundsätzlich mit einem Rollenmodell nach einem Vier- bis Sechs-Augen-Prinzip. Dies trifft lediglich beim kleinsten Plan, der Sandbox (SBX), nicht zu.

Securosys weist in der Dokumentation explizit darauf hin, dass SBX nicht für den produktiven Einsatz, sondern nur für Test- und Integrationsumgebungen gedacht ist. Der Hersteller bietet damit eine besonders günstige Option für IT-Verantwortliche, die ihrerseits eine mehrstufige Infrastruktur bestehend aus separaten Umgebungen für Entwicklung, Test und Produktion betreiben. Dergestalt lassen sich so dieselben Sicherheitsfunktionen in der Entwicklung nutzen, die später auch im produktiven Betrieb zum Einsatz kommen.

SBX bietet den identischen Funktionsumfang zum Tarif Economy (ECO), aber ohne das Rollenmodell und ohne zugesicherte Leistungsmerkmale mit Performance nach dem Best-Effort-Betrieb. Neue Funktionen kündigt Securosys mit einem Vorlauf von 14 Tagen an, implementiert diese dann zunächst in SBX und vier Wochen später erst im Plan ECO. So können Kunden, die einen DevOps-Ansatz verfolgen, auch die Weiterentwicklung seitens des Herstellers in ihre eigenen Testzyklen einbeziehen.

Unterstützung auch für Post-Quanten-Algorithmen

Im Plan "SBX" arbeiten mehrere aktive HSMs georedundant in einem globalen Cluster, mit "ECO" kommt zu mindestens zwei aktiven, georedundanten HSMs ein weiteres, inaktives als Backup hinzu. Dies gilt ebenso für die "Economy Certified"-Lizenz (ECO-CC). Letztere adressiert Anwendungsfälle mit strikten regulatorischen Anforderungen, die etwa Compliance mit Federal Information Processing Standards (FIPS) oder Common Criteria (CC) verlangen. Über Zertifizierungen nach ISO/IEC 27001:2022 und ISO 9001:2015 hinaus betreibt Securosys die HSMs in diesem Plan konform zum strengen Common Criteria-Modus EAL4+ und gemäß dem Profil EN 419 221-5, was für eIDAS-konforme qualifizierte Signaturen relevant ist.

Weiterhin garantiert die Zertifizierung nach FIPS 140-2 Level 3, dass Schlüssel das Modul nicht im Klartext verlassen und dass Manipulationsversuche erkannt werden. Die Zertifizierung nach FIPS 140-3 war bis zum Redaktionsschluss noch in Arbeit. Dies bedeutet allerdings auch, dass die Entwicklung in diesem Plan langsamer verläuft und ECO-CC einige der neuesten Post-Quanten-Algorithmen (Post Quantum Cryptography, PQC) noch nicht unterstützt, die ECO ohne Namenszusatz sowie SBX bereits beinhalten.

Eine Auflistung aller unterstützten Algorithmen würde den Umfang dieses Artikels sprengen, erwähnt sei aber, dass Cloud-HSM symmetrische (AES, 3DES, Camellia, ChaCha, Poly1305), asymmetrische (RSA, ECC, Diffie-Hellman) und Hashing-Algorithmen (SHA-2, SHA-3) beherrscht. Zum Zeitpunkt unseres Tests bot das CloudHSM mit der Firmware in der Version 3.2 zudem bereits Unterstützung für die PQC-Algorithmen ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium), SLH-DSA (SPHINCS+), HSS-LMS und XMSS. Sollten aufkommende Quantencomputer einen oder mehrere der herkömmlichen Algorithmen brechen, kann der Hersteller aufgrund der dynamischen Architektur der physischen HSMs grundsätzlich durch Firmware-Upgrades weitere PQC-Algorithmen installieren.

Auf Wunsch volle Kontrolle

Die ECO-Lizenzierung umfasst mehrere mögliche Dienstpakete, mit denen sich auf Wunsch der Betrieb des HSM-Clusters auf bestimmte Regionen beschränken lässt. So nutzt etwa "Economy (ECO), Germany" das Rechenzentrum in Deutschland und eines in der Schweiz für die aktiven HSMs mit einem weiteren RZ in der Schweiz für das Backup. SBX bietet keine geografischen Optionen, seine aktiven Rechenzentren befinden sich in der Schweiz, Singapur und den USA.

Standardmäßig verwalten Mitarbeiter von Securosys die Partitionskonfiguration für die CloudHSM-Kunden. Alternativ können Unternehmen die Administration ihrer Partitionen ohne Beteiligung des Herstellers auch selbst mit der Rolle des Partition Security Officers (PSO) übernehmen. Dies erfolgt abgesichert durch Zwei-Faktor-Authentifizierung (2FA) und ein Quorum, bei dem ein oder zwei von bis zu 255 möglichen Berechtigten Aktionen genehmigen müssen (1-von-n- oder 2-von-n-Quorum). Securosys bietet dafür mit dem Decanus-Terminal eine optionale Hardware an, mit der Administratoren die volle Kontrolle über ihre HSM-Partition erlangen. Dies umfasst administrative Tätigkeiten, wie das Zurücksetzen von Anmeldeinformationen, das Ändern der Sicherheitskonfiguration der Partition, die Verwaltung ungültiger Schlüssel, Export von Protokollen sowie auch das Sichern und Wiederherstellen der Partition.

Für volle Autonomie können Administratoren sogar ausschließen, dass Securosys in ihre HSM-Partition eingreift und damit die alleinige Verantwortung für die Rolle des PSO übernehmen. Wer diesen Weg wählt, muss sich aber bewusst sein, dass etwa beim Verlust der Zugangsdaten des PSO der Herstellersupport nicht mehr helfen kann.

Mehrfach abgesicherte Schnittstellen

Wann immer Clientsysteme über das Internet auf CloudHSM zugreifen, sorgt der Anbieter dafür, dass dies auf sichere Art und Weise geschieht und nur authentifizierte Nutzer Zugang zu genau ihrer Partition erhalten. Administratoren richten dazu auf ihren Systemen einen Crypto-Provider ein oder nutzen das vom Hersteller ebenfalls angebotene REST-API. Letzteres setzt neben dem CloudHSM einen Transaction Security Broker als Gegenstelle in der Cloud voraus. Das REST-API positioniert sich als Middleware vor dem CloudHSM. Für Kunden ist diese Middleware transparent, da sich der Hersteller vollständig um die Verwaltung kümmert.

Crypto-Provider stehen für drei Schnittstellen zur Verfügung: Als Key Storage Provider (KSP) für das "Microsoft Cryptography API: Next Generation" (CNG), als plattformunabhängige "Java Cryptographic Extension "(JCE) und zu guter Letzt als PKCS#11-Client (Public-Key Cryptography Standards #11). Letzterer unterstützt neben Windows die gängigen Linux-Distributionen von Red Hat, Oracle, Ubuntu, Debian und SUSE sowie weitere Betriebssysteme auf Anfrage. In der Dokumentation weist Securosys darauf hin, dass viele andere Linux-Distributionen, wie etwa Rocky Linux, in der Regel auch funktionieren, sofern die GLIBC-Bibliotheken kompatibel sind.

Zusätzlich stellt Securosys mit den Primus-Tools noch ein Java-basiertes Werkzeug bereit, mit dem Administratoren die Verbindung zum CloudHSM testen und Verwaltungsaufgaben wie Schlüsseloperationen ausführen. Diese Tools positionieren sich damit als Alternative zu plattformspezifischen Werkzeugen wie OpenSC/pkcs11-tool unter Linux oder certutil unter Windows. Die Kommunikation zwischen Client und CloudHSM ist sowohl für die Provider als auch für die Tools mehrfach abgesichert – über eine Firewall hinaus auch durch ein Gateway, das als Reverse-Proxy fungiert. Clients müssen sich zunächst mit einem Proxy-Benutzer nebst zugehörigem Passwort authentifizieren.

Optional ist es in diesem Schritt möglich, den Zugriff auf bestimmte Client-IP-Adressen zu begrenzen. Erst nach der erfolgreichen Anmeldung am Proxy kommt eine mit dem Algorithmus AES-256-GCM Ende-zu-Ende-verschlüsselte Verbindung zwischen Client und HSM zustande.

Gut dokumentierte Integrationen

Die Dokumentation listet ohne Anspruch auf Vollständigkeit zahlreiche Integrationsmöglichkeiten für das CloudHSM auf, darunter etwa verbreitete Anwendungsfälle wie die Integration mit der Public-Key-Infrastruktur (PKI) der Microsoft Active Directory Certification Services (ADCS) oder auch Keyfactor EJBCA sowie Verschlüsselung im Kontext von Datenbanken, Container-Orchestrierung, Identitätsmanagement, Codesignatur und Netzwerksicherheit.

Darüber hinaus wird auch Bring Your Own Key (BYOK) unterstützt und exemplarisch erklärt für AWS, Microsoft Azure und Salesforce. Zu all diesen Integrationen erläutert der Hersteller in seiner Doku neben einer allgemeinen Übersicht über die jeweilige Architektur die technischen Voraussetzungen eines jeden Anwendungsfalls und bietet umfangreiche Tutorials, die Admins auf dem Weg zu einer Beispielkonfiguration begleiten.

Einige dieser Tutorials wollten wir in unserer Testumgebung nachvollziehen. Dazu hatte uns der Hersteller kostenfrei eine Trial-Version des CloudHSM im Plan SBX zur Verfügung gestellt. Admins können über eine webbasierte Cloudkonsole ihr Abonnement verwalten, weitere Services bestellen und die Zugangsdaten herunterladen oder ihren gewünschten Plan auf klassischem Weg per Formular bestellen. Wir vollzogen letzteren Weg und bestellten unseren Zugang zum CloudHSM mithilfe eines PDF-Formulars. Darin wählten wir den gewünschten Tarif, die benötigten APIs sowie weitere Funktionen, darunter die Sicherheitsrichtlinie für unsere Partition, die auf Wunsch etwa den Export und Import von Schlüsselmaterial erlaubt oder verbietet. Weiterhin waren bis zu drei für den Support berechtigte Kontakte zu hinterlegen und diesen eine Rolle zuzuweisen. Dabei erhalten nur privilegierte Benutzer Zugriff auf die Zugangsdaten.

Die lieferte Securosys anschließend als über unsere E-Mail-Adresse und Mobilfunknummer doppelt gesicherten Download einer Textdatei. Darin fanden wir die DNS-Namen der zu unserem gebuchten Plan gehörigen Endpunkte mitsamt den TCP-Ports für die verschiedenen APIs. Weiterhin enthielt das File die benötigten Zugangsdaten, zum einen den Proxy-Benutzer mit seinem Passwort, den eigentlichen HSM-Benutzer mit einem initialen Setup-Passwort sowie ein separates Passwort für die PKCS#11-Schnittstelle. Beim Setup-Passwort galt es zu beachten, dass dieses ab der ersten Benutzung nur eine Woche lang gültig ist und die Crypto-Provider im Rahmen ihrer Installation je ein permanentes Secret mit dem CloudHSM aushandeln. Nach Ablauf des Setup-Passworts hilft der Support und übermittelt auf Anfrage ein neues Passwort, wenn die Installation weiterer Provider gewünscht ist.

Unkomplizierte Installation unter Windows

Wir begannen nun mit einer der komplexesten Aufgaben, dem Aufbau einer PKI in unserem Active Directory. Securosys beschreibt in der Online-Dokumentation detailliert und kleinschrittig die Installation einer Root Certification Authority (CA) mit einer untergeordneten Enterprise-CA. Hierzu hatten wir zwei Systeme vorbereitet, einen alleinstehenden Windows Server 2025 und einen weiteren als Mitglied unserer Domäne. Auf beiden installierten wir komplikationslos den Microsoft CNG Provider. Zwecks hoher Verfügbarkeit legten wir in der Konfiguration des Providers Verbindungen zu allen von Securosys benannten Endpunkten in der Cloud an. Dabei benötigten wir jeweils die Zugangsdaten des Proxy- und des HSM-Benutzers. Bei der ersten Verbindung handelt der Provider mithilfe des Setup-Passworts ein dauerhaftes Secret für den weiteren Betrieb aus.

Nachdem wir die Verbindungen erfolgreich getestet hatten, konnten wir uns der weiteren Inbetriebnahme von Root- und Enterprise-CA widmen, die sich kaum von einer Infrastruktur ohne HSM unterscheidet. Im Rahmen der ADCS-Konfiguration wählten wir lediglich einen der vom "Securosys Primus HSM Key Storage Provider" angebotenen Algorithmen anstelle des "Microsoft Software Key Storage Providers". Der Securosys-Provider unterstützt neben klassischem RSA auch neuere Algorithmenfamilien auf Basis von elliptischen Kurven (Elliptic Curve Cryptography, ECC). Im Rahmen unseres Tests beließen wir es aber beim derzeit noch verbreiteten RSA, konnten unsere ADCS damit komplikationslos in Betrieb nehmen und Zertifikate ausstellen.

Gelungene Integration auch unter Linux

Ebenso problemlos gestaltete sich die Handhabung unter Linux. Hier hatten wir eine Instanz von Ubuntu 22.04.5 LTS vorbereitet, auf der wir ebenfalls eine PKI einrichten wollten – in diesem Fall die Community-Edition der "Keyfactor Enterprise JavaBeans Certificate Authority" (EJBCA). Da nur die Enterprise-Edition von EJBCA die vereinfachte Integration des CloudHSM per REST-API unterstützt, richteten wir den PKCS#11-Provider ein, den Securosys für die Paketmanager von Red Hat und Debian sowie als Tarball zur manuellen Installation anbietet. Wir nutzten das Debian-Paket, das wir mittels Advanced Package Tool (APT) installierten und unseren Benutzer zur vom Setup angelegten Primus-Gruppe hinzufügten. Standardmäßig berechtigt Securosys nur diese Gruppe für die Dateien des PKCS#11-Providers und dessen Konfiguration.

Anschließend trugen wir die Endpunkte nebst Namen des Proxy- und des HSM-Benutzers in der Konfigurationsdatei des Providers ein. Nun mussten wir mithilfe des ppin-Befehls aus dem Umfang des Providers manuell die Passwörter für den Proxy, das initiale Setup sowie für PKCS#11 übergeben und damit das permanente Secret für den weiteren Betrieb generieren. Daraufhin konnten wir sowohl mithilfe des ppin-Kommandos als auch mit dem generischen OpenSC/ pkcs11-Tool erfolgreich die Verbindung zum CloudHSM testen.

Anschließend folgten wir dem Tutorial, mit dem Keyfactor die Inbetriebnahme einer Testumgebung bestehend aus EJBCA und MariaDB als unterliegender Datenbank in Docker-Containern beschreibt. Zur Integration mit CloudHSM mussten wir lediglich das Verzeichnis mit den Dateien des PKCS#11-Providers sowie ein Verzeichnis mit zwei weiteren Konfigurationsdateien als zusätzliche Volumes in den Docker-Container von EJBCA einbinden. Anschließend waren wir in der Lage, aus dem Webfrontend von EJBCA heraus mithilfe des Providers einen Crypto-Token und darauf basierend auch Schlüsselpaare zu generieren.

Mit BYOK zügig in andere Clouds

Zu guter Letzt richteten wir die Java-basierten Primus-Tools unter Windows sowie unter Linux ein. Dazu benötigten wir unabhängig von der Plattform lediglich eine Java-Laufzeitumgebung. Neben Oracle Java harmonieren die Tools auch ohne Probleme mit OpenJDK. Mittels Aufruf der Tools auf der Kommandozeile übergaben wir zunächst wiederum das Proxy- und das initiale Setup-Passwort, um diese AES-verschlüsselt in Textdateien zu speichern. Daraus erzeugten wir dann auch in diesem Fall ein permanentes Secret für künftige Aufrufe und testeten die Verbindung zum CloudHSM.

Mithilfe der Tools konnten wir BYOK-Szenarien für Cloudprovider konfigurieren, so etwa für Azure. Hierzu folgten wir der auch für diesen Anwendungsfall ausführlichen Dokumentation, die die nötigen Handgriffe erläutert, um mit der Azure-PowerShell und den Primus-Tools einen "Key Exchange Key" sowie einen "Target Key" zu erzeugen.

Fazit

Securosys CloudHSM kümmert sich um die sichere Schlüsselverwaltung, ohne dass Administratoren dafür eigene Hardware implementieren müssen. Der Dienst unterstützt eine Vielzahl an Algorithmen sowie Integrationen mit Drittanbietern, die der Hersteller in der umfangreichen Online-Dokumentation detailliert beschreibt. Das Einrichten der Provider gelang schnell und komplikationslos, wobei Administratoren unter Windows weniger Handgriffe benötigen als unter Linux.

Da es sich bei CloudHSM im Regelfall um einen vollständig verwalteten und noch dazu für die Informationssicherheit relevanten Dienst handelt, kommt dem Herstellersupport besondere Bedeutung zu. Auch hier konnte Securosys überzeugen und unsere diversen Anfragen, die wir während der Inbetriebnahme stellten, schnell und umfassend beantworten. Wer mehr Autonomie benötigt, kann auf Wunsch die Verwaltung des HSM auch komplett in die eigenen Hände nehmen.

Produkt	Cloudbasiertes Hardware-Security-Modul.
Hersteller	Securosys https://www.securosys.com/cloud-security/cloudhsm-overview
Preis	Die monatlichen Preise beginnen für CloudHSM Sandbox (SBX) bei 299 Euro, für CloudHSM Economy (ECO) bei 795 Euro und CloudHSM Certified (CC) startet bei 895 Euro.
Systemvoraussetzungen	Primus CNG/KSP Provider: Microsoft Windows Server 2012 R2 oder höher und Windows 7 (x64/x32) oder höher. PKCS#11 Provider: Windows Server 2012 R2 oder höher und Windows 7 (x64/x32) oder höher, RHEL 7 bis 9 (x64), CentOS 7/(8) (x64), Oracle Linux 7-9 (x64), Ubuntu 16-24 (x64), Debian 8-12 (x64), SUSE Linux Enterprise Server (SLES) 12/15 (x64). Primus-Tools: Java Runtime Environment (JRE) 8
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter

Schnittstellen	8
Algorithmen	7
Integrationen	7
Dokumentation	8
Support	7
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik