Wenn ich über ACL und RBAC lese, scheint es mir leicht zu verstehen - es gibt entweder Benutzernamen oder Rollen, die Zugriff auf ein Asset erhalten. Ich kann auch sehen, wie ich diese umsetzen könnte.

dh dieses Bild gibt mir eine klare Sicht auf ACL und RBAC (wie in Ich kann fortfahren und Datenbanktabellen basierend auf oben entwerfen): (Bild mit freundlicher Genehmigung von Pressebüchern )

Was ich zu kämpfen habe, ist ABAC. Verschiedene Bilder, die ich bisher gefunden habe, sind von Hand gewellt oder übermäßig kompliziert oder schlagen vor, eine externe Autorisierung eines Drittanbieters zu verwenden, um die Autorisierung durchzuführen. Oder geben Sie seltsame Attributbeispiele, deren Verwendung ich nicht ganz sicher bin.

Startbeispiel

Lassen Sie mich also mit etwas im wirklichen Leben beginnen. Angenommen, ich habe eine Firma mit 70 bis 200 Mitarbeitern. Und mein Kapital zum Schutz ist eine Website mit vielen verschiedenen Seiten. Ich möchte bestimmten Personen den Zugang zu bestimmten Vermögenswerten ermöglichen.

Ich möchte beispielsweise, dass eine Person LeslieZugriff auf eine aufgerufene Webseite Price Managerhat und ihr erlaubt, nur die Preise für die TravelPreisgruppe auf dieser Seite zu verwalten, nicht jedoch die Preise für die ProductGruppe auf derselben Seite. Wie würde ich dies mit ABAC implementieren?

Stochern so weit, ist meine Vermutung ich zuweisen könnte Leslieeinige Attribute (aber welche und was sind diese Attribute?) Und haben dann eine Datenbanktabelle diejenigen zu speichern. Ich kann dann eine Engine entwerfen, die diese Attribute betrachtet (aber nicht Lesliewie in RBAC als "Rolle" betrachtet) und von dort aus entscheidet, ob Zugriff auf die Seite gewährt wird oder nicht. Wie würde dieser Motor aussehen? Ist es ein einfacher if / else-Block? Etwas anderes?

Was passiert, wenn Leslie später ihre Position ändert und jemand ihren Zugang ändern muss? Wie wird es aussehen, wenn der Zugriff verschoben Productund widerrufen werden muss Travel? Wie wird es codiert, wenn ihr der Zugriff auf die Price ManagerSeite insgesamt entzogen werden muss und sie daher keinen Zugriff mehr auf die Seite Travelhat oder Product?

Das Asset in meinem Fall ist, um es noch einmal zu wiederholen Price Manager, und ein Benutzer kann auf verschiedene Preisgruppen auf dieser Seite zugreifen, wie z. B. TravelPreise, ProductPreise usw.

Was ich suche, ist eine einigermaßen vollständige Roadmap zur Klärung der Details und zur Umsetzung dahin, wo ich sie ohne Vermutung umsetzen könnte. dh es könnte konzeptionell vervollständigt werden und / oder ein spezifisches Beispiel dafür haben, wo ich eine Datenbankstruktur usw. visualisieren kann.

Bonus: Ist ABAC ein geeigneter Weg für einen relativ geringen Genehmigungsbedarf, dh die Verwaltung von 70 bis 200 Personen und den Zugriff auf etwa 150 bis 450 Vermögenswerte? Wird es besser sein, stattdessen bei ACL / RBAC zu bleiben?

Eine ABAC-Implementierung ist komplexer als ACL / RBAC. Einige Frameworks bieten Ihnen sogar Infrastruktur, um mit letzterem fertig zu werden. Wenn die Personen und Vermögenswerte unter einer relativ kleinen und festen Anzahl von Rollen / Kategorien zusammengefasst werden können, ist es wahrscheinlich am besten, sich an ACL / RBAC zu halten. Wenn sich die Berechtigungen von Person zu Person stark unterscheiden, könnte ABAC eine bessere und flexiblere Lösung bieten.

Wenn Sie sich für den ABAC-Pfad entscheiden, müssen Sie zunächst einige Zeit damit verbringen, den XACML- Standard zu lesen und zu verstehen . Die im Dokument bereitgestellten Beispiele verwenden eine XACML-kompatible Syntax und sind zunächst etwas schwierig zu kauen. Ich vermute, Sie möchten keine standardkompatible Lösung implementieren, sodass Sie nur die allgemeinen Ideen daraus benötigen.

Konzepte

XACML dreht sich um 4 Konzepte und deren Attribute: Themen , Aktionen , Ressourcen und Umgebung . Es gibt noch ein paar mehr, aber diese sind die wichtigsten. Alles andere ist darauf aufgebaut. Wenn ich mit diesen Konzepten einen Satz machen würde, könnte dies etwas in der Art sein: Subjekte führen Aktionen an Ressourcen in einer bestimmten Umgebung durch . Wenn Sie dies auf Ihr Szenario anwenden, bedeutet dies Folgendes:

• Leslie öffnet die Preismanager-Webseite.
• Leslie erstellt einen Reisepreis über die Webseite des Preismanagers.

Attributsammlung

Als erstes müssen wir die relevanten Attribute der oben genannten Konzepte erfassen. Im Idealfall sollten Sie keine bestimmten Attribute zuweisen, da XACML versucht, unauffällig zu sein und sich nur auf das zu verlassen, was das System natürlich bietet. Und so haben wir:

Gegenstand

Jeder Schauspieler in Ihrem System, sei es eine Person oder eine Dienstleistung. Unser Thema ist Leslie. Welche Attribute sind erforderlich, um Leslie eindeutig zu identifizieren? Wahrscheinlich einige der folgenden: first name, last name, e-mail, ssn, company id, position(s).

Aktion

Jede von den Probanden durchgeführte Aktion. Kann die Standard-CRUD-Operation oder etwas komplexeres sein. Unsere Handlungen sind open/viewund create. Die Attribute für diese Aktionen können je nach verwendetem Webanwendungsframework unterschiedlich sein. Wir werden mehr darüber sprechen, wenn wir zur Ressource kommen.

Ressource

Ziemlich selbsterklärend. Unsere Ressourcen sind die price manager page, travel pricesund the newly created price. Es könnte mehr geben, wenn Sie wirklich wollen. Möglicherweise möchten Sie Aktionen ausblenden, die die Benutzer nicht ausführen können. Z.B. Dies create price buttonkann eine Ressource sein, die angezeigt / ausgeblendet werden kann, je nachdem, ob der Benutzer zum Erstellen von Preisen berechtigt ist. Da ein Benutzer eine Preisliste nur über diese Seite anzeigen kann, ist es wahrscheinlich eine gute Idee, die Autorisierung auf dieser Ebene durchzusetzen, anstatt weiter unten im Stapel.

Der Zugriff auf Ressourcen ist am kompliziertesten zu implementieren, insbesondere bei Ressourcen, die aus einer Datenbank stammen. Die feinkörnigere Option ist die Sicherheit auf Zeilenebene. Einige Datenbanken haben eine gewisse Unterstützung dafür. Einige XACML-Implementierer haben sogar eine SQL-Obermenge erstellt. Dies hängt wirklich von Ihren Autorisierungsanforderungen ab, aber das einzige, was Sie nicht tun möchten, ist, alles von einem Tisch zu ziehen und dann zu entscheiden, was angezeigt werden soll. Sie können Ressourcen nach Berechtigungssätzen gruppieren, sie hinter einer API abstrahieren und die Autorisierung an den API-Endpunkten erzwingen.

Umgebung

Ich kann es nicht richtig definieren (XACML hat auch keine richtige Definition), aber sagen wir, es ist die "Blase", in der all dies passiert. Dazu gehören: web application, web server, operating system, browser, office. Sie könnten extrahieren Attribute wie: ip address, time of day, user locale, user agent, operating system version. Sie können diese verwenden, um den Benutzerzugriff in Umgebungen zu blockieren, die von Ihrer Anwendung nicht unterstützt werden (z. B. alte Browser, alte Betriebssysteme, Computer außerhalb Ihres Netzwerks, Zugriff außerhalb der Geschäftszeiten).

Autorisierungsanfrage

Sobald wir alle erforderlichen Attribute gesammelt haben, bündeln wir sie in einer Autorisierungsanforderung und leiten sie an eine Entität weiter, die basierend auf den Werten dieser Attribute Autorisierungsentscheidungen treffen kann. In XACML lingua wird der Ort, an dem Sie diese Attribute sammeln und die daraufhin getroffenen Entscheidungen erzwingen, als Policy Enforcement Point (PEP) bezeichnet, und der Punkt, an dem Entscheidungen getroffen werden, wird als Policy Decision Point (PDP) bezeichnet. Die Speicherorte, von denen Attributwerte abgerufen werden, werden als Richtlinieninformationspunkte (PIP) bezeichnet. PEPs, PDPs und PIPs können Teil Ihrer Anwendung sein, da es sich um externe Systeme handeln kann. Ein Diagramm, wie sie miteinander kommunizieren, finden Sie im XACML-Standard.

Entscheidungsprozess

Der Entscheidungsprozess basiert auf Regeln . Regeln können in Richtlinien gruppiert werden , die weiter in Richtliniensätzen gruppiert werden können . Jeder von diesen hat ein Ziel . Das Ziel wird verwendet, um zu entscheiden, ob eine der Regeln für die Autorisierungsanforderung gilt. Betrachten Sie es als Filter. Das Ziel enthält Bedingungen, die unter Verwendung von Attributnamen und -werten erstellt wurden. Beispielsweise könnten die Regeln für Ihre Anwendung in folgende Gruppen unterteilt werden:

Webanwendung (Richtliniensatz)
| - Ziel: Anwendungsname == "Webanwendung"
`- Version 1.0 (Richtliniensatz)
    | - Ziel: Anwendungsversion == "1.0"
    `- Preismanager anzeigen (Richtlinie)
        | - Ziel: Webseiten-Name == "Preismanager" && Aktionsname == "Ansicht"
        `- Leslie kann den Preismanager anzeigen (Regel)
            | - Ziel: Betreffname == "Leslie"
            `- Erlaubnis: erlauben

Der PDP vergleicht alles im obigen Satz mit den Attributwerten in der Autorisierungsanforderung. Was passiert, wenn es keine übereinstimmenden Regeln gibt, hängt von der Implementierung Ihres PDP ab. Sobald die PDP eine Entscheidung getroffen hat ( allow, denyoder not-applicable) es sendet es an den PEP Rückseite , die auf sie wirkt , indem es die Gewährung oder den Ressourcenzugriff verweigert. Zusammen mit der Reaktion kann die PDP eine Liste senden obligationsund advicesdass der PEP muss oder bei der Durchsetzung Prozess erfüllen sollte. Abhängig davon, wie die Regeln gespeichert sind (Textdateien oder Datenbank), kann ein Administrator einen Standardtexteditor oder eine benutzerdefinierte Bearbeitungsanwendung verwenden, um diese nach eigenem Ermessen zu ändern. Durch den Widerruf des Zugriffs von Leslie auf den Preismanager wird die Berechtigung einfach von allowauf geändertdeny, vorausgesetzt, die PEP macht ihre Arbeit.

Durchsetzung

Dies hängt stark von Ihrem Technologie-Stack ab. Einige Webframeworks verfügen über natürliche Durchsetzungspunkte (z. B. ASP.NET MVC verfügt über Attributfilter). Ihre Geschäftsschichten müssen möglicherweise solche Durchsetzungspunkte definieren. Ich fand es einfacher, die Durchsetzung auf Service-Endpunkten (Think Microservices) oder auf UI-Ebene anzuwenden.

Andere Vorteile

Ein netter Nebeneffekt bei der Implementierung ist, dass Sie einen ziemlich umfangreichen Audit-Trail erhalten, der für andere Zwecke verwendet werden kann.