FirebirdSQL logo
 SicherheitSQL-Anweisungen für die Benutzerverwaltung 

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.

docnext count = 3

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