SicherheitSQL-Anweisungen für die Benutzerverwaltung

Die Sicherheit der gesamten Datenbank hängt davon ab, einen Benutzer zu identifizieren und seine Berechtigung zu überprüfen, ein Verfahren, das als Authentifizierung bekannt ist.Die Benutzerauthentifizierung kann auf verschiedene Weise durchgeführt werden, abhängig von der Einstellung des Parameters AuthServer in der Konfigurationsdatei firebird.conf.Dieser Parameter enthält die Liste der Authentifizierungs-Plugins, die beim Herstellen einer Verbindung zum Server verwendet werden können.Wenn das erste Plugin bei der Authentifizierung fehlschlägt, kann der Client mit dem nächsten Plugin fortfahren usw.Wenn kein Plugin den Benutzer authentifizieren konnte, erhält der Benutzer eine Fehlermeldung.

Die Informationen über Benutzer, die berechtigt sind, auf einen bestimmten Firebird-Server zuzugreifen, werden in einer speziellen Sicherheitsdatenbank namens security3.fdb gespeichert.Jeder Eintrag in security4.fdb ist ein Benutzerkonto für einen Benutzer.Für jede Datenbank kann die Sicherheitsdatenbank in der Datei database.conf (Parameter SecurityDatabase) überschrieben werden.Jede Datenbank kann eine Sicherheitsdatenbank sein, sogar für diese Datenbank selbst.

Ein Benutzername, bestehend aus bis zu 63 Zeichen, ist ein Bezeichner, der den normalen Regeln für Bezeichner folgt (Groß-/Kleinschreibung nicht in Anführungszeichen, Groß-/Kleinschreibung in doppelten Anführungszeichen).Aus Gründen der Abwärtskompatibilität akzeptieren einige Anweisungen (z. B. isqls CONNECT) Benutzernamen in einfachen Anführungszeichen, die sich wie normale Bezeichner ohne Anführungszeichen verhalten.

Die maximale Passwortlänge hängt vom User-Manager-Plugin ab (Parameter UserManager, in firebird.conf oder databases.conf).Bei Kennwörtern muss die Groß-/Kleinschreibung beachtet werden.Der Standardbenutzermanager ist das erste Plugin in der UserManager-Liste, kann aber in den SQL-Benutzerverwaltungsanweisungen überschrieben werden.Für das Srp-Plugin beträgt die maximale Passwortlänge 255 Zeichen, bei einer effektiven Länge von 20 Bytes (siehe auch [fblangref40-security-auth-effective-20-bytes-de]).Für das Legacy_UserManager-Plugin sind nur die ersten acht Bytes von Bedeutung.Während es für Legacy_UserManager gültig ist, ein Passwort mit mehr als acht Bytes einzugeben, werden alle nachfolgenden Zeichen ignoriert.

Warum beträgt die effektive Kennwortlänge SRP 20 Byte?

Das SRP-Plugin hat keine 20-Byte-Beschränkung für die Kennwortlänge, und längere Kennwörter können verwendet werden.Hashes verschiedener Passwörter, die länger als 20 Byte sind, sind auch – normalerweise – unterschiedlich.Diese effektive Grenze ergibt sich aus der begrenzten Hash-Länge in SHA1 (wird in der Firebirds SRP-Implementierung verwendet), 20 Byte oder 160 Bit und dem pigeonhole-Prinzip.Früher oder später wird es ein kürzeres (oder längeres) Passwort geben, das den gleichen Hash hat (z.B. bei einem Brute-Force-Angriff).Aus diesem Grund wird die effektive Kennwortlänge für den SHA1-Algorithmus häufig als 20 Byte bezeichnet.

Die eingebettete Version des Servers verwendet keine Authentifizierung.Allerdings müssen in den Verbindungsparametern der Benutzername und ggf. die Rolle angegeben werden, da sie den Zugriff auf Datenbankobjekte steuern.

SYSDBA oder der Eigentümer der Datenbank erhalten uneingeschränkten Zugriff auf alle Objekte der Datenbank.Benutzer mit der Rolle RDB$ADMIN erhalten einen ähnlichen uneingeschränkten Zugriff, wenn sie die Rolle beim Verbinden angeben.

Besonders privilegierte Benutzer

In Firebird ist das SYSDBA-Konto ein “Superuser”, der über alle Sicherheitsbeschränkungen hinaus existiert.Er hat vollständigen Zugriff auf alle Objekte in allen regulären Datenbanken auf dem Server und vollen Lese-/Schreibzugriff auf die Konten in der Sicherheitsdatenbank security4.fdb.Kein Benutzer hat Zugriff auf die Metadaten der Sicherheitsdatenbank.

Für Srp existiert das SYSDBA-Konto standardmäßig nicht;Es muss über eine eingebettete Verbindung erstellt werden.Für Legacy_Auth ist das Standard-SYSDBA-Passwort unter Windows und MacOS masterkey — oder masterke, um genau zu sein, wegen der Längenbeschränkung von 8 Zeichen.

Important

Extrem wichtig!

Das Standardpasswort masterkey ist im ganzen Universum bekannt.Sie sollte geändert werden, sobald die Installation des Firebird-Servers abgeschlossen ist.

Andere Benutzer können auf verschiedene Weise erhöhte Berechtigungen erwerben, von denen einige von der Betriebssystemplattform abhängig sind.Diese werden in den folgenden Abschnitten besprochen sowie in [fblangref40-security-administrators-de] und [fblangref40-security-sys-privs-de] zusammengefasst.

docnext count = 18

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.

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:

Gewähren der Rolle als Standard-Rolle.Der Benutzer kann jederzeit Benutzer erstellen, ändern oder löschen.
```
grant default MANAGE_USERS to user ALEX;
```
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:

mit Win_Sspi-Authentifizierung und
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

Benutzerauthentifizierung