Datenbankanwendung mit Benutzerrechten... Wer kann helfen ?

[Killerloop]

Hallo !

Ich muss eine Dantenbankanwendung programmieren, bestehend aus Kunden-, Projekt- und Zeiterfassungsmodul.
Jetzt sollen verschiedene User auch verschiedene rechte haben, so soll benutzer A z.B. keine möglichkeit haben
ins kundenmodul zu schauen aber dafür seine Arbeitszeiten zu erfassen. bei benutzer B genau umgekehrt.

Nach welchem Schema würdet Ihro sowas machen ? Beim Programstart einen anmeldemaske, dann wird der angemeldete Benutzer und seine rechte in einer globalen variable gespeichtert solang die anwendung läuft, und dann ?

Meine einzige Idee wäre das immer wenn benutzer A auf den Button "Kundenstamm" klickt erstmal abgefrgt wird: Hat der benutzer das recht diesen zu sehen.. aber das ist ja total aufwändig wenn vor dem öffnen jedes fenster abgefragt wird ob das der aktuell
angemeldete benutzer auch darf... :-/

Hat jemand schonmal sowas oder was ähnliches gemacht und hat einen tip für mich ?

Danke

[Jelly]

Mit der Abfrage in deine Anwendung hast du noch kein Sicherheitsloch gestopft. Die Tabellensperre muss auf Datenbankebene erfolgen, vorausgesetzt du nutzt ein Datenbanksystem, welches das auch unterstützt. Von Firbird über MySQL, bis hin zu MSSQL oder Oracle bist du da aber auf der sicheren Seite.

Jedenfalls verpasst du deinen Datenbankaccounts entsprechende Rechte. Deine Leute müssen sich dann in die Datenbank einloggen, und erhalten automatisch nur Zugriff auf erlaubte Aktionen. In deinem Programm kannst du das dann noch zusätzlich abfangen, ist aber kein Muss.

[Killerloop]

Hm, naja aber wen ich das auf datenbank-ebene mache dann habe ich ja folgendes problem: der benutzer will einen neuen Kunden anlegen, ok, dialog kunden aanlegen öffnet sich. er gibt alle daten ein und wenn er dann auf Übernehmen klickt werden ja die daten in die datenbank eingefügt. wenn er jetzt dazu aber die rechte garnicht besitzt hat er ja alles umsonst eingetippt nur um dann zu erfahren das er keine rechte dazu hat. man sollte also diesn user garnicht erst in den dialog "kunden alegen" hereinlassen oder noch besser für bestimmte user bestimmt Menüs sperren. Ich glaub ich bin grad selber drauf gekommen...

wenn jemand trotzdem eine gute idee hat wie man sowas auf anwedungsebene und nicht auf der datenbankebene realisieren kann dann bin ich für alles offen...

[Bernhard Geyer]

Zitat von Jelly:

Mit der Abfrage in deine Anwendung hast du noch kein Sicherheitsloch gestopft. Die Tabellensperre muss auf Datenbankebene erfolgen, vorausgesetzt du nutzt ein Datenbanksystem, welches das auch unterstützt. Von Firbird über MySQL, bis hin zu MSSQL oder Oracle bist du da aber auf der sicheren Seite.

Dies bringt aber nur dann was, wenn Du festlegen kannst, das der User x die Tabellen a, b, c schreiben darf, den View x öffen darf und die Stored Procedure z ausführen darf.
Dies wird aber für 90% der Anwendungen nicht der Fall sein (z.B. der User X darf nur Kunden aus dem Gebiet X sehen bzw. bearbeiten oder nur Aufträge bis 10.000 EURO eingeben), so daß eine eigene Benutzer/Rechteverwaltung nötig ist.

[Marcel Gascoyne]

Zitat von Jelly:

Mit der Abfrage in deine Anwendung hast du noch kein Sicherheitsloch gestopft. Die Tabellensperre muss auf Datenbankebene erfolgen, vorausgesetzt du nutzt ein Datenbanksystem, welches das auch unterstützt. Von Firbird über MySQL, bis hin zu MSSQL oder Oracle bist du da aber auf der sicheren Seite.

Für eine klassische Client/Server Anwendung mag das zutreffen. Bei einer mehrschichtigen Anwendung oder auch einen Webinterface wird sich der Anwender in der Regel nicht direkt gegen die Datenbank identifizieren. Hier sollte dies dann auf Anwendungsebene passieren.

Ich mache das immer so:

• Kennwort für die Datenbank wird als verschlüsselter String in der Anwendung gespeichert und erst zur Laufzeit entschlüsselt, z.b. Blowfish Algorythmus). Der Key befindet sich ebenfalls in der Anwendung und sollte möglichst Sonderzeichen enthalten. Ist bei uns nicht sicherheitskritisch, da die Datenbankanbindung über einen Delphi SOAP Server stattfindet. Die Clients greifen nur über SOAP auf den Server zu.
• Benutzer werden in einer Tabelle gespeichert (ID,Benutzername,Kennwort,etc...)
• Für Benutzerrechte gibt es eine entsprechende Tabelle (Benutzer_ID,Mandant,Recht).
• Alle Funktionen der Anwendung sind als Aktionen (TAktion) definiert und es muss nur die Eigenschaft Enabled entsprechend gesetzt werden, dies mache ich gleich nach der Anmeldung.

Gruß,
Marcel

[Jelly]

Zitat von Bernhard Geyer:

Dies wird aber für 90% der Anwendungen nicht der Fall sein (z.B. der User X darf nur Kunden aus dem Gebiet X sehen bzw. bearbeiten oder nur Aufträge bis 10.000 EURO eingeben), so daß eine eigene Benutzer/Rechteverwaltung nötig ist.

Da geb ich dir Recht. So Sachen kann man auf Clientseite lösen, muss man aber trotzdem nicht. Geschickt wäre es, eine Stored Procedure aufzurufen, welche die Daten in die Tabelle einfügt. In der Stored Procedure kannst du dann auch noch sämtliche Bedingung treffen (Aufträge bis 10.000e etc.) und gegebenfalls das Einfügen blockieren.

@Marcel: Dein vorschlag ist wohl der Einfachste, wenn man nicht absolute Sicherheit in der Datenbank anstrebt. Bei kritischen Daten (z.B. Personendaten mit Lohninformationen) ist dies jedoch nicht der beste Weg. So wie du es beschreibst nutze ich es selbst in einem Projekt (Rema, auch hier im Forum schon mal durchdiskutiert worden), aber eigentlich nur, weil ich MySQL als Server nutze, und aber auch aus Bequemlichkeit.

Prinzipiell gilt immer, wenn es wirklich um sensible Daten geht, sollte man die Sicherheit einem Datenbankserver überlassen. Ist aber nur meine Meinung.

[Stevie]

Moin,

ich finde, der beste Weg ist, GUI- und DB-Sicherheiten zu verknüpfen!
Mit seinem DB-Account meldet sich der Benutzer am Programm an.
In zusätzlichen Tabellen sind die Sicherheiten für die GUI gespeichert
(welche Menüpunkte darf er sehen/auswählen, sind Datenmengen/Eingabemasken ReadOnly usw.)
Diese werden beim Start überprüft und umgesetzt. Somit kann innerhalb der Software
kein Bereich betreten werden, wo man nicht hindarf und zusätzlich können Daten nicht
über eine andere Schnittstelle abgerufen/manipuliert werden.

MfG
Stevie

[Jelly]

Zitat von Stevie:

Diese werden beim Start überprüft und umgesetzt. Somit kann innerhalb der Software kein Bereich betreten werden, wo man nicht hindarf und zusätzlich können Daten nicht über eine andere Schnittstelle abgerufen/manipuliert werden.

Ganz deiner Meinung. Die GUI soll die Funktionen gleich blocken. Die eigentliche Sicherheit liegt jedoch auf dem Server.

[Bernhard Geyer]

Zitat von Jelly:

Geschickt wäre es, eine Stored Procedure aufzurufen, welche die Daten in die Tabelle einfügt. In der Stored Procedure kannst du dann auch noch sämtliche Bedingung treffen (Aufträge bis 10.000e etc.) und gegebenfalls das Einfügen blockieren.

Wäre eine von vielen Möglichkeiten. Hat aber auch Nachteile, wenn man diverse DBMS unterstützen will, da man für jede DB eine SP programieren (und entwanzen) muss.

Alternativen wäre z.B. auch 3-Tier-Architektur mit Rechteverwaltung auf Businness-Schicht.