Kosten und Verwaltung von Hardware Security Modules (HSM)

Es gab einen erheblichen Anstieg bei der Verwendung von kryptographischen Techniken und Hardware Security Modules (HSM) in größeren Unternehmen und Banken insbesondere seit dem Aufschwung der Online-Dienste in den späten 1990er Jahren.

Dies wurde grösstenteils auf Projektbasis durchgeführt, wobei jedes Projekt eigene Ziele und ein eigenes Budget hatte (teilweise wird das sogar noch heute so gehandhabt). Die angebliche Sicherheit durch projektbasierte HSM-Implementierungen führt aber zu Insel-Lösungen, welche die Fähigkeit komplett ausser acht lässt, dass HSM-Ressourcen sicher über viele Systeme verteilt werden könnten, welche eine sichere Schlüsselverwaltung benötigen. Dadurch entstehen immer wieder Projekte, welche die vorhandene HSM-Infrastruktur für die Produktion jedes Projekts "duplizieren". Für große Organisationen wie z.B. Banken sind die Konsequenzen dieses Modells unnötig große Krypto-Infrastrukturen, welche immer teurer werden und letztendlich niemals nachhaltig zu verwalten sind.

Die Projektdimension

Projekt-Zeitskalen zur Implementierung waren für diese neuen Online-Service-Projekte in der Regel mehrere Monate bis hin zu mehreren Jahren, je nach Projekt und gegebener Komplexität. Viele dieser frühen Implementierungen sind sogar noch heute in der Produktion, einige können in einem kryptographischen Sinne auch während der ganzen vergangenen Jahre in der Produktionsnutzung funktional unverändert geblieben sein.

Der entscheidende Punkt ist jedoch, dass ein Hardware-Security-Modul - sowohl von der ursprünglichen als auch der realen Projektbetrachtung ausgehend - nur mit einem kleinen Zeitfenster des gesamten Produkt-Lebens produktiv im Einsatz ist, oft sogar weniger als 10%.

Dennoch ist es sehr wahrscheinlich, dass nur und ausschlieslich während dieser "Projektperiode" der Einsatz von Kryptographie Sinn macht. Häufig ist es zu beobachten, das sogar komplette Farmen an HSM-Modulen über Jahre hinweg unbeachtet laufen.

Oft ist es die "Business-as-Usual" Mentalität:

  • "Not broken - Do not touch" und
  • "Herr Meier verließ vor zwei Jahren das Unternehmen und er war der einzige, der wirklich alle Details verstanden hat".

Kommt Ihnen das auch bekannt vor?

Aktuelle HSM-Trends - die letzten zehn Jahre

Die schnelle Bereitstellung von Mid-Range-Server-basierten Business-Anwendungen in den frühen Teil des letzten Jahrzehnts verwendet in-Server "Crypto Cards". In der Mitte des letzten Jahrzehnts war eine zusätzliche Option das "Networked HSM" und wurde damit immer breiter verfügbar.

In vielen Online-Transaktions-Systemen, bei denen die Nachgiebigkeit wesentlich ist, kann die technische Auslastung von HSM für ein Gerät, das auf Verfügbarkeit 24/7 ausgelegt ist, 10% oder weniger betragen. In Batch-Verarbeitungssystemen kann die Nutzung sehr intensiv sein, aber eben nur für sehr kurze Zeiträume in einem Verarbeitungstag mit erheblichen Leerlaufzeiten.

Es ist auch nicht ungewöhnlich, dass ein HSM zweimal seine ursprünglichen Anschaffungskosten über einen Zeitraum von 5 bis 6 Jahren kostet, wenn Support- und Wartungskosten mit eingerechnet werden. Die Kosten für handelsübliche Crypto-Karten bis hin zu High-End Networked HSM's reichen typischerweise von € 2.000 bis zu € 40.000 pro Stück.

In der ersten Hälfte des letzten Jahrzehnts wurde die Lebensdauer eines HSM standardmäßig mit zehn Jahre angenommen. Am Ende des Jahrzehnts hatte sich diese Zeit auf etwa die Hälfte, also 5 Jahre, reduziert. Die Gründe dafür sind vielfältig, sind primär aber damit begründet, dass sich die Empfehlung des BSI (Technische Richtlinie) von der ursprünglichen Schlüssellänge massiv gewandelt hat und von 1024 auf 2048 und in der Zwischenzeit noch höher gesetzt wurde. Dies hat dazu geführt, das eine ganze Reihe von HSM´s komplett ausgetauscht werden mussten, andere wurden aufgrund der höheren Schlüssellängen erheblich mehr ausgelastet wurden. Teilweise war es sogar erforderlich, die HSM-Farmen massiv aufzustocken, um die geforderte Rechenleistung speziell im Batch-Betrieb verzögerungsfrei zur Verfügung stellen zu können.

Innerhalb dieser Produktionslebensspanne besteht auch die sehr hohe Wahrscheinlichkeit, dass jedes HSM jedes Jahr eine ganze Reihe von Firmware-Upgrades erhalten wird, da die HSM-Hersteller ihre Produkte mit Hilfe von Firmware-Upgrades und Sicherheits-Patches auf aktuellem Stand halten wollen und müssen.

Die neuesten HSM-Produkte haben immer eine höhere technische Leistungsfähigkeit sowie einen höheren Durchsatz als ihre jeweiligen Vorgänger. Es kann als realistisch betrachtet werden, vier vorhandene HSM-Geräte mit einem seiner Nachfolger zu konsolidieren. Während dies die HSM-Konsolidierung selbst erleichtern kann, kann die tatsächliche HSM-Nutzung immer noch sehr niedrig sein und zusätzliche inkrementelle HSM-Kapazitäten hinzufügen oder für die Rationalisierung und Modernisierung von HSMs ist das nicht einfach zu erreichen, wenn es um Enterprise Change Management und Governance-Anforderungen geht.

Bei bestimmten leistungsfähigen Zahlungssystemen, bei denen die HSM-Auslastung hoch war (60% +), war es in der Mitte des letzten Jahrzehnts nicht ungewöhnlich, über ein Dutzend HSMs oder sogar mehr auf einem Produktionssystem zu bündeln. Mit den neuesten HSM Produkten kann dies auf nicht mehr als 4 oder 5 Einheiten reduziert werden. Der Verlust eines HSM beispielsweise aufgrund eines technischen Fehlers bringt damit ganz andere operative Herausforderungen als noch vor 10 Jahren.

Es muss aber auch anerkannt werden, dass HSMs einen Produkt-Tausch während des normalen Betriebs als (kostenpflichtiges...) System-Upgrade erfahren werden. Dies ist weder allgemein anerkannt noch akzeptiert!

Während es ja eine gute Sache ist, dass Sie nun weniger neue HSMs im Vergleich zu deren Vorgängern benötigen, wurde nicht viel wichtiges getan, um das operative Management der HSMs zu verbessern. Organisationen, die z.B. mehrere sichere Datenbanksysteme verwenden, welche für die Schlüsselverwaltung auf HSMs angewiesen sind, haben mit der Insel-Lösung HSM für Datenbanksysteme so oder so trotzdem viel zu viel Überkapazität an HSM-Leistung geschaffen.
Eine Aufstellung:
1 x Produktiv
1 x HA
1 x Test

Und das ganze dann für die PKI genau so - und für email etc noch weiter folgend.

Innerhalb vieler großer Organisationen ist die Aufrechterhaltung ausgewogener technischer Gesamtkonfigurationen, einschließlich aller HSM-Überlegungen, anspruchsvoller, komplexer und viel teurer, als es jemals bei der ursprünglichen Projektinitiierung in Betracht gezogen wurde.

Ändern des HSM-Management-Modells

Mit diesen großen Kosten des HSM-Managements sowohl aus der Beschaffung selbst als auch der Instandhaltung von HSMs suchen die Unternehmen zunehmend nach günstigeren Wegen, um diese Herausforderungen zu meistern:

  • Kryptografische Ressourcen in sicherer Weise im Unternehmen zu teilen, um beispielsweise neue Geschäftsanwendungen ohne eigene HSM-Farm zu ermöglichen, vorhandene verwaltete HSMs als Kryptographie-Pool zu nutzen
  • Verringerung der Anzahl der HSM im Einsatz auf ein angemessenes Niveau
  • Die Wiederverwendung oder Umverteilung von bestehenden HSMs, die als Überschuss an Leistungsanforderungen angesehen werden können und die Vermeidung von mehreren HSM-Anbietern

Die Verringerung der direkten & indirekten Kosten, welche den HSMs zugeschrieben werden, darf allerdings nicht isoliert betrachtet werden, da es ihre tatsächliche Interaktion innerhalb Ihres Unternehmens ist, welche der entscheidende Faktor ist.

Partner | Referenzen
  • NXP.png
  • tuev-nord.jpg
  • 1_LOGO_Avalara.jpg
  • sbb.gif
  • 1_LOGO_VEEAM.png
  • DEUTSCHE_BANK.png
  • commerzbank.gif
  • Exponet Infrakon 4c.png
  • Postbank.jpg
  • 1_LOGO_SEMATICON.png
  • TDT-AG.JPG
  • 1_LOGO_NEXIONA.png
  • CLAAS.png
  • 1_LOGO_FARSITE.png
  • BAYER.png
  • VENTURETEC.png
  • netcologne.gif
  • ASKLEPIOS.png
  • gieseckedevrient.gif
  • Tsystems.gif