it-swarm.com.de

Wie entwerfe ich eine rollenbasierte Zugriffskontrolle?

Ich versuche, dem Rollenbasis-Zugriffssteuerungsmodell zu folgen, um einzuschränken, was Benutzer in meinem System tun können oder nicht.

Bisher habe ich folgende Entitäten:

Benutzer - Personen, die das System verwenden. Hier habe ich Benutzernamen und Passwörter. Rollen - Sammlung von Rollen, die Benutzer haben können. Dinge wie Manager, Administrator usw. Ressourcen - Dinge, die Benutzer manipulieren können. Wie Verträge, Benutzer, Vertragsentwürfe usw. Operationen - Dinge, die Benutzer mit den Ressourcen tun können. Wie erstellen, lesen, aktualisieren oder löschen.

Nun, mein Zweifel steigt hier im Diagramm auf, wo ich eine Beziehung wie diese habe:

Operationen (0 .. *) werden ausgeführt auf Ressourcen (0 .. *) welche generiert eine Tabelle, die ich Berechtigungen aufgerufen habe und in der die Operation und die Ressource gespeichert werden.

Die Berechtigungstabelle sieht folgendermaßen aus (eine Zeile davon): ID: 1, Operation: create, resource: contract.

Was bedeutet, dass ein Erlaubnis zu erstellen ein Vertrag.

Ich habe es so gemacht, weil ich der Meinung bin, dass einige Ressourcen möglicherweise nicht alle Arten von Operationen haben. Zum Registrieren von Verträgen können Benutzer beispielsweise Dateien hochladen, aber diese Operation ist nicht zum Registrieren eines Anbieters verfügbar .

Wenn der Administrator nun Berechtigungen für eine Rolle erteilt, verfügt er nicht über eine Ressourcenliste für jede einzelne im System registrierte Operation.

Ich denke, jede Ressource hat ihre eigene Sammlung von Operationen, die auf ihn ausgeführt werden können.

Ich kann klären, ob etwas nicht verständlich ist.

Ist dies der richtige Weg, um den rbac zu implementieren?

EDIT

Was ich damit meine ist, dass ich mit einer Berechtigungen Tabelle, die Operation und Ressource hat, ZWEI zusätzliche Tabellen habe, weil ich --- zuordnen möchte Ressourcen mit Operationen. Ich hätte es auch einfach tun können Ressourcen haben Berechtigungen wo die Berechtigungstabelle die Berechtigungen speichern würde.

Dann wäre jedoch passiert, dass einige Berechtigungen, die für einige Ressourcen nicht einmal vorhanden sind, angezeigt worden wären, wenn der Administrator sie zugewiesen hätte.

Ich möchte also aus Sicht des Datenbankdesigns wissen, ob diese Tabellenberechtigung mit einer Spaltenoperation und einer anderen Ressource korrekt ist. Werde ich auf Probleme stoßen, wenn es so bleibt?

15
imran.razak

Ihr Design scheint mir ziemlich nahe zu sein. Nur ein paar Vorschläge.

benutzer - Personen, die das System verwenden. Hier habe ich Benutzernamen und Passwörter.

Fein

rollen - Sammlung von Rollen, die Benutzer haben können. Sachen wie Manager, Admin usw.

Auch gut. Sie benötigen jedoch auch eine Entität/Tabelle "UserRoles", aus der hervorgeht, welche Benutzer welche Rollen haben. Es ist wahrscheinlich, dass ein bestimmter Benutzer zwei oder mehr Rollen hat.

ressourcen - Dinge, die Benutzer manipulieren können. Wie Verträge, Benutzer, Vertragsentwürfe usw.

Könnte nur eine Frage der Semantik sein. Ich glaube nicht, dass Benutzer Ressourcen direkt manipulieren. Rollen tun. So geht es Benutzer -> Benutzerrolle -> Rolle -> Operation -> Ressource

operationen - Dinge, die Benutzer mit den Ressourcen tun können. Wie erstellen, lesen, aktualisieren oder löschen.

ja, außer "Rollen" anstelle von "Benutzern"

Die Berechtigungstabelle sieht folgendermaßen aus (eine Zeile davon): ID: 1, Operation: Erstellen, Ressource: Vertrag. Was bedeutet, eine Erlaubnis, einen Vertrag zu erstellen.

Hmmm. Hierfür gibt es zwei Möglichkeiten. Sie könnten die Berechtigungstabelle haben, die Sie beschreiben, aber Sie würden auch eine zusätzliche RolePermissions Tabelle/Entität benötigen, die Ihnen sagt, welche Rolle welche Berechtigung hat. Aber ich bin mir nicht sicher, ob das notwendig ist.

Eine einfachere Möglichkeit hierfür ist eine Berechtigungstabelle/-entität mit den folgenden Spalten/Attributen: Rollen-ID, Operations-ID, ResourceID. Auf diese Weise werden Operationen x Ressourcenkombinationen direkt einer Rolle zugewiesen und nicht in eine Berechtigung geladen, die einer Rolle zugewiesen ist. Es wird eine Entität eliminiert. Es ist wirklich keine separate rollenunabhängige Berechtigungstabelle erforderlich, es sei denn, Sie möchten vordefinieren, welche Berechtigungskombinationen zulässig sind und welche nicht.

11
John Wu

Ich würde RBAC nicht verwenden oder implementieren. Stattdessen würde ich ABAC verwenden. Lassen Sie mich erklären...

  • Bei RBAC oder rollenbasierter Zugriffssteuerung geht es um Benutzerverwaltung und Rollenzuweisung. In RBAC kann man sagen, dass Alice eine Managerin ist. Sie können dazu statische Berechtigungen definieren. Zum Beispiel kann ein Manager Kredite genehmigen. Es gibt also einen Link von Alice zum Manager, um Loan als Erlaubnis zu genehmigen. Es gibt viele Systeme, mit denen Sie dies tun können, sodass Sie keine eigenen Tabellen implementieren müssen. Sogar LDAP unterstützt begrenzte Mengen von RBAC. Das ist in Ordnung, solange Sie nur relativ wenige Rollen und Berechtigungen haben. Aber was ist, wenn Sie bestimmte Berechtigungen berücksichtigen möchten, wie dies in Ihrem Fall der Fall ist? Anzeigen, löschen, einfügen? Was ist, wenn Sie Beziehungen berücksichtigen möchten?
  • Bei der ABAC- oder attributbasierten Zugriffskontrolle geht es um richtliniengesteuerte, differenzierte Autorisierung. Mit ABAC können Sie Rollen wie in RBAC definiert verwenden und Richtlinien schreiben, z. B.
    • Manager können Dokumente in ihrer Abteilung anzeigen
    • Mitarbeiter können Dokumente bearbeiten, die sie besitzen

In Ihrer Frage haben Sie im Wesentlichen das Informationsmodell definiert. Ihre Objekte und ihre Attribute, z. ein Benutzer (Name, Passwort, Abteilung ...); ein Objekt (z. B. ein Vertrag) und so weiter.

(Information model

In ABAC würden Sie daher Ihren App-Code/Ihre App-Logik vollständig von der Autorisierungslogik entkoppeln, die dann mithilfe von Attributen als Richtlinien gespeichert wird. Die Berechtigungen selbst werden direkt in der Richtlinie gespeichert (siehe Beispiel oben). Die ABAC-Bereitstellungsarchitektur sieht wie folgt aus

(Attribute Based Access Control Architecture

Der Punkt ist, dass Sie, wenn Sie einen ABAC-Ansatz wählen, Richtlinien für ABAC schreiben (entweder in XACML oder ALFA - dafür gibt es viele Tools) und Sie RBAC oder Zugriffskontrolle nie wieder benutzerdefinieren oder benutzerdefinieren müssen.

13
David Brossard