Effizientes Bereitstellen von Testdaten mit Oracle Data Masking

Effizientes Bereitstellen von Testdaten mit Oracle
Data Masking
Oliver Gehlert
metafinanz Informationssysteme GmbH
München
Schlüsselworte:
Oracle Grid Control, Oracle 11gR2, Security, Compliance, Test
Einleitung
Laut einer Studie des Ponemon Instituts verwenden mehr als 70% der befragten Unternehmen
sensible Originaldaten für ihre Testsysteme. Dies geschieht, obwohl nur 7% der Unternehmen
davon ausgehen, dass ihre Testsysteme ausreichend geschützt sind.
Aus welchen Gründen werden diese sensiblen Daten ungeschützt übernommen? Die Gründe
dafür sind u. a. das Nachstellen von Fehlern, die nur in Produktion aufgetreten sind, Tunen
von Statements, konsistente Testdaten und das einfache Erstellen der Testdatenbank.
Abgesehen vom ersten Punkt, können all diese Punkte mit dem Oracle Data Masking Pack
gelöst werden.
Das Data Masking Pack für Grid Control ab 10.2.0.4 bzw. die DB Console in Version 11g
Release 2 bietet die Möglichkeit sensible Daten automatisiert zu ersetzen.
Anforderungen an die Datenmaskierung
Die Maskierung einzelner Spalten, ohne Berücksichtigung von Fremdbeziehungen ist trivial.
Kompliziert wird es dann, wenn Daten sinnvoll verschlüsselt werden sollen und die
referentielle Integrität erhalten bleiben muss. Existieren abhängige Daten, wie Emailadressen,
oder Regionszuordnungen, dann müssen diese Spalten auch angepasst werden.
All diese Anforderungen lassen sich problemlos mit PL/SQL umsetzen, der Aufwand ist aber
merklich und Anpassungen sowie Erweiterungen sind nur mit größerem Aufwand
implementierbar.
Oracle Data Masking
Benötigte Infrastruktur
Um das Data Masking Pack verwenden zu können, benötigt man entweder Grid Control, das
die entsprechenden Datenbanken verwaltet oder die DB Console ab Oracle Datenbankversion
11g Release 2.
Verwendung des Enterprise Managers
Data Masking ist ein Unterpunkt des Reiters „Schema“
Abbildung 1 Links in Grid Control
Formatbibliothek
Bei Version 10.2.0.5 bzw. in der DB Console werden ein paar Maskierungsdefinitionen
mitgeliefert. Die Definitionen sind aber eher für den amerikanischen Markt interessant:
• Social Security Number
• Telefonnummer USA
• ISBN
• Kreditkartennummern
• UPC
Abbildung 2 Formatbibliothek
Das Anlegen neuer Definitionen erfolgt über einen Assistenten. Angelegte Definitionen sind
für alle Benutzer von Grid Control sichtbar. Es erfolgt keine Zuordnung zu Tabellenspalten.
Formatdefinitionen
Formatdefinitionen sind spaltenbezogen und weisen Spalten Maskierungsformate aus der
Formatbibliothek bzw. neu erstellte Formate zu. Die Formatdefinitionen können sich auf
einzelne Spalten oder Spaltengruppen beziehen. Die Formatdefinitionen können, wie die
Einträge aus der Formatbibliothek, im XML-Format exportiert bzw. importiert werden. Die
Formatdefinitionen stehen nur dem Benutzer zur Verfügung, der sie angelegt hat.
Maskierung einzelner Spalten
Für die Maskierung einzelner Spalten stehen folgende Maskierungsmöglichkeiten zur
Verfügung:
•
•
•
•
•
•
•
Wertemenge
Feste Zahl
Feste Zeichenkette
Teilstring
Tabellenspalte
Löschen
Vertauschen
•
•
•
•
•
•
•
Zufallszahl
Zufallsdatum
Zufallszeichenkette
Truncate
Benutzerdefinierte Funktionen
Postprocessing Funktionen
Ersetzung durch Hashwert
Bei Spalten vom Typ Varchar2 können mehrere Maskierungsformate zusammengefügt
werden, bei Date- oder Numberspalten ist nur eine Maskierung zulässig:
Abbildung 3 Zusammengesetzte Formate
Die Maskierung einzelner Spalten kann auch in Abhängigkeit von den Werten anderer
Spalten erfolgen. Dies kann bei nicht komplett normalisierten Datenmodellen vorkommen:
Abbildung 4 Bedingte Maskierung
Grid Control testet weder bei der Anlage noch bei der Skriptgenerierung, ob die Definition
überschneidungsfrei ist. Eventuelle Fehler erhält man erst zur Laufzeit.
Existieren Abhängigkeiten zwischen mehreren Spalten, so kann man diese als Spaltengruppen
maskieren. Hierbei stehen aber deutlich weniger Formatmasken zur Verfügung
Maskierung von Spaltengruppen
Abbildung 5 Spaltengruppen
Abbildung 6 Maskierungsformate für Gruppen
Erhaltung der referentiellen Integrität
Werden Spalten maskiert, auf die Foreign Keys verweisen, so nimmt Oracle Data Masking
automatisch die zugehörigen Spalten mit in die Maskierungsdefinition auf. Gibt es
Abhängigkeiten, die nur in der Applikation abgeprüft werden, so kann man die Spalten
manuell über „Dependent Columns“ hinzufügen.
Abbildung 7 Abhängige Spalten
Datenbankcloning
Das effizienteste Verfahren zur Erstellung einer Testdatenbank ist das Clonen der
Produktivdatenbank per RMAN. Das Data Masking Pack erlaubt es, eine oder mehrere
Maskierungsdefinitionen an den Cloningprozess anzubinden. Das Maskieren erfolgt hierbei
nach dem Cloning.
Als Ziele stehen alle Server zur Verfügung, die als Ziele in Grid Control hinterlegt sind und
auf denen die passende Softwareversion installiert ist. Ab Oracle 11gR2 kann die Datenbank
auch direkt mit RMAN geclont werden, ohne das die Backupdateien zwischengespeichert
werden müssen.
Hinter den Kulissen von Data Masking
Aus den angelegten Formaten generiert Grid Control SQL-Skripte, die mehrere Prozeduren
und Funktionen enthalten, sowie eine eigene Jobsteuerung, die die eigentliche Maskierung
durchführen:
• Test, ob der Benutzer zur DBA-Gruppe gehört
• Erstellen einer Zwischentabelle MGMT_DM_TT_ mit Ursprungsspaltenwert und
maskiertem Wert
• Löschen aller Constraints der betroffenen Tabellen
• Löschen aller Indizes auf den betroffenen Tabellen
• Umbenennen der Tabellen in Tabellenname$DMASK
• Neuerstellen der Tabellen per Create Table as Select ausgehend von der umbenannten
Ursprungstabelle und der Zwischentabelle mit den maskierten Spalten.
• Löschen der $DMASK-Tabellen
• Neuanlage von Not Null Constraints, Unique Keys und Primary Keys
• Anlegen von Foreign Keys
• Neubestimmung der Statistiken mit Sample_Size Auto
• Löschen der Zwischentabellen
Aufgrund dieses Vorgehens werden abhängige Packages, Views, Materialized Views und
Trigger invalidiert.
Maskiert man Dimensionen und Fakttabellen, so wird nur eine Zwischentabelle je Dimension
angelegt, die zum Maskieren der Dimensionstabelle und Fakttabelle verwendet wird. Dadurch
bleiben die vorhandenen Mengengerüste und Datenverteilungen erhalten.
Lizenz
Das Data Masking Pack ist eine Option für die Oracle Enterprise Edition und muss
entsprechend für je CPU oder Named User lizenziert werden. Zu lizenzieren ist nicht nur die
Produktivdatenbank sondern auch die zugehörigen Testdatenbanken.
Die Verwendung der Data Masking Funktionalität im Enterprise Manager muss gesondert
lizenziert werden. Zu den lizenzpflichtigen Features gehören:
• Alle zugehörigen Seiten im Enterprise Manager
• Die Formatbibliothek
• Die Maskierungsdefinitionen
• Der Export und Import von Definitionen bzw. Templates
• Die Skriptgenerierung
• Datenbankcloning und Maskierungsworkflow
• Bei den Maskierungstechniken
o Bedingte Maskierung
o Zusammengesetzte Maskierung
o Deterministische Maskierung
Für die genauen Lizenzbedingungen wenden Sie sich bitte an Ihren Oracle
Vertriebsbeauftragten.
Oracle Datapump
Seit Oracle 11g Release 1 gibt es auch die Möglichkeit Daten beim Export mit Oracle
Datapump zu verändern. Hierzu wird für jede angegebene Spalte eine Funktion aufgerufen,
die ausgehend vom Originalwert einen neuen Wert zurückliefert. Es werden hier keine
fertigen Definition mitgeliefert.
Alternativ können die Daten beim Import mit Oracle Datapump verändert werden. Die Syntax
ist analog zum Datapumpexport.
Durch die Verwendung selbsterstellter Funktionen erreicht man mit Datapump maximale
Anpassung an die eigenen Anforderungen. Nachteilig ist aber, dass man selber für die
referentielle Integrität der Testdaten verantwortlich ist, und daher für Spalten mit ForeignkeyBeziehungen nur deterministische Funktionen verwendet werden können. Auch die
Maskierung abhängiger Spalten muss programmatisch gelöst werden. Bei den
Maskierungsfunktionen kann aber nur die zu maskierende Spalte als Parameter übergeben
werden. Das obige Beispiel für die Berechnung der Spalte AGE_RANGE, bzw
EMAILADRESS wäre mit Datapump nicht abbildbar.
Je nach Qualität und Anzahl der Maskierungsfunktionen erhöht sich der Zeitbedarf für den
Export deutlich, bei 3 Millionen Zeilen und einer Maskierungsfunktion (Random)
verdreifacht sich der Zeitbedarf für den Export.
Fazit
Mit Oracle Data Masking ist das Thema Testdatenerstellung deutlich vereinfacht worden.
Durch die Integration in die DB Console bei der Version 11gR2 wird auch keine aufwendige
Infrastruktur mehr benötigt, was die Nutzbarkeit von Data Masking deutlich vereinfacht.
Die Performance ist selbst auf schwächeren Testservern ausreichend und die Einbindung in
den Cloningprozess führt das Maskieren direkt nach dem Erstellen der Testdatenbank durch.
Das Clonen auf andere Server ist nur per Grid Control möglich, aber man kann das
Duplizieren und Maskieren auch per rman- und SQL-Skript automatisieren.
Datenschutz in Test- und Integrationsumgebungen ist ab sofort kein aufwendiges Unterfangen
mehr. Das Data Masking Pack erlaubt die komfortable Erstellung unterschiedlichster Regel
zur Datenmanipulation und die resultierenden Skripte können einfach in bereits vorhandene
Prozesse integriert werden. Durch die Realisierung in PL/SQL sind die Skripte auch
Plattformübergreifend zu verwenden.
Eine günstigere Alternative ist Oracle Datapump, die sich insbesondere für heterogene
Umgebungen anbietet. Die Maskierung einzelner Spalten ist hier ebenfalls sehr flexibel
gelöst, aber die Erhaltung referentieller Integrität bzw. die Konsistenz über unterschiedliche
Spalten hinweg ist für Datapump zu komplex.
Kontaktadresse:
Oliver Gehlert
metafinanz Informationssysteme GmbH
Leopoldstraße 146
D-80804 München
Telefon:
Fax:
E-Mail
Internet:
+49(0)89-360531-0
+49(0)89-360531-15
[email protected]
www.metafinanz.de