31-Berechtigungs-RBAC für KI-Wissensdatenbanken entwerfen

Warum KI-Wissensdatenbanken echte Zugriffskontrolle brauchen

Ein KI-Workspace konzentriert Ihr sensibelstes operatives Wissen: interne Dokumente, Chat-Verläufe mit RAG-Zitaten, Agentenkonfigurationen und Verbindungen zu externen Systemen. Wenn diese Oberfläche einem ganzen Unternehmen offensteht, hört „wer was sehen kann" auf, eine nette Feature-Anfrage zu sein, und wird zur gleichen Problemklasse wie Datenbankberechtigungen - eine Designentscheidung, die von Konstruktion an korrekt sein muss.

Simmetric Chat behandelt es genau so. Jede authentifizierte Anfrage durchläuft eine Rollen- und Berechtigungsprüfung, bevor sie Geschäftsdaten berührt, und dasselbe Modell, das den Chat-Verlauf schützt, regiert auch, welche Teile der Anwendung ein Benutzer überhaupt in der Seitenleiste sehen kann. Dieser Artikel zeigt, wie das System aufgebaut ist: die 31 Berechtigungen, die die Ressourcenoberfläche der Plattform abdecken, die 13 Menüabschnitte, die diese Berechtigungen auf die Benutzeroberfläche abbilden, und die anfrageebenen Guards, die authentifizierte Benutzer davon abhalten, Datensätze zu erreichen, die nicht ihre sind.

Das Berechtigungsmodell: 31 granulare Berechtigungen

Im Kern des Modells steht ein fester Wortschatz von 31 Berechtigungen. Jede Berechtigung benennt eine Ressource und eine Aktion nach der ressource:action-Konvention. Workspaces, Projekte, Chats und Dokumente tragen jeweils das volle Lese-/Schreib-/Lösch-Triplett, weil dies die Ressourcen sind, die Benutzer im normalen Arbeitsablauf erstellen und zerstören:

• workspace:read, workspace:write, workspace:delete
• project:read, project:write, project:delete
• chat:read, chat:write, chat:delete
• document:read, document:write, document:delete

Um diesen Kern herum sitzen Berechtigungen für den Erstellungsfluss selbst (workspace:create, project:create), für die Plattformadministration (admin:users, admin:settings, admin:roles) und für das Lesen oder Konfigurieren von LLM-Providern (provider:read, provider:write). Archive erhalten dieselbe Triplett-Behandlung wie die Kernressourcen, weil archivierte Unterhaltungen weiterhin sensible Daten sind.

Ein Cluster von sechs Backup-Berechtigungen trennt Zielverwaltung, Job-Ausführung, Log-Inspektion und Wiederherstellungsoperationen - die Trennung zählt, weil „ein Backup auslösen können" und „Produktionsdaten in einen beliebigen Workspace wiederherstellen können" unterschiedliche Vertrauensstufen sind. Schließlich decken memory:read und memory:write das Speichersystem pro Benutzer und pro Workspace ab, und filters:manage gate die Filteradministration nur für Administratoren.

Berechtigungen werden als Enum-Tabelle in der Datenbank gespeichert und per Name referenziert. Benutzerdefinierte Rollen werden durch Auswahl aus dem 31-Berechtigungssatz zusammengestellt, sodass ein Operator „Archivar" oder „nur-lesender Analyst" ausdrücken kann, ohne Code anzufassen:

{
"name": "archivist",
"permissions": ["workspace:read", "document:read", "archive:read", "chat:read"]
}

Zwei Standardrollen werden mitgeliefert. Die Admin-Rolle hält alle 31 Berechtigungen; die Benutzerrolle hält ein Arbeits-Subset - Lesezugriff auf Workspaces und Provider, Lesen/Schreiben auf Chats und Dokumenten, Lesen auf Archiven, Erstellen auf Workspaces und Projekten sowie volle Verwaltung der eigenen Speicher. Keine Rolle ist in der Anwendungslogik spezialbehandelt; beide sind gewöhnliche Zeilen, die das Berechtigungs-Middleware wie jede andere auflöst.

Menüabschnitte: Berechtigungen, die die Oberfläche formen

Zugriffskontrolle, die nur API-Routen schützt, erzeugt eine verwirrende Erfahrung - Benutzer klicken auf Schaltflächen, die fehlschlagen. Simmetric Chat bildet Berechtigungen daher auch auf 13 Menüabschnitte ab, die die Seitenleisten-Sichtbarkeit steuern. Die Abschnitte sind die strukturelle Anatomie der Anwendung:

dashboard, chat, documents, knowledgeBase, workspaces, projects, marketplace, mcpConnections, eventLog, analytics, widget, settings und uploads.

Jede Rolle trägt ihre eigene Menüabschnittsliste, als Strings gespeichert, damit neue Abschnitte ohne Datenbankmigration hinzugefügt werden können. Eine Benutzerrolle könnte dashboard, chat, documents, knowledgeBase, workspaces, widget und uploads sehen, während die Admin-Rolle alle 13 sieht. Das Ergebnis ist, dass die Oberfläche selbst widerspiegelt, was die Rolle kann: Ein Benutzer ohne Analytics-Berechtigungen begegnet nie einem Analytics-Einstiegspunkt zum Klicken.

Berechtigungsprüfungen und Menü-Sichtbarkeit sind zwei Ausdrücke derselben zugrunde liegenden Rolle, was bedeutet, dass es eine einzige Quelle der Wahrheit gibt, über die man bei einem Audit nachdenken kann.

Anfrageebenen-Guards: RBAC als Middleware

Jede API-Anfrage löst den Benutzer zusammen mit Rollen und Berechtigungen auf (mit Cache) und hängt die aufgelöste Identität an die Anfrage. Darüber sitzen vier Middleware-Guards, jeder beantwortet eine andere Frage:

• requirePermission - Admins passieren immer; alle anderen müssen jede gelistete Berechtigung für die Route halten. Nicht authentifizierte Anfragen erhalten 401; authentifizierte Benutzer ohne ausreichende Berechtigungen erhalten 403 mit einem expliziten „Insufficient permissions"-Fehler.
• requireAdmin - harte Sperre für administrative Routen, antwortet mit 403 „Admin access required" für Nicht-Admins.
• requireProjectAccess - ein IDOR-Check gegen Projektbesitz und explizite Zugriffszeilen.
• requireWorkspaceAccess - dieselbe Prüfklasse für Workspaces, akzeptiert Workspace-Besitz, Eltern-Projekt-Besitz oder eine explizite Zugriffsgewährung.

Die letzten beiden verdienen Betonung, weil sie die Verwundbarkeitsklasse behandeln, die Multi-Tenant-Systeme plagt. Ein IDOR-Angriff (insecure direct object reference) passiert, wenn /api/workspaces/123 dem Bezeichner in der URL mehr vertraut als der Identität des Aufrufers. Ein Benutzer, der authentifiziert - aber für Workspace 123 nicht autorisiert - ist, darf seine Dokumente nicht durch Raten von Bezeichnern lesen können. Simmetric Chat beantwortet solche Anfragen mit 401, wenn der Benutzer nicht authentifiziert ist, und 403 „Insufficient permissions", wenn dem Benutzer schlicht der Zugriff fehlt, statt die Existenz oder den Inhalt der Ressource preiszugeben.

Der Routenschutz ist deklarativ. Workspace-CRUD erfordert requireWorkspaceAccess; das Erstellen eines Workspace erfordert die workspace:create-Berechtigung und respektiert Planlimits; die Rollenadministration liegt hinter requireAdmin. Die Routentabelle liest sich wie die Sicherheitspolitik, genau die Eigenschaft, die man will, wenn ein neuer Ingenieur fragt „was kann dieser Endpunkt?"

Audit-Pfade: wissen, wer was getan hat

Berechtigungsprüfungen beantworten „sollte diese Aktion erlaubt sein?"; Audit-Pfade beantworten „was ist tatsächlich passiert?". Simmetric Chat zeichnet einen Audit-Pfad bedeutender Plattformaktionen auf - Authentifizierungsereignisse, Dokumentoperationen, Einstellungsänderungen und administrative Aktionen - in einem durchsuchbaren Ereignisprotokoll.

Die Kombination macht RBAC operativ statt theoretisch. Wenn eine unerwartete Dokumentlöschung passiert, identifiziert das Ereignisprotokoll den Akteur und die Aktion; das Berechtigungsmodell erklärt, welche Rolle sie erlaubt hat; und die Anpassung entweder der Berechtigungen einer Rolle oder ihrer Menüabschnitte schließt die Lücke. Die Audit-Oberfläche ist selbst berechtigungsgesperrt über den eventLog-Menüabschnitt, sodass das Protokoll sicherheitsrelevanter Aktivität nur für Rollen sichtbar ist, denen es anvertraut wurde.

Sensible Aufbewahrungsänderungen - wie das Konfigurieren der Chat-Nachrichten-Aufbewahrungstage - werden selbst auditiert, sodass sogar die Kontrollen, die den Datenlebenszyklus regieren, ihre eigene Spur hinterlassen.

Wie das in der Praxis aussieht

Betrachten Sie eine Drei-Rollen-Bereitstellung. Administratoren behalten den vollen 31-Berechtigungssatz und alle 13 Menüabschnitte. Eine Tagesnutzer-Rolle arbeitet in Chats, Dokumenten und ihren eigenen Workspaces und sieht nie das Ereignisprotokoll oder die Provider-Einstellungen. Ein Compliance-Prüfer erhält Leseberechtigungen auf Dokumenten, Chats und Archiven plus Zugriff auf das Ereignisprotokoll - fähig, alles zu inspizieren, nichts zu ändern.

Nichts davon erforderte das Forken der Anwendung oder das Schreiben benutzerdefinierter Middleware. Es erforderte, Berechtigungen zu Rollen zu assemblen und Menüabschnitte zu mappen. Das ist das Designziel, dem das 31-Berechtigungsmodell dient: fein genug, um echte organisatorische Grenzen auszudrücken, einfach genug, dass die Politik in den Kopf passt.

Um das vollständige Berechtigungsvokabular und die Rollenverwaltungs-Endpunkte zu sehen, lesen Sie die API-Referenz. Für eine praktische Tour durch Rollen, Berechtigungen und Menüabschnitte in der Admin-Oberfläche siehe den Benutzungsleitfaden.