Benutzerverwaltung Client-Server Datenbank

[jobo]

Zitat:

Zitat von elmar.faber (Beitrag 1334690)

wie erreiche ich es, dass ein bestimmter Benutzer nur ganz
bestimmte Rechte bekommt?

Das ginge nur, wenn Du dem Benutzer in der geöffneten Session diese Rechte erteilst, also so, wie ich es oben mit der Rolle vorgeschlagen habe.

Zitat:

Zitat von elmar.faber (Beitrag 1334690)

Ich müßte doch hierzu die Verbindung trennen und mit einem Benutzer mit anderen Rechten
wieder neu aufbauen.

Nein, nicht unbedingt. Schau Dir mal die Möglichkeiten an, die die role grants bieten.

Zitat:

Zitat von elmar.faber (Beitrag 1334690)

Wie steuere ich die Rechte für viele Anwender mit nur einem angelegten DB-Benutzer?

Über wechselnde Rollen oder gar nicht, soweit mir bekannt.

Zitat:

Zitat von elmar.faber (Beitrag 1334690)

Und verhindere gleichzeitig, dass nie Daten das Backend verlassen, zu denen der Anwender keine Rechte besitzt?

Wenn Du es so machst, wie es üblich ist (Mehrschichtanwendung) nur durch Sorgfalt.
Alternativ baust Du wie vorgeschlagen eine eigene, anwendungsinterne Zwischenschicht, die anhand logisch zugewiesener Rollen für den jeweiligen User die Zugriffe auf die DB prüft und erlaubt oder verbietet.

[p80286]

Ich sehe die "one User fits all"-Lösung sehr kritisch.
Sobald die Möglichkeit besteht, daß jemand sich die Zugangsdaten des DB-Users besorgt, der dann auch noch Owner ist, dann kann man die Zugangsdaten auch gleich ans schwarze Brett pinnen.

Jeder User der Zugriff auf eine DB hat, sollte nicht mehr Rechte/Möglichkeiten haben als unbedingt nötig.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1334724)

Ich sehe die "one User fits all"-Lösung sehr kritisch.
..ans schwarze Brett pinnen.
..nicht mehr Rechte/Möglichkeiten haben als unbedingt nötig.

Ja, das ist letztlich wohl der wichtigste Punkt. In der klassischen Zwischenschicht dringt ja kein User soweit vor.

Ich habe auch selbst noch mal nach der set role Funktion geschaut, aber da findet man nichts bzw. nichts sinnvolles, was so etwas abbildet.
Es ist allerdings schon so, dass man unter einem SQL Server standardmäßig verschiedene DB liegen hat und ansprechen kann, wenn die Rechte passen. Also könntest Du mit dem Owner sicher auch das Recht bekommen, auf dieser DB und nur darauf User anzulegen und zu löschen, wahlweise als Domaine User oder SQL Variante.

[elmar.faber]

Vielen Dank für die vielen Anregungen, ich denke es kristallisiert sich die Lösung der Zwischenschicht
heraus, so wie befürchtet, was allerdings bei max. 80 Benutzern meiner Meinung nach den Aufwand gegenüber
dem Nutzen deutlich sprengt. Da wäre doch eine eigene Instanz im Cluster deutlich sinnvoller.
Ich finde auch, wie hier mehrfach angesprochen wurde, eine Lösung mit einem Benutzer der dazu noch owner
sein müßte bzw. zu hohe Rechte benötigt, viel zu kritisch in Punkto Sicherheit. Um aber Rollen anzupassen
brauche ich nunmal gewisse Rechte. Ausserdem wüßte ich nicht, wie ich in einer laufenden Session Benutzerrechte
anpassen könnte - würde dann nicht der nächste Benutzer auch diese Rechte erst einmal haben und wieder verändern?
Hat von euch schon mal jemand ein Projekt mit einer Zwischenschicht umgesetzt oder Informationen wie man sowas
umsetzen könnte (Gibt es vielleicht irgendwo ein einfaches Beispiel um mal die prinzipielle Vorgehensweise zu sehen?

Viele Grüße

[jobo]

Zitat:

Zitat von elmar.faber (Beitrag 1334745)

Um aber Rollen anzupassen
brauche ich nunmal gewisse Rechte. Ausserdem wüßte ich nicht, wie ich in einer laufenden Session Benutzerrechte
anpassen könnte

Nochmal zum Sortieren:
Die Rollengeschichte, die ich ins Spiel gebracht habe, geht nicht unter MS SQL. Zumindest nicht so, wie ich dachte. Ich dachte die hätten da was von Oracle übernommen. In Oracle ist es nur ein SQL Befehl, der auf die entsprechend vordefinierte(n) Rolle(n) umschaltet.
Zwischenschicht: Wenn Du sie clientseitig implementierst, ändert es nichts daran, dass die DB mit einem zentralen User für alle da steht. Klassisch ist eine Zwischenschicht serverseitig angelegt und hat als einzige physikalisch Zugriff auf die DB.
"Instanz": Ich weiß nicht, ob wir da nur Begriffsprobleme haben, aber eine eigene Instanz sollte nicht notwendig sein. Das sollte doch gehen mit SQL Server, vielleicht kann das jemand bestätigen:
Nur eine eigene DB. Eine eigene DB sollte administrativ autark zu verwalten sein. Ein entsprechender User darf nur dort weitere User anlegen und löschen, Rollen dürften ebenfalls nur mit Berechtigungen für Tabellen dieser DB angelegt und vergeben werden.
Und noch als Idee: Wenn für das Anlegen und Löschen eine eigenständige SP gebaut wird, die nur selbst angelegte User auch wieder löschen kann und der User, der diese SP administrativ nutzt, selbst keine anlegen darf, könnte man auch mit dem bestehenden System klarkommen.

[Lemmy]

Zitat:

Zitat von elmar.faber (Beitrag 1334745)

Vielen Dank für die vielen Anregungen, ich denke es kristallisiert sich die Lösung der Zwischenschicht
heraus, so wie befürchtet, was allerdings bei max. 80 Benutzern meiner Meinung nach den Aufwand gegenüber
dem Nutzen deutlich sprengt.

vielleicht verrennst Du dich da gerade in irgend welchen monströsen Dingen...

Zitat:

Zitat von elmar.faber (Beitrag 1334745)

Ich finde auch, wie hier mehrfach angesprochen wurde, eine Lösung mit einem Benutzer der dazu noch owner
sein müßte bzw. zu hohe Rechte benötigt, viel zu kritisch in Punkto Sicherheit.

Ich habe jetzt nicht jeden Beitrag gelesen, meine aber, dass das so explizit nirgends stand. Es geht darum, dass Du einen Benutzer für die Datenbankzugriffe verwendest, das muss nicht der Owner sein (und um es anders zu sagen: Es sollte nicht der DB Owner sein). D.h. du müsstest in der MSSQl-Instanz lediglich 2 User anlegen, keine 80 (was die Coexistenz mit anderen Datenbankanwendungen deutlich erleichtert, außer jeder nimmt die beiden selben User: DBUser und DBAdmin :-). Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)


Und jetzt nochmal zur Zwischenschicht:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist) wäre der Einsatz eines ORM - und genau hier hättest Du dann die Chance ein Zugriffsmanagement recht einfach zu implementieren - nämlich, darf der gerade angemeldete Nutzer der Software diese Daten abrufen / anzeigen / ändern oder eben nicht. Hat aber nix mit dem DBUser zu tun.

Und um das dann noch eine Stufe höher aufzuhängen: Restserver: Der liefert dir die Daten und würde sich auch um die Berechtigung kümmern, was ein bestimmter Nutzer (oder besser seine zugewiesene Gruppenberechtigung) darf und was nicht. Und um den Punkt auch noch abzudecken: Wenn Du für deinen Restserver (solltest Du jemals einen implementieren) auch Anmeldemöglichkeiten für google+, Facebook,... anbieten, hättest Du hier auch keine unterschiedlichen Datenbankuser sondern eben nur "einen", dafür aber eine eigene auf der Anwendungsseite (=Restserver) liegende Rechteverwaltung.

[Fishermans]

Zitat:

vielleicht verrennst Du dich da gerade in irgend welchen monströsen Dingen...

Ja das stimmt wohl, das Gefühl hab ich auch... Ich habe nun so viele Gespräche und Diskussionen geführt, dass ich nicht mehr so recht weiß, wie ich weiter vorgehen soll.

Zitat:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist)

Ist das wirklich als Zwischenschicht zu rechnen? Dann sind doch die Daten schon auf dem Frontend. Das will ich ja vermeiden. Ich habe mich auch unglücklich ausgedrückt, ich habe zwar 80 Benutzer aber maximal 30 Anmeldungen (Schichtdienst).

Zitat:

außer jeder nimmt die beiden selben User: DBUser und DBAdmin . Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)

Das höre ich gerne :) das war eines meiner Vorschläge für einige Rollen "Rollen-Benutzer" anzulegen.

Zitat:

Und um das dann noch eine Stufe höher aufzuhängen: Restserver: Der liefert dir die Daten und würde sich auch um die Berechtigung kümmern, was ein bestimmter Nutzer (oder besser seine zugewiesene Gruppenberechtigung) darf und was nicht. Und um den Punkt auch noch abzudecken: Wenn Du für deinen Restserver (solltest Du jemals einen implementieren) auch Anmeldemöglichkeiten für google+, Facebook,... anbieten, hättest Du hier auch keine unterschiedlichen Datenbankuser sondern eben nur "einen", dafür aber eine eigene auf der Anwendungsseite (=Restserver) liegende Rechteverwaltung.

Das wäre dann genau das was ich brauche, das Problem ist die Einarbeitung in die Thematik und die Umsetzung. Das Projekt ist noch lange nicht abgeschlossen und ständige Veränderungen an der Datenbankstruktur sind notwendig, das wird dann viel komplizierter. Ist "DataSnap" auch für eine Benutzerverwaltung in der Zwischenschicht geeignet? Ich habe dazu kaum Informationen gefunden.
Ich denke, ich sollte mich mit dem spannenden Thema Restserver / DataSnap beschäftigen... das Problem wird sein, die richtigen Informationen zu finden, die Beschreibungen sind ja eher sehr ernüchternd dünn im Netz gesät... Vielleicht gibt es ja dazu auch den ein oder anderen Tipp...:-D:-D:-D

[Lemmy]

Zitat:

Zitat von Fishermans (Beitrag 1334835)

Zitat:

Eine Zwischenschicht hast Du eh: Zumindest Datenbankzugriffskomponenten, besser (bei 80 Anwendern auf einer DB würde ich sogar davon ausgehen, dass das Pflicht ist)

Ist das wirklich als Zwischenschicht zu rechnen? Dann sind doch die Daten schon auf dem Frontend. Das will ich ja vermeiden. Ich habe mich auch unglücklich ausgedrückt, ich habe zwar 80 Benutzer aber maximal 30 Anmeldungen (Schichtdienst).

Nach meiner Meinung ja, nur bringt dir die wenig. Ein gekapseltes ORM ist hier deutlich mächtiger (wie ich das Wort hasse) und flexibler. Die 80 Benutzer habe ich jetzt als "Maßstab" genommen, dass es nicht nur eine ToDo-Liste wird. Wenn Du bei Delphi bleibst, schau dir mal 1-2 Tage tiopf an, etwas steile Lernkurve, aber dann kann man gut damit arbeiten.

Zitat:

außer jeder nimmt die beiden selben User: DBUser und DBAdmin . Der Owner macht Backups, DDL Updates,..., der "einfache" Benutzer dann DML (Insert, Select, Update, Delete). Sollten Fremdsysteme auch Zugriff auf die Daten erhalten wäre ggf. noch ein dritter DBUser notwendig mit entsprechend wengier Rechten (z.B. nur Zugriff auf bestimmte Views)

Das höre ich gerne :) das war eines meiner Vorschläge für einige Rollen "Rollen-Benutzer" anzulegen.

Zitat:

Zitat von Fishermans (Beitrag 1334835)

Das wäre dann genau das was ich brauche, das Problem ist die Einarbeitung in die Thematik und die Umsetzung. Das Projekt ist noch lange nicht abgeschlossen und ständige Veränderungen an der Datenbankstruktur sind notwendig, das wird dann viel komplizierter. Ist "DataSnap" auch für eine Benutzerverwaltung in der Zwischenschicht geeignet? Ich habe dazu kaum Informationen gefunden.

wenn ich das auf die schnelle richtig verstehe dann ja. Aber das über einen Appserver/Restserver zu lösen da bedarf es dann schon etwas mehr Anforderungen als eine einfach CRUD-Anwendung.