KI-Automatisierungsplattformen verarbeiten sensible Daten und kritische Workflows. Kundendaten fließen durch Recipe-Schritte. Finanzberichte werden erstellt und verteilt. Interne Kommunikation wird entworfen und versendet. Das Zugriffskontrollmodell muss den Anforderungen entsprechen.
„Admin oder Benutzer” reicht nicht aus. Sie brauchen einen Compliance-Beauftragten, der Audit-Logs lesen, aber nichts ausführen kann. Sie brauchen Abteilungsleiter, die die Automatisierungen ihres Teams verwalten, aber andere Abteilungen nicht berühren können. Sie brauchen klare Grenzen, die Ihrer Organisationsstruktur entsprechen, nicht einen flachen binären Schalter.
Dieser Beitrag behandelt JieGous RBAC-System: die 6-Rollen-Hierarchie, 26 granulare Berechtigungen, abteilungsbezogene Overrides und den Durchsetzungsmechanismus, der bei jedem API-Aufruf ausgeführt wird.
Die 6-Rollen-Hierarchie
Jeder Benutzer in JieGou hat eine globale Rolle — eine einzelne numerische Stufe, die seine Basisberechtigungen über das gesamte Konto bestimmt.
| Rolle | Stufe | Zweck |
|---|---|---|
| Owner | 50 | Kontoersteller. Vollzugriff einschließlich Kontolöschung. |
| Admin | 40 | Vollständige Verwaltung: Abrechnung, Benutzer, API-Schlüssel, abteilungsübergreifende Analytik. |
| Dept Lead | 30 | Abteilungsleiter. Bearbeiten/Löschen aller Inhalte in ihren Abteilungen. Packs installieren. Workflows befördern. |
| Member | 20 | Standardbenutzer. Inhalte erstellen, eigene bearbeiten, Recipes/Workflows ausführen, Zeitpläne verwalten. |
| Auditor | 15 | Lesezugriff auf Audit-Logs, Analytik, Governance. Kann nichts erstellen oder ausführen. |
| Viewer | 10 | Lesezugriff auf Inhalte. Kann nichts ausführen. |
Die numerischen Stufen sind nicht willkürlich. Sie ermöglichen O(1)-Berechtigungsprüfungen — anstatt Rollenlisten zu durchlaufen, vergleicht das System zwei Ganzzahlen. Eine Berechtigung erfordert eine Mindeststufe, und der Benutzer erreicht sie oder nicht.
Die Auditor-Rolle
Auditor ist die neueste Ergänzung, speziell für Compliance konzipiert. Sie liegt zwischen Viewer (10) und Member (20) auf Stufe 15.
Der wesentliche Unterschied zum Viewer: Auditoren erhalten die Berechtigung audit:read. Sie können auf Audit-Logs, Analytik-Dashboards und Governance-Berichte zugreifen. Viewer können das nicht.
Der wesentliche Unterschied zum Member: Auditoren können keine Inhalte erstellen, keine Recipes ausführen, keine Workflows starten oder Zeitpläne verwalten. Sie beobachten und berichten. Nichts anderes.
Das ist wichtig für regulierte Branchen. Ihr Compliance-Beauftragter muss überprüfen, dass Workflows den Richtlinien folgen, dass die Datenverarbeitung den Anforderungen entspricht und dass die Benutzeraktivität mit Ihrem Governance-Framework übereinstimmt. Er sollte nicht die Fähigkeit — und auch nicht die Berechtigung — haben, irgendetwas zu ändern oder auszuführen.
Auditoren sind im SSO-Gruppen-zu-Rollen-Mapping verfügbar, sodass Sie Compliance-Beauftragte automatisch aus Ihrem IdP bereitstellen können. Ordnen Sie Ihre Gruppe compliance-team oder internal-audit der Auditor-Rolle zu, und neue Mitarbeiter in diesen Gruppen erhalten beim ersten Login den richtigen Zugriff. Keine manuelle Rollenzuweisung erforderlich.
26 Berechtigungen in 8 Kategorien
Rollen sind Abkürzungen. Berechtigungen sind das, was tatsächlich geprüft wird. JieGou definiert 26 granulare Berechtigungen, organisiert in 8 Kategorien:
Konto (4 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
account:delete | Owner | Das gesamte Konto löschen |
account:admin | Admin | Administrative Aktionen (SSO-Konfiguration, Kontoeinstellungen) |
account:settings | Admin | Kontoweite Einstellungen verwalten |
account:billing | Admin | Abrechnung und Abonnement verwalten |
Benutzer (2 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
users:manage | Admin | Alle Benutzer kontoweit verwalten |
users:manage-department | Dept Lead | Benutzer in der eigenen Abteilung(en) verwalten |
Inhalte (6 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
content:create | Member | Neue Recipes, Workflows, Dokumente erstellen |
content:edit-own | Member | Eigene erstellte Inhalte bearbeiten |
content:edit | Dept Lead | Inhalte in der eigenen Abteilung bearbeiten |
content:edit-any | Admin | Alle Inhalte abteilungsübergreifend bearbeiten |
content:delete-any | Admin | Alle Inhalte abteilungsübergreifend löschen |
content:read | Viewer | Inhalte lesen (Recipes, Workflows, Dokumente) |
Ausführung (3 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
execution:run | Member | Recipes und Workflows ausführen |
execution:schedules | Member | Geplante Ausführungen erstellen und verwalten |
execution:triggers | Member | Ereignisgesteuerte Trigger konfigurieren |
Analytik (2 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
analytics:read-department | Auditor | Analytik für eigene Abteilung(en) lesen |
analytics:read-all | Admin | Analytik abteilungsübergreifend lesen |
Features (4 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
features:chat | Member | Die KI-Chat-Schnittstelle nutzen |
features:documents | Member | Wissensdatenbank-Dokumente verwalten |
features:packs | Dept Lead | Abteilungs-Packs installieren und verwalten |
features:connectors | Admin | MCP-Connectors und Integrationen konfigurieren |
Governance (3 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
governance:audit | Auditor | Audit-Logs und Governance-Berichte lesen |
governance:environments | Dept Lead | Deployment-Umgebungen verwalten |
governance:promote | Dept Lead | Workflows zwischen Umgebungen befördern |
Sicherheit (2 Berechtigungen)
| Berechtigung | Min. Rolle | Beschreibung |
|---|---|---|
security:byok | Admin | Bring-Your-Own-Key-API-Schlüssel verwalten |
security:embedded-api | Admin | Die eingebettete API konfigurieren |
Die Zuordnung von Rolle zu Berechtigungen ist statisch. Ein Dept Lead (Stufe 30) hat automatisch jede Berechtigung mit einer Minimalrolle von 30 oder darunter. Keine benutzerspezifischen Berechtigungs-Overrides, keine benutzerdefinierten Rollendefinitionen. Dies hält das Modell auditierbar — Sie können die Rolle eines Benutzers ansehen und genau wissen, was er kann und was nicht.
Abteilungsbezogene Rollen-Overrides
Eine globale Rolle gilt überall. Aber Organisationen sind nicht flach. Ein Produktmanager könnte Member-Zugriff global benötigen, aber Dept-Lead-Zugriff in der Produktabteilung, um die Automatisierungen seines Teams zu verwalten.
Abteilungsbezogene Overrides lösen dies. Ein Benutzer hat eine globale Rolle plus null oder mehr abteilungsspezifische Rollen-Overrides.
Beispiel: Sarah ist global Member. Sie hat einen Dept Lead-Override in der Vertriebsabteilung. Im Vertrieb kann sie alle Inhalte bearbeiten, Packs installieren und Workflows befördern. Im Engineering ist sie ein Standard-Member — sie kann nur ihre eigenen Inhalte bearbeiten.
Das kritische Designprinzip: Overrides können nur erhöhen, nie reduzieren. Wenn Sie ein globaler Admin mit einem Viewer-Override im Engineering sind, ist Ihre effektive Rolle im Engineering immer noch Admin. Der Override wird ignoriert, weil er den Zugriff reduzieren würde. Dies verhindert, dass ein falsch konfigurierter Override jemanden versehentlich aus einer Abteilung aussperrt, auf die er Zugriff haben sollte.
Effektive Rollenauflösung
Wenn das System bestimmen muss, was ein Benutzer in einer bestimmten Abteilung tun kann, führt es diese Auflösung durch:
- Prüfen, ob ein Abteilungs-Override für diesen Benutzer in dieser Abteilung existiert
- Wenn ein Override existiert, den höheren Wert von globaler Rolle und Override zurückgeben
- Wenn kein Override existiert, die globale Rolle zurückgeben
In Pseudocode:
effectiveRole(user, department):
override = getDepartmentOverride(user, department)
if override exists:
return max(user.globalRole, override.role)
return user.globalRoleAbteilungsbezogene Berechtigungsprüfungen verwenden diese effektive Rolle. Wenn Sarah versucht, ein Pack im Vertrieb zu installieren, löst das System ihre effektive Rolle im Vertrieb auf (Dept Lead, Stufe 30), prüft die Mindeststufe für features:packs (30) und gewährt Zugriff. Wenn sie dasselbe im Engineering versucht, ist ihre effektive Rolle Member (20), was unter der erforderlichen Stufe liegt.
Anti-Eskalationsregeln
Rollenänderungen sind die sicherheitssensibelste Operation im System. Vier Regeln verhindern Privilegien-Eskalation:
-
Sie können Ihre eigene Rolle nicht ändern. Keine Selbstbeförderung. Ein Admin, der Owner werden möchte, braucht einen anderen Owner, der die Änderung vornimmt.
-
Sie können die Owner-Rolle nicht zuweisen. Owner-Transfer ist eine separate, bewusste Operation mit eigenen Sicherheitsvorkehrungen. Sie erfolgt nicht über die Standard-Rollenänderungs-API.
-
Sie können keine Rolle zuweisen, die größer oder gleich Ihrer eigenen ist (es sei denn, Sie sind Owner). Ein Admin (40) kann Dept Lead (30), Member (20), Auditor (15) oder Viewer (10) zuweisen. Er kann nicht Admin (40) oder Owner (50) zuweisen. Nur der Owner kann andere Admins erstellen.
-
Sie können die Rolle von jemandem mit einer Rolle, die größer oder gleich Ihrer eigenen ist, nicht ändern (es sei denn, Sie sind Owner). Ein Admin kann die Rolle eines anderen Admins nicht ändern. Ein Dept Lead kann die Rolle eines Admins nicht ändern. Die Hierarchie wird strikt nach oben durchgesetzt.
Diese Regeln wirken zusammen. Kombiniert garantieren sie, dass kein Benutzer seine eigenen Privilegien oder die seiner Peers eskalieren kann — nur der Owner steht außerhalb dieser Einschränkung.
Wie Berechtigungen durchgesetzt werden
Jede API-Route in JieGou durchläuft einen dreistufigen Auth-Guard, bevor Geschäftslogik ausgeführt wird:
Schritt 1: Session-Cookie verifizieren. Das Session-Token aus dem HTTP-Cookie wird gegen Firebase Auth validiert. Das Ergebnis wird in Redis mit einer 5-Minuten-TTL gecacht, sodass wiederholte Anfragen derselben Session nicht bei jedem Aufruf Firebase Auth ansprechen.
Schritt 2: AccountUser-Datensatz nachschlagen. Die Kontomitgliedschaft des Benutzers — einschließlich seiner globalen Rolle und Abteilungs-Overrides — wird aus Firestore geladen. Dies wird ebenfalls in Redis mit einer 5-Minuten-TTL gecacht.
Schritt 3: Berechtigung gegen Rollenhierarchie prüfen. Die erforderliche Berechtigung wird auf ihre Minimalrollenstufe abgebildet. Die effektive Rolle des Benutzers (unter Berücksichtigung von Abteilungs-Overrides, wenn die Prüfung abteilungsbezogen ist) wird damit verglichen. Dies ist O(1) — ein einzelner Hash-Lookup zur Bestimmung der Mindeststufe plus ein numerischer Vergleich.
Keine Datenbankabfragen zum Zeitpunkt der Berechtigungsprüfung. Kein Durchlaufen von Berechtigungslisten. Zwei gecachte Lookups und ein Ganzzahlvergleich.
Ressourcen-Level-Prüfungen
Über rollenbasierte Berechtigungen hinaus haben individuelle Ressourcen (Recipes, Workflows, Dokumente) eigentümerbasierte Zugriffsregeln:
- Owner, Admin, Dept Lead — können jede Ressource in ihrem Bereich ändern
- Member — können nur Ressourcen ändern, die sie erstellt haben
- Auditor, Viewer — können keine Ressource ändern
Dies kombiniert sich mit Rollen-Level-Berechtigungen. Ein Member mit content:edit-own kann nur Ressourcen bearbeiten, bei denen resource.createdBy === user.id. Ein Dept Lead mit content:edit kann jede Ressource in seiner Abteilung bearbeiten, unabhängig davon, wer sie erstellt hat.
Integration mit Plattform-Features
RBAC ist nicht isoliert — es verbindet sich mit jedem wichtigen Plattform-Subsystem:
Genehmigungsschritte. Die Genehmigungsberechtigung respektiert die Rollenhierarchie. Sie können einen Genehmigungsschritt so konfigurieren, dass eine Mindestrolle erforderlich ist — zum Beispiel nur Dept Lead oder höher kann Workflow-Ausgaben genehmigen, bevor sie in Produktion gehen.
Lauf-Sichtbarkeit. Workflow-Läufe haben 4 Sichtbarkeitsbereiche: privat (nur der Ausführende), Abteilung (jeder in derselben Abteilung), Gruppe (angegebene Gruppen) und Konto (alle). RBAC bestimmt, wer Laufergebnisse sehen kann und wer nicht.
Umgebungsbeförderung. Verschiedene Umgebungen (Entwicklung, Staging, Produktion) können verschiedene Mindestrollen erfordern. Entwicklung erlaubt möglicherweise Member-Level-Beförderung. Produktion erfordert möglicherweise Admin. RBAC kontrolliert jeden Übergang.
Governance-Reporting. Das Governance-Dashboard zeigt die Rollenverteilung über das Konto, die Anzahl der pro Benutzer zugänglichen Ressourcen und die Berechtigungsnutzung. Auditoren können diese Daten überprüfen, um sicherzustellen, dass Zugriffsmuster den Richtlinien entsprechen.
Verfügbarkeit
RBAC ist in allen Tarifen verfügbar. Jedes JieGou-Konto erhält die vollständige 6-Rollen-Hierarchie und 26 Berechtigungen. Abteilungsbezogene Overrides und die Auditor-Rolle sind in Team- und Enterprise-Tarifen verfügbar. Alle Features erkunden oder kostenlose Testversion starten.