IT Systeme werden fast ausschliesslich in einem Netzwerk betrieben. Datenbankanwendungen greifen über dieses Netzwerk auf die Datenbank zu. Für potentielle Angreifer ist der Netzwerkverkehr ein interessanter und mit einfachsten Mitteln zu attackierender Bereich eines IT Systems. Konsequenterweise gilt es, diesen Bereich unbedingt zu schützen.

Dieser Schutz ist mit der Freigabe der Oracle Datenbank 12c Release 1 Ende Juni 2013 deutlich erleichtert worden. Denn sowohl die native Verschlüsselung über SQL*Net als auch die Verschlüsselung über SSL sind ab sofort nicht mehr als Teil der Advanced Security Option zu lizenzieren, sondern stehen - ebenso wie die starken Authentifizierungsmethoden - als Feature der Datenbank sowohl in der Enterprise Edition als auch in der Standard Edition der Datenbank ohne zusätzliche Kosten zur Verfügung. Das gilt übrigens auch für vorangegangene Releases (zum Beispiel für Oracle Database 11g), sofern diese das technisch unterstützen.

Da die Netzwerkverschlüsselung über SQL*Net innerhalb von Minuten aktiviert werden kann, wird in diesem Artikel diese Form der Verschlüsselung näher dargestellt. Vorweg sollen einige Erläuterungen die Entwicklung der verschlüsselten Übertragung im Kontext der Oracle Datenbank erläutern.

Bei der Verschlüsselung ist zunächst folgende Unterscheidung zu treffen

• Übertragung von Daten zum Aufbau einer Benutzersitzung (Authentifizierung). Hierbei interessiert vor allem die Frage, inwieweit die übertragene Information von Benutzernamen und Passwort für andere sichtbar ist.
• Übertragung von Daten einer bestehenden Benutzersitzung. Hier interessieren sowohl die vom Benutzer zur Datenabfrage oder Datenmanipulation eingegebenen SQL Befehle als auch die Daten, die zum Beispiel als Ergebnismenge einer Abfrage von der Datenbank an den Benutzer geschickt werden.

Alle Datenbank- und Clientversionen vor 7.1 kennen die automatische Verschlüsselung des Logins nicht. Beginnend mit der Datenbankversion 7.1 und seit der Version 2.1 von SQL*Net werden die Authentifizierungsinformationen grundsätzlich verschlüsselt übertragen. Der verwendete Schlüssel wird dabei für jede Benutzersitzung / Session immer wieder neu erstellt.

Das bedeutet praktisch, dass für alle derzeit unter Support stehenden Datenbank- und Oracle Client-Versionen das Login grundsätzlich verschlüsselt erfolgt und keiner weiteren Betrachtung bedarf.

Man ist geneigt, diesen Abschnitt mit einer Überschrift wie zum Beispiel "Netzwerkübertragungen von Nutzerdaten" zu versehen. Das wäre aber eine zu einschränkende Sicht auf das Thema. Nachdem der Benutzer eine Benutzersitzung aufgebaut hat, findet bei den folgenden Übertragungen keine Verschlüsselung mehr statt, es sei denn, man hat entweder seine Zugriffe auf die Datenbank über SQL*Net entsprechend konfiguriert oder man hat sein gesamtes Netzwerk verschlüsselt. Man hat hier die Wahl, aber irgendeine Form der Verschlüsselung sollte auf jeden Fall genutzt werden.

Folgendes Beispiel soll das verdeutlichen. Der Benutzer SCOTT baut eine Benutzersitzung auf und fragt die Tabelle EMP ab. Sowohl die Abfrage als auch das Ergebnis sind über das Netzwerk klar sichtbar. Um das nachzuvollziehen, könnte man jetzt einen Netzwerksniffer einsetzen, also ein Tool, das den Netzwerkverkehr mitliest und mittels Filter gezielt nach Datenübertragungen suchen kann. Da in vielen Firmen - zu Recht - schon die Installation eines solchen Sniffers streng verboten ist, sollen stattdessen die Mittel der Oracle Datenbanksoftware genutzt werden, um einen Einblick in den Netzwerkverkehr mit der Datenbank zu bekommen. Dazu muss nur in der Datei SQLNET.ORA ein Tracing mit geeigneten Optionen eingestellt werden, hier

trace_level_client = 16

Jede neue Datenbanksitzung wird ohne Neustart der Datenbank ab sofort eine Tracedatei erzeugen. In dieser Tracedatei kann man dann zum Beispiel folgende Einträge finden



Man sieht genau, welches SELECT-Statement vom Client an den Datenbankserver geschickt wird. Das sieht auf den ersten Blick nicht wirklich gefährlich aus. Dennoch enthalten Datenbankabfragen oft interessante Informationen für nicht autorisierte Personen. Nachdem die Abfrage von der Datenbank bearbeitet wurde, wird das Ergebnis an den Client geschickt



Ein Teil der Informationen zum Datensatz eines Mitarbeiters, und zwar von KING, ist klar lesbar. Wäre das Netzwerk verschlüsselt, sähen die Informationen aus der Trace Datei für die Abfrage und die Benutzerdaten etwa folgendermassen aus





Ein Angreifer kann also alle unverschlüsselt an den Client geschickten Daten abfangen und lesen. Das ist aber noch nicht alles: Wird das Passwort eines Datenbankbenutzers mit dem Befehl ALTER USER geändert und die Anwendung benutzt dabei eine Netzwerkverbindung, so wird auch das neue Passwort unverschlüsselt übertragen. In SQL*Plus ist deshalb schon seit einigen Jahren der Befehl PASSWORD eingeführt worden, der eine verschlüsselte Übertragung der Passwortänderung ermöglicht.

Aber nicht nur das Mitlesen von Datenpaketen ist problematisch. Ein Angreifer kann diese Datenpakete auch verändern und so in Transaktionen eingreifen.

Man kann anhand dieser einfachen Beispiele, die man in jeder Oracle Datenbankinstallation nachvollziehen kann, sehen, dass die Absicherung des Netzwerkverkehrs ein elementarer Baustein jeder Sicherheitsstrategie sein muss. Das gilt umso mehr, da viele Angriffe auf IT Systeme innerhalb der von Firewalls geschützten Bereiche durch sogenannte Innentäter erfolgen. Eine Verschlüsselung des gesamten Netzwerkverkehrs wäre für die meisten Unternehmen allerdings nicht zwingend notwendig und wohl auch zu teuer. Deshalb bietet Oracle die Verschlüsselung und Sicherung der Netzwerkkommunikation zwischen Oracle Datenbanken und Oracle Clients an. Dabei ist der Begriff "Oracle Client" weit zu fassen: Aus der Sicht einer Datenbank ist ein Application Server oder eine andere Datenbank, die über einen Datenbank Link zugreift, ebenfalls ein Oracle Client.

Über Einträge in der Datei SQLNET.ORA können unterschiedliche Verschlüsselungsalgorithmen festgelegt werden. Zur Zeit stehen 12 Verschlüsselungsalgorithmen zur Verfügung.

Zwei Aspekte werden konfiguriert

• Soll überhaupt verschlüsselt werden?
• Welcher Algorithmus soll verwendet werden?

Ob verschlüsselt wird, legen die Parameter SQLNET.ENCRYPTION_CLIENT beziehungsweise SQLNET.ENCRYPTION_SERVER fest. Dabei hat man die Wahl zwischen vier Einstellungen

• REJECTED
  Verschlüsselung wird grundsätzlich abgelehnt
• ACCEPTED (Default)
  Verschlüsselung wird akzeptiert, wenn der Kommunikationspartner das möchte
• REQUESTED
  Verschlüsselung wird gewünscht, aber nicht verlangt
• REQUIRED
  Verschlüsselung wird verlangt

Entsprechend der Einstellungen auf beiden Seiten ergibt sich nun, ob verschlüsselt wird oder nicht, beziehungsweise ob überhaupt eine Datenbankverbindung zustandekommt. Per Default gilt für beide Seiten der Wert ACCEPTED. Das hat zur Folge, dass beide Seiten für eine Verschlüsselung zur Verfügung stehen, sie diese aber nicht ausdrücklich wünschen - es findet also als Default keine Verschlüsselung statt. Die folgende Abbildung zeigt die möglichen Kombinationen und ihre Auswirkungen auf die Verschlüsselung beziehungsweise den Verbindungsaufbau zwischen den Kommunikationspartnern.



Als nächstes muß noch der Verschlüsselungsalgorithmus gewählt werden. Je nach Version der Datenbank beziehungsweise des Oracle Client stehen verschiedene Algorithmen zur Verfügung. Für ältere Datenbankversionen sind die verfügbaren Algorithmen zur Zeit noch im Handbuch "Advanced Security Administrators Guide" beschrieben. Für Oracle Database 12c erläutert das Handbuch Oracle Database Security Guide die Algorithmen. Die Datei SQLNET.ORA auf der Datenbankseite könnte schliesslich etwa folgende Einträge enthalten

sqlnet.encryption_server       = required
sqlnet.encryption_types_server = AES256
sqlnet.encryption_client       = required
sqlnet.encryption_types_client = AES256

Auch die CLIENT Parameter wurden angegeben, da eine Datenbank - wie oben bereits erwähnt - auch als Client agieren kann. Die gleiche Datei kann auch auf der Client Seite verwendet werden, vorausgesetzt der Client unterstützt die angegebenen Algorithmen. Die Tatsache, dass auch datenbankseitige Parameter spezifiziert sind, stört dabei nicht.

Die Verschlüsselung allein reicht nicht aus, um den Netzwerkverkehr abzusichern. Auch verschlüsselte Datenpakete können abgehört, umgeleitet und in veränderter Form wieder eingespielt werden. Um sich dagegen zu schützen, sollten Prüfsummenverfahren genutzt werden. Zur Verfügung stehen zur Zeit 5 Algorithmen, deren Verwendung ebenfalls über zwei Parameter in der Datei SQLNET.ORA konfiguriert wird. Auch hier werden wieder der Einsatzmodus und der Algorithmus festgelegt

sqlnet.crypto_checksum_server        = required
sqlnet.crypto_checksum _types_server = SHA1
sqlnet.crypto_checksum_client        = required
sqlnet.crypto_checksum _types_client = SHA512