Benutzerverwaltung

[M303M]

Hallo zusammen,

hoffe Ihr könnt mir helfen, ich steh grad etwas auf dem Schlauch bei einer ganz banalen Frage (so dachte ich zumindest) :

Wohin gehört eine Benutzerverwaltung mit Passwortabfrage ? In die DB oder das FrontEnd ?


Hintergrund meiner Frage ist folgender :

Ich habe 3 Benutzer in einer Oracle DB angelegt bekommen (bin in einer Firma und nicht der Admin) :

"Admin"
"User"
"ReadUser"

Von diesen 3 Benutzern hat 1 Admin - Rechte und der Plan war, den anderen beiden die Rechte über Rollen zuzuteilen.

Es gibt hier ein paar Kollegen (10-20), die sich mit einem FrontEnd darauf verbinden sollen und die Tabellen des "Admin" (in dem ich alle angelegt habe) zugreifen und verändern oder lesen können sollen (mit einer entsprechenden Rolle im Benutzer "User").
Und wiederum weitere, die mit einer Rolle mit Leserechten über den Benutzer "ReadUser" lesend auf die Daten zugreifen können sollen.

Jetzt steh ich grad vor der ganz einfachen Frage :
Mehr Benutzer anlegen und damit die Benutzerverwaltung in die DB "auszulagern", oder im FrontEnd managen ?

Wie wird das überwiegend gemacht ?
Würde das überhaupt klappen, daß sich mehrere Benutzer (also die Kollegen) mit dem Login von "User" einloggen und dann gleichzeitig hier Daten verändern können ?

 

[dabadepdu]

Wenn es nicht User sind, die nur über einen Web / Applicationserver verbinden, dann würde man wohl die DB User anlegen. Hier hast Du am meisten Möglichkeiten. Du musst bei einem Kaufsystem lediglich die Lizenzbestimmungen beachten. Das gilt aber für Web - oder DB User Zugriff.

 

[M303M]

Ich würde dann auch für (sagen wir mal es wächst immens) tausende Benutzer für jeden einzelnen einen Benutzer in der DB anlegen und nur die Rolle vergeben ?

Was mich etwas verunsichert hat ist der Umstand, weil ich eben diese 3 User in einer großen Oracle DB bei uns in der Firma bekommen habe,
aber für "andere Benutzer" nur Datenbanken sehe, aber anscheinend keine Benutzer die darauf zugreifen, also scheint es nicht so realisiert worden zu sein
für die anderen DB - Benutzer. Oder würde nur ich die dann sehen ?

 

[Dukel]

Es gibt zwei Möglichkeiten.
Du nutzt die Benutzerverwaltung der DB oder implementierst eine eigene Benutzerverwaltung in der DB.
Bei ersterem brauchst du einen Servicenutzer, mit dem die Applikation mit der DB spricht. In deinem Fall wären die drei DB User Serviceuser.
Wenn die (menschlichen) Benutzer sich unterscheiden wollen brauchst du eine eigene Benutzerverwaltung in der DB/Applikation.

Viele Web-Anwendungen arbeiten so. Hier gibt es eine Usertabelle, in der die Nutzer gepflegt werden.
In einer Firma möchte man am liebsten eine Zentrale Benutzerverwaltung (z.B. Active Directory) nutzten. das muss aber auch der DB Admin einrichten.

Das Benutzerkonzept hätte man sich aber vorher überlegen sollen und dem DB Admin sagen, was man benötigt.

 

[dabadepdu]

aber für "andere Benutzer" nur Datenbanken sehe, aber anscheinend keine Benutzer die darauf zugreifen, also scheint es nicht so realisiert worden zu sein
für die anderen DB - Benutzer.

Das habe ich nicht verstanden.

In Oracle ist es so, dass ein Benutzer verglichen mit anderen Systemen mehr oder weniger eine eigene DB ist.
Wenn Du 3 Oracle User hast, hast Du 3 User Schema, in jedem kannst Du namensgleiche Tabellen anlegen, komplett identisch. Melden sich die 3 User an, sehen sie alle zunächst nur ihre Daten in ihren Tabellen. Das kann man wollen, wäre aber ungewöhnlich. Du hast z.B. eher einen application owner, einer der 3 User, der "Admin" z.B., in dem das Datenmodell liegt und dem entsprechend die Daten gehalten werden. Die anderen beiden Nutzer bekommen darauf Zugriffsrechte entlang des Bedarfs. Der "User" hat z.B. r/w Rechte für alles was man braucht, der "Readuser" nur Leserechte, typisch für Reporting o.ä.. Dem folgend könntest Du 3 verschiedene Anwendungen bauen, die intern mit jeweils einem der 3 User arbeiten, alle 3 Anwendungen mit unterschiedlichen Rechten und Funktionen. So ist es vielleicht gedacht. Das bedeutet, Du musst für die Anmeldung einzelner Echtuser eine eigene Verwaltung bauen.

Das Ganze hat verschiedene Aspekte. In einer Webapp kannst Du problemlos den Application User/Application Owner irgendwo mit Passwort im Klartext ablegen. Nur Admins haben darauf Zugriff. Ist es ein Fat Client, der z.B. irgendwo als EXE rumfliegt bedeutet das, in dieser EXE muss irgendwo der Application Owner mit (verschlüsseltem) Passwort gespeichert sein. Würde sich jeder User mit PW explizit als DB User anmelden, würde das PW nur zur Eingabe und Anmeldung verwendet und müsste nirgendwo gespeichert werden.
Es gibt dabei wie gesagt auch Lizenzfragen und vielleicht andere Aspekte. Du kannst eine 20er named user Lizenz haben, dann können halt 20 Nutzer sich explizit anmelden. Du kannst eine CPU Lizenz haben, dann können sich beliebig viele DB User anmelden (und existieren auch als echte DB User). Oracle beherrscht glaub ich auch eine Anmeldung über MS Active Directory, was wieder vielen individuellen Nutzern entsprechen würde. Nach meiner Erfahrung ist die Arbeit mit vielen individuellen Nutzern recht unproblematisch, weil es nicht gigantisch viel Speicher benötigt, explizite Benutzer Sessions zu haben. Aber mit den 3 Accounts, die Du erhalten hast, sieht es nicht nach sowas aus.

 

[Dukel]

Auch bei Oracle sind Named User natürliche Personen und keine Accounts.
Ein Benutzer braucht eine Lizenz, egal ob er sich mit einem Account oder 10 anmeldet.

 

[M303M]

Danke erstmal für eure ausführlichen Antworten.

Das habe ich nicht verstanden.

-> etwas viele "Benutzer" in einem Satz, sorry %)
Wie du dann beschrieben hast, besitze ich 3 Schemas und die "anderen User" (die ich über den SQL_Developer sehen kann) in der DB scheinen ebenfalls "nur" Schemas zu sein, keine nur für den Login verwendeten (menschlichen) Benutzer.

Auch bei Oracle sind Named User natürliche Personen und keine Accounts.
Ein Benutzer braucht eine Lizenz, egal ob er sich mit einem Account oder 10 anmeldet.

das heißt mit jedem User, den ich für den Login anlegen würde, würde eine Lizenz fällig werden ? Damit fiele diese Option aus, die Benutzer werden definitiv mehr werden im Laufe der Zeit.

Es ist mir klar, daß ich etwas spät dran bin mit der Userverwaltungs Überlegung, aber hilft jetzt nichts, da muß ich grad durch und das will ich es so sicher wie möglich machen, daher die "low level" Fragen.
Ich hab es mir relativ einfach vorgestellt und dachte daß ich das "along the way" schaffe, aber mir läuft die Zeit davon und jetzt, da ich soweit wäre mit verschiedenen menschlichen
Benutzern zu arbeiten, sehe ich die Probleme erst so richtig %)

Eine andere Idee war mir doch noch ein 4. Schema anlegen zu lassen, in dem nur eine Tabelle mit Benutzernamen, Passwörter und Rolle in einer einzelnen Tabelle angelegt ist (mit dem Modul "cryptography.fernet" verschlüsselte PW´s abgelegt).
Man sich also mit einem in der Anwendung (eine .exe) hinterlegten PW anmelden muß, aber in einem an sich leeren Schema, das nur eine Tabelle beinhaltet.
Den Schlüssel zum decodieren würde ich in eine sqlite3 DB verschlüsselt ablegen und mit der Anwendung ausrollen.
Wenn der menschliche Benutzer erkannt wird, geschieht jetzt der Login in das entsprechende Schema passend zur Rolle (Admin / User / ReadUser) mit den Login - Daten, die wieder verschlüsselt in der sqlite3 DB liegen.

Wäre das aus eurer Sicht ein gangbarer Weg ?

Active Directory wäre in der Firma wahrscheinlich eine Möglichkeit, aber die Implementierung schien mir auf die Kürze der Zeit (spätestens Winter ist Abgabetermin) ein "overkill" zu sein beim überfliegen.
Könnte das Login - Verfahren später auf Active Directory geändert werden können oder müsste ich das jetzt einbauen oder es wäre später nicht mehr möglich ?

 

[Dukel]

Bei Oracle (ähnlich bei SQL Server) kannst du nach CPU oder Anzahl der Nutzer lizenzieren. Bei letzterem musst du zählen, wer auf die DB zugreift, egal wieviele Accounts angelegt wurden.
Auch wenn immer der "User" genutzt wird, brauchst du die Anzahl der natürlichen Personen.
Das muss dir aber der DB Admin sagen, wie die DB lizenziert wurde.