Problem mit dem systemübergreifenden Schutz von Datenbanken

[ingrolf]

Hallo, ich habe folgendes Problem:

Ich habe probeweise eine Datenbank unter einem System erstellt,
wo das Passwort für den SYSDBA aus Sicherheitsgründen geändert war. Anschließend habe ich diese von Hand auf ein anderes System übertragen. Nun war es dort ohne Weiteres möglich, mit den vollen Benutzerrechten auf diese Datenbank zuzugreifen, weil das Passwort des lokalen SYSDBA noch auf MASTERKEY gesetzt war. Wie kann ich diese Sicherheitslücke umgehen? Ist es nicht irgendwie möglich, einer einzelnen Datenbank ein eigenes Passwort zuzuordnen?

[Markus Kinzler]

Bisher sind die Benutzer und Passwörter in einegen eigenen Datenbank (fbsecurity) serverabhängig abgelegt. Wird sich aber mit FB3 ändern. Man kann das Problem umgehen in dem man eine Rolle (in DB gespeichert) mit dem Namen SYSDBA anlegt und der die Rechte wegnimmt. (Vorher natürlich volle Rechte an alt. Adminuser übergeben)

[ingrolf]

Erstmal vielen Dank für die Hilfe!

Ich befürchte allerdings, dass ich wenn ich den SYSDBA sperre und stattdessen einem anderen Benutzernamen die vollen Rechte einräume, dass Problem nur verlagere.

[Markus Kinzler]

Dar reine Kopieren der Datenbank (welche auch in keiner Freigabe liegen sollte) reicht dann nicht mehr. Der Angreifer muss dann Benutzername und Passwort erraten

[harri]

Hallo.
ich denke daß eine ganze Reihe von Admins erfreut sind, wenn FB3 mit dieser neuen Funnktionalität erscheint.
Hat denn schonmal jemand im Kaffesatz gelesen und ein Release-Datum mit der 3 am Anfang deuten können?

[Markus Kinzler]

Der Release ist traditionell im Q4 des Jahres geplant (ursprünglich 2007, dann 2008 und nun 2009). Da aber die FB2.5 schon fast alles der 3er hat (und einiges, was ursprünglich für Versionen > 3 geplant war) besteht Grund zur Hoffnung, das es Ende dieses/Anfang nächstes Jahr soweit sein könnte. Ist aber eine reine Spekulation von mir. Du kannst dir ja mal Vulcan anschauen

[ingrolf]

SYSDBA sperren

Ich habe jetzt mal mit CREATE ROLE SYSDBA den sysdba gesperrt.
Dann bleibt allerdings das Problem, dass kein unbefugter Benutzer den Namen des Owners kennen darf, da er sich dann mit vollen Benutzerrechten mit der Datenbank verbinden kann. Den Passwortschutz kann man auch weiterhin dadurch aushebeln, dass man die Datenbank auf einen anderen Rechner überträgt und dort den benötigten Benutzernamen selber anlegt.

Wenn man das Sicherheitskonzept von Firebird erfolgreich umsetzen will, scheint es wichtig zu sein dafür zu sorgen, dass kein direkter Zugriff auf die Datenbankdatei möglich ist.