Effizientes Bereitstellen von Testdaten mit Oracle Data Masking

Transkript

1 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 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 adressen, 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

2 Abbildung 1 Links in Grid Control Formatbibliothek Bei Version 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

3 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 Zufallszahl Feste Zahl Zufallsdatum Feste Zeichenkette Zufallszeichenkette Teilstring Truncate Tabellenspalte Benutzerdefinierte Funktionen Löschen Postprocessing Funktionen Vertauschen 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:

4 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

5 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.

6 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

7 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 Foreignkey- Beziehungen 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 ADRESS 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:

8 Oliver Gehlert metafinanz Informationssysteme GmbH Leopoldstraße 146 D München Telefon: +49(0) Fax: +49(0) Internet: