Concevoir un RBAC à 31 permissions pour les bases de connaissances IA

Pourquoi les bases de connaissances IA ont besoin d'un vrai contrôle d'accès

Un workspace IA concentre vos connaissances opérationnelles les plus sensibles : documents internes, historiques de chat avec citations RAG, configurations d'agents et connecteurs vers des systèmes externes. Quand cette surface est ouverte à toute une entreprise, "qui peut voir quoi" cesse d'être une demande de fonctionnalité agréable et devient le même type de problème que les permissions de base de données - une décision de conception qui doit être correcte par construction.

Simmetric Chat la traite ainsi. Chaque requête authentifiée passe par un contrôle de rôle et de permission avant de toucher aux données métier, et le même modèle qui protège l'historique des chats régit aussi quelles parties de l'application un utilisateur peut même voir dans la barre latérale. Cet article détaille comment le système est conçu : les 31 permissions qui couvrent la surface des ressources de la plateforme, les 13 sections de menu qui mappent ces permissions sur l'interface utilisateur, et les protections au niveau des requêtes qui empêchent les utilisateurs authentifiés d'atteindre des enregistrements qui ne sont pas les leurs.

Le modèle de permissions : 31 permissions granulaires

Au cœur du modèle se trouve un vocabulaire fixe de 31 permissions. Chaque permission nomme une ressource et une action, selon la convention ressource:action. Les workspaces, projets, chats et documents portent chacun le triplet complet lecture/écriture/suppression, parce que ce sont les ressources que les utilisateurs créent et détruisent au cours du travail normal :

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

Autour de ce noyau se trouvent les permissions pour le flux de création lui-même (workspace:create, project:create), pour l'administration de la plateforme (admin:users, admin:settings, admin:roles), et pour lire ou configurer les fournisseurs LLM (provider:read, provider:write). Les archives reçoivent le même traitement triplet que les ressources du noyau, parce que les conversations archivées restent des données sensibles.

Un groupe de six permissions de sauvegarde sépare la gestion des destinations, l'exécution des tâches, l'inspection des journaux et les opérations de restauration - la distinction compte parce que "pouvoir déclencher une sauvegarde" et "pouvoir restaurer des données de production dans un workspace arbitraire" sont des niveaux de confiance différents. Enfin, memory:read et memory:write couvrent le système de mémoire par utilisateur et par workspace, et filters:manage gate l'administration des filtres aux administrateurs uniquement.

Les permissions sont stockées comme une table d'énumération dans la base de données et référencées par nom. Les rôles personnalisés sont assemblés en sélectionnant parmi l'ensemble des 31 permissions, si bien qu'un opérateur peut exprimer "archiviste" ou "analyste en lecture seule" sans toucher au code :

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

Deux rôles par défaut sont livrés. Le rôle admin détient les 31 permissions ; le rôle utilisateur détient un sous-ensemble de travail - accès en lecture aux workspaces et aux fournisseurs, lecture/écriture sur les chats et les documents, lecture sur les archives, création sur les workspaces et les projets, et gestion complète de ses propres mémoires. Aucun rôle n'est spécial-casé dans la logique applicative ; ce sont des lignes ordinaires que le middleware de permissions résout comme n'importe quelle autre.

Sections de menu : les permissions qui façonnent l'interface

Un contrôle d'accès qui ne protège que les routes API produit une expérience confuse - les utilisateurs cliquent sur des boutons qui échouent. Simmetric Chat mappe donc aussi les permissions sur 13 sections de menu qui contrôlent la visibilité de la barre latérale. Les sections sont l'anatomie structurelle de l'application :

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

Chaque rôle porte sa propre liste de sections de menu, stockée sous forme de chaînes pour que de nouvelles sections puissent être ajoutées sans migration de base de données. Un rôle utilisateur pourrait voir dashboard, chat, documents, knowledgeBase, workspaces, widget et uploads, tandis que le rôle admin voit les 13. Le résultat est que l'interface elle-même reflète ce que le rôle peut faire : un utilisateur sans permissions d'analytics ne rencontre jamais un point d'entrée analytics à cliquer.

Les contrôles de permission et la visibilité des menus sont deux expressions du même rôle sous-jacent, ce qui signifie qu'il existe une source de vérité unique pour raisonner lors d'un audit.

Protections au niveau des requêtes : RBAC comme middleware

Chaque requête API résout l'utilisateur avec les rôles et les permissions (avec un cache) et attache l'identité résolue à la requête. Par-dessus se trouvent quatre middleware de protection, chacun répondant à une question différente :

• requirePermission - les admins passent toujours ; tous les autres doivent détenir chaque permission listée pour la route. Les requêtes non authentifiées obtiennent 401 ; les utilisateurs authentifiés sans permissions suffisantes obtiennent 403 avec une erreur explicite "Insufficient permissions".
• requireAdmin - porte dure pour les routes administratives, répondant 403 "Admin access required" pour les non-admins.
• requireProjectAccess - un contrôle IDOR contre la propriété du projet et les lignes d'accès explicites.
• requireWorkspaceAccess - la même classe de contrôle pour les workspaces, acceptant la propriété du workspace, la propriété du projet parent ou une concession d'accès explicite.

Les deux derniers méritent l'emphase parce qu'ils traitent la classe de vulnérabilité qui afflige les systèmes multi-tenant. Une attaque IDOR (insecure direct object reference) se produit quand /api/workspaces/123 fait davantage confiance à l'identifiant dans l'URL qu'à l'identité de l'appelant. Un utilisateur authentifié - mais non autorisé pour le workspace 123 - ne doit pas pouvoir lire ses documents en devinant des identifiants. Simmetric Chat répond à ces requêtes avec 401 quand l'utilisateur n'est pas authentifié et 403 "Insufficient permissions" quand l'utilisateur manque simplement d'accès, plutôt que de fuir l'existence ou le contenu de la ressource.

La protection des routes est déclarative. Le CRUD de workspace exige requireWorkspaceAccess ; créer un workspace exige la permission workspace:create et honore les limites du plan ; l'administration des rôles vit derrière requireAdmin. La table des routes se lit comme la politique de sécurité, ce qui est exactement la propriété que vous voulez quand un nouvel ingénieur demande "que peut faire cet endpoint ?"

Pistes d'audit : savoir qui a fait quoi

Les contrôles de permission répondent "cette action devrait-elle être autorisée ?" ; les pistes d'audit répondent "que s'est-il réellement passé ?". Simmetric Chat enregistre une piste d'audit des actions significatives de la plateforme - événements d'authentification, opérations sur les documents, changements de paramètres et actions administratives - dans un journal d'événements consultable.

La combinaison est ce qui rend le RBAC opérationnel plutôt que théorique. Quand une suppression de document inattendue survient, le journal d'événements identifie l'acteur et l'action ; le modèle de permissions explique quel rôle l'a permise ; et ajuster soit les permissions d'un rôle, soit ses sections de menu ferme l'écart. La surface d'audit est elle-même protégée par permission via la section de menu eventLog, si bien que le registre de l'activité liée à la sécurité n'est visible que des rôles qui en sont jugés dignes.

Les changements sensibles de conservation - comme configurer les jours de conservation des messages de chat - sont eux-mêmes audités, donc même les contrôles qui gouvernent le cycle de vie des données laissent leur propre trace.

À quoi cela ressemble en pratique

Considérez un déploiement à trois rôles. Les administrateurs gardent l'ensemble complet des 31 permissions et les 13 sections de menu. Un rôle d'utilisateur quotidien travaille dans les chats, les documents et ses propres workspaces, et ne voit jamais le journal d'événements ni les paramètres des fournisseurs. Un auditeur de conformité obtient des permissions en lecture seule sur les documents, les chats et les archives, plus l'accès au journal d'événements - capable d'inspecter n'importe quoi, de ne rien changer.

Rien de tout cela n'a exigé de forker l'application ou d'écrire un middleware personnalisé. Il a fallu assembler des permissions en rôles et mapper des sections de menu. C'est l'objectif de conception que sert le modèle à 31 permissions : assez granulaire pour exprimer de vraies frontières organisationnelles, assez simple pour que la politique tienne dans la tête.

Pour voir le vocabulaire complet des permissions et les endpoints de gestion des rôles, lisez la référence API. Pour une visite pratique des rôles, permissions et sections de menu dans l'interface d'administration, voir le guide d'utilisation.