Benutzermanager

<< Generiere HTML Dokumentation | IBExpert | Rechtemanager >>

Die deutschsprachige Dokumentation wird seit dem 26. Juli 2016 nicht mehr gepflegt. Aktuelle und vollständige Dokumentation finden Sie auf der englischsprachigen Webseite: IBExpert Documentation


Tutorium verfügbar

  1. Benutzermanager
    1. Benutzerrechte für die Datenbank
    2. Benutzer
      Passwort
    3. Roles
    4. Mitgliedschaft
  2. Serversicherheit ISC4.GDB / SECURITY.FDB
  3. Serversicherheit SECURITY2.FDB
    1. Classic Server auf POSIX
    2. Bei der neuen Sicherheitsdatenbank
      zu beachten
    3. Die Sicherheitsdatenbank Upgrade
      durchführen
    4. NULL-Fähigkeit des RDB$PASSWD
    5. Vorsicht mit LegacyHash
  4. Userpasswort mit Batch-Datei ändern

Benutzermanager

Der Benutzermanager verwaltet Datenbank Benutzer und ihre Roles (Rollen). Hier kann einzelnen Benutzern Zugang zur Datenbank und zum Server gewährt werden. Der Benutzermanager gilt für den Datenbankserver, nicht die einzelnen Datenbanken (weitere Information hierzu finden Sie hier: Serversicherheit ISC4.GDB / SECURITY.FDB.

Seit IBExpert Version 2014.12.17 verwendet der Benutzer Manager SQL statt den Services API bei der Arbeit mit Firebird 3 Datenbanken. Um die Vorteile der SEC$USERS Systemtabelle zu geniessen, müssen Sie eventuell die security3.fdb in das IBExpert\IBExpert Developer Studio\IBExpert Unterverzeichnis kopieren. Alle Firebird 3.0 Benutzer werden dann auch im IBExpert DB Explorer angezeigt, und können von dort aus bearbeitet werden.

Den Benutzermanager öffnen Sie über den IBExpert Menüpunkt, Nützliches / Benutzermanager, oder klicken Sie auf das entsprechende Symbol in der Nützliches-Symboleiste.

Wenn Sie bereits mit einer Datenbank verbunden sind, verbindet sich der Benutzermanager direkt mit dem Services Manager für diese Datenbank. Wenn keine Datenbankverbindung besteht, müssen Sie sich erst am Server einloggen.

Der Benutzemanager-Editor zeigt eine Liste aller registrierten Datenbanken (Aufklappliste). Die Serververbindung darf über die Aufklappliste geändert werden.

Wählen Sie die Datenbank und Server (lokal oder Remote) aus, die Sie verwalten möchten.

Wenn die registrierte Datenbank mit einem Firebirdserver 2.1 oder höher arbeitet und die Trusted authentication-Option bei der Datenbankregistrierung spezifiziert wurde, wird auch hier Windows "Trusted User"-Sicherheit unterstützt.

Wenn möglich, wird die Aktiven Benutzer-Liste von MON$ATTACHMENTS geholt.

zurück zum Seitenanfang

Benutzerrechte für die Datenbank

Alle Benutzer müssen sich einloggen, um auf dem Server arbeiten zu können. Was sie genau auf dem Server machen dürfen wird mit den GRANT und REVOKE-Befehlen geregelt (siehe den IBExpert Rechtemanager für weitere Information) oder vom Frontend-Program kontrolliert.

Vermerk: Sie benötigen Serveradministratorenrechte, um Benutzer und Roles erstellen, ändern und löschen zu können.

zurück zum Seitenanfang

Benutzer

Auf der Benutzer-Seite finden Sie eine vollständige Liste aller Benutzer, die für diese Serververbindung registriert sind. Auch wenn die ausgewählte Datenbank nicht verbunden ist, kann die Benutzerliste noch angesehen werden, weil die Benutzer direkt in der Sicherheitsdatenbank auf dem Server registriert sind und deshalb Rechte für alle Datebanken auf diesem Server bekommen können. Die AC-Spalte (Active Users) zeigt, wieviele aktive Verbindungen ein Benutzer hat zu einer spezifizierten Datenbank (funktioniert nur bei aktiven Datenbanken). Der Refresh-Button (aktualisieren) unten rechts wurde eingefügt, um die Liste aller Benutzer zu aktualisieren.

Eventuell werden Sie aus Sicherheitsgründen aufgefordert, ein Passwort einzugeben, wenn Sie mit einer noch nicht verbundenen Datenbank verbinden möchten.

Ein Benutzer kann vom SYSDBA erzeugt werden (nicht vom Datenbankbesitzer, da Benutzer für alle Datenbanken auf dem Server erzeugt werden). Klicken Sie einfach auf dem Hinzufügen-Button, und füllen Sie das Neuer Benutzer-Formular vollständig aus:

InterBase® 7.5 eingebettete Benutzerauthentifikation wird auch unterstützt.

Nur der SYSDBA darf Benutzerinformation ändern oder löschen. Bei Änderungen darf nur den für das Login definierten Benutzernamen nicht geändert werden. Hier darf aber ein neues Passwort definiert werden, falls der Benutzer sein altes vergessen hat, oder den Nachnamen im Falle z.B. eines Heirats geändert werden.

Diese Liste beinhaltet alle aktuellen Benutzer. Um Benutzer hinzuzufügen, zu bearbeiten oder zu löschen, verwenden Sie die Buttons auf der rechten Seite. Im Hinzufügen / Bearbeiten-Fenster legen Sie den Benutzernamen, Passwort und (optional) den Vor- und Nachnamen fest.

Passwort

Das Passwort ist immer benutzerorientiert. Passwörter werden verschlüsselt in der Serverdatenbank gespeichert. Wenn ein Benutzer sein Passwort eingibt wird es an den Server weitergeleitet und der Server vergleicht den eingetippten String mit dem String des verschlüsselten Passwortes auf dem Server. Das Passwort wird NIE vom Server an den Client weitergeleitet.

Sollte ein Benutzer sein Passwort vergessen, kann der SYSDBA ein neues Passwort definieren, welches das alte ersetzt. Alternativ kann eine UDF in einen Program eingebaut werden, so dass der Benutzer sein Passwort selbst ändern kann, ohne dass er den SYSDBA stören oder sein Passwort an eine dritte Person verraten muss. Ein Beispiel einer solchen UDF befindet sich in der FreeUDFlib.dll-Bibliothek, die von https://www.ibexpert.com/download/udf/ downloaded werden kann.

Direkt im IBExpert Rechtemanager können Benutzer eingegeben und Rechte erteilt werden, obwohl es meistens sinnvoller ist, möglichst viele User Rechte über Roles zu erteilen. Roles werden verwendet, mehrere Leute die gleichen Rechte zu geben. Wenn Änderungen notwendig werden, muss nur die Role einmal geändert werden und nicht jeder einzelne Benutzer.

zurück zum Seitenanfang

Roles

Die Roles-Seite wird genutzt, Roles in der gleichen Art und Weise wie Datenbankobjekt Roles zu erzeugen und löschen. Alle Roles und ihre Besitzer werden für die ausgwählte Datenbank angezeigt. Andere Datenbanken am selben Server können ausgewählt werden, um auch ihre Roles anzuzeigen.

Verwenden Sie die Buttons auf der rechten Seite, um Roles hinzuzufügen oder zu löschen. Nachdem eine Role erzeugt oder gelöscht wird, erscheint das Compile-Fenster. Committen Sie die Transaktion, um die Role zu erzeugen oder zu löschen. Nach erfolgreicher Erzeugung einer Role können die Benutzer und Rechte im IBExpert Rechtemanager definiert, bearbeitet oder gelöscht werden.

Roles können nur auf Systemebene bearbeitet werden. Sie können aber mit dem Benutzermanager erzeugt oder gelöscht werden.

zurück zum Seitenanfang

Mitgliedschaft

Die Mitgliedschaft-Seite zeigt auf der ersten Seite, Benutzer -> Roles, welche Benutzer welche Rechte auf welchen Roles besitzen und auf der zweiten Seite, Roles -> Benutzer, eine Liste aller Roles und welche Benutzer welche Rechte auf diesen Roles haben.

Die Abkürzungen G bedeutet Granted (erteilt), M bedeutet Member of selected role (Mitglied der ausgewählte Role) und AO bedeutet With Admin option (Mit Verwaltungsoption). Benutzer können Roles einfach zugeordnet werden: wählen Sie den Benutzer und checken Sie entweder die Grant-/Member of selected role-Optionen oder die ADMIN option-Option. Zum Beispiel alle Vertriebspersonal können den Benutzernamen VERTRIEB mit der Role VERTRIEB erhalten. Wenn sie sich einloggen müssen beide Namen eingegeben werden. Wenn die Admin option gecheckt ist, darf der Benutzer seine Rechte an andere Benutzer weitergeben.

Diese Seiten zeigen auch Windows-Benutzer (bei Verwendung der ''Trusted Authentification) an, und auch Benutzer, die in der Sicherheitsdatenbank fehlen jedoch in RDB$USER_PRIVILEGES vorhanden sind.

zurück zum Seitenanfang

Serversicherheit ISC4.GDB / SECURITY.FDB

Wenn Firebird/InterBase® auf einem Server installiert wird, wird auch eine Datenbank mit autorisierten Benutzern angelegt. Sie ist unerlässlich für die Serversicherheit, um den Server vor nicht-autorisierten Benutzern zu schützen.

Die Sicherheitdatenbank heißt ISC4.GDB; seit Firebird 1.5 SECURITY.FDB: die Einführung der neuen Endung ist auf Windows XPs Kopierprobleme mit .GDB-Dateien zurückzuführen. Die SECURITY.FDB wurde in SECURITY2.FDB in Firebird 2.0 umbenannt (sehen Sie Serversicherheit SECURITY2.FDB unten für weitere Details).

ISC4.GDB bietet eine Benutzerseite mit den Rechten für den Firebird-/InterBase®-Server. Hier werden alle Benutzer eingegeben, die auf dem Server arbeiten dürfen. Das Benutzerpasswort ist serverorientiert und nicht datenbankorientiert. Es ist wichtig Benutzer und Rechte zu benutzen, um Zugang einzuschränken und Manipulation zu kontrollieren. Ein besonderer Vorteil ist zum Beispiel, dass man nachvollziehen, wer was wann gemacht hat, da die Benutzernamen im Protokoll mit erfasst werden.

Jeder Benutzer, der in der Sicherheitsdatenbank Benutzerliste eingetragen ist, darf eine Datenbank durch Eingabe der entsprechenden Benutzernamen und Passwort öffnen. Wenn ein Benutzername und Passwort bei der Datenbankerzeugung angegeben wird, wird dieser User der Datenbankbesitzer. Nur der SYSDBA und der Datenbankbesitzer dürfen die Datenbank löschen. Sollte kein Datenbankbesitzer bei der Erzeugung der Datenbank angegeben werden ist nur der SYSDBA autorisiert, die Datenbank zu löschen.

Wenn ein Benutzer eine Tabelle erzeugt, wird er Tabellenbesitzer und nur der Tabellenbesitzer und der SYSDBA dürfen die Tabelle löschen.

Der SYSDBA und der Datenbankbesitzer können GRANT, REVOKE und Zugangsrechte an Datenbankbenutzer vergeben; der SYSDBA und der Tabellenbesitzer können GRANT, REVOKE und Zugangsrechte auf Tabellen vergeben. Diese Regel gelten auch für Views und Prozeduren.

Den Benutzern Zugang zur Datenbank zu gewähren macht wenig Sinn, wenn sie keinen Zugang zu den Datenbankobjekten haben. Serversicherheit wird daher in IBExpert mit dem Benutzermanager verwaltet; Benutzerrechte können dann im IBExpert Rechtemanager erteilt und verwaltet werden.

Weitere Sicherheitsfeatures:

  1. Views: können verwendet werden um viele Tabelleninformationen vor den Benutzern zu verbergen; die Benutzer haben nur Zugang zu den Spalten und Zeilen, die sie sehen müssen, um ihre Arbeit ausführen zu können.
  2. Referentielle Integrität: schützt Daten vor orphaned rows und anderen Operationen, die möglicherweise die Datenbankintegrität schaden könnten (weitere Information finden Sie im Kaptiel, Referentielle Integrität).
  3. GRANT und REVOKE Anweisungen: können im IBExpert Rechtemanager benutzt werden, um zu spezifizieren welche Benutzer Zugang zu welchen Tabellen und Views haben dürfen, und ob sie auch Daten manipulieren oder nur ansehen dürfen.
  4. Ein Objekt darf nicht gelöscht werden, wenn es an einer andere Datenbankstelle referenziert wird. Zum Beispiel, eine Tabelle kann nicht gelöscht werden, wenn es in einer View referenziert wird, einer Prüfbeschränkung, einem Trigger, einer Prozedur oder in einem anderen Objekt referenziert wird.

zurück zum Seitenanfang

Serversicherheit SECURITY2.FDB

Die Firebird 2.x Sicherheitsdatenbank wurde in security2.fdb umbenannt. Die Benutzerauthentifikationsstabelle, die Benutzernamen und Passwörter speichert, heißt nun RDB$USERS. Die Tabelle, "users", existiert nicht mehr, dafür gibt es eine neue View, "USERS", auf RDB$USERS.

Wenn Sie eine frühere Sicherheitsdatenbank upgraden möchten, lesen Sie bitte Mit der neuen Sicherheitsdatenbank arbeiten unten.

Hier ist eine Zusammenfassung der Hauptänderungen, deren Details im Firebird 2.0.4 Release Notes Kapitel, Security in Firebird 2, nachgelesen werden können:

Classic Server auf POSIX

Der Hauptgrund, direkten Zugang zu der Sicherheitsdatenbank einzuschränken war, es vor Zugriff von älteren Clientsoftware Versionen zu schützen. Gleichzeitig bietet es auch einen besseren Schutz des eingebetteten Classic Server auf POSIX, denn es ist höchst unwahrscheinlich, dass eine Zusammensetzung eines alten Clients und eines neuen Servers vorhanden sind.

Vorsicht: Allerdings ist Firebird Sicherheit in einer Hinsicht immer noch nicht zufriedenstellend: ein schwerwiegendes Firebird Sicherheitsproblem ist immer noch nicht gelöst: die Übertragung schlecht-verschlüsselter Passwörter "in clear" über das Netzwerk. Es ist nicht möglich dieses Problem zu lösen, ohne alte Clients abzubrechen.

Das Problem kann kurzfristig durch den Einsatz von IP-tunneling Software (z.B. ZeBeDee) gelöst werden, um Daten von und nach einem Firebird Server - sowohl 1.5 als auch 2.0 - zu übersenden. Es verbleibt die empfohlene Methode, um ein sicherer Zugang zu Ihrem Firebird Server über das Internet zu gewährleisten.

Bei der neuen Sicherheitsdatenbank zu beachten

Wenn Sie versuchen, eine prä-Firebird 2 Sicherheitsdatenbank security.fdb oder eine umbenannte isc4.gdb in einen aktuellen Firebird-Ordner zu legen und dann anschließend mit dem Server zu verbinden, erhalten Sie die Nachricht "Cannot attach to password database". Es ist keinen Bug, sondern beabsichtigt. Eine Sicherheitsdatenbank aus einer frühereren Firebirdversion kann nicht direkt in Firebird 2.0 oder höher verwendet werden.

Um eine alte Sicherheitsdatenbank nutzen zu können, müssen Sie den Upgradeskript, security_database.sql, der sich im ../upgrade-Unterordner der Firebird Server Installation befindet, oder im Appendix to Firebird 2 Release Notes zu diesen Notizen: Security Upgrade Script ausführen

Die Sicherheitsdatenbank Upgrade durchführen

Führen Sie folgende Schritte aus, um den Upgrade durchzuführen:

  1. Legen Sie die alte Sicherheitsdatenbank dort ab, wo Sie sie noch finden können, falls Sie eine Kopie benötigen, aber nicht in Firebirds neuen Hauptordner.
  2. Starten Sie Firebird 2 mit ihrer neuen nativen security2.fdb.
  3. Konvertieren Sie die alte Sicherheitsdatenbank zu ODS11 (d.h. führen Sie einen Backup und dann mit Firebird 2.0 einen Restore aus). Ohne diesen Schritt wird der security_database.sql nicht funktionieren!
  4. Verbinden Sie die restorierten Sicherheitsdatenbank als SYSDBA und führen Sie den Skript aus.
  5. Halten Sie die Firebirddienst an.
  6. Kopieren Sie die upgraded Datenbank als security2.fdb in das Firebird 2 Hauptverzeichnis.
  7. Starten Sie Firebird neu.

Nun sollten Sie mit dem Firebird 2 Server anhand Ihren alten Loginnamen und Passwörtern verbinden können.

NULL-Fähigkeit des RDB$PASSWD

Vor Firebird 2.0 waren User mit NULL-Passwörtern erlaubt. Seit Version 2.0, das RDB$PASSWD-Feld in der Sicherheitsdatenbank ist als NOT NULL definiert.

Jedoch um Exceptions während der Upgradeprozess zu vermeiden, wird das Feld als null-fähig im Upgradeskript erzeugt. Wenn Sie wirklich sicher sind, dass Sie keine leere Passwortfelder in der Sicherheitsdatenbank haben, können Sie den Skript selbst modifizieren. Zum Beispiel, können Sie folgende Zeile editieren, von: 

 RDB$PASSWD RDB$PASSWD,

zu 

 RDB$PASSWD RDB$PASSWD NOT NULL,

Vorsicht mit LegacyHash

So lange Sie LegacyHash = 1 in firebird.conf konfigurieren, funktioniert die Firebird Sicherheit nicht vollständig. Um diese zu berichtigen, müssen Sie folgendes machen:

  1. Ändern Sie das SYSDBA-Passwort.
  2. Lassen Sie die User ihre Passwörter ändern (in 2.0 kann jeder User sein eigenes Passwort selbst ändern).
  3. Setzen Sie LegacyHash zurück zum Defaultwert, 0, oder kommentieren Sie es aus.
  4. Die Konfigurationsänderung wird erst wirksam, nachdem Sie den Firebirdserver gestoppt und neu gestartet haben.

Source: Firebird 2.0.4 Release Notes

zurück zum Seitenanfang

Userpasswort mit Batch-Datei ändern

Um ein Userpasswort auf der Kommandozeilenebene zu ändern verwenden Sie folgenden Syntax: 

 gsec -modify SYSDBA -pw password

oder: 

 gsec -user SYSDBA -password oldpassword -modify SYSDBA -pw newpassword

Beispiel einer Batchdatei: 

 set isc_user=sysdba
 set isc_password=masterke
 gsec -add username -pw password

Siehe auch:
deutschsprachig:
Role
WITH ADMIN OPTION
Referentielle Integrität
englischsprachig:
REVOKE ADMIN OPTION FROM

zurück zum Seitenanfang
<< Generiere HTML Dokumentation | IBExpert | Rechtemanager >>