Konfrontiert mit einer steigenden Anzahl an Sicherheitsvorfällen und verschärften rechtlichen Anforderungen interessieren sich viele Unternehmen dafür, wie sie sensible Daten auf ihren IBM-i-Systemen schützen können. Eine effektive Technik, um die Vertraulichkeit solcher Daten zu gewährleisten, ist die gezielte Verschlüsselung von DB2-Daten auf Feldebene. Wie das funktioniert und wie die Alternativen aussehen, erfahren Sie in diesem Artikel.

Warum aber müssen Daten geschützt werden? Zum einen existieren handfeste Gründe in Form verschiedener Vorschriften und Empfehlungen. Der Datenschutz etwa stellt den Schutz personenbezogener Daten obenan. Gerade die EU-Datenschutzgrundverordnung, die sonst sehr zurückhaltend ist, wenn es darum geht, konkrete technische Maßnahmen zu benennen, führt die Verschlüsselung gleich viermal an (Erwägungsgrund 83, Artikel 6, 32 und 34). Ähnlich der IT-Grundschutz-Katalog, in dem der Verschlüsselung ein ganzes Kapitel mit dem lyrischen Namen „M 4.72 Datenbank-Verschlüsselung“ gewidmet ist. Die BaFin empfiehlt in einem aktuellen Entwurf zu „Versicherungsaufsichtlichen Anforderungen an die IT“ (VAIT) den Einsatz von Verschlüsselung. Weitere Beispiele finden sich etwa in der Payment Cards Initiative (PCI) und dem COBIT-Framework.

Zum anderen aber liegt es im ureigenen Interesse jedes Unternehmens, bestimmte Daten vor unbefugten Zugriffen zu schützen – sei es, um das Vertrauen seiner Kunden und Partner zu bewahren („unsere Daten sind bei Müller KG sicher“), was heutzutage einen immer gewichtigeren Faktor darstellt, oder sei es, um kritische Interna wie Geschäftszahlen oder Kundennamen vor der Konkurrenz zu schützen.

Die IBM i bietet standardmäßig eine Reihe von APIs zur Verschlüsselung. Diese haben den Vorteil, dass sie leistungsfähige und als sehr sicher geltende Verschlüsselungsalgorithmen wie den Advanced Encryption Standard (AES) abbilden.

Bis einschließlich Version 6 von i5/OS war die Verfügbarkeit solcher APIs alles, was die IBM i im Hinblick auf die Verschlüsselung anzubieten hatte. Wer Daten in DB2-Dateien schützen wollte, musste irgendwie sicherstellen, dass seine Verschlüsselungsroutinen bei Zugriffen auf die Daten ausgeführt wurden. Solche Lösungen waren mit Änderungen an den Anwendungen verbunden, was je nach Situation aufwändig oder sogar unmöglich war.

IBM i 7.1 änderte dies gründlich. Denn diese Version stellte mit den sogenannten Field Procedures eine „enabling technology“ zur Verfügung, die eine deutlich einfachere Verbindung von Verschlüsselungs-APIs und DB2-Zugriffen ermöglichte. Field Procedures lassen sich für jedes Feld einer Datei festlegen (also für jede Spalte in jeder Tabelle, wenn man die SQL-Ausdrücke bevorzugt). Wenn man sich eine Datei als eine Art Excel-Datenblatt mit horizontalen Datensätzen und vertikalen Spalten vorstellt, dann wird für bei jedem Zugriff jede Zelle, die in einer Spalte mit Field Procedure enthalten ist, die Field Procedure ausgeführt. Das geschieht nach dem Aktivieren der Field Procedure automatisch und ohne Änderungen an den zugreifenden Anwendungen. Eine Field Procedure ist also quasi ein Exit Point, der beim Zugriff auf eine Datenbankzelle automatisch aufgerufen wird, den Inhalt der Zelle als Parameter erhält und ein definiertes Programm aufruft.

Kommerziell verfügbare Verschlüsselungslösungen für IBM i wie Crypto Complete von HelpSystems nutzen Field Procedures, um Daten beim Schreiben in die Datenbank automatisch zu verschlüsseln und diese beim Lesen entweder zu entschlüsseln oder durch einen sogenannten maskierten Wert wie „XXXX“ anzuzeigen, dass der Zugriff nicht erlaubt ist (siehe untenstehende Abbildung). Als Kriterium wird dabei das zugreifende Benutzerprofil verwendet: Steht es auf einer vom Crypto-Complete-Administrator festgelegten Liste, wird der Zugriff erlaubt, und der Zellinhalt wird entschlüsselt. Alle anderen Benutzerprofile sehen nur einen teilweise oder sogar vollständig maskierten Wert wie „XXXXXXXXXXXXXXXX“. Das gilt auch für Benutzerprofile mit *ALLOBJ-Berechtigung wie QSECOFR.

Auf diese Weise kann eine Verschlüsselung ohne Änderung an den verwendeten Applikationen aufgesetzt werden. Außerdem können gezielt nur die Felder verschlüsselt werden, die schützenswürdig sind, nach der DSGVO etwa Namen oder Kontonummern von Kunden oder Partnern. Diese Beschränkung der Verschlüsselung auf ausgewählte Spalten minimiert den Overhead, der eine Verschlüsselungslösung grundsätzlich begleitet.

Tabelle: Vergleich Platten- und Feldverschlüsselung

Platt(e) gemacht

Im Gegensatz zur Verschlüsselung mit Field Procedures werden bei der Festplattenverschlüsselung grundsätzlich alle Daten verschlüsselt gespeichert. Der für die Entschlüsselung notwendige Schlüssel muss einmalig an die Festplatte übermittelt werden, wenn die Festplatte eingeschaltet wird. Danach ist die Platte „freigeschaltet“ und ver- und entschlüsselt transparent, bis sie wieder heruntergefahren wird oder der Strom ausfällt. Bei der Plattenverschlüsselung findet also nach der Erstauthentifizierung keine Zugriffsprüfung mehr statt. Im Gegensatz dazu wird bei der Feldverschlüsselung bei jedem lesenden Zugriff auf ein verschlüsseltes Feld überprüft, ob der Zugang erlaubt ist (siehe Tabelle oben).

Die beiden Ansätze entsprechen unterschiedlichen Bedrohungsszenarien: Die Plattenverschlüsselung schützt Sie, wenn Platten physisch entwendet werden oder durch ein Versehen ohne Datenlöschung nach außen gelangen. Die Feldverschlüsselung schützt in den folgenden Szenarien:

Hacker verschaffen sich Zugriff über das Internet;

Mitarbeiter, die einen Zugang zum System haben, versuchen, auf Daten zuzugreifen, für die sie nicht befugt sind.

Diese letzten beiden Szenarien sind heute die wichtigeren: Hackerangriffe via Internet und Mitarbeiter mit Impulskontrollproblemen sind ein höheres Risiko als Einbrecher, die sich nachts durch Stahltüren schweißen, um die IBM i zu entführen. Darum sollte die Feldverschlüsselung immer die erste Lösung sein, um die ein Unternehmen sich kümmern muss; erst danach lohnt es sich, sich Gedanken über eine Plattenverschlüsselung zu machen.

Datenbankabfrage bei Verwendung von Feldverschlüsselung. Die Daten für die angefragte Spalte wurden zuvor bereits transparent verschlüsselt. Über dieselbe Field Procedure werden sie nun an Crypto Complete gereicht. Nach erfolgreichem Vergleich mit der Liste der berechtigten Benutzer werden die Daten entschlüsselt und über Field Procedure und DB2 an die Anwendung zurückgemeldet. Quelle: Helpsystems

Gute Lösungen, schlechte Lösungen

  • Zum Abschluss findet sich eine kurze Checkliste für Verschlüsselungslösungen auf der IBM i. Gute Lösungen sollten
  • weithin akzeptierte und als sicher geltende kryptografische Algorithmen unterstützen, vor allem AES,
  • eine sichere und benutzerfreundliche Schlüsselverwaltung bieten,
  • transparente Ver- und Entschlüsselung mittels Field Procedures unterstützen,
  • Daten auch vor *ALLOBJ-Benutzerprofilen schützen können,
  • die Anbindung externer Keystore Appliances mittels KMIP-Protokoll unterstützen.

    www.helpsystems.com