Directus Berechtigungen: Rollen, Richtlinien und Zugriffskontrolle

Directus Berechtigungen: Rollen, Richtlinien und Zugriffskontrolle

Directus-Berechtigungen bestehen aus drei Teilen: Berechtigungen (was eine Sammlung und eine Aktion erlauben), Richtlinien (benannte Gruppen von Berechtigungen) und Rollen (wie Personen in Ihrer Organisation eingeordnet sind). Richtlinien werden Rollen oder direkt Benutzern zugewiesen, und der effektive Zugriff eines Benutzers ergibt sich aus der Summe aller zugewiesenen Richtlinien. Wenn dieses Modell stimmt, ist der Rest Konfiguration. Wenn nicht, entstehen die verwirrenden Verhaltensweisen, die den Directus Issue-Tracker füllen: ein Administrator, dem angeblich „die Berechtigung fehlt“, eine Dateiregel, die nichts bewirkt, oder eine Benutzersammlung, die Felder offenlegt.

Dieser Leitfaden erläutert das Modell, zeigt, wie Sie den Zugriff auf Sammlungs-, Feld- und Elementebene konfigurieren, behandelt ein Genehmigungsmuster vom Entwurf bis zur Veröffentlichung und endet mit dem Testen und Absichern Ihrer Konfiguration. Wir entwickeln und betreuen Directus-Projekte bei Ridiculous Engineering, daher konzentrieren sich die Empfehlungen auf Lösungen, die sich in der Produktion bewähren.

Wichtigste Erkenntnisse

• Jede Berechtigung gilt für genau eine Sammlung und eine Aktion und kann vollständigen Zugriff, keinen Zugriff oder benutzerdefinierte Regeln erlauben.
• Richtlinien bündeln Berechtigungen und werden Rollen oder Benutzern zugewiesen. Der effektive Zugriff ist additiv, daher erhält ein Benutzer die Vereinigung aller seiner Richtlinien.
• Lassen Sie den Zugriff der Rolle „Public“ standardmäßig verweigern und beschränken Sie Änderungen an Benutzern, Rollen, Richtlinien und Berechtigungen ausschließlich auf vertrauenswürdige Administratoren.
• Verwenden Sie Elementfilter, Feldlisten, Validierung und Voreinstellungen, um reale Geschäftsregeln abzubilden, etwa „Autoren bearbeiten nur ihre eigenen Entwürfe“.
• Prüfen Sie über die Permissions API, was ein Benutzer tatsächlich tun kann, statt dies anhand der Einstellungsseite zu vermuten.

Inhaltsverzeichnis

• Wie das Directus-Berechtigungsmodell zusammenspielt
• Zugriff für Sammlungen, Felder und Elemente konfigurieren
• Filter, Voreinstellungen und Validierung: drei Werkzeuge, drei Aufgaben
• Ein ausgearbeitetes Beispiel: Entwurf, Prüfung, Veröffentlichung
• Öffentlicher Zugriff und Administratorzugriff
• Testen und Beheben von Problemen beim tatsächlichen Benutzerzugriff
• Häufige Fehler, die wir in realen Projekten sehen
• Berechtigungen planen, bevor Sie entwickeln
• Arbeiten mit Ridiculous Engineering auf Directus
• FAQ
• Quellen

Wie das Directus-Berechtigungsmodell zusammenspielt

Laut der Directus-Dokumentation zur Zugriffskontrolle gilt eine Berechtigung für genau eine Sammlung und eine Aktion. Für jede Kombination wählen Sie vollständigen Zugriff, keinen Zugriff oder benutzerdefinierte Regeln auf Basis von Elementfiltern, Feldlisten, Validierung und Voreinstellungen.

Die Bestandteile greifen wie folgt ineinander:

• Berechtigung: eine Sammlung, eine Aktion (erstellen, lesen, aktualisieren, löschen, teilen) mit ihren Regeln.
• Richtlinie: eine Gruppe von Berechtigungen. Richtlinien können auf Rollen oder einzelne Benutzer angewendet werden.
• Rolle: eine Beschreibung der Position einer Person innerhalb der Organisation. Eine Rolle kann Richtlinien, Benutzer und untergeordnete Rollen umfassen.
• Benutzer: eine Person oder ein Dienstkonto, die bzw. das eine Rolle, direkt zugewiesene Richtlinien oder beides haben kann.

Zwei Verhaltensweisen sind besonders wichtig. Erstens sind effektive Berechtigungen additiv: Wenn eine Richtlinie das Lesen von Artikeln erlaubt und eine andere ihre Aktualisierung, kann der Benutzer beides tun. Es gibt kein „Verweigern“, das ein „Erlauben“ aus einer anderen Richtlinie außer Kraft setzt. Sie entziehen den Zugriff daher, indem Sie die Richtlinie entfernen, statt zusätzlich eine Einschränkung darüberzulegen. Zweitens ist die Administratorrolle uneingeschränkt, während die öffentliche Rolle Anfragen ohne Authentifizierung regelt.

Die praktische Konsequenz daraus ist, dass Richtlinien die Einheit bilden, um die herum Sie Ihr Berechtigungskonzept entwerfen sollten. Rollen beantworten die Frage „Wer ist diese Person?“. Richtlinien beantworten die Frage „Was darf getan werden?“. Wenn Sie diese Fragen getrennt halten, verhindern Sie, dass eine Berechtigungskonfiguration zu einer Ansammlung individueller Ausnahmen wird. Wenn Sie die umfassenderen Designüberlegungen dahinter kennenlernen möchten, zeigt unser Leitfaden für den rollenbasierten Zugriffskontrollentwurf wie Sie Rollen aus realen Aufgabenfunktionen ableiten, bevor Sie ein Tool verwenden.

Warum sich die Administratorrolle anders verhält

Administratoren kann weder mehr noch weniger Zugriff gewährt werden. Die Rolle ist definitionsgemäß uneingeschränkt, daher können Sie sie nicht durch Regeln begrenzen. Wenn Sie jemanden benötigen, der Inhalte verwaltet, aber nicht auf Einstellungen zugreifen darf, erstellen Sie für diese Person eine separate Richtlinie. Verwenden Sie kein Administratorkonto in der Hoffnung, es einschränken zu können. Viele der Meldungen zu „Berechtigungsproblemen beim Root-Benutzer“ im öffentlichen Issue-Tracker entstehen, weil erwartet wird, dass sich Administratorkonten wie jede andere Rolle konfigurieren lassen.

Zugriff für Sammlungen, Felder und Elemente konfigurieren

Für jede Sammlung und Aktion wählen Sie eine von drei Einstellungen: alle, keine oder benutzerdefiniert. Bei „Benutzerdefiniert“ findet die eigentliche Arbeit statt. Wie im Leitfaden zur Zugriffskontrollebeschrieben, können benutzerdefinierte Berechtigungen festlegen, auf welche Elemente die Aktion angewendet wird und welche Felder zulässig sind.

Zugriff auf Sammlungsebene

Beginnen Sie hier und bleiben Sie zurückhaltend. Eine typische Richtlinie für ein Content-Team könnte so aussehen:

Diese Tabelle veranschaulicht ein Muster, stellt jedoch keinen vorgeschriebenen Standard dar. Entscheidend ist die Struktur: Referenzdaten sind schreibgeschützt, Inhalte werden unter bestimmten Bedingungen erstellt und bearbeitet, und niemand im Content-Team löscht etwas.

Zugriff auf Feldebene

Innerhalb einer benutzerdefinierten Regel listen Sie die Felder auf, die ein Benutzer bearbeiten darf. Betrachten Sie dies als Positivliste. Alles, was Sie nicht auswählen, ist für diese Richtlinie unsichtbar oder unveränderlich – genau das, was Sie für interne Notizen, Preisfelder oder Statuskennzeichen für Workflows benötigen.

In öffentlichen Diskussionen taucht immer wieder ein Fallstrick auf: Man deaktiviert jedes Feld einer System-Collection wie der Benutzertabelle und erwartet, dass die Collection aus der Ansicht verschwindet. Wenn Benutzer die Details anderer Personen nicht sehen sollen, schränken Sie die Einträge mit einem Filter ein (siehe unten) und begrenzen Sie anschließend die Felder, statt sich allein auf eine leere Feldliste zu verlassen.

Zugriff auf Eintragsebene mit Filtern

Eintragsregeln bestimmen, auf welche Zeilen eine Aktion zugreifen kann. Der React-Authentifizierungsleitfaden von Directus zeigt zwei Muster, die sich zur Übernahme eignen:

1. Erstellung eigener Inhalte. Gewähren Sie Erstellungszugriff mit einer Voreinstellung, die das Autorenfeld auf $CURRENT_USERsetzt; gewähren Sie anschließend Aktualisierungs- und Löschzugriff nur, wenn user_created gleich $CURRENT_USER (Authentifizierung in React verwenden).
2. Selbstbedienungsprofil. Gewähren Sie Lese- und Aktualisierungsregeln auf Eintragsebene für directus_users beschränkt auf id = $CURRENT_USER, sodass Benutzer nur ihren eigenen Datensatz sehen und bearbeiten können (derselbe Leitfaden).

Diese beiden Regeln decken einen überraschend großen Teil realer Anwendungen ab: Kundenportale, Dashboards für Mitwirkende, Partner-Extranets und interne Tools, in denen jede Person Eigentümerin ihrer eigenen Datensätze ist.

Filter, Voreinstellungen und Validierung: drei Tools, drei Aufgaben

Diese Begriffe werden ständig verwechselt, daher ist es hilfreich, sie voneinander zu trennen.

• Eintragsfilter: bestimmt, welche vorhandenen Einträge die Aktion sehen oder ändern kann. Er beantwortet die Frage: „Welche Zeilen?“
• Validierung: prüft die übermittelten Werte. Sie beantwortet die Frage: „Ist diese Änderung zulässig?“
• Voreinstellung: füllt beim Erstellen eines Eintrags Standardwerte ein. Sie beantwortet die Frage: „Was sollte vorausgefüllt sein?“

Der Leitfaden zur Zugriffskontrolle beschreibt diese Aufteilung: Filter definieren zugängliche Einträge und validieren übermittelte Werte, während Voreinstellungen Standardwerte festlegen. Sobald Sie diesen Unterschied verstanden haben, lassen sich die meisten Rätsel rund um Berechtigungen leicht einordnen. „Autoren sollen nur ihre eigenen Beiträge bearbeiten“ ist ein Filter. „Autoren dürfen Beiträge nur als Entwurf speichern“ ist eine Validierung. „Neue Beiträge sollen festhalten, wer sie verfasst hat“ ist eine Voreinstellung.

Ein durchgängiges Beispiel: Entwurf, Prüfung, Veröffentlichung

Bei Freigabe-Workflows zeigen die Berechtigungen von Directus ihren Nutzen. Das offizielle Tutorial zu Content-Freigabe-Workflows mit benutzerdefinierten Berechtigungen erstellt einen solchen Workflow ausschließlich mit Richtlinien – und die Struktur ist es wert, verstanden zu werden.

Autoren

• Das Erstellen ist zulässig, wobei die Validierung nur Entwurfsartikel erlaubt.
• Das Aktualisieren ist bei Einträgen zulässig, die sich im Entwurf befinden oder geprüft werden.
• Die Validierung der Aktualisierung erlaubt nur einen Übergang zu „in Prüfung“, sodass ein Autor seine eigene Arbeit nicht veröffentlichen kann.

Redakteure

• Eine Aktualisierung ist nur für Artikel zulässig, die sich in Prüfung befinden.
• Die Validierung der Aktualisierung erfordert, dass die Statusänderung zu „veröffentlicht“ erfolgt.
• Löschen und Teilen bleiben eingeschränkt.

Das Designprinzip besteht darin, dass jede Rolle ein Element genau einen Schritt weiterbewegen kann und der Filter sicherstellt, dass sie nur Elemente in der von ihr verantworteten Phase sehen. Dafür ist kein Code erforderlich. Das bedeutet außerdem, dass der Workflow auf API-Ebene durchgesetzt wird und nicht nur in der Benutzeroberfläche der App, sodass ein benutzerdefiniertes Frontend oder ein Skript ihn nicht umgehen kann.

Wenn Sie vergleichen, wie andere Teams Fälligkeitstermine und die Übergabe von Entwürfen rund um einen solchen Ablauf strukturieren, Workflows für Entwürfe mit Fälligkeitstagen zeigen ein verwandtes redaktionelles Muster. Wenn Genehmigungen zusätzlich zu Berechtigungen Benachrichtigungen, Eskalationen oder System-Hooks benötigen, ist das der Bereich von Flows, den wir unter Directus Flows in der Praxisbehandeln.

Öffentlicher Zugriff und Administratorzugriff

Diese beiden Enden des Spektrums verursachen die schwerwiegendsten Fehler, daher verdienen sie eigene Regeln.

Die Rolle „Public“

Lassen Sie „Public“ standardmäßig den Zugriff verweigern. Gewähren Sie Lesezugriff nur auf Daten, die tatsächlich für alle im Internet bestimmt sind, und schränken Sie ihn doppelt ein: durch einen Elementfilter (z. B. nur Elemente mit dem Status „veröffentlicht“) und durch eine Feldliste (lassen Sie interne Notizen, E-Mail-Adressen von Autoren und alles andere weg, was Sie nicht auf eine Plakatwand drucken würden). Die Directus-Leitlinien stellt außerdem ausdrücklich klar, dass sensible und System-Sammlungen nicht ohne Grund offengelegt werden sollten.

Eine kurze Gewohnheit hilft: Fragen Sie sich jedes Mal, wenn Sie eine Public-Berechtigung hinzufügen, was eine fremde Person mit einem Skript abrufen könnte, wenn sie jedes Element dieser Sammlung anfordern würde. Wenn Ihnen die Antwort unangenehm ist, verschärfen Sie den Filter.

Administratoren und die Identitätssammlungen

Beschränken Sie Änderungen an Benutzern, Rollen, Richtlinien, Berechtigungen, Einstellungen und dem Schema auf vertrauenswürdige Administratoren. Die Directus bewährten Sicherheitspraktiken empfehlen das Erstellen, Aktualisieren und Löschen ausschließlich durch Administratoren für directus_users, directus_roles und directus_policies, da diese Befugnisse Konten erstellen, Berechtigungen zuweisen oder ändern können, worauf eine Rolle zugreifen kann. Jede Person, die diese Bereiche bearbeiten kann, kann sich selbst beliebige Rechte gewähren.

Für gewöhnliche Benutzer, die ihr eigenes Profil bearbeiten müssen, empfiehlt dieselbe Anleitung:

1. Eine Elementregel von id = $CURRENT_USER.
2. Entfernen Sie Rollen und Richtlinien aus den bearbeitbaren Feldern, damit eine Person sich nicht selbst befördern kann.
3. Kein umfassenderer Zugriff auf die Benutzerverwaltung.

Schritt zwei wird von Teams oft vergessen. Eine Regel zur Selbstbearbeitung ohne Feldeinschränkungen ist eine Rechteausweitung, die nur darauf wartet, ausgenutzt zu werden.

Testen und Beheben von Problemen bei den tatsächlichen Benutzeraktionen

Der Einstellungsbildschirm zeigt Ihnen, was Sie konfiguriert haben. Er zeigt Ihnen nicht, welche Berechtigungen ein bestimmter Benutzer letztlich erhält, wenn mehrere Richtlinien zusammenwirken. Verwenden Sie dafür die in den bewährten Sicherheitspraktikenbeschriebene Permissions API: Sie meldet den Zugriff des aktuellen Benutzers nach Sammlung und Aktion als keinen, teilweisen oder vollständigen Zugriff; Prüfungen auf Elementebene können einen bestimmten Datensatz untersuchen.

Ein zuverlässiger Testablauf:

1. Erstellen Sie für jede tatsächliche Rolle einen Testbenutzer, nicht nur für einen Administrator.
2. Authentifizieren Sie sich als dieser Benutzer und rufen Sie den Berechtigungsendpunkt auf, um den Zugriff nach Sammlung und Aktion zu prüfen.
3. Prüfen Sie bei jedem Ergebnis „teilweise“ ein bestimmtes Element, das zulässig sein sollte, und eines, das nicht zulässig sein sollte.
4. Führen Sie die Prüfung nach jeder Änderung an einer Richtlinie erneut durch, da kumulativer Zugriff bedeutet, dass eine neue Richtlinie den möglichen Handlungsspielraum eines Benutzers unbemerkt erweitern kann.

Wenn der Zugriff umfassender ist als erwartet

Die Ursache ist fast immer eine additive Kombination. Ein Benutzer hat eine Rolle mit einer Richtlinie und eine direkt zugewiesene Richtlinie mit einer anderen, und die Vereinigung ist größer als beabsichtigt. Listen Sie jede Richtlinie auf, die den Benutzer erreicht, einschließlich der Richtlinien, die über untergeordnete Rollen geerbt werden, und entfernen Sie die Richtlinie, die den zusätzlichen Zugriff gewährt.

Wenn der Zugriff eingeschränkter ist als erwartet

Prüfen Sie dies in der folgenden Reihenfolge:

• Ist die Aktion auf „Benutzerdefiniert“ eingestellt und mit einem Filter versehen, der das Element ausschließt? Ein Status- oder Eigentümerfilter ist meist die Ursache.
• Fehlt das benötigte Feld in der Liste der zulässigen Felder?
• Lehnt die Validierung den übermittelten Wert ab? Die fehlschlagende Änderung kann der konkrete Wert sein, nicht die Aktion.
• Haben Sie bei System-Sammlungen wie Dateien und Benutzern Regeln für die richtige Aktion festgelegt? Meldungen, dass Dateiregeln „nicht wie erwartet funktionieren“, sind meist auf eine fehlende Lese- oder Aktualisierungsberechtigung zurückzuführen, von der die Oberfläche abhängt. Testen Sie daher genau die Anfragen, die Ihre Anwendung sendet.

Änderungen können außerdem veraltet erscheinen, wenn Sie mit einer alten Sitzung testen. Authentifizieren Sie sich erneut, bevor Sie zu dem Schluss kommen, dass eine Regel fehlerhaft ist.

Häufige Fehler, die wir in realen Projekten sehen

• Eine Richtlinie pro Person. Das wirkt präzise und wird bereits ab der zehnten Einstellung unwartbar. Erstellen Sie Richtlinien auf Grundlage von Aufgabenbereichen und weisen Sie sie Rollen zu.
• Jemandem Administratorrechte geben, um eine Blockade zu lösen. Das vorübergehende Administratorkonto wird dauerhaft. Schreiben Sie stattdessen die enger gefasste Richtlinie.
• Vergessen, dass Berechtigungen additiv sind. Teams versuchen, durch das Hinzufügen einer einschränkenden Richtlinie den Zugriff zu „verweigern“. Entfernen Sie stattdessen die freigebende Richtlinie.
• Selbstbearbeitung ohne Feldbegrenzungen. Benutzer können ihre eigene Rolle oder ihre eigenen Richtlinien ändern.
• Dem Frontend vertrauen. Eine Schaltfläche auszublenden ist keine Zugriffskontrolle. Regeln gehören in die Berechtigungsebene, der jeder Client unterliegt.
• Nie überprüfen. Berechtigungen verändern sich, wenn Personen ihre Aufgaben wechseln. Planen Sie vierteljährlich eine Richtlinienüberprüfung ein.

Berechtigungen planen, bevor Sie entwickeln

Der günstigste Zeitpunkt, Berechtigungen richtig festzulegen, ist vor dem Abschluss des Schemas, da das Design der Sammlungen bestimmt, welche Filter Sie schreiben können. Fügen Sie ein Eigentümerfeld hinzu, wenn Datensätze einer Person gehören, ein Statusfeld, wenn Datensätze verschiedene Phasen durchlaufen, und eine klare Trennung zwischen öffentlichen und internen Inhalten. Halten Sie anschließend in klarer Sprache fest, wer jede Sammlung unter welchen Bedingungen erstellen, lesen, aktualisieren und löschen darf. Diese Tabelle in Richtlinien zu übertragen, dauert einen Nachmittag. Sie aus einem laufenden System zurückzuentwickeln, dauert Wochen.

Wenn Sie abwägen, ob Directus überhaupt zu Ihrem Projekt passt, deckt unser ehrlicher Directus-Überblick ab, wo es seine Stärken hat und wo wir etwas anderes wählen würden. Und wenn Sie externe Unterstützung in Betracht ziehen, was Sie in einem Directus-Beratungs-SOW klären sollten führt die Fragen auf, die Sie vor der Unterzeichnung beantworten sollten.

Mit Ridiculous Engineering an Directus arbeiten

Wir entwerfen und entwickeln Headless-CMS-Plattformen, einschließlich Directus-Implementierungen und Migrationen, mit Berechtigungsmodellen, die an die tatsächliche Arbeitsweise Ihres Teams angepasst sind. Für Teams, die eine verwaltete Option wünschen, wird Consus, unser verwaltetes Headless-CMS,über einen fokussierten Beta- und Beratungsprozess angeboten und nicht als Self-Service-Software. Die Preise für individuelle Arbeiten werden auf Anfrage festgelegt. Berichten Sie uns von Ihren Rollen und Ihrem Genehmigungsablauf, und wir erklären Ihnen, wie wir ihn modellieren würden.

FAQ

Was ist in Directus der Unterschied zwischen einer Rolle und einer Richtlinie?

Eine Rolle beschreibt die Position einer Person in Ihrer Organisation und kann Benutzer, Richtlinien und untergeordnete Rollen enthalten. Eine Richtlinie ist eine Gruppe von Berechtigungen, die einer Rolle oder direkt einem Benutzer zugewiesen werden kann. Gestalten Sie den Zugriff auf Grundlage von Richtlinien und verwenden Sie Rollen, um zu organisieren, wer diese erhält.

Kann ich den Zugriff mit einer zweiten Richtlinie verweigern?

Nein. Die tatsächlich geltenden Berechtigungen sind additiv, sodass ein Benutzer die Vereinigung aller Berechtigungen erhält, die seine Richtlinien erlauben. Um den Zugriff zu entfernen, lösen Sie die Zuweisung der Richtlinie, die ihn gewährt, oder bearbeiten Sie diese, anstatt eine einschränkende Richtlinie hinzuzufügen.

Wie kann ich Benutzern erlauben, nur ihre eigenen Inhalte zu bearbeiten?

Gewähren Sie Erstellungszugriff mit einer Voreinstellung, die das Autorenfeld auf $CURRENT_USERsetzt, und beschränken Sie Aktualisierung und Löschung auf Elemente, bei denen user_created gleich $CURRENT_USERist. Directus beschreibt dieses Muster in seinem React-Leitfaden zur Authentifizierung. Bei Profilbearbeitungen beschränken Sie directus_users auf id = $CURRENT_USER.

Wie sollte ich die öffentliche Rolle konfigurieren?

Lassen Sie den Zugriff standardmäßig verweigert und gewähren Sie Lesezugriff nur auf Daten, die für alle bestimmt sind. Schränken Sie diesen Zugriff durch Elementfilter ein, etwa auf den Status „veröffentlicht“, sowie durch eine Feldliste, die interne Daten ausschließt. Vermeiden Sie die Offenlegung von Systemsammlungen.

Wie kann ich prüfen, worauf ein Benutzer tatsächlich zugreifen kann?

Verwenden Sie die Permissions API, während Sie als dieser Benutzer authentifiziert sind. Sie meldet je Sammlung und Aktion keinen, teilweisen oder vollständigen Zugriff. Mit Prüfungen auf Elementebene können Sie einen bestimmten Datensatz überprüfen. Führen Sie die Prüfung nach jeder Richtlinienänderung aus.

Quellen

• Zugriffssteuerung, Dokumentation von Directus
• Bewährte Sicherheitsverfahren, Dokumentation von Directus
• Authentifizierung in React verwenden, Dokumentation von Directus
• Content-Freigabeworkflows mit benutzerdefinierten Berechtigungen erstellen, Dokumentation von Directus

Empfohlen

• Directus-Beratung: Leistungsbeschreibung, Budget und Zeitplan vor Ihrer Unterschrift
• Directus-Workflows in der Produktion: Architektur, Sicherheit und Zuverlässigkeit
• Design der rollenbasierten Zugriffskontrolle: Ein praxisnaher Leitfaden