Bundesamt für Sicherheit in der Informationstechnik

G 2.110 Mangelhafte Organisation bei Versionswechsel und Migration von Datenbanken

Alle organisatorischen Schritte vor und während eines Versionswechsels des Datenbankmanagementsystems ( DBMS ) oder einer Datenbankmigration werden in Migrations- und Versionskonzepten festgehalten. Das Fehlen solcher Konzepte kann die Aufgabenerledigung erheblich beeinträchtigen, wenn bei einer Datenbankmigration oder einem DBMS-Upgrade Probleme auftreten und das DBMS oder einzelne Datenbanken unvorhergesehen nicht zur Verfügung stehen.

Werden neben der Planung der physischen und semantischen Datenmigration keine sicheren Rückfallpositionen festgelegt, kann die Arbeitsfähigkeit der Datenbank bzw. des DBMS für Benutzer und Anwendungen gefährdet werden.

Bei einem DBMS-Versionswechsel bleiben die im DBMS abgelegten Datenbanken unverändert. Sicherheitsprobleme können hier weniger in der Datenbank selbst als im Zusammenspiel der Datenbanken mit dem neuen DBMS entstehen.

Beispiele:

  • Durch ein Datenbank-Upgrade wurden Grunddefinitionen in den Typen geändert.
  • Zugriffsberechtigungen für standardmäßig vom DBMS bereitgestellte Benutzergruppen sind geändert und beeinflussen damit die Rechte daraus abgeleiteter Benutzergruppen.

Bei einer Datenmigration werden Daten aus einer Datenbank in eine andere Datenbank überspielt. Dabei können die Daten in jeglicher Art konvertiert und in neue Strukturen einer Datenbank auf einem eventuell völlig anderen DBMS übertragen werden. Hier ist zu beachten, dass Datenbanken zur Sicherstellung der Datenkonsistenz unterschiedliche Konstrukte (Trigger, Constraints, etc. ) benutzen können. Über solche Konstrukte werden Reihenfolgen und Abhängigkeiten innerhalb der Daten implementiert, die bei Datenmigrationen berücksichtigt und entsprechend nachgebildet werden müssen. Die Analyse und Nachbildung aller einzuhaltenden Bedingungen kann sehr aufwendig und umfangreich sein. Dadurch besteht die Gefahr, dass sich Fehler einschleichen, die die Datenkonsistenz und die Funktionalität nach der Migration gefährden.

Beispiele:

  • Bei einer Datenbank-Migration von Microsoft Access auf den Microsoft SQL -Server müssen in Access vorhandene Spalten vom Typ AutoWert gesondert beachtet werden, da dieser Typ auf verschiedenen DBMS unterschiedlich implementiert ist.
  • In der zu migrierenden Datenbank existieren die zwei Tabellen MITARBEITER und FIRMA. Um sicherzustellen, dass neue Mitarbeiter nur existierenden Firmen zugeordnet werden können, wird der Tabelle MITARBEITER ein UPDATE/INSERT-Trigger zugeordnet, der vor Neueinträgen und/oder Veränderungen in der Tabelle MITARBEITER prüft, ob es in der Tabelle FIRMA einen korrespondierenden Eintrag gibt.

Sollte es keinen entsprechenden Eintrag in der Tabelle FIRMA geben, wird die UPDATE- oder INSERT-Anweisung abgebrochen. Die in dieser DB implementierte Reihenfolge (umgangssprachlich: "Zuerst Firma, dann erst Mitarbeiter") muss bei der Migration der Datenbank beachtet werden. Sollte im Migrationslauf die Tabelle MITARBEITER vor der Tabelle FIRMA übertragen werden, so wird die Einfügung verweigert, da noch keine korrespondierenden Einträge in der Tabelle FIRMA existieren.

Stand: Stand 2006

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK