- Anzeigen -


Sie sind hier: Home » Fachbeiträge » Grundlagen

Compliance-konforme Datensicherheit


HSM stellen sicher, dass Unternehmen aller Branchen ihre Vorgaben für die IT-Compliance erfüllen können
Hardware Security-Module erzeugen hochwertige kryptographische Schlüssel und speichern sie so sicher, dass unautorisierte Personen keinen Zugriff darauf haben

Autor Malte Pollmann
Autor Malte Pollmann Die Verantwortlichen sollten im Vorfeld prüfen, welche Compliance-Anforderungen ein HSM-Modul zwingend erfüllen muss, denn einzelne Sicherheitsstufen können auch Einschränkungen mit sich bringen, Bild: Utimaco

(05.05.15) - Die Vertraulichkeit und Integrität von Daten ist unverzichtbar – nicht zuletzt auch aus Compliance-Gründen. Eine Grundlage dafür: Die konsequente Verschlüsselung von wichtigen Informationen. Ein besonders hohes Schutzniveau bieten Hardware-basierte Verschlüsselungssysteme, so genannte Hardware Security Module (HSM). Zur Sicherung von Daten und Transaktionen sind kryptographische Verfahren unverzichtbar.

Sie umfassen zwei Bereiche:
• >> Das Erzeugen, Speichern und Verwalten von Schlüsseln sowie
• >> die Anwendung für die Signaturerstellung und Verschlüsselung mit diesen kryptographischen Schlüsseln.

Hier kommen Hardware Security-Module ins Spiel: Sie erzeugen hochwertige kryptographische Schlüssel und speichern sie so sicher, dass unautorisierte Personen keinen Zugriff darauf haben. Zudem stellen HSM sicher, dass Unternehmen aller Branchen ihre Vorgaben für die IT-Compliance erfüllen – eine Aufgabe, die nicht zu unterschätzen ist, steigt doch die Zahl der Verpflichtungen aus Gesetzen, Verordnungen und Normen ständig. Aber es geht nicht nur darum, Vorschriften zu erfüllen. Gezielte Maßnahmen für den Schutz wichtiger Unternehmensdaten lohnen sich auch im Hinblick auf Prozessqualität, Transparenz, Kosten und nicht zuletzt auf die Sicherung der Unternehmenswerte.

HSM - Schutzmaßnahmen und Funktionsweise
Ein Hardware-Sicherheitsmodul stellt eine Reihe von Schutzmaßnahmen zur Verfügung. Dazu zählen das Erkennen von Manipulationsversuchen durch eine Versiegelung der Recheneinheit, Maßnahmen, um das Auslesen von Daten und Signalen aus der Recheneinheit zu verhindern sowie automatische Löschroutinen im Falle eines Angriffs. Außerdem stellt ein HSM über ein spezielles, gehärtetes Betriebssystem Verfahren bereit, die ausschließlich den Zugriff autorisierter Administratoren erlauben.

Die Funktionen des HSM stehen über eine definierte Schnittstelle (API) zur Verfügung. So kann beispielsweise eine Finanzanwendung die gesamte Schlüsselverwaltung auf ein HSM auslagern. Dies erhöht zum einen die Sicherheit. Zum anderen wird der Host-Rechner entlastet, auf dem die Anwendung läuft. Ein bekannter Vertreter einer Standardschnittstelle ist PKCS#11 (OASIS PKCS 11 TC, 2014). Ursprünglich wurde sie entwickelt, um X.509-Token und deren Anwendung zu adaptieren. Im Grunde lässt sich HSM als Security-Token einordnen – also als ein System, das die sichere Speicherung und Anwendung von kryptographischen Schlüsseln ermöglicht. Allerdings unterstützt ein HSM im Unterschied zu einem Token nicht nur eine einzelne Identität, das heißt einen einzelnen Nutzer, sondern kann sehr viele Schlüsseldaten mit unterschiedlichen Identitäten verarbeiten.

Alternativen zu Standard-APIs
Applikationsschnittstellen sind somit ein zentraler Punkt bei HSM. Einerseits bilden sie die vitale Schnittstelle zum legitimen Nutzer des Schlüssels, andererseits bieten sie Angreifern standardisierte Ansatzpunkte. Die Wahl der richtigen Schnittstelle erfordert daher eine genaue Analyse der Anwendungsumgebung und des Sicherheitskonzeptes.

Dies ist ein Grund, weshalb sich bei HSM proprietäre API etabliert haben. Ein weiterer ist, dass sich mit fachspezifischen Schnittstellen die Komplexität einer Standard-API reduzieren lässt. Das wiederum macht es einfacher, die Vorgaben branchenspezifischer Sicherheitskonzepte zu erfüllen.

Hinzu kommen folgende Vorteile von individuellen APIs bei Hardware-Sicherheitsmodulen:
• >> höhere Performance, die vor allem bei Hochleistungs-Transaktionssystemen wichtig ist,
• >> bessere Auditierbarkeit,
• >> optimierte Host-Programmierung und damit die Möglichkeit, das HSM als Teil eines Gesamtsystems zu betrachten,
• >> niedrigere Komplexität, die etwa für die Zertifizierung eine Rolle spielt.

Diesen Vorzügen stehen bei herstellerspezifischen Schnittstellen einige Nachteile gegenüber. Dazu zählt, dass der Austausch von HSM-Systemen aufwändig sein kann. Da im Normalfall eine Anpassung der HSM-Firmware erfolgt, ist ein Wechsel zu einem anderen Hersteller nur nach Anpassung von dessen Produkten möglich.
Hinzu kommen Einschränkungen in Bezug auf die Erweiterbarkeit. Denn bei jeder funktionalen Erweiterung der Host-Anwendung fallen Funktionserweiterungen an der HSM-Schnittstelle an. Diese müssten programmiert und gegebenenfalls neu zertifiziert werden.

Ein HSM für Schutzmaßnahmen

Hardware Security Module (HSM)
Hardware Security Module (HSM) Zuverlässigen Schutz vor Cyber-Angriffen und Datenverlusten durch Unachtsamkeit und Bedienungsfehler. Dadurch legen HSM Grundlage für eine sichere und vertrauensvolle Kommunikation, Bild: Utimaco


Lösungen mit Zertifikat
Je nachdem, in welcher Branche und in welchen Ländern ein Unternehmen tätig ist, existieren unterschiedliche Compliance-Vorgaben. Diese schreiben teilweise auch bestimmte Sicherheitszertifikate der eingesetzten Lösungen vor. Zu den wichtigsten Zertifizierungs-Frameworks zählt FIPS 140-2 des NIST (National Institute of Standards and Technology). Es dokumentiert, dass ein HSM für die vom NIST freigegebenen Verschlüsselungsalgorithmen ausgelegt ist und zudem die grundlegenden Anforderungen hinsichtlich der physischen Sicherheit erfüllt. Die Vorgaben der Spezifikation Common Criteria for Information Technology Security Evaluation von ISO und IEC sind flexibler. Allerdings gibt es bislang nur ein einziges spezielles Profil für die Absicherung von HSM. Darüber hinaus existieren weitere Zertifizierungen, etwa gemäß PCI-HSM.

Die Verantwortlichen sollten im Vorfeld prüfen, welche Compliance-Anforderungen ein HSM-Modul zwingend erfüllen muss, denn einzelne Sicherheitsstufen können auch Einschränkungen mit sich bringen. Ein Beispiel: Erfüllt ein HSM die Vorgaben von FIPS 140-2 Level 3, arbeitet es im FIPS-Modus. Das wiederum schränkt die Nutzung von APIs mit ein. Außerdem existieren Limitierungen bezüglich der Schlüssel-Länge und der Schlüssel-Attribute.

Fazit
HSM bieten Unternehmen aller Branchen einen sicheren Weg, um ihre Kommunikationskanäle sowie übermittelte Daten vor dem Zugriff Unbefugter zu schützen und ihre IT Compliance-konform auszurichten. Darüber hinaus gewinnen IT-Verantwortliche damit zusätzliche Rechenkapazitäten, um Lastspitzen aufzufangen. Neue Verfahren erlauben sogar, unternehmensspezifische Funktionen in ein HSM zu implementieren, ohne vorhandene Zertifizierungen zu verlieren.

Check-Liste: Das richtige Hardware Security Modul finden
Auf dem Markt ist eine Vielzahl unterschiedlicher Hardware Security Module zu finden. Folgende Kategorien gilt es zu berücksichtigen:
• Technische Faktoren: dazu zählen unter anderem die Performance und Skalierbarkeit, Redundanz und Backup-Optionen, APIs, Betriebssysteme, Hardware-Support und vor allem die physische Sicherheit, etwa Schutzmechanismen gegen Einbruchsversuche
• Formfaktor: hier haben Unternehmen die Auswahl zwischen Network-attached und Embedded HSM
• Zertifizierungen: wichtig ist eine eindeutige Identifizierung der nötigen Zertifizierung
• Unterstützung durch den Anbieter: Image, Referenzen und Integrationsservices können Unternehmen bei der Entscheidung für ein HSM helfen. Speziell für Unternehmen und öffentliche Einrichtungen in Deutschland spielt ein weiterer Aspekt eine Rolle – nämlich in welchem Land der Anbieter der HSM-Lösung beheimatet ist. So unterliegen Hersteller mit Hauptsitz in Deutschland ausschließlich den hier oder in der EU geltenden Gesetzen. Der Zugriff auf Kundendaten oder technische Details einer Verschlüsselungslösung durch staatliche Einrichtungen ist im Gegensatz zu anderen Ländern ausgeschlossen.

(*) Der Autor:
Malte Pollmann ist seit 2008 Mitglied des Management Boards von Utimaco und seit 2011 CEO. Zuvor war er Product Director und Geschäftsbereichsleiter bei Lycos Europe NV. Pollmann studierte Physik an den Universitäten Paderborn und Kaiserslautern und absolvierte eine Ausbildung in General Management bei INSEAD in Fontainebleau. Er ist Aufsichtsratsmitglied der International School of IT-Security (isits AG) in Bochum.
(Utimaco: ra)

Lesen Sie auch den Schwerpunkt:
"IT-Sicherheit im Kontext von Compliance"

Utimaco: Kontakt und Steckbrief

Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.

- Anzeigen -





Kostenloser IT SecCity-Newsletter
Ihr IT SecCity-Newsletter hier >>>>>>

- Anzeigen -


Meldungen: Grundlagen

  • Große Zahl ungesicherter IoT-Geräte

    DDoS-Angriffe haben sich in den letzten sechs Monaten nahezu verdoppelt. Laut einer Studie von Corero Network Security entspricht das einem monatlichen Mittel von 237 Angriffsversuchen. Einer der Gründe für den Anstieg liegt in der hohen Zahl einfach zu übernehmenden IoT-Geräten, die zumeist nur unzureichend geschützt sind. Diese "smarten" Geräte eignen sich dann ganz vorzüglich um zu einem Teil eines riesigen Botnets zu werden. Dieses Problem wird sich weiter verschärfen. Dazu muss man nur an die unzähligen Gadgets für Endverbraucher denken, die etwa in der Weihnachtszeit über die physischen und virtuellen Ladentische gewandert sind. Diese Geräte sind eines der vordringlichen Ziele für die Übernahme durch Hacker. Neben den Bedenken, die man im Hinblick auf die Sicherheit der Privatsphäre und vertraulicher Daten hegen kann gibt es noch eine ganze Reihe von weiteren ernsthaften Gefahren, die mit diesen Geräten verbunden sind. Hacker machen sich unsichere IoT-Geräte zunutze um riesige Bot-Netze aufzubauen und DDoS-Attacken zu lancieren. Unsichere IoT-Devices waren in einigen der größten DDoS-Angriffe auf Online-Plattformen innerhalb der letzten Jahre beteiligt. Es spielt bei DDoS-Angriffen keine Rolle, wie groß ein Unternehmen ist. Gefährdet sind alle. Und sollten entsprechend Sorge tragen, was die Sicherheit ihrer Geräte, Daten und Netzwerke anbelangt.

  • A fool with a tool

    Unternehmen stehen heute vielfältige Sicherheitslösungen zur Verfügung. Doch ein Sammelsurium aus technischen Einzelmaßnahmen kann nur bedingt gegen Angriffe schützen. Vielmehr benötigen Unternehmen eine Informationssicherheitsstrategie, gestützt auf Prozesse und Tools die es einem Unternehmen ermöglichen, Informationssicherheit effizient und effektiv zu managen. Der Schlüssel zum Erfolg wird dabei im richtigen Mix aus Menschen und deren Fähigkeiten, Prozessen und Tools liegen. Nur so wird es Unternehmen gelingen proaktiv zu agieren und durch Antizipation zukünftiger Bedrohungen und entsprechender Vorbereitung die richtigen Maßnahmen zum Schutz ihrer sensiblen Daten zu treffen.

  • Was ist Certificate Transparency?

    Möglicherweise haben Sie schon vor einigen Jahren von Certificate Transparency (CT) gehört, als Google die Anforderung für alle Extended Validation (EV) SSL/TLS-Zertifikate ankündigte, die nach dem 1. Januar 2015 ausgestellt worden sind. Seitdem hat Google die Anforderung auf alle Arten von SSL-Zertifikaten ausgedehnt und zuletzt eine Frist bis zum April 2018 gesetzt. Zertifikaten, die nicht CT-qualifiziert sind und die nach diesem Datum ausgestellt werden, wird in Chrome nicht vertraut. GlobalSign hat im Hintergrund bereits daran gearbeitet, dass alle Zertifikate mit CT ausgestattet werden - Extended Validation (EV) seit 2015, Domain Validated (DV) seit August 2016 und Organisation Validated (OV) ab Oktober 2017 - GlobalSign-Kunden sind damit für den Fristablauf seitens Google gerüstet.

  • Wo ist der Authentifizierungsprozess fehlbar?

    Ich habe den größten Teil meines beruflichen Lebens damit verbracht Authentifizierungslösungen zu programmieren, zu implementieren, weiterzuentwickeln und zu patentieren. Daher nehme ich mir das Recht heraus zu sagen, letzten Endes funktioniert Authentifizierung einfach nicht. Mit "funktionieren" im engeren Sinne meine ich, dass es zu 100Prozent garantiert ist, dass es sich tatsächlich um eine vertrauenswürdige Identität handelt, wenn eine Benutzeridentität von einer Authentifizierungslösung an den betreffenden Partner weitergeleitet wird. Und genau das lässt sich nicht garantieren. Es lässt sich belegen, dass und wie der eigentliche Validierungsprozess innerhalb der Authentisierung funktioniert. Das bedeutet, wir verifizieren mathematisch und empirisch, dass die von einem Authentifizierungsmechanismus zusammengestellte Entität mit den Werten übereinstimmt, die in der Datenbank des akzeptierenden Dritten gespeichert sind, also "matched". Das kann ein Passwort sein, ein Einmal-Passwort, OTP, X.509-basierte Verschlüsselung, biometrische Merkmale, mobile Push-Werte oder eine Gesichtserkennung. In einem Satz: Der Authentisierungsprozess lässt sich validieren und damit auch, dass das technische System korrekt arbeitet.

  • Rollende Sicherheitslücken

    Viele Fahrzeuge sind heutzutage längst zu rollenden Computern geworden, denn bereits jetzt stecken in der Software eines modernen Oberklasse-PKW etwa 100 Millionen Codezeilen. Zum Vergleich: Die Flugsoftware einer Boeing 787 Dreamliner kommt mit etwa 14 Millionen Zeilen aus. Die Erwartungen an das zukünftige autonom fahrende Auto sind vielzählig: Mehr Sicherheit auf den Straßen, mehr Komfort, beispielsweise durch selbstständiges Einparken, die Nutzung eines Autopiloten im Stau oder komplett fahrerlose Roboterautos, welche im Car-Sharing-Verfahren neue Infrastrukturmöglichkeiten bieten könnten. Dem gegenüber stehen die Ängste: Bei Technikfehlern nur noch ein hilfloser Passagier an Board zu sein oder Opfer eines Hacker-Angriffs zu werden.