Beziehungsbasierte Zugriffskontrolle mit OpenFGA

Die Verwaltung des Zugriffs auf einzelne Ressourcen in einer Cloud-Umgebung kann eine Herausforderung sein, insbesondere wenn es um Berechtigungen für mehrere Benutzer und Dateien geht. Stellen Sie sich ein Szenario vor, in dem verschiedene Benutzer unterschiedliche Zugriffsebenen für mehrere in einem Cloud-Laufwerk gespeicherte Dateien benötigen. Herkömmliche Zugriffsverwaltungslösungen bieten oft nicht die erforderliche Granularität und Flexibilität.

Das ist wo FGA öffnen von der Autor 0 Das Team tritt ein und bietet eine feinkörniges Autorisierungssystem, das eine präzise und effektive Rechteverwaltung auf individueller Ressourcenebene ermöglicht.

In diesem Artikel werden wir untersuchen, wie OpenFGA implementiert werden kann, um allgemeine Herausforderungen bei der Zugriffskontrolle zu lösen und eine sichere, effiziente Verwaltung von Benutzerberechtigungen zu gewährleisten.

Tl; dr — für die Vielbeschäftigten

OpenFGA bietet eine leistungsstarke Lösung für die Verwaltung des feingranularen Zugriffs auf Ressourcen:

Fine-Grained Authorization (FGA) ermöglicht es, bestimmten Benutzern das Recht zu gewähren, bestimmte Aktionen an einzelnen Ressourcen durchzuführen.

Typ

Ein Typ ist eine Zeichenfolge, die eine Kategorie von Objekten definiert, die ähnliche Eigenschaften aufweisen:

• Nutzer
• Mappe
• Dokument

Definition des Typs

Eine Typdefinition spezifiziert alle Potenziale Beziehungen die ein Benutzer oder ein anderes Objekt mit diesem Typ haben kann:

type document
	relations
		define can_view: [user] or owner
		define can_edit: [user] or owner
		define owner: [user]

Autorisierungsmodell

Strukturierter Weg, um zu definieren, wer unter welchen Bedingungen Zugriff auf welche Ressourcen hat:

model
	schema 1.1
	
type document
	relations
		define can_view: [user] or owner
		define can_edit: [user] or owner
		define owner: [user]
		
type user

Objekt

Ein Objekt stellt innerhalb des Systems eine Entität dar, und die Beziehungen der Benutzer zu ihr werden mithilfe von Beziehungstupeln definiert, wie in der Autorisierungsmodell:

• Dokument:Ausgaben
• Ordner:allgemein

Nutzer

EIN Benutzer ist eine Entität im System, die sein kann verbunden zu einem Objekt:

• Benutzer: john
• Dokument: Vertrieb

Tupel

EIN Beziehungstupel umfasst eine Benutzer, Beziehung, und Objekt. Diese Tupel werden in OpenFGA geschrieben und gespeichert, um bestimmte Beziehungen und Berechtigungen innerhalb des Systems zu definieren.

Behauptungen

Assertions sind Abfragen, um zu überprüfen, ob ein Benutzer eine bestimmte Beziehung zu einer Ressource hat.

is user:alice related to resource:file1 as can_view? // true

Umsetzung

Definieren wir einige Regeln und Herausforderungen, die wir lösen möchten:

• Jeder Benutzer, der eine Datei erstellt, ist Eigentümer der Ressource
• Ansicht-/Bearbeitungsberechtigungen können anderen Benutzern erteilt werden
• Ein Benutzer kann eine Datei anzeigen, wenn er eine Bearbeitungsberechtigung hat
• Einzelne Ressourcen können mit allen Benutzern geteilt werden, um eine Datei anzusehen - öffentlicher Zugriff
• Eine Datei kann von Benutzern angesehen werden, die einen übergeordneten Ordner anzeigen können

Schauen wir uns eine einfache Cloud-Drive-Struktur an. Wir können verschiedene Benutzer und Ressourcen haben.

Um mit der Arbeit an den oben definierten Regeln zu beginnen, müssen wir uns zunächst um das Autorisierungsmodell kümmern. Bevor wir damit beginnen, wollen wir klären, was das Modell ist.

‍

Autorisierungsmodell

Das Autorisierungsmodell in FGA öffnen ist eine strukturierte Methode, um zu definieren, wer unter welchen Bedingungen Zugriff auf welche Ressourcen hat. Es basiert auf ReBac Regeln. Die wichtigsten Bestandteile des Modells sind Typen und Beziehungen. Lassen Sie uns zur Definition des Modells für unsere Bedürfnisse übergehen:

model
	## schema version must be defined
	schema 1.1
	
## Let's assume that document will be our resource
type document
	relations
		define can_view: [user] or owner
		define can_edit: [user] or owner
		define owner: [user]
		
### user type must be defined if we are using it in the model
type user

Wenn das Modell vorhanden ist, können wir jetzt Tupel hinzufügen. Anhand dieser identifizieren wir den Besitzer der Datei. Kurz gesagt, Tupel sind Bausteine zur Definition von Beziehungen zwischen Typen.

Schauen wir uns an, wie Tupel basierend auf unseren Bedürfnissen definiert werden sollten:

## A tuple consists of object, relation and user fields, 
## where 'user' does not mean 'user of the system' but rather a subject.

## Our first tuple defines the relation between the user "John"
## and document created by him "sales"

## user john is related to document sales as owner
Object: "document:sales"
Relation: "owner"
User: "user:john"

## user mark is related to document expenses as owner
Object: "document:expenses"
Relation: "owner"
User: "user:mark"

Großartig! Mit unseren ersten Tupeln und dem definierten Modell können wir jetzt Aussagen treffen.

Behauptung

Fangen wir mit einem einfachen Anwendungsfall an:

John versucht, das Verkaufsdokument einzusehen. Das ist einfach. Aber wie würde diese Behauptung in OpenFGA strukturiert sein?

Ist Benutzer: john im Zusammenhang mit Dokument: Vertrieb als can_view ? ✅

‍Wir haben einen Benutzer (Subjekt), ein Objekt und eine Beziehung, genau wie in Tupeln.

Die grundlegende Abfragestruktur sollte wie folgt gelesen werden:
Ist Benutzer: {userId} im Zusammenhang mit Objekt: {objectId} als Verwandter?

Aus Codesicht wäre die Abfrage wie folgt definiert:

Object: "document:expenses"
Relation: "can_view"
User: "user:john"

Großartig, aber wir haben nur das Eigentümertupel definiert, um anzugeben, wem die Datei gehört.

Woher wissen wir, ob John es sehen kann?

Gehen wir zurück zum Schema. Wir haben definiert, dass das Dokument vom direkten Benutzer [Benutzer] oder vom Eigentümer der Datei eingesehen werden kann:

define can_view: [user] or owner

Es gibt uns klare Informationen, dass ein Benutzer, dem die Datei gehört, sie anzeigen kann. Außerdem kann der Besitzer die Datei bearbeiten.

Lassen Sie uns einige schnellere Behauptungen aufstellen:

Ist Benutzer: mark im Zusammenhang mit Dokument: Vertrieb als can_view ? 🚫

‍Diese Behauptung ist falsch, da der Nutzer Mark kein Eigentümer der Verkäufe von Dokumenten ist und er keinen Zugang zu ihnen erhalten hat.

Wie können wir es reparieren? Durch Hinzufügen eines Tupels, das eine Beziehung hinzufügt can_view zwischen Mark und der Datei:

### user mark is related to document sales as can_view
Object: "document:sales"
Relation: "can_view"
User: "user:mark"

Jetzt kann Mark die Verkäufe von Dokumenten einsehen. Wir haben den granularen Zugriff auf dieses Dokument mit dem FGA-Tupel definiert. Trotzdem kann Mark die Datei nicht bearbeiten, da es kein Tupel mit einem kann_bearbeiten Beziehung. Um das zu beheben, müssen wir ein weiteres Tupel hinzufügen:

### user Mark is related to document sales as can_edit
Object: "document:sales"
Relation: "can_edit"
User: "user:mark"

Toll, jetzt kann Mark die Datei bearbeiten und ansehen. Aber etwas stimmt nicht ganz. Wenn jemand eine Datei bearbeiten kann, sollte er sie auch ansehen können. Brauchen wir wirklich zwei separate Tupel? Lassen Sie uns das Schema vereinfachen und noch einmal überprüfen:

 model
	schema 1.1
	
type document
	relations
		### define that the document can be viewed by a user with a can_edit relation
		define can_view: [user] or owner or can_edit
		define can_edit: [user] or owner
		define owner: [user]
		
type user

Wenn Sie nun ein Tupel für einen neuen Benutzer mit der Beziehung can_edit erstellen, kann dieser auch eine Datei anzeigen.

Allen Benutzern Zugriff auf Dokumente gewähren

Was ist mit einer Situation, in der jeder Benutzer die Datei sehen kann? Das Definieren von Tupeln für jeden einzelnen Benutzer kann umständlich sein. OpenFGA gibt uns Platzhalter. Lassen Sie uns unser Schema um sie erweitern, um unser Leben einfacher zu machen.

model
	schema 1.1
	
type document
	relations
		## Extending can_view relation with user:* allow us to make decision
		## if a file can be viewed by all of the users
		define can_view: [user, user:*] or owner or can_edit
		define can_edit: [user] or owner
		define owner: [user]
		
type user

Einfach ausgedrückt haben wir definiert, dass alle Benutzer eine Datei anzeigen können, aber wir müssen eine bestimmte Datei direkt mit dieser Einstellung markieren, um sie für alle sichtbar zu machen. Dafür müssen wir eine erstellen Tupel bevor Sie ein Tupel definieren, bei dem Mark Eigentümer der Dokumentenausgaben ist. Machen wir es öffentlich!

Object: "document:expenses"
Relation: "can_view"
User: "user:*"

Großartig, jetzt kann jeder Benutzer einen Spesenbeleg einsehen.

🚨 Bevor ein Tupel gespeichert wird, wird es anhand des Autorisierungsmodells validiert. Das Tupel würde abgelehnt, wenn Autorisierungsmodell war zuvor nicht verlängert worden und der Zugriff konnte nicht jedem Benutzer gewährt werden.

Jetzt würden alle Behauptungen durchgehen:

## Can Paul view a document expenses?
is user:paul related to document:expenses as can_view ? // true

### Can Katie view a document expenses?
is user:katie related to document:expenses as can_view ? // true

Gruppieren von Dokumenten mit Ordnern

Derzeit liegen uns einzelne Dokumente vor. Unser Ziel ist es, den Zugriff auf Ordnerebene so zu ermöglichen, dass einem Benutzer Folgendes gewährt wird can_view Die Berechtigung für einen Ordner ermöglicht es ihnen automatisch, alle in diesem Ordner enthaltenen Dokumente einzusehen. Dieser Ansatz ermöglicht es Benutzern auch, ganze Ordner mit all ihren Inhalten gemeinsam zu nutzen, ohne für jedes einzelne Dokument Tupel hinzufügen zu müssen.

Fangen wir mit dem Autorisierungsmodell an:

model
	schema 1.1
	
type document
	relations
		define can_view: [user, user:*] or owner or can_edit
		define can_edit: [user] or owner
		define owner: [user]
		### Every document now will have the possibility to assign parent (folder) 
		define parent: [folder]
		
type user

type folder
	relations
		### Let's create simple relations for folders
		define owner: [user]
		define can_view: [user] or owner

Lassen Sie uns ein Dokument mit einem Ordner verbinden und die übergeordnete Beziehung mit Tupeln zuweisen:

### First define the owner of the folder
Object: "folder:general"
Relation: "owner"
User: "user:paul"

### Let's assign the parent folder to the invoices document
Object: "folder:general"
Relation: "parent"
User: "document:invoices"

Wir haben das übergeordnete Element dem Rechnungsdokument zugewiesen. Teilen wir den ganzen Ordner mit Mike:

### To share the folder with Mike - we need to create a tuple for it
Object: "folder:general"
Relation: "can_view"
User: "user:mike"

Was haben wir gemacht? Wir haben Zugriff auf den Ordner gewährt. Mike kann einen Ordner einsehen, der das übergeordnete Element des Rechnungsdokuments ist. Lassen Sie uns eine Behauptung aufstellen:

Ist Benutzer: mike im Zusammenhang mit Dokument:Rechnungen als can_view ? 🚫

Leider kann Mike das Dokument in dem Ordner immer noch nicht sehen, auch wenn er eine can_view Beziehung zu diesem Ordner. Um das zu ermöglichen, müssen wir zu unserem Modell zurückkehren:

model
	schema 1.1
	
type document
	relations
		## Adding "can_view from parent" gives information that a document can
		## can be viewed by a user with relation can_view to parent (folder).
		## In simple words - every user who has can_view permission to a parent folder
		## can view documents inside of it (connected with parent relation)
		define can_view: [user, user:*] or owner or can_edit or can_view from parent
		define can_edit: [user] or owner
		define owner: [user]
		define parent: [folder]
		
type user

type folder
	relations
		## Let's create simple relations for folders
		define owner: [user]
		define can_view: [user] or owner

Wir haben die Beziehung erweitert can_view auf einem Dokument. Dank dessen würde die Behauptung jetzt durchgehen:

Ist Benutzer: mike im Zusammenhang mit Dokument:Rechnungen als can_view? ✅

Fazit

Implementierung eines feinkörnigen Autorisierungssystems wie FGA öffnen verändert die Art und Weise, wie wir den Ressourcenzugriff in verschiedenen Umgebungen verwalten. Indem wir ein robustes Autorisierungsmodell definieren, Tupel zum Aufbau von Beziehungen verwenden und hierarchischen Zugriff ermöglichen, wir können präzise kontrollieren, wer Ressourcen einsehen und bearbeiten kann. Die Unterstützung flexibler Berechtigungseinstellungen und Platzhalter durch OpenFGA vereinfacht den Verwaltungsprozess weiter und stellt sicher, dass die Zugriffskontrolle sowohl sicher als auch einfach zu handhaben ist. Mit diesen Tools können Unternehmen vertrauensvoll den entsprechenden Zugriff auf ihre Ressourcen gewähren und so die Sicherheit und Betriebseffizienz verbessern.