Benutzerverwaltung Client-Server Datenbank

[elmar.faber]

Hallo,

ich suche Konzepte zum Aufbau einer Client-Server Benutzerverwaltung - vornehmlich MS-SQL, doch sollte das Konzept ja durchaud übertragbar sein.
Erst einmal sehe ich zwei unterschiedliche Möglichkeiten:

1. Die Benutzerverwaltung verwendet die Datenbankfunktionalitäten, Benutzer anlegen, Rollen vergeben etc.
- Vorteil: Funktioniert und ist durch verwenden von Views sehr sicher, kein Benutzer hat direkten Zugriff auf die Tabellen
- Nachteil: eine eigene Instanz ist notwendig mit rechten die das alles ermöglichen.

2. Eine eigene Benutzerverwaltung mittels einer Tabelle die die Zugangsdaten und Rollen der einzelnen Benutzer enthält
- Vorteil: keine eigene Instanz nötig, es wird nur ein Benutzer benötigt
- Nachteil, ich hab keine Ahnung wie ich das am besten umsetzen soll.

Zum besseren Verständnis:

Die aktuelle Situation ist folgende: Ich habe eine Delphi Applikation die im Domänen-Netzwerk läuft und auf einen MS-SQL Server
via FireDAC Komponenten zugreift. Die Benutzer die sich an der Applikation anmelden werden als Datenbank-Benutzer auf dem Server
eingetragen und über Rollen bekommen sie die Rechte innerhalb der Datenbank zugewiesen. Bei 50 Benutzern muß ich 50 Benutzer-Einträge
in die Datenbank machen und benötige dazu höhere Rechte zur Verwaltung auf dem SQL Server.
Im MS-SQL Cluster bräuchte ich nun eine eigene Instanz dafür ansonsten könnte ich auch Benutzer anderer Datenbanken löschen.
Das will der Systembetrieb nicht.
Wenn ich nun eine Tabelle nehme und dort meine Anwenderdaten ablege, bräuchte ich nur einen Benutzer der das Recht hat lesend und schreibend
auf die Datenbank zuzugreifen, müsste aber die Zugriffsverwaltung irgendwie innerhalb meiner Datenbank organisieren.
Da fehlt mir aber die zündende Idee, bzw. ich weiß nicht, ob das überhaupt funktionieren kann.
Es steht die Delphi XE7 Enterprise Version zur Verfügung.

zu 2: Wenn ich mit FDConnection eine Verbindung aufbaue mit einem Benutzer der lediglich das Recht hat eine Stored-Procedure
aufzurufen mit der ich auf die Tabelle mit den Benutzerdaten zugreifen kann, könnte ich ja die Benutzerdaten überprüfen
aber wie geht es weiter? Ich habe doch lediglich die Rechte zur Verfügung die der einzelne Benutzer hat - somit hilft mir
das ja nicht weiter? Wie kann ich im Backend (in meiner Datenbank) eine Verwaltung aufbauen die nur einen Benutzer benötigt?

Gibt es noch andere Verfahren und kennt von euch jemand Links die mir da auf die Sprünge helfen?

Ich hoffe auf eine angeregte Diskussion

Viele Grüße

Crossposting: http://forum.delphi-treff.de/index.p...105#post445106

[jobo]

Was ist denn so schlimm an einer 2. Instanz. Kostet das? Oder geht es um den Ressourcenverbrauch?
Eine eigene Welt hätte den Vorteil, dass es nie Streß gibt, wenn irgendwo was schief läuft und die IT sagt, sie haben da doch vorgestern was eingespielt...
Ansonsten bin ich nicht so bewandert mit dem MSSQL Benutzerkonzept, aber es gibt doch dort nicht nur Instanzen, sondern auch ganz normale Datenbanken. Bieten die nicht schon einen eigenständigen Rechtekontext? Dann kannst Du eine eigene DB nehmen und dort das gleiche machen wie in einer eigenen Instanz, ohne das Du auf die anderen Systeme kannst.

Nur ein User für den Zugriff, das wird ja eigentlich bei fast jeder Webanwendung so gemacht. Die haben dann für sich ein Userkonzept mit eigenen Usertabelle, PW Verwaltung usw.. Sollte also im Zweifel auch möglich sein.

In Oracle mache ich Rollenzuweisung beim Login. Ein User, der nichts darf, bekommt unter gewissen umständen beim Login eine Rolle zugewiesen. Das ist Dbseitig wiederum mit Priviliges und PW verbunden, könnte mir aber vorstellen, dass es sowas ähnliches auch in MSSQL gibt. Die schauen sich ja eh immer untereinander alles ab.

[elmar.faber]

Ja das habe ich auch gefragt, aber da geht es wohl um Prinzipien, dann kommen am ende noch andere und wollen auch...

Ja wie könnte man das wie bei einer Webanwendung umsetzen? Das wäre genau das, was ich gerne ausprobieren würde...

[mquadrat]

Üblicherweise nimmt man 2.) und sorgt in der Zwischenschicht dafür, dass keine Statements gegen die DB ausgeführt werden, die im aktuellen Nutzerkontext nicht zulässig sind. Der DB-Benutzer darf meist alles.

[elmar.faber]

Aber eine Zwischenschicht gibt es doch in meinem Fall nicht - oder hab ich da was mißverstanden?

[mkinzler]

Die "Zwischenschicht" kann auch in Deinem Programm implementiert werden. Die Benutzer müssen dann nicht als Datenbankbenutzer angelegt werden, sondern Dein Programm enscheidet anhand des Benutzers (des Programmes) was dieser darf.

[elmar.faber]

Dann hätte ich aber keine saubere Trennung von Frontend und Backend mehr da ja prinzipiell
alle Daten ins Frontend gelangen und erst da gefiltert wird

[mkinzler]

Jein. Wenn die Rechte fehlen kannst Du ja verhindern, dass die Daten geladen werden.

[elmar.faber]

Ja genau da liegt mein Verständnisproblem, ich baue eine Verbindung zur Datenbank auf und die Rechte
sind fest über einen Benutzer definiert, wie erreiche ich es, dass ein bestimmter Benutzer nur ganz
bestimmte Rechte bekommt? Ich müßte doch hierzu die Verbindung trennen und mit einem Benutzer mit anderen Rechten
wieder neu aufbauen. Wie steuere ich die Rechte für viele Anwender mit nur einem angelegten DB-Benutzer?
Und verhindere gleichzeitig, dass nie Daten das Backend verlassen, zu denen der Anwender keine Rechte besitzt?

[mkinzler]

Die Frage ist ja, ob man das über Datenbankbenutzer regeln muss, oder durch eine Benutzerverwaltung im Programm.

[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.