Ich habe bisher einen Aspekt absichtlich und gewissenhaft aus der sQLshell herausgelassen, mich aber jetzt - wo die Zahl der gefundenen Sicherheitslücken in allen möglichen Produkten immer mehr zunimmt - doch einmal damit beschäftigt...

Die sQLshell bietet ja Unterstützung bei der Migration ganzer Datenmodelle an, die auf XML beruht. Damit ist es auch möglich, zwischen Datenbank-Systemen zu nigrieren, die jede ihr eigenes proprietäres Austauschformat definieren und das jeweils andere nicht verstehen würden. Tabellenstruktur und einige andere Aspekte werden in extra dafür generierten XML-Schemata abgebildet.

Diese Lösung ist extrem flexibel: Beides - Schema und die eigentlichen Daten - läßt sich mit Standardwerkzeugen bearbeiten und anpassen. Es ist sogar möglich, mittels dieser Lösung eine direkte Migration zwischen Datenbanken mit der sQLshell zu realisieren: Sind zeitgleich beide Verbindungen (die zu Ziel und Quelle) in der sQLshell geöffnet, kommt der Migrationsprozess vollkommen ohne Dateien aus - alle Informationen werden direkt an die Zieldatenbank durchgeleitet.

Der Aspekt, den ich oben angesprochen habe und den ich bisher vernachlässigte ist sicherzustellen, dass die Daten, die aus der Quelle exportiert werden auch genau so wieder im Ziel importiert werden. Ich bin bisher hier der Unix-Philosophie gefolgt, die ja besagt: "Mach eine Sache - aber mache sie richtig!" Und daraus folgt, dass die Daten zunächst einmal aus dem Export als ganz normale Daten herauspurzeln und in Dateien geschrieben werden.

Anschließend steht es dem Anwender frei, diese Dateien zu verschlüsseln und/oder elektronisch zu signieren. Dann besteht aber ein kurzer Moment zwischen Abschluss des Exports und Beginn der Arbeit des hypothetischen Werkzeugs zum Absichern der Datei, in dem sie manipuliert werden könnte. Schließlich ist der Export zunächst nur eine Datei im Dateisystem ohne besondern Schutz. Und im Sinne von Zero Trust ist sogar die Möglichkeit nicht auszuschließen, dass das Dateisystem selbst kompromittiert ist und die Manipulation bereits beim Schreiben der Datei geschieht. Daher die Überlegung, das Signieren der Daten bereits in der sQLshell zu realisieren.

Zunächst schaute ich mir dafür XML Signaturen an. Allerdings gibt es in der Java-Implementierung hierbei ein Problem: Es besteht nur eine Implementierung für das Document Object Model (DOM) und nicht für die Simple API for XML (SAX). Der Unterschied: Für die Arbeiten mit XML-Dokumenten mittels DOM muss das Dokument komplett in den Speicher des Prozesses passen. Das lässt sich aber im beschriebenen Szenario nur schwer garantieren - schließlich ist die Größe des resultierenden XML nur von der Anzahl der Zeilen im Export abhängig und nicht begrenzt. Das war auch der Grund, warum ich mich entschied, für die Import/Export-Funktionalität der sQLshell auf SAX zu setzen.

Das bedeutet, es gibt mehrere Möglichkeiten für eine Umsetzung (abgesehen von der, die Umsetzung nicht vorzunehmen und alles so zu belassen, wie es aktuell ist):

• eine beliebige Zahl von Zeilen als Obergrenze festlegen - wenn der Export mehr hat, wird nicht signiert
• prinzipiell auf XML-Signaturen verzichten und einfach den Bitstrom signieren
• einfach probieren und wenns schiefgeht -> nochmal SAX und ohne Signatur?
• oder erstmal als Datei wie gehabt per SAX und anschließend die Datei signieren? Dann ist sie aber bereits einmal im Dateisystem aufgetupft...
• Könnte man eventuell eine Weiche ähnlich tee unter Linux im Export einbauen? Eine geht direkt in eine Datei, die andere erzeugt einen DOM-Baum. Nach Abschluss der Operation wird geschaut, ob der Baum erzeugt wurde und falls ja - signiert. Darf natürlich die Erzeugung des Output-Files nicht beeinträchtigen wenn der DOM-Baum kracht