RBAC, scoping et audit
Vérifié contre le produit le .
L’audit est traité ici, et non dans un scénario à part : chaque geste des blocs 1 à 4 y laisse une trace, et c’est en les relisant qu’on vérifie le journal.
| Domaine | Rôles, permissions, portée, et le journal d’audit qui en garde la trace |
| Durée | ~16 min |
| Niveau | complet |
| Étiquette | manuel — la vérification d’un droit se fait du point de vue de celui qui le subit, donc dans une seconde session |
Préparation
Section intitulée « Préparation »Socle B, monté par Identité et invitations — alice administratrice, bob et dave membres sans rôle.
Deux navigateurs : alice dans l’un, bob ou dave dans l’autre.
État de départ : aucun rôle Un ensemble nommé de droits, attribué à une personne pour tout l'établissement ou pour une partie seulement. personnalisé n’existe encore, et le référentiel contient les deux campus et les quatre salles du socle B.
1. Les rôles système
Section intitulée « 1. Les rôles système »Session alice → Administration → Rôles.
| # | Action | Résultat attendu |
|---|---|---|
| 1.1 | Ouvrir l’écran | cinq rôles étiquetés « Système », plus le sous-titre « Rôles système et rôles personnalisés construits à partir du catalogue de permissions. » |
| 1.2 | Tenter de modifier un rôle système | aucun bouton de modification — ils ne s’éditent pas |
| 1.3 | Compter les permissions proposées à la création | douze, et il n’existe aucun moyen d’en créer une treizième |
2. Créer et attribuer un rôle personnalisé
Section intitulée « 2. Créer et attribuer un rôle personnalisé »| # | Action | Résultat attendu |
|---|---|---|
| 2.1 | « Créer un rôle », nom « Demandeur », sans cocher aucune permission, valider | « Sélectionnez au moins une permission. » |
| 2.2 | Cocher room.book, valider |
le rôle apparaît, étiqueté « Personnalisé » |
| 2.3 | Créer de même « Valideur A » avec booking.approve |
il apparaît |
| 2.4 | Recréer un rôle nommé « Demandeur » | « Un rôle porte déjà ce nom. » |
| 2.5 | Administration → Utilisateurs → « Gérer » sur bob → attribuer « Demandeur », sans périmètre | l’attribution apparaît sous « Rôles actuels », avec « Tout l’établissement » |
| 2.6 | Chez bob, sans se reconnecter, recharger | l’entrée « Réservation » est apparue dans son menu |
| 2.7 | Révoquer le rôle chez alice, recharger chez bob | l’entrée a disparu — l’effet est immédiat |
| 2.8 | Ré-attribuer le rôle | l’entrée revient |
Ce que le bloc démontre : ce qui n’est pas permis n’existe pas à l’écran. Il n’y a ni entrée grisée, ni cadenas — la navigation est filtrée.
3. La portée
Section intitulée « 3. La portée »| # | Action | Résultat attendu |
|---|---|---|
| 3.1 | Attribuer « Valideur A » à dave, en cochant « Campus » = campus A dans « Périmètre (optionnel) » | l’attribution apparaît avec son périmètre |
| 3.2 | bob demande une salle du campus A — poser au préalable la règle « Approbation requise » sur son profil | la demande part en validation |
| 3.3 | Session dave → Validations | il voit la demande |
| 3.4 | bob demande B-201, sur le campus B | — |
| 3.5 | Session dave → Validations | il ne voit pas cette seconde demande |
| 3.6 | Session alice → Validations | elle voit les deux — son rôle n’a pas de périmètre |
| 3.7 | Comparer les compteurs de dave et d’alice | ils diffèrent |
La règle fail-closed
Section intitulée « La règle fail-closed »| # | Action | Résultat attendu |
|---|---|---|
| 3.8 | Créer une salle sans la rattacher à un campus, si le produit le permet, ou repérer une ressource dont le campus n’est pas renseigné | — |
| 3.9 | Vérifier ce que dave en voit | rien : une permission limitée à un campus ne couvre jamais une ressource dont le campus est inconnu |
Dans le doute, la réponse est non. C’est la règle la plus contre-intuitive du modèle, et la seule qui protège d’une ouverture par accident. Elle est expliquée sur Rôles.
4. Le cumul de rôles
Section intitulée « 4. Le cumul de rôles »| # | Action | Résultat attendu |
|---|---|---|
| 4.1 | Attribuer en plus à dave un rôle sans périmètre portant booking.approve |
il porte désormais deux rôles |
| 4.2 | Session dave → Validations | il voit maintenant les demandes des deux campus |
Les permissions s’additionnent, la plus large gagne. Le périmètre du premier rôle n’est pas « intersecté » avec le second : il est contourné. Retirez le second rôle avant de continuer.
5. Le journal d’audit
Section intitulée « 5. Le journal d’audit »Session alice → Administration → Journal d’audit.
| # | Action | Résultat attendu |
|---|---|---|
| 5.1 | Ouvrir l’écran, filtres à « Tous » | une timeline en français : « alice a créé Rôle », « alice a modifié Attribution de rôle », « alice s’est connecté(e) » |
| 5.2 | Filtrer sur « Type d’entité » = « Rôle » | seules les créations et modifications de rôle du bloc 2 |
| 5.3 | Filtrer sur « Action » = « Suppression » | la révocation du cas 2.7 |
| 5.4 | Ouvrir « Diff » sur une modification | « Champ », « Avant », « Après », plus le « JSON brut » |
| 5.5 | Vérifier le contenu d’une attribution de rôle | le nom du rôle et son périmètre — aucune adresse e-mail |
| 5.6 | Filtrer sur « Acteur » = alice | ses gestes seulement |
| 5.7 | « Exporter en CSV » | un fichier reprenant le résultat filtré |
| 5.8 | Se tromper de mot de passe volontairement, puis revenir au journal | une entrée « Échec de connexion » |
Ce que le journal ne contient pas
Section intitulée « Ce que le journal ne contient pas »| # | Action | Résultat attendu |
|---|---|---|
| 5.9 | Créer puis supprimer un cours ou une matière dans Pédagogie | — |
| 5.10 | Revenir au journal, filtres à « Tous » | aucune entrée ne correspond : la pédagogie n’est pas auditée |
| 5.11 | Consulter plusieurs écrans, puis revenir | aucune entrée de consultation : seules les écritures sont tracées |
Le cas 5.10 vérifie une absence, et c’est le résultat attendu. Un lecteur qui croit tout trouver dans le journal perdra du temps — mieux vaut le savoir maintenant.
Pièges connus
Section intitulée « Pièges connus »- Un rôle personnalisé sans utilisateur n’est signalé nulle part. L’écran des rôles ne compte pas les attributions ; un rôle créé « pour plus tard » ressemble à un rôle en service.
- Un périmètre vide vaut « tout l’établissement ». Laisser les deux listes vides est le réglage le plus permissif, pas le plus restrictif.
- Supprimer un rôle retire les droits immédiatement, sans avertissement pour la personne concernée.
Les pièges transverses — environnement, authentification, fraîcheur des données — sont rassemblés sur Les pièges connus.
Traçabilité
Section intitulée « Traçabilité »| Ce qui est couvert | Story | Vue |
|---|---|---|
| Catalogue de permissions, rôles système et personnalisés | STORY-004 |
V60 |
| Attribution, révocation, effet immédiat | STORY-004 |
V60 |
| Portée d’un rôle et règle fail-closed | STORY-004 |
— |
| Journal d’audit, filtres, diff, export | STORY-010 |
V62 |
| Traces d’authentification | STORY-010 |
— |
Couvert par les tests automatisés : apps/api/src/rbac/rbac.e2e.spec.ts et
apps/api/src/audit/audit.e2e.spec.ts. Le catalogue, la résolution des permissions, la sémantique
de portée et le contenu des entrées d’audit y sont couverts ; le filtrage de la navigation et
l’effet immédiat côté utilisateur ne le sont pas.
Checklist
Section intitulée « Checklist »- Cinq rôles « Système », non modifiables ; douze permissions au catalogue
- Rôle sans permission → « Sélectionnez au moins une permission. »
- Nom déjà pris → « Un rôle porte déjà ce nom. »
- Rôle attribué à bob → l’entrée « Réservation » apparaît sans reconnexion
- Rôle révoqué → l’entrée disparaît immédiatement
- dave, limité au campus A → il voit la demande du campus A, pas celle du campus B
- alice, sans périmètre → elle voit les deux
- Second rôle sans périmètre à dave → il voit les deux : le cumul est permissif
- Référentiel avec un rôle scopé → les deux campus sont visibles (le périmètre n’y est pas appliqué)
- Journal d’audit → timeline en français, filtres par acteur, entité et action
- « Diff » → « Champ », « Avant », « Après », sans adresse e-mail
- Échec de connexion volontaire → entrée « Échec de connexion »
- « Exporter en CSV » → le résultat filtré
- Cours créé puis supprimé → aucune entrée : la pédagogie n’est pas auditée
- Consultation d’écrans → aucune entrée
Écrans concernés
Section intitulée « Écrans concernés »- Rôles — les rôles, le catalogue, la règle de portée.
- Utilisateurs — l’attribution et l’éditeur de périmètre.
- Journal d'audit — le journal.
- Approbations — le seul écran où la portée mord.
- Accueil — « Vos accès », le miroir des droits.