“Erstellen eines Oracle – Sicherheitsplans“

Diplomarbeit
Thema:
“Erstellen eines Oracle –
Sicherheitsplans“
Christian Krämer
geboren am 23.12.1977
Matr.-Nr.: 7050968
An der Fachhochschule Dortmund im Fachbereich Informatik erstellte
Diplomarbeit
im Studiengang Wirtschaftsinformatik
zur Erlangung des Grades Diplom – Informatiker (FH) von
Erstprüferin: Prof. Dr. Heide Faeskorn - Woyke
Zweitprüferin: Prof. Dr. Birgit Bertelsmeier
Fachbereich Informatik
Dortmund, 05.10.2008
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
Inhaltsverzeichnis
Inhaltsverzeichnis ......................................................................... 2
Abbildungsverzeichnis ................................................................... 5
Tabellenverzeichnis ....................................................................... 6
1.
Einleitung ................................................................................ 7
1.1. Motivation und Hintergrund............................................................................. 8
1.2. Zielsetzung und Aufgabenstellung.................................................................... 8
1.3. Vorgehensweise und Gliederung ...................................................................... 9
2.
Datenbanksysteme................................................................ 10
2.1. Entstehung der Datenbanksysteme .................................................................10
2.1.1.
Das relationale Datenbanksystem MySQL ....................................................12
2.1.2.
Das relationale Datenbanksystem Oracle .....................................................13
3.
Sicherheit und deren Gegner................................................. 15
3.1. Bedrohungen ...............................................................................................15
3.1.1.
Interne Angriffe........................................................................................18
3.1.2.
Externe Angriffe .......................................................................................18
3.2. Sicherheit lt. BSI ..........................................................................................18
4.
Umsetzung von Sicherheit in Datenbanksystemen ................ 20
4.1. Acht Gebote der Datensicherheit ....................................................................20
4.2. Der Sicherheitskompromiss............................................................................21
4.3. Mitarbeiter sensibilisieren ..............................................................................22
5.
Erarbeitung eines Sicherheitsplans ....................................... 24
5.1. Verantwortlichkeiten zuweisen .......................................................................24
5.2. Die Systemlandschaft....................................................................................27
5.2.1.
Das Betriebssystem IBM – AIX ...................................................................27
5.2.2.
Errichtung einer DMZ ................................................................................28
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 2 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
5.3. Absicherung des Betriebssystems IBM – AIX ....................................................29
5.3.1.
Dateisicherheit .........................................................................................29
5.3.2.
Das administrative Konto Root ...................................................................30
5.3.3.
UNIX – Benutzer und deren Passwörter .......................................................32
5.3.4.
Auditing ..................................................................................................32
5.3.5.
Sonstige Sicherheitsaspekte.......................................................................33
5.4. Der Anfang zur Sicherung des Oracle – Datenbanksystems ................................34
5.4.1.
Oracle – Gruppen und Benutzer unter UNIX .................................................34
5.4.2.
Zusätzliche Oracle – Features.....................................................................35
5.4.3.
Standardbenutzer und deren Passwörter .....................................................38
5.5. Innere Absicherung des Oracle – Datenbanksystems.........................................40
5.5.1.
Benutzer – Authentifizierung ......................................................................41
5.5.2.
Benutzerberechtigungen ............................................................................42
5.5.3.
Rollen .....................................................................................................45
5.5.4.
Datenbankautorisierung durch das DEFAULT – Profil .....................................49
5.5.5.
Benutzerpasswörter ..................................................................................53
5.5.6.
Views ......................................................................................................55
5.5.7.
Die Datenbankbenutzer SYS und SYSTEM ....................................................56
5.6. Sicherung mittels zusätzlicher Komponenten....................................................59
5.6.1.
Oracle Virtual Private Database (VPD) .........................................................59
5.6.2.
Oracle Label Security ................................................................................61
5.6.3.
Oracle Data Vault .....................................................................................62
5.6.4.
Auditing ..................................................................................................64
5.7. Erweiterte Sicherheitsmaßnahmen ..................................................................66
5.7.1.
Netzwerksicherheit ...................................................................................67
5.7.2.
Datenbankbackup .....................................................................................69
5.7.3.
Abschließende Sicherungsmöglichkeiten ......................................................71
6.
Oracle 11g vs. MySQL 5.0.67 ................................................. 74
6.1. Neuerungen in Oracle 11g .............................................................................74
6.1.1.
Der Umgang mit Kennwörtern ....................................................................74
6.1.2.
Verbessertes Auditing ...............................................................................76
6.1.3.
Verschlüsselung des Tablespace .................................................................76
6.1.4.
Verschlüsselung von Betriebssystemdateien.................................................76
6.2. Sicherheitsmöglichkeiten in MySQL 5.0.67 .......................................................77
6.2.1.
Absicherung mit dem Shellskript mysql_secure_installation ...........................77
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 3 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
6.2.2.
Optionen zum Starten des MySQL – Server mysqld.......................................78
6.2.3.
Sichere Anlage von Datenbankbenutzern .....................................................80
6.2.4.
Anpassungen der Datei my.cnf ...................................................................81
6.2.5.
Eine abgesicherte Verbindung zur Datenbank ...............................................81
6.3. Fazit ...........................................................................................................81
7.
Penetrationstest.................................................................... 84
7.1. Port – Scan ..................................................................................................84
7.2. Angriff über Checkpwd ..................................................................................87
7.3. Untersuchung der ermittelten Datenbankbenutzer ............................................88
7.4. Die DBA – Rolle ............................................................................................91
7.5. Angriff über Oracle XML – DB .........................................................................92
7.6. Fazit ...........................................................................................................95
7.6.1.
8.
Möglichkeiten zur Absicherung ...................................................................96
Checkliste zum Inhalt eines Sicherheitsplans........................ 97
8.1. Die Systemlandschaft planen .........................................................................97
8.2. Sicherung des Betriebssystems ......................................................................97
8.3. Das Datenbanksystem absichern ....................................................................98
8.4. Backups durchführen ....................................................................................99
9.
Fazit .................................................................................... 100
10. Danksagung ........................................................................ 102
Literaturverzeichnis................................................................... 103
Abkürzungsverzeichnis .............................................................. 104
Eidesstattliche Erklärung ........................................................... 106
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 4 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
Abbildungsverzeichnis
Abbildung 3-1: Bedrohungen auf ein IT – System und dessen Komponenten (Quelle:
selbst erstellt) ..........................................................................................16
Abbildung 5-1: Multiuser – System (Quelle: selbst erstellt)..................................29
Abbildung 7-1: Port – Scan Ausgabe der Software NMap (Quelle: selbst erstellt) ....85
Abbildung 7-2: Port – Scan Ausgabe inkl. Zusatzinformationen der Software NMap
(Quelle: selbst erstellt) ..............................................................................86
Abbildung 7-3: Angriffsversuch mit Checkpwd (Quelle: selbst erstellt) ..................87
Abbildung 7-4: Inhalt der View v$pwfile_users (Quelle: selbst erstellt)..................89
Abbildung 7-5: Unkenntlich gemachte Studentendaten (Quelle: selbst erstellt) ......90
Abbildung 7-6: Unkenntlich gemachte Daten von Dozenten (Quelle: selbst erstellt) 90
Abbildung 7-7: Datenbankbenutzer mit der Rolle DBA (Quelle: selbst erstellt) .......91
Abbildung 7-8: Verbindungsversuch über Oracle XML – DB (Quelle: selbst erstellt).93
Abbildung 7-9: Auslesen der Datenbankbenutzer über Oracle XML – DB (Quelle:
selbst erstellt) ..........................................................................................94
Abbildung 7-10: Kennwort des Datenbankbenutzers SYS (Quelle: selbst erstellt) ...95
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 5 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
Tabellenverzeichnis
Tabelle 2-1: Bekannte DBS-Typen (Quelle: [Kersken 2003] Seite 131 ff.) .............12
Tabelle 3-1: 2006 getätigte Angriffsformen (Quelle: [kes 2007]) ..........................17
Tabelle 3-2 Schutzziele für Sicherheit im IT – System (Quelle:
http://www.bsi.bund.de, 15.03.2008) .........................................................19
Tabelle 4-1 Acht Gebote der Datensicherheit (Quelle: [Faeskorn-Woyke et al. 2007]
Seite 56 f.) ..............................................................................................21
Tabelle 5-1 Sicherheitsmitarbeiter (Quelle: Vgl. [Newman et al. 2004] Seite 86) ....26
Tabelle 5-2 Zusätzliche Oracle – Softwarekomponenten (Quelle: selbst erstellt) .....38
Tabelle 5-3 Standardbenutzer und deren Passwörter (Quelle:
http://www.petefinnigan.com/default/oracle_default_passwords.htm,
21.07.2008) .............................................................................................40
Tabelle 5-4 Typische Objekt- und Systemberechtigungen (Quelle: [Bryla et al. 2007]
Seite 324 ff.)............................................................................................45
Tabelle 5-5 Bekannte von Oracle vordefinierte Rollen (Quelle: [Bryla et al. 2007]
Seite 332 ff.)............................................................................................48
Tabelle 5-6 Ein Ausschnitt der View dba_profiles (Quelle: [Bryla et al. 2007] Seite
316)........................................................................................................50
Tabelle 5-7 Wichtige Profil – Ressourcenparameter (Quelle: Vgl. [Bryla et al. 2007]
Seite 317 ff.)............................................................................................52
Tabelle 5-8 Wichtige DATA DICTIONARY – Views (Quellen: [Bryla et al. 2007] und
[Newman et al. 2004]) ..............................................................................58
Tabelle 5-9 Parameter der Prozedur ADD_POLICY (Quelle: [Bryla et al. 2007] Seite
345 f.).....................................................................................................61
Tabelle 5-10 Parameter AUDIT_TRAIL der Datei init.ora (Quelle: [Bryla et al. 2007]
Seite 358 f.).............................................................................................65
Tabelle 6-1 Parameter zum sicheren Starten des MySQL – Servers (Quelle: MySQL
Online-Referenzhandbuch - http://dev.mysql.com/doc/refman/5.1/de/privilegesoptions.html, 08.09.2008) .........................................................................79
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 6 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
1.
Einleitung
Bereits der berühmte amerikanische Psychologe Prof. Abraham Harald Maslow1 hat
im Jahre 1943 das Thema Sicherheit in seiner Bedürfnispyramide als eines der
wichtigsten menschlichen Bedürfnisse benannt. Daran ist zu erkennen, wie wichtig
Sicherheit für den Menschen ist. Hierbei spielt es kaum eine Rolle in welchem
Zusammenhang dieses Thema verwendet wird.
Während damals an Sicherheit in der Informationstechnologie noch nicht zu denken
war, ist das Thema IT – Sicherheit2 nun in aller Munde. Gerade wenn es um
Informationen geht, die nur uns betreffen, ist Sicherheit ein heikles Thema. Ob es
die privaten Fotos, E-Mails oder aber die privaten Dokumente sind, Sicherheit ist
gewünscht und sollte größtmögliche Priorität haben um Daten jeglicher Art zu
schützen3.
Zu anfänglichen Zeiten der IT verstand man unter IT – Sicherheit lediglich die
Sicherstellung der korrekten Funktionsweise von Hard- und Software. Mittlerweile
geht es längst nicht nur um korrekte Funktionsweisen. Unmengen von Software und
Hardware existieren auf dem Markt. Das Internet, daraus resultierende Bedrohungen
und die weltweite Möglichkeit auf Informationen der genannten Komponenten
zuzugreifen, ließen Sicherheitslücken darin erkennen und machen ein System bzw.
deren Komponenten angreifbar. Viele, erst im Laufe der Jahre aufgetauchten
Bedrohungen (siehe Abschnitt 3-1) eines IT – Systems4, machen es notwendig,
präventive Maßnahmen zu ergreifen um ein System und dessen Komponenten zu
schützen.
Eine Komponente, die vielen Bedrohungen ausgesetzt ist, ist ein Datenbanksystem.
Nicht zuletzt aufgrund der Globalisierung und der rasenden Verbreitung und damit
auch Kommerzialisierung des Internets, benötigt fast jedes größere Unternehmen
bzw. jede größere Organisation zur Verwaltung der riesigen Datenmengen ein DBS5.
Ob private Kundeninformationen oder aber Informationen über Studenten und deren
Benotungen. Ein DBS sollte einen größtmöglichen Schutz genießen.
Um ein DBS richtig zu schützen ist es wichtig die Schwachstellen, die darauf
wirkenden Bedrohungen, die umgebende IT – Systemlandschaft und die von der
Hard- bzw. Software bereitgestellten Sicherheitstools zu kennen. All diese
Informationen können in einen Sicherheitsplan fließen, mit dem man ein
Datenbanksystem besser schützen kann.
1
2
3
4
5
Er lebte vom 01.04.1908 bis 08.06.1970 in Brooklyn, New York.
Unter IT – Sicherheit versteht man den Zustand eines IT – Systems, in dem die Risiken, die bei jedem
IT – Einsatz bestehen auf ein tragbares Maß reduziert werden.
Diesbezüglich sei zu erwähnen, dass es aktuell Politiker gibt, die diese Ansicht wohl nicht voll und
ganz teilen.
Ein System zur Beschaffung, Verarbeitung, Speicherung, Übertragung und Bereitstellung von
Informationen bzw. Daten (Wichtige Komponenten: Hardware, Software, Menschen, Datenbanken).
Vgl. [Siebdrat 2007]
DBS ist eine geläufige Abkürzung für Datenbanksystem.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 7 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
1.1.
Motivation und Hintergrund
Da die Bedeutung des Themas IT – Sicherheit in den letzten Jahren immer mehr
zugenommen hat, ist es ein grundlegendes Bedürfnis, Komponenten (in diesem Falle
ein Datenbanksystem) eines IT – Systems zu schützen.
Zur Durchsetzung von Sicherheitsmaßnahmen und –anforderungen ist es hilfreich
einen Sicherheitsplan einzuführen. In diesem Plan sollten alle möglichen
Schwachstellen, Bedrohungen, Hintergrundinformationen und natürlich auch
Gegenmaßnahmen verankert und erläutert sein. Somit wird es den auszuführenden
Personen erleichtert, die Maßnahmen zur Sicherung des Datenbanksystems
umzusetzen.
Die Fachhochschule Köln (Campus Gummersbach) setzt in ihrer aktuellen
Systemlandschaft ein Oracle- und ein MySQL – Datenbanksystem ein. Das Oraclesowie das MySQL – Datenbanksystem werden von der Verwaltung der
Fachhochschule z.B. für die Erfassung von Stundenplänen und Daten von Studenten
bzw. Lehrkräften eingesetzt. Von den Studenten und Lehrkräften werden die
Systeme ebenfalls zu Vorlesungs- und Übungszwecken benutzt.
Im Hinblick auf Oracle und MySQL bekommen Studenten einen Überblick darüber,
wie man die Datenbanksysteme auf verschiedenen Betriebssystemen richtig
installiert, konfiguriert und einsetzt. Die Datenbankverwaltung und der damit
verbundene Überblick über server- und clientseitige Programme, wie z.B. der Einsatz
des MySQL – Server und des MySQL – Clients werden ebenso betrachtet. Im Hinblick
auf Absicherung bekommen Studenten einen Überblick über allgemeine
Sicherheitsaspekte,
Benutzerkontenverwaltung
sowie
Datensicherung
und
Wiederherstellung.
In Bezug auf SQL wird den Studenten Wissen über Datentypen, Funktionen,
Operatoren
und
Systemvariablen
sowie
die
richtige
Anwendung
der
Datendefinitionssprache (Data Definition Language), der Datenmanipulationssprache
(Data Manipulation Language), der Datenabfragesprache (Data Query Language) und
der Datenadministrationssprache (Data Administration Language) vermittelt.
1.2.
Zielsetzung und Aufgabenstellung
Diese Diplomarbeit soll einerseits dazu dienen, einen Sicherheitsplan für ein Oracle –
Datenbanksystem zu erstellen. Zu diesem Sicherheitsplan werden Umwelteinflüsse,
wie der Begriff der Sicherheit oder aber Angriffe auf ein IT- und Datenbanksystem
ebenso kritisch begutachtet wie die Möglichkeiten, die Oracle bietet, um Sicherheit
innerhalb eines Datenbanksystems umzusetzen. Dieser Sicherheitsplan wird so
ausgelegt sein, dass der Schutz sicherungsbedürftiger Daten höchste Priorität hat.
Die Erkenntnisse zur Erarbeitung dieses Sicherheitsplans werden dazu genutzt eine
Datenbankinstallation am Campus Gummersbach auf Sicherheitslücken und
Schwachstellen in der Konfiguration hin zu untersuchen. Hierbei wird die Datenbank
oras1.gm.fh-koeln.de6 mit typischen Bedrohungen konfrontiert. Da die Datenbank
auch von Studenten während der vorlesungsfreien Zeit über das Internet genutzt
werden kann, werden hauptsächlich Angriffe von außen, mittels eines
6
Dies ist eine Installation die hauptsächlich zu Übungszwecken für Studenten dient.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 8 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 1: Einleitung
Penetrationstests7, simuliert.
Neben der Erstellung des Konzepts sowie dem Sicherheitstest der Datenbank wird es
weiterhin eine Unterscheidung der beiden Datenbanksysteme Oracle und MySQL im
Hinblick auf Sicherheit geben. Hierzu werden die Sicherheitstools der aktuellen
produktiven Systeme Oracle 11g und MySQL in der Version 5.0.678 miteinander
verglichen, kritisch begutachtet und objektiv bewertet.
1.3.
Vorgehensweise und Gliederung
Zu Beginn werden in dieser Diplomarbeit grundlegende Begriffe der Thematik
Datenbanksysteme und Sicherheit erläutert. Innerhalb der Datenbanksysteme
werden die für diese Arbeit relevanten Systeme Oracle und MySQL betrachtet.
Nach dieser Betrachtung wird der Sicherheitsaspekt aufgegriffen. Neben gesetzlichen
Richtlinien werden ebenfalls Angriffe beschrieben, die auf ein IT – System und ein
DBS einwirken können. Weiterhin wird auf den wichtigen Punkt der Umsetzbarkeit
von Sicherheit in einem DBS eingegangen. Hierin geht es um die Notwendigkeit eines
Sicherheitskompromisses, um die korrekte Zuweisung von Verantwortlichkeiten und
um die Sensibilisierung von Mitarbeitern im Umgang von Sicherheit in
Datenbanksystemen
In Abschnitt 5 wird die Sicherung eines Oracle – Datenbanksystems beschrieben. Da
nicht nur das DBS selbst, sondern auch die umgebende Systemlandschaft gesichert
werden muss, wird neben der Absicherung des DBS auch die Sicherung des
umgebenen Betriebssystems beschrieben.
Die derzeitigen Sicherheitsmöglichkeiten und –tools der Datenbanksysteme Oracle
und MySQL werden in den aktuellen produktiven Versionen 11g in einem separaten
Abschnitt gegeneinander gestellt. Die Möglichkeiten der beiden Systeme werden
betrachtet, zweckgebunden untersucht und objektiv bewertet.
Anhand der genannten Absicherungsmöglichkeiten wird das, an der Fachhochschule
Köln (Campus Gummersbach) eingesetzte Oracle – Datenbanksystem, unter der
Adresse oras1.gm.fh-koeln.de, auf typische Schwachstellen untersucht.
Als letzten Schritt, zur Sicherung einer Oracle – Datenbank, wird eine Checkliste
erstellt. Diese Liste soll dazu dienen Schritte zur Sicherung eines Datenbanksystems
nachzuvollziehen und ein evtl. bereits umgesetztes Sicherheitskonzept auf
Schwachstellen zu überprüfen.
7
8
Ein Penetrationstest ist in der Informatik eine Methode, um Sicherheitsschwachstellen festzustellen.
Versionsstand vom 10.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 9 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 2: Datenbanksysteme
2.
Datenbanksysteme
Die Wichtigkeit von Sicherheit in Datenbanksystemen hat erst die letzten Jahre
enorm zugenommen. Während man DBS zu Beginn hauptsächlich in großen
Unternehmen auf Großrechnern einsetzte9, findet man heute, innerhalb des
Internets, hinter sehr vielen, vor allem kommerziellen Homepages Datenbanken. Ob
man bei Amazon10 Bücher bestellt, bei seiner Bank eine Online – Überweisung tätigt,
bei Ebay11 an einer Auktion teilnimmt, sich bei einer Versicherung ein Online –
Angebot ausrechnen lässt oder ob man einen SQL – Test auf der Website einer
Professorin der Fachhochschule Köln ausführt. Hinter all den genannten Beispielen
stecken Datenbanksysteme mit Millionen von Daten. Unternehmen wie die BMW AG12
oder Oracle selbst, verwenden zur Verwaltung ihrer großen Datenmenge tausende
von Datenbanken. Viele der enthaltenen Daten sind nicht unbedingt schutzbedürftig.
Andere jedoch, wie die Daten der eigenen Kreditkarte, des Bankkontos oder aber der
eigenen Adresse, haben einen besonderen Schutzbedarf.
Datenbanksysteme haben nicht mehr nur die Aufgabe die enthaltenen Daten zu
speichern und anderen zugänglich zu machen. Nein, sie haben auch die Aufgabe, die
enthaltenen Daten zu schützen. Die vermehrt kommerzielle Ausrichtung des
Internets, die große Menge an Daten, die täglich über die Datenleitungen fließt und
die unüberschaubare Anzahl an Nutzern des Internets haben die Anforderungen an
Sicherheit von Datenbanksystemen grundlegend verändert. Datenbanksysteme
müssen daher ein gewisses Maß an Vertraulichkeit, Integrität und Verfügbarkeit
bieten (vgl. Abschnitt 3-2).
Die folgenden Abschnitte sollen daher einen grundlegenden Überblick über die
Datenbanksysteme, vor allem Oracle und MySQL bieten.
2.1.
Entstehung der Datenbanksysteme
Vorreiter der Datenbanken waren Dateien. So genannte Flatfiles13 sorgten für die
Speicherung der Daten. Diese Flatfiles hatten jedoch den Nachteil, dass die darin
enthaltenen Daten nur von dem Programm gelesen werden konnte, von dem das
Flatfile erzeugt wurde. Wollte nun ein anderes Programm auf die Daten zugreifen, so
war, aufgrund der fehlenden Integrität (siehe Abschnitt 3-2), meist ein schwieriges
Im- und Export – Verfahren über eine zuvor definierte Schnittstelle notwendig um die
Daten verwenden zu können. Ein weiterer, damit verbundener Nachteil war die
Redundanz14 der Daten. Die gleichen Daten standen mehrmals zur Verfügung, was
auf Dauer einen gewaltigen Speicherbedarf darstellte. Weiterhin konnte es dadurch
vorkommen, dass die Daten einen inkonsistenten15 Zustand erhielten. Änderte ein
Programm innerhalb eines Flatfiles, z.B. die Adresse von Kundendaten, so bekam das
andere Programm die Änderung erst dann mitgeteilt, wenn das erwähnte Im- und
Export – Verfahren wieder durchgeführt wurde.
9
10
11
12
13
14
15
z.B. Das IBM – Betriebssystem OS390 mit dem Datenbanksystem DB2.
http://www.amazon.de 20.05.2008
http://www.ebay.de 20.05.2008
http://www.bmwgroup.com 10.09.2008
Als Flatfiles werden einfache Textdateien bezeichnet.
Redundanz bedeutet, dass Daten mit gleichem Informationsgehalt mehrfach vorkommen.
Inkonsistenz besagt, dass Datenzusammenhänge widersprüchlich sind.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 10 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 2: Datenbanksysteme
Aufgrund immer komplexer gewordenen Datenstrukturen, der Notwendigkeit
Datenbestände immer aktuell zu halten und der Bedarf von Unabhängigkeit zwischen
Daten und Programm sorgten schließlich Ende der 60er Jahre für die Entstehung der
Datenbank16.
Die genaue Definition von Datenbanksystemen spiegelt folgendes Zitat wider: „Ein
Datenbanksystem ist eine Ansammlung von Daten, die allen Benutzern bzw.
Anwendungen zur Verfügung steht und in der die Daten nach einheitlichen Regeln
abgespeichert werden. Ein Datenbanksystem besteht aus einer Datenbasis17 und
einem Datenbankmanagementsystem18 “19.
Über viele Jahre hinweg sind sehr viele verschiedene Typen von Datenbanksystemen
aufgetaucht. Nachfolgende Tabelle zeigt Typen, die am meisten in Erscheinung
getreten sind:
Typ
Erläuterung
RDBMS20
Relationale
(RelationaleDatenbankManagementSysteme)
Einzeltabellen
Datenbanken
miteinander
bieten
zu
die
Möglichkeit,
verknüpfen
(Relationen).
Informationen, die an verschiedenen Stellen benötigt werden,
müssen nur einmal aufgeführt werden. Es handelt sich hier
um die am meisten benutzten Datenbanksysteme (z.B.
MySQL und Oracle).
OODBS
(Objekt- OrientierteDatenbanksysteme)
Diese Datenbanken arbeiten auf der Grundlage von Klassen
und Objekten. Im Gegensatz zu relationalen Datenbanken
besteht bei ihnen die Möglichkeit nicht lineare Beziehungen
zwischen den Informationen abzubilden (z.B. O2 – DBS). Eine
Mischform zwischen RDBMS und OODBS sind ORDBS (Objekt
– Relationale Datenbanksysteme).
XMLDBS
Diese Datenbanken speichern die Informationen in Form von
XML – Dokumenten ab. Da der Austausch von Informationen
XMLDatenbanksysteme21
mit Hilfe von XML – Dokumenten die letzten Jahre sehr
zugenommen hat (einheitliche Schnittstellen), bieten diese
die
Möglichkeit,
die
erhaltenen
Informationen
direkt
abzuspeichern ohne das Dokument noch parsen zu müssen
(z.B. das Datenbanksystem Tamino).
16
17
18
19
20
21
Siehe [Faeskorn-Woyke et al. 2007] Seite 21 ff.
In der Datenbasis sind die Daten der Datenbank enthalten.
Das DBMS managt und kontrolliert das Datenbanksystem.
Siehe [Faeskorn-Woyke et al. 2007] Seite 21
Es wird auch der Begriff RDBS benutzt, jedoch hat der Begriff RDBMS im Internet die größte
Verbreitung, weshalb dieser Begriff in dieser Arbeit verwendet wird.
Oracle bietet ebenfalls eine Methode zur Speicherung von XML – Dateien.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 11 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 2: Datenbanksysteme
Hierarchische
Die Verknüpfung der Datenobjekte erfolgt hier über eine
Datenbanksysteme
Baumstruktur. Der Nachteil dieses DBS besteht darin, dass
sich
nur
1:1 oder
1:N
Beziehungen
darstellen lassen.
XMLDBS sind eine Art hierarchischer DBS. Sie werden heute
nur noch selten verwandt.
Netzwerk
Die
Datenobjekte
sind
über
Netzwerke
miteinander
Datenbanksysteme
verbunden. Es existiert keine hierarchische Struktur zwischen
den Datenobjekten. Rein theoretisch kann jedes Datenobjekt
miteinander verbunden sein. Dieses DBS wird heute ebenfalls
so gut wie nicht mehr verwendet.
Tabelle 2-1: Bekannte DBS-Typen (Quelle: [Kersken 2003] Seite 131 ff.)
2.1.1.
Das relationale Datenbanksystem MySQL
Obwohl Datenbanksysteme wie Oracle22 oder Microsoft SQL – Server (MS SQL)23
führend im Datenbankgeschäft sind24, versucht in den letzten Jahren MySQL des
Unternehmens MySQL AB mit in die Spitze vorzudringen. Da es sich mit MySQL um
ein Open – Source – Produkt handelt und Branchenbeobachter die Lizenzumsätze
eines Unternehmens als Kenngröße für den Markt von Datenbanksystemen nutzen,
kann nur anhand der großen Verbreitung, hauptsächlich im Internet, vermutet
werden, dass das Unternehmen schon viele Teile des Datenbankmarktes für sich
beansprucht.
Es handelt sich dabei um ein relationales DBS, das in der Programmiersprache C
sowie C++ programmiert wird und dadurch auf fast alle Betriebssysteme portiert
werden kann. 1995 wurde es durch das Unternehmen TcX mit dem
hauptverantwortlichen Entwickler Michael Widenius in der Version 1.0 als Open –
Source – Produkt veröffentlicht.
Der Gedankengang, die Entwicklung von MySQL auf der Open – Source – Basis
voranzutreiben, hat das Datenbanksystem in der weiteren Entwicklung sehr
vorangetrieben. Zwar wurden erst im Laufe der Zeit Versionen von MySQL
veröffentlicht, die es als richtiges relationales Datenbanksystem erkennen ließen25,
jedoch ist diese Weiterentwicklung erst durch die daraus erwachsene Popularität und
dem unermüdlichen Eifer der Open – Source – Programmierer zu verdanken.
So existiert z.B. erst seit der Version 4.1 die Unterstützung von Subselects oder
unterschiedlicher Zeichensätze, was für den Einsatz auf dem weltweiten Markt sehr
22
23
24
25
Lt. Oracle Corporation ist Oracle das derzeit führende Datenbanksystem.
http://www.oracle.com, 20.03.2008
MS SQL ist ein von Microsoft und Sybase in Kooperation entwickeltes relationales Datenbanksystem.
http://de.wikipedia.org/wiki/Microsoft_SQL_Server, 15.09.2008
Vgl. hierzu die Geschichte der Datenbanksysteme unter:
http://de.wikipedia.org/wiki/Datenbanksystem#Geschichte, 20.04.2008
Einen tieferen Einblick in die Regeln einer relationalen Datenbank kann man über das im AddisonWesley Verlag erschiene Buch von E.F. Codd erhalten: "The Relational Model for Database
Management"
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 12 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 2: Datenbanksysteme
wichtig ist. Mit Version 5.0 kamen weitere wesentliche Änderungen26, die es MySQL
ermöglichen werden, im Markt der kommerziellen Datenbanksysteme zu bestehen
und früher oder später, in großen Unternehmen Fuß zu fassen. Neben wichtigen
Neuerungen im Bezug auf Sicherheit sei die Einführung von Views27, Stored –
Procedures oder auch Trigger, genannt28.
MySQL existiert mittlerweile in der Version 629. Diese Version ist derzeit nur im Alpha
– Release verfügbar. In Abschnitt 6-2 werden daher nur die zur Verfügung stehenden
Sicherheitstools der produktiven Version 5.0.67 betrachtet.
2.1.2.
Das relationale Datenbanksystem Oracle
Der Beginn von Oracle fand 1977 statt. In diesem Jahr gründeten die drei
Unternehmer Larry Ellison30, Ed Oates und Bob Miner das Unternehmen Software
Development Laboratories. Im darauf folgenden Jahr kam die erste Version des
Oracle – Datenbanksystems auf den freien Markt. Noch in Assembler – Code
programmiert, wurde 1979 die erste Oracle – Version veröffentlicht, die SQL
unterstützt.
1982 wurde der Name des Unternehmens in Oracle Systems umbenannt. Ende der
80er Jahre wurde in der Version 6 die Programmiersprache PL/SQL vorgestellt. Mit
dieser eigens entwickelten Programmiersprache war es möglich Schnittstellen zu den
Daten, innerhalb einer Datenbank, bereitzustellen. Novum war, dass eine
Programmiersprache der vierten Generation (SQL) mit einer Programmiersprache der
dritten Generation gepaart wurde.
Neben PL/SQL unterstützt Oracle mittlerweile eine Datenbankintegration für Java und
.NET. Darüber hinaus ist es in Oracle möglich über definierte Schnittstellen andere
Programme in anderen Programmiersprachen anzusprechen. Somit können die, in
der Datenbank enthaltenen Daten, auch Programmen zugänglich gemacht werden,
die z.B. in der Sprache C programmiert sind31.
Mittlerweile existiert das Datenbanksystem in der Version 11g und ist ein sehr
ausgereiftes System. Neben neuen Sicherheitsaspekten, die u.a. in Abschnitt 6-1
genauer erläutert werden, sind schon längere Zeit Features integriert, die in MySQL
erst seit kurzem verfügbar sind (z.B. Trigger, Views und Stored – Procedures),
ebenso implementiert, wie viele Development- und Administrationstools. Weiterhin
hat Oracle, aufgrund der großen Verbreitung, den Vorteil, dass sich viele
Softwareunternehmen darauf spezialisiert haben, Software zu entwickeln, die den
Umgang mit dem Datenbanksystem erleichtert32.
Oracle ist alleiniger Anführer im Markt der relationalen Datenbanksysteme. Die BMW
AG hat knapp 2.200 Oracle – Datenbanken im Einsatz, die Siemens AG33 sogar ca.
8.000. Seit 2005 hat Oracle die Marktführerschaft des gesamten Datenbankmarktes
26
27
28
29
30
31
32
33
Vgl. [Rüttger 2006] Seite 44 ff.
Eine View ist eine Select – Abfrage auf eine oder mehrere Tabellen, die logisch als eine eigene Tabelle
abgelegt wird.
Vgl. [Rüttger 2006] Seite 44 ff.
http://dev.mysql.com/downloads/mysql/6.0.html, 15.09.2008
Er entdeckte in einem Journal die Idee der relationalen Datenbank und sie wussten, dass noch kein
Unternehmen ein solches DBS auf den Markt gebracht hatte.
http://www.oracle.com/profit/features/p27anniv_timeline.pdf, 22.05.2008
Dieses Dokument wurde von Oracle aufgrund des 30 jährigen Jubiläums 2007 veröffentlicht.
Ein bekanntes Development – Tool ist z.B. der SQL – Navigator des Unternehmens Quest Software.
http://www.siemens.de, 15.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 13 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 2: Datenbanksysteme
übernommen, obwohl diese Platzierung wohl nicht zuletzt der vielen Übernahmen
anderer Software – Hersteller zur verdanken ist34.
Im Gegensatz zu MySQL kann man sagen, dass Oracle dank der 30 jährigen
Erfahrung schon viele Kinderkrankheiten ausgemerzt und wichtige Zusatzfeatures
implementiert hat. Im Laufe der Zeit wurde das Datenbanksystem aber auch immer
mehr mit zusätzlichen Tools und Features aufgebläht, die bestimmt nicht alle für den
reibungslosen Betrieb eines relationalen Datenbanksystems notwendig sind (vgl.
Abschnitt 5-4-2). Jedoch ist MySQL, als Open – Source – Produkt, kostenlos nutzbar
und mit den richtigen Programmierkenntnissen selbständig erweiterbar, was jedoch
eine nachfolgende Veröffentlichung des selbst programmierten Quellcodes
voraussetzt.
34
Vgl. [Faeskorn-Woyke et al. 2007] Seite 48
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 14 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 3: Sicherheit und deren Gegner
3.
Sicherheit und deren Gegner
Bevor auf die Sicherheitsbegriffe und die Umsetzbarkeit von Sicherheit innerhalb
eines Datenbanksystems eingegangen wird, möchte ich zunächst auf die
wesentlichen Gründe für einen Sicherheitsplan und deren Begrifflichkeiten eingehen.
Der Gesetzgeber hat die letzten Jahre viele Gesetze erlassen, die die Anforderungen
an Sicherheit in Unternehmen und damit auch deren Datenbanksystemen erhöhen
sollen. Von daher ist für Unternehmen die Einhaltung von Sicherheitsvorkehrungen
primär von rechtlicher Natur. Hier haben Unternehmen die Sorgfaltspflicht, den
Datenschutz und das Fernmeldegeheimnis zu beachten35. Beim Umgang mit
personenbezogenen Daten geht, wenn mind. 10 Personen mit diesen Daten ständig
arbeiten, die Nennung eines Datenschutzbeauftragten36 hervor, welcher die
Einhaltung der Datenschutzrichtlinien innerhalb des Unternehmens überprüft und
diese durchsetzt. Bei gravierenden Missständen kann die Aufsichtsbehörde die
Datenverarbeitung untersagen.
Weiterhin sind die informationstechnischen Bedrohungen zu beachten, welche die
letzten Jahre immer mehr zunahmen und auch noch weiter zunehmen werden. Zu
diesen Bedrohungen zählen z.B. Angriffe, also vorsätzliche Ereignisse sowie zufällige
Ereignisse und unabsichtliche Fehler.
3.1.
Bedrohungen
Unternehmen dürfen ihre Datenverarbeitung nur mittels Einhaltung der eben
genannten Gesetze überhaupt durchführen. Für jede andere Institution bzw. jeden
anderen Anwender eines Datenbanksystems sind die direkten Bedrohungen auf ein
IT – System bzw. ein Datenbanksystem jedoch der Anlass, einen Sicherheitsplan
einzusetzen. Obwohl man natürlich erwähnen muss, dass die primären Gründe, also
die Gesetze, erst durch die informationstechnischen Bedrohungen entstanden sind.
Einen Überblick über mögliche Bedrohungen und damit die Ursache allen Übels gibt
nachfolgende Abbildung:
35
36
Die entsprechenden Vorschriften und Möglichkeiten zur Einhaltung dieser Pflichten findet man auf der
Homepage des Bundesamtes für Sicherheit in der Informationstechnik unter:
http://www.bsi.bund.de, 07.06.2008
Vgl. http://www.ihk-muenchen.de/internet/mike/ihk_geschaeftsfelder/recht/Datenschutz/
Datenschutzbeauftragter.html, 17.06.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 15 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 3: Sicherheit und deren Gegner
Abbildung 3-1: Bedrohungen auf ein IT – System und dessen Komponenten (Quelle: selbst erstellt)
Die hier gezeigten Bedrohungen lassen sich in die drei Gruppen Technik, Mensch und
Naturkatastrophen einordnen. Gegen Naturkatastrophen und die Technik kann als
hauptsätzliche Schutzmaßnahme, die Durchführung regelmäßiger Backups sowie die
Einspielung aktueller Patches37 genannt werden. Da Menschen auch durch
menschliches Versagen zur Bedrohung werden können, kann mit regelmäßigen
Schulungen versucht werden, zur richtigen Handhabung mit den ihnen anvertrauten
Daten, der Bedrohung entgegenzuwirken.
Problematisch wird es jedoch bei Menschen die vorsätzlich durch Angriffe, zur
Bedrohung werden. Ihr Handeln muss man entweder Erahnen oder aber es gibt
bereits Erfahrungswerte durch getätigte Angriffe, die zur Sicherheitsvorkehrung
verwendet werden können. Durch Angriffe wurden z.B. 2005 den Unternehmen
CardSystems und Choiceline 40 Mio. bzw. 1 Mio. Kreditkartendaten entwendet38. Im
August 2008 wurde außerdem bekannt, dass dem deutschen Unternehmen SKL
(Süddeutsche Klassenlotterie), Bankdaten von ca. 17.000 Kunden gestohlen worden
sind39.
Nachfolgende Tabelle erläutert die 2006 am meisten in Erscheinung getretenen
Angriffsformen:
37
38
39
Ein Patch führt eine Fehlerbereinigung durch die Ersetzung einzelner Programmteile durch.
Dies geht aus einer Studie des Identity Theft Resource Center vom September 2005 hervor.
www.idtheftcenter.org/breaches.pdf, 26.05.2008
Vgl. http://www.heise.de/newsticker/Verbraucherzentrale-Massenhafter-Missbrauch-von-BankkontenDaten-2-Update--/meldung/114124, 21.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 16 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 3: Sicherheit und deren Gegner
Angriffsform
Erläuterung
Malware
Als Malware bezeichnet man meist getarnte Software, die eine
vom Benutzer unerwünschte ggf. schädliche Funktion ausführt.
Hierunter fallen z.B. Viren, Würmer und Trojaner. 2006 fielen
35% auf diese Angriffsform zurück.
Unbefugte
Hierunter fällt jeder Angriff, der darauf abzielt Daten auszulesen,
Kenntnisnahme
die nicht für die auslesende Person bestimmt sind (vgl. Tabelle 41). Hierunter zählt man z.B. Abhörversuche und Analysen des
Kommunikationsverhaltens. 12% aller Angriffe wurden hierüber
getätigt.
Cracker
Cracker hacken mit böser Absicht. Sie dringen in Netze / Rechner
ein, um dort Schaden anzurichten. Sie löschen, ändern oder
missbrauchen geschützte Datenbestände. Der Gegenpart hierzu
sind Hacker, deren Motivation gut ist. Sie arbeiten auch im
Auftrag von Unternehmen als Penetrationstester. Ebenfalls 12%
entfielen auf die Angriffsform des Cracking.
Manipulation zur
Diese Form des Angriffs ist dann gegeben, wenn Programme oder
Bereicherung
auch Berechtigungen eines DBS dahingehend manipuliert werden
um hauptsächlich Daten eines Systems auszuspähen (z.B. SQL –
Injection40). Diese, in Erfahrung gebrachten Daten, werden dann
z.B. weiterverkauft. 11% der Angriffe wurden durch diese
Angriffsform verursacht.
Sabotage
Unter Sabotage sind Angriffe zu verstehen, die darauf abzielen,
das IT – System oder deren Komponenten zu schädigen. Z.B.
zählen Denial of Service – Attacken (Gezielte Bombardierung
eines Servers, damit dieser den Dienst einstellt.) oder die
böswillige Abschaltung einer Homepage dazu. 10% aller Angriffe
entfielen auf diese Angriffsform.
Tabelle 3-1: 2006 getätigte Angriffsformen (Quelle: [kes 2007])
40
Bei einer SQL – Injection wird versucht, artfremde SQL – Statements abzusetzen um damit z.B. einen
Benutzer zu erstellen, der dazu berechtigt ist, gesicherte Daten auszulesen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 17 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 3: Sicherheit und deren Gegner
Anhand dieser Tabelle ist zu erkennen, dass die meisten Schäden immer noch durch
Malware verursacht werden. Jedoch sind die anderen vier Angriffsformen mit knapp
10% stark vertreten und lt. [kes 2007] erst in den letzten Jahren vermehrt
aufgetaucht. Dies liegt nicht zuletzt daran, dass mittlerweile genaue Beschreibungen
von Sicherheitslücken fast jeder Software im Internet nachgeschlagen werden
können. Meist gibt es auf entsprechenden Homepages genaue Beschreibungen wie
man die Lücken ausnutzen kann. Da sich viele Angriffe gegen Sicherheitslücken
richten, die schon lange bekannt sind, würde meist schon das regelmäßige Einspielen
von sicherheitsrelevanten Patches genügen um vielen Angriffen den Wind aus den
Segeln zu nehmen.
3.1.1.
Interne Angriffe
Gegenüber der Angriffsform, wird weiterhin unterschieden ob ein Angriff innerhalb
oder außerhalb eines IT – Systems durchgeführt wird. Die einhellige Meinung, die
jeder hat, wenn er von Angriffen auf ein IT – System hört, ist, dass Eindringlinge die
meisten Verursacher von Einbrüchen auf ein IT – System sind. Entgegen dieser
Meinung hat eine Studie von 2004 ergeben, dass 70% der Angriffe, die auf eine
Komponente eines IT – Systems erfolgen, entweder durch Insider oder durch
unzufriedene Mitarbeiter geschehen41. Viele Institutionen geben große Mengen ihres
IT – Budgets für die Entwicklung einer sicheren Systemlandschaft, inkl. Firewall und
Betriebssystem aus, ohne von der größten Bedrohung zu ahnen, die innerhalb der
Institution droht. Gerade in diesem Fall ist, neben einer vertrauensvollen Auswahl
der Administratoren, auch eine sehr eng zugeschnittene Berechtigungsvergabe für
die Benutzer von Datenbanksystemen von Nöten42.
3.1.2.
Externe Angriffe
Hört man von Angriffen auf ein IT – System, so werden meist nur die externen
Angriffe vernommen, die zwar nur 30% der Angriffe ausmachen, aber trotzdem
genauso beachtet werden sollten. Zu den externen Angriffsformen zählen z.B., wie
unter Abschnitt 3-1 bereits erwähnt, Malware, Cracker, Hacker, Denial of Service –
Attacken als auch der Missbrauch von Rechnern als Bot – Netze. Bei diesen Bot –
Netzen handelt es sich um eine relativ neue Angriffsform. Dabei wird ein Programm
unerkannt auf dem Rechner eingeschleust. Mittels einer externen Fernsteuerung wird
das eingeschleuste Programm aktiviert und missbraucht den Rechner z.B. zur
Versendung von Denial of Service- oder Spam – Attacken.
3.2.
Sicherheit lt. BSI
Wie bereits erwähnt, wirken viele Bedrohungen auf ein IT – System und damit auch
auf deren Komponenten. In unserem Falle auf ein Datenbanksystem. Das Bundesamt
für Sicherheit in der Informationstechnologie (kurz: BSI) beschreibt hier drei
Schutzziele, die es, aufgrund der Bedrohungen, zu wahren gilt. Diese wichtigen Ziele
werden in nachfolgender Tabelle kurz erläutert:
41
42
Lt. einer Studie von Computer Security Institute and FBI Survey im Jahre 2004.
Vgl. Abschnitt 5-5-2
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 18 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 3: Sicherheit und deren Gegner
Schutzziel
Erläuterung
Verfügbarkeit
Die Verfügbarkeit soll gewährleistet werden. Die Funktionen bzw.
Services
eines
IT –
Systems
bzw.
einer
darin enthaltenen
Komponente sowie deren enthaltene Daten sollen dauerhaft zur
Verfügung stehen.
Integrität
Die Daten innerhalb einer Komponente sollten nur von Befugten in
beabsichtigter Weise vollständig, widerspruchsfrei und korrekt
verarbeitet werden, da ansonsten der Verlust der Integrität
gegeben ist.
Vertraulichkeit
Die in einer Komponente enthalten Daten dürfen nur befugten
Personen
zugänglich
sein.
D.h.
es
soll
kein
unbefugter
Informationsgewinn erfolgen.
Tabelle 3-2 Schutzziele für Sicherheit im IT – System (Quelle: http://www.bsi.bund.de, 15.03.2008)
Diese Schutzziele bilden die Grundlage zur Erstellung einer Risikobewertung, einer
Überprüfung des vorhandenen IT – Sicherheitsniveaus sowie einer Implementierung
und den Aufbau einer IT – Sicherheitsorganisation.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 19 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 4: Umsetzung von Sicherheit in Datenbanksystemen
4.
Umsetzung von Sicherheit in
Datenbanksystemen
Sicherheit in Datenbanksystemen ist ein sehr komplexes Thema. Datenbanksysteme
sind häufig „Out of the Box“ sehr unsicher, weshalb man zur Absicherung auch die
Systemlandschaft, in der das Datenbanksystem eingebettet ist, genau betrachten
und absichern muss43. Viele Sicherheitsprobleme werden häufig durch die Client –
Anwendungen der Datenbanksysteme verursacht, wobei z.B. die Wahl der
Passwörter von vielen Anwendern inkonsequent gehandhabt wird.
MySQL hat mit Erscheinen der Version 5.0.67 (siehe Abschnitt 6-2) schon wichtige
Sicherheitstools implementiert. Auch Oracle legt mittlerweile ein größeres
Augenmerk auf Sicherheit. So wurden z.B. bis Ende 2006 schon 28444
Sicherheitsfehler ausgemerzt. 87 dieser Sicherheitslücken betrafen hierbei
Schwachstellen der Datenbank selbst.
Die nachfolgenden Teilabschnitte beschäftigen sich mit der Umsetzung von Sicherheit
in Datenbanksystemen und den damit verbundenen IT – Systemen. Neben den „Acht
Geboten der Datensicherheit“ wird weiterhin auf einen hinzunehmenden
Sicherheitskompromiss und die Sensibilisierung aller Mitarbeiter, die direkt oder
indirekt mit dem Datenbanksystem zu tun haben, eingegangen.
4.1.
Acht Gebote der Datensicherheit
Besonders
in
Betrachtung
von
Datenbanksystemen
und
der
damit
zusammenhängenden Datensicherheit wurden vom Bundesamt für Sicherheit in der
Informationstechnik die „Acht Gebote der Datensicherheit“ entworfen. Sie sind in §9
des
BDSG45
verankert.
Sie
sollten
innerhalb
der
Verwendung
eines
Datenbanksystems ebenfalls Beachtung finden.
Gebot
Erläuterung
Zutrittskontrolle
Bei diesem Gebot sollten nur befugte Personen Zugriff auf die
Daten haben dürfen.
Zugangskontrolle
Bei den zugreifenden Personen soll eine Authentifizierung46
durchgeführt werden. D.h. dass die entsprechende Person nur
mit
eigenem
Usernamen
und
Kennwort
auf
das
System
zugreifen darf.
43
44
45
46
Vgl. Abschnitt 5-2
Vgl. http://www.red-database-security.com/wp/doag_best_of_oracle_security_2006.pdf, 26.05.2008
Red – Database – Security GmbH ist Spezialist für das Thema Sicherheit im Oracle – Umfeld.
BundesDatenSchutzGesetz
Als Authentifizierung wird die Überprüfung einer vorgegebenen Identität bezeichnet.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 20 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 4: Umsetzung von Sicherheit in Datenbanksystemen
Zugriffskontrolle
Mittels
Autorisierung47
Personen
das
Recht
wird
zuteil
geprüft,
wird
ob
eine
den
zugreifenden
bestimmte
Aktion
durchzuführen bzw. bestimmte Daten auszulesen.
Weitergabe-
Personen dürfen ihnen anvertraute Daten nicht an unberechtigte
kontrolle
Personen weitergeben.
Eingabekontrolle
Hier soll nachgeprüft werden, welche Person, wann, welche
Daten im System eingegeben hat.
Auftragskontrolle
Es soll z.B. mittels eines Berechtigungssystems innerhalb des
DBS überprüft werden, welche Personen bestimmte Prozesse
anstoßen, durchführen und beenden dürfen.
Verfügbarkeits-
Alle Daten innerhalb eines DBS sollten immer verfügbar sein.
kontrolle
Zur Erfüllung dieses Gebots besteht die Möglichkeit regelmäßig
Backups der Datenbasis durchzuführen.
Trennungsgebot
Nicht
zusammenhängende
Daten
sollten
auch
nicht
zusammenhängend gespeichert werden.
Tabelle 4-1 Acht Gebote der Datensicherheit (Quelle: [Faeskorn-Woyke et al. 2007] Seite 56 f.)
Diese acht Gebote können bereits während der Konzeption und der Einbettung des
DBS in die Systemarchitektur Beachtung finden. Indem man sich z.B. Gedanken über
Verfügbarkeits-, Zutritts-, Zugriffs- und Zugangskontrolle macht, kann schon von
Beginn an ein Fokus, auf die Benutzer der Datenbank, auf das System in dem das
DBS abgelegt wird und evtl. damit verbundene Backupmethoden, gelegt werden. Die
weiteren Gebote können innerhalb der Datenmodellierung und der Auswahl bzw. der
Rechte- und Rollenvergabe der Benutzer, Beachtung finden.
4.2.
Der Sicherheitskompromiss
Meist beginnt Sicherheit mit der Dokumentation von entsprechenden Richtlinien und
Durchführungsbestimmungen in einem Sicherheitsplan. Dieser Sicherheitsplan wird
bzw. sollte ein sehr komplexes Dokument sein, das sich durch alle Schichten eines IT
– Systems und die Organisation einer Institution schlängelt. Neben der Einhaltung
von Gesetzen und der Abwehr von allen nur erdenklichen Gefahren müssen natürlich
auch die verantwortlichen Mitarbeiter und deren Aufgaben benannt werden.
Weiterhin ist Sicherheit ein immer fortlaufender Prozess, was den Sicherheitsplan zu
einem lebendigen Dokument macht. Allein schon bei den eben genannten Punkten,
müssen früher oder später Kompromisse eingegangen werden. Die Pflege und
Kontrolle der Durchführung eines Sicherheitsplans nimmt viel Zeit in Anspruch, was
47
Die Autorisierung erfolgt nach der Authentifizierung und beinhaltet die Zuweisung von Rechten für den
angegebenen Benutzer.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 21 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 4: Umsetzung von Sicherheit in Datenbanksystemen
einen Arbeitstag durchaus füllen kann.
Ein weiterer Punkt ist immer noch die fehlende Unterstützung durch die
verantwortlichen Mitarbeiter einer Institution. Eine komplette Umsetzung von
Sicherheitsrichtlinien ist leider auch ein erhöhter Kostenfaktor. Neben laufenden
Schulungen von Mitarbeitern und Benutzern, werden i.d.R. auch zusätzliche Software
und Mitarbeiter, die die Sicherheit umsetzen, benötigt. Weiterhin sind oft
einschneidende Änderungen in der Systemarchitektur und deren Bearbeitung von
Nöten.
Da die Einführung zu strenger Sicherheitspläne, aufgrund von zusätzlich
entstehenden Kosten für weitere Sicherheitssoftware, das Trainieren der Benutzer
und die Durchführung komplexer Prozeduren oft nicht praktikabel ist, muss versucht
werden, das Sicherheitsrisiko und die Sicherheitskosten auf einem geringen Niveau
zu halten.
Um den Kompromiss zwischen Risiko und Effizienz besser beurteilen zu können,
sollte versucht werden die Gefahren bzw. Ereignisse für ein Datenbanksystem und
deren mögliche Kosten aufzulisten, um ihnen danach eine gewisse Priorität zuordnen
zu können. Ereignisse die auftreten können sind z.B. die Zerstörung des kompletten
Datenbanksystems und die dadurch entstandenen Kosten für einen Neuaufbau, die
Korruption und eine damit verbundene Neueinspielung von Programmen innerhalb
einer Datenbank oder aber das Eindringen in die Datenbank mit administrativen
Benutzerrechten. Hierdurch entstehen nicht nur direkte Kosten, wie z.B. den
Neuaufbau des Datenbanksystems. Es entstehen auch indirekte Kosten, wie z.B. der
Suche nach der Ursache oder aber zusätzliche Schulungsmaßnahmen für die
Administratoren. Daher sind die möglichen Risiken und deren mögliche Kosten genau
einzustufen, zu priorisieren und einander abzuwägen.
Die Umsetzung und Einführung eines Sicherheitsplans für Datenbanksysteme sollte
demnach ein Kompromiss zwischen reduziertem Risiko und Effizienz sein.
4.3.
Mitarbeiter sensibilisieren
Jeder noch so gute Sicherheitsplan hilft nicht, wenn Mitarbeiter die Forderungen
eines solchen Plans nicht verwirklichen. Entweder weil sie es nicht wissen oder aber
weil sie es nicht wollen.
Da erhöhte Sicherheit auch meistens erhöhten Aufwand bedeutet, wird das auch
einige Mitarbeiter abschrecken, hier erfolgreich mitzuwirken. Ungewohnte
Arbeitsabläufe und ungewohnte Barrieren fördern eine gewisse Diskrepanz
gegenüber dem Thema Sicherheit. Typische Fragen wie „Ich durfte doch die ganze
Zeit auf der Produktion Daten ändern, warum jetzt nicht mehr?“ sind an der
Tagesordnung. Hauptsächlich diese Mitarbeiter werden auch versuchen die
Anforderungen, die an sie gestellt wurden, zu umgehen.
Andere
Mitarbeiter
hingegen
haben
einfach
keine
Vorstellung
von
Datenbanksystemen und dem Thema IT – Sicherheit. Allein durch Unwissen werden
sie die Umsetzung von Sicherheitsanforderungen nicht verstehen und unterstützen
können.
Es kann festgehalten werden, dass Sicherheit nur umgesetzt werden kann, wenn die
betroffenen Personen ihre an sie gestellten Anforderungen gewissenhaft umsetzen.
Darum ist es unumgänglich, Mitarbeiter für die Sicherheitsanforderungen, die aus
einem Sicherheitsplan hervorgehen, zu sensibilisieren.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 22 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 4: Umsetzung von Sicherheit in Datenbanksystemen
Ein über ein Intranet48 oder E-Mail gesteuerter Informationsdienst, mit Informationen
über aktuelle Bedrohungen, wie z.B. Viren oder Hinweisen über aufgetretene
Sicherheitslücken, kann die Mitarbeiter informieren und nicht zuletzt sensibilisieren.
Als weitere Maßnahme sollten regelmäßig Schulungen durchgeführt werden, die z.B.
über den richtigen und sicheren Umgang der zu verwaltenden Daten eines
Datenbanksystems oder aber über die richtige Auswahl von Passwörtern (vgl.
Abschnitt 5-5-5) informieren.
48
Ein Intranet ist ein internes Netzwerk aus Rechnern / Servern, innerhalb eines Unternehmens bzw.
einer Organisation.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 23 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
5.
Erarbeitung eines Sicherheitsplans
Nachdem nun grundlegende Sicherheitsbegriffe, Datenbanksysteme und mögliche
Angriffe erläutert wurden, soll nun die Erarbeitung eines Oracle – Sicherheitsplans
erfolgen. Die Erarbeitung eines Oracle – Sicherheitsplans umfasst die Nennung von
verantwortlichen Mitarbeitern, grundlegenden Sicherheitshinweisen in Bezug auf die
umgebende Systemlandschaft und natürlich die Sicherung des Datenbanksystems
selbst.
5.1.
Verantwortlichkeiten zuweisen
Bevor Sicherheit im Datenbanksystem richtig umgesetzt werden kann, sollte
zunächst überlegt werden, wer letztlich für eine Umsetzung und Verteilung der zu
bewältigenden Anforderungen verantwortlich ist. Mit der Nennung von
Administratoren ist es allein nicht getan. Es sollte vielmehr ein ganzes Netz aus
Personen gesponnen werden, die einen Teil zur Sicherheit beitragen. Dieses Netz
sollte aus allen Personen, die direkt oder indirekt mit dem Datenbanksystem zutun
haben, bestehen. Denn nur wenn jeder seinen Teil zum Ganzen beiträgt, kann das
Datenbanksystem und damit auch die Sicherheit der Daten gewährleistet werden.
Sicherheit und Datenbanksysteme sind meist zwei verschiedene Welten. Während
eine Datenbankgruppe oft wenig Hintergrundwissen zum Thema Sicherheit besitzt,
hat eine Security – Gruppe meist wenig Wissen über Datenbanken und der
Notwendigkeit, deren enthaltene Daten zu sichern. Dies liegt auch daran, dass
Security im Datenbankumfeld i.d.R. eine andere Rolle spielt. Hier geht es meist um
Fragen, wie Benutzerrollen oder Privilegien der Benutzer. Weiterhin sind
Datenbanksysteme meist sehr komplex, was es den Anwendern schwierig macht ein
weiteres Verständnis für Sicherheitsprobleme außerhalb der Datenbanken zu
entwickeln. Außerhalb der Datenbanken haben Systemadministratoren i.d.R. kein
oder zumindest relativ wenig Datenbankwissen. Sie kennen sich zwar bestens mit
Betriebssystemen aus, jedoch ist die darauf installierte Software meist nur
oberflächlich bekannt und existiert für sie nur als Blackbox49.
In Bezug auf diese Problematik wäre es wünschenswert Sicherheitsmitarbeiter zu
beschäftigen die einen grundlegenden Überblick über die gesamte Systemlandschaft
besitzen und Sicherheitslücken aller Komponenten innerhalb eines IT – Systems
kennen und diese zum Schutz des Datenbanksystems einsetzen.
Hat eine Organisation eine gewisse Größe erreicht, haben auch viele weitere
Abteilungen, außerhalb der IT – Abteilung, indirekt mit Datensicherheit zutun. Hier
wäre
eine
Zusammenarbeit
mit
anderen
Abteilungen
wünschenswert.
Sicherheitsanforderungen und –pläne könnten zusammen erarbeitet und mit Hilfe
der jeweiligen Abteilungen (Datenbankadministratoren, Datenbankprogrammierer,
Fachabteilung usw.) besser durchgesetzt werden.
Nachfolgende
Tabelle
Sicherheitsmitarbeitern:
49
zeigt
eine
mögliche
Zusammensetzung
von
Die Software ist nur über die nach außen gelegenen Schnittstellen bekannt. Dadurch fehlt
Hintergrundwissen in Bezug auf das interne Arbeiten der Software.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 24 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Mitarbeiter
Erläuterung
Datenbank-
Datenbankadministratoren sind für das Datenbanksystem und
administrator
dessen Komponenten verantwortlich. Ihr Aufgabengebiet kann in
verschiedene Gruppen eingeteilt werden. In der Praxis wird meist,
auf horizontaler Ebene, zwischen Applikationsadministratoren und
Administratoren für den restlichen Bereich unterschieden.
Die Applikationsadministratoren sind für die Applikationen rund
um die Datenbank verantwortlich. Sie sind u.a. für die Anbindung
der Forms – Masken, der PL/SQL – Packages, der Stored –
Procedures usw. zuständig.
Die andere Gruppe der Administratoren ist für den reibungslosen
und sicheren Betrieb des Datenbanksystems verantwortlich. Sie
können z.B. Konfigurationsdateien einspielen und ändern, neue
Schemas anlegen, die Performance und Speicherintensität der
Datenbank kontrollieren und verbessern, Sicherheitstools des
Datenbanksystems einspielen, die Berechtigungen sowie Rollen
vergeben und das DBS auf dem Betriebssystem warten.
Möchten
Entwickler
ihre
Programme
auf
höher
gelegenen
Datenbankinstanzen einspielen (z.B. von der Testdatenbank auf
die
Produktionsdatenbank)
Unterscheidung
Entwicklungs-
der
und
gibt
es
noch
eine
vertikale
Administratoren.
Hier
wird
zwischen
Produktionsadministratoren
Programmierer
können
durchführen,
müssen
somit
Änderungen
diese
Produktionsadministratoren
in
aber
die
unterschieden.
an
Programmen
erst
über
produktive
die
Datenbank
einspielen lassen.
Betriebssystem-
Für das reibungslose Funktionieren des Betriebssystems sind
administrator
diese
Mitarbeiter
Antivirensoftware
verantwortlich.
ein,
Sie
kontrollieren
spielen
Patches
eingespielte
und
Software,
vergeben Berechtigungen für Verzeichnisse (z.B. könnte eine
erstellte Gruppe50 Datenbankadministratoren, die Berechtigung
erhalten, die Verzeichnisse des Datenbanksystems selbst zu
50
Gruppen werden im Zusammenhang mit IBM – AIX im Abschnitt 5-3-1 und Abschnitt 5-3-3
beschrieben.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 25 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
verwalten), verbessern die Performance und Speicherverwaltung,
sichern das Betriebsystem und sorgen letztlich für das perfekte
Zusammenspiel zwischen Datenbank- und Betriebssystem.
Netzwerk-
Netzwerkadministratoren sollten die sichere Vernetzung im Auge
administrator
haben. Sie ermöglichen z.B. eine sichere Netzwerkverbindung
über Virtual Private Network (VPN) und über Secure Socket Layer
(SSL). Weiterhin kümmern sie sich um die richtige Konfiguration
von Firewalls, Routern, Switches und sorgen dafür, dass die
Datenübertragung zwischen verschiedenen Systemlandschaften
und den darin enthaltenen Datenbanksystemen nur über zuvor
definierte Schnittstellen erfolgt. Somit wird dafür gesorgt, dass
nur valide Daten im Datenbanksystem ankommen.
Internet-
Im Falle einer Internetanbindung liegt hier die Verantwortlichkeit,
administrator
den Webauftritt so in der Systemlandschaft zu platzieren und zu
warten, dass das Zusammenspiel mit den übrigen Komponenten
eines Netzwerkes perfekt funktioniert. Der richtige Einsatz einer
Demilitarisierten Zone (DMZ)51 ist hier ebenfalls gefragt. In
Zusammenarbeit mit Penetrationstestern sorgen sie auch dafür,
dass der Webauftritt gegen Angriffe abgeschottet ist.
Security-
Bei größeren Unternehmen existiert weiterhin eine Security –
Abteilung
Abteilung. Diese ist u.a. für die Kontrolle des Auditing zuständig.
Das Betriebssystem- bzw. Datenbank – Auditing (vgl. Abschnitt
5-3-4 und Abschnitt 5-6-4) wird von ihnen auf besondere
Vorkommnisse kontrolliert. Neben Berechtigungsvergaben an
verschiedene Benutzergruppen wird auch die Umsetzung der
Sicherheitsvorgaben,
sowie
die
Arbeit
der
Administratoren
überprüft.
Penetrations-
Penetrationstester existieren i.d.R. ebenfalls nur bei größeren
tester
Unternehmen. Sie spüren Sicherheitslücken bzw. fehlerhafte
Konfigurationen auf und fixen diese. Bei kleineren Unternehmen
oder Organisationen werden auch externe Penetrationstester
engagiert um Sicherheitsprobleme aufzuspüren und zu beseitigen.
Tabelle 5-1 Sicherheitsmitarbeiter (Quelle: Vgl. [Newman et al. 2004] Seite 86)
51
Vgl. Abschnitt 5-2-2
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 26 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Diese Tabelle zeigt auf, dass Verantwortlichkeiten und Sicherheitswissen des IT –
Systems auf viele Personen verteilen werden muss um einen umfassenden
Sicherheitsplan für ein Datenbanksystem zu verwirklichen.
Die Personen müssen während der Durchführung eines Prozesses (z.B. die
Einspielung neuer Daten in die Datenbank) einerseits miteinander kommunizieren
um den Prozess zu vervollständigen. Andererseits ist das komplette Wissen von
Sicherheitstools und eventuellen Sicherheitslücken auf viele Personen verteilt. Dies
macht es einem internen Angreifer schwer, sein Vorhaben zu verwirklichen.
Weiterhin erhöht sich, da jede Person ein exakteres Wissen über seinen Teilbereich
von Aufgaben hat, die Qualität und Sicherheit des gesamten IT- und
Datenbanksystems.
5.2.
Die Systemlandschaft
Wie schon in Abschnitt 4 erwähnt sind Sicherheitslücken sowie fehlerhafte
Konfigurationen und somit Angriffspunkte auf ein Datenbanksystem häufig außerhalb
zu finden. Von daher reicht die Absicherung des Datenbanksystems allein nicht aus,
um dafür zu sorgen, dass die enthaltenen Daten sicher sind. Es muss zunächst
geklärt werden, mit welchen Komponenten das Datenbanksystem interagiert.
In diesem Fall wird davon ausgegangen, dass das Datenbanksystem in dem
Betriebssystem IBM – AIX eingebunden ist. Weiterhin ist dieses Betriebssystem Teil
eines Netzwerkes, das vom Internet ansprechbar und damit auch angreifbar ist.
Demnach wird neben dem Betriebssystem, der Einsatz einer Demilitarisierten Zone
kurz betrachtet.
5.2.1.
Das Betriebssystem IBM – AIX
Die erste Version von UNIX wurde 1969 von Ken Thompson und Dennis Ritchie, in
den Bell – Laboratories52, entwickelt. Diese Urversion von UNIX wurde in Assembler
geschrieben. Nachdem beide Entwickler 1970 die Programmiersprache C (was heute
übrigens eine der weit verbreiteten Programmiersprachen ist) erfanden, wurde UNIX
in diese Sprache umgeschrieben. 1973 wurde UNIX zu Ausbildungszwecken erstmals
an Universitäten eingesetzt.
Seither wurden viele neue Varianten entwickelt. Da UNIX von vielen Unternehmen
weiterentwickelt wurde, existieren mittlerweile viele verschiedene UNIX - Versionen.
Diese Weiterentwicklung sorgte dafür, dass jeweils sehr stabile und sichere Systeme
entstanden sind. Das derzeit führende UNIX – Betriebssystem heißt Solaris und wird
von dem Unternehmen Sun – Microsystems entwickelt und vertrieben.
IBM – AIX wird, wie der Name schon sagt, von IBM entwickelt. Dieses System
zeichnet sich durch eine sehr gute Skalierbarkeit53 und Zuverlässigkeit aus, was
Hauptkriterien für den sicheren und stabilen Einsatz eines Datenbanksystems sind.
Die Interoperabilität54 und die Benutzerfreundlichkeit sind mit "gut" zu bewerten. Der
52
53
54
Heute als Unternehmen mit dem Namen AT&T bekannt.
Über die Skalierbarkeit wird angegeben, wie ein System mit großen Mengen an Prozessen bzw.
Transaktionen und dem daraus resultierenden Datenstrom umgeht.
Die Interoperabilität beschreibt die Zusammenarbeit mit anderen Produkten (auch die anderer
Unternehmen) und Industriestandards.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 27 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Preis sowie die Kosten für den Support und Schulungen sind jedoch sehr teuer. Ein
Sicherheitsexperte des Unternehmens Google aus der Niederlassung in Dublin,
berichtete aus eigener Erfahrung, dass die von IBM zu erhaltende Hardware ebenfalls
überteuert und einige, damit verbundene Komponenten, veraltet wären und nicht
den neuesten Sicherheitsrichtlinien entsprechen.
UNIX – Betriebssysteme werden hauptsächlich von großen Unternehmen und
Hochschulen eingesetzt. Das IBM eigene Datenbanksystem DB2 sowie das extra für
UNIX entwickelte Datenbanksystem Oracle bilden den Großteil der vertretenden
Datenbanksysteme auf AIX.
5.2.2.
Errichtung einer DMZ
Wie schon in den vorigen Abschnitten erwähnt, ist es in größeren Institutionen
weiterhin wichtig eine Demilitarisierte Zone55 einzusetzen. Es handelt sich hierbei um
eine Technik, interne vor öffentlichen Netzwerken, wie z.B. dem Internet zu
schützen. Eine DMZ sollte also immer dann zum Tragen kommen, wenn mehrere
Rechner in einem Netzwerk miteinander verbunden sind und einer dieser Rechner
über das Internet angebunden ist.
Der oder die Rechner die ans Internet angebunden sind, z.B. Webserver oder FTP –
Server, liegen in dieser DMZ. Die DMZ kann vom Internet, als auch von den internen
Rechnern, dem Intranet des Unternehmens, angesprochen werden. In
Organisationen und Unternehmen in denen eine direkte Weiterleitung von Daten aus
dem Internet zum Intranet keine ökonomische Relevanz hat, sollten die im Intranet
enthaltenen Rechner selbst dafür verantwortlich sein, Daten, die zuvor über das
Internet zur Verfügung gestellt wurden, abzuholen.
Gerade in Bezug auf ein Datenbanksystem und der Notwendigkeit, dieses mit dem
Internet zu verbinden, ist die Einführung einer DMZ bzw. mehrerer DMZ sehr
sinnvoll. Daten die über das Internet in die Datenbank eingespielt werden sollen,
können z.B. in einem täglichen Lauf abgerufen und in die interne, im Intranet
liegende, richtige Datenbank, eingespielt werden. Das Datenbanksystem, das in der
DMZ liegt, sollte nur ganz wenige Berechtigungen, Benutzer und keine
sicherungsbedürftigen Daten beinhalten. Das Internet sollte zur DMZ und dem darin
enthaltenen Webserver bzw. Datenbanksystem über eine erste Firewall geschützt
sein. Das Intranet selbst sollte dann ebenfalls wieder über eine Firewall zur DMZ
verbunden und gesichert sein.
Weiterhin muss beachtet werden, dass nur die notwendigste Software auf den, in der
DMZ liegenden, Rechnern eingespielt wird. Jede Software ist ein zusätzlicher
Angriffspunkt und birgt Gefahrenpotenziale. Da wohl keine Software perfekt ist,
enthält jede Software Bugs, die im Extremfall als Sicherheitslücke ausgenutzt werden
kann56.
55
56
Vgl. http://www.itwissen.info/definition/lexikon/demilitarized-zone-DMZ-Demilitarisierte-Zone.html,
23.06.2008
Eine zusätzliche Beschreibung zur richtigen Absicherung eines gesamten Netzwerkes, würde den
Inhalt dieser Arbeit sprengen. Von daher sei hier auf weiterführende Literatur verwiesen.
http://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5M%C5Z%D5%D1&url=searchalias%3Daps&field-keywords=netzwerksicherheit, 07.08.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 28 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
5.3.
Absicherung des Betriebssystems IBM – AIX
Die Absicherung eines IBM – AIX – Systems ist sehr vielseitig und könnte ganze
Bücher füllen. Allein deshalb sei darauf hingewiesen, dass es sich hier nur um
grundlegende Sicherheitsanforderungen bzw. Umsetzungen handeln kann. Um
ausführliche Sicherheitstools nutzen zu können, sei auf das Administrationsbuch
[Michael 2002] verwiesen.
IBM – AIX ist, wie jedes andere UNIX, ein Multiuser – System. Wie in nachfolgender
Grafik dargestellt, bedeutet dies, dass sich mehrere Benutzer gleichzeitig an dem
Betriebssystem anmelden und auch damit arbeiten können.
Abbildung 5-1: Multiuser – System (Quelle: selbst erstellt)
Anhand dieser Betrachtung wird sehr schnell deutlich, dass aufgrund der vielen
Benutzer ein erhöhtes Sicherheitsrisiko besteht. Selbst wenn das Betriebssystem an
kein öffentliches Netzwerk angeschlossen ist, treten allein durch die Anzahl der
möglichen Benutzer viele Sicherheitsrisiken auf, die entsprechend ausgeschaltet
werden müssen.
Die in den folgenden Teilabschnitten erwähnten Sicherheitstools und -möglichkeiten
gelten sowohl für IBM – AIX als auch für sonstige UNIX – Betriebssysteme. Daher
werden beide Begriffe, IBM – AIX als auch UNIX, gleichbedeutend verwendet.
5.3.1.
Dateisicherheit
Um mit Berechtigungen innerhalb eines UNIX – Betriebssystems richtig umgehen zu
können, wird zu Beginn auf das von UNIX verwendete Berechtigungssystem
eingegangen.
Dieses stellt drei Berechtigungsebenen zum Schützen von Dateien und
Verzeichnissen zur Verfügung: den Dateibesitzer, die Dateigruppe und alle anderen
Benutzer. Zu erwähnen ist, dass die Dateiberechtigungen nicht einem Einzelnen, bis
auf den Dateibesitzer, erteilt oder entzogen werden können sondern nur Gruppen
und den restlichen Usern.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 29 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Weiterhin gibt es drei verschiedene Berechtigungstypen: Lesen, Schreiben und
Ausführen. Über den Befehl „ls –l“ werden die Dateien, Verzeichnisse und
symbolischen Links57 in einem Verzeichnis angezeigt. Vor jeder Datei steht eine 10
Zeichen lange Zeichenkette, die anhand des nachfolgenden Beispiels kurz erläutert
wird:
-rwxrwxr-x
1 vtadm
vt
515
27 Mai 2004 umgebung_Q60.sh
Der erste Buchstabe, in unserem Fall ein -, gibt an, ob es sich um eine Datei (-), ein
Verzeichnis (d) oder aber um einen symbolischen Link (l) handelt. Nach diesem
Zeichen gibt es drei Gruppen mit jeweils drei Zeichen. Die ersten drei Zeichen, hier
rwx, geben die Berechtigungen des Dateibesitzers (hier: vtadm) an. Die nächsten
drei Zeichen (ebenfalls rwx) die der Dateigruppe (hier: vt) und die letzten drei
Zeichen (r-x), die der restlichen Benutzer.
Die erste Position jeder Gruppe ist die Leseberechtigung und wird durch ein r (read)
dargestellt. Die zweite Position ist die Position mit den Schreibrechten, welches durch
ein w (write) dargestellt wird. An der dritten Position stehen die ausführbaren
Rechte. Diese werden durch ein x (execute) dargestellt. Steht an einer der
erwähnten Positionen ein -, so bedeutet dies, dass für die jeweilige Gruppe, das
jeweilige Recht entzogen ist.
Am obigen Beispiel darf die Gruppe der restlichen Benutzer (r-x) das Shellskript
umgebung_Q60.sh lesen (r) und ausführen (x), jedoch nicht schreiben (-).
Um Berechtigungen an einer Datei zu ändern, kann der Befehl chmod mit den
Aufrufparametern Zugriffsrechte und Pfad- bzw. Dateiname58 benutzt werden. Jedoch
ist dabei zu beachten, dass nicht nur den Dateien selbst, sondern auch den
Verzeichnissen, in denen die Dateien liegen, entsprechende Berechtigungen erteilt
werden müssen. Denn, wenn der entsprechende Benutzer keine Zugriffsberechtigung
auf das Verzeichnis hat, in dem die Dateien sich befinden, kann er trotz erteilter
Berechtigung auf Dateiebene, nicht auf die Datei zugreifen.
Anhand des Befehls chmod ist es also möglich für jede Datei bzw. jedes Verzeichnis
und Benutzergruppe die Berechtigungen genau einzustellen um einem Missbrauch an
Dateien frühzeitig einen Riegel vorzuschieben.
5.3.2.
Das administrative Konto Root
Die Autorisierung als Root – Benutzer ist weiterhin ein wichtiger Aspekt in der
Absicherung. Es handelt sich dabei um das administrative Konto von UNIX –
Systemen. Dieses Konto erlaubt es dem Benutzer, jeglichen möglichen Befehl auf
dem Betriebssystem auszuführen. Um es einer evtl. Brute – Force – Attacke59
möglichst schwer zu machen, sollte das Passwort für dieses Konto in keinem
Wörterbuch zu finden sein. Weiterhin sollten Zahlen und Sonderzeichen, ebenfalls
wie Groß- und Kleinbuchstaben verwendet werden. Da bei einem sechs Zeichen
langen Kennwort ca. eine Milliarde Vergleiche notwendig sind um das Passwort zu
knacken, sollte die Verwendung eines zwölf Zeichen langen Kennworts halbwegs
57
58
59
Als symbolischen Link bezeichnet man eine Referenz auf eine Datei oder ein Verzeichnis.
Für das oben genannte Beispiel hätte der Befehl folgendermaßen ausgeführt werden können:
„chmod 775 umgebung_Q60.sh“
Vgl. [Michael 2002]
Mittels dieser Attacke, wird versucht, mit allen möglichen Kombinationen aus Wörtern (meist
entstammt die Grundlage einem Wörterbuch) das Passwort oder aber den Namen des Benutzers
herauszufinden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 30 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
sicher sein. Dieses könnte z.B. folgendermaßen aussehen: tJ8mPü48ß{tz.
Zugegeben, dieses Kennwort ist nicht leicht zu merken, es erfordert jedoch sehr viel
Aufwand es zu knacken. Da die Gültigkeit des UNIX – Passworts keine gewisse
Gültigkeitsdauer hat, sollte das Passwort nach einer festgelegten Zeit geändert
werden. Dieser Zeitraum kann jedoch nicht verallgemeinert werden. In großen
Unternehmen ist es, im Gegensatz zu kleinen, nicht möglich, dass ein Administrator
z.B. alle drei Monate sein Kennwort ändert, da er hier nicht selten tagelang damit
beschäftigt wäre, sein Passwort zu ändern. Hier sollten größere Zeiträume (z.B. alle
sechs Monate) gewählt werden. Der Prozess zur Änderung eines Kennworts kann so
durchdacht werden, dass Administratoren z.B. jeden Monat nur einen gewissen Teil
ihrer Passwörter ändern müssen, womit sich der Gesamtaufwand besser verteilt.
Ein Problem, dass bei großen Unternehmen und somit in der Praxis leider nur sehr
schwer zu korrigieren ist, ist die Tatsache, dass Benutzer für unterschiedliche
Systeme oft das gleiche Passwort verwenden. Ist also ein Passwort bekannt, so sind
gleich mehrere Passwörter bekannt. Bei bspw. 800 wartbaren Servern, würde ein
Administrator jedoch 800 verschiedene Kennwörter benötigen und somit kennen
müssen. Hier sollte zumindest durch Vorgaben versucht werden, bestimmte
Passwortkonventionen, wie z.B. ein zwölf Zeichen langes Passwort, zu erzwingen. Als
Kompromiss könnten auch Konventionen eingesetzt werden, die auf verschiedenen
Systemen, z.B. Passwörter erlauben, die bis auf eine Stelle gleich sind. Die jeweils
erste Stelle eines Kennworts könnte z.B. eine feste und bekannte Nummer einer IP –
Adresse eines jeweiligen Servers beinhalten. Bei kleineren Unternehmen und
Organisationen sollte jedoch darauf geachtet werden, dass bei verschiedenen
Systemen auch immer verschiedene Passwörter eingesetzt werden.
Für das Betriebssystem, wie auch später das Datenbanksystem, sollten mehrere
Administratoren eingetragen werden. Sollte ein Administrator aus irgendeinem Grund
ausfallen oder aber aufgrund eines neuen, für ihn unangenehmen, Abteilungsleiters
zur Gefahrenquelle werden, gibt es weitere Administratoren, die die Arbeit
übernehmen können. Es versteht sich von selbst, dass die Datenbankadministratoren
und die Betriebssystemadministratoren unterschiedliche Personen sein sollen.
Je nach Größe des Unternehmens und Möglichkeit der Umsetzung, sollte folgende
Umgebung geschaffen werden um Administratoren eine unrechte Arbeitsweise zu
erschweren:
•
Überwachung der Aufgaben eines Administrators.
•
Kontrolle von Skripten bevor sie eingespielt und ausgeführt werden.
•
Prozesse so gestalten, dass sie nur zu zweit ausgeführt werden
können.
•
Unterschiedliche
verteilen.
•
Nur die für die Aufgaben unbedingt notwendigen Berechtigungen
vergeben.
Aufgaben
an
unterschiedliche
Administratoren
Benötigt ein Benutzer, z.B. zur Einspielung eines Patches des Datenbanksystems,
kurzzeitig Administrationsrechte am Betriebssystem, so empfiehlt sich hierfür die
Verwendung des von UNIX zur Verfügung gestellten und in der Praxis etablierten
Befehls sudo. Mit diesem Befehl kann bestimmten Usern, z.B. zum Aufruf eines
Programms, das der Berechtigung eines Root – Benutzers bedarf, Berechtigungen für
explizit genannte Programme vergeben werden. Hierfür müssen die jeweiligen
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 31 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Informationen in der Datei /etc/sudoers hinterlegt werden60.
Bei größeren Unternehmen ist es, aufgrund von erheblichen, zusätzlichen Kosten und
einer zunehmenden Reaktionszeit, leider oft nicht möglich alle der genannten
Überwachungsinstanzen einzuführen. Hier sollte, nach eingehender Analyse der
Arbeitsprozesse, ein wirtschaftlicher Kompromiss zwischen Sicherheit und Kosten
bzw. Reaktionszeit erreicht werden.
5.3.3.
UNIX – Benutzer und deren Passwörter
Da UNIX ein Multiuser – System ist, erlaubt dieses System mehrere Benutzer
anzulegen um diese bei der Anmeldung zu authentifizieren. Während der Erstellung
muss dem Benutzer weiterhin ein Passwort zugewiesen werden. Zusätzlich können
Gruppen61 erstellt werden, um den Benutzern gemeinsame Berechtigungen
zuzuweisen. Benutzer können mehreren Gruppen zugeordnet sein, jedoch kann eine
Gruppe selbst kein Mitglied einer anderen Gruppe sein.
Standardmäßig werden unter UNIX erstellte Benutzer und deren Kennwörter in einer
Benutzerliste, in der Datei /etc/passwd, gespeichert. Diese Datei ist von allen
Benutzern des UNIX – Systems lesbar, jedoch nur vom Root – Benutzer editierbar.
Die Kennwörter sind in dieser Datei als Kennwort – Hashes abgelegt, die durch
Einwegfunktionen, wie dem MD5 Message Digest – Algorithmus62 generiert wurden.
Gruppen werden ebenfalls in einer solchen Datei abgelegt. Die Liste der Gruppen,
inkl. Kennwort – Hashes, wird in einem ähnlichen Format in der Datei /etc/groups
gespeichert.
Jemand, der sich nun auf seinem Rechner anhand einer Wortliste und des gleichen
Algorithmus, ebenfalls Kennwort – Hashes genieren lässt, kann diese vergleichen und
somit ein unsicheres Passwort innerhalb von Minuten knacken.
Dies wurde bei den meisten Systemen behoben, indem die Hashes in die Datei
/etc/shadow verschoben wurden. Für Gruppen wurde dies durch eine Verschiebung
in /etc/gshadow gelöst. Das besondere daran ist, dass nur noch das administrative
Konto Lesezugriff auf die Dateien hat.
Um die Kennwörter zu schützen, sollte die Aktivierung dieser Option kontrolliert
werden. Indem der Administrator den Befehl pwconv ausführt werden alle Kennwort
– Hashes, aus der Datei /etc/passwd entfernt und in /etc/shadow geschrieben. Für
Gruppen erfolgt die Verschiebung in /etc/gshadow anhand des Befehls grpconv.
5.3.4.
Auditing
Als letzten separaten Punkt soll das Auditing erwähnt werden. Es dient dazu die
Aktivitäten auf dem Betriebssystem detailliert zu protokollieren. Auf IBM – AIX
erfolgt die Speicherung der Protokollierungen in den Verzeichnissen /var/log und
/var/adm. Standardmäßig hat jeder Benutzer Leserechte auf die darin enthaltenen
60
61
62
Vgl. [Michael 2002]
Unter UNIX ist eine Gruppe eine Liste von Benutzern.
Es handelt sich hierbei um eine kryptographische Hash – Funktion, die einen Hash – Wert von 128 Bit
erzeugt. Dieser Wert wird in der Datei passwd als 32 stelliger Hexadezimal – Wert abgespeichert.
Unter den meisten UNIX – Systemen kann man den Befehl „md5sum <zu hashender Wert>“ zur
Erstellung eines Hash – Wertes verwenden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 32 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Dateien. Auch wenn die Dateien für einen Laien nur schwer zu analysieren sind,
sollte die Leseberechtigung entzogen werden.
Die Protokolldateien sollten häufig nach unbekannten oder nicht autorisierten IP –
Adressen sowie nach ungewöhnlichen Aktivitäten, wie Port – Scans63 durchsucht
werden.
Um die Protokollierungen vor unberechtigten Lesezugriffen zu schützen, können die
Dateien auch an einem anderen Ort gespeichert werden. Die Änderung bzw. Angabe
dieses Ortes erfolgt in der Datei /etc/syslog.conf.
Das Auditing ist zwar wichtig, benötigt aber auch einen zusätzlichen Overhead. Je
mehr mitprotokolliert wird, desto mehr Performance geht verloren. Es sollte also
auch hier nicht alles und jeder nur erdenkliche Befehl protokolliert werden.
5.3.5.
Sonstige Sicherheitsaspekte
Erwähnenswert ist die simpelste Absicherung. Der entsprechende Server sollte in
einem sicheren Serverraum untergebracht sein. Ziel ist es, dass der Server gegen
menschliche und höhere Gewalt geschützt ist. In der Praxis gibt es sogar Fälle, in
denen der Serverraum gegen schwere Waffen, wie z.B. Raketenwerfer geschützt ist.
Weiterhin sollte gründlich überlegt werden, ob ein Remote – Zugriff für Benutzer des
Betriebssystems notwendig ist. Um eine Fernwartung zu ermöglichen, sollte maximal
den Administratoren ein solcher Zugriff gewährt werden. Denn, wenn dies keinem
Benutzer gestattet ist, kann auch niemand sonst versuchen, sich über Remote –
Zugriff auf dem System einzuloggen.
Ebenfalls sollten alle Netzwerkdienste, die nicht benötigt werden, deaktiviert werden.
Läuft auf dem Betriebssystem nur das Oracle – Datenbanksystem, so sollten lediglich
die Dienste, die im Zusammenhang mit Oracle benötigt werden, genutzt werden. Die
Dienste werden i.d.R. beim Starten des Betriebssystems gestartet. Die dafür
verantwortlichen Skripte liegen in den Verzeichnissen /etc/rc2.d und /etc/rc3.d.
Ein weiterer wichtiger Teil in der Absicherung des Betriebssystems besteht, wie
schon in vorigen Abschnitten erwähnt, in der Einspielung von Patches. Es sollten
regelmäßig Newsgroups64 und in Bezug zu IBM – AIX die Homepage von IBM65
durchforstet werden, um das System mit entsprechenden Patches sicher zu halten.
Als letzter Punkt soll darauf hingewiesen werden, dass auf dem Betriebssystem nur
die Software eingespielt werden sollte, die auch wirklich auf dem System benötigt
wird. Jegliche Software, die mit IBM ausgeliefert, aber nicht benötigt wird, sollte
entfernt werden, denn jede zusätzliche Software bietet mögliche Bugs sowie einen
weiteren neuen Einstiegspunkt in das System und somit ein weiteres
Sicherheitsrisiko.
63
64
65
Bei einem Port – Scan untersucht ein Programm die Ports des Betriebssystems und protokolliert,
welche Ports offen und welche geschlossen sind.
Einer der bekanntesten Newsgroups zu sicherheitsrelevanten Themen von UNIX und anderen
Systemen, ist die folgende Homepage:
http://www.securityfocus.com, 12.07.2008
Patches zur Einspielung von IBM – AIX erhält man über den Link:
http://www-933.ibm.com/eserver/support/fixes/fixcentral/pseriesfixpackdetails/5300-07-00-0747,
12.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 33 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
5.4.
Der Anfang zur Sicherung des Oracle –
Datenbanksystems
Da Oracle das am verbreiteten, relationale Datenbanksystem weltweit ist, ist es nicht
schwer zu erahnen, dass der Fokus, gerade was Sicherheitslücken angeht, genau auf
diesem DBS liegen. Einerseits entsteht hierdurch ein positiver Nebeneffekt. Oracle
selbst ist sehr darum bemüht so viele Sicherheitslücken wie möglich auszumerzen.
Andererseits werden durch die Fokussierung auch immer neue Sicherheitslücken
aufgedeckt.
Die Sicherheitslücken sind im Umfang eines Datenbanksystems enthalten und
werden kostenlos mitgeliefert. Auch wenn Oracle in den letzten Jahren bereits viele
dieser Sicherheitslücken ausgemerzt hat, bleiben diese Lücken oft, gerade bei älteren
Installationen, bestehen. Oracle ist im Ausmerzen von diesen Problemen nicht
gerade schnell. Nachdem eine Sicherheitslücke bekannt wurde, dauert es
durchschnittlich 1,5 Jahre bis zur Veröffentlichung eines Patches66. Leider führen oft
fehlerhafte Konfigurationen des Datenbanksystems dazu, dass Sicherheitslücken als
Angriffspunkt benutzt werden können.
Deshalb soll dieser Abschnitt dazu dienen entstandene Lücken vor, während und
nach der Installation zu schließen, um das Betriebssystem sowie das
Datenbanksystem von Beginn an zu schützen.
5.4.1.
Oracle – Gruppen und Benutzer unter UNIX
Bevor Oracle auf dem Betriebssystem installiert wird, sind einige Regeln zu beachten
um die Datenbank sowie das Betriebssystem ein Stück sicherer zu machen.
Oracle selbst rät aus Sicherheitsgründen dazu verschiedene Gruppen bzw. Benutzer
anzulegen um das Datenbanksystem auf dem Betriebssystem zu installieren bzw. zu
administrieren. So empfiehlt Oracle auf UNIX – Betriebssystemebene z.B. die
Erstellung einer Gruppe namens oinstall, welche dazu dient die Datenbank auf dem
System zu installieren. Weiterhin wird dazu geraten eine Benutzergruppe namens
dba zu erstellen. Diese gilt als Synonym für Datenbankadministratoren und dient
dazu, das DBS später zu administrieren. Zum Schluss sei erwähnt, dass ein User mit
dem Benutzernamen oracle angelegt werden sollte, der als Eigentümer bzw.
Installateur der Software fungiert.
Da die Erstellung der Benutzer bzw. Gruppen von Oracle empfohlen wird, lässt sich
daraus folgern, dass diese Informationen noch weiteren Menschen bekannt sind. Hat
nun einer dieser Menschen schlechte Absichten und möchte sich zudem noch Zugang
zum Betriebssystem verschaffen, so versucht dieser sich auf dem UNIX –
Betriebssystem mit solchen Benutzern anzumelden. Aus Sicherheitsgründen sollten
die angelegten Benutzer mit sehr starken Kennwörtern geschützt werden. Auch hier
sollte die Verwendung eines zwölf Zeichen langen Passworts genügen.
66
Siehe http://www.red-database-security.com/wp/oracle_sicherheit_dt.pdf, 10.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 34 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
5.4.2.
Zusätzliche Oracle – Features
Je größer ein System wird, desto mehr zusätzliche Softwarepakete werden mit jeder
neuen Version ausgeliefert. Dies ist von dem größten Hersteller für Client –
Betriebssysteme, von dem Betriebssystem IBM – AIX und natürlich auch vom
Datenbanksystem Oracle bekannt.
Die Installation des Oracle – Datenbanksystems kann auf verschiedenen Wegen
erfolgen. Der Nutzer hat die Möglichkeit mit Binary – Files oder den GUI – Tools
Oracle Universal Installer (OUI) bzw. Database Creation Assistent (DBCA) das
Datenbanksystem zu erstellen. Mit dem OUI ist es neben der Konfiguration des
Betriebssystems weiterhin möglich unerwünschte Softwarepakete aus dem
Installationsprozess auszuschließen67.
Die in der Praxis gängige Methode das Datenbanksystem sowie die Datenbanken
anzulegen erfolgt mit Hilfe der Binary – Files. Datenbankadministratoren wählen
diese Methode u.a. deshalb, weil mit Verwendung des DBCA unsichere Datenbanken
entstehen können. Wird z.B. die Version 10.2.0.1 und danach der Patch zur Version
10.2.0.4 installiert, so entsteht eine unsichere Datenbankinstallation, da der DBCA
nicht die Version 10.2.0.4 komplett über die erste Version installiert sondern beide
Versionen miteinander vermischt.
Oracle bietet, mit Auslieferung der Version 11g, drei verschiedene Versionen an. Von
der Standard – Edition One, die für kleine Unternehmen und Organisationen gedacht
ist, bis hin zur Enterprise – Edition, die für große Unternehmen geeignet ist. Je nach
Version liefert Oracle verschiedene Softwarekomponenten und Optionen mit aus68.
Weiterhin bietet Oracle, in der Version 10g, die Express – Edition, welche eine
kostenlose Einsteiger – Version ist, an. Was hier jedoch ein sehr unschöner Aspekt
ist, ist die Tatsache, dass Oracle hierfür keinerlei Sicherheits – Patches anbietet.
Anhand der Sicherheitslücken, die in dieser Arbeit noch erwähnt werden, kann die
Speicherung von wichtigen bzw. sensiblen Daten, hierfür nicht empfohlen werden.
Nachfolgende Tabelle gibt einen Überblick über bekannte, zusätzlich ausgelieferte
Komponenten bzw. Optionen der Enterprise – Edition sowie deren Nützlichkeit:
Softwarepaket
Erläuterung
Oracle Locator
Hierbei handelt es sich um insgesamt vier Komponenten die
mitinstalliert
und
Oracle Spatial
werden.
Sinn
dieser
Komponenten
ist
die
Verarbeitung und Handhabung räumlicher Daten, die z.B. für
Geographische
Informationssysteme
(GIS)
oder
CAD
–
69
Anwendungen genutzt werden .
Wird die Verarbeitung dieser Daten nicht zwingend benötigt,
sollte vorerst auf deren Installation verzichtet werden.
67
68
69
Nähere Informationen zu dem Oracle Universal Installer und dem Database Creation Assistent findet
man unter: [Bryla et al. 2007] Seite 689 ff.
Eine Auflistung über die von Oracle derzeit zur Verfügung gestellten Versionen findet man unter:
http://www.oracle.com/database/product_editions.html, 20.09.2008.
Vgl. http://www.oracle.com/lang/de/database/spatial.html, 19.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 35 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Oracle Real
Bei dieser Option wird die Datenbank von mehreren Rechnern
Application
angesteuert. Mindestens zwei Rechner greifen dabei auf dieselben
Clusters (RAC)
Datenbankdateien (parallel) zu. D.h. beide Rechner arbeiten
immer mit. Fällt nun ein Rechner aus oder ist überlastet, so kann
der zweite Rechner die Ansteuerung der Datenbank übernehmen.
Ziel ist eine höhere Skalierbarkeit und Ausfallsicherheit70.
Es handelt sich hierbei um eine sehr gute Option, die Datenbank
immer lauffähig zu halten. Dies kann gerade bei der Betreibung
von Online – Shops sehr hilfreich sein.
Oracle Online
Mittels
dieser
Optionen
besteht
die
Möglichkeit
die
Daten
Analytical
innerhalb der Datenbank, nicht nur für den Datenbankentwickler,
Processing
aufbereitet und strukturiert darzustellen. Ziel ist z.B. eine
Auswertung der enthaltenen Daten in eine verständliche Form.
und
Oracle Data
Mining
Hier spielt die schnelle Umwandlung von Daten in Informationen,
z.B. für die Geschäftsleitung, eine große Rolle. Somit kann z.B.
der Datenbankentwickler oder aber, früher oder später, die
Geschäftsleitung
selbst,
auf
die
Datenbank
zugreifen
und
71
Auswertungen erstellen .
Da
hieraus
die
Möglichkeit
erwächst,
dass
z.B.
die
Geschäftsleitung direkt auf den Datenbestand zugreifen kann,
liegt es auf der Hand, dass daraus früher oder später ein
Sicherheitsrisiko entstehen kann. Insofern sollte man auch die
Nutzung bzw. Installation dieser
Komponenten überdenken.
Solange die Nutzung nicht zwingend erforderlich wird, kann der
Datenbankentwickler in klassischer Weise SQL – Statements
absetzen und die Ergebnisse für die Geschäftsleitung aufbereiten.
Oracle
Oracle Multimedia war vor Version 11g unter dem Namen Oracle
Multimedia
interMedia bekannt. Es handelt sich hierbei um eine Komponente,
die dazu dient, alle gängigen Formate von Multimediadaten zu
speichern und zu verwalten. Die Daten werden in Binary Large
70
71
Vgl. http://www.oracle.com/database/rac_home.html, 19.07.2008
Vgl. http://www.oracle.com/lang/de/collateral/downloads/ORACLE_OLAP10g.pdf, 20.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 36 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Objects (BLOB) und Binary File Large Objects (BFILE) innerhalb
bzw. außerhalb der Datenbank gespeichert72.
Diese Komponente ist dann geeignet, wenn z.B. für einen Online
– Shop multimediale Dateien innerhalb der
Datenbank zu
speichern sind oder aber auf diese referenziert wird. Wird diese
Art der Datenverarbeitung nicht benötigt, so sollte auf diese
Komponente
gänzlich
verzichtet
werden.
Allein
durch
die
Verwendung von BFILE’s besteht ein Risiko dadurch, dass die
Datenbank auf eine Datei außerhalb des Datenbanksystems
referenziert.
Oracle Text
Diese Komponente ermöglicht das Suchen und Analysieren von
Texten innerhalb der Datenbank. Diese Suche wird mittels
Realisierung einer Volltextsuche ermöglicht. Um bestimmte Texte
zu finden, besteht u.a. die Möglichkeit, die Texte in mehreren
Tabellen gleichzeitig zu suchen73.
Dies ist natürlich nur ein kleiner Ausschnitt der Aufgabenvielfalt
dieser Komponente. Jedoch geht daraus hervor, dass diese
Komponente nur dann benötigt wird, wenn viele textlastige
Dateninhalte in der Datenbank verwendet werden. Falls dies nicht
zutrifft sollte das Datenbanksystem erstmal ohne Oracle Text
installiert werden.
Oracle
Mit Hilfe des
Oracle
Enterprise Managers
lassen sich alle
Enterprise
Anwendungen innerhalb des Datenbanksystems mittels einer
Manager
einheitlichen Konsole überwachen und auch in Bezug auf das
eingesetzte Betriebssystem managen74.
und
Oracle Grid
Control
Dieses
sehr
mächtige
Tool
ermöglicht
gerade
den
Datenbankadministratoren eine überschaubare Möglichkeit, die
Datenbank
zu
administrieren.
Bei
großen
Mengen
von
Datenbanken (über 500) besteht hierin oft die einzige Möglichkeit
diese ordentlich zu verwalten. Jedoch liegt der Schwachpunkt
darin, dass es viele Schnittstellen beinhaltet, die den Weg zu
72
73
74
Vgl. http://www.oracle.com/technology/products/intermedia/index.html, 20.07.2008
Vgl. http://www.oracle.com/technology/products/text/index.html, 20.07.2008
Vgl. http://www.oracle.com/lang/de/enterprise_manager/index.html, 20.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 37 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
anderen, externen Anbietern erleichtern soll. Da zusätzliche
Schnittstellen Schwachpunkte in der Sicherheit darstellen, sollte
man dies beim Einsatz bedenken.
Oracle Grid Control ist der Nachfolger des Oracle Enterprise
Manager, als eigenständige Webanwendung. Aus Gründen der
Abwärtskompatibilität
bietet
Oracle
jedoch
beide
Tools
zur
Administration der Datenbank an.
Tabelle 5-2 Zusätzliche Oracle – Softwarekomponenten (Quelle: selbst erstellt)
Generell kann gesagt werden, dass jede zusätzliche Komponente, die von Oracle
ausgeliefert wird, ihre Nützlichkeit besitzt. Jedoch sollte immer bedacht werden, dass
jede zusätzliche Software das Datenbanksystem angreifbarer macht. Daher sollte vor
der Installation der Datenbank genau überlegt werden, welche zusätzlichen Pakete
zu installieren sind und welche nicht. Generell sollte eher weniger installiert werden.
Zusätzlich benötigte Komponenten können später immer noch dazu installiert
werden. Dies kann jedoch, bei gepatchten Datenbanksystemen, zu Inkonsistenzen
und Problemen führen.
Nicht alle der eben erwähnten Komponenten und Optionen lassen sich während der
Installation ausschließen bzw. hinzufügen. D.h. dass sie in den Installationsprozess
bereits fest integriert sind. Das Vorhandensein dieser Komponenten sollte daher
überprüft werden. Sie sind ggf. wieder zu deinstallieren.
Die genannten Komponenten sind längst nicht alle, die mit dem Oracle
Datenbanksystem 11g ausgeliefert werden. Jedoch sollte es sich hierbei auch nur um
eine Ansammlung von wichtigen Optionen und den daraus resultierenden
Softwarekomponenten handeln75.
5.4.3.
Standardbenutzer und deren Passwörter
Je nachdem, welche Datenbank – Version, welche Softwarekomponenten oder aber
welche Skripte im Anschluss bzw. während der Installation des Datenbanksystems
ausgeführt werden, entstehen innerhalb der Datenbank eine Menge an
Datenbankbenutzern76 und damit zusammenhängende Schemas, von dessen
Existenz während des Installationsprozesses gar nichts bekannt wird.
Die Existenz dieser Benutzer wird während dem Installationsprozess erst seit
Erscheinen der Version 10g ersichtlich. Denn hier wird während der Installation nach
den Initialpasswörtern gefragt, die diesen Benutzern zugewiesen werden sollen.
Verfügt man jedoch noch über eine ältere Oracle – Version, so kann mancher
Datenbankadministrator schon mal ins Staunen geraten, wenn er entdeckt welche
Benutzer sich auf dem Datenbanksystem angesammelt haben, ohne dass einer von
diesen Benutzern selbst angelegt wurde.
75
76
Eine Auflistung aller Optionen und Softwarekomponenten, die mit Oracle 11g ausgeliefert werden
erhält man auf nachfolgender Webseite:
http://www.aspicon.de/oracle_datenbank/docs/Oracle_11g_Datenbank_Produkteditionen_und_Featur
es_v1-1.pdf, 18.07.2008
Auch Datenbankaccounts genannt.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 38 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Zu vielen zusätzlich ausgelieferten Komponenten legt Oracle einen User in dem
Datenbanksystem an, der für die Administration und Verwaltung dieser Komponente
verantwortlich ist. Im Oracle – Umfeld werden diese Benutzer auch Standardbenutzer
genannt. Nachfolgende Tabelle zeigt typische Standardbenutzer und deren
Passwörter:
Benutzer
Initialpasswort
Erläuterung
SCOTT
TIGER
Wohl einer der berühmtesten Benutzer
unter Oracle. Er wird, seit Oracle 9i,
immer erst dann erstellt, wenn die
Oracle – Beispiel – Datenbank
mitinstalliert wird. Bis zur Version Oracle
8i wurde dieser User standardmäßig auf
dem Datenbanksystem installiert.
SYS
CHANGE_ON_INSTALL
Neben SYSTEM gehört dieses
Benutzerkonto zu denen der
Datenbankadministratoren.
SYSTEM
MANAGER
Ebenfalls ein Konto, das zur
Administration der Datenbank benutzt
wird.
SYSMAN
CHANGE_ON_INSTALL
Der Administrationsbenutzer für den
Oracle Enterprise Manager.
DBSNMP
DBSNMP
Mit diesem Benutzerkonto steuert das
Datenbanksystem Zugriffe aus dem
Oracle Enterprise Manager.
MDSYS
MDSYS
Dieser User dient zur Administration der
Komponenten Oracle Spatial und Oracle
Locator.
OLAPSYS
MANAGER
Er wird standardmäßig zur Verwaltung
der Komponente Oracle Online Analytical
Processing installiert.
LBACSYS
LBACSYS
Sicherheitsoptionen der
Sicherheitskomponente Oracle Label
Security (siehe Abschnitt 5-6-2) lassen
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 39 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
sich mit diesem Benutzer verwalten und
erstellen.
CTXSYS
CTXSYS
Die Komponenten Oracle Text und Oracle
Multimedia werden mit diesem Konto
administriert.
Tabelle 5-3 Standardbenutzer und deren Passwörter (Quelle:
http://www.petefinnigan.com/default/oracle_default_passwords.htm, 21.07.2008)
Die Tabelle 5-3 zeigt nur einen kleinen Ausschnitt von standardmäßig erstellten
Benutzern. Je nach Version und Komponente können die Benutzervielfalt und die
damit verwendeten Initialpasswörter abweichen. Hier hilft ein Blick auf die Homepage
von Pete Finnigan (http://www.petefinnigan.com, 21.07.2008). Dieser besitzt eine
sehr gute Übersicht zu den von Oracle verwendeten Benutzern und deren
Passwörter.
Das Problem dieser Benutzer liegt nicht nur in deren Existenz, sondern auch an der
Tatsache, dass viele dieser Benutzer Rechte im Datenbanksystem besitzen, die
einem Datenbankadministrator ähnlich sind. Weiterhin kennt jeder Cracker, der sich
in eine Datenbank einhacken will, die von Oracle standardmäßig verwendeten
Benutzernamen und deren Initialpasswörter. Somit wird ein erster Angriffsversuch
auf eine Oracle – Datenbank damit beginnen, sich mit einem dieser Benutzer und
deren bekannten Kennwörtern einzuloggen.
Falls also solch ein bekanntes Benutzerkonto in der Datenbank existiert, so sollten
diese Benutzer neue Benutzernamen bzw. neue Schemas mit neuen, sicheren
Passwörtern erhalten. Jedoch ist zu beachten, dass die Benutzer SYS und SYSTEM
nicht gelöscht werden dürfen. Würde z.B. der Benutzer SYS gelöscht werden, so
könnte der Datenbankserver nicht mehr gestartet werden.
Eine Liste der Benutzer, die Standardpasswörter verwenden, wird seit Erscheinen der
Version 11g durch Ausführung des nachfolgenden SQL – Befehls ausgegeben:
SELECT * FROM dba_users_with_defpwd; 77
Diese von Oracle verwendete View zum Auslesen dieser Benutzer hat nun aber
wieder den Nachteil, dass ein Benutzer, der das Recht hat, diese View zu lesen,
direkt weiß, welche Standardbenutzer auf der Datenbank existent sind.
5.5.
Innere Absicherung des Oracle – Datenbanksystems
Die innere Absicherung in einem Oracle – Datenbanksystem ist das Fundament für
einen sicheren und organisatorisch kontrollierten Ablauf in einer Oracle – Datenbank.
Je nach Größe der Institution, in der die Datenbank eingesetzt wird, kann sich eine
Vielzahl von Benutzern auf der Datenbank tummeln, die es zu verwalten gilt.
Die Typen aller Datenbankbenutzer kann grob in drei Kategorien eingeteilt werden.
Die erste Kategorie sind die Applikationsbenutzer. Sie arbeiten letztlich mit den in
einer Datenbank enthaltenen Daten. Sie bilden i.d.R. die größte Gruppe der
77
Vgl. http://www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/11gsecurity.html, 20.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 40 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Datenbankuser. Zu ihnen kann man auch Web – User zählen, die über das Internet
auf die Datenbank zugreifen. Weiterhin gibt es die Datenbank- bzw.
Anwendungsentwickler, Programmierer oder auch Schema – Owner. Ihre Aufgaben
beinhaltet z.B. das Modellieren der Datenmodelle, das Schreiben von PL/SQL –
Programmen oder Datenbanktriggern sowie das Absetzen von Abfragen über SQL.
Letztlich
existieren
natürlich
noch
die
bereits
mehrfach
erwähnten
Datenbankadministratoren, die man horizontal in Applikationsadministratoren und
übrigen
Administratoren
sowie
vertikal
in
Entwicklungsbzw.
Produktionsadministratoren unterteilen kann. Sie bilden die kleinste Gruppe des
Datenbanksystems und verwalten bzw. sichern das gesamte Datenbanksystem (vgl.
Tabelle 5-1).
Die drei beschriebenen Kategorien und deren Häufigkeit des Auftretens sind stark
von der Verwendung der Datenbank und der Größe des Unternehmens bzw. der
Organisation abhängig, weshalb man keine allgemeine Aussage über deren jeweilige
Größe treffen kann. Benutzt man z.B. die Datenbank hauptsächlich fürs Internet und
zur Schulung von Studenten sind andere Applikationsbenutzer bzw. mehr Web – User
notwendig, als wenn die Datenbank zur Verwaltung von Versicherungsdaten in einem
großen Versicherungsunternehmen verwendet wird.
5.5.1.
Benutzer – Authentifizierung
Der Zugriff auf das Oracle – Datenbanksystem erfolgt über zuvor eingerichtete
Benutzerkonten. Mit der Kombination aus Benutzername und Benutzerpasswort
identifiziert sich der jeweilige Benutzer an der Datenbank. Der Benutzer zur
Administration der Datenbank ist das Benutzerkonto SYSTEM. Mit Hilfe dieses Kontos
lassen
sich
weitere
Datenbankadministratoren
sowie
Entwickler
und
Applikationsbenutzer anlegen.
Die Entscheidung ob der Benutzer der Datenbank ein Entwickler oder
Applikationsbenutzer wird, fällt letztlich der DBA indem er dem anzulegenden
Benutzer z.B. Tablespace78 in der Datenbank zuweist mit dem dieser arbeiten kann.
Die Applikationsuser verfügen über kein eigenes Schema, in denen Objekte
existieren. Die Entwickler hingegen verfügen auch über Schemas und somit über
eigene Objekte verschiedener Objekttypen, wie z.B. Tabellen, PL/SQL – Packages,
Procedures, Views usw.
Der Datenbankadministrator legt einen Datenbankbenutzer mit nachfolgendem SQL
– Statement an, der entweder mit Hilfe eines SQL – Editors oder des Oracle
Enterprise Managers erfolgen kann:
CREATE USER v_username
IDENTIFIED BY v_password
DEFAULT TABLESPACE v_tablespace
TEMPORARY TABLESPACE v_tmp_tablespace
QUOTA v_size ON v_tablespace
PROFILE DEFAULT
PASSWORD EXPIRE
78
Unter Tablespace versteht man den Plattenplatz, der einem Benutzer zugewiesen werden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 41 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
ACCOUNT UNLOCK; 79
In diesem Fall wird ein Account mit dem in der Variablen v_username angegebenen
Passwort angelegt. Der Benutzername kann eine maximale Länge von 30 Zeichen
enthalten. Hier sollte man die maximale Länge möglichst ausnutzen und Namen
verwenden, die durch keine Brute – Force – Attacke bedroht werden können. In
einem zweiten Schritt wird das Initialpasswort vergeben80. Dieses sollte, auch wenn
es nur einmalig Verwendung findet, von Benutzer zu Benutzer verschieden sein. Mit
den Parametern PASSWORD EXPIRE gibt der DBA an, dass das Passwort nach
erstmaliger Verbindung zur Datenbank vom Benutzer geändert werden muss.
Anhand der Tablespace – Parameter entscheidet der DBA, ob es sich um einen
Programmierer oder Applikationsuser handelt. Denn ohne diese Parameter hätte der
Benutzer keine Berechtigung, Objekte innerhalb der Datenbank zu speichern und
würde somit auch nicht über ein eigenes Datenbankschema verfügen. ACCOUNT
UNLOCK bedeutet hierbei, dass das Benutzerkonto nicht gesperrt ist und somit
verwendet werden kann. Diese Einstellung ist in Oracle 11g standardmäßig gesetzt,
so dass dies nicht gesondert angegeben werden muss. Auf die Parameter PROFILE
DEFAULT wird in Abschnitt 5-5-4 näher eingegangen.
Anhand des beispielhaften SQL – Statements ist erkennbar, dass die Erstellung der
verschiedenen Datenbankbenutzer in SQL – Skripten hinterlegt werden sollte. Somit
haben die Datenbankadministratoren immer einheitliche Skripte zur Erstellung von
Benutzern zur Verfügung und können die einzelnen Übergabevariablen der Skripte,
wie z.B. v_username oder v_password entsprechend setzen. Weiterhin haben sie
während der Datenbankkontrolle die Möglichkeit besser einzusehen, ob die Benutzer,
durch die von ihnen verwendeten Skripte erstellt wurden.
5.5.2.
Benutzerberechtigungen
Nachdem ein Benutzer erstellt wurde und er die Möglichkeit hat, sich an dem
Datenbanksystem zu authentifizieren, geht es bei den Benutzerberechtigungen
darum zu prüfen, ob der Benutzer autorisiert ist, bestimmte Aktionen innerhalb der
Datenbank durchzuführen. Dies bezeichnet man auch als Autorisierungsprüfung der
Datenbank. Hierbei wird u.a. überprüft, ob der angemeldete Benutzer das Recht hat,
bestimmte Objekte, wie z.B. Tabellen, zu lesen.
Je nach Benutzertyp benötigt der jeweilige Benutzer verschiedene Berechtigungen.
Oracle
unterscheidet
hier
zwischen
Objektund
Systemberechtigungen.
Objektberechtigungen81 dienen dazu, auf bereits bestehende Objekte, wie Tabellen,
Views oder Sequences zuzugreifen. Die meisten Systemberechtigungen82 hingegen
sind dazu gedacht, Objekte in einer Datenbank verwalten zu können. Dazu zählt z.B.
das Anlegen oder Löschen von Tabellen. Ebenso gibt es Systemberechtigungen, die
zur Verwaltung des Datenbanksystems dienen. Hierzu zählt z.B. die Möglichkeit eine
Datenbank starten und beenden zu können.
Solche Berechtigungen können für einen Benutzer erstellt und auch wieder entzogen
werden. Nachdem ein Benutzer angelegt wurde, benötigt er zunächst die
79
80
81
82
Vgl. [Bryla et al. 2007] Seite 310 ff.
Seit Oracle 11g ist es möglich, bei der Wahl von Kennwörtern, entweder eine maximale Länge von 30
oder optional 50 Zeichen zu wählen.
Objektberechtigungen gehören zur Data Manipulation Language und Data Query Language.
Systemberechtigungen gehören zur Data Definition Language und Data Administration Language.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 42 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Systemberechtigung sich mit der Datenbank verbinden zu dürfen, wie nachfolgender
SQL – Befehl zeigt:
GRANT CREATE SESSION
TO v_username;
Ein Applikationsbenutzer benötigt i.d.R. nur Objektberechtigungen. Diese dienen ihm
dazu bestimmte Views oder Zeilen bzw. Spalten einer bestimmten Tabelle lesen,
einzufügen oder auch löschen zu können. Möchte man diesem Benutzer das Recht
erteilen auf eine bestimmte Tabelle lesend und aktualisierend zuzugreifen, so setzt
der Datenbankadministrator nachfolgenden Befehl ab:
GRANT INSERT, SELECT
ON v_table
TO v_username;
Die Tabelle v_table ist hierbei das Objekt und die Parameter INSERT und SELECT
sind die zu vergebenden Objektberechtigungen.
Der Entwickler benötigt nicht nur das Recht, Tabellen selektieren zu können, sondern
auch Applikationen, d.h. Prozeduren, Funktionen oder PL/SQL – Packages schreiben
zu können. Er benötigt auch Systemberechtigungen. Die Rechtevergabe hierfür
könnte folgendermaßen aussehen:
GRANT CREATE PROCEDURE
TO v_username;
In dem angegeben Beispiel hat der Benutzer v_username das Recht in seinem
eigenen Schema Prozeduren zu erstellen. In größeren Organisationen ist es oft
erforderlich, dass Datenbankentwickler Prozeduren in anderen Schemas erstellen
müssen. Hierfür könnte die Berechtigung CREATE ANY PROCEDURE vergeben
werden. Dies führt jedoch zu einer unsicheren Arbeitsweise, weil der Entwickler somit
in allen anderen Schemas Prozeduren schreiben kann. Nun sollte der Programmierer
entweder nur für das benötigte Schema die Berechtigung zum Schreiben von
Prozeduren erhalten oder aber das Einspielen einer Prozedur in einem anderen
Schema sollte durch die Administratoren erfolgen.
Weiterhin ist es möglich, Berechtigungen zu erteilen, die der jeweilige Benutzer dann
an andere Benutzer weitergeben kann. Zu diesem Zweck stellt Oracle die
Schlüsselwörter
WITH_GRANT_OPTION83
und
WITH_ADMIN_OPTION84
zur
Verfügung. Während das Statement
GRANT INSERT
ON v_table
TO v_username
WITH_GRANT_OPTION;
dem Benutzer v_username erlaubt, das INSERT – Recht an der Tabelle v_table auch
an andere Benutzer weiterzugeben, so erlaubt der Befehl
GRANT CREATE TABLE
83
84
WITH_GRANT_OPTION dient dazu, dass der Benutzer bestimmte Objektberechtigungen, wie INSERT
und DELETE an andere Benutzer weitergeben darf.
WITH_ADMIN_OPTION dient dazu, dass der Benutzer bestimmte Systemberechtigungen wie CREATE
TABLE oder CREATE SESSION weitergeben darf.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 43 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
TO v_username
WITH_ADMIN_OPTION;
dass der Benutzer v_username das CREATE TABLE – Recht ebenfalls an andere
Benutzer weitergeben darf. Wie unschwer zu erkennen ist, sollten diese
Berechtigungen Benutzern erst gar nicht erteilt werden, denn bei näherer
Betrachtung kann hiermit viel Unfug angerichtet werden. Anhand der
WITH_GRANT_OPTION können u.U. viele Benutzer Berechtigungen erteilt
bekommen, die sie nicht benötigen bzw. nicht haben sollen. Mit der
WITH_ADMIN_OPTION sind die erteilten Berechtigungen evtl. nicht mehr so schnell
rückgängig zu machen. Erhält z.B. der Benutzer v_username_1 die CREATE TABLE –
Berechtigung als WITH_ADMIN_OPTION und gibt diese Berechtigung an
v_username_2 weiter, so behält der Benutzer v_username_2 die Berechtigung auch
dann, wenn dem Benutzer v_username_1 die CREATE TABLE – Berechtigung wieder
entzogen wird. In diesem Zusammenhang wird ersichtlich, dass dies nicht gerade
förderlich für eine sichere, leicht verwaltbare und überschaubare Datenbank ist.
Ebenfalls ist es in Oracle möglich, Berechtigungen an alle Datenbankbenutzer zu
vergeben. Hierzu erfolgt die Vergabe von Rechten nicht an einen einzigen Benutzer,
sondern an PUBLIC. Der Befehl für eine solche Objektberechtigung könnte
folgendermaßen aussehen:
GRANT SELECT
ON v_table
TO PUBLIC;
Hierbei sollte beachtet werden, dass die SELECT – Berechtigung an der Tabelle
v_table nicht nur an alle bestehenden Benutzer, sondern auch an Benutzer, die
zukünftig an der Datenbank erstellt werden, weitergegeben wird. Da es i.d.R. keine
Tabelle im Datenbanksystem gibt, die wirklich für jeden lesbar sein muss, sollten
Berechtigungsvergaben, die an PUBLIC erteilt werden, unbedingt vermieden werden.
In Versionen vor Oracle 8i besitzt der Datenbankbenutzer PUBLIC sogar die CREATE
EXTERNAL JOB – Berechtigung, womit es möglich ist, externe Jobs zu erstellen.
Selbst Oracle empfiehlt, dieses Recht dem Benutzer PUBLIC zu entziehen und nur
den Datenbankadministratoren zuzuweisen85.
Nachfolgende Tabelle zeigt eine kleine Auswahl
Systemberechtigungen:
von typischen Objekt- und
Berechtigungstyp
Berechtigung
Erläuterung
SYSTEM
CREATE
Ermöglicht einem Benutzer sich mit der
SESSION
Datenbank zu verbinden.
CREATE TABLE
Erlaubt dem Benutzer eigene Tabellen zu
SYSTEM
erstellen.
SYSTEM
85
CREATE USER
Dient zur Erstellung eines Benutzerkontos.
Siehe http://download.oracle.com/docs/cd/B28359_01/server.111/b28337.pdf, 20.07.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 44 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
SYSTEM
SYSDBA und
Bieten z.B. die Möglichkeit eine Datenbank
SYSOPER
anzulegen und zu verwalten86.
…
…
…
OBJEKT
SELECT
Erlaubt das Lesen von Zeilen einer View
oder einer Tabelle.
OBJEKT
UPDATE
Ermöglicht die Aktualisierung einer Tabelle
oder updatebaren View.
OBJEKT
EXECUTE
Wird dazu genutzt, um PL/SQL – Packages,
Prozeduren oder Funktionen aufzurufen.
Tabelle 5-4 Typische Objekt- und Systemberechtigungen (Quelle: [Bryla et al. 2007] Seite 324 ff.)
Es handelt sich hier nur um eine kleine Auswahl der möglichen Berechtigungen in
einer Oracle – Datenbank, welche lediglich dazu dienen, ein besseres Verständnis für
die Objekt- bzw. Systemberechtigungen zu entwickeln.
Gerade Systemberechtigungen dürfen nur mit allergrößter Sorgfalt an
Datenbankbenutzer vergeben werden. Datenbankadministratoren sollten alle
Systemberechtigungen, die an Benutzer vergeben werden, sehr genau kennen und
somit auch die möglichen Ausmaße einer solchen Vergabe immer bedenken. Eine
Berechtigung, wie SYSDBA oder SYSOPER, kann weitreichende Folgen für das
Datenbanksystem haben. Mit SYSDBA z.B. kann ein vollständiges Backup der
Datenbank durchgeführt werden. Diese Berechtigungen sollten also nur
Datenbankadministratoren vorbehalten sein.
5.5.3.
Rollen
Möchte man jedem neu angelegten Benutzer bestimmte Berechtigungen erteilen,
haben die Administratoren, je nach Menge der Datenbankbenutzer, viel
Schreibaufwand. Die Benutzererstellung und deren Berechtigungsvergabe sollten
zwar in Skripten verpackt sein, jedoch kann es hier leicht zu einer unüberschaubaren
Länge von SQL – Befehlen kommen. Im Zusammenhang mit Berechtigungen stellt
Oracle jedoch eine Möglichkeit bereit, bestimmten Benutzergruppen immer die
gleichen Berechtigungen zu erteilen, ohne dass dieses Recht jedem Benutzer einzeln
erteilt werden muss. Dies erhöht die Sicherheit der Datenbank aufgrund von immer
gleichen Berechtigungsvergaben und geschieht anhand von Rollen. Indem einem
Benutzer eine bestimmte Rolle zugewiesen wird, erhält dieser, je nach Definition der
Rolle, mit Ausführung nur eines SQL – Statements die Berechtigung, z.B. 10 Tabellen
lesen zu dürfen.
Angenommen, in einer Organisation gibt es zwei Gruppen. Die erste Gruppe sind
Applikationsbenutzer, die nur auf Tabellen, die Buchhaltungsdaten enthalten, lesend
und aktualisierend zugreifen müssen. Die zweite Gruppe sind Applikationsuser, die
nur Tabellen, die Personaldaten enthalten, bearbeiten müssen. Nun müsste jedem
86
Vgl. [Bryla et al. 2007] Seite 325
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 45 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
neuen Datenbankbenutzer die entsprechenden Berechtigungen für jede einzelne
Tabelle der Personaldaten bzw. der Buchhaltungsdaten erteilt werden. Kommt
zusätzlich eine Tabelle hinzu, müsste jeder User der jeweiligen Gruppe die
Berechtigung erteilt bekommen, auf die neue Tabelle zugreifen zu dürfen. Bei Rollen
hingegen werden die Berechtigungen auf die entsprechenden Tabellen nur der
jeweiligen Rolle zugewiesen und diese Rolle dem jeweiligen Datenbankbenutzer
vergeben. Kommt nun eine Tabelle hinzu, so erhält die Rolle die Berechtigung, auf
die Tabelle zugreifen zu dürfen und somit erhält auch jeder Datenbankbenutzer, dem
diese Rolle zugewiesen wurde, das Recht auf die Tabelle zuzugreifen.
Neben dem minimierten Aufwand für Datenbankadministratoren ist die Sicherheit
natürlich ein weiterer Aspekt zur Verwendung von Rollen. In unserem Falle, würde,
nach Auswahl einer entsprechenden Nomenklatur, immer eine direkte Übersicht
welche Datenbankuser auf welche Objekte zugreifen dürfen, ersichtlich. Käme es z.B.
zu einem Sicherheitsvorfall, in dem Personaldaten manipuliert worden wären, so
könnte auf einen Schlag den Datenbankbenutzern der Personaldaten die UPDATE –
Berechtigung entzogen werden, in dem dieses Recht einfach der Rolle entzogen wird.
Bei Einrichtung einer Rolle für Buchhaltungs- und Personaldaten, könnten die SQL –
Befehle hierzu folgendermaßen aussehen:
CREATE ROLE eu_sel_tbl_personal;
CREATE ROLE eu_sel_tbl_bookkeeping;
Die Definition der ersten Rolle soll dazu dienen, Applikationsbenutzern das SELECT –
Recht an den Tabellen der Personaldaten zu geben. Die zweite Rolle ist analog zur
ersten Rolle zu verstehen, jedoch sollen hierin die SELECT – Berechtigungen an den
Buchhaltungstabellen verankert werden.
Die Zuweisung der einzelnen SELECT – Berechtigungen erfolgt nun nicht mehr an
den Applikationsuser sondern direkt an die Rolle.
GRANT SELECT
ON personal_table_1
TO eu_sel_tbl_personal;
GRANT SELECT
ON personal_table_2
TO eu_sel_tbl_personal;
Eine Zuweisung der erwähnten Rolle an den einzelnen Datenbankbenutzer erfolgt
nun mit folgendem SQL – Statement:
GRANT eu_sel_tbl_personal
TO personal_user;
Weiterhin ist es möglich, Rollen ineinander zu verschachteln. Beispielsweise kann
eine weitere Rolle eu_ins_tbl_personal, die für INSERT – Berechtigungen zuständig
ist, angelegt werden. Diese Rolle und die Rolle eu_sel_tbl_personal könnte, nach
vorheriger Definition der Rolle eu_sel_ins_tbl_personal, dieser zugewiesen werden.
GRANT eu_sel_tbl_personal, eu_ins_tbl_personal
TO eu_sel_ins_tbl_personal;
Neben der Rollenzuweisung bietet Oracle ebenfalls die Möglichkeit, Rollen mit
Passwörtern zu versehen. Somit kann eine Rolle einem Benutzer zugewiesen werden,
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 46 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
dieser kann aber erst dann über das Recht verfügen, wenn er sich die Rolle mit dem
versehenen Passwort selbst setzt. Eine Rolle mit Passwort wird folgendermaßen
definiert:
CREATE ROLE eu_del_tbl_personal
IDENTIFIED BY password;
Möchte der Datenbankbenutzer nun die Rolle eu_del_tbl_personal nutzen, so gibt er
folgenden Befehl ein:
SET ROLE eu_del_tbl_personal
IDENTIFIED BY password;
Im angegebenen Beispiel wäre es möglich, dass den Applikationsbenutzern, die auf
die Personaldaten zugreifen, z.B. eine gesamte Personalabteilung, die Rollen
eu_sel_tbl_personal, eu_ins_tbl_personal und eu_del_tbl_personal zugewiesen
wurden, jedoch nur der Abteilungsleiter der Personalabteilung die Rolle
eu_del_tbl_personal setzen darf. Das vergebene Passwort könnte dabei z.B. in einer
Forms – Maske hinterlegt sein. Versucht der Benutzer personal_leader nun einen
Datensatz zu löschen, so könnte die Forms – Maske explizit für diesen User das
Kennwort setzen. Diese Vergabe von Rollen kann eine Datenbank durch die
Einsparung von Rollen übersichtlicher und somit auch sicherer machen, da weniger
Rollen vergeben werden müssen.
Rollen können nicht nur selbst definiert werden. Auch Oracle liefert bereits einige
vordefinierte Rollen mit aus. Einige, bekannte Rollen sind in nachfolgender Tabelle
erläutert:
Rolle
Erläuterung
CONNECT
Diese Rolle sollte lt. Oracle an allgemeine Datenbankbenutzer vergeben
werden.
Hat ein Benutzer, seit Oracle 10g (Release 2), diese Rolle, so besitzt er
die CREATE SESSION – Berechtigung. Bis zu Oracle 10g (Release 1)
jedoch, wurden diesem Benutzer weiterhin Berechtigungen, wie ALTER
SESSION, CREATE VIEW und CREATE DATABASE LINK 87 zugewiesen.
RESOURCE
Hier handelt es sich, lt. Oracle, um eine Rolle für übliche Entwickler.
Systemberechtigungen wie CREATE TABLE und CREATE PROCEDURE
sind hierin verankert.
DBA
Dies ist eine verschachtelte Rolle. In diesem Fall sind in ihr sieben
weitere Rollen enthalten, die auch den Datenbankadministratoren SYS
87
Mit CREATE DATABASE LINK ist es möglich, auf ein entferntes Datenbanksystem zuzugreifen und von
dort Daten auszulesen. Dabei muss es sich nicht um ein Oracle – Datenbanksystem handeln. Jedoch
ist hierfür die Installation von heterougenous Services Voraussetzung, die im Rahmen von Oracle
Gateway kostenintensiv erworben werden kann.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 47 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
und SYSTEM zugewiesen sind.
Beispielrollen die zu der Rolle DBA gehören sind IMP_FULL_DATABASE,
EXP_FULL_DATABASE, SELECT_CATALOG_ROLE und
EXECUTE_CATALOG_ROLE.
Insgesamt enthält dies Rolle 114 Systemberechtigungen88.
SELECT_
CATALOG_
ROLE
Mit dieser Rolle wird die Berechtigung gewährt, auf jede Tabelle bzw.
jede View der DATA DICTIONARY89 zuzugreifen.
Bekannte Views der DATA DICTIONARY sind dba_users, all_users,
all_roles oder dba_sys_privs90.
EXECUTE_
Diese Rolle beinhaltet Systemberechtigungen auf die DATA
CATALOG_
DICTIONARY und somit auch das Datenbankschema SYS.
ROLE
Enthaltene Berechtigungen ermöglichen z.B. ausführbare Rechte an
PL/SQL – Packages und Prozeduren der DATA DICTIONARY.
Tabelle 5-5 Bekannte von Oracle vordefinierte Rollen (Quelle: [Bryla et al. 2007] Seite 332 ff.)
Nun, dass die Vergabe der Rolle DBA ein Sicherheitsrisiko ist, muss man nicht mal
erwähnen. Da den Datenbankadministrationskonten SYS und SYSTEM die Rolle DBA
zugewiesen ist, ist es ein leichtes, sich vorzustellen welche weitreichenden Folgen es
haben kann, wenn ein Datenbankbenutzer diese Rolle sein eigen nennt. Neben den
bereits
vorgestellten
Rollen,
wie
EXECUTE_CATALOG_ROLE
und
SELECT_CATALOG_ROLE
bedeuten
die
Rollen
IMP_FULL_DATABASE
und
91
EXP_FULL_DATABASE , dass der Benutzer eine Datenbank komplett importieren
bzw. extrahieren kann.
Ebenfalls besitzt die Rolle CONNECT für allgemeine Datenbankbenutzer, die sich auf
einem Datenbanksystem vor Oracle 10g (Release 1) anmelden, zu viele
Berechtigungen, die solch ein Benutzer nicht benötigt.
Wie schon im Abschnitt zuvor erwähnt, dürfen jedem Benutzer nur die minimal
notwendigen Rollen und damit verbundene Berechtigungen erteilt werden. Gerade in
Bezug auf Sicherheit sollte, aufgrund des eingesparten Arbeitsaufwandes, eine
bestimmte Rolle nicht jedem nur erdenklichen Benutzer zugewiesen werden. Auch
wenn vielleicht 90%, der in der Rolle angegebenen Berechtigungen, auf den
Benutzer zutreffen, ist es eher sinnvoll, einige Rollen mehr zu definieren, dafür aber
auch eine genaue, 100%ige Abstufung und Einteilung der vergebenen
Berechtigungen an die jeweiligen Benutzer zu erreichen.
88
89
90
91
Vgl. [Newman et al. 2004] Seite 274
Die DATA DICTIONARY enthält alle Informationen über den Inhalt der Datenbank. Es enthält
Metadaten, also Informationen über die enthaltenen Daten. Z.B. welche Objekte existieren, wer hat
sie angelegt, welche Rollen existieren in der Datenbank, wem sind sie zugewiesen usw. Die DATA
DICTIONARY befindet sich im Schema des Datenbankbenutzers SYS.
Weitere Informationen zu bekannten Views des DATA DICTIONARY finden sich im Abschnitt 5-5-7.
EXP_FULL_DATABASE enthält weiterhin die Rollen SELECT_CATALOG_ROLE und
EXECUTE_CATALOG_ROLE sowie weitreichende Systemberechtigungen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 48 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Weiterhin sollten, aufgrund der Vermeidung von Fehleranfälligkeit und
Verwaltungsaufwand, die Berechtigungs- und Rollenvergaben pro Benutzer in SQL –
Skripten verpackt werden, die wiederum mit entsprechenden Übergabeparametern
angesteuert werden.
Ebenfalls ist, wie in diesem Abschnitt bereits erwähnt, die Nomenklatur zur Vergabe
von Rollennamen, richtig zu wählen. Datenbankadministratoren sollten auch Wochen
später direkt erkennen können, welche Rolle für welche Datenbankbenutzer, welche
Objekte und welche Berechtigung gedacht ist.
5.5.4.
Datenbankautorisierung durch das DEFAULT – Profil
Nach der Anmeldung eines Benutzers an der Datenbank, erfolgen neben den eben
erwähnten Autorisierungsprüfungen, weitere Sicherheits- und Systemprüfungen. In
diesem Zusammenhang wird auf den in Abschnitt 5-5-1, während der Benutzer –
Authentifizierung, erwähnten Parameter PROFILE DEFAULT eingegangen.
Ein Profil dient in Bezug auf Sicherheit dazu, bestimmte Autorisierungsmaßnamen für
den Benutzer festzulegen. Mit dem DEFAULT – Profil werden eine Menge von
Parametern gesetzt bzw. Funktionen ausgeführt. Mit Hilfe des nachfolgenden SQL –
Befehls, der die View dba_profiles ausliest, kann man sich die Parameter bzw.
Funktionen anzeigen lassen, die im DEFAULT – Profil aktiviert sind:
SELECT * FROM dba_profiles WHERE profile = ‘DEFAULT’;
Nachfolgend angegebene Tabelle gibt einen Einblick in die Ausgabe des vorigen SQL
– Befehls:
PROFILE
RESOURCE_NAME
RESOURCE
LIMIT
DEFAULT
SESSIONS_PER_USER
KERNEL
UNLIMITED
DEFAULT
CPU_PER_SESSION
KERNEL
UNLIMITED
DEFAULT
CONNECT_TIME
KERNEL
UNLIMITED
DEFAULT
PRIVATE_SGA
KERNEL
UNLIMITED
DEFAULT
IDLE_TIME
KERNEL
UNLIMITED
…
…
…
…
DEFAULT
FAILED_LOGIN_ATTEMPS
PASSWORD
10
DEFAULT
PASSWORD_LIFE_TIME
PASSWORD
180
DEFAULT
PASSWORD_REUSE_TIME
PASSWORD
UNLIMITED
DEFAULT
PASSWORD_REUSE_MAX
PASSWORD
UNLIMITED
DEFAULT
PASSWORD_VERIFY_FUNCTION
PASSWORD
NULL
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 49 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
DEFAULT
PASSWORD_LOCK_TIME
PASSWORD
1
DEFAULT
PASSWORD_GRACE_TIME
PASSWORD
7
Tabelle 5-6 Ein Ausschnitt der View dba_profiles (Quelle: [Bryla et al. 2007] Seite 316)
In der Spalte PROFILE ist der selektierte Profilname zu erkennen. Unter
RESOURCE_NAME sind die Ressourcenparameter zu finden, also die gültigen
Ressourcenbeschränkungen.
Die
Spalte
RESOURCE
gibt
an,
welche
Ressourceneinstellungen zum Tragen kommen. Im Falle DEFAULT für das System
KERNEL und die Passwortverwaltung PASSWORD. In der Spalte LIMIT ist die
jeweilige Beschränkung zu erkennen.
Wie unschwer zu erkennen ist, sind viele Werte auf UNLIMITED, NULL oder auf zu
hohe Werte gesetzt. Dies sollte umgehend geändert werden. Um nun Profil –
Änderungen durchführen zu können, erfolgt nachstehend eine Erläuterung der
einzelnen, wichtigsten Ressourcenparameter:
Ressourcenparameter
Erläuterung
SESSIONS_PER_USER
Hier ist die Maximalanzahl von Sitzungen angegeben,
die ein Benutzer an der Datenbank gleichzeitig halten
kann.
Um einen Missbrauch auszuschließen sollte dieser Wert
von UNLIMITED auf eins gesetzt werden.
CONNECT_TIME
Der Benutzer darf nur bis zu dieser Zeitangabe in
Minuten am System angemeldet bleiben. Danach muss
er sich erneut verbinden.
Je nach Benutzertyp kann es hier erforderlich sein eine
große Zahl anzugeben. Ein Programmierer könnte u.U.
ein Skript laufen lassen, das auch über Nacht läuft.
Somit wären hier evtl. 1440 (Minutenanzahl / Tag)
angemessen. Ein reiner Applikationsbenutzer hingegen
benötigt z.B. nur 480 (Minutenanzahl / 8 Stunden), da
sein Arbeitstag maximal acht Stunden fasst und er nur
diese Zeit an der Datenbank angemeldet sein muss.
IDLE_TIME
Nach einer Inaktivität des Datenbankbenutzers von
IDLE_TIME – Minuten muss sich dieser User erneut mit
der Datenbank verbinden.
Es reicht i.d.R. eine Maximalanzahl von 15 (Minuten)
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 50 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
aus. Wobei es hier natürlich auch Unterschiede geben
kann.
FAILED_LOGIN_ATTEMPS
Die Anzahl der Anmeldeversuche, die fehlschlagen
kann, bevor das Benutzerkonto gesperrt wird und
danach wieder von einem DBA entsperrt werden muss.
Diese ist mit 10 viel zu schwach angegeben und sollte
auf eine angemessene Zahl herabgesenkt werden.
PASSWORD_LIFE_TIME
In Tagen wird angegeben, wie lange das Kennwort
seine Gültigkeit behält.
Je nach Verwendungszweck der Datenbank und Menge
der eingesetzten Datenbanken sind 180 Tage zu lang.
Zwischen
30
und
60
Tage
reichen
bei
kleineren
Unternehmen oder Organisationen vollkommen aus. Bei
größeren Unternehmen kann die Zahl, wie schon in
Abschnitt 5-3-3 erwähnt, entsprechend erhöht werden.
PASSWORD_REUSE_TIME
Anzahl der Tage, die ein Benutzer warten muss, bis
dieser
ein
bereits
verwendetes
Passwort
wieder
verwenden darf.
PASSWORD_REUSE_MAX
Passwort
–
Änderungen,
nach
denen
ein
bereits
verwendetes Kennwort wieder genutzt werden darf.
PASSWORD_LOCK_TIME
Wurde
ein
Benutzerkonto
aufgrund
von
FAILED_LOGIN_ATTEMPS gesperrt, so besteht hier die
Möglichkeit, dieses Konto, nach einer angegebenen
Anzahl von Tagen, automatisch wieder zu entsperren.
Da der Benutzer bei drei fehlgeschlagenen Versuchen
sein
Passwort
Parameter
i.d.R.
auf
gewährleistet
vergessen
UNLIMITED
eine
bessere
hat,
gesetzt
sollte
werden.
Kontrolle
über
dieser
Dies
evtl.
Angriffsversuche und die Administratoren müssen das
Datenbankkonto
vor
der
nächsten
Verwendung
zurücksetzen.
PASSWORD_GRACE_TIME
Eine Art Galgenfrist, die dem Benutzer, nach Ablauf von
PASSWORD_LIFE_TIME,
gewährt
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
wird
um
sein
Seite 51 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Kennwort zurückzusetzen.
Hier sollte eine eher kurze Frist von drei bis sieben
Tagen gelten. Innerhalb dieser Frist könnte der User via
E-Mail aufgefordert werden, sein Passwort zu ändern.
Somit würde nur der eigentliche Benutzer von der
anstehenden
Änderung
des
Kennworts
informiert
werden und es bliebe ihm noch etwas Zeit, diese
Änderung durchzuführen.
PASSWORD_VERIFY_FUNC
Dieser Parameter steht für einen Funktionsaufruf, um
TION
eine
bestimmte
Sicherheitspolitik
durchzusetzen.
Standardmäßig ist dieser Wert auf NULL gesetzt, was
bedeutet, dass keine Funktion ausgeführt wird.
Tabelle 5-7 Wichtige Profil – Ressourcenparameter (Quelle: Vgl. [Bryla et al. 2007] Seite 317 ff.)
Werden
die
Ressourcenparameter
PASSWORD_REUSE_TIME
und
PASSWORD_REUSE_MAX auf UNLIMITED gesetzt, können bereits benutzte
Kennwörter sofort nach Ablauf wieder verwendet werden. Um eine direkte
Wiederverwendung des Passworts auszuschließen, sollte der Ressourcenparameter
PASSWORD_REUSE_TIME gesetzt werden. Dieser Wert sollte, angegeben in Tagen,
über zwei oder gar drei Perioden, in denen ein Passwort geändert werden muss,
anhalten. In diesem Fall bezieht man sich auf PASSWORD_LIFE_TIME und setzt den
Wert des Parameters auf eine dreimal höhere Zahl. Dies ermöglicht dem
Datenbankbenutzer, sein altes Passwort, nach dreimaliger Verwendung eines
anderen Kennworts, wieder zu verwenden. Würde PASSWORD_REUSE_MAX gesetzt,
so könnte ein hartnäckiger User sein Kennwort auf einmal so lange ändern, bis er
wieder die Möglichkeit hat, sein altes Passwort zu setzen.
Der wichtigste Ressourcenparameter ist PASSWORD_VERIFY_FUNCTION. Dieser Wert
ist zwar standardmäßig auf NULL gesetzt, jedoch liefert Oracle 11g ein SQL –
Skript92, das diesen Wert auf verify_function_11g setzt. Es handelt sich hierbei um
eine Funktion, die bei Ausführung des Skripts utlpwdmg.sql, welches sich im
Betriebssystemverzeichnis $ORACLE_HOME/rdbms/admin befindet, angelegt wird
und danach bei jeder Erstellung eines Benutzers mit dem DEFAULT – Profil
ausgeführt wird. Mit Hilfe dieses Skripts werden, neben der Erstellung der Funktion,
die auf die Ressource PASSWORD bezogenen Ressourcenparameter neu gesetzt. Da
diese Parametereinstellungen normalerweise nicht ausreichen, kann das Skript
utlpwdmg.sql, den eigenen Wünschen entsprechend, angepasst werden. Ebenfalls
kann auch die Funktion verify_function_11g den eigenen, sicherheitspolitischen
Regeln, angepasst werden. Dies ist auch notwendig, denn hierin wird z.B. nur eine
maximale Passwortlänge von vier Zeichen erzwungen, was für heutige Ansprüche viel
zu wenig ist. Weitere Maßnahmen dieser Funktion sind u.a., dass sich das alte und
das neue Kennwort durch mind. drei Zeichen unterscheiden muss und das Passwort
sowie der Benutzername nicht gleich sein dürfen. Die in der Datenbank abgelegte
Funktion sollte des Öfteren auf Anomalien überprüft werden. Falls sich ein Angreifer
92
Dieses SQL – Skript wurde bereits seit Oracle 9i, entsprechend angepasst, ausgeliefert.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 52 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Zugang zu der Funktion verschaffen kann, so könnte es sein, dass dieser die
Funktion so anpasst, dass z.B. das vergebene Passwort eines Benutzers irgendwo
abgelegt wird und der Angreifer somit Benutzername und Passwort des neuen
Benutzers kennt.
Es ist auch möglich, eigene Funktionen und auch eigene Profile zu erstellen. Ein
Punkt, der dafür sprechen würde, wäre z.B., dass das DEFAULT – Profil möglichen
Angreifern bekannt ist und diese Angriffe entwickeln, die sich an gesetzte
Parameterwerte des Standardprofils anlehnen.
In Bezug auf die vorher gemachten Angaben kann mit nachfolgend angegebenem
SQL – Statement auch ein eigenes Profil erstellt werden:
CREATE PROFILE v_profilname LIMIT
SESSIONS_PER_USER
1
CONNECT_TIME
480
IDLE_TIME
15
FAILED_LOGIN_ATTEMPS
3
PASSWORD_LIFE_TIME
30
PASSWORD_LOCK_TIME
UNLIMITED
PASSWORD_REUSE_TIME
90
PASSWORD_REUSE_MAX
UNLIMITED
PASSWORD_GRACE_TIME
3
PASSWORD_VERIFY_FUNCTION
v_verify_function_11g;
Werden im eigenen Profil Angaben, die im DEFAULT – Profil enthalten sind,
weggelassen, so übernimmt Oracle bei der Anlage von Benutzern die Werte der
Ressourcenparameter, die im DEFAULT – Profil angegeben sind. Wird bei der
Benutzeranlage weiterhin das Standardprofil benutzt, so können, mit nachfolgendem
SQL – Befehl, die entsprechenden Werte des Profils geändert werden:
ALTER PROFILE DEFAULT LIMIT
PASSWORD_VERIFY_FUNCTION
v_my_verify_function;
Es ist jedoch nicht möglich, das Standardprofil DEFAULT zu löschen.
5.5.5.
Benutzerpasswörter
Wie schon in den Abschnitten 5-3-2 und 5-4-3 angedeutet, sind Passwörter sehr
starke
und
bewährte
Schutzmechanismen.
Auch
in
Betrachtung
der
Datenbankbenutzer sind diese die wichtigsten Authentifizierungsmethoden. Da
jedoch viele Hacker bzw. Cracker versuchen, mittels den bekannten Brute – Force –
Attacken in Systeme einzudringen, sollte noch mal auf die richtige Verwendung der
Kennwörter eingegangen werden.
Vor allem den Datenbankbenutzern sollte plausibel erläutert werden, wie wichtig die
richtige Wahl eines starken Kennworts ist. Wenn nur einer von 1000 möglichen
Datenbankbenutzern ein schwaches Passwort gewählt hat, ist es bei einer
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 53 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
hartnäckigen Attacke ein leichtes, sich auf der Datenbank anzumelden.
Mit dem Freewaretool Checkpwd93 des Unternehmens Red – Database – Security
GmbH, ist es möglich, die Passwörter seines Oracle – Datenbanksystems prüfen zu
lassen. Weiterhin bietet das Unternehmen die Software Repscan94 an. Diese
ermöglicht neben der Passwortprüfung einen kompletten Sicherheitscheck des Oracle
– Datenbanksystems. Lt. des Unternehmens prüft das Programm Repscan ca.
600.000 Kennwörter pro Sekunde95 und benötigt 10 Sekunden zur Berechnung von
5 Zeichen96 langen Passwörtern und bis zu 4 Jahre zur Berechnung eines 10 Zeichen
langen Passwortes. An diesem Beispiel ist zu erkennen, wie wichtig es ist, im
Datenbanksystem nur die Verwendung von Kennwörtern mit einer gewissen
Mindestlänge zuzulassen. Die Verwendung von zwölf Zeichen langen Passwörtern
sollte die Datenbank vor möglichen Attacken halbwegs sicher machen. Wie schon im
vorigen Abschnitt erwähnt, kann mittels der PASSWORD_VERIFY_FUNCTION die
Komplexität der Kennwortwahl vorgeben und die Mindestlänge für einen
Datenbankbenutzer hierin verankert werden.
Weitere wichtige Hinweise zur Verwendung von Passwörtern sind:
•
Keine Verwendung von trivialen Passwörtern. Eine Kombination aus
Groß- und Kleinbuchstaben (erst seit Version 11g möglich) sowie
Zahlen und Sonderzeichen sollten Verwendung finden.
•
Kennwörter, die aus einem einfachen Algorithmus zu bilden sind, wie
z.B. eine Kombination aus Benutzername und Jahreszahl oder eine
Kombination aus Zeichen, die auf einer Tastatur nebeneinander liegen,
sind zu vermeiden.
•
Keine Verwendung von Wörtern, die in Wörterbuchern zu finden sind.
•
In Bezug auf innere Angriffe, sollten Passwörter keinen erkennbaren
Bezug zum Benutzer oder dessen Umgebung haben (Z.B. Geburtstag
oder Automarke).
Diese Vorgaben können nicht alle in einer vorgegebenen Funktion verankert werden.
Diejenigen,
die
aufgrund
fehlender
Rechenleistung
und
eines
kaum
implementierbaren Algorithmus nicht vorgegeben werden können, sollten jedoch
mittels Schulung der Datenbankbenutzer, an diese weitergegeben werden.
Oracle benutzt in der Version 11g zur Verschlüsselung des Kennworts den SHA-197 –
Algorithmus. Der Algorithmus zur Erstellung dieses Hash – Wertes wurde bereits
200598 allgemein und die Implementierung in Oracle 11g im Jahre 200799 geknackt.
Dieser Umstand ist jedoch keine direkte Sicherheitslücke, da der bekannte
Algorithmus erstmal durchlaufen werden muss, um den Hash – Wert eines
Passwortes herauszufinden. D.h. bei richtig gewählten Kennwörtern benötigt die
93
94
95
96
97
98
99
Siehe http://www.red-database-security.com/software/checkpwd.html, 01.08.2008
Siehe http://www.red-database-security.com/software/repscan.html, 01.08.2008
Vorausgesetzt wird ein Intel Pentium Dual – Xeon Prozessor mit einer 3 GHZ – Taktung.
Vgl. http://www.red-database-security.com/whitepaper/oracle_passwords.html, 01.08.2008
Voraussetzung ist die Verwendung des ASCII – Zeichensatzes.
SHA-1 oder Secure Hash Algorithm in der Version 1 ist eine kryptographische Hash – Funktion zur
Erstellung eines Hash – Wertes.
Siehe http://www.heise.de/security/Kryptoverfahren-SHA-1-geknackt--/news/meldung/56428,
31.07.2008
Siehe http://blog.red-database-security.de/2007/09/21/oracle-password-algorithmus-poc-code/,
02.08.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 54 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Ermittlung, wie bereits erwähnt, eine gewisse Zeit um einen möglichen Hash – Wert
zu ermitteln. Ebenfalls ist es, seit der neuen Datenbankversion, erstmals möglich
Kennwörter in Groß- und Kleinbuchstaben als Passwörter zu speichern. Vor dieser
Version wurden die Passwörter, vor der Speicherung in der Datenbank, in
Großbuchstaben umgewandelt und dann abgespeichert.
In Versionen vor Oracle 11g werden der Benutzername und das Passwort über die
DATA DICTIONARY – View dba_users, des Schemas SYS, ausgelesen. Diese View
greift auf die Tabelle user$ des gleichen Schemas zu. Seit 11g wird das Kennwort
jedoch nicht mehr in der angegebenen View angezeigt. Wird die Datenbank komplett
exportiert, so befinden sich die Passwörter aber noch in den entsprechenden Export
– Files. Sie sind ebenfalls in den entsprechenden Tablespaces auf dem
Betriebssystem zu finden.
Wenn sich ein Datenbankadministrator über das Betriebssystem mit der Datenbank
verbindet, verwendet er i.d.R., zur Authentifizierung mit der Datenbank, das von
ORAPWD100 erstellte Passwort – File. Diese Datei wird auf Betriebssystemebene
standardmäßig im Verzeichnis $ORACLE_HOME/dbs abgelegt. Es ist jedoch möglich,
während der Erstellung dieser Datei, einen eigenen Pfad anzugeben. Hier sollte
jedoch ein anderer, als der benannte Pfad gewählt werden, da dieser auch Hackern
bzw. Crackern bekannt ist. Auf die erwähnten Orte innerhalb des Betriebs- bzw.
Datenbanksystems ist, aufgrund der Wichtigkeit ihrer enthaltenen Daten,
entsprechend zu achten.
5.5.6.
Views
Um dem Sicherheitsaspekt einer View gerecht zu werden, wird in diesem Abschnitt
auf die Verwendung dieser Sichten eingegangen. Sie dienen vor allem dazu,
sicherungsbedürftige Daten, wie z.B. personenbezogene Daten zu schützen und
damit den Datenschutz, dem Organisationen unterliegen, zu unterstützen. Views
existieren im Oracle – Datenbanksystem seit der ersten Version und sind bewährte
Methoden zur Sicherung von Tabellen. Weiterhin ermöglichen sie Benutzergruppen
eine eigene Sichtweise auf Tabellenebene.
Eine View ist eine Select – Abfrage auf eine oder mehrere Tabellen, die logisch als
eine eigene Tabelle abgelegt ist. Da bei Abfragen auf die eigentlichen Tabellen der
Zugriff durch die Views so eingeschränkt werden kann, dass wichtige Spalten bzw.
Zeilen einer Tabelle nicht angezeigt werden, stellt die Verwendung einer View eine
verbesserte Sicherheit gegenüber den Datenbeständen dar.
Um eine View erstellen zu können, benötigt ein Entwickler die CREATE VIEW –
Berechtigung. Das SQL – Statement zur Erstellung einer View könnte folgendes
Aussehen haben:
CREATE VIEW v_bokkeeping_view
AS
SELECT name, surname, employee_id
FROM personal_table_1
WHERE department = ‘Buchhaltung’;
100
Mit Hilfe des von Oracle mitgelieferten Programms ORAPWD wird eine Datei erzeugt, die die
Passwörter der Datenbankadministratoren in verschlüsselter Form abspeichert und ihnen zur
Authentifizierung mit der Datenbank dient.
Vgl. [Newman et al. 2004] Seite 247
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 55 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Diese View könnte den Applikationsbenutzern der Personalabteilung, die für die
Angestellten in der Buchhaltung zuständig sind, dazu dienen, immer nur die
entsprechenden Angestellten anzuzeigen.
Dem Benutzer kann weiterhin die CREATE ANY VIEW – Berechtigung zugewiesen
werden, damit dieser die Möglichkeit hat, Views in anderen Schemas anzulegen.
Doch aus den bekannten Gründen der Sicherheit, sollte diese Einspielung einer View
den Datenbankadministratoren vorbehalten sein.
Seit der Version 7 des Oracle – Datenbanksystems, ist es auch möglich, dass
Datenbankbenutzer mit entsprechend ausreichenden Berechtigungen (INSERT,
UPDATE oder DELETE), Daten über eine View in die Tabelle einspielen können. Eine
Berechtigungsvergabe hierfür könnte folgendermaßen aussehen:
GRANT INSERT
ON v_view
TO v_username;
Vorraussetzung hierfür ist natürlich, dass derjenige auch die INSERT – Berechtigung
auf der zugrunde liegenden Tabelle besitzt. Da auch diese Arbeitsweise schnell
unübersichtlich wird und evtl. nicht mehr nachvollzogen werden kann, welcher User
welche Aktualisierungen auf der Tabelle durchgeführt hat, sollte diese
Berechtigungsvergabe außen vor bleiben.
5.5.7.
Die Datenbankbenutzer SYS und SYSTEM
Die
Datenbankadministratoren
sind
die
wichtigste
Personengruppe
im
Datenbanksystem. Ihre Aufgaben sind sehr umfangreich und vertrauensvoll, was
eine sehr genaue Auswahl von diesen Mitarbeitern voraussetzt.
Die Datenbankadministratoren arbeiten grundsätzlich mit den Konten SYS und
SYSTEM. Mit beiden können sie die Datenbank komplett verwalten. Diese werden
auch automatisch während der Installation des Datenbanksystems angelegt. Der
Benutzer SYS ist hierbei der Datenbankbenutzer, der die meisten Rechte im
Datenbanksystem hat. Er kann alle internen Objekte einer Datenbank betrachten.
Weiterhin ist er Eigentümer der DATA DICTIONARY. Beide besitzen die
Berechtigungen SYSDBA und SYSOPER101, mit denen man sich, aus dem
Betriebssystem heraus, an der Datenbank anmelden kann102, bevor der
Datenbankserver gestartet ist. Ebenfalls ist ihnen die Rolle DBA zugewiesen. Wem
die Berechtigungen SYSDBA und SYSOPER zugewiesen sind, kann mit nachfolgendem
SQL – Befehl herausgefunden werden:
SELECT * FROM v$pwfile_users;
Zur Administration der Datenbank sollten jedoch eigens erstellte Datenbankkonten
bzw. Datenbankbenutzer eingerichtet und diesen nur die, für die Administration
notwendigen Berechtigungen zugewiesen werden. Da SYS und SYSTEM jedem
Angreifer weitreichend bekannt sind, sollte sich darauf beschränkt werden,
101
102
Seit Oracle 10g besitzen diese, bei einer zuvor eingerichteten ASM – Instanz, ebenfalls die
Berechtigung SYSASM, die dazu dient diese ASM – Instanzen zu verwalten.
Vgl. [Bryla et al. 2007] Seite 302
Dies geschieht u.a. mittels des von ORAPWD erstellten Passwort – Files (Vgl. Abschnitt 5-5-5).
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 56 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Angriffsversuche über diese Benutzerkonten, im Auditing103 der Datenbank bzw. des
Betriebssystems, zu beobachten. Weiterhin kann mit eigens zugewiesenen
Berechtigungen, die i.d.R. weniger weitreichend sind, als die der benannten
Benutzer, in der Datenbank weniger Schaden angerichtet werden.
Eine der elementaren Aufgaben eines Datenbankadministrators ist die Überwachung
des Datenbanksystems. Dazu gehört der tägliche Blick in das DATA DICTIONARY.
Oracle stellt hier, wie schon erwähnt, alle Informationen, die eine einzelne
Datenbank betreffen, mittels Views zur Verfügung. Hierbei wird unterschieden
zwischen DBA – Views, die nur für die Nutzung durch den Datenbankadministrator
gedacht sind, da sie auch sicherheitsrelevante Informationen enthalten, ALL – Views,
die die gleichen Informationen wie DBA – Views enthalten, dabei aber
sicherheitsrelevante Informationen auslassen und USER – Views, die Information zu
dem Datenbankbenutzer enthalten, der gerade angemeldet ist. Einige wichtige, auf
Sicherheit bezogene Views sind in nachstehender Tabelle erläutert:
View
Erläuterung
dba_users
Diese View enthält Informationen über alle Datenbankkonten.
Enthaltene Spalten sind z.B. Benutzername, verschlüsselte
Passwörter, das Erstellungsdatum des Benutzers, den ihm
zugewiesenen Tablespace und das ihm zugewiesene Profil.
Seit Oracle 11g ist das verschlüsselte Passwort jedoch nur noch
in der Tabelle user$ zu finden.
user_history$
Passworthistorie einzelner Benutzer, falls eine der DEFAULT –
Profil – Parameter PASSWORD_REUSE_TIME bzw.
PASSWORD_REUSE_MAX, aktiviert wurde. Sie enthält Daten wie
Passwort, Benutzername und das Datum zu dem das Passwort
seine Gültigkeit hatte.
dba_sys_privs
Sie zeigt die Systemberechtigungen an, die Rollen und
Benutzerkonten zugewiesen wurden. Spalten dieser View sind
der Benutzer- bzw. Rollenname des Benutzers, dem die
Berechtigung zugewiesen wurde, die Systemberechtigung und
eine Spalte die angibt sowie ein Kennzeichen, das angibt ob die
Berechtigung mit der WITH_ADMIN_OPTION – Berechtigung
weitergegeben wurde.
dba_tab_privs
Tabellenberechtigungen, die an Rollen und Benutzer vergeben
wurden. Die Spalten umfassen den Datenbankbenutzer für den
103
Das Auditing der Datenbank wird im Abschnitt 5-6-4 näher betrachtet.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 57 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
die Berechtigung erteilt wurde, den Eigentümer der Tabelle, den
Tabellennamen, den Benutzer, der die Berechtigung ausgeführt
hat, die Berechtigung selbst sowie eine Information, die angibt,
ob die Berechtigung mit der WITH_GRANT_OPTION –
Berechtigung versehen ist und weitergegeben werden kann.
dba_roles
Diese View enthält alle Namen der Rollen einer Datenbank sowie
ein Kennzeichen, ob diese Rollen, zur Aktivierung durch den
User, ein Kennwort benötigen.
role_sys_privs
Hierin sind alle Rollen verankert, die Systemberechtigungen
enthalten. Inhalte dieser View sind der Rollenname, die
Systemberechtigung und ein Kennzeichen, das angibt, ob die
Rolle mit der WITH_ADMIN_OPTION – Berechtigung versehen
ist.
role_tab_privs
Sie enthält alle Rollen, die sich auf Tabellen- und
Spaltenberechtigungen beziehen. Enthaltene Informationen sind
der Rollenname, der Tabellenname, der Spaltenname (wenn
explizit nur für die Spalte vergeben), die Objektberechtigung
und ein Kennzeichen, welches anzeigt, ob die Rolle mit der
WITH_GRANT_OPTION – Berechtigung gekennzeichnet ist.
dba_role_privs
Enthalten sind die Namen der Rollen, die Benutzern oder
anderen Rollen zugewiesen wurden, der Name des
Datenbankbenutzers bzw. der Rolle und ein Kennzeichen, ob die
Rolle mit der WITH_ADMIN_OPTION – Berechtigung versehen
ist.
Tabelle 5-8 Wichtige DATA DICTIONARY – Views (Quellen: [Bryla et al. 2007] und [Newman et al. 2004])
Als Mindestanforderung sollten die angegebenen Views einer täglichen Kontrolle
unterzogen und auf besondere Vorkommnisse überprüft werden. Um einen gesamten
Überblick über die DATA DICTIONARY zu erhalten, sind die im Schema SYS
enthaltenen Views genau zu kennen104.
Wie schon in Abschnitt 5-1 erwähnt, sollte, damit Datenbankentwickler ihre Skripte
nicht in jedem Schema einspielen können, nur die Gruppe, der für den jeweiligen
Bereich zuständigen Administratoren, entsprechende Berechtigungen an den global
nutzbaren Objekten einer Datenbank, wie z.B. Tabellen oder PL/SQL – Packages,
erhalten.
104
Einen Überblick über alle in Oracle 11g existierenden DATA DICTIONARY – Views erhält man auf
folgender Homepage:
http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28320/toc.htm, 04.08.08
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 58 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Die übrigen Datenbankadministratoren wiederum, müssten mit den eigentlichen
Daten und Objekten innerhalb der Datenbank nicht mehr viel zu tun haben. Ihnen
obliegen
dann
mögliche
Berechtigungsvergaben
von
Systemund
Objektberechtigungen sowie die gesamte Sicherung und Überwachung des
Datenbanksystems, sowohl intern als auch extern.
Generell kann natürlich keine Aussage darüber gemacht werden, welche Gruppen in
einer Organisation zum Tragen kommen, da Anforderungen und evtl. fehlende
Mitarbeiter eine weitere Rolle spielen. Jedoch sollten die Aufgaben, der
verschiedenen, eingesetzten Administratoren miteinander verzahnt sein, um somit
eine gegenseitige und unbewusste Kontrolle zu ermöglichen.
5.6.
Sicherung mittels zusätzlicher Komponenten
Nachdem nun vieles erläutert wurde, um das Datenbanksystem von innen heraus,
mit den von Oracle standardmäßig mitgelieferten Möglichkeiten zu schützen, geht es
in diesem Abschnitt darum, das Datenbanksystem mit zusätzlichen Komponenten zu
sichern.
Der Einsatz dieser zusätzlichen Software hängt nicht minder vom Umfang des
Datenbanksystems und der darin enthaltenen Daten einer Datenbank zusammen. Je
nach Schutzbedürftigkeit der Daten, sind viele Komponenten sehr sinnvoll und
können den Zugriff auf die Daten um einiges sicherer machen. Es ist ebenfalls zu
beachten, dass jede zusätzliche Komponente einen gewissen Overhead verursacht,
der die Datenbank und Zugriffe auf die enthaltenen Daten immens verlangsamen
kann. Weiterhin sind zwei der nachstehend genannten Komponenten kostenpflichtig
und meist sehr teuer, was eine eingehende Kosten / Nutzen – Analyse voraussetzt.
Auch wenn durch deren Einsatz weitere Sicherheitslücken im Datenbanksystem
entstehen können, sollten die wichtigsten Anwendungen, die Oracle zusätzlich bietet,
um das Datenbanksystem zu schützen, bekannt sein.
5.6.1.
Oracle Virtual Private Database (VPD)
In Version 8i hat Oracle die Virtual Private Database eingeführt. Es handelt sich um
keine Option bzw. Komponente die während der Installation ausgewählt und
hinzugefügt werden kann. Sie ist in den Installationsprozess integriert und dient
dazu, eine Sicherheitspolitik direkt auf Datenebene durchzuführen.
Mit dieser Komponente ist es möglich eine Art View zu erstellen, die direkt über dem
jeweiligen Objekt, d.h. der Tabelle oder einer anderen View liegt. Während bei der
Verwendung von bekannten Views, zumindest die Datenbankentwickler den wahren
Inhalt der Tabelle, des zugrunde liegenden Objekts, sehen können, ist dies bei der
Verwendung einer VPD, nicht möglich. Die Sicherheitsmaßnahmen greifen, aus dem
Blickwinkel der Datenbankbenutzer, direkt auf View- bzw. Tabellenebene. D.h., dass
selbst die Entwickler eine eingeschränkte Sicht auf die Inhalte von Tabellen und
Views haben. Dies ist z.B. dann nützlich wenn sensible Daten, wie Gehälter etc., in
einer Tabelle abgelegt sind.
Durch Einsatz der VPD wird, bei einer Abfrage auf das jeweilige Objekt, durch
Anhängen einer WHERE – Klausel, einfach der Blick auf bestimmte Zeilen des
zugrunde liegenden Objekts verwährt. Dies wird im Oracle – Umfeld auch Row Level
Security (RLS) bzw. Fine Grained Access Control (FGAC) genannt. Die Entwickler
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 59 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
bzw. Applikationsbenutzer bekommen, bei Abfragen auf das jeweilige Objekt,
bestimmte Zeilen einfach nicht angezeigt. Mit Erscheinen von Oracle 10g, wurde die
VPD auf Spaltenebene erweitert. Nach einer abgesetzten Abfrage bekommen die
Benutzer, bei den selektierten Spalten, dabei standardmäßig nur einen NULL – Wert,
anstatt der gesicherten Information, angezeigt.
Dieser Mechanismus wird in der Datenbank mittels so genannter Policy – Funktionen
und der darin enthaltenen Schutzmaßnahmen integriert. Als Ergebnis liefern sie ein
Prädikat, die benannte WHERE – Klausel, zurück.
Sie werden meist durch die Datenbankadministratoren an- und in einem bestimmten
Schema für Sicherheitsrichtlinien abgelegt. Mit Hilfe des im Schema SYS enthaltenen
PL/SQL – Package DBMS_RLS, können von Oracle vordefinierte Funktionen bzw.
Prozeduren genutzt werden, um Sicherheitsrichtlinien einzuführen. Zur Anlage einer
zuvor erstellten Policy – Funktion wird die in DBMS_RLS enthaltene Prozedur
ADD_POLICY verwendet. Ihr werden zur Aktivierung, die in der Tabelle 5-9
enthaltenen Parameter übergeben.
Parameter
Erläuterung
OBJECT_SCHEMA
Der Datenbankbenutzer bzw. das Datenbankschema für den
die Sicherheitsrichtlinie greifen soll und welches das zu
sichernde Objekt enthält.
OBJECT_NAME
Enthält den Namen des Objekts für das die Richtlinie greifen
soll. Also den View- oder Tabellennamen.
FUNCTION_SCHEMA
Name des Schemas, das die Policy – Funktion enthält.
POLICY_FUNCTION
Name der zuvor erstellten und zu verwendeten Policy –
Funktion.
STATEMENT_TYPES
Der Geltungsbereich für den die Funktion zutrifft. Erlaubt
sind die Werte INSERT, UPDATE, DELETE und SELECT.
UPDATE_CHECK
Gibt an, ob die Policy auch bei Aktualisierungen (INSERT
und UPDATE) des Objekts ausgeführt wird.
ENABLE
Standardmäßig auf TRUE gesetzt, gibt dieser Parameter an,
ob die Policy nach Anlage über ADD_POLICY, direkt aktiviert
werden soll.
STATIC_POLICY
Ist dieser Parameter auf TRUE gesetzt, gilt die Policy –
Funktion für jeden User, der auf das Objekt zugreift.
POLICY_TYPE
Standardmäßig ist dieser Wert NULL und bedeutet, dass die
Policy immer angewendet wird und statisch ist. Eine
dynamische Policy kann mit bestimmten
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 60 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Datenbankbenutzern verknüpft und der dazugehörige
Kontext mit CREATE CONTEXT105 angelegt werden.
LONG_PREDICATE
Der enthaltene Wert ist standardmäßig FALSE und
bedeutet, dass das von der Policy – Funktion zurück
gelieferte Prädikat max. 4.000 Zeichen haben darf.
SEC_RELEVANT_COLS
Erst seit Version 10g enthalten, definiert dieser Parameter
die Spalten, für die die Policy – Funktion benutzt werden.
SEC_RELEVANT_COLS
Gibt den Wert an, der in den gesicherten Spalten, für den
_OPT
Datenbankbenutzer angezeigt wird. Dieser ist
standardmäßig mit NULL belegt.
Tabelle 5-9 Parameter der Prozedur ADD_POLICY (Quelle: [Bryla et al. 2007] Seite 345 f.)
Das Package DBMS_RLS bietet, neben der ADD_POLICY, auch Prozeduren zur
Löschung, Aktivierung und Deaktivierung sowie weitere nützliche Prozeduren zur
Verwaltung von Policies an106.
Dieser Schutz könnte u.a. für den Applikationskontext Internet von großer
Bedeutung sein. Greifen Anwender über das Internet auf eine Datenbank zu, so
könnte es u.U. mittels SQL – Injection, dazu kommen, dass die Datenbank
angegriffen wird um Daten auszulesen. Würde nun eine Sicherheitsmaßnahme der
Applikationen über der Datensicht, wie z.B. die Internetanbindung oder die PL/SQL –
Prozedur, die auf die Tabelle oder die View zugreift, ausgehebelt, so könnte der
Angreifer die gewünschten Daten trotzdem nicht auslesen, da die Sicherung direkt
mit dem Objekt, also der Tabelle bzw. View verknüpft ist. Dies würde natürlich nur
dann
helfen,
wenn
der
Angreifer
über
keine
Berechtigungen
eines
Datenbankadministrators verfügt und die VPD wieder entfernen kann. In der Praxis
ist dies jedoch eine Wunschvorstellung, da die VPD nur bei Benutzern greift, die
eindeutig zu identifizieren sind. Erfolgt eine Internetanbindung an die Datenbank, so
erfolgt der Zugriff auf die Datenbank, aufgrund mangelnder Oracle – Kenntnis der
Web – Entwickler, meist mit einem standardisierten User, der sich nicht eindeutig
identifizieren lässt, was eine solche Sicherung in diesem Kontext ausschließt.
5.6.2.
Oracle Label Security
Die Oracle Label Security ist eine zusätzliche Komponente, die ebenfalls seit Version
8i des Oracle – Datenbanksystems verfügbar ist und Zugriffe auf Zeilenebene
beschränkt. Sie basiert auf der Technologie der Virtual Private Database. Der
Unterschied zur VPD liegt hauptsächlich darin, dass keine Policy – Funktionen
programmiert und implementiert werden müssen.
105
106
Hilfreiche Beispiele zur Anlage von kontextbezogenen, dynamischen Policies sind auf folgender
Homepage enthalten:
http://www.ordix.de/ORDIXNews/2_2007/Datenbanken/fine_grained_access_control.html, 10.08.08
Weitere Informationen zur Verwendung von Policies und einer VPD findet man in:
[Bryla et al. 2007] ab Seite 339.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 61 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Die Wartung erfolgt i.d.R. über den Oracle Policy Manager, der in den Oracle
Enterprise Manager integriert ist. Hierin kann man z.B. Richtlinien erstellen, Label –
Komponenten definieren, Richtlinien an Tabellen und Schemas zuweisen, Audit –
Optionen einstellen und vieles mehr.
Als Grundlage dienen so genannte Labels. Datenbankbenutzer erhalten Labels,
ihre minimalen und maximalen Zugriffsrechte auf bestimmte Tabellen definieren.
zu sichernden Tabellen erhalten, nach Anlage im Oracle Policy Manager,
zusätzliche Spalte, ebenfalls ein Label, dass das benötigte Zugriffsrecht auf
jeweilige Zeile definiert.
die
Die
als
die
Die Vergabe der Labels basiert auf einem hierarchischen Prinzip und besteht aus drei
Teilen. Jeder dieser Teile kann bis zu 9.999 Ausprägungen beinhalten. Im ersten Teil,
den Levels, werden die Datenbankbenutzer bzw. Benutzergruppen definiert. Der
einfache Angestellte erhält z.B. das Label 1. Der Gruppenleiter erhält das Label mit
dem numerischen Wert 2 usw. Wird einem Gruppenleiter das Label 2 zugeordnet, so
hat dieser auch automatisch die Berechtigungen des Labels 1, also die des einfachen
Angestellten. Im zweiten Teil erfolgt die Definition der Compartments. Gibt es z.B.
eine Personalabteilung, die in unterschiedliche Gruppen aufgeteilt ist, so kann eine
Unterteilung der Gruppen vorgenommen und sichergestellt werden, dass jede
Gruppe nur die Angestellten anzeigen darf, die auch für sie bestimmt sind. Im dritten
Teil werden die Groups festgelegt. Groups ermöglichen die Unterteilung in
verschiedene Organisationsstrukturen. Als Unterscheidung kann hier z.B. festgelegt
werden, dass eine Gruppe in einer Personalabteilung mehr Berechtigungen hat, als
die gesamte Personalabteilung und diese wieder mehr Berechtigungen als die Gruppe
der Auszubildenden, die in dieser Personalabteilung tätig sind.
Es besteht eine Menge von Möglichkeiten bei der Verwendung von Labels. Die
Definition bedarf jedoch einer vorherigen genauen Planung um bei einer späteren
Umstrukturierung, nicht alles neu definieren zu müssen. Weiterhin benötigt dies
einen gewissen Pflegeaufwand, der schnell unübersichtlich werdenden Labels, des
Datenbestandes
und
der
Datenbankbenutzer.
Die
pflegenden
Datenbankadministratoren müssen weiterhin die Organisation und die darin
enthaltenen Geschäftsprozesse beherrschen, was natürlich nicht der Fall sein sollte,
da Administratoren für die Technik verantwortlich sind und keine fachlichen Abläufe
kennen sollten. Aufgrund dieser eher negativen Eigenschaften ist die Verwendung
einer VPD, der einer Label Security, vorzuziehen107. In Deutschland wird diese
Komponente, aufgrund der Komplexität und hohen Kosten von rund 20.000 US –
Dollar pro verwendetem Prozessor, nur von wenigen Unternehmen und nur auf
einzelnen Datenbanken eingesetzt.
5.6.3.
Oracle Data Vault
Ein Novum in der Welt der Oracle – Datenbanksysteme ist die Oracle Data Vault.
Diese mit Version 10g (Release 2) erschiene, später auf Oracle 9.2 zurückportierte
Komponente und dort unter dem Namen Oracle Database Vault bekannt, ist zwar
kostenpflichtig, d.h. nicht direkt in der Enterprise – Edition enthalten, vom ersten
Eindruck her aber sehr nützlich. Im Gegensatz zur Oracle Label Security und Oracle
Virtual Private Database schränkt diese Komponente nicht den Zugriff auf
Zeilenebene sondern direkt auf Objekt- und Befehlsebene ein, bietet jedoch die
Möglichkeit, die beiden Komponenten, inkl. ihrer Funktionalität, miteinander zu
107
Weitere Informationen zur Verwendung der Oracle Label Security findet man unter:
http://www.oracle.com/lang/de/database/label-security.html, 10.08.2008.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 62 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
verknüpfen. Um diese Komponente verwenden zu können ist jedoch der Kauf der
Oracle Label Security Voraussetzung.
Wie schon zu Beginn dieser Arbeit erwähnt, erfolgen viele Angriffe auf ein IT- bzw.
Datenbanksystem von innen heraus. Der Gruppe der Datenbankadministratoren ist
es, da diese i.d.R. die entsprechenden Berechtigungen besitzen, ein leichtes auf alle
Daten innerhalb der Datenbank zuzugreifen und diese auszulesen. Nun, da es
womöglich
auch
schwarze
Schafe
unter dieser
Gruppe
und
anderen
Datenbankanwendern mit vergleichsweise hohen Berechtigungen gibt und es nicht
unbedingt gewünscht ist, dass jeder, dieser hoch privilegierten User, alle Daten lesen
soll, hat Oracle diese Komponente entwickelt.
Es können nun Datenbankobjekte, die auch gegen Zugriffe hoch privilegierter
Benutzer geschützt werden sollen, in dem Data Vault abgelegt werden. Innerhalb
dieses Tresors können nun Regeln festgelegt werden, die autorisierten Usern die
Zugriffe auf die darin enthaltenen Informationen gewähren bzw. verweigern.
Jeglicher Datenbankbenutzer, der nicht für die jeweiligen Bereiche autorisiert ist,
kann auf die Datenbankobjekte dieser Bereiche nicht mehr zugreifen bzw. diese nicht
mehr verwalten.
Eine Menge von System- und Objektberechtigungen kann dabei mit Regeln verknüpft
und dadurch, dessen Ausführung von hoch privilegierten Benutzern, verhindert
werden. Derzeit bietet Oracle 45 dieser Datenbankbefehle zur Verknüpfung an. Hierin
sind u.a. gebräuchliche ALTER, CREATE und GRANT – Befehle enthalten. Die
Einhaltung dieser Regeln wird bei jedem Zugriff über das im Datenbanksystem
enthaltene DBMS überprüft und ggf. abgewährt. Nach der Einspielung der Data Vault
schützt die Komponente direkt verschiedene Objekte. Hierzu zählt auch der Schutz,
dass die vordefinierte Rolle DBA nicht mehr mit Ausführung des GRANT – Befehls
weitergegeben werden darf.
Weiterhin werden so genannte Realms definiert, denen jeweils eigenständige
Datenbankadministratoren zugewiesen sind. Standardmäßig werden drei Realms
angelegt bzw. verwaltet. Einer für das Benutzermanagement, ein weiterer für die
DATA DICTIONARY und einer zur Verwaltung der Data Vault.
Die Daten innerhalb der Datenbank können nun so verwaltet werden, dass z.B. ein
Schema, welches alle Personaldaten beinhaltet, einen eigenständigen DBA und ein
Schema, dass die Priorität über die Buchhaltungsdaten inne hat, einen eigens
zugewiesenen DBA erhält. Jedem dieser Administratoren können nun, innerhalb
seines Schemas, Berechtigungen zur Anlage und Verwaltung von Objekten
zugewiesen werden. Sie können jedoch keine Datenbankbenutzer anlegen. Dieses
Recht obliegt nun einzig demjenigen, der auch für den Realm des
Benutzermanagements zuständig ist.
Der Gedanke liegt nahe, dass zumindest die Datenbankadministratoren des Schemas
SYS bzw. SYSTEM, die Möglichkeit haben, die in den anderen Schemas enthaltenen
Objekte anzusehen bzw. zu verändern. Nun, obwohl jeder dieser Benutzer
weitreichende Systemberechtigungen sein Eigen nennt, gelangen sie, innerhalb der
Datenbank,
nicht
an
die
gewünschten
Informationen.
Denn
das
Datenbankmanagementsystem prüft bei jeder Abfrage auf ein Objekt, ob dieses sich
im geschützten Bereich befindet. Wird versucht auf geschützte Bereiche zuzugreifen,
fängt das DBMS diesen Versuch ab, gibt eine Fehlermeldung aus und schreibt, wenn
gewünscht, einen Eintrag in das zuschaltbare Data Vault – Auditing. Der typische
Datenbankadministrator, der alle Datenbankbenutzer und enthaltene Objekte
verwaltet, gibt es in dieser Form also nicht mehr. Zumindest nicht für die Bereiche,
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 63 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
die im Datentresor abgelegt oder über eigenständige Realms geschützt sind, denn
diese benötigen nun einen eigenen Datenbankadministrator108.
Was Oracle jedoch nicht vermarktet, sind die negativen Eigenschaften dieser
Komponente, die dazu führen, dass sie derzeit in keinem Unternehmen produktiv
eingesetzt wird. Sogar bei Oracle selbst nicht.
Allein die Tatsache, dass nun, anstatt einem Administrator, drei Administratoren
benötigt werden, erhöht die Kosten, gerade bei einer großen Menge von
Datenbanken immens. Rein theoretisch verdreifacht sich also der Personalbedarf an
Datenbankadministratoren. Kommen dann noch Urlaube und Krankheiten der
Mitarbeiter hinzu, wird noch mal eine entsprechende Anzahl an zusätzlichen
Mitarbeitern benötigt. Dies führt dazu, dass die Data Vault letztlich in Personalunion
betrieben werden muss, womit man wieder bei der eigentlichen Ursache zur
Schaffung dieser Komponente angelangt ist.
Weiterhin ist die Komponente, anhand ihres Aufbaus, kaum teamfähig. Müssen,
innerhalb der Datenbank, Fehler behoben werden, so muss nach dem Administrator
gesucht werden, der den Fehler beheben kann. Wurde dieser gefunden, so kann
hinzukommen, dass derjenige Administrator wieder auf der Suche nach anderen
Administratoren ist, die für einen anderen Teil der Fehlerbehebung zuständig sind.
Dies verursacht wieder zusätzliche Kosten, da dadurch Reaktionszeit und reine
Arbeitszeit verloren geht.
Als letzten Schwachpunkt der Data Vault, sollte erwähnt werden, dass sie nicht
gegen Angriffe aus Betriebssystemebene heraus schützt. Bei nicht verschlüsselten
Tablespaces existieren die Daten der Datenbank weiterhin gut leserlich auf dem
Betriebssystem. Ebenfalls kann ein Datenbankadministrator, der für die Interaktion
mit dem Betriebssystem verantwortlich ist, die Data Vault einfach abschalten109.
5.6.4.
Auditing
Auch wenn es sich hierbei um keine Komponente handelt, die direkt mit Sicherheit
der Daten in Zusammenhang gebracht wird, sollte das allgemeine Auditing der
Datenbank in diesem Abschnitt trotzdem Beachtung finden. Denn hiermit ist es
möglich, jegliche Angriffsversuche auf Daten, die Datenbank und das
Datenbanksystem selbst auszuwerten und darauf zu reagieren. Wissen Mitarbeiter,
dass das Auditing eingeschaltet ist, so kann dies innerhalb einer Organisation ein
hilfreiches Abschreckungsmittel für Angriffsversuche sein. Das Auditing des
Datenbanksystems Oracle bietet verschiedene Typen zur Überwachung, wobei die
gängigsten in diesem Abschnitt näher betrachtet werden.
Die typischen Protokollierungen des Auditing, können entweder in Verzeichnissen auf
dem Betriebssystem direkt oder in der datenbankeigenen Tabelle aud$ im Schema
SYS abgelegt werden. Die Abfrage der Administratoren auf die Audit – Einträge
erfolgt mit der View dba_audit_trail.
Die Initialisierungsparameter zum Einschalten des Auditing werden mit dem
108
109
Ein Whitepaper zur Oracle Data Vault findet man auf der Homepage von Oracle unter:
http://www.oracle.com/lang/de/collateral/downloads/ORACLE_White_Paper_Database_Vault.pdf,
11.08.2008.
Das Unternehmen Red – Database – Security hat weiterhin einige, schwerwiegende Sicherheitsfehler
entdeckt.
Siehe http://www.all-about-security.de/kolumnen/frage-des-monats/artikel/6555-red-databasesecurity-ein-sehr-interessantes-produkt-na/, 13.08.2008.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 64 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
AUDIT_TRAIL – Parameter in der Datei init.ora110 gesetzt. Die Datei befindet sich im
Betriebssystemverzeichnis des installierten Datenbanksystems. Nachfolgende Tabelle
zeigt die Parameterwerte und deren Funktionen:
Parameterwert
Erläuterung
NONE, FALSE
Mit diesen Werten deaktiviert man das Auditing
OS
Aktiviert das Auditing und schreibt die Datensätze
standardmäßig in das Verzeichnis
$ORACLE_HOME/rdbms/audit. Da dieses Verzeichnis
Angreifern bekannt ist, sollte das Verzeichnis geändert
werden, indem der Parameter AUDIT_FILE_DEST in der
Datei init.ora auf einen anderen Wert gesetzt wird.
DB, TRUE
Aktiviert ebenfalls das Auditing. Sendet die Datensätze
jedoch an die Tabelle aud$ im Schema SYS.
XML
Speicherung der Daten im XML – Format.
DB_EXTENDED
Entspricht dem Parameter DB. Jedoch werden zusätzlich die
Spalten sqlbind und sqltext, innerhalb der Tabelle aud$,
gefüllt.
Tabelle 5-10 Parameter AUDIT_TRAIL der Datei init.ora (Quelle: [Bryla et al. 2007] Seite 358 f.)
Ein Typ zur Überwachung von Ereignissen innerhalb der Datenbank ist das
Anweisungs – Auditing. Mit dessen Hilfe können alle möglichen SQL – Statements,
die von einem, einigen bestimmten oder von allen Datenbankbenutzern durchgeführt
wurden, protokolliert werden (z.B. abgesetzte SELECT, INSERT oder UPDATE –
Befehle). Weiterhin das Berechtigungs – Auditing, mit dessen Hilfe, die Vergabe von
Systemberechtigungen überprüft wird (z.B. abgesetzte ALTER, CREATE und GRANT –
Befehle). Mit dem dritten Typ, dem Schemaobjekt – Auditing können Anweisungen,
die auf ein bestimmtes oder mehrere Objekte, innerhalb eines bestimmten Schemas
abzielen, überprüft werden (z.B.: „ALTER TABLE personal.personal_table;“).
Für die drei benannten Typen kann die Überwachung mit folgendem Befehl
eingeschaltet werden:
AUDIT v_statement
BY v_user ACCESS
WHENEVER SUCCESSFULL;
In dem angegebenen Beispiel werden alle Zugriffe mit dem, in v_statement
eingetragenen SQL – Befehl, immer dann protokolliert, wenn die Aktion von v_user
110
Diese Datei wird vom Datenbanksystem zur Initialisierung einer Datenbankinstanz verwendet. Bis zur
Oracle – Version 8i unter dem Namen init.ora und ab Version 9i, unter dem Namen sp.ora bekannt.
Die Dateinamen können je nach Benennung der Datenbankinstanzen abweichen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 65 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
erfolgreich durchgeführt wurde.
Die Klausel WHENEVER SUCCESSFULL bedeutet, dass nur die erfolgreichen
abgesetzten Befehle protokolliert werden. Der Gegenpart hierzu ist WHENEVER NOT
SUCCESSFULL. Sollen beide, die erfolgreichen und nicht erfolgreichen Anweisungen
protokolliert werden, so wird der BOTH gesetzt. Mit dem Zusatz BY v_user ACCESS
werden die in v_statement abgegebenen Anweisungen, bei dem Datenbankbenutzer
v_user immer mitprotokolliert. Mit BY v_user SESSION hingegen, kann die
Anweisung auf nur einen Audit – Eintrag, innerhalb einer Session, beschränkt
werden. Sind die Anweisungen aller Datenbankbenutzer zu protokollieren, so wird die
spezielle Benutzerangabe BY ACCESS einfach weggelassen. Nach dem Schlüsselwort
AUDIT folgt die Anweisung, die man mitprotokollieren möchte. Als Beispiel sei der
Befehl AUDIT TABLE genannt, womit die Erstellung, Löschung und Änderung von
Tabellen protokolliert werden kann. Würde hingegen AUDIT CREATE TABLE
angegeben, so würden die Audit – Einträge nur bei Erstellung einer Tabelle erzeugt.
Das hoch auflösende Auditing oder auch Fine Grained Auditing (FGA) ist ein weiterer
Vertreter der möglichen Typen innerhalb einer Oracle – Datenbank. Dieser mit
Version 9i erschienene Typ, ist mit dem Vorgehen einer Oracle Virtual Private
Database zu vergleichen. Während im Anweisungs- oder Schemaobjekt – Auditing
nur die allgemeinen Zugriffe auf Objekte, innerhalb der Datenbank, überwacht
werden, besteht hier die Möglichkeit von Datenbankbenutzern ausgewertete Spalten
bzw. Zeilen von Tabellen und Views in das Auditing einfließen zu lassen. Wie in
Abschnitt 5-6-1, gibt es auch hier Policies, die eingesetzt werden können. Oracle
stellt das PL/SQL – Package DBMS_FGA zur Verfügung, das u.a. auch eine Prozedur
ADD_POLICY zur Erstellung einer solchen Policy enthält111. Diese Auditing – Methode
dient dazu, dass Informationen feiner granuliert, protokolliert werden können und
unnütze Informationen aus der Protokollierung ausgeschlossen werden. Im
Gegensatz zu den vorgenannten Auditing – Typen, erfolgt hierbei die Protokollierung
in der Tabelle fga_log$ des Schemas SYS. Die Einträge können über die View
dba_fga_audit_trail ausgelesen werden.
Wird die Oracle Data Vault genutzt, kann, innerhalb dieser Komponente, ein eigenes
Auditing, mit eigenen Tabellen und Regeln, hinzugeschaltet werden.
Die Auswahl, welche Auditingtypen in welchem Umfang eingesetzt werden, sollte
vorher genau überlegt werden. Allein schon aus Gründen der Performance und
Speicherintensität kann das Auditing schnell auch zu einem Hindernis in der
Datenbank werden112.
Vorsicht ist bei Vergabe der bereits erwähnten Rolle DELETE_CATALOG_ROLE
geboten. Besitzt diese jemand, so ist es diesem User möglich, die allgemeinen Audit
– Tabellen zu löschen oder zu archivieren und für Auswertungszwecke zu
missbrauchen.
5.7.
Erweiterte Sicherheitsmaßnahmen
Als letzten Schritt zur Absicherung eines Oracle – Datenbanksystems werden einige
erweiterte Sicherheitsmaßnahmen beschrieben. Da das DBS der Fachhochschule Köln
111
112
Nützliche Tipps zur Erstellung einer Policy, findet man bei [Bryla et al. 2007] Seite 366 und unter:
http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_fga2.htm#1002217,
20.09.2008
Mögliche Einsatzszenarien für ein Auditing unter [Newman et al. 2004] Seite 507 ff.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 66 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
auch für Studenten über das Internet angebunden ist, wird in diesem Abschnitt u.a.
die Netzwerksicherheit erwähnt. Weiterhin wird der wichtige Einsatz von
Backupmethoden beschrieben. Auch eine sichere Datenbank kann durch einen
unerwarteten Festplattencrash ihre Daten verlieren. Zum Schluss werden noch
sonstige, kleinere Sicherheitsaspekte aufgegriffen um die Sicherung zu vollenden.
5.7.1.
Netzwerksicherheit
Ob die Datenbank innerhalb eines Netzwerkes bzw. Intranets mit anderen Rechnern
oder anderen Datenbanken verbunden ist oder aber die Datenbank direkt an das
Internet angeschlossen ist. Wird einmal von einem Zugriff aus dem Betriebssystem
heraus auf die darin liegende Datenbank abgesehen, ist nahezu jede Interaktion mit
der Datenbank und den technischen Komponenten innerhalb eines IT – Systems
auch mit den Themen Netzwerk und Sicherheit verbunden. Daraus resultieren neben
den üblichen Gefahrenquellen auch sicherheitsgefährdende Aspekte wie das
Sniffing113 und das Spoofing114.
Im Rahmen der kostenpflichtigen115 Oracle Advanced Security (OAS) bietet Oracle
verschiedene Möglichkeiten zur Netzwerk – basierten Absicherung. Hierunter zählen
u.a. Authentifizierungsmethoden, wie SSL und die Verschlüsselung mit dem
erwähnten SHA-1 – Algorithmus. Weiterhin sind Integritätsprüfungen enthalten, die
beim Netzwerkverkehr unrecht
modifizierte, zusätzliche oder gar gelöschte
Datenpakete aufspüren. Dies geschieht durch eindeutig vergebene Sequenznummern
sowie durch die Verwendung von Prüfsummen, die durch verschlüsselte Hash –
Werte (z.B. durch den SHA-1- oder MD5 – Algorithmus) gesichert sind.
Um Sniffing- oder Spoofing – Attacken vorzubeugen, hilft die Verwendung des
Secure Socket Layer oder auch SSL116. Es handelt sich um ein Standardprotokoll zur
Sicherung
von
Netzwerkverbindungen.
Neben
einer
verschlüsselten
Datenübertragung, besteht weiterhin die Möglichkeit eine Authentifizierung
durchzuführen. SSL kann dabei so konfiguriert werden, dass entweder nur der Server
oder aber der Client und der Server sich authentifizieren müssen. Der Einsatz eines
SSL – Verfahrens erfordert zwar einigen Aufwand, da man sich z.B. ein Zertifikat
erstellen lassen und dieses von einer öffentlichen Zertifikatsvergabestelle117
unterzeichnet werden muss, dient aber erheblich der Sicherheit der Datenbank.
Dieses Verfahren zur sicheren Datenübermittlung ist im Datenbanksystem unter dem
Namen Oracle SSL bekannt. Zur Verwendung hierfür ist u.a. die Modifikation der
Datei
listener.ora,
die
im
Betriebssystemverzeichnis
$ORACLE_HOME/network/admin/ zu finden ist, nötig. Hierin sind auch die Ports
angegeben, über die der Datenverkehr mit der Datenbank erfolgt. Die automatisierte
Konfiguration des Oracle SSL, kann mit dem Oracle Net Configuration Assistent
vorgenommen werden118.
113
114
115
116
117
118
Sniffing ist eine Methode um den Datenverkehr in einem Netzwerk aufzuzeichnen.
Das Spoofing bezeichnet eine Methode, in der versucht wird, im Netzwerk eine bestimmte Identität
vorzugaukeln. Im Kontext Oracle – DBS kann dies z.B. bedeuten, dass jemand versucht, sich im
Netzwerk als DBA auszugeben.
Der Einsatz der Oracle Advanced Security kostet ca. 10.000 US – Dollar pro verwendeten Prozessor.
Bei der Verwendung des Oracle SSL in der Oracle – Version 9i gibt es Sicherheitslücken, die mit
Herunterladen eines Sicherheits – Patches behoben werden sollten.
Siehe http://www.heise.de/security/Patches-beheben-SSL-Fehler-bei-Oracle--/news/meldung/42664,
16.08.2008
Eine dieser Vergabestellen für Zertifikate ist CAcert. Siehe http://www.cacert.org/, 15.08.2008
Eine Anleitung zur Netzwerkinstallation mit dem Oracle Net Configuration Assistent findet man in
[Bryla et al. 2007] Seite 563 ff.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 67 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Jeder Datenbankserver innerhalb eines Netzwerkes erhält die Datei listener.ora.
Diese Datei wird automatisch, mit Ausführung des Oracle Net Configuration
Assistenten generiert. Neben den Ports, die der Kommunikation mit der Außenwelt
dienen, enthält sie Informationen über die Namen und Adressen der Listener –
Prozesse (Dies ist der Datenbankprozess, der das Datenbanksystem anderen
Systemen zugänglich macht.), die auf dem Betriebssystem laufen sowie der
angesteuerten Datenbankinstanzen.
Mit Herausgabe der Datenbankversion 10g wurden alle Listener, gegen Angriffe von
außen, standardmäßig über den undokumentierten Parameter EXTERNAL
LOCAL_OS_AUTHENTICATION geschützt. Vergibt man diesen Listenern ein Passwort,
so macht man diese wieder von der Außenwelt angreifbar. Da es den Parameter in
vorigen Versionen nicht gab, ist im Rahmen der Netzwerksicherheit nun darauf zu
achten, dass ein Oracle – Listener der Versionen 7 bis 9i mit einem Passwort
versehen ist. Lt. des Unternehmens Red – Database – Security, sind 90% aller
Listener dieser Versionen nicht mit einem Passwort geschützt, was zu einem sehr
einfachen Angriff für die Datenbank genutzt werden kann. Der daraus resultierende
Schritt ist also die Vergabe eines Kennworts. Hierzu wird in das
Betriebssystemverzeichnis $ORACLE_HOME/bin/ gewechselt. Nun wird das
Befehlszeilenprogramm lsnrctl aufgerufen, mit dem auch der, bzw. die Listener –
Prozesse gestartet und gestoppt werden. Nach Angabe des Befehls change_password
listener_name erfolgt die Aufforderung ein Passwort einzugeben und dieses zu
bestätigen. Wie in den vorigen Abschnitten mehrmals erwähnt ist es auch hier
notwendig, sichere Passwörter zu vergeben. Da die Kennwörter, nach Anwendung
des von Oracle verwendeten Data Encryption Standard (DES), als Hash – Wert in der
Datei listener.ora abgelegt werden, ist weiterhin darauf zu achten, dass diese Datei
vor fremden Zugriffen auf dem Betriebssystem geschützt ist. Im Gegensatz zum
Oracle Net Configuration Assistent kann auch mit Hilfe des Oracle Net Manager ein
Kennwort für den Listener vergeben werden.
Neben der Listener – Absicherung sollte als weiterer Punkt, die Verwendung von SQL
– Plus, kritisch begutachtet werden. SQL – Plus ist ein Kommandozeilentool, mit dem
SQL – Befehle abgesetzt werden können. Via SQL – Plus erfolgt eine Verbindung zur
Datenbank entweder direkt über den Client – Rechner oder über eine Secure Shell
(SSH) und das UNIX – Betriebssystem. Es ist zwar auch möglich sich mit telnet an
UNIX
anzumelden,
sollte
jedoch,
aufgrund
der
unverschlüsselten
Passwortübertragung, nicht genutzt werden.
Nun gibt es einige Punkte, die beim Einsatz von SQL – Plus beachtet werden sollten
und die gegen eine Verwendung sprechen. Ein erster Punkt ist, dass ein Client, der
sich mit der Datenbank verbindet evtl. nicht optimal gesichert ist. Angreifer könnten
versuchen über den ungeschützten Client und damit auch über SQL – Plus eine
Verbindung mit der Datenbank und u.U. auch dem Betriebssystem aufzubauen.
Nutzt ein Datenbankadministrator SQL – Plus und verbindet sich zuerst über SSH mit
UNIX, ist eine zweite Sicherheitslücke gegeben, da bei einer Verbindung mit SQL –
Plus, dieser von SQL – Plus angestoßene, laufende Prozess auf dem UNIX –
Betriebssystem angezeigt wird. Gibt nun ein Benutzer des UNIX – Betriebssystems
den Befehl „ps –ef | grep sqlplus“ ein, so sieht er den angemeldeten Benutzer
inklusive Passwort! Eine Möglichkeit dies zu verhindern ist, dass man SQL – Plus, aus
dem UNIX – Betriebssystem heraus, mit dem Befehl „echo password sqlplus –s user“
startet, was dazu führt, dass der laufende Prozess in UNIX nun nur noch mit dem
Parameter user angezeigt wird. Dies ist nicht desto trotz, eine Sicherheitslücke die
für Datenbankadministratoren gar nicht erst geöffnet werden sollte. Entwicklern und
sonstigen Datenbankbenutzern sollte ein Betriebssystemzugriff generell untersagt
werden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 68 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Ein letzter Punkt der beim Umgang mit SQL – Plus zu beachten ist, ist, dass die
Startup – Dateien von SQL – Plus (login.sql und glogin.sql), ohne entsprechenden
Schutz auf dem Betriebssystem, so manipuliert werden können, dass dadurch die
Datenbank angegriffen und diese Angriffe sogar vereitelt werden können119. Neben
SQL – Plus können auch andere Programme, wie z.B. der SQL – Navigator und
TOAD120, über Startup – Dateien versteckte SQL – Befehle, während einem Login zur
Datenbank, absetzen.
Es gibt gewisse Standardports, die während der Kommunikation mit dem
Datenbanksystem verwendet werden und in den installierten Dateien des Systems,
bzw. während der Installation einer Netzwerkverbindung, schon vorbelegt sind. Diese
sind u.a. für den unverschlüsselten Datenverkehr Port – Nr. 1521 und für den
verschlüsselten Port – Nr. 2482. Diese sind zu untersuchen und zu ändern. Ein
Angreifer der diese Ports offen vorfindet, kann sich denken, dass sie zum Oracle –
DBS gehören und wird versuchen seinen direkten Datenbankzugriff hierüber zu
tätigen.
Beschreibungen zur gesamten Absicherung eines Netzwerkes können nicht behandelt
werden, da sie den Rahmen einer solchen Arbeit ums Weite sprengen und dem
Nutzen eines Netzwerkadministrators nicht gerecht werden.
5.7.2.
Datenbankbackup
Trotz noch so ausgereifter Sicherheitsmaßnahmen kann es dazu kommen, dass
Daten durch Benutzer- und Hardwarefehler oder durch Naturkatastrophen verloren
gehen. Weiterhin kann der Datenbestand durch Angriffe mutwillig entfernt oder
beschädigt werden. Auch wenn in den genannten Fällen der Übeltäter überführt und
ausfindig gemacht werden kann, bleibt die Tatsache bestehen, dass der letztmögliche
Datenbestand wieder in das Datenbanksystem eingespielt werden muss.
Um nun Datenbackups durchzuführen, bietet Oracle eine Menge von Möglichkeiten
an. Eine Variante die schon kurz aufgezeigt wurde, ist das Import- und
Exportverfahren
über
die
vergebenen
Rollen
IMP_FULL_DATABASE
und
EXP_FULL_DATABASE. Der Ex- und Import kann über den Oracle Enterprise Manager
erfolgen. Die daraus exportierten Daten enthalten allerdings nur die
Metainformationen der Datenbank. Also nicht das komplette Datenbanksystem. Diese
Variante wurde von Oracle dafür gedacht, dass Datenbankbenutzer ihre eigenen
Backups verwalten können. Seit Oracle 10g kann man für diese Backupmethode auch
die Oracle Data Pump benutzen, die im PL/SQL – Package DBMS_DATAPUMP, im
Schema SYS zu finden ist. Sie zeichnet sich, lt. Oracle, im Gegensatz zur
Verwendung der Ex- und Import – Verfahren über den Oracle Enterprise Manager,
durch bessere Performance aus121.
Eine weitere Methode zur Datenbanksicherung ist das Backup im Offline- und Online
– Modus. Im Offline – Modus geschieht die Datenbanksicherung, indem auf
Betriebssystemebene die kompletten Verzeichnisse der datenbankbezogenen
Dateien, in andere, beliebige Verzeichnisse kopiert werden. Im Online – Modus ist
der Vorgang gleich, jedoch werden hier die existierenden Tablespaces der Datenbank
zuerst in einen festen Zustand überführt, damit keine Inkonsistenz der Daten
119
120
121
Vgl. http://www.doag.org/pub/docs/sig/database/2005/03/absicher_admin_pc.pdf, 16.08.2008
Beide Programme werden vom Unternehmen Quest Software entwickelt.
Siehe http://www.questsoftware.de, 21.09.2008
Eine sehr gute Beschreibung zur Verwendung der Oracle Data Pump erhält man unter
http://www.ordix.de/ORDIXNews/2_2004/db_2.html, 16.08.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 69 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
entstehen kann. Dies geschieht auf Datenbankebene mit dem SQL – Statement:
ALTER TABLESPACE USERS BEGIN BACKUP;
Nach der Erstellung einer Sicherheitskopie auf dem Betriebssystem, wird der Befehl:
ALTER TABLESPACE USERS END BACKUP;
ausgeführt, damit die Tablespaces wieder normal benutzt werden können122.
Eine dritte und gerade in größeren Unternehmen bevorzugte Methode, ist die
Datenbanksicherung mittels Oracle Recovery Manager (RMAN). Dieser ist seit der
Oracle – Version 8i verfügbar und wird mit der Standard – Edition bzw. der
Enterprise – Edition installiert. Die Nutzung dieser Komponente ist nur dem
Datenbankadministrator bzw. dem Datenbankbenutzer mit der SYSDBA –
Berechtigung vorbehalten und über den Oracle Enterprise Manager ansteuerbar. Er
bietet, im Gegensatz zu den vorgenannten Methoden einige Vorteile. Einer ist z.B.,
dass die verschiedenen Sicherungen in einer Historie abgelegt werden, womit man
ältere Sicherungen wiederherstellen kann. Dadurch ist es auch möglich nur die Daten
zu sichern, die sich, basierend auf den Änderungen seit dem letzten Backup,
geändert haben. Ein weiterer Vorteil ist die Plattformunabhängigkeit. Sicherungen die
mit dieser Komponente initiiert wurden können auch auf anderen Betriebssystemen,
außerhalb eines UNIX – Betriebssystems, mit den gleichen, bereits erstellten
Backupmethoden, wieder durchgeführt werden. Als letzter Punkt ist leider nur die im
Rahmen der Oracle Advanced Securtiy und somit kostenpflichtig zur Verfügung
gestellte, integrierte Verschlüsselung des RMAN, zu erwähnen. Sie ist ein immenser
Vorteil und sorgt somit bereits während des Backups, für eine gewisse Sicherheit der
Daten. Andere, betriebssystemspezifische Dateien, wie z.B. die listener.ora, werden
bei dieser Methode jedoch nicht gesichert und müssen mit entsprechenden Befehlen
der Betriebssystemumgebung, separat geschützt werden123.
Backups der Datenbank sollten nur durchgeführt werden, wenn auf der Datenbank
am wenigsten gearbeitet wird. Dies ist, bei den meisten Organisationen bzw.
Unternehmen, in den frühen Morgenstunden. Aufgrund der Globalisierung kann diese
Aussage jedoch nicht verallgemeinert werden. Bevor ein Backup geplant und
durchgeführt wird, sollte der Datenverkehr also genauestens untersucht werden.
Eine Sicherung der Datenbank sollte natürlich täglich erfolgen, da es an jedem Tag
dazu kommen kann, dass eine Wiederherstellung der Daten notwendig wird. Die
Sicherung selbst bzw. die gesicherten Daten sollten auf einem physikalisch anderswo
abgelegten Speicher erfolgen, da durch Naturkatastrophen oder durch
Hardwarefehler und Festplattencrashs eine Sicherung auf dem gleichen Rechner nicht
viel hilft. In jedem Fall sollte die Sicherung maschinell erfolgen, damit manuelle
Fehler nicht dazu führen, dass eine Sicherung vergessen oder unvollständig
durchgeführt wird.
122
123
Weitere Informationen zur Sicherung im Online- und Offline – Modus unter:
[Bryla et al. 2007] Seite 425 f.
Umsetzungsmöglichkeiten mit RMAN findet man bei [Bryla et al. 2007] Seite 453 ff.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 70 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
5.7.3.
Abschließende Sicherungsmöglichkeiten
Während nun in vielen Abschnitten auf die Bereiche einer Oracle – Datenbank und
deren Absicherung eingegangen wurde, werden in diesem letzten separaten Punkt,
abschließende Maßnahmen, zur Sicherung eines Oracle – Datenbanksystems,
erläutert.
In der letzten Zeit wurden viele IT – Systeme mit so genannten Rootkits124
angegriffen. Diese gelten als eine neue Form der Malware und können neben
Betriebssystemen, auch Datenbanksysteme, wie Oracle, angreifen. Sie sind eine
Sammlung von Programmen, mit denen es dem Angreifer u.a. möglich ist, Login –
Daten von Datenbankbenutzern auszuspähen und die Prozesse, mit denen der
Angreifer die Angriffe verursacht, zu verstecken. Ziel dieser Attacken ist es, sensible
bzw. sicherungsbedürftige Informationen aus der Datenbank auszulesen.
Auf Datenbankebene versuchen Angreifer Rootkits auf der Datenbank einzuspielen,
indem sie sich, z.B. mit Standardbenutzern und deren standardmäßig vergebenen
Passwörtern einloggen (siehe Abschnitt 5-4-3). Eine beliebte Methode im Oracle –
Umfeld ist das Einspielen von gefährlichen Attacken über eine Startup – Datei von
SQL – Plus, der login.sql bzw. glogin.sql. Von daher ist es wichtig alle
Betriebssystemdateien, die mit der Datenbank in Verbindung stehen, regelmäßig
nach Veränderungen zu durchsuchen und diese entsprechend zu schützen. Da
Rootkits auch Code enthalten können, die die Prozesse, auf denen die Angriffe
verursacht werden, verbergen können, reicht es nicht aus, sich nur die
Betriebssystemprozesse anzuschauen, die mit der Datenbank verbunden sind. Es
müssen auch die Dateien auf Veränderungen untersucht werden. Auf
Datenbankebene sollte die Datenbank täglich auf Datenbankbenutzer hin überprüft
werden, die zu viele Berechtigungen enthalten (siehe Abschnitt 5-5-2).
Über die DATA DICTIONARY – View v$parameter können weitere Informationen, ob
Benutzer unberechtigten Zugriff auf das Datenbanksystem erhalten können,
gewonnen
werden.
Die
enthaltenen
Informationen
stammen
aus
den
Betriebssystemdateien, die das Datenbanksystem während der Initialisierung
verwendet. Die darin enthaltenen Parameter O7_DICTIONARY_ACCESSIBILTY,
REMOTE_OS_AUTHENT und REMOTE_OS_ROLES sollten dahingehend überprüft
werden, dass sie jeweils mit dem Wert FALSE versehen sind. Ist dies bei
O7_DICTIONARY_ACCESSIBILTY125 nicht der Fall, so kann ein Datenbankbenutzer,
mit der Berechtigung SELECT ANY TABLE, Informationen aus der DATA DICTIONARY
auslesen. Bei den Parametern REMOTE_OS_AUTHENT und REMOTE_OS_ROLES ist es
durch eine falsche Zuweisung möglich, dass externe Benutzer bei einem externen
Zugriff zur Datenbank, u.a. kein Kennwort angeben müssen126. Standardmäßig sind
Datenbankbenutzer als interne Benutzer angelegt. Sie können jedoch als externe
Benutzer angelegt werden, indem, während der Anlage eines Datenbankaccounts,
das Schlüsselwort EXTERNALLY angegeben wird.
Der Schutz der Redo – Log – Dateien darf in der Verwendung eines Oracle –
Datenbanksystems ebenfalls nicht vergessen werden. Diese Dateien enthalten im
Klartext, die auf der Datenbank zuvor verwendeten SQL – Befehle der
Datendefinitionsund
der
Datenmanipulationssprache.
Sie
werden
vom
124
125
126
Weiterführende, wichtige Informationen über Rootkits, erfährt man auf den folgenden Webseiten:
http://www.muniqsoft.de/unternehmen/Rootkits.pdf, 14.08.2008
http://www.red-database-security.com/wp/db_rootkits_dt.pdf, 15.07.2008
Seit der Oracle – Version 8i ist dieser Parameter bereits richtig gesetzt und muss nicht angepasst
werden.
Vgl. [Newman et al. 2004] Seite 597
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 71 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
Datenbanksystem dazu genutzt, im Falle eines Systemabsturzes der Datenbank, die
Datenbank wieder auf den aktuellen Stand zurückzufahren. Die Redo – Log – Dateien
werden
standardmäßig
im
Betriebssystemverzeichnis
der
jeweiligen
Datenbankinstanz gespeichert. Haben Angreifer nun Zugang zu diesen Dateien,
können sie diese Dateien mit einfachen Editoren auslesen und die darin enthaltenen
Informationen, für einen Angriff gegen die Datenbankinstanz, verwenden. Ebenfalls
können sie bereits getätigte Angriffe über diese Dateien vereiteln, indem sie die darin
enthaltenen und im Zuge ihres Angriffs erstellten Daten einfach ändern.
Weiterhin gibt es in großen Unternehmen i.d.R. viele Entwickler, die während ihrer
täglichen Arbeit, eine Menge von Programmen im Datenbanksystem ablegen. Da sich
während der Programmierung schnell Fehler einschleichen, die durch den
Programmierer nicht direkt erkannt werden und das Zusammenspiel von PL/SQL –
Packages, Prozeduren, Tabellen usw. nicht immer direkt funktioniert, ist ein
Hinzuziehen von Produktionsadministratoren, um Programme auf eine nächst höhere
Instanz zu promoten, oft mühselig. Weiterhin nimmt dies meist viel Zeit in Anspruch,
die ein Unternehmen nur selten hat. Um diese Hürde zu umgehen, kann eine
Testdatenbank für Programmierer eingesetzt und ihnen nach entsprechender
Berechtigungsvergabe für dieses Testsystem, die Möglichkeit gegeben werden,
Testszenarien
durchzuspielen.
Nach
erfolgtem
Test,
könnten
die
Produktionsadministratoren die fertigen Objekte oder auch SQL – Befehle auf einer in
der Systemarchitektur nächst höher gelegenen Datenbank einspielen. Hierfür ist aber
unbedingt darauf zu achten, die Produktionsdatenbank nicht zu clonen. Da sehr viele
Organisationen ihre Produktionsdatenbank clonen127 und diese als Testdatenbank
verwenden, muss ein potenzieller Angreifer nur die Zugangsdaten zur Testdatenbank
herausfinden und schon hat er Zugriff auf die Produktionsdatenbank.
Als letzte Maßnahme ist zu erwähnen, dass regelmäßig Sicherheits – Patches
eingespielt werden sollten um bestehende Sicherheitslücken zu schließen. Weiterhin
ist es hilfreich immer auf dem neuesten Stand zu bleiben, was Sicherheitslücken
angeht. Hierfür gibt es verschiedene Unternehmen und Homepages, die im Umgang
mit Oracle und Sicherheit spezialisiert sind.
Einige ausgewählte Homepages und Unternehmen im Umgang mit Oracle –
Sicherheit:
127
•
http://www.red-database-security.com
ist
die
Homepage
des
Unternehmens Red – Database – Security GmbH, das Spezialist in
allen Fragen rund um Oracle – Sicherheit ist. Auf der Homepage
werden viele kostenfreie Informationen sowie ein Blog – Bereich zu
diesem Thema bereitgestellt. 17.08.2008
•
http://www.praetoriate.com ist die Homepage von Donald K. Burleson.
Er ist Oracle – Consultant und spezialisiert auf das Thema Oracle –
Sicherheit. 17.08.2008
•
http://www.petefinnigan.com ist die offizielle Homepage von Pete
Finnigan, der Inhaber des Unternehmens petefinnigan.com Limited ist.
Auf der Homepage sind ebenfalls viele Informationen sowie ein Blog –
Bereich zu diesem Thema enthalten. 18.08.2008
Lt. Aussage von Hr. Alexander Kornbrust, Geschäftsführer des Unternehmens Red – Database –
Security.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 72 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 5: Erarbeitung eines Sicherheitsplans
•
http://www.muniqsoft.de gehört zum Unternehmen MuniQSoft GmbH.
Auf der angegebenen Homepage sind viele nützliche Hinweise zum
Thema Oracle und Sicherheit enthalten. 18.08.2008
Über die Homepage von Oracle besteht die Möglichkeit, Sicherheits – Patches und
Informationen zu dem verwendeten Datenbanksystem, herunter zuladen.
•
http://tahiti.oracle.com/ bietet Dokumentationen zu allen Oracle –
Versionen ab 8i. 20.09.2008
•
http://www.oracle.com/technology/deploy/security/alerts.htm
beinhaltet die Links zu sicherheitsrelevanten Updates in Bezug auf
Oracle – Datenbanksysteme. 20.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 73 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
6.
Oracle 11g vs. MySQL 5.0.67
Auch wenn die Überschrift im ersten Moment etwas abschreckt, geht es in diesem
Abschnitt nur darum, die Sicherheitsmöglichkeiten der beiden Datenbanksysteme
Oracle und MySQL gegeneinander zu stellen und zu vergleichen. Hierbei werden die
Möglichkeiten in den derzeit aktuellen produktiven Versionen beschrieben.
Da bereits viele Sicherheitsaspekte in Oracle benannt wurden, werden in diesem
Abschnitt nur die Neuerungen der Version 11g vorgestellt. In Bezug auf MySQL
werden die aktuell eingesetzten Sicherungsmechanismen der produktiven Version
5.0.67 erläutert. Nach Gegenüberstellung der beiden Systeme, erfolgt eine
Bewertung der Absicherungsmöglichkeiten in einem Fazit.
6.1.
Neuerungen in Oracle 11g
Oracle 11g gilt in der derzeitigen Version als ein sehr sicheres System. Viele
Krankheiten im Sicherheitsbereich wurden bereits mit der Vorgängerversion Oracle
10g ausgemerzt. Natürlich gibt es immer noch eine Menge an Sicherheitslücken,
doch man kann festhalten, dass es schon tief greifender Kenntnisse bedarf um in die
aktuelle Datenbankversion einzudringen.
Oracle hat mit Erscheinen der Version 11g keine grundlegenden Sicherheitsfeatures
eingebaut. Viele Schwachstellen, die in Vorgängerversionen noch enthalten waren,
wurden ausgebessert und sind als kein direktes Sicherheitsnovum zu erkennen.
Einige der nachstehend genannten Neuerungen wurden sogar schon mit Oracle 10g
(Release 2) eingeführt, jedoch mit Erscheinen von 11g erweitert. Dokumentationen
zu den Neuerungen der aktuellen Version stehen auf der Oracle – Homepage128 zum
Download bereit. Die wichtigsten werden in den nachfolgenden Abschnitten kurz
erläutert.
6.1.1.
Der Umgang mit Kennwörtern
Gerade in Bezug auf den Umgang mit Passwörtern hat Oracle einiges verbessert.
Einige Neuerungen wurden im Verlauf dieser Arbeit schon mal angesprochen, werden
in diesem Abschnitt aber noch mal explizit erläutert.
In Abschnitt 5-4-3 wurden bereits die, während der Installation, von Oracle
angelegten Standardbenutzer genannt. Sie werden vom Datenbanksystem meist zur
Verwaltung einer zusätzlich installierten Komponente benötigt. Leider können einige
dieser Komponenten während der Installation nicht direkt ausgewählt werden. Sie
werden einfach, inkl. der dazugehörigen Datenbankbenutzer, mitinstalliert. Gerade
vor Version 10g erfuhren Administratoren des Datenbanksystems erst nach der
Installation von deren Existenz.
Um nun in 11g eine direkte Möglichkeit zu haben, diese Datenbankbenutzer
herauszufinden, hat Oracle, mit Erscheinung der neuen Version, eine View
128
http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/toc.htm, 01.09.2008
http://www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/11g-security.html,
03.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 74 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
bereitgestellt, die es erlaubt, die Standardbenutzer denen auch ein Standardpasswort
vergeben wurde, mit einer einzigen SQL – Abfrage herauszufinden.
SELECT * FROM dba_users_with_defpwd;
Nach Ausführung dieses Befehls erhält man eine Ausgabe, die Datenbankaccounts
ausgibt, welche noch ihr, während der Installation erhaltenes Kennwort innehaben.
Da jeder andere Datenbankbenutzer, der die Berechtigung hat, die DATA
DICTIONARY zu lesen, diesen Befehl ebenfalls absetzen kann, sollten die
Administratoren
diese
Ausgabe
zum
Anlass
nehmen,
den
ermittelten
Datenbankbenutzern starke Kennwörter zu vergeben.
Ebenfalls mit Version 11g erschienen, ist ein weiteres Novum, das leider viel zu lange
auf sich warten ließ. Wie schon in Abschnitt 5-5-5 erwähnt, besteht nun die
Möglichkeit, Kennwörter in Groß- und Kleinschreibung festzulegen. Wird z.B. eine
Datenbank mit dem Database Creation Assistent erstellt, wird nachgefragt, ob die
„new security standards“ genutzt werden sollen. Bejaht man dies, so müssen die
Benutzer der Datenbank, ab sofort ihre Kennwörter in der richtigen Groß- bzw.
Kleinschreibung angeben. Wird eine gewisse Zeit benötigt um dies den Usern der
Datenbank plausibel darzustellen, so kann die alte Kennwortvergabe mit
nachfolgendem Statement wieder aktiviert werden:
ALTER SYSTEM SET sec_case_sensitive_logon = FALSE;
Das gleiche gilt natürlich auch im umgekehrten Fall, indem der Parameter
sec_case_sensitive_logon wieder auf TRUE gesetzt wird. Welche Kennwortmethode
verwendet wird, ist nun in der View dba_users und dem, seit 11g enthaltenen,
zusätzlichen Feld password_versions zu erkennen.
Aus Erfahrungswerten des Unternehmens Red – Database – Security, muss jedoch
festgehalten werden, dass bei einer solchen Umstellung auch die Datenbankbenutzer
selbst mitwirken müssen, damit dies eine Verbesserung in der Qualität der
verwendeten Kennwörter darstellt. Denn leider ist es oft so, dass die User nun,
anstatt eines großgeschriebenen Wortes, entweder ein kleingeschriebenes Wort
benutzen oder aber nur den ersten Buchstaben groß schreiben und die restlichen
klein.
Eine weitere Veränderung ist darin zu erkennen, dass nun die Kennwörter der
jeweiligen Datenbankbenutzer nicht mehr in der View dba_users angezeigt werden.
In der Spalte password, stand vor dieser Datenbankversion, immer der Hash – Wert
des jeweiligen Kennworts bzw. Datenbankaccounts. Nun ist hier nur noch ein NULL –
Wert zugegen und der eigentliche Hash – Wert ist nur in der Tabelle user$ des
Schemas SYS zu finden.
Als letztes neues Feature, in Bezug auf Kennwörter, ist die von Oracle mitgelieferte
Funktion verify_function_11g zu erwähnen. Wie bereits in Abschnitt 5-5-4 erläutert,
können mit Hilfe dieser Funktion, Passwortkonventionen festgelegt werden, die
während einer Passwortvergabe durch den Datenbankbenutzer, angewendet werden.
Der Name verify_function_11g wird im bereits bestehenden DEFAULT – Profil, als
Wert für den Parameter PASSWORD_VERIFY_FUNCTION festgelegt. Die Funktion
selbst, wird nach Ausführung des SQL – Skripts utlpwdmg.sql, das sich im
Betriebssystemverzeichnis $ORACLE_HOME/rdbms/admin befindet, kreiert. Diese
Funktion
sollte
den
eigenen
Bedürfnissen
angepasst
werden,
da
die
Standardeinstellungen für ein Datenbanksystem, das eine starke Sicherung benötigt,
nicht ausreichen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 75 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
6.1.2.
Verbessertes Auditing
Eine Neuerung, die vielleicht nicht unbedingt als Verbesserung angesehen werden
kann, ist, dass das Berechtigungs – Auditing bereits nach Installation eingeschaltet
ist. Hierzu ist der AUDIT_TRAIL – Parameter in der Datei init.ora bereits mit dem
Wert ON belegt. Daraus resultiert die Tatsache, dass die Datenbank nicht erst
komplett gestoppt werden muss, um das Auditinig zu aktivieren. D.h. man spart ein
stoppen und starten der jeweiligen Datenbank. Die Protokollierung erfolgt mit dieser
Einstellung in der Tabelle aud$ des Schemas SYS.
Eine weitere Neuerung ist, dass die Protokollierung von Systemberechtigungen
nunmehr um einiges performanter sein soll. Oracle möchte hier wohl die
Hemmschwelle herabsetzen, das Auditing einzusetzen. Weiterhin wurde von Oracle –
erkannt, dass es nicht nur darum geht, das Verhalten der Datenbankbenutzer im
Umgang mit Daten zu dokumentieren sondern, aufgrund von vermehrt
auftauchenden Fällen, auch das Verhalten von Angreifern die versuchen,
Systemberechtigungen zu erlangen und diese für ihre Zwecke auszunutzen.
6.1.3.
Verschlüsselung des Tablespace
Für den Tablespace der Datenbank, der u.a. dazu dient die Daten, die im
Datenbanksystem abgelegt sind, zu speichern, ist es seit der Version 11g möglich,
diesen zu verschlüsseln. Dies hat den Vorteil, dass es z.B. für Angreifer, die zwar auf
das Betriebssystem aber nicht auf das Datenbanksystem zugreifen können,
schwieriger wird, Daten aus den Tablespaces auszulesen.
Diese Methode ermöglicht die Verschlüsselung einzelner Tablespaces, die sensible
Daten enthalten. Hierzu muss zuerst ein so genannter Wallet kreiert werden, der den
Schlüssel bzw. das Kennwort enthält, um an die verschlüsselten Daten zu gelangen.
Die Verschlüsselung selbst, erfolgt entweder über den Verschlüsselungsalgorithmus
Advanced Encryption Standard (AES) oder aber über den Data Encryption Standard
(DES), welcher in dem SQL – Befehl, während der Erstellung des Tablespace,
angegeben werden kann. Da AES der Nachfolger von DES und sicherer ist, sollte
jedoch dieser gewählt werden129.
Was jedoch bei der Verschlüsselungsmethode von Tablespaces beachtet werden
sollte, ist die Tatsache, dass sich die Verschlüsselung nicht mehr rückgängig machen
lässt. Dies wird zwar von Oracle nicht direkt vermarktet, ist aber für eine später evtl.
notwendige Rücksicherung von entscheidender Bedeutung. Weiterhin wird dieses
Feature nur mit der teuren Oracle Advanced Security verkauft.
6.1.4.
Verschlüsselung von Betriebssystemdateien
Es war bereits seit langem ein großer Schwachpunkt von Oracle, dass mit nur
wenigen Handgriffen gesicherte Dateien, die z.B. aus einer Backupmethode
entsprangen, gelesen werden konnten. Sobald der Angreifer über bestimmte, frei
zugängliche Software verfügte und dabei noch auf die entsprechenden Verzeichnisse
bzw. Dateien des Betriebssystems zugreifen konnte, war es relativ schnell möglich
129
Eine genaue Beschreibung zur Erstellung von verschlüsselten Tablespaces erhält man auf
nachfolgender Homepage:
http://www.oracle-base.com/articles/11g/TablespaceEncryption_11gR1.php, 05.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 76 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
die gesicherten Daten auszulesen.
In Abschnitt 5-7-2 wurde bereits auf Datenbankbackups eingegangen. Darin wurde
u.a. auch die Datenbanksicherung mit der Komponente Oracle Data Pump
beschrieben, welche die gesicherten Dateien ebenfalls auf dem Betriebssystem
speichert.
Da
mit
dem
Oracle
Recovery
Manager
verschlüsselte
Datenbanksicherungen angelegt werden können, bezieht sich die Neuerung in Oracle
11g nur auf die Backupmethode Oracle Data Pump. Denn nun ist es auch mit dieser
Komponente möglich, Datenbanksicherungen zu verschlüsseln. Hierbei wird, genau
wie bei der Verschlüsselung der Tablespaces, zuerst ein Wallet, mit einem
entsprechenden Kennwort angelegt. Danach wird auf Betriebssystemebene die
Komponente Oracle Data Pump, mit entsprechenden Parametern zur verschlüsselten
Sicherung des jeweiligen Datenbestandes, gestartet130.
Neben der Verschlüsselung von Backupdateien gelingt es nun auch die, unter
Abschnitt 5-7-3 erwähnten, Redo – Log – Dateien zu verschlüsseln. Die auf dem
Betriebssystem abgespeicherten Dateien, die SQL – Befehle als Klartext enthalten,
galten ebenfalls seit langer Zeit als Schwachpunkt des Datenbanksystems. Der
einzige aber teure Wehrmutstopfen besteht in der Oracle Advanced Security, die
auch hier als Option erst teuer dazugekauft werden muss.
6.2.
Sicherheitsmöglichkeiten in MySQL 5.0.67
MySQL ist ein sehr junges relationales Datenbanksystem. Erst mit Veröffentlichung
der Version 5, sind Neuerungen enthalten, die es als richtiges RDBMS erkennen
lassen. U.a. wird mittlerweile von MySQL auch der Einsatz von Triggern, Views und
Stored – Procedures unterstützt.
Vom Sicherheitsaspekt her, gibt es in der aktuell produktiven Version wesentliche
Verbesserungen. Gerade vor dieser Version galt MySQL als ein sehr unsicheres
System. Grundsätzlich erfüllt MySQL schon viele Anforderungen an Sicherheit.
Obwohl viele Unternehmen bzw. große Organisationen dieses Datenbanksystem
vorerst wohl eher nicht als Datenhaltung für sensible Daten nutzen werden und es
für das Unternehmen MySQL AB noch einiges zutun gibt, werden nachfolgend die
derzeitigen Möglichkeiten aufgezeigt, die MySQL an Sicherheitsoptionen bietet.
6.2.1.
Absicherung mit dem Shellskript mysql_secure_installation
Das Shellskript mysql_secure_installation wird dann benötigt, wenn MySQL frisch auf
einem UNIX – Betriebssystem installiert wurde. Denn direkt nach Installation der
Version 5.0.67, die mit Ausführung des Shellskripts mysql_install_db erfolgt, treten
drei Nebeneffekte auf, die mit diesem Skript geschlossen werden können.
Zuerst wird während der Installation des Datenbanksystems ein Datenbankbenutzer
angelegt, der für die Administration der Datenbank verantwortlich ist. Dieser hat den
Namen root, verfügt zwar über kein Kennwort, besitzt jedoch schon alle möglichen
Berechtigungen. Mit Ausführung dieses Shellskripts wird nun gefragt, ob dieser
Benutzer mit einem neuen Passwort abgesichert werden sollte. Die Passwortvergabe
ist dabei so zu wählen, dass sie den bereits mehrfach erwähnten
130
Eine Beschreibung zur Verschlüsselung von Sicherungsdateien findet man unter:
http://www.ordix.de/ORDIXNews/1_2006/TDE.html, 06.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 77 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
Passwortkonventionen entspricht.
Während der Installation wird ebenfalls eine Testdatenbank angelegt. Diese ist dazu
gedacht, um das MySQL – Datenbanksystem besser kennen zu lernen. Da die
Testdatenbank auch für Angriffe aus dem inneren des Datenbanksystems genutzt
werden kann, z.B. für SQL – Injections, sollte diese gelöscht werden, was durch
Ausführung des benannten Skripts angeboten wird.
Zuletzt wird während der Installation ein Benutzer anonymous erstellt. Dieser ist
dazu gedacht, um von einem MySQL – Client auf den MySQL – Server, d.h. die
Datenbank zuzugreifen. Auch dieser Datenbankuser besitzt, wie der Benutzer root,
alle Berechtigungen und verfügt über kein vergebenes Passwort. Dies führt dazu,
dass auch über dieses Konto in die Datenbank eingedrungen und immenser Schaden
angerichtet werden kann. Die Löschung dieses Datenbankbenutzers wird während
der Ausführung des Shellskripts ebenfalls angeboten131.
6.2.2.
Optionen zum Starten des MySQL – Server mysqld
Mysqld ist der MySQL – Server des Datenbanksystems MySQL. Das Programm
mysqld kann mit verschiedenen Parametern gestartet werden. Diese Parameter
legen u.a. fest, welche SQL – Syntax verwendet wird oder aber in welchem
Verzeichnis
die
Datendateien
abgelegt
werden.
Weiterhin
können
sicherheitsspezifische Regeln angewendet werden132. Nachfolgende Tabelle gibt einen
Überblick über die, im Bezug auf Sicherheit zu setzenden Parameter:
Parameter
Erläuterung
--local-infile=0
Dies ist die Deaktivierung des SQL – Befehls "LOAD
LOCAL DATA". Wie der Name schon sagt, hat ein MySQL
– Benutzer, ohne Deaktivierung dieses Befehls, die
Möglichkeit lokale Dateien des Betriebssystems bzw. des
Datenbanksystems zu lesen. Ein MySQL – Benutzer
könnte beliebige Dateien lesen, auf die der
Datenbankserver zugreift. Da dies normalerweise nicht
gewünscht ist und nur der Datenbankadministrator diese
Daten lesen sollte, wird dieser Parameter gesetzt.
--safe-user-create
Anhand dieses Parameters kann ein Benutzer nur dann
neue Benutzer mit dem SQL – Statement GRANT
anlegen, wenn er auch die INSERT – Berechtigung für die
Tabelle user des Schemas MYSQL hat. Wenn also
131
132
Weitere Informationen zum Skript mysql_secure_installation findet man unter:
http://dev.mysql.com/doc/refman/5.1/en/mysql-secure-installation.html, 09.09.2008
Eine Auswahl von möglichen Parametern zum Starten des MySQL – Server unter:
http://dev.mysql.com/doc/refman/5.1/de/server-options.html, 08.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 78 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
versehentlich einem User eine Berechtigung erteilt
wurde, die es ihm erlaubt Datenbankbenutzer anzulegen,
so kann er diese erst anlegen, wenn er auch die
Berechtigung hat, einen INSERT auf die genannte Tabelle
auszuführen.
--secure-auth
Vor der MySQL – Version 4.1 wurden die Passwörter der
Datenbankaccounts in der Tabelle user, als 16 Zeichen
langer Hash – Wert abgelegt. Seit Version 4.1 jedoch
erfolgt ein Hashing – Algorithmus, der Passwörter in der
Tabelle user, mit 41 Zeichen anlegt.
Das Setzen dieses Parameters besagt nun, dass die Hash
– Werte von Datenbankusern nur noch mit dem neuen
Hashing – Algorithmus vergeben werden und somit ein
Hash – Wert in einer Länge von 41 Zeichen in der Spalte
password, der entsprechenden Tabelle abgelegt werden.
--bind-adress=ip_adress
Ein Client kann sich mit dem Datenbankserver entweder
über TCP / IP oder über Sockets verbinden. Soll sich nur
ein bestimmter Rechner mit dem Datenbankserver
verbinden, so kann mit diesem Parameter die IP –
Adresse dieses Rechners angegeben werden.
Es besteht jedoch keine Möglichkeit, weitere IP –
Adressen zuzulassen.
--skip-networking
Sollte hingegen erreicht werden, dass mit dem
Datenbankserver nur über UNIX – Sockets und nicht
über TCP / IP – Verbindungen kommuniziert werden
kann, so muss diese Option angegeben werden.
Tabelle 6-1 Parameter zum sicheren Starten des MySQL – Servers (Quelle: MySQL OnlineReferenzhandbuch - http://dev.mysql.com/doc/refman/5.1/de/privileges-options.html, 08.09.2008)
Der Aufruf des MySQL – Servers könnte nun folgendermaßen aussehen:
mysqld
--local-infile=0
--safe-user-create
--secure-auth
--bind-adress=127.0.0.1
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 79 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
In der Auslieferung von MySQL ist weiterhin ein Skript enthalten, das unter UNIX
zum Start des MySQL – Servers verwendet werden kann. In dem Skript
mysqld_safe133 ist u.a. eine Option enthalten, die die Protokollierung von
Netzwerkfehlern und Laufzeitinformationen erlaubt. Weiterhin kann das Skript mit
den eben beschriebenen Parametern, zum Starten des Datenbankservers, bestückt
werden.
6.2.3.
Sichere Anlage von Datenbankbenutzern
Im Gegensatz zu Oracle, ist es in MySQL nicht möglich, Benutzern direkt zu Beginn
irgendwelche Rollen, wie z.B. die Oracle – Rolle RESOURCE, zuzuweisen. Dies hat
Vorteile, als auch Nachteile. Ein Vorteil ist sicherlich zu darin sehen, dass neuen
Datenbankbenutzern nur die Berechtigungen erteilt werden, die auch wirklich
notwendig sind, da sie manuell und explizit vergeben werden müssen. Nachteile
bestehen jedoch darin, dass bei einer größeren Menge von Datenbankbenutzern wohl
ein hoher Zeitaufwand damit verbracht werden muss, die Benutzer, mit den für sie
notwendigen Berechtigungen, zu bestücken.
Weiterhin besteht in MySQL, im Gegensatz zu Oracle, nicht die Möglichkeit
Datenbankbenutzern bestimmte Profile zuzuweisen. Eine Möglichkeit bestimmte
Passwortkonventionen einzusetzen existiert nicht und Begrenzungen von
Benutzerressourcen müssen bei MySQL, während der Anlage von neuen Benutzern,
jeweils explizit angegeben werden. Einerseits wieder vorteilhaft, andererseits kann es
u.a. dazu führen, dass Datenbankadministratoren zu lange mit der Anlage von
Benutzern beschäftigt sind.
Nachdem ein neuer Datenbankuser erstellt wurde, könnte eine Berechtigungsvergabe
für einen neuen MySQL – Benutzer folgendermaßen aussehen:
GRANT SELECT, INSERT, UPDATE
ON personal.personal_table_1
TO ’v_personal_user’@127.0.0.1
IDENTIFIED BY v_password
WITH MAX_QUERIES_PER_HOUR 30
MAX_UPDATES_PER_HOUR 20
MAX_CONNECTIONS_PER_HOUR 10
MAX_USER_CONNECTIONS 1;
Im vorigen Beispiel ist angegeben, dass der User v_personal_user innerhalb einer
Stunde maximal 30 Abfragen und 20 Updates auf die Tabelle personal_table_1
ausführen kann. Weiterhin darf er sich innerhalb einer Stunde maximal zehnmal
anmelden und darf weiterhin höchstens eine Verbindung zur Datenbank halten134.
Diese Angaben können natürlich den eigenen Gegebenheiten angepasst werden.
133
134
Weitere Informationen zum Skript mysqld_safe in der MySQL – Referenz unter:
http://dev.mysql.com/doc/refman/5.1/de/mysqld-safe.html, 09.09.2008
Weitere Hinweise zur Begrenzung von Benutzerressourcen unter MySQL findet man unter:
http://dev.mysql.com/doc/refman/5.1/de/user-resources.html, 09.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 80 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
6.2.4.
Anpassungen der Datei my.cnf
MySQL verwendet zur Konfiguration des Datenbankservers die Datei my.cnf. Hierin
werden Optionen bzw. Parameter angegeben, die auf den MySQL – Server
angewendet werden.
Darin werden z.B. die UNIX – Sockets festgelegt, über die der Datenbankserver
kommuniziert. Weiterhin befindet sich hier die Angabe des Ports, über den der
Server mit der Außenwelt in Erscheinung tritt. Dieser ist standardmäßig auf 3306
gestellt, sollte jedoch, da dieser Port Angreifern als Standardport bekannt ist,
geändert werden.
Weiterhin, ist hierin die maximal mögliche Anzahl von Verbindungen, die gleichzeitig
mit der Datenbank geführt werden können, anzugeben. Der von MySQL zur
Verfügung gestellte und hierfür zuständige Parameter max_connections kann je nach
Verwendungszweck entsprechend gesetzt werden.
Ebenfalls wird in dieser Datei der Betriebssystembenutzer angegeben, mit dem der
Datenbankserver gestartet wird. Dieser ist standardmäßig als mysql festgelegt.
Dieser kann und sollte jedoch durch einen Benutzer mit einem anderen Namen
ersetzt werden135.
6.2.5.
Eine abgesicherte Verbindung zur Datenbank
Seit der Version 5 existiert in MySQL ein Übertragungsverfahren, welches die
Kennwörter der Datenbankbenutzer, verschlüsselt zur Anmeldung beim MySQL –
Server überträgt. Vor dieser Version gab es in MySQL keine verschlüsselte
Übertragung von Passwörtern.
Alle weiteren Daten, die zur Datenbank übertragen werden, erfolgen standardmäßig
unverschlüsselt. Um eine sichere Übertragung zu gewährleisten, muss ein
Verschlüsselungsverfahren bzw. ein entsprechendes Netzwerkprotokoll gewählt
werden. MySQL bietet hierbei eine Unterstützung für die Protokolle Secure Socket
Layer (SSL) und die Secure Shell (SSH) an.
Bei
der
Verwendung
von
SSL
besteht,
neben
einer
verschlüsselten
Datenübertragung, weiterhin die Möglichkeit eine Authentifizierung durchzuführen.
SSL kann so konfiguriert werden, dass entweder nur der Server oder aber der Client
und der Server sich authentifizieren müssen. Der Einsatz eines SSL – Verfahrens
erfordert zwar einigen Aufwand, dient aber erheblich der Sicherheit des
Datenbanksystems.
6.3.
Fazit
MySQL bietet erstmals seit Version 5 ein stabiles und abgesichertes
Datenbanksystem an. In vorigen Versionen hörte man zu oft von irgendwelchen
Schwächen, was Performance, Sicherheit und nicht zuletzt Stabilität angeht.
Ein positiver Aspekt ist u.a. die Vermarktung als Open – Source – Produkt. Dies hat
wohl hauptsächlich dazu beigetragen, dass MySQL im Markt der Datenbanksysteme
135
Weitere Informationen zur Konfiguration der Datei my.cnf unter:
http://dev.mysql.com/doc/refman/5.1/de/option-files.html, 09.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 81 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
Fuß fassen konnte. Die Datenbankentwickler kommen also nicht nur von dem
Unternehmen MySQL AB, sondern von der ganzen Welt. Dies hat weiterhin den
Vorteil, dass viele der erkannten Fehler sehr schnell gefixt und in das
Datenbanksystem eingespielt werden können. Kostenlose Updates und Patches sind
dadurch schnell verfügbar136 und können relativ einfach eingespielt werden. Eine
Enterprise – Version für Unternehmen kann weiterhin für einen, im Datenbankmarkt
günstigen Preis, erworben werden. Für knapp 600 US – Dollar kann diese Version
gekauft werden, was weiterhin bedeutet, dass darin ein kompletter Support von
MySQL AB enthalten ist. Oracle hingegen, lässt sich seine Arbeit richtig gut bezahlen.
Allein die Verwendung der Oracle Advanced Security kostet für einen Prozessor ca.
10.000 US – Dollar.
Was auch nicht verachtet werden sollte, ist die Tatsache, dass MySQL in der
aktuellen Version schon viele Optionen sowie sicherheitsrelevante Eigenschaften
bietet. Jedoch muss auch festgehalten werden, dass der aktuellen MySQL – Version
noch viele simple aber dennoch sehr wichtige Eigenschaften fehlen. Leider gibt es
innerhalb des Datenbanksystems, außer einem gezielten Einsatz von Triggern auf die
Tabelle user, keine Möglichkeit zum Auditing, d.h. zur gezielten Protokollierung von
Datenbankereignissen. Oracle bietet dagegen unzählige Möglichkeiten, jegliche
Ereignisse, die mit der Datenbank in Verbindung stehen, zu dokumentieren.
Eine einfache Möglichkeit zur Administration von MySQL unter UNIX fehlt ebenfalls.
Hier wird dann gerne das Tool phpMyAdmin genannt. Doch in diesem Tool wurden
immer wieder schwerwiegende Sicherheitslücken entdeckt, was nicht gerade für
deren Verwendung spricht. Datenbankadministratoren sollten also immer auf
Zeilenebene arbeiten, was auf Dauer sehr viel Zeit kosten kann und damit zu Lasten
der eigentlichen Datenbankadministration geht. Oracle kann hier aufgrund der
Unterstützung von Drittanbietern und z.B. dem eigenen Oracle Enterprise Manager
einige Vorteile aufweisen.
Die Möglichkeit zur Verwendung von Benutzerressourcen könnte in MySQL ebenfalls
komplexer sein. Hier bietet das DEFAULT – Profil von Oracle schon viele Optionen,
die die Datenbankbenutzer zu einem, mehr oder weniger, sicheren Umgang mit dem
Datenbanksystem zwingen. Definierbare Rollen, wären für einen sicheren Umgang
mit Tabellen und deren Datenbankbenutzern, ebenfalls wünschenswert.
Fehlende Optionen und Eigenschaften können natürlich auch als ein positiver
Umstand gewertet werden. Dieses Datenbanksystem ist sehr schlank, was den
sicheren Umgang sicherlich erleichtert, da nicht viele, zusätzliche Schwachstellen
entstehen können.
Auch wird MySQL in der derzeitigen Version als sehr performant bezeichnet, was
hingegen bezweifelt werden darf. Während den Recherchen wurde festgestellt, dass
Performance sehr unterschiedliche Aussagen hervorruft. Einige bezeichnen einen
schnellen Umgang mit Datenbanktabellen, die 100.000 Einträge haben, als
performant. Bei anderen muss ein Datenbanksystem 100.000.000 und mehr
Einträge, einer einzelnen Tabelle, handeln können, was Oracle durchaus bietet.
Als Fazit sollte man doch festhalten, dass es ganz auf den Verwendungszweck
ankommt, wofür eine Datenbank benötigt wird. MySQL hat mit der Version 5 schon
einen wichtigen Schritt in die richtige Richtung getan. Jedoch erscheint es, gerade
sicherheitspolitisch, noch etwas wie ein Prototyp, der in der Versuchsphase steckt.
Oracle hingegen verfügt über 30 Jahre Erfahrung in der Datenbankentwicklung, was
sich auch in der immensen Verbreitung dieses Systems widerspiegelt.
136
Downloads in Bezug auf MySQL finden sich auf der MySQL – Homepage unter:
http://dev.mysql.com/downloads/mysql/5.0.html, 10.09.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 82 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 6: Oracle 11g vs. MySQL 5.0.67
Sicherheitstechnisch gesehen, hat Oracle viel mehr Möglichkeiten, Daten zu
verschlüsseln, bzw. sensible Daten sicher zu schützen. Weiterhin ist die Arbeit der
Datenbankadministratoren
und
der
Datenbankbenutzer
entweder
durch
entsprechende Tools oder auch durch die Verwendung von Optionen, wie z.B. Rollen,
besser zu kontrollieren und damit auch sicherer.
Wird ein einfacher Webshop betrieben, wird eine Datenhaltung für ein
mittelständiges Unternehmen oder ein einfaches Content – Management – System
benötigt, so kann MySQL ohne weiteres genutzt werden, da mittlerweile ja auch
schon sichere Netzwerkprotokolle wie SSL unterstützt werden. Bei größeren Shops
wie z.B. dem Unternehmen Amazon, könnte die Verwendung allerdings schon
schwieriger werden, da hier ein sicheres, performantes, stabiles und nicht zuletzt
wartbares Datenbanksystem benötigt wird, was Millionen von sensiblen Daten
beinhaltet. Das Oracle diese Eigenschaften erfüllt muss nicht weiter erwähnt werden
und bedarf auch keiner eingehenden Prüfung, da dies klar wird, wenn man die
Verwendung bei großen Unternehmen wie der BMW AG oder IKEA betrachtet.
In der Zukunft, wenn MySQL weiter ausgebaut und stetig verbessert wurde, kann
dieses Datenbanksystem sicherlich in Betracht gezogen werden. Doch zum jetzigen
Zeitpunkt, wird es wohl keine Konkurrenz, zu einem der großen Datenbanksysteme
wie Oracle darstellen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 83 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
7.
Penetrationstest
Ein gesichertes Datenbanksystem ist der beste Schutz vor Angreifern. Viele Angreifer
benutzen vorgefertigte Software, die sie aus dem Internet herunterladen, beliebige
Parameter eintragen und damit versuchen das IT – System bzw. Datenbanksystem
anzugreifen. Merken diese, dass der Angriff, aufgrund eines halbwegs gesicherten
Systems fehlschlägt, geben viele auch schon wieder auf und suchen sich ein anderes
Opfer bzw. ein anderes Ziel. Es gibt natürlich auch die Sorte von Angreifern, die sich
gezielt das bestimmte Datenbanksystem heraussuchen um Daten auszuspionieren
oder aber um das System auf irgendeine Art lahm zu legen. Nun, so wie jede
Software ihre Lücken hat, hat auch jedes ausgeklügelte Sicherheitssystem seine
Lücken. Irgendein Schlupfloch wird es immer geben. Letztlich wird es hauptsächlich
darauf ankommen allgemeine und bekannte Sicherheitslücken zu stopfen. Denn
wenn diese gestopft sind, bedarf es meist mehr als nur ein wenig Hintergrundwissen
und einen großen Zeitaufwand um in das gewünschte System einzudringen.
Die Erkenntnisse, die während der Erarbeitung dieser Diplomarbeit, im Rahmen der
Oracle – Sicherheit, gewonnen wurden, werden nun zum Teil dazu genutzt um ein
bestehendes Datenbanksystem auf seine Schwachstellen und Sicherheitslücken zu
testen. Hierbei wird die Oracle – Datenbank des Campus Gummersbach,
oras1.gm.fh-koeln.de, mit verschiedenen Bedrohungen konfrontiert. Die Datenbank
ist hauptsächlich für Übungszwecke von Studenten gedacht. In diesem
Zusammenhang, ist es sehr spannend herauszufinden, ob diese Datenbank vor
gewöhnlichen Attacken, z.B. von frustrierten Studenten bzw. Studentinnen,
geschützt ist. Hierzu werden verschiedene Mittel eingesetzt. Zuerst wird untersucht
ob die typischen, von Oracle verwendeten Ports offen stehen. Weiterhin wird die
Datenbank mit der Software Checkpwd des Unternehmens Red – Database –
Security und weiterführenden Maßnahmen auf typische Oracle – Schwachstellen hin
untersucht. Sind Schwachstellen zu erkennen, die ein Eindringen in das System
ermöglichen, so wird ebenfalls versucht, Berechtigungen zu erlangen, die denen
eines Administrators ähneln. In einem anschließenden Fazit wird die Sicherheit des
Datenbanksystems entsprechend bewährtet.
7.1.
Port – Scan
Kommuniziert ein IT – System mit seiner Umgebung erfolgt diese Kommunikation via
Ports. Zu Beginn des Penetrationstests wurde ein Port – Scan auf das bekannte
Datenbanksystem durchgeführt. Bei einem solchen Scan werden die einzelnen Ports,
die ein Rechner zur Verfügung stellt, untersucht und auf Zugänglichkeit geprüft. Ist
dem System eine Firewall vorgeschaltet, sind viele Ports geschlossen um es einem
Angreifer möglichst schwer zu machen in ein System einzudringen.
Um zu erkennen welche Ports offen sind, wurde die Software NMap bzw. Network
Mapper genutzt. Es handelt sich um ein Open – Source – Produkt, das auf der
Homepage http://nmap.org, kostenlos zum Download zur Verfügung steht. Es ist
eine sehr bekannte Software, die von vielen Netzwerkadministratoren bzw.
Penetrationstestern, zur Untersuchung einer Firewall bzw. eines Rechners, genutzt
wird.
Der Test wurde am 19.08.2008 um 22.30 Uhr gestartet und lieferte die Resultate,
die in Abbildung 7-1 und Abbildung 7-2 angezeigt sind.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 84 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-1: Port – Scan Ausgabe der Software NMap (Quelle: selbst erstellt)
Anhand der angezeigten Ergebnisse ist zu erkennen, welche Ports für die Außenwelt
geöffnet sind. Ebenfalls lässt das Programm erkennen welche Komponenten durch
die jeweiligen Ports angesteuert werden.
Auf den ersten Blick macht die Ausgabe in Abbildung 7-1 einen sehr sicheren
Eindruck, da nur wenige Ports über das Internet verfügbar sind bzw. waren.
Betrachtet man jedoch Abbildung 7-2, sind auf Anhieb einige Lücken zu erkennen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 85 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-2: Port – Scan Ausgabe inkl. Zusatzinformationen der Software NMap (Quelle: selbst erstellt)
In einer erweiterten Ausgabe sind neben den offenen Ports, detaillierte Anmerkungen
zu den etwaigen Komponenten zu erkennen. Neben der Ausgabe des Ports 8080 ist
z.B. ein
Hinweis zum verwendeten
Oracle –
System inkl. genauer
Versionsbeschreibung zu erkennen. Anhand dieser Information kann sich ein
Angreifer in aller Ruhe auf die Suche nach möglichen Angriffsmethoden machen.
Weiterhin zeigt die Ausgabe, dass hinter Port 1521 der Listener von Oracle zu finden
ist137.
Nach dem Port – Scan kann als Ergebnis festgehalten werden, dass neben der gut
geschützten Firewall auch einige Schwachstellen zu erkennen waren. Zum einen,
wird zum Zeitpunkt des Tests, der von Oracle verwendete Standardport 1521 zur
Verbindung mit dem Internet genutzt. Dies ist die erste Anlaufstation für Angreifer,
wenn sie versuchen in ein Oracle – Datenbanksystem einzudringen. Als zweite
Schwachstelle ist, wie bereits erwähnt, zu erkennen, dass die Datenbankversion vom
Internet ausgelesen werden kann. Angreifer können nun mit speziellen Angriffen, für
diese Oracle – Version, die Datenbank hacken.
137
Eine Liste mit von Oracle standardmäßig verwendeten Ports findet man unter:
http://www.red-database-security.com/whitepaper/oracle_default_ports.html, 28.08.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 86 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
7.2.
Angriff über Checkpwd
In diesem Abschnitt wird der erste Angriffsversuch auf das bekannte
Datenbanksystem erläutert. Dieser Angriff wurde mit dem von Red – Database –
Security zur Verfügung gestellten Tool Checkpwd (Version 1.21), am 21.08.2008
durchgeführt.
Der Angriff der durch das Programm erzeugt wird, besteht darin, dass die View
dba_users mit den darin enthaltenen Usernamen und den dazugehörigen
Passwörtern bzw. Hash – Werten ausgelesen und u.a. mit einer Textdatei, die
1.545.344 Passwörter enthält, abgeglichen wird. Wird nun ein Benutzer gefunden,
der ein Standardpasswort enthält, so wird dieser angezeigt.
Die erste Schwierigkeit lag darin, einen Datenbankbenutzer zu finden, der nicht nur
Zugriff auf die Datenbank sondern auch die Berechtigung hat, die angegebene View
und somit auch die DATA DICTIONARY auszulesen.
Dies stellte jedoch kein großes Problem dar. Nach einigen fehlgeschlagenen
Verbindungsversuchen mit der Datenbank und einigen in Abschnitt 5-4-3
angegebenen, von Oracle verwendeten Standardbenutzern, war nach gerade einmal
20 Minuten ein User gefunden, der sich mit der Datenbank verbinden konnte und
weiterhin die Berechtigung besaß, die DATA DICTIONARY – Views auszulesen.
Der Standardbenutzer DBSNMP war offen und bot, dank dem gleichnamigen
Kennwort, jedem Angreifer die Möglichkeit die besagte View auszulesen.
Checkpwd wurde nun mit dem User DBSNMP gestartet, wie folgende Abbildung zeigt:
Abbildung 7-3: Angriffsversuch mit Checkpwd (Quelle: selbst erstellt)
Nach ca. 32 Minuten war der Test abgeschlossen und lieferte aufschlussreiche
Ergebnisse.
Von insgesamt 381 festgestellten Datenbankaccounts konnte von 207 das Kennwort
ausgelesen werden. Von diesen 207 Benutzern waren 15 Benutzer gesperrt und
somit noch 192 Benutzer frei zugänglich. Eine positive Erscheinung war die Tatsache,
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 87 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
dass die 15 gesperrten Benutzer, hoch privilegierte Standardbenutzer waren, die
während der Installation des Datenbanksystems angelegt werden. Anhand der
Ausgabe des Programms konnte erkannt werden, dass bei einer Neuanlage eines
Benutzers kein großer Wert auf ein starkes Kennwort gelegt wird. Die
Datenbankadministratoren scheinen immer ein Kennwort zu vergeben, das gleich
dem Namen des Datenbankaccounts ist.
Weiterhin unangenehm aufgefallen sind insgesamt 18 Datenbankuser mit
ausgelesenen Kennwörtern, die von ihrer Benennung her, als Mitarbeiter der
Fachhochschule auszumachen sind oder zur Verwaltung des Datenbanksystems oder
deren Komponenten angelegt worden sein könnten. Die Kennwörter waren jeweils so
schwach gewählt, dass das Programm diese ermitteln konnte. Neben dem schon
erwähnten Fehler, dass viele Kennwörter gleich dem Benutzernamen waren,
enthielten einige sehr schwache und auch ohne Hilfsmittel der Software zu
erratenden Passwörter.
Das Ergebnis dieses Tests war unerwartend. Um in dieses Datenbanksystem
einzudringen wurde wenig Hintergrundwissen benötigt. Mit bekannten Standardusern
und frei verfügbaren Tools aus dem Internet, die eigentlich dazu dienen das DBS
sicherer zu machen, gelang es, in diese Datenbank einzudringen. In nur 30 Minuten
waren 207 User inkl. Kennwort ausgelesen. Mit entsprechend größerem Aufwand und
einer breit angelegten Brute – Force – Attacke, wäre es sicherlich möglich gewesen,
weitere Benutzer mit ausgelesenen Kennwörtern aufzuspüren.
7.3.
Untersuchung der ermittelten Datenbankbenutzer
Die bis dahin bekannten Datenbankbenutzer wurden nun noch etwas genauer
untersucht. Dies geschah mit dem Hilfsmittel OraCmd138. Neben vergebenen
Berechtigungen
an
die
einzelnen
Benutzer,
wurden
Inhalte
einzelner
Benutzertabellen sowie die Sicherheitsstufe, des standardmäßig zu verwendeten
DEFAULT – Profils, untersucht.
Die erste Erforschung der Datenbank geschah mit dem User DBSNMP. Da dieser User
die Berechtigung besitzt, jegliche Tabellen der DATA DICTIONARY auszulesen, wurde
versucht, hiermit herauszufinden, welche Profile, die unter Abschnitt 5-5-4 erläutert
wurden, konfiguriert sind. Nach Ausführung des SQL – Befehls
SELECT * FROM dba_profiles;
war die Anzeige ernüchternd. Neben dem standardmäßig zur Verfügung gestellten
DEFAULT – Profil wurden keine weiteren Profile, innerhalb der Datenbank, gefunden.
Weiterhin wurde in dem DEFAULT – Profil keiner der unter Abschnitt 5-5-4
angegebenen Parameter, die für eine sichere Verwaltung der Benutzer und der
Datenbank unabdingbar sind, gesetzt. Eine gute Methode zur sicheren Vergabe eines
starken
Kennworts
ist
z.B.
die
Nutzung
des
Parameters
PASSWORD_VERIFY_FUNCTION, mit einer entsprechend dafür hinterlegten Funktion.
Daneben ist aufgefallen, dass die vergebenen Kennwörter nie ablaufen, da
PASSWORD_LIFE_TIME
ebenfalls
nicht
gesetzt
ist.
Weiterhin
ist
FAILED_LOGIN_ATTEMPS nicht gesetzt, was dazu führt, dass ein Angreifer, mit
138
OraCmd ist eine Shareware des Unternehmens Withdata Software. Als Alternative zu SQL – Plus ist es
ein Kommandozeilentool, dass es über eine TCP / IP – Verbindung ermöglicht, ohne einen zuvor
installierten Oracle – Client, auf die Datenbank zuzugreifen und SQL – Befehle auszuführen.
http://www.withdata.com/oracmd.html, 30.08.2008
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 88 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
einem bekannten Benutzerkonto, auch mit falsch eingegebenen Kennwörtern, immer
wieder einen Angriffsversuch über dieses Konto starten kann, da das Benutzerkonto
nie gesperrt wird. Andererseits muss auch erwähnt werden, dass ein Setzen von
FAILED_LOGIN_ATTEMPS dazu führen kann, dass über eine Denial of Service –
Attacke der Datenbankserver sehr leicht lahm gelegt werden kann. Gerade, weil die
Datenbank für Studienzwecke verwendet wird und diese auch übers Internet
verfügbar
ist,
könnte
ein
mutmaßlicher
Angreifer
versuchen,
jeden
Datenbankaccount zu locken, indem er für jeden Benutzer der Datenbank oft genug
ein falsches Kennwort angibt. Wenn vor einer Klausur die Datenbank zu Lernzwecken
benötigt wird, könnte dies unangenehme Folgen für die Studenten haben.
Um herauszufinden, wer der eigentliche Administrator dieses Systems ist, wurde,
ebenfalls mit diesem Benutzer untersucht, wer die SYSDBA und SYSOPER –
Berechtigung, zur Administration der Datenbank, hat. Dies geschah mit folgendem
Statement:
SELECT * FROM v$pwfile_users;
Die unter Abbildung 7-4 gezeigte Ausgabe ergab, dass wohl der User ORACLE für die
Administration des Datenbanksystems verantwortlich ist. Ein potentieller Angreifer
würde nun versuchen, das Passwort dieses Benutzers, anhand des bekannten Hash –
Wertes, herauszufinden.
Abbildung 7-4: Inhalt der View v$pwfile_users (Quelle: selbst erstellt)
Die Untersuchung der weiteren Benutzer ergab ebenfalls einige Auffälligkeiten, die
nicht unerwähnt bleiben sollten.
Neben meist trivialen Daten, wurden zwei Datenbankbenutzer gefunden, die, nach
Rückfrage bei Fr. Prof. Dr. Faeskorn-Woyke, Informationen von Studenten (siehe
Abbildung 7-5) und Dozenten (siehe Abbildung 7-6) enthalten, die für die öffentliche
Stundenplanung verwendet werden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 89 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-5: Unkenntlich gemachte Studentendaten (Quelle: selbst erstellt)
Abbildung 7-6: Unkenntlich gemachte Daten von Dozenten (Quelle: selbst erstellt)
Als letzten Schwachpunkt muss die Berechtigungsvergabe erwähnt werden. Einige
der Benutzer, die von ihrer Benennung her, wahrscheinlich zu Mitarbeitern der
Fachhochschule gehörten, konnten weitreichende Systemberechtigungen ihr eigen
nennen. Berechtigungen wie CREATE ANY TRIGGER oder CREATE ANY DIRECTORY
gehörten dabei nicht zur Seltenheit.
Jeder der untersuchten User hatte weiterhin UNLIMITED TABLESPACE, was dazu
führt, dass ein Angreifer die Datenbankinstanz lahm legen kann, indem er in einem
beliebigen Datenbankschema so viele Daten ablegt, bis der vom Betriebssystem zur
Verfügung gestellte Speicher voll ist. Über die Rolle CONNECT ist auch die
Berechtigung CREATE DATABASE LINK vergeben, womit eine Verlinkung zu einer
entfernten Datenbank erfolgen kann um Daten und somit evtl. Schaden auf dem
System einzuschleusen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 90 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
7.4.
Die DBA – Rolle
Ein Ziel eines versierten Angreifers, ist wohl die Erlangung der Rolle DBA. Diese
wissen, dass dieser Rolle weitreichende Berechtigungen zugewiesen sind, die zur
Verwaltung des Datenbanksystems und der Datenbankbenutzer genutzt werden
kann.
Einige bekannte Lücken zur Erlangung dieser Rolle, die mittels SQL – Injection
ausgenutzt werden können und in Whitepapers und Präsentationen von Red –
Database – Security, zur Verfügung gestellt werden, brachten keinen Erfolg. Somit
kann davon ausgegangen werden, dass die Administratoren einige Sicherheits –
Pachtes eingespielt haben, die bekannte Lücken stopfen.
Doch nach einer Anfrage bei Hr. Alexander Kornbrust, Geschäftsführer von Red –
Database – Security, stellte dieser ein selbst geschriebenes Tool des Unternehmens
zur Verfügung, dass eine Lücke im Listener – Prozess dieser Datenbankversion
ausnutzt, um die DBA – Rolle zu erhalten. Diesem Tool wird als Parameter der
anzugreifende Host, der offene Port, ein beliebiger Datenbankbenutzer inkl. Passwort
und ein SQL – Befehl mitgegeben. Als SQL – Statement wurde „GRANT DBA TO
PUBLIC;“ ausgeführt. Das Tool verbindet sich dabei zur Datenbank und sendet den
Befehl „ALTER SESSION SET NLS_LANG=AMERICAN_AMERICA;“. Während diesem
Prozess führt das Datenbanksystem, in dem Kontext des Users SYS, diesen Befehl
aus und schreibt das Ergebnis in eine Datei des Oracle – Client. In diesem Falle in
oraclient9.dll. Danach wird durch das Tool der ALTER SESSION – Befehl durch den
Befehl „GRANT DBA TO PUBLIC;“ in der jeweiligen DLL ersetzt. Nach einem erneuten
Login auf die Datenbank wird das Statement aus der DLL ausgeführt und alle
Datenbankbenutzer haben die Rolle DBA. Die ausgenutzte Sicherheitslücke entsteht
dabei dadurch, dass das DBS den Code in der DLL bereits ausführt, bevor der LOGON
– Trigger des Datenbanksystems ausgeführt wird.
Die Rolle DBA wurde, innerhalb von OraCmd, sofort wieder mit dem Befehl „REVOKE
DBA FROM PUBLIC;“ den Usern entzogen. Jedoch wurde noch ein Benutzer
VB_WI_99 erstellt, dem die Rolle DBA zugewiesen wurde, wie das Ergebnis (siehe
Abbildung 7-7) des nachstehenden SQL – Befehls zeigt:
SELECT * FROM dba_role_privs
WHERE granted_role = ’DBA’;
Abbildung 7-7: Datenbankbenutzer mit der Rolle DBA (Quelle: selbst erstellt)
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 91 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Mit Hilfe des erstellten Benutzers VB_WI_99, wurden weitere Tabellen von
Datenbankbenutzern untersucht, dessen Kennwort zu Beginn nicht ermittelt werden
konnte. Hierbei wurden ebenfalls keine sensiblen Daten gefunden. Jedoch, wurde
innerhalb des einen Benutzerschemas, eine Tabelle mit Fragen gefunden, die von
ihrem Aufbau her wohl dazu diente, Klausuren mit Fragen zu bestücken. Daneben
gab es noch eine Tabelle Noten, die neben Noten auch noch eine Benutzer-Id
enthielt, die es ermöglichte, die Noten einem Namen in einer weiteren Tabelle
zuzuweisen.
Mit Erlangung dieser Rolle war das Ziel des Penetrationstests erreicht. Mit diesem
Benutzer konnte man nun, mehr oder weniger, die gesamte Datenbankinstanz
verwalten. Daten und Benutzer auslesen, Daten manipulieren und nicht zuletzt die
Datenbank lahm legen.
7.5.
Angriff über Oracle XML – DB
Wie bereits in Abbildung 7-2 zu erkennen, ist neben dem Port 1521 auch der Port
8080 geöffnet. Dahinter verbirgt sich die von Oracle zur Verfügung gestellte
Komponente XML – DB. Mit ihr ist es u.a. möglich XML – Dokumente in der
Datenbank abzuspeichern.
Da es in der vorliegenden Version 9.2.0.6, auch hierüber relativ einfach ist, in die
Datenbank einzudringen, wurde zuletzt versucht, hierüber die Passwörter der
Datenbankbenutzer auszulesen.
Zuerst wurde dabei, über einen gewöhnlichen Internetbrowser, die entsprechende
Webseite der Datenbank aufgerufen. Dies war, wie in Abbildung 7-2 zu sehen ist, die
Seite http://oras1.gm.fh-koeln.de:8080.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 92 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-8: Verbindungsversuch über Oracle XML – DB (Quelle: selbst erstellt)
Zur Authentifizierung wurde der bereits bekannte Standardbenutzer DBSNMP mit
dem dazugehörigen Passwort gewählt.
Nach erfolgreichem Login konnte, nach Eingabe nachfolgender URL, die Struktur der
Datenbankbenutzer ausgelesen werden:
http://oras1.gm.fh-koeln.de:8080/oradb/PUBLIC/ALL_USERS
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 93 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-9: Auslesen der Datenbankbenutzer über Oracle XML – DB (Quelle: selbst erstellt)
Nachdem nun alle Datenbankbenutzer inkl. dessen USER_ID angezeigt wurden,
konnte in einem letzten Schritt, der Hash – Wert der Kennwörter eines jeden
Datenbankaccounts, mit nachfolgender SQL – Injection, sichtbar gemacht werden:
http://oras1.gm.fh-koeln.de:8080/oradb/PUBLIC/ALL_USERS?transform=
'||(select%20username||'='||password%20from%20dba_users%20where%2
0user_id=0)||'
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 94 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
Abbildung 7-10: Kennwort des Datenbankbenutzers SYS (Quelle: selbst erstellt)
Wie der Versuch zeigt, ist es relativ simpel die Kennwörter der Datenbank, über
diese Komponente auszulesen. Die in der SQL – Injection benutzte USER_ID kann
natürlich durch jede, der in Abbildung 7-9 dargestellten USER_ID ersetzt werden.
7.6.
Fazit
Als Fazit kann ist festzuhalten, dass es sich um ein sehr anfälliges und für versierte
Angreifer lohnendes Datenbanksystem hält. Der Port – Scan inkl. eines ersten
Eindringens in die Datenbank, dem Auslesen aller Datenbankbenutzer und vielen
dazugehörigen Kennwörtern, hat gerade einmal vier Stunden gedauert. Daraus
resultierte eine schnelle Verfügbarkeit von Studenten- und Dozentendaten sowie
Telefonnummern, die jedoch für eine öffentliche Stundenplanung bestimmt und
daher sowieso öffentlich zugänglich sind.
Die in Abschnitt 7-5, über die Komponente Oracle XML – DB verursachte SQL –
Injection ist ebenfalls eine Lücke, die geschlossen werden sollte. Leider ist es über
die Webseite http://oras1.gm.fh-koeln.de:8080 möglich, dass sich dort jeder an der
Datenbank registrierte Datenbankbenutzer anmelden kann, was dazu führt, das jeder
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 95 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 7: Penetrationstest
dieser User, die Hash – Werte auslesen könnte und somit auch, früher oder später,
die einzelnen Kennwörter der Datenbank ermitteln könnte.
Die Anfälligkeit hängt zu einem großen Teil mit der verwendeten Datenbankversion
zusammen. Oracle 9i gilt, lt. Hr. Alexander Kornbrust, als ein System mit sehr vielen
Bugs und Sicherheitslücken, deren Angriffspunkte mittlerweile allgemein bekannt
sind.
Andererseits hätte ein schnelles Eindringen in die Datenbank leicht verhindert
werden können, indem alle während der Installation angelegten Standardbenutzer,
gesperrt gewesen wären. Die von den Administratoren erstellten Konten sollten
weiterhin kein Kennwort erhalten, das gleich dem Benutzernamen ist. Das von Oracle
zur Verfügung gestellte DEFAULT – Profil sollte ebenfalls durchdacht konfiguriert und
eingesetzt werden.
Auch wenn es sich um eine Datenbank handelt, die für Übungs- und Lehrzwecke
gedacht ist und keine sensiblen Daten enthält, sollten Dozenten und Mitarbeiter der
Fachhochschule, die mit einem von der Außenwelt ansprechbaren System arbeiten,
Kennwörter wählen, die nicht leicht auszumachen sind.
7.6.1.
Möglichkeiten zur Absicherung
Nach Rücksprache mit Hr. Alexander Kornbrust, wurden nachfolgende Punkte
entworfen, die zur Absicherung des Datenbanksystems eingesetzt werden sollten:
•
Den Oracle – Listener absichern (vgl. Abschnitt 5-7-1). Hierbei sollte
neben einem Passwort, innerhalb der Datei listener.ora, der Parameter
ADMIN_RESTRICTIONS auf den Wert ON gesetzt werden.
•
Schwache Passwörter durch starke ersetzen.
•
Die im DEFAULT – Profil (vgl. Abschnitt 5-5-4) erwähnte Funktion zur
Überprüfung eines Kennworts sollte ebenfalls konfiguriert und über das
Profil gesetzt werden.
•
Innerhalb der Betriebssystemdatei init.ora sollte entweder die Option
Oracle XML – DB deaktiviert oder der entsprechende Port der Firewall
geschlossen werden.
•
Die
CREATE
PROCEDURE
sollte,
wenn
möglich,
nicht
an
Datenbankbenutzer vergeben werden, da hierüber leicht SQL –
Injections durchgeführt werden können.
•
Um Angriffe zu erkennen, sind u.a. Trigger einzusetzen, die dann
mitprotokollieren, wenn SQL – Befehle der Datendefinitions- oder
Datenadministrationssprache abgesetzt werden. Weiterhin sollten
bestimmte SQL – Fehlermeldungen (die z.B. auf ein Eindringen
hinweisen) protokolliert werden.
•
Zuletzt sollte die vorhandene Version mit der Oracle – Version 9.2.0.8
bzw. der supporteten Version 10.2.0.4 gepatcht werden.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 96 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 8: Checkliste zum Inhalt eines Sicherheitsplans
8.
Checkliste zum Inhalt eines Sicherheitsplans
Nachdem nun die wichtigsten sicherheitsrelevanten Themen zum sicheren Betrieb
eines Oracle – Datenbanksystems erläutert wurden, soll in diesem Abschnitt, zu
guter letzt, eine Checkliste zur Verfügung gestellt werden. Grundlegende,
sicherheitsrelevante Aspekte werden noch mal zusammengestellt. Anhand dieser
Liste lässt es sich leichter nachvollziehen ob man wichtige Aspekte zur Sicherung des
Datenbanksystems vergessen hat und noch nachholen sollte.
8.1.
Die Systemlandschaft planen
Ein Angreifer hat es schwieriger, wenn er, anstatt nur einem Betriebssystem,
mehrere Systeme und Firewalls zu umgehen hat um z.B. an die Daten einer
Datenbank zu gelangen. Somit sollte die Systemlandschaft so geplant werden, dass
ein Angreifer möglichst viele Hürden überwinden muss um an sein Ziel und in diesem
Fall, an die gewünschten Daten zu gelangen. Folgende Aspekte sollten beim Planen
der Systemlandschaft beachtet werden:
•
Die richtige Wahl der Betriebssysteme (vgl. Abschnitt 5-2-1).
•
Eine Firewall bzw. mehrere Firewalls sollten eingesetzt werden um z.B.
nicht benötigte Ports des eingesetzten Betriebssystems zu schließen.
•
Innerhalb der Systemlandschaft sollten mehrere sicherheitsrelevante
Zonen eingesetzt werden. Dabei sollte eine Zone eingesetzt werden,
die nur mit dem Internet kommuniziert und keine Zugriffe, aus dem
Internet, in andere Zonen zulässt. Hierzu empfiehlt sich z.B. der
Einsatz einer bzw. mehrerer DMZ (vgl. Abschnitt 5-2-2).
Bei der Planung der Systemlandschaft sollte darauf geachtet werden, dass alle
eingesetzten
Komponenten
miteinander
harmonieren
und
zwischen
den
verschiedenen Komponenten wohl definierte Schnittstellen eingesetzt werden.
8.2.
Sicherung des Betriebssystems
Das Betriebssystem ist die Grundlage jeder lauffähigen Software. Ob das
Datenbanksystem selbst, das Intranet, der Webserver oder aber andere Software auf
dem jeweiligen System laufen. Es stellt meist die letzte Hürde vor einem möglichen
Angriff an die Software dar. Das Betriebssystem sollte daher u.a. mit folgenden
Maßnahmen gesichert werden:
•
Für das Root – Benutzerkonto sollte ein sicheres Passwort gesetzt sein
(vgl. Abschnitt 5-3-2).
•
Die Betriebssystemdateien sollten mit entsprechend vergebenen
Berechtigungen richtig geschützt sein (vgl. Abschnitt 5-3-1).
•
Es sollte nur die Software auf dem Betriebssystem installiert sein, die
auch wirklich benötigt wird.
•
Das Auditing des Betriebssystems sollte aktiviert werden, um
ungewöhnliche Ereignisse zu dokumentieren und darauf reagieren zu
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 97 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 8: Checkliste zum Inhalt eines Sicherheitsplans
können (vgl. Abschnitt 5-3-4).
•
Regelmäßig Patches auf dem Betriebssystem installieren.
Um alle möglichen Sicherheitsmaßnahmen, zum Schutz eines Betriebssystems
durchzuführen, ist es unumgänglich Administrationsbücher der jeweiligen Systeme
zu studieren 139.
8.3.
Das Datenbanksystem absichern
Das Datenbanksystem Oracle und der Schutz der darin enthaltenen Daten ist das
Kernstück dieser Arbeit. Das Datenbanksystem sollte mit allen Möglichkeiten die es
bietet, geschützt werden. Einige wichtige Schutzmaßnahmen werden noch mal kurz
zusammengefasst:
139
•
Die Standardbenutzer, die von Oracle mit installiert werden, sind zu
schützen. U.a. sollten ihnen sichere Kennwörter vergeben werden (vgl.
Abschnitt 5-4-3).
•
Es sollten nur die Anwendungen von Oracle installiert werden, die auch
wirklich Beachtung finden. Werden später weitere Komponenten
benötigt, so sollten diese nachinstalliert werden (vgl. Abschnitt 5-4-2).
•
Die Datenbankbenutzer sollten nur die Rollen und Berechtigungen
erhalten, die sie auch wirklich für ihre Arbeit benötigen. Hier gilt der
Grundsatz: „Lieber zu wenig Berechtigungen, als zu viele!“ (vgl.
Abschnitt 5-5-2 und Abschnitt 5-5-3).
•
Das von Oracle zur Verfügung gestellte DEFAULT – Profil sollte aktiviert
werden. Weiterhin sollte die damit zur Verfügung gestellte Funktion zur
sicheren Vergabe eines Passworts genutzt werden (vgl. Abschnitt 5-54).
•
Die im Zusammenhang mit Oracle verwendeten Dateien, die auf dem
Betriebssystem gespeichert werden, sollten gegen unerlaubten Zugriff
geschützt werden. Ist eine, im Rahmen der Oracle Advanced Security
enthaltene, Verschlüsselung verfügbar, sollte diese genutzt werden
(vgl. Abschnitt 6-1-3 und Abschnitt 6-1-4).
•
In Versionen vor Oracle 10g ist der Listener des Datenbanksystems mit
einem Kennwort gegen unerlaubten Zugriff zu schützen (vgl. Abschnitt
5-7-1 und Abschnitt 7-6-1).
•
SSL sollte zur Verschlüsselung des Netzwerkverkehrs aktiviert werden.
Sieht sich ein Datenbankadministrator ohne Verschlüsselung des
Datenverkehrs, z.B. über den Oracle Enterprise Manager, die Tabelle
der Datenbankbenutzer an, so werden die Hash – Werte der
Kennwörter unverschlüsselt übertragen (vgl. Abschnitt 5-7-1).
•
Um Angriffe auf das Datenbanksystem zu erkennen und darauf
reagieren zu können, sollte das Auditing bzw. entsprechende Trigger
des Datenbanksystems konfiguriert und aktiviert werden (vgl.
Abschnitt 5-6-4).
•
Der Arbeit der Datenbankadministratoren sollte nicht blind vertraut
Vgl. hierzu [Michael 2002]
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 98 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 8: Checkliste zum Inhalt eines Sicherheitsplans
werden. Ihre Arbeit sollte, nach Möglichkeit, kontrolliert werden.
•
8.4.
Sicherheits – Patches, die für das Datenbanksystem in der jeweiligen
Version zur Verfügung gestellt werden, sollten regelmäßig eingespielt
werden (vgl. Abschnitt 5-7-3).
Backups durchführen
Daten auf dem Datenbanksystem, wie auch Daten bzw. Dateien auf dem jeweiligen
Betriebssystem selbst, sollten durch Backups gesichert werden. Die Backups sollten
automatisiert ablaufen um ein regelmäßiges Backup zu gewährleisten. Sollten einmal
innerhalb der Datenbank durch einen Angriff mittels SQL – Injection, Daten verloren
gehen, so kann, durch Einspielung eines Backups, ein relativ aktueller Stand wieder
hergestellt werden (vgl. Abschnitt 5-7-2).
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 99 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 9: Fazit
9.
Fazit
Oracle – Datenbanksysteme sind am weitesten verbreitet, was den Fokus, in Bezug
auf Sicherheit, besonders auf dieses System lenkt. Nicht zuletzt deswegen, gibt es
eine Menge an Büchern, die sich nur mit der Absicherung dieses Datenbanksystems
beschäftigen. Ziel war es nun gewesen, einen Sicherheitsplan zu erstellen, der für
Oracle – Datenbanksysteme allgemein eingesetzt und auch für sensible Daten
verwendet werden kann. Oracle bietet zwar weitreichende und komplexe
Möglichkeiten zur Absicherung eines Datenbestandes und des Datenbanksystems an,
jedoch ist eine fast vollkommene Absicherung oft nur für einen immensen
Kostenaufwand zu erreichen, was auch nicht unbedingt bedeutet, dass damit alle
Sicherheitslücken gestopft sind.
Während den ganzen Recherchen zu dieser Arbeit, wurde erkannt, dass nicht nur die
Absicherung des Datenbanksystems selbst sondern auch die darauf einwirkenden
Umweltfaktoren betrachtet werden müssen. Dies führte zu der Erkenntnis, dass es
meist nur rein theoretisch möglich ist, eine Oracle – Datenbank vollkommen
abzusichern. In der Praxis ist es oft nicht möglich ist, ein Datenbanksystem
vollkommen abzusichern.
Organisationen und Unternehmen stellen meist wenig Zeit zur Verfügung, um einen
umfassenden Sicherheitsplan zu erstellen bzw. umzusetzen. Die Geschäftsprozesse
sind oft so aufgebaut, dass das wirkliche Absichern der Datenbank keine oder nur
wenig Beachtung findet. Datenbankadministratoren müssen in vielen Unternehmen
nicht selten über 1.000 Datenbanken administrieren. Allein die Einspielung eines
einzigen Security – Patches verschlingt dabei schon Unmengen an Zeit. Die
Datenbankbenutzer als auch die Datenbankadministratoren sind in dem Thema
Sicherheit weiterhin nicht ausreichend geschult, womit schon viele Schwachpunkte
erschlagen werden könnten. Ebenfalls trägt Oracle, mit der Preispolitik der Oracle
Advanced Security, nicht gerade dazu bei, umfassende Sicherheitsmaßnahmen, zur
Absicherung von sensiblen Daten, ohne weiteres einzusetzen.
Als Fazit kann festgehalten werden, dass ein halbwegs abgesichertes
Datenbanksystem bereits mit wenigen Handgriffen möglich ist. Es muss also
versucht werden, die Organisationen bzw. Unternehmen mehr für das Thema
Sicherheit zu sensibilisieren. Hier sollte ein Konsens zwischen einer ausreichenden
Produktivität und einer sicheren Datenbank erreicht werden. Wie man während des
Penetrationstests bereits gesehen hat, hätte die Absicherung der Standardbenutzer
und das Setzen eines Kennworts für den Oracle – Listener bereits dazu geführt, dass
zumindest ein erheblich höherer Zeitaufwand notwendig gewesen wäre, um in das
Datenbanksystem einzudringen. Allein dieser Aspekt, hätte wahrscheinlich schon die
meisten Angreifer davon abgehalten, weitere Versuche zu starten.
Der Sicherheitsaspekt in Datenbanksystemen wird in naher Zukunft immer weiter
zunehmen. Aufgrund der Globalisierung, der immer höher einzustufenden Wichtigkeit
des Internets sowie der damit zusammenhängenden Speicherung von sensiblen und
persönlichen Daten. Wie auch die aktuelle Diskussion der Öffentlichkeit beweist, ist
es nicht nur notwendig Datenbanksysteme selbst abzusichern. Einerseits müssen die
Personen, die mit den Datenbanken arbeiten einen anderen Blickwinkel zum Thema
Sicherheit erhalten und z.B. ihrem Datenbankkonto ein sicheres Kennwort vergeben.
Andererseits dürfen die Personen, deren sensible Daten abgespeichert in
Datenbanken vorhanden sind, nicht so leichtfertig mit ihren Daten umgehen. Solange
Personen bei jedem Preisausschreiben mitmachen und ihre Daten bereitwillig im
Internet irgendwelchen Unternehmen zur Verfügung stellen, bleibt es für Angreifer
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 100 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 9: Fazit
ein lohnendes Geschäft, in Datenbanksysteme
auszuspähen und diese zu verkaufen.
einzudringen,
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
sensible
Daten
Seite 101 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 10: Danksagung
10.
Danksagung
Diesen Abschnitt möchte ich nutzen, um mich bei einigen Personen, die mich bei
dieser Arbeit besonders unterstützt haben, zu danken.
Zuerst geht mein ganz besonderer Dank an Hr. Alexander Kornbrust, Geschäftsführer
des Unternehmens Red – Database – Security, der mir mit viel Mühe und einer
Unmenge von weitreichenden, nützlichen und praxisnahen Tipps zu diesem Ergebnis
verholfen hat.
Weiterhin möchte ich den Professorinnen Fr. Prof. Dr. Faeskorn - Woyke und Fr. Prof.
Dr. Bertelsmeier danken, die mich während des Studiums mit dem notwendigen
Wissen bereichert und mich schließlich zu diesem sehr interessanten Thema
hingeführt haben. Neben jeglicher Unterstützung habe ich die notwendige Kritik und
auch nützliche Tipps erhalten um dieser Arbeit ihr Gesicht zu geben.
Last but not least geht mein Dank an Thorsten Dahm und Alexander Plegnière sowie
an alle, die mich während der gesamten Regelstudienzeit von 10 Semestern
unentwegt unterstützt und mir auch bei dieser Arbeit nützliche und nicht zuletzt
grammatikalische Unterstützung zukommen ließen.
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 102 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 10: Danksagung
Literaturverzeichnis
[Bryla et al. 2007]
B. Bryla, K. Loney; Oracle Database 11g – DBA Handbuch – Eine
skalierbare und sichere Oracle Enterprise Datenbank administrieren;
Hanser Verlag; München 2008
[Faeskorn-Woyke et al. 2007]
H. Faeskorn-Woyke, B. Bertelsmeier, P. Riemer, E. Bauer;
Datenbanksysteme – Theorie und Praxis mit SQL2003 Oracle und MySQL;
Pearson Verlag; München 2007
[Michael 2002]
R. K. Michael; AIX 5L Administration – Guide to IBM’s 5. version of IBM –
AIX.; Mcgraw – Hill Verlag; California 2002
[Newman et al. 2004]
A. Newman, M. Theriault; Oracle Sicherheitshandbuch – Einen
umfassenden Sicherheitsplan in der Oracle – Umgebung implementieren;
Hanser Verlag; München 2004
[Kersken 2003]
S. Kersken; Kompendium der Informationstechnik; Galileo Press Verlag;
Bonn 2003
[kes 2007]
<kes> Zeitschrift für Informationssicherheit; Secu Media Verlag
Ingelheim, in Zusammenarbeit mit dem Bundesamt für Sicherheit in der
Informationstechnik; Ausgabe Nr. 3, Juli 2007
[Rüttger 2006]
M. Rüttger; MySQL 5 Professionell – Administration und Tuning; Mitp
Verlag; Heidelberg 2006
[Siebdrat 2007]
Prof. Dr. Siebdrat, Skript des WPF Betriebliche Anwendungssysteme –
Fachhochschule Köln im SS 2007
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 103 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 10: Danksagung
Abkürzungsverzeichnis
AES
Advanced Encryption Standard
BDSG
Bundesdatenschutzgesetz
BLOB
Binary Large Objects
BFILE
Binary File Large Objects
Bsp.
Beispiel
BSI
Bundesamt für Sicherheit in der Informationstechnologie
bzgl.
bezüglich
bzw.
beziehungsweise
ca.
circa
DAL
Data Administration Language
DBA
Datenbankadministrator
DBCA
Database Creation Assistent
DBMS
Datenbankmanagementsystem
DBS
Datenbanksystem
DDL
Data Definition Language
DES
Data Encryption Standard
DML
Data Manipulation Language
DMZ
Demilitarisierte Zone
DQL
Data Query Language
DoS
Denial of Service
evtl.
eventuell
FGA
Fine Grained Auditing
FGAC
Fine Grained Access Control
FTP
File Transfer Protokoll
ggf.
gegebenenfalls
GIS
Geographische Informationssysteme
inkl.
inklusive
i. d .R.
in der Regel
HTML
Hypertext Markup Language
MD5
Message Digest Algorithm 5
MS SQL
Microsoft SQL – Server
NTFS
New Technology File System
OAS
Oracle Advanced Security
OODBS
Objekt – Orientierte – Datenbanksysteme
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 104 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 10: Danksagung
ORDBS
Objekt – Relationale – Datenbanksysteme
OUI
Oracle Universal Installer
PHP
PHP Hypertext Preprocessor
RAC
Real Application Cluster
RDBS
Relationale – Datenbank – Systeme
RDBMS
Relationale – Datenbank – Management – Systeme
RLS
Row Level Security
RMAN
Oracle Recovery Manager
SCM
Service Controll Manager
SHA
Secure Hash Algorithm
SQL
Structured Query Language
SSH
Secure Shell
SSL
Secure Socket Layer
u. a.
unter anderem
u. U.
unter Umständen
Vgl.
Vergleiche
VPD
Virtual Private Database
VPN
Virtual Private Network
XML
Extensible Markup Language
XMLDBS
XML – Datenbanksysteme
z. B.
zum Beispiel
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 105 von 106
Erstellen eines Oracle-Sicherheitsplans
Kapitel 10: Danksagung
Eidesstattliche Erklärung
Gemäß § 26 (1) der DPO erkläre ich an Eides statt, dass ich die vorliegende
Arbeit selbständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient
und keine anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle
Stellen, die wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten
Schriften und anderen Quellen entnommen sind, habe ich als solche kenntlich
gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner
Prüfungsbehörde vorgelegen.
Saarbrücken, 05.10.2008
________
___________
(Christian Krämer)
Diplomarbeit – Fachhochschule Dortmund – Fachbereich – Informatik
Seite 106 von 106