Un utilisateur voit le bouton « exporter » mais reçoit un refus incompréhensible. Un responsable régional obtient un rôle national parce qu’aucun périmètre intermédiaire n’existe. Un administrateur ne sait plus pourquoi une permission a été ajoutée ni qui la retire. Ces symptômes apparaissent quand les droits deviennent une accumulation de cases, de conditions dans les contrôleurs et d’exceptions connues de quelques personnes.
Le risque ne vient pas seulement d’un accès trop large. Une matrice illisible ralentit chaque évolution, augmente la charge support et pousse les équipes à contourner les contrôles. La sécurité se dégrade alors des deux côtés : certains comptes conservent trop de pouvoirs, d’autres ne peuvent plus réaliser leur travail et partagent un compte privilégié pour avancer.
Le vrai enjeu est de représenter une décision métier avec assez de précision pour protéger chaque ressource, mais avec assez de stabilité pour être relue, testée et administrée. Une application métier développée sur mesure gagne à séparer ce que la personne peut faire, sur quel périmètre et sous quelles conditions plutôt qu’à créer un rôle pour chaque combinaison.
Contre-intuitivement, davantage de granularité ne donne pas toujours davantage de contrôle. Si mille permissions ne sont ni possédées ni testées, elles masquent les écarts. Les seuils de revue, durées d’élévation et nombres de rôles évoqués ici sont à décider localement selon les risques, l’organisation et les capacités d’exploitation ; ils ne constituent pas des normes universelles.
Identifier la vraie complexité des permissions
La complexité utile provient du métier : plusieurs organisations, séparation des tâches, dossiers attribués, actions irréversibles ou délégations temporaires. La complexité accidentelle provient de l’implémentation : noms incohérents, décisions dispersées, rôles copiés, périmètres encodés dans l’interface et correctifs individuels sans expiration. Les deux ne se traitent pas de la même manière.
L’inventaire part des ressources et des actions réelles. Pour une facture, consulter, corriger une référence, exporter, valider et annuler sont des capacités différentes. Pour chaque capacité, l’équipe identifie l’impact, les responsabilités incompatibles et le périmètre possible. Cette carte révèle qu’un « administrateur » global cache souvent plusieurs missions qui devraient être séparées.
Séparer capacité, périmètre et condition
Une capacité décrit un verbe métier sur une ressource : valider une commande, inviter un membre, télécharger un justificatif. Le périmètre décrit les objets concernés : sa propre organisation, les agences de sa région, les dossiers affectés ou un projet précis. La condition complète la règle : dossier ouvert, montant sous délégation, authentification récente ou approbation distincte.
Cette séparation évite des noms qui mélangent toutes les dimensions. La décision devient : l’identité possède-t-elle la capacité, la ressource appartient-elle à son périmètre et les conditions sont-elles réunies ? Le vocabulaire se partage avec le métier et se transforme en tests sans exposer la structure technique à l’utilisateur.
Construire un catalogue de capacités stable
Le catalogue utilise des noms orientés intention, indépendants de la position d’un bouton ou d’une route. « contract.approve » reste compréhensible si l’écran change ; « cliquer sur bouton vert » ne l’est pas. Chaque entrée possède une description, un propriétaire métier, un niveau de sensibilité et les incompatibilités connues.
Une capacité est ajoutée lorsque l’action porte une responsabilité ou un risque distinct, pas à chaque détail d’interface. Lire une fiche et lire son historique peuvent rester ensemble si leur exposition est identique ; télécharger toutes les fiches mérite souvent une capacité séparée. L’équipe revoit le catalogue lors d’une évolution majeure et déprécie explicitement les entrées, au lieu de les laisser survivre dans des conditions mortes.
Composer des rôles sans les multiplier
Un rôle regroupe des capacités correspondant à une responsabilité reconnue : gestionnaire client, opérateur facturation, responsable régional ou support niveau deux. Il sert de modèle d’attribution, pas de décision complète. Le même rôle peut s’appliquer à des périmètres différents sans être cloné pour chaque région ou client.
Le nombre acceptable dépend de l’organisation. Un signal faible apparaît lorsque deux administrateurs ne savent plus expliquer la différence entre des rôles proches, ou quand une évolution impose d’en modifier des dizaines. Dans ce cas, l’équipe rapproche les rôles par responsabilité, retire les doublons et déplace les variantes dans les périmètres ou conditions. La priorité reste la lisibilité, pas un nombre théorique.
Sortir les exceptions du socle
Une permission accordée pour un incident, un remplacement ou un projet ne doit pas devenir une ligne permanente dans le rôle commun. L’exception porte un bénéficiaire, une capacité, un périmètre, un motif, un approbateur et une expiration. Elle est visible séparément dans l’administration afin qu’une revue distingue le fonctionnement nominal des dérogations.
La durée est proportionnée au besoin et choisie localement. Une élévation de quelques heures peut convenir à une intervention ; une délégation de plusieurs semaines peut être nécessaire pour un congé. Le système expire automatiquement l’accès et ferme les sessions concernées. Si la mission continue, alors une nouvelle décision explicite vaut mieux qu’une prolongation silencieuse.
Cloisonner les organisations dans chaque requête
Dans un portail multi-tenant, le rôle ne suffit jamais. Un gestionnaire peut consulter des factures, mais uniquement celles des organisations auxquelles il est rattaché. Le serveur calcule ce périmètre depuis des relations fiables ; il ne fait pas confiance à un identifiant d’entreprise fourni par le navigateur pour décider de l’accès.
Le filtre s’applique aux détails, listes, compteurs, recherches, fichiers et traitements asynchrones. Une fuite se produit souvent dans un endpoint secondaire qui a réutilisé une capacité sans le périmètre. Les caches incluent donc le tenant et les workers transportent un contexte minimal signé ou recalculent la décision avant l’effet sensible.
Centraliser la décision côté serveur
L’interface peut demander quelles actions afficher, mais elle ne constitue pas une barrière. Chaque requête serveur vérifie la capacité, la ressource et le contexte. Le refus par défaut protège les nouvelles routes : tant qu’aucune politique ne les autorise, elles restent inaccessibles. Cette position suit les recommandations de l’OWASP sur le contrôle des autorisations.
La décision vit dans un composant partagé, proche du domaine, plutôt que dans chaque contrôleur. Ses entrées sont l’identité, l’action, la ressource et le contexte ; sa sortie est autorisé ou refusé avec un code de motif interne. Les dépendances — annuaire, relations, délégations — sont explicites. La journalisation et le monitoring mesurent latence, erreurs et refus sans transformer une indisponibilité en autorisation.
Appliquer l’autorisation jusque dans les données
Vérifier un objet après l’avoir chargé peut déjà révéler son existence par un temps de réponse ou un message. Pour les listes et recherches, le périmètre doit contraindre la requête. Les repositories ou providers reçoivent un contexte d’accès et produisent uniquement les lignes admissibles. Un résultat vide ne permet pas de distinguer l’absence d’objet d’un objet étranger.
Les colonnes sensibles demandent parfois une politique supplémentaire. Un agent peut lire le statut d’un dossier sans voir les coordonnées bancaires. Les exports reconstruisent une projection autorisée plutôt que sérialiser l’entité complète. Cette approche évite qu’un nouveau champ devienne automatiquement visible dans tous les canaux.
Rendre l’administration des droits compréhensible
L’écran d’administration répond à trois questions : quels droits cette personne détient-elle, d’où viennent-ils et quand changent-ils ? Il distingue rôle de base, périmètres, appartenance à un groupe, délégation et exception directe. Une vue « droits effectifs » explique la combinaison sans obliger l’administrateur à recalculer mentalement l’héritage.
Avant une attribution sensible, l’interface affiche les capacités ajoutées et les conflits de séparation des tâches. La confirmation exige un motif lorsque le risque le justifie. Les actions en masse offrent un aperçu et un rapport ; elles ne réutilisent pas aveuglément le résultat d’une personne pour une autre. Le support voit un code de refus actionnable, tandis que l’utilisateur reçoit une explication non sensible.
Piloter le cycle de vie des habilitations
L’arrivée attribue un rôle depuis une responsabilité validée. La mobilité retire les droits précédents avant ou en même temps qu’elle ajoute les nouveaux. Le départ révoque sessions, jetons, délégations et appartenances, puis transfère les dossiers qui ont encore un propriétaire métier. Copier les accès d’un collègue accélère le démarrage mais reproduit aussi ses anomalies.
Une revue périodique compare responsables, comptes actifs, rôles et exceptions. Sa cadence dépend du niveau de risque et du rythme de changement. Plutôt que demander « faut-il garder ce rôle ? », elle présente les capacités, le dernier usage pertinent et le propriétaire. Une absence d’usage n’entraîne pas automatiquement la suppression, mais signale une décision à instruire.
Expliquer une décision sans exposer les règles
Une trace d’autorisation conserve identité, action, ressource, résultat, politique et identifiant de corrélation. Pour une attribution, elle ajoute auteur, bénéficiaire, périmètre, motif et expiration. Elle n’enregistre ni secret, ni document complet, ni détail qui permettrait de contourner un contrôle. L’accès aux traces est lui-même protégé.
La version de politique permet de reconstituer le verdict même après une évolution. Le runbook indique comment rechercher un refus, comparer les sources et corriger une appartenance. Une hausse de refus peut révéler une régression, une attaque ou un changement métier mal accompagné ; un seuil n’a donc de sens qu’avec une baseline locale et une action associée.
Tester les refus et les frontières
Les tests positifs prouvent qu’un gestionnaire peut effectuer son travail. Les tests négatifs prouvent qu’il ne peut pas agir sur l’organisation voisine, contourner une étape ou utiliser une route directe. Pour chaque capacité sensible, la matrice de test combine identité, rôle, périmètre, état de ressource et résultat attendu.
Les propriétés sont utiles : changer seulement le tenant doit transformer une autorisation en refus ; retirer une délégation doit fermer tous les chemins ; un bouton caché et un appel API manuel doivent aboutir au même verdict. La recette inclut exports, fichiers, jobs et caches. Elle provoque aussi l’indisponibilité d’une dépendance : si le service de politique ne répond pas, alors l’action sensible reste refusée et la reprise est visible.
Migrer une matrice existante sans rupture
Une refonte brutale des droits risque de bloquer l’exploitation. L’équipe extrait d’abord rôles, attributions et usages observés, puis construit une correspondance vers le nouveau catalogue. Les règles anciennes et nouvelles peuvent fonctionner en mode comparaison : la nouvelle décision est journalisée sans être appliquée, et les divergences sont qualifiées.
Les écarts se classent en droit manquant, droit excessif, source incohérente ou cas métier non décrit. Le basculement se fait par population ou capacité, avec un feature flag et un rollback. Les écritures sensibles passent en premier si leur périmètre est maîtrisé ; les cas ambigus restent sur l’ancien moteur jusqu’à décision. Aucun double moteur ne doit devenir permanent.
Arbitrer un cas concret de portail B2B
Un portail pilote dessert huit filiales et trois prestataires. Le rôle « manager » comporte vingt-sept permissions, mais deux filiales ont cloné ce rôle pour masquer des menus et un prestataire dispose du rôle administrateur afin de traiter les incidents. À la première revue, personne ne sait dire si la modification de RIB est incluse par nécessité ou par héritage.
L’équipe crée des capacités métier, rattache les managers à un périmètre de filiale et sépare la modification financière de la consultation. Le prestataire obtient une délégation limitée aux dossiers assignés et une élévation approuvée pour l’incident. Pour ce pilote, une exception dépassant sept jours déclenche une revue ; cette valeur correspond à la cadence de l’équipe, pas à une règle générale.
La comparaison tourne pendant deux semaines sur ce périmètre. Si une divergence touche une écriture financière, alors le basculement est bloqué jusqu’à validation ; un écart d’affichage non sensible peut rejoindre le lot suivant. La décision repose sur les scénarios rejoués, le nombre d’exceptions expliquées et la capacité du support à diagnostiquer un refus sans accès à la base.
Savoir quand ce modèle devient nécessaire
Cette séparation convient particulièrement aux portails multi-organisations, back-offices à plusieurs métiers, applications avec délégation ou produits qui exposent une API. Elle devient urgente lorsque les rôles portent des noms de personnes, lorsque les équipes demandent régulièrement un rôle supérieur « temporaire » ou lorsque le frontend contient plus de logique d’accès que le serveur.
Un outil interne simple peut rester sur quelques rôles si les risques et périmètres le permettent. Ajouter un moteur de politique distribué serait alors une dette inutile. Le bon arbitrage consiste à adopter le modèle conceptuel avant l’infrastructure : capacités claires, périmètres contrôlés et exceptions expirables peuvent vivre dans une architecture monolithique parfaitement lisible.
Erreurs fréquentes des matrices de droits ingérables
- Créer un rôle par personne. Les responsabilités communes disparaissent et chaque correction devient individuelle.
- Mettre le périmètre dans le nom du rôle. Les combinaisons explosent dès qu’une personne couvre plusieurs zones.
- Contrôler seulement l’écran. API, export et téléchargement restent atteignables sans bouton.
- Ajouter sans retirer. La mobilité accumule des pouvoirs incompatibles au fil des postes.
- Refuser sans motif interne. Le support transforme chaque incident de droit en enquête manuelle.
- Automatiser une matrice non possédée. Le provisioning propage plus vite des décisions que personne ne sait valider.
Décider entre rôle, attribut et relation
Le rôle convient à une responsabilité stable partagée par plusieurs personnes. L’attribut convient à un contexte déjà maîtrisé, comme la filiale, la région ou le niveau de sensibilité. La relation convient lorsque le droit dépend du lien à l’objet : propriétaire, membre du projet, délégataire. L’exception convient à un besoin nominatif et temporaire.
Si une règle demande un rôle pour chaque client, alors déplacer le client dans le périmètre. Si elle dépend du demandeur et du valideur, alors représenter la relation et la séparation des tâches. Si une exception revient chaque mois, alors arbitrer si elle révèle une responsabilité permanente. La décision doit rester formulable en une phrase métier et testable avec quelques exemples contradictoires.
Plan d’action : stabiliser les droits en six semaines
Semaines 1 et 2 : inventorier et nommer
Le produit choisit deux parcours sensibles et liste ressources, actions, rôles actuels, périmètres et exceptions. Le métier nomme le propriétaire de chaque capacité ; la sécurité qualifie l’impact. Les entrées viennent des configurations, du code et des usages, pas uniquement de la documentation. La sortie est un catalogue court avec les inconnues, les incompatibilités et les populations pilotes.
Semaines 3 et 4 : implémenter et comparer
Le développement centralise la décision, applique le périmètre dans les requêtes et ajoute la journalisation de politique. Le contrat précise entrées, sortie, responsabilités, dépendances, monitoring et comportement de repli. La comparaison avec l’ancien moteur alimente une file d’écarts ; un retry traite les dépendances momentanément indisponibles sans convertir l’erreur en accès autorisé.
Semaines 5 et 6 : recetter et basculer
Les utilisateurs pilotes jouent autorisations, refus, changement de périmètre, élévation et révocation. Le support exécute le runbook, puis l’équipe mesure les écarts et les corrections manuelles. Le rollback conserve l’ancien verdict pour la population non migrée. Les seuils de go sont décidés avant la recette et adaptés au risque des actions.
Le comité rapproche alors les refus inexpliqués, les exceptions encore ouvertes et les décisions réellement exercées. Une action sensible ne bascule que si ses cas positifs et négatifs sont signés par le métier. Les droits sans propriétaire restent à différer ; les écarts à faible impact rejoignent un lot daté plutôt qu’un correctif silencieux. Cette règle protège la reprise et donne au support une source unique.
- D’abord, nommer capacités et propriétaires ; à refuser si une permission sensible n’a aucun décideur métier.
- Ensuite, tester tenant, état et relation ; si le périmètre n’est pas appliqué aux données, alors bloquer le basculement.
- Puis, rapprocher anciens et nouveaux verdicts et documenter chaque divergence avant de l’accepter.
- Enfin, ouvrir par population, conserver un rollback et élargir seulement lorsque support et métier expliquent les refus.
Relier permissions, sécurité et exploitation
La séparation des accès externes et internes prolonge la réflexion sur délégation, comptes techniques et urgence. Elle permet de vérifier que le modèle reste cohérent lorsque plusieurs populations partagent la même application.
Pour les traces et la reprise, l’observabilité des workflows métier aide à distinguer décision, effet et incident. Le NIST décrit la fédération d’identité, utile lorsque les attributs arrivent d’un fournisseur externe mais ne doivent pas devenir aveuglément des autorisations locales.
- Relire les capacités avec leurs propriétaires et leurs actions incompatibles.
- Contrôler les périmètres sur écrans, API, exports et traitements différés.
- Tester la révocation et le diagnostic support avant chaque extension de population.
Conclusion : garder une règle explicable
Une permission utile n’est pas la plus fine possible. C’est celle qui exprime une responsabilité, s’applique au bon périmètre, expire lorsqu’elle est exceptionnelle et produit le même verdict sur l’écran, l’API et les traitements différés.
Commencer par deux parcours réels permet de découvrir les rôles clonés, les périmètres implicites et les refus impossibles à diagnostiquer. Le catalogue, les tests contradictoires et la comparaison progressive réduisent le risque sans imposer une réécriture brutale.
Dawap peut cadrer ce modèle avec vos métiers, sécuriser sa migration et intégrer les contrôles à votre architecture. Nous transformons les responsabilités en politiques maintenables, écrans d’administration et runbooks dans une application web métier sur mesure.
