“Erstellen eines Oracle – Sicherheitsplans“blogs.gm.fh-koeln.de/.../diplomarbeit_sicherheitsplan_oracle_dbs.pdf · “Erstellen eines Oracle ... Tabelle 5-6 Ein Ausschnitt der

Diplomarbeit

Thema:

Erstellen eines Oracle

Sicherheitsplans

Christian Krmer

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

Erstprferin: Prof. Dr. Heide Faeskorn - Woyke

Zweitprferin: Prof. Dr. Birgit Bertelsmeier

Fachbereich Informatik

Dortmund, 05.10.2008

Erstellen eines Oracle-Sicherheitsplans

Kapitel 1: Einleitung

Diplomarbeit Fachhochschule Dortmund Fachbereich Informatik Seite 2 von 106

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




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 Passwrter .......................................................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. Zustzliche Oracle Features.....................................................................35

5.4.3. Standardbenutzer und deren Passwrter .....................................................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. Benutzerpasswrter ..................................................................................53

5.5.6. Views ......................................................................................................55

5.5.7. Die Datenbankbenutzer SYS und SYSTEM ....................................................565.6. Sicherung mittels zustzlicher 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 ..................................................................................................645.7. Erweiterte Sicherheitsmanahmen..................................................................66

5.7.1. Netzwerksicherheit ...................................................................................67

5.7.2. Datenbankbackup.....................................................................................69

5.7.3. Abschlieende Sicherungsmglichkeiten ......................................................71

6. Oracle 11g vs. MySQL 5.0.67................................................. 74

6.1. Neuerungen in Oracle 11g .............................................................................74

6.1.1. Der Umgang mit Kennwrtern ....................................................................74

6.1.2. Verbessertes Auditing ...............................................................................76

6.1.3. Verschlsselung des Tablespace .................................................................76

6.1.4. Verschlsselung von Betriebssystemdateien.................................................766.2. Sicherheitsmglichkeiten in MySQL 5.0.67 .......................................................77

6.2.1. Absicherung mit dem Shellskript mysql_secure_installation ...........................77




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...............................................816.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. Mglichkeiten zur Absicherung ...................................................................96

8. 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 durchfhren ....................................................................................99

9. Fazit .................................................................................... 100

10. Danksagung ........................................................................ 102

Literaturverzeichnis................................................................... 103

Abkrzungsverzeichnis .............................................................. 104

Eidesstattliche Erklrung ........................................................... 106




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




Tabellenverzeichnis

Tabelle 2-1: Bekannte DBS-Typen (Quelle: [Kersken 2003] Seite 131 ff.) .............12

Tabelle 3-1: 2006 gettigte Angriffsformen (Quelle: [kes 2007])..........................17

Tabelle 3-2 Schutzziele fr 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 Zustzliche Oracle Softwarekomponenten (Quelle: selbst erstellt) .....38

Tabelle 5-3 Standardbenutzer und deren Passwrter (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/privileges-

options.html, 08.09.2008) .........................................................................79

http://www.bsi.bund.dehttp://www.petefinnigan.com/default/oracle_default_passwords.htmhttp://dev.mysql.com/doc/refman/5.1/de/privileges-




1. Einleitung

Bereits der berhmte amerikanische Psychologe Prof. Abraham Harald Maslow1 hat im Jahre 1943 das Thema Sicherheit in seiner Bedrfnispyramide als eines der wichtigsten menschlichen Bedrfnisse benannt. Daran ist zu erkennen, wie wichtig Sicherheit fr den Menschen ist. Hierbei spielt es kaum eine Rolle in welchem Zusammenhang dieses Thema verwendet wird.

Whrend 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 gewnscht und sollte grtmgliche Prioritt haben um Daten jeglicher Art zu schtzen3.

Zu anfnglichen Zeiten der IT verstand man unter IT Sicherheit lediglich die Sicherstellung der korrekten Funktionsweise von Hard- und Software. Mittlerweile geht es lngst nicht nur um korrekte Funktionsweisen. Unmengen von Software und Hardware existieren auf dem Markt. Das Internet, daraus resultierende Bedrohungen und die weltweite Mglichkeit auf Informationen der genannten Komponenten zuzugreifen, lieen Sicherheitslcken darin erkennen und machen ein System bzw. deren Komponenten angreifbar. Viele, erst im Laufe der Jahre aufgetauchtenBedrohungen (siehe Abschnitt 3-1) eines IT Systems4, machen es notwendig,prventive Manahmen zu ergreifen um ein System und dessen Komponenten zu schtzen.

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, bentigt fast jedes grere Unternehmen bzw. jede grere Organisation zur Verwaltung der riesigen Datenmengen ein DBS5. Ob private Kundeninformationen oder aber Informationen ber Studenten und deren Benotungen. Ein DBS sollte einen grtmglichen Schutz genieen.

Um ein DBS richtig zu schtzen 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 knnen in einen Sicherheitsplan flieen, mit dem man ein Datenbanksystem besser schtzen kann.

1 Er lebte vom 01.04.1908 bis 08.06.1970 in Brooklyn, New York.2 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.3 Diesbezglich sei zu erwhnen, dass es aktuell Politiker gibt, die diese Ansicht wohl nicht voll und

ganz teilen.4 Ein System zur Beschaffung, Verarbeitung, Speicherung, bertragung und Bereitstellung von

Informationen bzw. Daten (Wichtige Komponenten: Hardware, Software, Menschen, Datenbanken).Vgl. [Siebdrat 2007]

5 DBS ist eine gelufige Abkrzung fr Datenbanksystem.




1.1. Motivation und Hintergrund

Da die Bedeutung des Themas IT Sicherheit in den letzten Jahren immer mehr zugenommen hat, ist es ein grundlegendes Bedrfnis, Komponenten (in diesem Falle ein Datenbanksystem) eines IT Systems zu schtzen.

Zur Durchsetzung von Sicherheitsmanahmen und anforderungen ist es hilfreich einen Sicherheitsplan einzufhren. In diesem Plan sollten alle mglichen Schwachstellen, Bedrohungen, Hintergrundinformationen und natrlich auch Gegenmanahmen verankert und erlutert sein. Somit wird es den auszufhrenden Personen erleichtert, die Manahmen zur Sicherung des Datenbanksystems umzusetzen.

Die Fachhochschule Kln (Campus Gummersbach) setzt in ihrer aktuellen Systemlandschaft ein Oracle- und ein MySQL Datenbanksystem ein. Das Oracle-sowie das MySQL Datenbanksystem werden von der Verwaltung der Fachhochschule z.B. fr die Erfassung von Stundenplnen und Daten von Studenten bzw. Lehrkrften eingesetzt. Von den Studenten und Lehrkrften werden die Systeme ebenfalls zu Vorlesungs- und bungszwecken benutzt.

Im Hinblick auf Oracle und MySQL bekommen Studenten einen berblick darber, 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 fr ein Oracle Datenbanksystem zu erstellen. Zu diesem Sicherheitsplan werden Umwelteinflsse, wie der Begriff der Sicherheit oder aber Angriffe auf ein IT- und Datenbanksystem ebenso kritisch begutachtet wie die Mglichkeiten, die Oracle bietet, um Sicherheit innerhalb eines Datenbanksystems umzusetzen. Dieser Sicherheitsplan wird so ausgelegt sein, dass der Schutz sicherungsbedrftiger Daten hchste Prioritt hat.

Die Erkenntnisse zur Erarbeitung dieses Sicherheitsplans werden dazu genutzt eine Datenbankinstallation am Campus Gummersbach auf Sicherheitslcken 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 whrend der vorlesungsfreien Zeit ber das Internet genutzt werden kann, werden hauptschlich Angriffe von auen, mittels eines

6 Dies ist eine Installation die hauptschlich zu bungszwecken fr Studenten dient.

http://oras1.gm.fh-koeln.de




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 erlutert. Innerhalb der Datenbanksysteme werden die fr 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 knnen. 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 Sicherheitsmglichkeiten und tools der Datenbanksysteme Oracle und MySQL werden in den aktuellen produktiven Versionen 11g in einem separaten Abschnitt gegeneinander gestellt. Die Mglichkeiten der beiden Systeme werden betrachtet, zweckgebunden untersucht und objektiv bewertet.

Anhand der genannten Absicherungsmglichkeiten wird das, an der Fachhochschule Kln (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 berprfen.

7 Ein Penetrationstest ist in der Informatik eine Methode, um Sicherheitsschwachstellen festzustellen.8 Versionsstand vom 10.09.2008

http://oras1.gm.fh-koeln.de


Kapitel 2: Datenbanksysteme


2. Datenbanksysteme

Die Wichtigkeit von Sicherheit in Datenbanksystemen hat erst die letzten Jahre enorm zugenommen. Whrend man DBS zu Beginn hauptschlich in groen Unternehmen auf Grorechnern einsetzte9, findet man heute, innerhalb des Internets, hinter sehr vielen, vor allem kommerziellen Homepages Datenbanken. Ob man bei Amazon10 Bcher bestellt, bei seiner Bank eine Online berweisung ttigt, bei Ebay11 an einer Auktion teilnimmt, sich bei einer Versicherung ein Online Angebot ausrechnen lsst oder ob man einen SQL Test auf der Website einer Professorin der Fachhochschule Kln ausfhrt. Hinter all den genannten Beispielenstecken Datenbanksysteme mit Millionen von Daten. Unternehmen wie die BMW AG12

oder Oracle selbst, verwenden zur Verwaltung ihrer groen Datenmenge tausende von Datenbanken. Viele der enthaltenen Daten sind nicht unbedingt schutzbedrftig. 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 zugnglich zu machen. Nein, sie haben auch die Aufgabe, die enthaltenen Daten zu schtzen. Die vermehrt kommerzielle Ausrichtung des Internets, die groe Menge an Daten, die tglich ber die Datenleitungen fliet und die unberschaubare Anzahl an Nutzern des Internets haben die Anforderungen an Sicherheit von Datenbanksystemen grundlegend verndert. Datenbanksysteme mssen daher ein gewisses Ma an Vertraulichkeit, Integritt und Verfgbarkeit 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 fr 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 Integritt (siehe Abschnitt 3-2), meist ein schwieriges Im- und Export Verfahren ber eine zuvor definierte Schnittstelle notwendig um die Daten verwenden zu knnen. Ein weiterer, damit verbundener Nachteil war die Redundanz14 der Daten. Die gleichen Daten standen mehrmals zur Verfgung, 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 erwhnte Im- und Export Verfahren wieder durchgefhrt wurde.

9 z.B. Das IBM Betriebssystem OS390 mit dem Datenbanksystem DB2.10 http://www.amazon.de 20.05.200811 http://www.ebay.de 20.05.200812 http://www.bmwgroup.com 10.09.200813 Als Flatfiles werden einfache Textdateien bezeichnet.14 Redundanz bedeutet, dass Daten mit gleichem Informationsgehalt mehrfach vorkommen.15 Inkonsistenz besagt, dass Datenzusammenhnge widersprchlich sind.

http://www.amazon.dehttp://www.ebay.dehttp://www.bmwgroup.com




Aufgrund immer komplexer gewordenen Datenstrukturen, der Notwendigkeit Datenbestnde immer aktuell zu halten und der Bedarf von Unabhngigkeit zwischen Daten und Programm sorgten schlielich Ende der 60er Jahre fr 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 Verfgung 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 Erluterung

RDBMS20

(Relationale-

Datenbank-

Management-

Systeme)

Relationale Datenbanken bieten die Mglichkeit,

Einzeltabellen miteinander zu verknpfen (Relationen).

Informationen, die an verschiedenen Stellen bentigt werden,

mssen nur einmal aufgefhrt werden. Es handelt sich hier

um die am meisten benutzten Datenbanksysteme (z.B.

MySQL und Oracle).

OODBS

(Objekt- Orientierte-

Datenbanksysteme)

Diese Datenbanken arbeiten auf der Grundlage von Klassen

und Objekten. Im Gegensatz zu relationalen Datenbanken

besteht bei ihnen die Mglichkeit nicht lineare Beziehungen

zwischen den Informationen abzubilden (z.B. O2 DBS). Eine

Mischform zwischen RDBMS und OODBS sind ORDBS (Objekt

Relationale Datenbanksysteme).

XMLDBS

XML-

Datenbanksysteme21

Diese Datenbanken speichern die Informationen in Form von

XML Dokumenten ab. Da der Austausch von Informationen

mit Hilfe von XML Dokumenten die letzten Jahre sehr

zugenommen hat (einheitliche Schnittstellen), bieten diese

die Mglichkeit, die erhaltenen Informationen direkt

abzuspeichern ohne das Dokument noch parsen zu mssen

(z.B. das Datenbanksystem Tamino).

16 Siehe [Faeskorn-Woyke et al. 2007] Seite 21 ff.17 In der Datenbasis sind die Daten der Datenbank enthalten.18 Das DBMS managt und kontrolliert das Datenbanksystem.19 Siehe [Faeskorn-Woyke et al. 2007] Seite 2120 Es wird auch der Begriff RDBS benutzt, jedoch hat der Begriff RDBMS im Internet die grte

Verbreitung, weshalb dieser Begriff in dieser Arbeit verwendet wird.21 Oracle bietet ebenfalls eine Methode zur Speicherung von XML Dateien.




Hierarchische

Datenbanksysteme

Die Verknpfung der Datenobjekte erfolgt hier ber eine

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

Datenbanksysteme

Die Datenobjekte sind ber Netzwerke miteinander

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

fhrend im Datenbankgeschft 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 Lizenzumstze eines Unternehmens als Kenngre fr den Markt von Datenbanksystemen nutzen, kann nur anhand der groen Verbreitung, hauptschlich im Internet, vermutet werden, dass das Unternehmen schon viele Teile des Datenbankmarktes fr 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 verffentlicht.

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 verffentlicht, die es als richtiges relationales Datenbanksystem erkennen lieen25, jedoch ist diese Weiterentwicklung erst durch die daraus erwachsene Popularitt und dem unermdlichen Eifer der Open Source Programmierer zu verdanken.

So existiert z.B. erst seit der Version 4.1 die Untersttzung von Subselects oder unterschiedlicher Zeichenstze, was fr den Einsatz auf dem weltweiten Markt sehr

22 Lt. Oracle Corporation ist Oracle das derzeit fhrende Datenbanksystem.http://www.oracle.com, 20.03.2008

23 MS SQL ist ein von Microsoft und Sybase in Kooperation entwickeltes relationales Datenbanksystem.http://de.wikipedia.org/wiki/Microsoft_SQL_Server, 15.09.2008

24 Vgl. hierzu die Geschichte der Datenbanksysteme unter:http://de.wikipedia.org/wiki/Datenbanksystem#Geschichte, 20.04.2008

25 Einen tieferen Einblick in die Regeln einer relationalen Datenbank kann man ber das im Addison-Wesley Verlag erschiene Buch von E.F. Codd erhalten: "The Relational Model for Database Management"

http://www.oracle.comhttp://de.wikipedia.org/wiki/Microsoft_SQL_Serverhttp://de.wikipedia.org/wiki/Datenbanksystem#Geschichte




wichtig ist. Mit Version 5.0 kamen weitere wesentliche nderungen26, die es MySQL ermglichen werden, im Markt der kommerziellen Datenbanksysteme zu bestehenund frher oder spter, in groen Unternehmen Fu zu fassen. Neben wichtigen Neuerungen im Bezug auf Sicherheit sei die Einfhrung von Views27, Stored Procedures oder auch Trigger, genannt28.

MySQL existiert mittlerweile in der Version 629. Diese Version ist derzeit nur im Alpha Release verfgbar. In Abschnitt 6-2 werden daher nur die zur Verfgung 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 grndeten 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 Codeprogrammiert, wurde 1979 die erste Oracle Version verffentlicht, die SQL untersttzt.

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 mglich 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 untersttzt Oracle mittlerweile eine Datenbankintegration fr Java und .NET. Darber hinaus ist es in Oracle mglich ber definierte Schnittstellen andere Programme in anderen Programmiersprachen anzusprechen. Somit knnen die, in der Datenbank enthaltenen Daten, auch Programmen zugnglich 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-1genauer erlutert werden, sind schon lngere Zeit Features integriert, die in MySQL erst seit kurzem verfgbar sind (z.B. Trigger, Views und Stored Procedures),ebenso implementiert, wie viele Development- und Administrationstools. Weiterhin hat Oracle, aufgrund der groen Verbreitung, den Vorteil, dass sich viele Softwareunternehmen darauf spezialisiert haben, Software zu entwickeln, die den Umgang mit dem Datenbanksystem erleichtert32.

Oracle ist alleiniger Anfhrer 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 Marktfhrerschaft des gesamten Datenbankmarktes

26 Vgl. [Rttger 2006] Seite 44 ff. 27 Eine View ist eine Select Abfrage auf eine oder mehrere Tabellen, die logisch als eine eigene Tabelle

abgelegt wird.28 Vgl. [Rttger 2006] Seite 44 ff.29 http://dev.mysql.com/downloads/mysql/6.0.html, 15.09.200830 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.31 http://www.oracle.com/profit/features/p27anniv_timeline.pdf, 22.05.2008

Dieses Dokument wurde von Oracle aufgrund des 30 jhrigen Jubilums 2007 verffentlicht.32 Ein bekanntes Development Tool ist z.B. der SQL Navigator des Unternehmens Quest Software.33 http://www.siemens.de, 15.09.2008

http://dev.mysql.com/downloads/mysql/6.0.htmlhttp://www.oracle.com/profit/features/p27anniv_timeline.pdfhttp://www.siemens.de




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 jhrigen Erfahrung schon viele Kinderkrankheiten ausgemerzt und wichtige Zusatzfeatures implementiert hat. Im Laufe der Zeit wurde das Datenbanksystem aber auch immer mehr mit zustzlichen Tools und Features aufgeblht, die bestimmt nicht alle fr den reibungslosen Betrieb eines relationalen Datenbanksystems notwendig sind (vgl. Abschnitt 5-4-2). Jedoch ist MySQL, als Open Source Produkt, kostenlos nutzbarund mit den richtigen Programmierkenntnissen selbstndig erweiterbar, was jedocheine nachfolgende Verffentlichung des selbst programmierten Quellcodes voraussetzt.

34 Vgl. [Faeskorn-Woyke et al. 2007] Seite 48


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, mchte ich zunchst auf die wesentlichen Grnde fr 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 erhhen sollen. Von daher ist fr Unternehmen die Einhaltung von Sicherheitsvorkehrungenprimr 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 stndig arbeiten, die Nennung eines Datenschutzbeauftragten36 hervor, welcher die Einhaltung der Datenschutzrichtlinien innerhalb des Unternehmens berprft und diese durchsetzt. Bei gravierenden Missstnden kann die Aufsichtsbehrde 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 zhlen z.B. Angriffe, also vorstzliche Ereignisse sowie zufllige Ereignisse und unabsichtliche Fehler.

3.1. Bedrohungen

Unternehmen drfen ihre Datenverarbeitung nur mittels Einhaltung der eben genannten Gesetze berhaupt durchfhren. Fr 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 natrlich erwhnen muss, dass die primren Grnde, also die Gesetze, erst durch die informationstechnischen Bedrohungen entstanden sind.

Einen berblick ber mgliche Bedrohungen und damit die Ursache allen bels gibtnachfolgende Abbildung:

35 Die entsprechenden Vorschriften und Mglichkeiten zur Einhaltung dieser Pflichten findet man auf der Homepage des Bundesamtes fr Sicherheit in der Informationstechnik unter:http://www.bsi.bund.de, 07.06.2008

36 Vgl. http://www.ihk-muenchen.de/internet/mike/ihk_geschaeftsfelder/recht/Datenschutz/ Datenschutzbeauftragter.html, 17.06.2008

http://www.bsi.bund.dehttp://www.ihk-muenchen.de/internet/mike/ihk_geschaeftsfelder/recht/Datenschutz/




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 alshauptstzliche Schutzmanahme, die Durchfhrung regelmiger Backups sowie die Einspielung aktueller Patches37 genannt werden. Da Menschen auch durch menschliches Versagen zur Bedrohung werden knnen, kann mit regelmigen Schulungen versucht werden, zur richtigen Handhabung mit den ihnen anvertrauten Daten, der Bedrohung entgegenzuwirken.

Problematisch wird es jedoch bei Menschen die vorstzlich durch Angriffe, zur Bedrohung werden. Ihr Handeln muss man entweder Erahnen oder aber es gibt bereits Erfahrungswerte durch gettigte Angriffe, die zur Sicherheitsvorkehrung verwendet werden knnen. Durch Angriffe wurden z.B. 2005 den Unternehmen CardSystems und Choiceline 40 Mio. bzw. 1 Mio. Kreditkartendaten entwendet38. Im August 2008 wurde auerdem bekannt, dass dem deutschen Unternehmen SKL(Sddeutsche Klassenlotterie), Bankdaten von ca. 17.000 Kunden gestohlen worden sind39.

Nachfolgende Tabelle erlutert die 2006 am meisten in Erscheinung getretenen Angriffsformen:

37 Ein Patch fhrt eine Fehlerbereinigung durch die Ersetzung einzelner Programmteile durch.38 Dies geht aus einer Studie des Identity Theft Resource Center vom September 2005 hervor.

www.idtheftcenter.org/breaches.pdf, 26.05.200839 Vgl. http://www.heise.de/newsticker/Verbraucherzentrale-Massenhafter-Missbrauch-von-Bankkonten-

Daten-2-Update--/meldung/114124, 21.09.2008

http://www.idtheftcenter.org/breaches.pdfhttp://www.heise.de/newsticker/Verbraucherzentrale-Massenhafter-Missbrauch-von-Bankkonten-




Angriffsform Erluterung

Malware Als Malware bezeichnet man meist getarnte Software, die eine

vom Benutzer unerwnschte ggf. schdliche Funktion ausfhrt.

Hierunter fallen z.B. Viren, Wrmer und Trojaner. 2006 fielen

35% auf diese Angriffsform zurck.

Unbefugte

Kenntnisnahme

Hierunter fllt jeder Angriff, der darauf abzielt Daten auszulesen,

die nicht fr die auslesende Person bestimmt sind (vgl. Tabelle 4-

1). Hierunter zhlt man z.B. Abhrversuche und Analysen des

Kommunikationsverhaltens. 12% aller Angriffe wurden hierber

gettigt.

Cracker Cracker hacken mit bser Absicht. Sie dringen in Netze / Rechner

ein, um dort Schaden anzurichten. Sie lschen, ndern oder

missbrauchen geschtzte Datenbestnde. 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

Bereicherung

Diese Form des Angriffs ist dann gegeben, wenn Programme oder

auch Berechtigungen eines DBS dahingehend manipuliert werden

um hauptschlich Daten eines Systems auszusphen (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 schdigen. Z.B.

zhlen Denial of Service Attacken (Gezielte Bombardierung

eines Servers, damit dieser den Dienst einstellt.) oder die

bswillige Abschaltung einer Homepage dazu. 10% aller Angriffe

entfielen auf diese Angriffsform.

Tabelle 3-1: 2006 gettigte 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.




Anhand dieser Tabelle ist zu erkennen, dass die meisten Schden 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 Sicherheitslcken fast jeder Software im Internet nachgeschlagen werden knnen. Meist gibt es auf entsprechenden Homepages genaue Beschreibungen wie man die Lcken ausnutzen kann. Da sich viele Angriffe gegen Sicherheitslcken richten, die schon lange bekannt sind, wrde meist schon das regelmige Einspielen von sicherheitsrelevanten Patches gengen um vielen Angriffen den Wind aus den Segeln zu nehmen.

3.1.1. Interne Angriffe

Gegenber der Angriffsform, wird weiterhin unterschieden ob ein Angriff innerhalb oder auerhalb eines IT Systems durchgefhrt wird. Die einhellige Meinung, die jeder hat, wenn er von Angriffen auf ein IT System hrt, ist, dass Eindringlinge diemeisten Verursacher von Einbrchen 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 groe Mengen ihres IT Budgets fr die Entwicklung einer sicheren Systemlandschaft, inkl. Firewall und Betriebssystem aus, ohne von der grten 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 fr die Benutzer von Datenbanksystemen von Nten42.

3.1.2. Externe Angriffe

Hrt 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 zhlen z.B., wie unter Abschnitt 3-1 bereits erwhnt, 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. zurVersendung von Denial of Service- oder Spam Attacken.

3.2. Sicherheit lt. BSI

Wie bereits erwhnt, wirken viele Bedrohungen auf ein IT System und damit auch auf deren Komponenten. In unserem Falle auf ein Datenbanksystem. Das Bundesamt fr 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 erlutert:

41 Lt. einer Studie von Computer Security Institute and FBI Survey im Jahre 2004.42 Vgl. Abschnitt 5-5-2




Schutzziel Erluterung

Verfgbarkeit Die Verfgbarkeit soll gewhrleistet werden. Die Funktionen bzw.

Services eines IT Systems bzw. einer darin enthaltenen

Komponente sowie deren enthaltene Daten sollen dauerhaft zur

Verfgung stehen.

Integritt Die Daten innerhalb einer Komponente sollten nur von Befugten in

beabsichtigter Weise vollstndig, widerspruchsfrei und korrekt

verarbeitet werden, da ansonsten der Verlust der Integritt

gegeben ist.

Vertraulichkeit Die in einer Komponente enthalten Daten drfen nur befugten

Personen zugnglich sein. D.h. es soll kein unbefugter

Informationsgewinn erfolgen.

Tabelle 3-2 Schutzziele fr Sicherheit im IT System (Quelle: http://www.bsi.bund.de, 15.03.2008)

Diese Schutzziele bilden die Grundlage zur Erstellung einer Risikobewertung, einerberprfung des vorhandenen IT Sicherheitsniveaus sowie einer Implementierung und den Aufbau einer IT Sicherheitsorganisation.

http://www.bsi.bund.de


Kapitel 4: Umsetzung von Sicherheit in Datenbanksystemen


4. Umsetzung von Sicherheit in

Datenbanksystemen

Sicherheit in Datenbanksystemen ist ein sehr komplexes Thema. Datenbanksysteme sind hufig 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 hufig durch die Client Anwendungen der Datenbanksysteme verursacht, wobei z.B. die Wahl der Passwrter 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 greres Augenmerk auf Sicherheit. So wurden z.B. bis Ende 2006 schon 28444

Sicherheitsfehler ausgemerzt. 87 dieser Sicherheitslcken betrafen hierbeiSchwachstellen der Datenbank selbst.

Die nachfolgenden Teilabschnitte beschftigen 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 zusammenhngenden Datensicherheit wurden vom Bundesamt fr Sicherheit in der Informationstechnik die Acht Gebote der Datensicherheit entworfen. Sie sind in 9des BDSG45 verankert. Sie sollten innerhalb der Verwendung eines Datenbanksystems ebenfalls Beachtung finden.

Gebot Erluterung

Zutrittskontrolle Bei diesem Gebot sollten nur befugte Personen Zugriff auf die

Daten haben drfen.

Zugangskontrolle Bei den zugreifenden Personen soll eine Authentifizierung46

durchgefhrt werden. D.h. dass die entsprechende Person nur

mit eigenem Usernamen und Kennwort auf das System

zugreifen darf.

43 Vgl. Abschnitt 5-244 Vgl. http://www.red-database-security.com/wp/doag_best_of_oracle_security_2006.pdf, 26.05.2008

Red Database Security GmbH ist Spezialist fr das Thema Sicherheit im Oracle Umfeld.45 BundesDatenSchutzGesetz46 Als Authentifizierung wird die berprfung einer vorgegebenen Identitt bezeichnet.

http://www.red-database-security.com/wp/doag_best_of_oracle_security_2006.pdf




Zugriffskontrolle Mittels Autorisierung47 wird geprft, ob den zugreifenden

Personen das Recht zuteil wird eine bestimmte Aktion

durchzufhren bzw. bestimmte Daten auszulesen.

Weitergabe-

kontrolle

Personen drfen ihnen anvertraute Daten nicht an unberechtigte

Personen weitergeben.

Eingabekontrolle Hier soll nachgeprft werden, welche Person, wann, welche

Daten im System eingegeben hat.

Auftragskontrolle Es soll z.B. mittels eines Berechtigungssystems innerhalb des

DBS berprft werden, welche Personen bestimmte Prozesse

anstoen, durchfhren und beenden drfen.

Verfgbarkeits-

kontrolle

Alle Daten innerhalb eines DBS sollten immer verfgbar sein.

Zur Erfllung dieses Gebots besteht die Mglichkeit regelmig

Backups der Datenbasis durchzufhren.

Trennungsgebot Nicht zusammenhngende Daten sollten auch nicht

zusammenhngend gespeichert werden.

Tabelle 4-1 Acht Gebote der Datensicherheit (Quelle: [Faeskorn-Woyke et al. 2007] Seite 56 f.)

Diese acht Gebote knnen bereits whrend der Konzeption und der Einbettung des DBS in die Systemarchitektur Beachtung finden. Indem man sich z.B. Gedanken ber Verfgbarkeits-, 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 knnen 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 Durchfhrungsbestimmungen 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 schlngelt. Neben der Einhaltung von Gesetzen und der Abwehr von allen nur erdenklichen Gefahren mssen natrlichauch 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, mssen frher oder spter Kompromisse eingegangen werden. Die Pflege und Kontrolle der Durchfhrung eines Sicherheitsplans nimmt viel Zeit in Anspruch, was

47 Die Autorisierung erfolgt nach der Authentifizierung und beinhaltet die Zuweisung von Rechten fr den angegebenen Benutzer.




einen Arbeitstag durchaus fllen kann.

Ein weiterer Punkt ist immer noch die fehlende Untersttzung durch die verantwortlichen Mitarbeiter einer Institution. Eine komplette Umsetzung von Sicherheitsrichtlinien ist leider auch ein erhhter Kostenfaktor. Neben laufenden Schulungen von Mitarbeitern und Benutzern, werden i.d.R. auch zustzliche Software und Mitarbeiter, die die Sicherheit umsetzen, bentigt. Weiterhin sind oft einschneidende nderungen in der Systemarchitektur und deren Bearbeitung von Nten.

Da die Einfhrung zu strenger Sicherheitsplne, aufgrund von zustzlich entstehenden Kosten fr weitere Sicherheitssoftware, das Trainieren der Benutzer und die Durchfhrung komplexer Prozeduren oft nicht praktikabel ist, muss versuchtwerden, das Sicherheitsrisiko und die Sicherheitskosten auf einem geringen Niveau zu halten.

Um den Kompromiss zwischen Risiko und Effizienz besser beurteilen zu knnen, sollte versucht werden die Gefahren bzw. Ereignisse fr ein Datenbanksystem und deren mgliche Kosten aufzulisten, um ihnen danach eine gewisse Prioritt zuordnen zu knnen. Ereignisse die auftreten knnen sind z.B. die Zerstrung des kompletten Datenbanksystems und die dadurch entstandenen Kosten fr 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 zustzliche Schulungsmanahmen fr die Administratoren. Daher sind die mglichen Risiken und deren mgliche Kosten genau einzustufen, zu priorisieren und einander abzuwgen.

Die Umsetzung und Einfhrung eines Sicherheitsplans fr 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 erhhte Sicherheit auch meistens erhhten Aufwand bedeutet, wird das auch einige Mitarbeiter abschrecken, hier erfolgreich mitzuwirken. Ungewohnte Arbeitsablufe und ungewohnte Barrieren frdern eine gewisse Diskrepanz gegenber 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. Hauptschlich 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 untersttzen knnen.

Es kann festgehalten werden, dass Sicherheit nur umgesetzt werden kann, wenn die betroffenen Personen ihre an sie gestellten Anforderungen gewissenhaft umsetzen. Darum ist es unumgnglich, Mitarbeiter fr die Sicherheitsanforderungen, die aus einem Sicherheitsplan hervorgehen, zu sensibilisieren.




Ein ber ein Intranet48 oder E-Mail gesteuerter Informationsdienst, mit Informationen ber aktuelle Bedrohungen, wie z.B. Viren oder Hinweisen ber aufgetretene Sicherheitslcken, kann die Mitarbeiter informieren und nicht zuletzt sensibilisieren. Als weitere Manahme sollten regelmig Schulungen durchgefhrt werden, die z.B. ber den richtigen und sicheren Umgang der zu verwaltenden Daten eines Datenbanksystems oder aber ber die richtige Auswahl von Passwrtern (vgl.Abschnitt 5-5-5) informieren.

48 Ein Intranet ist ein internes Netzwerk aus Rechnern / Servern, innerhalb eines Unternehmens bzw. einer Organisation.


Kapitel 5: Erarbeitung eines Sicherheitsplans


5. Erarbeitung eines Sicherheitsplans

Nachdem nun grundlegende Sicherheitsbegriffe, Datenbanksysteme und mglicheAngriffe erlutert 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 natrlich die Sicherung des Datenbanksystems selbst.

5.1. Verantwortlichkeiten zuweisen

Bevor Sicherheit im Datenbanksystem richtig umgesetzt werden kann, sollte zunchst berlegt werden, wer letztlich fr eine Umsetzung und Verteilung der zu bewltigenden 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 beitrgt, kann das Datenbanksystem und damit auch die Sicherheit der Daten gewhrleistet werden.

Sicherheit und Datenbanksysteme sind meist zwei verschiedene Welten. Whrend 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 Verstndnis fr Sicherheitsprobleme auerhalb der Datenbanken zu entwickeln. Auerhalb der Datenbanken haben Systemadministratoren i.d.R. keinoder zumindest relativ wenig Datenbankwissen. Sie kennen sich zwar bestens mit Betriebssystemen aus, jedoch ist die darauf installierte Software meist nur oberflchlich bekannt und existiert fr sie nur als Blackbox49.

In Bezug auf diese Problematik wre es wnschenswert Sicherheitsmitarbeiter zu beschftigen die einen grundlegenden berblick ber die gesamte Systemlandschaft besitzen und Sicherheitslcken aller Komponenten innerhalb eines IT Systems kennen und diese zum Schutz des Datenbanksystems einsetzen.

Hat eine Organisation eine gewisse Gre erreicht, haben auch viele weitere Abteilungen, auerhalb der IT Abteilung, indirekt mit Datensicherheit zutun. Hierwre eine Zusammenarbeit mit anderen Abteilungen wnschenswert. Sicherheitsanforderungen und plne knnten zusammen erarbeitet und mit Hilfe der jeweiligen Abteilungen (Datenbankadministratoren, Datenbankprogrammierer, Fachabteilung usw.) besser durchgesetzt werden.

Nachfolgende Tabelle zeigt eine mgliche Zusammensetzung von Sicherheitsmitarbeitern:

49 Die Software ist nur ber die nach auen gelegenen Schnittstellen bekannt. Dadurch fehlt Hintergrundwissen in Bezug auf das interne Arbeiten der Software.




Mitarbeiter Erluterung

Datenbank-

administrator

Datenbankadministratoren sind fr das Datenbanksystem und

dessen Komponenten verantwortlich. Ihr Aufgabengebiet kann in

verschiedene Gruppen eingeteilt werden. In der Praxis wird meist,

auf horizontaler Ebene, zwischen Applikationsadministratoren und

Administratoren fr den restlichen Bereich unterschieden.

Die Applikationsadministratoren sind fr die Applikationen rund

um die Datenbank verantwortlich. Sie sind u.a. fr die Anbindung

der Forms Masken, der PL/SQL Packages, der Stored

Procedures usw. zustndig.

Die andere Gruppe der Administratoren ist fr den reibungslosen

und sicheren Betrieb des Datenbanksystems verantwortlich. Sie

knnen z.B. Konfigurationsdateien einspielen und ndern, neue

Schemas anlegen, die Performance und Speicherintensitt der

Datenbank kontrollieren und verbessern, Sicherheitstools des

Datenbanksystems einspielen, die Berechtigungen sowie Rollen

vergeben und das DBS auf dem Betriebssystem warten.

Mchten Entwickler ihre Programme auf hher gelegenen

Datenbankinstanzen einspielen (z.B. von der Testdatenbank auf

die Produktionsdatenbank) gibt es noch eine vertikale

Unterscheidung der Administratoren. Hier wird zwischen

Entwicklungs- und Produktionsadministratoren unterschieden.

Programmierer knnen somit nderungen an Programmen

durchfhren, mssen diese aber erst ber die

Produktionsadministratoren in die produktive Datenbank

einspielen lassen.

Betriebssystem-

administrator

Fr das reibungslose Funktionieren des Betriebssystems sind

diese Mitarbeiter verantwortlich. Sie spielen Patches und

Antivirensoftware ein, kontrollieren eingespielte Software,

vergeben Berechtigungen fr Verzeichnisse (z.B. knnte 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.




verwalten), verbessern die Performance und Speicherverwaltung,

sichern das Betriebsystem und sorgen letztlich fr das perfekte

Zusammenspiel zwischen Datenbank- und Betriebssystem.

Netzwerk-

administrator

Netzwerkadministratoren sollten die sichere Vernetzung im Auge

haben. Sie ermglichen z.B. eine sichere Netzwerkverbindung

ber Virtual Private Network (VPN) und ber Secure Socket Layer

(SSL). Weiterhin kmmern sie sich um die richtige Konfiguration

von Firewalls, Routern, Switches und sorgen dafr, dass die

Datenbertragung zwischen verschiedenen Systemlandschaften

und den darin enthaltenen Datenbanksystemen nur ber zuvor

definierte Schnittstellen erfolgt. Somit wird dafr gesorgt, dass

nur valide Daten im Datenbanksystem ankommen.

Internet-

administrator

Im Falle einer Internetanbindung liegt hier die Verantwortlichkeit,

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 dafr,

dass der Webauftritt gegen Angriffe abgeschottet ist.

Security-

Abteilung

Bei greren Unternehmen existiert weiterhin eine Security

Abteilung. Diese ist u.a. fr die Kontrolle des Auditing zustndig.

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

berprft.

Penetrations-

tester

Penetrationstester existieren i.d.R. ebenfalls nur bei greren

Unternehmen. Sie spren Sicherheitslcken bzw. fehlerhafte

Konfigurationen auf und fixen diese. Bei kleineren Unternehmen

oder Organisationen werden auch externe Penetrationstester

engagiert um Sicherheitsprobleme aufzuspren und zu beseitigen.

Tabelle 5-1 Sicherheitsmitarbeiter (Quelle: Vgl. [Newman et al. 2004] Seite 86)

51 Vgl. Abschnitt 5-2-2




Diese Tabelle zeigt auf, dass Verantwortlichkeiten und Sicherheitswissen des IT Systems auf viele Personen verteilen werden muss um einen umfassenden Sicherheitsplan fr ein Datenbanksystem zu verwirklichen.

Die Personen mssen whrend der Durchfhrung eines Prozesses (z.B. die Einspielung neuer Daten in die Datenbank) einerseits miteinander kommunizieren um den Prozess zu vervollstndigen. Andererseits ist das komplette Wissen von Sicherheitstools und eventuellen Sicherheitslcken auf viele Personen verteilt. Dies macht es einem internen Angreifer schwer, sein Vorhaben zu verwirklichen. Weiterhin erhht sich, da jede Person ein exakteres Wissen ber seinen Teilbereich von Aufgaben hat, die Qualitt und Sicherheit des gesamten IT- und Datenbanksystems.

5.2. Die Systemlandschaft

Wie schon in Abschnitt 4 erwhnt sind Sicherheitslcken sowie fehlerhafte Konfigurationen und somit Angriffspunkte auf ein Datenbanksystem hufig auerhalb zu finden. Von daher reicht die Absicherung des Datenbanksystems allein nicht aus,um dafr zu sorgen, dass die enthaltenen Daten sicher sind. Es muss zunchst geklrt 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 Zonekurz 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 Universitten eingesetzt.

Seither wurden viele neue Varianten entwickelt. Da UNIX von vielen Unternehmen weiterentwickelt wurde, existieren mittlerweile viele verschiedene UNIX - Versionen. Diese Weiterentwicklung sorgte dafr, dass jeweils sehr stabile und sichere Systeme entstanden sind. Das derzeit fhrende UNIX Betriebssystem heit 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 Zuverlssigkeit aus, was Hauptkriterien fr den sicheren und stabilen Einsatz eines Datenbanksystems sind. Die Interoperabilitt54 und die Benutzerfreundlichkeit sind mit "gut" zu bewerten. Der

52 Heute als Unternehmen mit dem Namen AT&T bekannt.53 ber die Skalierbarkeit wird angegeben, wie ein System mit groen Mengen an Prozessen bzw.

Transaktionen und dem daraus resultierenden Datenstrom umgeht.54 Die Interoperabilitt beschreibt die Zusammenarbeit mit anderen Produkten (auch die anderer

Unternehmen) und Industriestandards.




Preis sowie die Kosten fr 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 wren und nicht den neuesten Sicherheitsrichtlinien entsprechen.

UNIX Betriebssysteme werden hauptschlich von groen Unternehmen und Hochschulen eingesetzt. Das IBM eigene Datenbanksystem DB2 sowie das extra fr UNIX entwickelte Datenbanksystem Oracle bilden den Groteil der vertretenden Datenbanksysteme auf AIX.

5.2.2. Errichtung einer DMZ

Wie schon in den vorigen Abschnitten erwhnt, ist es in greren Institutionen weiterhin wichtig eine Demilitarisierte Zone55 einzusetzen. Es handelt sich hierbei umeine Technik, interne vor ffentlichen Netzwerken, wie z.B. dem Internet zu schtzen. 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 dafr verantwortlich sein, Daten, die zuvor ber dasInternet zur Verfgung gestellt wurden, abzuholen.

Gerade in Bezug auf ein Datenbanksystem und der Notwendigkeit, dieses mit dem Internet zu verbinden, ist die Einfhrung einer DMZ bzw. mehrerer DMZ sehr sinnvoll. Daten die ber das Internet in die Datenbank eingespielt werden sollen, knnen z.B. in einem tglichen 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 sicherungsbedrftigen Daten beinhalten. Das Internet sollte zur DMZ und dem darin enthaltenen Webserver bzw. Datenbanksystem ber eine erste Firewall geschtzt 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 zustzlicher Angriffspunkt und birgt Gefahrenpotenziale. Da wohl keine Software perfekt ist, enthlt jede Software Bugs, die im Extremfall als Sicherheitslcke ausgenutzt werden kann56.

55 Vgl. http://www.itwissen.info/definition/lexikon/demilitarized-zone-DMZ-Demilitarisierte-Zone.html, 23.06.2008

56 Eine zustzliche Beschreibung zur richtigen Absicherung eines gesamten Netzwerkes, wrde den Inhalt dieser Arbeit sprengen. Von daher sei hier auf weiterfhrende Literatur verwiesen.http://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Daps&field-keywords=netzwerksicherheit, 07.08.2008

http://www.itwissen.info/definition/lexikon/demilitarized-zone-DMZ-Demilitarisierte-Zone.htmlhttp://www.amazon.de/s/ref=nb_ss_w?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-




5.3. Absicherung des Betriebssystems IBM AIX

Die Absicherung eines IBM AIX Systems ist sehr vielseitig und knnte ganze Bcher fllen. Allein deshalb sei darauf hingewiesen, dass es sich hier nur um grundlegende Sicherheitsanforderungen bzw. Umsetzungen handeln kann. Um ausfhrliche Sicherheitstools nutzen zu knnen, 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 knnen.

Abbildung 5-1: Multiuser System (Quelle: selbst erstellt)

Anhand dieser Betrachtung wird sehr schnell deutlich, dass aufgrund der vielen Benutzer ein erhhtes Sicherheitsrisiko besteht. Selbst wenn das Betriebssystem an kein ffentliches Netzwerk angeschlossen ist, treten allein durch die Anzahl der mglichen Benutzer viele Sicherheitsrisiken auf, die entsprechend ausgeschaltet werden mssen.

Die in den folgenden Teilabschnitten erwhnten Sicherheitstools und -mglichkeitengelten sowohl fr IBM AIX als auch fr 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 knnen, wird zu Beginn auf das von UNIX verwendete Berechtigungssystem eingegangen.

Dieses stellt drei Berechtigungsebenen zum Schtzen von Dateien und Verzeichnissen zur Verfgung: den Dateibesitzer, die Dateigruppe und alle anderen Benutzer. Zu erwhnen ist, dass die Dateiberechtigungen nicht einem Einzelnen, bis auf den Dateibesitzer, erteilt oder entzogen werden knnen sondern nur Gruppen und den restlichen Usern.




Weiterhin gibt es drei verschiedene Berechtigungstypen: Lesen, Schreiben und Ausfhren. 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 erlutert 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 nchsten 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 ausfhrbaren Rechte. Diese werden durch ein x (execute) dargestellt. Steht an einer der erwhnten Positionen ein -, so bedeutet dies, dass fr 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 ausfhren (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 mssen. 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 mglich fr jede Datei bzw. jedes Verzeichnisund Benutzergruppe die Berechtigungen genau einzustellen um einem Missbrauch an Dateien frhzeitig 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 mglichen Befehl auf dem Betriebssystem auszufhren. Um es einer evtl. Brute Force Attacke59

mglichst schwer zu machen, sollte das Passwort fr dieses Konto in keinem Wrterbuch 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 zwlf Zeichen langen Kennworts halbwegs

57 Als symbolischen Link bezeichnet man eine Referenz auf eine Datei oder ein Verzeichnis.58 Fr das oben genannte Beispiel htte der Befehl folgendermaen ausgefhrt werden knnen:

chmod 775 umgebung_Q60.sh Vgl. [Michael 2002]

59 Mittels dieser Attacke, wird versucht, mit allen mglichen Kombinationen aus Wrtern (meist entstammt die Grundlage einem Wrterbuch) das Passwort oder aber den Namen des Benutzers herauszufinden.

http://umgebung_Q60.shhttp://umgebung_Q60.sh




sicher sein. Dieses knnte z.B. folgendermaen aussehen: tJ8mP48{tz. Zugegeben, dieses Kennwort ist nicht leicht zu merken, es erfordert jedoch sehr viel Aufwand es zu knacken. Da die Gltigkeit des UNIX Passworts keine gewisse Gltigkeitsdauer hat, sollte das Passwort nach einer festgelegten Zeit gendert werden. Dieser Zeitraum kann jedoch nicht verallgemeinert werden. In groen Unternehmen ist es, im Gegensatz zu kleinen, nicht mglich, dass ein Administrator z.B. alle drei Monate sein Kennwort ndert, da er hier nicht selten tagelang damit beschftigt wre, sein Passwort zu ndern. Hier sollten grere Zeitrume (z.B. alle sechs Monate) gewhlt werden. Der Prozess zur nderung eines Kennworts kann so durchdacht werden, dass Administratoren z.B. jeden Monat nur einen gewissen Teil ihrer Passwrter ndern mssen, womit sich der Gesamtaufwand besser verteilt.

Ein Problem, dass bei groen Unternehmen und somit in der Praxis leider nur sehr schwer zu korrigieren ist, ist die Tatsache, dass Benutzer fr unterschiedliche Systeme oft das gleiche Passwort verwenden. Ist also ein Passwort bekannt, so sind gleich mehrere Passwrter bekannt. Bei bspw. 800 wartbaren Servern, wrde ein Administrator jedoch 800 verschiedene Kennwrter bentigen und somit kennen mssen. Hier sollte zumindest durch Vorgaben versucht werden, bestimmte Passwortkonventionen, wie z.B. ein zwlf Zeichen langes Passwort, zu erzwingen. Als Kompromiss knnten auch Konventionen eingesetzt werden, die auf verschiedenen Systemen, z.B. Passwrter erlauben, die bis auf eine Stelle gleich sind. Die jeweils erste Stelle eines Kennworts knnte 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 Passwrter eingesetzt werden.

Fr das Betriebssystem, wie auch spter das Datenbanksystem, sollten mehrereAdministratoren eingetragen werden. Sollte ein Administrator aus irgendeinem Grund ausfallen oder aber aufgrund eines neuen, fr ihn unangenehmen, Abteilungsleiters zur Gefahrenquelle werden, gibt es weitere Administratoren, die die Arbeit bernehmen knnen. Es versteht sich von selbst, dass die Datenbankadministratoren und die Betriebssystemadministratoren unterschiedliche Personen sein sollen.

Je nach Gre des Unternehmens und Mglichkeit 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 ausgefhrt werden.

Prozesse so gestalten, dass sie nur zu zweit ausgefhrt werden knnen.

Unterschiedliche Aufgaben an unterschiedliche Administratorenverteilen.

Nur die fr die Aufgaben unbedingt notwendigen Berechtigungenvergeben.

Bentigt ein Benutzer, z.B. zur Einspielung eines Patches des Datenbanksystems,kurzzeitig Administrationsrechte am Betriebssystem, so empfiehlt sich hierfr die Verwendung des von UNIX zur Verfgung 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 fr explizit genannte Programme vergeben werden. Hierfr mssen die jeweiligen




Informationen in der Datei /etc/sudoers hinterlegt werden60.

Bei greren Unternehmen ist es, aufgrund von erheblichen, zustzlichen Kosten und einer zunehmenden Reaktionszeit, leider oft nicht mglich alle der genannten berwachungsinstanzen einzufhren. 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 Passwrter

Da UNIX ein Multiuser System ist, erlaubt dieses System mehrere Benutzer anzulegen um diese bei der Anmeldung zu authentifizieren. Whrend der Erstellung muss dem Benutzer weiterhin ein Passwort zugewiesen werden. Zustzlich knnenGruppen61 erstellt werden, um den Benutzern gemeinsame Berechtigungen zuzuweisen. Benutzer knnen mehreren Gruppen zugeordnet sein, jedoch kann eine Gruppe selbst kein Mitglied einer anderen Gruppe sein.

Standardmig werden unter UNIX erstellte Benutzer und deren Kennwrter 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 Kennwrter 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/groupsgespeichert.

Jemand, der sich nun auf seinem Rechner anhand einer Wortliste und des gleichen Algorithmus, ebenfalls Kennwort Hashes genieren lsst, 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. Fr Gruppen wurde dies durch eine Verschiebung in /etc/gshadow gelst. Das besondere daran ist, dass nur noch das administrative Konto Lesezugriff auf die Dateien hat.

Um die Kennwrter zu schtzen, sollte die Aktivierung dieser Option kontrolliert werden. Indem der Administrator den Befehl pwconv ausfhrt werden alle Kennwort Hashes, aus der Datei /etc/passwd entfernt und in /etc/shadow geschrieben. Fr Gruppen erfolgt die Verschiebung in /etc/gshadow anhand des Befehls grpconv.

5.3.4. Auditing

Als letzten separaten Punkt soll das Auditing erwhnt werden. Es dient dazu die Aktivitten auf dem Betriebssystem detailliert zu protokollieren. Auf IBM AIX erfolgt die Speicherung der Protokollierungen in den Verzeichnissen /var/log und /var/adm. Standardmig hat jeder Benutzer Leserechte auf die darin enthaltenen

60 Vgl. [Michael 2002]61 Unter UNIX ist eine Gruppe eine Liste von Benutzern.62 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 zur Erstellung eines Hash Wertes verwenden.




Dateien. Auch wenn die Dateien fr einen Laien nur schwer zu analysieren sind, sollte die Leseberechtigung entzogen werden.

Die Protokolldateien sollten hufig nach unbekannten oder nicht autorisierten IP Adressen sowie nach ungewhnlichen Aktivitten, wie Port Scans63 durchsuchtwerden.

Um die Protokollierungen vor unberechtigten Lesezugriffen zu schtzen, knnen 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, bentigt aber auch einen zustzlichen Overhead. Je mehr mitprotokolliert wird, desto mehr Performance geht verloren. Es sollte alsoauch hier nicht alles und jeder nur erdenkliche Befehl protokolliert werden.

5.3.5. Sonstige Sicherheitsaspekte

Erwhnenswert ist die simpelste Absicherung. Der entsprechende Server sollte in einem sicheren Serverraum untergebracht sein. Ziel ist es, dass der Server gegen menschliche und hhere Gewalt geschtzt ist. In der Praxis gibt es sogar Flle, in denen der Serverraum gegen schwere Waffen, wie z.B. Raketenwerfer geschtzt ist.

Weiterhin sollte grndlich berlegt werden, ob ein Remote Zugriff fr Benutzer des Betriebssystems notwendig ist. Um eine Fernwartung zu ermglichen, sollte maximal den Administratoren ein solcher Zugriff gewhrt 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 bentigt werden, deaktiviert werden. Luft auf dem Betriebssystem nur das Oracle Datenbanksystem, so sollten lediglich die Dienste, die im Zusammenhang mit Oracle bentigt werden, genutzt werden. Die Dienste werden i.d.R. beim Starten des Betriebssystems gestartet. Die dafr 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 erwhnt, in der Einspielung von Patches. Es sollten regelmig 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 bentigt wird. Jegliche Software, die mit IBM ausgeliefert, aber nicht bentigt wird, sollte entfernt werden, denn jede zustzliche Software bietet mgliche Bugs sowie einenweiteren neuen Einstiegspunkt in das System und somit ein weiteres Sicherheitsrisiko.

63 Bei einem Port Scan untersucht ein Programm die Ports des Betriebssystems und protokolliert, welche Ports offen und welche geschlossen sind.

64 Einer der bekanntesten Newsgroups zu sicherheitsrelevanten Themen von UNIX und anderen Systemen, ist die folgende Homepage:http://www.securityfocus.com, 12.07.2008

65 Patches zur Einspielung von IBM AIX erhlt man ber den Link: http://www-933.ibm.com/eserver/support/fixes/fixcentral/pseriesfixpackdetails/5300-07-00-0747, 12.07.2008

http://www.securityfocus.comhttp://www-933.ibm.com/eserver/support/fixes/fixcentral/pseriesfixpackdetails/5300-07-00-0747




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 Sicherheitslcken angeht, genau auf diesem DBS liegen. Einerseits entsteht hierdurch ein positiver Nebeneffekt. Oracle selbst ist sehr darum bemht so viele Sicherheitslcken wie mglich auszumerzen. Andererseits werden durch die Fokussierung auch immer neue Sicherheitslcken aufgedeckt.

Die Sicherheitslcken sind im Umfang eines Datenbanksystems enthalten und werden kostenlos mitgeliefert. Auch wenn Oracle in den letzten Jahren bereits viele dieser

Documents

“Erstellen eines Oracle – Sicherheitsplans“blogs.gm.fh-koeln.de/.../diplomarbeit_sicherheitsplan_oracle_dbs.pdf · “Erstellen eines Oracle ... Tabelle 5-6 Ein Ausschnitt der