
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Bei der Installation einer Oracle Datenbank werden notwendigerweise einige Accounts angelegt, die den Zugriff auf die Datenbank ermöglichen. Weiterhin werden Accounts eingerichtet, die durch Installation zusätzlicher Optionen entstehen. Es ist erstaunlich, wie viele Accounts so automatisch erzeugt werden und somit auch geschützt werden müssen.
In der Praxis heißt das, dass eine neu installierte Oracle Datenbank viele Zugänge hat, die mit wenig Aufwand zu öffnen sind und damit Zugriff auf die Daten erlauben.
Damit eine Oracle Datenbank produktiven Zwecken genügt, müssen vom Administrator deshalb einige Schritte ausgeführt werden, um das System vor nicht autorisiertem Zugriff zu schützen.
In diesem Artikel werden die verschiedenen Accounts in Beispielen aufgeführt, die zur Sicherheit der Daten(bank) unter Kontrolle sein sollten. Das betrifft nicht nur die bekannten Accounts SYS und SYSTEM – auch als Benutzer DBSNMP oder OUTLN kommt man zum Beispiel leicht an die Liste aller Benutzer einer Datenbank durch Zugriff auf die View ALL_USERS.
Bestimmte Benutzer werden von Oracle angelegt, um die Gestaltung, die Administration und das Arbeiten mit der Datenbank zu erlauben. Naturgemäß haben diese Accounts sehr viele Rechte und Privilegien im System. Sie sollten nach der Installation als erstes zumindest ein neues Passwort bekommen, wenn sie nicht gesperrt werden können (siehe Abbildung 1).
Abb. 1: Administrative Accounts mit hohem Rechte-Niveau.
Die zusätzlichen Optionen, die Oracle mit sich bringt, haben zumeist einen eigenen Benutzer (siehe Abbildung 2).
Abb. 2: Beispiele von weiteren, von Oracle standardmäßig angelegten Usern.
Eine dritte Gruppe von Accounts, die leicht übersehen werden, sind die Benutzer, die von Applikationen angelegt werden, die mit und in Oracle arbeiten. Oracle Applications etwa bringt selbst noch eine Reihe von Standard-Benutzern mit sich, die nach der Installation überprüft werden sollten. Auch SAP R/3 oder andere ERP-Systeme benötigen oft einen Benutzer mit DBA-Privilegien.
Zudem arbeiten auch die Programme, die der Überwachung oder dem Systemmanagement dienen, wie BMC PATROL oder Tivoli, auf der Datenbank mit einem Benutzer, der weitreichenden Zugriff auf die Systemressourcen und die Daten hat (siehe Abbildung 3).
Abb. 3: Benutzer, die von Standard-Applikationen angelegt werden.
Der erste Schritt sollte schon vor der Installation erfolgen: Welche der vielen Optionen, die die Installationsroutine anbietet, habe ich lizensiert und nutze ich wirklich? Wenn nötig, können fehlende Funktionalitäten jederzeit nachinstalliert werden.
Nach der Installation sollte überprüft werden, welche Benutzer mit Standard-Passwort auf der Datenbank bestehen. Bei einer automatischen Installation sperrt das Database Client Administrations-Tool (DBCA) alle Accounts bis auf SYS, SYSTEM, SCOTT, DBSNMP, OUTLN und dem JSERV-Benutzer. Bei einer manuellen Installation geschieht das nicht.
Für alle Standard-Benutzer sollte direkt nach der Installation ein neues Passwort vergeben werden. Im Idealfall ist die Kennung zu sperren (ACCOUNT LOCK).
Bei vielen Programmen, speziell den Standard-Lösungen aus dem ERP- und dem Systemmanagement-Bereich, hat es in den letzten Versionen aufgrund kritischer Anfragen hinsichtlich dieses Sicherheitsaspektes Veränderungen gegeben: die Standard-Benutzer dieser Programme kommen immer häufiger mit Accounts aus, die ein gezieltes Profil genau für ihre Aufgaben bekommen und nicht mehr die DBA-Privilegien brauchen.
Oft genug wird aber diese Möglichkeit nicht genutzt und wie zuvor ein über das nötige Maß ausgestatteter Benutzer zur Installationsvoraussetzung gemacht. Bei der Integration solcher Komponenten bringt eine konsequente Überprüfung der Notwendigkeit der angeforderten Privilegien schnell ein Plus an Sicherheit.
Datenbank überprüfenAuf Basis vieler Projekte haben wir ein kleines Skript entwickelt, das prüft, ob es Standard-Benutzer in der Datenbank gibt. Auf Nachfrage stellt ORDIX Ihnen gerne dieses Script zur Verfügung. Für Fragen und Unterstützung wenden Sie sich bitte einfach an den Autor unter info@ordix.de.
Damit eine neu installierte Oracle Datenbank produktiv eingesetzt werden kann, müssen in einem ersten Schritt die möglichen Zugänge durch mitinstallierte Standard-Benutzer sicher gemacht werden. Das hat für die Sicherheit der Datenbank und der Daten die gleiche Priorität wie die Bereitstellung hinreichender Ressourcen für die Verfügbarkeit.
Uwe Rübesamen (info@ordix.de).
Quelle: ORDIX News 4/2004Und nochmal ans Türchen geklopftZu dem Artikel "Knocking at your Backdoor" erhielten wir sehr viel Post, so dass sich der eine oder andere Leser ein wenig gedulden musste, bis er die gewünschten Informationen erhielt. Bitte haben Sie an dieser Stelle etwas Verständnis, dass wir – wenn schon kostenfrei – nicht immer sofort reagieren können. Manchmal müssen wir auch Geld verdienen, sonst könnten wir Ihnen so nützliche Unterlagen wie z. B. unsere News nicht unentgeltlich zur Verfügung stellen oder für Sie kostenlose Fachtreffs organisieren. Von einem ehemaligen ORDIX Mitarbeiter, jetzt bei SAP tätig, erhielten wir eine Information aus dem Hause SAP. Diese möchten wir Ihnen nicht vorenthalten, da sie eine wichtige Ergänzung zu unserem Artikel darstellt: Auch SAP hat die – mehr oder weniger schöne – Eigenart, Datenbank Benutzer anzulegen. In älteren R3 Releasen hieß der Benutzer sapr3 mit dem default password sap. Seit Mcod (Multi Component One Database) und Release >= 610 heißen die Benutzer standardmäßig sap<SCHEMAID> und sap<SCHEMAID>db für j2ee. Diese Benutzer haben kein Standard Passwort mehr. Ob es sich dabei um eine offizielle SAP Aussage handelt, entzieht sich der Kenntnis der Redaktion ;-) |