3 Datenübertragung (S. 110-111)

In diesem Kapitel geht es um die Sicherheit während der Übertragung der Datenbankdaten über das Netzwerk und wie man sich gegen etwaige Angriffe schützt.

Die Gefährdungen, die hier besprochen werden, setzen voraus, dass der Angreifer Zugriff auf den Datenverkehr hat oder sich diesen verschaffen kann. Oracle basiert auf der so genannten Two-Task-Architektur: Datenbank und Benutzerprozess( e) laufen als unterschiedliche Tasks physisch getrennt im Hauptspeicher. Im Detail funktioniert das so: Wenn die Datenbank gestartet wird, reserviert sie sich einen konfigurierbaren Bereich im Hauptspeicher: die System Global Area oder SGA. Sie dient zur Speicherung interner Strukturen, zum Cachen von Daten, zur Verwaltung von SQL etc. Daneben werden verschiedene Prozesse gestartet, die als Hintergrundprozesse bezeichnet werden und sich an die SGA anhängen. Wie das geschieht, hängt vom jeweiligen Betriebssystem ab. Auf dem PC wird dafür der C malloc()-Aufruf verwendet, da es sich hier nur um unterschiedliche Threads im gleichen Prozess handelt. In einer Unix-Umgebung sind es unterschiedliche Prozesse, die alle auf das gleiche Shared-Memory-Segment zugreifen. Diese Prozesse sind auch die einzigen, die auf die eigentlichen Datenbankdateien, also Tablespace-Dateien, Controlfiles, Redo Logs etc. lesend und schreibend zugreifen. Der Zugriff auf die Datenbank durch den Benutzer erfolgt dagegen über ein Client-Programm wie beispielsweise SQL*Plus. Beim Login wird Oracle für den Benutzer einen neuen Client-Prozess starten, über den dann die weitere Kommunikation erfolgt. Je nach Konfiguration und Umgebung wird der Client-Prozess über unterschiedliche (Netzwerk-)Adapter mit der Datenbank kommunizieren. Bei lokalem Zugriff, bei dem Client und Datenbank auf demselben Rechner sind, kann dies beispielsweise über IPC oder den Bequeath Adapter erfolgen. Sind Client und Datenbank auf unterschiedlichen Rechnern, erfolgt die Kommunikation heutzutage meist über TCP/IP. Dabei arbeitet Oracle nicht direkt mit TCP/IP, sondern mit SQL*Net. Vereinfacht gesagt, übersetzt SQL*Net SQL in das jeweilige Netzwerkprotokoll und zurück. Dafür wird auch ein eigener Prozess verwendet: der SQL*Net Listener. Der Client meldet sich hier über SQL*Net zuerst beim Listener an. Der Listener startet für den Client den Client-Prozess, über den dann die weitere Kommunikation zwischen Client und Datenbank erfolgt. Erfolgt die Verbindung im Shared-Server-Modus, teilen sich mehrere Clients die gleichen Kommunikationsprozesse.

SQL*Net wird über verschiedene Konfigurationsdateien konfiguriert:

- in der Datei listener.ora verwalten Sie den SQL*Net Listener. die Datei sqlnet.ora enthält verschiedene allgemeine SQL*Net-Einstellungen, darunter auch viele sicherheitsrelevante.

- die Datei tnsnames.ora enthält schließlich die SQL*Net-Aliase. Ein SQL*Net-Alias ist einfach ein Name, wie zum Beispiel MEINE_DATENBANK. Für jedes SQL*Net- Alias wird der physikalische Zugriffspfad definiert, also beispielsweise auf welchem Rechner die Datenbank liegt, wie die Datenbank heißt, welches Protokoll für den Zugriff verwendet wird etc.

Es gibt noch andere Konfigurationsdateien und -möglichkeiten für SQL*Net, dies ist aber das gebräuchlichste Setup.

Wenn Sie Oracle standardmäßig aufgesetzt haben, arbeiten Sie erst mal ohne Verschlüsselung der Daten. Das bedeutet konkret, dass die Daten von und zur Datenbank im Klartext übertragen werden. Wenn Sie also in Ihrer SQL*Plus-Session die Anweisung SELECT * FROM EMP absetzen, werden sowohl diese Anweisung als auch die resultierenden Daten unverschlüsselt übertragen. Jedermann mit Zugriff auf den Datenverkehr kann sie dann ohne große Anstrengung lesen.

Die unverschlüsselte Datenübertragung muss aber nicht zwangsläufig ein Problem sein. Solange es sich nicht um sensitive Daten handelt, reichen die Voreinstellungen der Oracle- Datenbank im Regelfall aus.

Wenn Sie aber mit sensitiven Daten arbeiten, müssen Sie sich schützen. Dafür gibt es bei Oracle zwei Verfahren:

Verschlüsselung: Um zu verhindern, dass jeder, der Zugriff auf den Datenverkehr hat, die Daten mit nur wenig Anstrengung lesen kann, müssen Sie die Daten verschlüsseln. Sind die Daten verschlüsselt, sieht der Angreifer nur noch unverständliche Zeichenfolgen statt Daten im Klartext.

Prüfsummen: Um zu verhindern, dass die Daten während des Transfers über das Netzwerk durch einen Angreifer verfälscht werden, müssen Sie spezielle Prüfsummen verwenden. Diese Prüfsummen garantieren dann, dass die abgeschickten Daten mit denen übereinstimmen, die der Empfänger am anderen Ende erhält – und umgekehrt. Erfolgt der Zugriff über (SQL*Net) TCP/IP, ist auch eine physikalische Zugriffskontrolle auf IP-Adressebene möglich.

3.1 Schutzmaßnahmen für den SQL*Net Listener

Erst durch den SQL*Net Listener wird der Zugriff auf die Datenbank über das Netzwerk möglich. Der beste Schutz ist also offensichtlich, überhaupt keinen Listener zu verwenden. Dann ist die Datenbank nur lokal erreichbar, aber das kann ja durchaus ausreichend sein. Der Großteil aller Oracle-Datenbanken ist und muss aber über das Netzwerk erreichbar sein. Grund genug also, den Listener möglichst gut zu schützen.