berechtigungstabelle

[Antibiotik]

hallo zusammen,

in meinem programm muss ich ein berechtigunskonzept einbauen.

-> jeder user darf seine daten sehen

-> bestimmte user dürfen daten von bestimmten usern sehen.

wie realisiere ich des in meiner datenbank??

ich hab eine usertabelle.

dann würd ich eine zweite tabelle mit 3 feldern (ID, Personalnummer aus der usertabelle und nochmal personalnummer aus der usertabelle) anlegen und hier die berechtigungen pflegen!

ist mein ansatz richtig??

Ciao

Antibiotik

[sylvester]

Hi, ich weiß nicht was Du für eine DB benutzt und in welchem Kontext Deine User auf die Datenbank zugreifen. Ich würde die Zugriffsberechtigungen in den Programmcode auslagern und jedem Benutzer nur die jeweils entsprechenden Funktionen zur Verfügung stellen.

Alternative --> Grant Revoke Methode...so kannst Du, glaube ich, aber nur SQL Befehle sperren und nicht den Zugriff auf einzelne Tupel. Du müsstest jeden Benutzer im DBMS bekannt machen. Mit der oben beschriebenen Methode brauchst du nur einen Benutzer. Aber ich habe von DB Gurus schon gehört, dass man möglichst viele Funktionen in die DB auslagern soll.

Also waren nur n paar Gedanken...

Syl

[Jaraz]

Original geschrieben von Antibiotik

ist mein ansatz richtig??

Ja!

Wobei die id nicht notwendig ist.

Du hast sozusagen eine n:m Beziehung die du über eine Zusatztabelle auflöst. Besonderheit ist halt, das sich die n:m Relation nicht auf verschiedene Tabellen bezieht, sondern nur auf eine.

Gruß Jaraz

[hades]

Original geschrieben von sylvester

Ich würde die Zugriffsberechtigungen in den Programmcode auslagern und jedem Benutzer nur die jeweils entsprechenden Funktionen zur Verfügung stellen.

Besser ist es, nur die Funktionen im Programmcode zu haben und die User und deren Berechtigungen als Datensätze zu speichern.

Eine User-/Rechteverwaltung (inkl. Benutzergruppen und deren Rechte, userspezifisch entzogene Rechte bzw. hinzugefuegte Rechte) kann sehr komplex werden und wird oft in einer separaten DB gespeichert.

[just_me]

Das ist ein interessantes und sehr kontroverses Thema.

Hierzu wird in der Fachwelt ziehmlich heftig diskutiert, da die möglichen Ansätze ebenso vielfältig sind, wie die möglichen Ziele, die es zu erreichen gilt.

Im Wesentlichen gibt es zwei grundlegende Ansätze, die sich in Umsetzung und Aufwand gravierend unterscheiden.

Alternative I

-> Voraussetzung: Daten sind dynamischer Bestandteil der Software.

(Das ist gewöhnlich dann der Fall, wenn verschiedene Programme auf die gleichen Daten zugreifen oder zugreifen können.)

-> Lösung: Filtern der Daten auf der Ebene von Views.

+ Die Geschäftslogik "Datenfilter" bleibt dort, wo sie hingehört: Direkt bei den Daten.

+ Das Einpflegen neuer, das Löschen alter sowie das Ändern vorhandener User und deren Rechte erfolgt unabhängig von Software und Daten.

+ Es ist nicht notwendig komplexe Berechtigungssätze zu entwickeln, die zudem bereits bei geringfügigen Änderungen an der Datenstruktur massiv und unter hohem Aufwand korrigiert werden müssen.

Alternative II

-> Voraussetzung: Die Daten sind von der Software transitiv abhängig.

(Das ist gewöhnlich dann der Fall, wenn hochspezialisierte Software auf hochspezialisierte Daten zugreift. Beispiel: Ein Vermessungssystem legt Daten in aufbereiteter Form ab, um diese für ein vektororientiertes grafisches System, dessen Engine klar definierten Erfordernissen angepasst wurde, zur Verfügung zu stellen.)

Hier macht es keinen Sinn, die Daten von der SW zu trennen, da diese ohne sie ihre Existenzberechtigung verlieren.

-> Lösung a: Transparente semi-dynamische Bindung mittels einer Benutzerdatenbank (UDB)

+ Bei kleineren Systemen vermindern sie den Pflegeaufwand. (Sie wirken, entsprechend der umgesetzten BL, wie "dynamische Views")

+ UDB's gestatten die Nachbildung respektive Bildung von Zugriffsgruppen und ermöglichen eine weitgehend dynamische Pflege.

- Hoher Transaktionsaufwand, da die UDB permanent gepollt werden muss.

- Gewaltiger Kontrollaufwand, da jede einzelne Abfrage - insbesondere, wenn diese vom Anwender direkt eingegeben und/oder ausgewählt werden darf - zunächst die Sicherheitsebene durchlaufen muss.

- Die zusätzlich verursachten Transaktionen können, auch und gerade bei Remotesystemen, zu enormen Laufzeiten und Kosten führen.

-> Lösung b: starre Bindung zwischen Software und Daten

Wird häufig dann verwendet, wenn die Sicherheit höhere Priorität als die mögliche Personalfluktuation hat.

(Beispiel: Die Software zieht "personengebunden" Daten aus einer Datenbank - bspw. eine Analyse-SW für das Top-Management.)

+ Die Sicherheitsebene ist starr konstruiert und daher wenig anfällig gegen Störungen (bspw. Diebstahl oder Manipulation).

+ Im Gegensatz zu Alternative II Lösung a wird der Kontrollaufwand zu 100% in die Software verlagert, was Geschwindigkeitsvorteile und Verminderung von Roundtrips bringt.

- Bei Personalfluktuation kommt es zu Störungen im Betrieb und gelegentlich hohen Adaptionskosten, da die entsprechenden Änderungen fest codiert werden müssen.

------------------------

Ich habe hier lediglich einen absolut rudimentären Kern von Möglichkeiten umrissen (und selbst hier noch an der Schilderung der entsprechenden Vor~ und Nachteile gespart), um den Rahmen dieses Forums nicht zu sprengen. Trotzdem - oder besser: gerade deswegen - hoffe ich, dass die dargelegten Ansätze dabei nicht den Überblick missen lassen.

Wie ich oben bereits andeutete, ist diese Aufgabe Gegenstand ungezählter Fachtagungen, Artikel und Bücher. Es wäre also unmöglich, hier und jetzt das Problem von allen Seiten zu durchleuchten, und die entsprechend richtige Lösung aus dem Hut zu holen. Dies gilt insbesondere, da du doch recht sparsam mit deinen Informationen warst.

Wenn also Sicherheitsbelange und technische Umgebung es zulassen, sollte den entsprechenden Designpattern gefolgt werden. Nicht umsonst haben sich Experten für beinahe jeden Anwendungsfall entsprechende adaptive Muster einfallen lassen, wie was wann wo am Besten um- respektive durchzusetzen ist.