FirebirdSQL logo
 SicherheitSQL-Anweisungen für die Benutzerverwaltung 

POSIX Hosts

Auf POSIX-Systemen, einschließlich MacOS, wird der POSIX-Benutzername als Firebird Embedded-Benutzername verwendet, wenn der Benutzername nicht explizit angegeben wird.

Der SYSDBA-Benutzer auf POSIX

Auf anderen POSIX-Hosts als MacOSX hat der SYSDBA-Benutzer kein Standardkennwort.Wenn die vollständige Installation mit den Standardskripten erfolgt, wird ein einmaliges Passwort erstellt und in einer Textdatei im gleichen Verzeichnis wie security4.fdb gespeichert, üblicherweise` /opt/firebird/.Der Name der Passwortdatei ist `SYSDBA.password.

Note

Bei einer Installation, die von einem verteilungsspezifischen Installationsprogramm durchgeführt wird, kann der Speicherort der Sicherheitsdatenbank und der Kennwortdatei vom Standard abweichen.

docnext count = 16

Der root-Benutzer

Der Benutzer * root * kann in Firebird Embedded direkt als SYSDBA fungieren.Firebird behandelt root als wäre es SYSDBA und bietet Zugriff auf alle Datenbanken auf dem Server.

Windows-Hosts

Auf Windows-Server-fähigen Betriebssystemen können Betriebssystemkonten verwendet werden.Die Windows-Authentifizierung (auch bekannt als Trusted Authentication) kann aktiviert werden, indem das Win_Sspi-Plugin in die AuthServer-Liste in firebird.conf aufgenommen wird.Das Plugin muss auch clientseitig in der Einstellung AuthClient vorhanden sein.

Administratoren des Windows-Betriebssystems werden beim Herstellen einer Verbindung mit einer Datenbank nicht automatisch SYSDBA-Berechtigungen gewährt.Dazu muss die intern erstellte Rolle RDB$ADMIN von SYSDBA oder dem Datenbankbesitzer geändert werden, um sie zu aktivieren.Einzelheiten finden Sie im späteren Abschnitt mit dem Titel [fblangref40-security-autoadminmapping-de].

Note

Vor Firebird 3.0 wurden mit aktivierter vertrauenswürdiger Authentifizierung Benutzer, die die Standardprüfungen bestanden haben, automatisch 'CURRENT_USER' zugeordnet.In Firebird 3.0 und höher muss die Zuordnung explizit mit CREATE MAPPING erfolgen.

Der Datenbankbesitzer

Der “Besitzer” (engl. “Owner”) einer Datenbank ist entweder der Benutzer, der zum Zeitpunkt der Erstellung (oder Wiederherstellung) der Datenbank CURRENT_USER war, oder, falls der USER-Parameter in der CREATE DATABASE-Anweisung angegeben wurde, der angegebene Benutzer.

“Owner” ist kein Benutzername.Der Benutzer, der Eigentümer einer Datenbank ist, hat volle Administratorprivilegien in Bezug auf diese Datenbank, einschließlich des Rechts, sie zu löschen, aus einem Backup wiederherzustellen und die << fblangref40-security-autoadminmapping-de>> Fähigkeit.

Note

Vor Firebird 2.1 hatte der Besitzer keine automatischen Berechtigungen für Datenbankobjekte, die von anderen Benutzern erstellt wurden.

Benutzer mit dem Systemprivileg USER_MANAGEMENT

Ein Benutzer mit dem USER_MANAGEMENT Systemprivileg in der Sicherheitsdatenbank kann Benutzer erstellen, ändern und löschen.Um die Berechtigung USER_MANAGEMENT zu erhalten, muss die Sicherheitsdatenbank eine Rolle mit dieser Berechtigung haben:

create role MANAGE_USERS
  set system privileges to USER_MANAGEMENT;

Es gibt zwei Möglichkeiten für den Benutzer, diese Rechte auszuüben:

  1. Gewähren der Rolle als Standard-Rolle.Der Benutzer kann jederzeit Benutzer erstellen, ändern oder löschen.

    grant default MANAGE_USERS to user ALEX;

  2. Gewähren der Rolle als normale Rolle.Der Benutzer kann nur dann Benutzer erstellen, ändern oder löschen, wenn die Rolle explizit beim Anmelden oder mit SET ROLE angegeben wird.

    grant MANAGE_USERS to user ALEX;

    Wenn die Sicherheitsdatenbank eine andere Datenbank ist als die, mit der sich der Benutzer verbindet – was normalerweise bei der Verwendung von security4.fdb der Fall ist – dann muss auch eine Rolle mit demselben Namen vorhanden sein und dem Benutzer in dieser Datenbank für die Benutzer, um die Rolle aktivieren zu können.Die Rolle in der anderen Datenbank benötigt keine Systemberechtigungen oder sonstigen Berechtigungen.

Note

Das Systemprivileg USER_MANAGEMENT erlaubt einem Benutzer nicht, die Administratorrolle zu erteilen oder zu entziehen.Dies erfordert die Rolle RDB$ADMIN.

RDB$ADMIN-Rolle

Die intern erstellte Rolle "RDB$ADMIN" ist in allen Datenbanken vorhanden.Die Zuweisung der Rolle RDB$ADMIN an einen regulären Benutzer in einer Datenbank gewährt diesem Benutzer die Privilegien des SYSDBA nur in dieser Datenbank.

Die erhöhten Berechtigungen werden wirksam, wenn der Benutzer unter der Rolle RDB$ADMIN bei dieser regulären Datenbank angemeldet ist und die vollständige Kontrolle über alle Objekte in dieser Datenbank bietet.

Die Zuweisung der Rolle RDB$ADMIN in der Sicherheitsdatenbank verleiht die Berechtigung zum Erstellen, Bearbeiten und Löschen von Benutzerkonten.

In beiden Fällen kann der Benutzer mit den erhöhten Rechten jedem anderen Benutzer die Rolle RDB$ADMIN zuweisen.Mit anderen Worten, die Angabe von WITH ADMIN OPTION ist unnötig, da dies in die Rolle integriert ist.

Gewähren der Rolle RDB$ADMIN in der Sicherheitsdatenbank

Da sich niemand – nicht einmal SYSDBA – aus der Ferne mit der Sicherheitsdatenbank verbinden kann, sind die Anweisungen GRANT und REVOKE für diese Aufgabe nutzlos.Stattdessen wird die Rolle RDB$ADMIN mit den SQL-Anweisungen für die Benutzerverwaltung gewährt und entzogen:

CREATE USER new_user
  PASSWORD 'password'
  GRANT ADMIN ROLE;

ALTER USER existing_user
  GRANT ADMIN ROLE;

ALTER USER existing_user
  REVOKE ADMIN ROLE;
Note

GRANT ADMIN ROLE und REVOKE ADMIN ROLE sind keine Anweisungen im GRANT und REVOKE Lexikon.Es handelt sich um Drei-Wort-Klauseln zu den Anweisungen CREATE USER und ALTER USER.
Table 1. Parameters for RDB$ADMIN Role GRANT and REVOKE

Parameter

Beschreibung

new_user

Name für den neuen Benutzer

existing_user

Name eines bestehenden Benutzers

password

Benutzerkennwort

Der Benutzer, der die Rechte vergibt (engl. grantor) muss als Administrator angemeldet sein.

Siehe auch

CREATE USER, ALTER USER, GRANT, REVOKE

Die gleiche Aufgabe mit gsec ausführen

Warning

Mit Firebird 3.0 war gsec veraltet.Es wird empfohlen, stattdessen die SQL-Benutzerverwaltungsanweisungen zu verwenden.

Eine Alternative besteht darin, gsec mit dem Parameter -admin zu verwenden, um das Attribut RDB$ADMIN im Datensatz des Benutzers zu speichern:

gsec -add new_user -pw password -admin yes
gsec -mo existing_user -admin yes
gsec -mo existing_user -admin no
Note

Abhängig vom administrativen Status des aktuellen Benutzers können beim Aufruf von gsec weitere Parameter benötigt werden, z. -user und -pass oder -trusted.

Verwenden der Rolle RDB$ADMIN in der Sicherheitsdatenbank

Um Benutzerkonten über SQL zu verwalten, muss der Stipendiat die Rolle RDB$ADMIN beim Verbinden oder über SET ROLE angeben.Kein Benutzer kann remote eine Verbindung zur Sicherheitsdatenbank herstellen. Die Lösung besteht daher darin, dass der Benutzer eine Verbindung zu einer regulären Datenbank herstellt, in der er auch die Rechte RDB$ADMIN hat und die Rolle RDB$ADMIN in seinen Anmeldeparametern angibt.Von dort aus können sie jeden beliebigen SQL-Benutzerverwaltungsbefehl senden.

Wenn es keine reguläre Datenbank gibt, in der der Benutzer die Rolle RDB$ADMIN hat, ist eine Kontoverwaltung über SQL-Abfragen nicht möglich, es sei denn, sie verbinden sich direkt über eine eingebettete Verbindung mit der Sicherheitsdatenbank.

Verwenden von gsec mit RDB$ADMIN-Rechten

Um die Benutzerverwaltung mit gsec durchzuführen, muss der Benutzer den zusätzlichen Schalter -role rdb$admin bereitstellen.

Gewähren der Rolle "RDB$ADMIN" in einer regulären Datenbank

In einer regulären Datenbank wird die Rolle RDB$ADMIN mit der üblichen Syntax zum Gewähren und Entziehen von Rollen gewährt und entzogen:

GRANT [ROLE] RDB$ADMIN TO username

REVOKE [ROLE] RDB$ADMIN FROM username
Table 1. Parameters for RDB$ADMIN Role GRANT and REVOKE

Parameter

Beschreibung

username

Name des Benutzers

Um die Rolle RDB$ADMIN zu erteilen und zu entziehen, muss der Erteilender als Administrator angemeldet sein..Siehe auchGRANT, REVOKE

Verwenden der Rolle RDB$ADMIN in einer regulären Datenbank

Um seine RDB$ADMIN-Privilegien auszuüben, muss der Stipendiat die Rolle bei der Verbindung mit der Datenbank in die Verbindungsattribute aufnehmen oder später mit SET ROLE angeben.

AUTO ADMIN MAPPING

Windows-Administratoren werden nicht automatisch RDB$ADMIN-Berechtigungen gewährt, wenn sie sich mit einer Datenbank verbinden (natürlich wenn Win_Sspi aktiviert ist)Der Schalter AUTO ADMIN MAPPING bestimmt nun datenbankweise, ob Administratoren über automatische RDB$ADMIN-Rechte verfügen.Wenn eine Datenbank erstellt wird, ist sie standardmäßig deaktiviert.

Wenn AUTO ADMIN MAPPING in der Datenbank aktiviert ist, wird es immer wirksam, wenn ein Windows-Administrator eine Verbindung herstellt:

  1. mit Win_Sspi-Authentifizierung und

  2. ohne eine Rolle anzugeben

Nach einer erfolgreichen auto admin-Verbindung wird die aktuelle Rolle auf RDB$ADMIN gesetzt.

Wenn beim Connect eine explizite Rolle angegeben wurde, kann die Rolle RDB$ADMIN später in der Sitzung mit SET TRUSTED ROLE übernommen werden.

Auto-Admin-Mapping in regulären Datenbanken

So aktivieren und deaktivieren Sie die automatische Zuordnung in einer regulären Datenbank:

ALTER ROLE RDB$ADMIN
  SET AUTO ADMIN MAPPING;  -- aktivieren

ALTER ROLE RDB$ADMIN
  DROP AUTO ADMIN MAPPING; -- deaktivieren

Beide Anweisungen müssen von einem Benutzer mit ausreichenden Rechten ausgegeben werden, d. h.:

  • Der Datenbankbesitzer

  • Ein Administrator

  • Ein Benutzer mit der Berechtigung ALTER ANY ROLE

Note

Die Anweisung

ALTER ROLE RDB$ADMIN
  SET AUTO ADMIN MAPPING;

ist eine vereinfachte Form einer CREATE MAPPING-Anweisung, um ein Mapping der vordefinierten Gruppe DOMAIN_ANY_RID_ADMINS auf die Rolle von RDB$ADMIN zu erstellen:

CREATE MAPPING WIN_ADMINS
  USING PLUGIN WIN_SSPI
  FROM Predefined_Group DOMAIN_ANY_RID_ADMINS
  TO ROLE RDB$ADMIN;

Dementsprechend ist die Anweisung

ALTER ROLE RDB$ADMIN
  DROP AUTO ADMIN MAPPING

gleichbedeutend zum Statement

DROP MAPPING WIN_ADMINS;

Für weitere Details, siehe auch [fblangref40-security-mapping-de]

In einer regulären Datenbank wird der Status von AUTO ADMIN MAPPING nur zur Verbindungszeit überprüft.Wenn ein Administrator die Rolle "RDB$ADMIN" hat, weil die automatische Zuordnung bei der Anmeldung aktiviert war, behält er diese Rolle für die Dauer der Sitzung bei, auch wenn er oder eine andere Person die Zuordnung in der Zwischenzeit deaktiviert.

Ebenso ändert das Einschalten von "AUTO ADMIN MAPPING" die aktuelle Rolle für Administratoren, die bereits verbunden waren, nicht in RDB$ADMIN.

Auto Admin Mapping in der Sicherheitsdatenbank

Die Anweisung ALTER ROLE RDB$ADMIN kann AUTO ADMIN MAPPING in der Sicherheitsdatenbank nicht aktivieren oder deaktivieren.Sie können jedoch ein globales Mapping für die vordefinierte Gruppe DOMAIN_ANY_RID_ADMINS auf die Rolle RDB$ADMIN wie folgt erstellen:

CREATE GLOBAL MAPPING WIN_ADMINS
  USING PLUGIN WIN_SSPI
  FROM Predefined_Group DOMAIN_ANY_RID_ADMINS
  TO ROLE RDB$ADMIN;

Außerdem können Sie gsec verwenden:

gsec -mapping set

gsec -mapping drop
Note

Abhängig vom administrativen Status des aktuellen Benutzers können beim Aufruf von gsec weitere Parameter benötigt werden, z. -user und -pass oder -trusted.

Nur SYSDBA kann AUTO ADMIN MAPPING aktivieren, wenn es deaktiviert ist, aber jeder Administrator kann es deaktivieren.

Wenn AUTO ADMIN MAPPING in gsec deaktiviert wird, schaltet der Benutzer den Mechanismus selbst aus, der ihm den Zugriff gewährt hat, und somit wäre er nicht in der Lage, AUTO ADMIN MAPPING wieder zu aktivieren.Auch in einer interaktiven gsec-Sitzung wird die neue Flag-Einstellung sofort wirksam.

Administratoren

Als allgemeine Beschreibung ist ein Administrator ein Benutzer mit ausreichenden Rechten zum Lesen, Schreiben, Erstellen, Ändern oder Löschen von Objekten in einer Datenbank, für die der Administratorstatus dieses Benutzers gilt.Die Tabelle fasst zusammen, wie Superuser-Rechte in den verschiedenen Firebird-Sicherheitskontexten aktiviert werden.

Table 1. Administrator- (Superuser-) Eigenschaften

Benutzer

RDB$ADMIN-Rolle

Hinweis

SYSDBA

Auto

Existiert automatisch auf Serverebene.Verfügt über alle Berechtigungen für alle Objekte in allen Datenbanken.Kann Benutzer erstellen, ändern und löschen, hat jedoch keinen direkten Fernzugriff auf die Sicherheitsdatenbank

root-Benutzer unter POSIX

Auto

Genau wie SYSDBA.Nur Firebird Embedded.

Superuser unter POSIX

Auto

Genau wie SYSDBA.Nur Firebird Embedded.

Windows-Administrator

Als CURRENT_ROLE festlegen, wenn die Anmeldung erfolgreich ist

Genau wie SYSDBA, wenn alle der folgenden Bedingungen zutreffen:

  • In der Datei firebird.conf enthält AuthServer Win_Sspi und Win_Sspi ist in der Konfiguration der clientseitigen Plugins (AuthClient) vorhanden

  • In Datenbanken, in denen AUTO ADMIN MAPPING aktiviert ist oder eine entsprechende Zuordnung der vordefinierten Gruppe DOMAIN_ANY_RID_ADMINS für die Rolle RDB$ADMIN existiertMIN

  • Bei der Anmeldung ist keine Rolle angegeben

Datenbankbesitzer

Auto

Wie SYSDBA, aber nur in den Datenbanken, die sie besitzen

Normaler Benutzer

Muss vorher erteilt werden;muss beim Login angegeben werden

Wie SYSDBA, aber nur in den Datenbanken, in denen die Rolle zugewiesen ist

Benutzer unter POSIX-Betriebssystemen

Muss vorher erteilt werden;muss beim Login angegeben werden

Wie SYSDBA, aber nur in den Datenbanken, in denen die Rolle zugewiesen ist.Nur Firebird Embedded.

Windows-Benutzer

Muss vorher erteilt werden;muss beim Login angegeben werden

Wie SYSDBA, aber nur in den Datenbanken, in denen die Rolle zugewiesen ist.Nur verfügbar, wenn in der Datei firebird.conf AuthServer Win_Sspi enthält und Win_Sspi in der Konfiguration der clientseitigen Plugins (AuthClient) vorhanden ist

Fein abgestufte Systemprivilegien

Firebird 4.0 gewährte Benutzern nicht nur volle Administratorrechte, sondern führte auch Systemprivilegien ein, die es ermöglichen, normalen Benutzern eine Untergruppe von Administratorrechten zu erteilen, die in der Vergangenheit nur auf SYSDBA und Administratoren beschränkt waren.Beispielsweise:

  • Führen Sie Dienstprogramme wie gbak, gfix, nbackup usw. aus

  • Fahren Sie eine Datenbank herunter und bringen Sie sie online

  • Verfolgen Sie die Anhänge anderer Benutzer

  • Greifen Sie auf die Überwachungstabellen zu

  • Führen Sie Management-Anweisungen . aus

Die Implementierung definiert einen Satz von Systemberechtigungen, analog zu Objektberechtigungen, aus denen Listen privilegierter Aufgaben Rollen zugewiesen werden können.

Es ist auch möglich, einem Systemprivileg normale Privilegien zu erteilen, wodurch sich das Systemprivileg wie ein spezieller Rollentyp verhält.

Die Systemprivilegien werden über CREATE ROLE und ALTER ROLE zugewiesen.

Warning

Beachten Sie, dass jedes Systemprivileg ein sehr geringes Maß an Kontrolle bietet.Für einige Aufgaben kann es erforderlich sein, dem Benutzer mehr als eine Berechtigung zu erteilen, um eine Aufgabe auszuführen.Fügen Sie beispielsweise IGNORE_DB_TRIGGERS zu USE_GSTAT_UTILITY hinzu, da gstat Datenbank-Trigger ignorieren muss.

Liste der gültigen Systemberechtigungen

In der folgenden Tabelle sind die Namen der gültigen Systemberechtigungen aufgeführt, die Rollen gewährt und entzogen werden können.

USER_MANAGEMENT

Benutzer verwalten (in der Sicherheitsdatenbank angegeben)
READ_RAW_PAGES

Seiten im Rohformat lesen mit Attachment::getInfo()
CREATE_USER_TYPES

Hinzufügen/Ändern/Löschen von Nicht-System-Datensätzen in RDB$TYPES
USE_NBACKUP_UTILITY

Verwenden von nbackup um Datenbankkopien zu erstellen
CHANGE_SHUTDOWN_MODE

Datenbank herunterfahren und online schalten
TRACE_ANY_ATTACHMENT

Verfolgen von Verbindungen anderer Benutzer
MONITOR_ANY_ATTACHMENT

Überwachen (Tabellen MON$) Anhänge anderer Benutzer
ACCESS_SHUTDOWN_DATABASE

Zugriff auf die Datenbank, wenn sie heruntergefahren ist
CREATE_DATABASE

Neue Datenbanken erstellen (in security.db angegeben)
DROP_DATABASE

Diese Datenbank löschen
USE_GBAK_UTILITY

Verwenden des gbak-Dienstprogramm
USE_GSTAT_UTILITY

Verwenden des gstat-Dienstprogramm
USE_GFIX_UTILITY

Verwenden des gfix-Dienstprogramm
IGNORE_DB_TRIGGERS

Engine anweisen, keine Trigger auf DB-Ebene auszuführen
CHANGE_HEADER_SETTINGS

Parameter auf der DB-Header-Seite ändern
SELECT_ANY_OBJECT_IN_DATABASE

Verwenden von SELECT für jedes auswählbare Objekt
ACCESS_ANY_OBJECT_IN_DATABASE

Zugriff (auf jede mögliche Weise) auf jedes Objekt
MODIFY_ANY_OBJECT_IN_DATABASE

Beliebiges Objekt ändern (bis zum Ablegen)
CHANGE_MAPPING_RULES

Authentifizierungszuordnungen ändern
USE_GRANTED_BY_CLAUSE

Verwenden von GRANTED BY in GRANT- und REVOKE-Anweisungen
GRANT_REVOKE_ON_ANY_OBJECT

GRANT- und REVOKE-Rechte für jedes Objekt in der Datenbank
GRANT_REVOKE_ANY_DDL_RIGHT

GRANT und REVOKE für alle DDL-Rechte
CREATE_PRIVILEGED_ROLES

Verwenden von SET SYSTEM PRIVILEGES in Rollen
MODIFY_EXT_CONN_POOL

Verwenden des Befehls ALTER EXTERNAL CONNECTIONS POOL
REPLICATE_INTO_DATABASE

Verwenden der Replikations-API, um Änderungssets in die Datenbank zu laden