Verständnis von Security.fdb

Forum für Fragen rund um die Installation, Konfiguration und Inbetriebnahme von Firebird.

Moderator: martin.koeditz

Antworten
zappa2
Beiträge: 11
Registriert: Fr 5. Okt 2018, 10:59

Do 7. Nov 2019, 09:48

Mal eine Frage zum grundsätzlichen Verständnis der security2/3.fdb:

Ich kann ja in dieser DB diverse Benutzer einrichten, mit Adminrechten versehen, aktivieren/deaktivieren, Benutzer-ID und Gruppen-ID vergeben usw. Genau so, wie in jeder anderen DB.

Mir stellt sich jetzt die Frage, ob ich diese nicht als eine zentrale Benutzerverwaltung für alle benutzten DBs in einer Server-Installation einrichten und benutzen kann. Momentan ist es so, dass ich in jeder DB eigene User mit dedizierten Rechten einrichte. Wenn ich einen neuen Mitarbeiter anlegen will, mache ich den ganzen Vorgang in allen DBs, ebenso beim Löschen oder ändern von Mitarbeitern.

Ich vermute, dass ich einfach noch nicht die Grundidee hinter der Security-DB verstanden habe. Google hat mir auch nicht wirklich helfen können.

Kann mich jemand bitte kurz darüber aufklären, wie ich diese eine Security-DB als zentrale User-Verwaltung einrichte und dann praktisch einsetze (Zugriff der anderen DBs auf die User aus der SecurityX.fdb)?
bfuerchau
Beiträge: 134
Registriert: Mo 7. Mai 2018, 18:09

Do 7. Nov 2019, 10:25

Eigentlich findest du alles hier:
https://firebirdsql.org/file/documentat ... s-sql.html
https://firebirdsql.org/file/documentat ... vs-de.html

Da man sich nicht mit der Security-DB verbinden kann, gelten eben alle Sicherheits-DDL's ausschließlich für die aktuell verbundene DB.
Alleine aus Sicherheitsgründen ist dies der bessere Weg.

Wobei ich konzeptionell den sog. App-User bevorzuge. Dies ist der Admin der Anwendung und der DB. Ich verbinde mich aus der Anwendung immer mit dem App-User zur DB.
Denn überlege mal was für einen Aufwand die Admins dieser Welt haben Berechtigungen angefangen vom AD (Domain) über Verzeichnisse bis hin zu DB's zu verteilen.
Für AD kann man zumindest mit Powershell scripten und beim SQL-Server aufs AD verweisen, zumindest wenn man Gruppen (Abteilungen) verwendet.

Es ist zwar schön, User auf einzelne Tabellen berechtigen zu können. Aber in der ERP-Welt (also Anwendungen der Auftragsverwaltung, Logistik, Finanzen, ...) werden Berechtigungen eher in Programmaufrufen als Tabellenverwendung realisiert. Denn ansonsten fällt eine App da dann schon mal auf die Schnauze weil z.B. bei der Auftragserfassung die Bestandsreservierung des Lagers nicht erlaubt wurde, weil die Lagertabelle zur Logistik und nicht zum Vertrieb gehört.
Und schon war eine Auftragserfassung nicht mehr möglich.

PS:
Hier gibts noch eine sehr gute Diskussion zum Thema Sicherheit:
https://stackoverflow.com/questions/339 ... me-passwor

Übrigens: Der tolle Microsoft-SQL-Server macht das auch nicht anders.
jhoehne
Beiträge: 14
Registriert: Di 11. Dez 2018, 09:19

Do 7. Nov 2019, 13:09

Ich verwende auch den "App-User", haben aber deren dreie: den "Admin", den "User" und den "Viewer":
Der "User" wird von allen Anwendungsprogrammen für die täglichen Arbeiten eingeloggt. Er darf Daten abfragen, anlegen, ändern und löschen. Er darf aber keine Strukturen ändern. Das darf nur der "Admin". Dieser wird bei Onlineupdates eingeloggt (und ggfs. von uns bei Fernwartungsvorgängen). Der "Viewer" schließlich dient dem Zugriff von außen, etwa via ODBC. Er "sieht" von der Datenbank nur einige ausgesuchte Views.
--
Joachim
Antworten