Sicherheit für Datenbankclient

[bundy]

Hi !

Ich arbeite momentan an einem Kundenverwaltungssystem, welches Modems Email´s Accounting...uvm verwaltet.
Ich verwände Orcale 9i als Datenbank dahinter. Der Zugriff erfolgt mittels RemObject & Dataabstract.

Client ----- Middelware------Database

Nun meine Frage zur Sicherheit.

Das Programm besitzt über einen Userloggin ,je nach Berechtigung kann der User gewisse sachen machen, oder auch nicht.

Da ich in einem anderen Thread schon mal gefragt habe über die Sicherheit von Visible oder Enable von Komponenten, und dieses als unsicher eingestuft worden ist, hab ich mir folgendes überlegt.

Wenn jemand einen Knopf drückt am Client z.B.

Delphi-Quellcode:

procedure Button1Click ....
begin

//machwas

end;

dann könnte ich doch in der DB einen Table anlegen, wo ich solche Proceduren aufnehme z.b

|ID|Name|
1|Button1Click

und diese mit dem Benutzertable verlinke.

Allso wenn jetzt ein User diese Procedure auslöst, eine Anfrage am Server mache, ob er sie auslösen darf.
z.b
UserID:Integer;
ProcedureID:integer;
checkUserPermission(UserID,ProcedureID):boolean

Ich würde dann zum Server UserID und ProcedureID senden und einen Rückgabewert mit false oder true erhalten.

Denke ich da richtig ? oder ist das auch ein Risiko?
Weil UserID und ProcedureID könnte man ja auch manipulieren oder?

Was würdet Ihr da Vorschlagen

lg
Bundy

[marabu]

Guten Morgen, Bundy.

Um eine möglichst hohe funktionale Sicherheit einer DB-Anwendung zu erreichen werden oft detaillierte Rechte an jeden User vergeben. Das Problem mit dem GUI-Client ist, dass zu keinem Zeitpunkt Aktionen angestoßen werden sollen, die im aktuellen Benutzerprofil unzulässig sind. Das Deaktivieren von UI-Controls erfüllt die Erwartungshaltung des Benutzers und die Berechtigungen im RDBMS garantieren die Sicherheit. Da eine zu enge Verzahnung von Client und RDBMS im Bereich der Rechte weder praktikabel noch wünschenswert ist, wurden von vielen Herstellern application roles eingeführt.

Die Rechte werden nicht mehr an den User, sondern an die Role gebunden. Dem User werden keine Rechte auf Datenobjekte mehr eingeräumt, sondern nur noch das Recht eine bestimmte Rolle einzunehmen. Das auf der Rolle basierende Benutzerprofil wird im UI Mangement Code der Anwendung nachgebildet. Der Vorteil dieses Ansatzes ist ein Höchstmaß an Sicherheit und Bedienungskomfort. Der Nachteil ist, dass eine neue Rolle Änderungen am Quelltext nötig macht. Ich halte diesen Nachteil nicht für gravierend, da der Nachführungsaufwand auf der Anwendungsseite eher klein ist, wenn man ihn mit dem konzeptionellen Aufwand vergleicht.

Die von dir vorgestellten Tabellen - hier und in deinem anderen thread - halte ich nicht für produktiv. Ich setze da eher auf zentrales Action-Management.

Grüße vom marabu