41
02/2016 ·
MIDRANGE
MAGAZIN
Private Daten vor unbefugtem Zugriff schützen
Datenschutz für IBM i
Ursprünglich stand der Begriff des Datenschutzes für „Datensicherung“ und verfolgte
den Zweck, gespeicherte Daten vor Verlust, Diebstahl oder Veränderung zu schützen.
Das hat sich den letzten Jahren stark in Richtung Schutz privater Daten vor unbefugtem
Zugriff/unbefugter Verwendung verändert
P
ersönliche Daten finden wir heut-
zutage überall. Nutzer stellen In-
formationen in sozialen Netzwerken
ein, speichern Daten in Apps und auf
Webseiten von Anbietern. Diese Daten
werden von den Betreibern natürlich
auch irgendwo gespeichert. Nicht sel-
ten steckt ein IBM Power i-System mit
seiner integrierten Datenbank dahin-
ter. Dazu kommen natürlich Unterneh-
men, die persönliche Informationen
in Kunden-/Lieferantenstammdateien
speichern und täglich für die Bearbei-
tung von Anfragen, Bestellungen, Aus-
lieferungen verwenden. Persönliche
Daten finden sich demzufolge an vielen
Stellen in unserer IBM i-Datenbank.
Natürlich machen sich Administra-
toren, Systemverantwortliche und Soft-
warehäuser Gedanken darüber, wie un-
befugter Zugriff auf diese teilweise sehr
sensiblen Daten verhindert werden
kann. IBM hat in i5/OS gute Grundlagen
geschaffen, mit denen es möglich ist,
dies wirksam zu realisieren, etwa durch
umfangreiche Objektberechtigungen,
die es im Native-Bereich erlauben, sen-
sible Daten effektiv zu schützen.
Eine Funktion, die leider erst recht
spät implementiert wurde, nämlich in
i5/OS V7R1, ermöglicht es beispiels-
weise, Felder in Datenbanken zu ver-
schlüsseln, ohne dass sich dies auf
darüber liegende Anwendungen nega-
tiv auswirkt. Allerdings ist das Basis-
technologie, IBM stellt hier Exitpoints
zur Verfügung. Die Verschlüsselung
selbst sowie die Verwaltung und Be-
rechtigung von Anwendern auf diese
Daten ist Sache des Anwenders, Soft-
warehauses oder von Drittanbietern.
Auf jeden Fall ist dies eine effektive
Methode, berechtigten Benutzern die
vollen Informationen, teilweise berech-
tigten Benutzern nur Auszüge aus den
Feldern – etwa die letzten vier Stellen
einer Kreditkartennummer – und nicht
berechtigten Benutzern lediglich Platz-
halter anzuzeigen.
Eine zweite Funktion ist das eben-
falls in der Datenbank angesiedelte
RCAC – Row and Column Access Con-
trol, das vollständig mit i5/OS V7R2
implementiert wurde. Hierüber können
ebenfalls Berechtigungen von Benut-
zern auf Datensatz- und Spaltenebene
ermöglicht werden. Auch RCAC kann
den Zugriff auf definierte Datensätze
und einzelne Spalten innerhalb von Da-
tenbanken regulieren. Daneben bietet
RCAC auch die Möglichkeit, Felder zu
maskieren, so dass nur die gewünsch-
ten Inhalte den berechtigten Benutzern
präsentiert werden. Beide Möglichkei-
ten sind sehr effektiv, weil sie immer
angewandt werden, ganz gleich wie ein
Anwender auf Daten zugreift, ob über
eine Anwendung, etwa eine Warenwirt-
schaftssoftware, über Bordmittel wie
SQL oder DFU oder aber von externen
Rechnern aus via FTP/ODBC. Restrikti-
onen, die in der Datenbank angesiedelt
sind, greifen immer.
Manchmal reicht es schon, wenn
ein Benutzer lesend auf Informationen
zugreifen kann. Ein Beispiel aus der
Realität: Ein Kollege, der einen Flug
gebucht und diesbezüglich Nachfragen
hatte, hatte Kontakt mit einem Mitar-
beiter der Buchungsgesellschaft. Später
wurden Unregelmäßigkeiten auf dem
Kreditkartenkonto meines Kollegen
festgestellt, die bis zu besagtem Mitar-
beiter zurückverfolgt werden konnten
und so den Übeltäter entlarvten.
Wie so etwas funktioniert? Viel-
leicht hatte der Anwendungsentwick-
ler der Buchungsgesellschaft lesende
Zugriffe protokolliert, indem er einen
Trigger auf die Datenbank gelegt hat-
te, der jeden Zugriff, egal ob lesend
oder schreibend, aufzeichnete und so
eine Nachverfolgung ermöglichte. So
etwas hat natürlich auch mit Daten-
schutz zu tun. Eine Kombination von
Triggern und Journalisierung lässt, wie
am Beispiel der Anwendung iSecurity
AP-Journal eine lückenlose Nachverfol-
gung von Zugriffen auf Datenbankin-
halte zu. Wenn das in Echtzeit erfolgt
und dabei noch regelbasiert Aktionen
ausgeführt werden, um Verantwortli-
che sofort zu informieren, so ist das ein
perfektes Beispiel dafür, missbräuchli-
chen Zugriffen Einhalt zu gebieten.
Sie sehen, neben der Objektberech-
tigung, die IBM native ins Betriebssys-
tem implementiert hat, sind zwingend
weitere Maßnahmen erforderlich, um
den Zugriff auf sensible Daten effektiv
einzuschränken und/oder zu protokol-
lieren.
Robert Engel
ó
Û
