Diskussion:Role Based Access Control

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Wechselnde Rollen eines Benutzers?[Quelltext bearbeiten]

Wie ist das wenn nun ein Systemadministrator nun die Aufgabe Beschwerdenbehandlung erledigt. Er hat haber verschiedene Rollen und somit Berechtigungen. Mit der Rolle Beschwerdenbehandlung muss er nicht die selben Berechtigungen haben wie als Systemadministrator. Arbeitet er jetzt in der Rolle des Beschwerdebehandlers auch mit den Rechten des Systemadministrators oder wird er weiterhin mit verschiedenen Accounts arbeiten. Vielfach hat ein Systemadministrator 2 unterschiedliche Accounts (1 Useraccount und 1 Administratorenaccount) damit er nicht plötzlich in der Tagesarbeit mit zuviel Berechtigung unabsichtlich etwas verbiegt. Wie wird das gelöst mit RBAC (Vorstehender nicht signierter Beitrag stammt von 83.76.190.139 (DiskussionBeiträge). 08:09, 27. Okt 2005)

Antwort: Separation of Duty: Das Problem mit dem Systemadministrator und seinen zwei Accounts kann relativ leicht mit einem Konzept gelöst werden, dass im RBAC Standard (aber nicht nur dort) als Separation of Duty bezeichnet wird. So könnte es beispielsweise zwei Rollen geben: Administrator und Standardbenutzer. Entweder, man sorgt dafür, dass diese beiden Rollen nicht ein und demselben Benutzer zugewiesen werden können - das nennt man dann auch Static Separation of Duty. Damit wäre aber das Problem des vorsichtigen Admins nicht gelöst. Die Lösung nennt man Dynamic Separation of Duty. Dabei kann ein Benutzer zwar beide Rollen innehaben, aber nur eine von beiden zu einem bestimmten Zeitpunkt bzw. in einer Session aktivieren. Auf diese Weise erhält der Administrator zwei völlig unterschiedliche Rechte-Sets, die seine Sorge um aus Versehen durchgeführte Aktionen beseitigen, es aber unnötig machen, zwei getrennte Accounts für ein und denselben Benutzer anzulegen. -- Alexander Serbe 21:42, 22. Nov. 2009 (CET)[Beantworten]

Trennung von Rechten[Quelltext bearbeiten]

Kommt auf die Art der Beschwerde an. ;) Beschwert sich ein Webserver-User, schlüpft jemand (muss nicht der Admin himself sein) in die Rolle 'Beschwerdebehandlung_Webserver' und erhält damit ein Bündel an Rechten, die ihm ermöglichen, die Beschwerde zu behandeln. Er darf aber zugleich nicht zum Beispiel Laufwerke ein- und aushängen. Bei manchen (meisten?) RBAC-Lösungen sind Rollen und User getrennt. Der User Admin kann in die Rolle Webadmin oder Mailadmin schlüpfen und erhält immer pasenden Zugriff - nicht mehr und nicht weniger. Der Unterschied zwischen Rollen und Gruppen ist der, dass Gruppen die Rechte immer erweitern, während Rollen diese auch einschränken können. (Vorstehender nicht signierter Beitrag stammt von 62.225.79.103 (DiskussionBeiträge). 15:46, 1. Feb 2006)

„...dass Gruppen die Rechte immer erweitern, während Rollen diese auch einschränken können“
Stimmt das? Wie verträgt sich das damit, daß ein User mehrere Rollen haben kann? Die Rollen in Zope können lokal zugewiesen werden (für einen bestimmten Zweig im Objektbaum), was für Gruppen (die es in Zope nicht gibt, sondern nur im Betriebssystem) m. E. nicht gilt; daß sie Rechte einschränken könnten, wäre mir neu. --Tobias 00:51, 11. Jun. 2008 (CEST)[Beantworten]
Prinzipiell können Rollen Rechte tatsächlich einschränken. Allerdings nicht im herkömmlichen Sinne. Dem Benutzer werden durch eine bestimmte Rolle Rechte nicht wieder aberkannt, die er durch eine andere erlangt hat. Eine Einschränkung kann druch das Separation of Duty-Konzept erreicht werden, welches ich etwas weiter oben - sehr grob - beschrieben habe. -- Alexander Serbe 21:48, 22. Nov. 2009 (CET)[Beantworten]

Gruppen haben m. E. eine zu prominente Rolle im Artikel; sie gehören doch nicht wirklich zum Modell, oder? Einer Rolle (im Kontext einer Anwendung) eine oder mehrere (Betriebssystem-) Gruppen zuzuordnen (und Rollen damit als zusätzliche Abstraktionsschicht einzuziehen), ist doch nur eine Implementationsmöglichkeit. Oder?! In Zope (ebenso wie in vielen anderen Server-Anwendungen) haben die Rollen nämlich gar nichts mit den Gruppen des Betriebssystems zu tun, weil es auch seine eigenen User definiert, die gleichermaßen keine Benutzer des Betriebssystems sind. --Tobias 01:09, 11. Jun. 2008 (CEST)[Beantworten]

Ich würde grundsätzlich sagen, dass Gruppen im RBAC-Modell überhaupt nichts verloren haben. Ich kann mich jedenfalls nicht erinnern, im ANSI-Standard für RBAC-Systeme irgendwas davon gelesen zu haben, dass man einer Rolle verschiedene Gruppen zuweisen kann (oder habe ich das falsch verstanden?). Man könnte höchstens Gruppen und Rollen (bis zu einem gewissen Punkt) miteinander vergleichen. Der entscheidende Unterschied ist jedoch, dass Gruppen Benutzer zusammenfassen, während in einer Rolle Rechte zusammengefasst werden. -- Alexander Serbe 23:44, 22. Nov. 2009 (CET)[Beantworten]

Gruppen gehören nicht zum Standard-RBAC, währenddessen die Berechtigung, die Operation, das Objekt und die Sitzung als Entitäten völlig unerwähnt bleiben. Ich schlage eine Neustrukturierung vor:

  • Standard
    • Core RBAC
    • Hierarchical RBAC
      • Eingeschränkte Rollenhierarchie
    • Constained RBAC
      • Static Separation of Duty
      • Dynamic Separation of Duty
  • Implementierungen

Wenn ich später Zeit habe, kann ich später gerne eigenen, geprüften Text beitragen. -- 78.50.65.207 08:28, 7. Okt. 2010 (CEST)[Beantworten]

Verweis und entsprechender Artikel zu ABAC fehlt[Quelltext bearbeiten]

Attribute Bases Access Control - vgl. auch die englische Wikipedia. Der Begriff sollte zumindest in RBAC erwähnt werden und ein Link auf eine dann hoffentlich existierende Seite zu ABAC anbieten. (nicht signierter Beitrag von 78.53.113.84 (Diskussion) 08:02, 23. Sep. 2016 (CEST))[Beantworten]