Un client modifie le dossier d’une autre société en changeant un identifiant dans l’URL. Un prestataire conserve son compte administrateur après la fin de sa mission. Un agent du support ouvre un export complet alors qu’il devait seulement vérifier un statut. Le risque est concret même si toutes les personnes sont correctement authentifiées.
Le défaut se situe dans l’autorisation. L’application sait qui agit, mais elle ne vérifie pas avec assez de précision ce que cette identité peut faire, sur quelle ressource, pour quelle organisation et dans quel contexte. Un bouton masqué ou un rôle nommé « externe » ne constitue pas une règle de sécurité.
Le vrai enjeu est de transformer les responsabilités métier en décisions exécutables sur chaque requête. Une application métier sur mesure doit refuser par défaut, contrôler le périmètre des données côté serveur, borner les privilèges dans le temps et produire une trace exploitable lorsqu’une action sensible est autorisée.
La séparation robuste ne consiste pas à créer toujours plus de rôles. Elle combine une identité fiable, quelques capacités compréhensibles, un périmètre de ressources et des conditions. Le modèle reste assez simple pour être relu par le métier, mais assez précis pour empêcher qu’un client, un prestataire et une équipe interne héritent des mêmes pouvoirs.
Séparer identité, rôle et périmètre
L’authentification établit l’identité ou un niveau de confiance ; l’autorisation décide si l’action demandée est permise. Une session valide ne donne aucun droit implicite sur toutes les fonctions. Cette distinction doit apparaître dans le code, les tests et les messages d’erreur.
Le rôle décrit une responsabilité générale : gestionnaire client, technicien prestataire, agent support ou administrateur sécurité. Le périmètre précise les objets concernés : une organisation, un établissement, un contrat, un projet ou un portefeuille. La condition ajoute le contexte, comme la durée de mission, le statut du dossier ou une approbation préalable.
La décision complète ressemble donc à : cette identité peut-elle exécuter cette action sur cette ressource maintenant ? Si l’application ne connaît qu’un rôle global, elle répond mal dès qu’une personne travaille pour plusieurs clients ou cumule plusieurs missions.
Inventorier ressources et actions
Le travail commence par les objets métier, pas par les écrans. Pour chaque ressource — commande, facture, document, utilisateur, configuration — l’équipe liste lecture, création, modification, validation, export, suppression et administration. Deux boutons proches peuvent porter des risques très différents.
La matrice relie ensuite chaque action aux responsabilités et aux périmètres. Elle précise aussi les interdictions structurelles : un demandeur ne valide pas sa propre demande ; un prestataire ne crée pas son propre accès ; un agent support ne modifie pas les données financières qu’il consulte pour diagnostiquer.
L’inventaire inclut API, traitements asynchrones, fichiers, recherche et administration. Une fonction absente de l’interface peut rester accessible par une route directe ou un export. Le contrôle porte sur la capacité réelle du système, jamais sur sa seule présentation.
Cloisonner les organisations clientes
Dans un produit multi-organisation, l’appartenance au client doit provenir de la session ou d’une relation serveur fiable. Le backend ne fait pas confiance à un identifiant d’organisation envoyé par le navigateur pour décider du périmètre. Il vérifie que l’utilisateur appartient réellement à l’organisation et que la ressource demandée relève de celle-ci.
Le cloisonnement est appliqué à toutes les lectures et écritures. Une recherche globale, un compteur, une pièce jointe ou un endpoint de téléchargement peut révéler une information même si la fiche principale est protégée. Les agrégations et les messages d’erreur demandent donc la même attention que les écrans de détail.
Une personne rattachée à plusieurs sociétés choisit un contexte explicite, mais ce choix ne lui accorde rien de nouveau. Le changement d’organisation modifie le périmètre actif parmi ses appartenances déjà validées. Les caches et files de fond conservent ce contexte pour éviter les fuites entre locataires.
Limiter les équipes internes à leur mission
Le mot « interne » ne justifie pas un accès global. Le support a besoin de diagnostiquer, la finance de rapprocher des paiements, les opérations de corriger certains états et la sécurité d’enquêter. Ces missions n’exigent ni les mêmes données ni les mêmes actions.
Le principe du moindre privilège réduit le coût d’un compte compromis et celui d’une erreur humaine. Les droits de lecture eux-mêmes sont segmentés lorsque les données sont sensibles. Voir un nom, télécharger un justificatif et exporter toute une base sont trois capacités distinctes.
La séparation des tâches protège les opérations irréversibles ou fraudogènes. Par exemple, la même personne ne devrait pas créer un bénéficiaire puis valider seule son paiement. L’application matérialise cette règle dans le workflow au lieu de compter sur une consigne orale.
Borner les accès des prestataires
Le compte prestataire est nominatif, rattaché à un sponsor interne, à une mission et à une date de fin. Les comptes partagés empêchent d’attribuer une action et compliquent la révocation. Même une intervention brève mérite une identité distincte.
Le périmètre correspond au besoin réel : environnement, projet, type de ressource et créneau éventuel. Un développeur chargé d’une intégration n’a pas automatiquement besoin des données de production. Un mainteneur peut consulter des journaux expurgés avant d’obtenir une élévation temporaire sur un incident précis.
La fin de mission déclenche la révocation des sessions, jetons, clés, groupes et délégations associés. La fermeture contractuelle ne prouve pas la fermeture technique. Une vérification indépendante confirme que l’identité ne peut plus accéder au système.
Choisir rôles, attributs et relations
Garder des rôles peu nombreux
Le contrôle par rôles convient aux responsabilités stables. Chaque rôle regroupe des capacités cohérentes et compréhensibles. Si un nouveau rôle apparaît pour chaque exception individuelle, la matrice devient illisible et personne ne sait plus comparer deux utilisateurs.
Les exceptions temporaires sont représentées séparément avec un motif et une expiration. Cette distinction permet de revoir le socle sans confondre droits normaux et dérogations. Elle évite aussi qu’une permission spéciale survive à un changement de poste.
Ajouter attributs et relations là où ils comptent
Les attributs expriment le contexte : organisation, région, niveau de sensibilité, heure ou statut de mission. Les relations expriment la proximité métier : propriétaire du dossier, membre du projet, délégataire ou responsable hiérarchique. Elles évitent de multiplier les rôles pour chaque combinaison.
Le modèle hybride reste explicable. Une règle peut dire : les gestionnaires de l’organisation peuvent modifier un dossier non clôturé, sauf s’ils en sont les demandeurs. Cette phrase devient une politique testée plutôt qu’une succession de conditions dispersées.
Contrôler chaque requête côté serveur
Masquer un bouton améliore l’expérience, pas la sécurité. La route, le contrôleur ou le service applicatif vérifie l’autorisation avant l’action. Le contrôle est exécuté pour chaque requête, y compris appels API, tâches déclenchées depuis l’interface et téléchargements directs.
La règle par défaut est le refus. Une nouvelle action reste inaccessible tant qu’une permission explicite ne l’autorise pas. Cette position suit les recommandations de l’OWASP sur les autorisations, qui insiste également sur la vérification de chaque requête et sur les tests automatisés.
Le contrôle s’effectue au plus près de la règle métier partagée. Le placer uniquement dans chaque contrôleur favorise les oublis lorsqu’une nouvelle API ou une commande interne réutilise le même service. L’interface peut demander « que puis-je afficher ? », mais la décision finale reste serveur.
Appliquer le périmètre à la couche de données
Une permission de type « lire les commandes » ne suffit pas : la requête doit aussi limiter les lignes à l’organisation autorisée. Le filtre est construit à partir du contexte de sécurité, jamais d’un champ libre envoyé par l’utilisateur. Cette règle réduit le risque d’accès horizontal par manipulation d’identifiant.
Les entrées portent l’identité, l’action et l’objet demandé ; les sorties ne contiennent que les champs autorisés. Le contrat d’autorisation garde la responsabilité de la décision, tandis que la journalisation enregistre la règle et le résultat. Ces dépendances sont communes aux pages, API et traitements différés.
Les tâches asynchrones reçoivent un contexte minimal et vérifié. Elles ne réutilisent pas aveuglément les privilèges du worker. Si une action a été autorisée pour un utilisateur et une organisation, ce périmètre est conservé ou recalculé au moment de l’exécution selon la règle métier.
Protéger aussi exports et documents
Un export cumule les risques : volume élevé, données faciles à copier et contrôle souvent différent de celui des écrans. L’autorisation vérifie le périmètre au moment de la demande et, pour les traitements longs, avant la remise du fichier. Un lien signé possède une durée courte et ne doit pas élargir les droits.
Les pièces jointes ne sont pas protégées par une URL difficile à deviner. Le téléchargement passe par un contrôle serveur ou un mécanisme signé lié à la ressource autorisée. Les aperçus, miniatures et versions archivées respectent la même politique.
Le fichier produit contient uniquement les colonnes nécessaires. Une permission d’export peut être distincte de la lecture écran, demander une justification ou une approbation selon le volume et la sensibilité. La trace conserve demandeur, périmètre, motif, volume et résultat.
Renforcer les actions sensibles
Modifier des coordonnées bancaires, attribuer un rôle privilégié, effacer des données ou valider un paiement demande davantage qu’une session ancienne. L’application peut exiger une réauthentification, un second facteur, une confirmation du contenu exact ou une approbation séparée.
Le niveau de protection dépend de l’impact et de la réversibilité. Une validation à deux personnes n’est pas utile partout ; elle l’est lorsque la fraude ou l’erreur d’un seul compte aurait une conséquence majeure. Le workflow interdit aussi l’auto-approbation.
Contre-intuitivement, donner un rôle administrateur permanent « pour aller plus vite » ralentit souvent les incidents. L’équipe doit ensuite déterminer quelles actions étaient légitimes, révoquer un périmètre trop large et reconstruire la preuve. Une élévation courte et ciblée simplifie l’enquête.
Encadrer délégation et assistance
Le support a parfois besoin de reproduire ce que voit un client. L’usurpation silencieuse de session est à éviter. Une délégation explicite indique l’agent, le client assisté, le motif, l’heure de début, la durée et les actions interdites.
L’interface montre clairement le contexte assisté et permet de le quitter. Les actions effectuées sous délégation portent l’identité de l’agent et celle du compte représenté. Le client ou un responsable peut être informé pour les interventions sensibles.
La délégation ne contourne pas les séparations fortes. Un agent qui peut consulter un dossier ne peut pas forcément signer, payer ou modifier un droit au nom du client. Les capacités disponibles en assistance forment un sous-ensemble explicite.
Séparer humains et comptes techniques
Une intégration utilise une identité de service, pas le compte d’un salarié. Cette identité possède un responsable, un usage, un environnement, un périmètre et une rotation de secret. Son nom permet de comprendre immédiatement le système appelant.
Les entrées et sorties attendues sont définies dans le contrat technique ; la file, les webhooks et les retries conservent un identifiant de corrélation. La journalisation distingue l’action automatique de l’utilisateur qui l’a éventuellement déclenchée. Un seuil d’échec active le repli sans accorder de privilège supplémentaire au worker.
Les secrets ne sont pas copiés dans le code, les tickets ou les messages. Un gestionnaire central les distribue et permet leur révocation. La durée de vie courte réduit l’exposition, mais elle suppose de tester le renouvellement et le comportement en cas d’expiration.
Automatiser arrivée, mobilité et départ
L’arrivée attribue des droits à partir d’une responsabilité validée, pas en copiant le compte d’un collègue. Le manager ou sponsor confirme le besoin, et les privilèges sensibles reçoivent une approbation dédiée. L’utilisateur comprend les limites de son accès.
Un changement de mission exige une revue complète. Ajouter les nouveaux droits sans retirer les anciens crée une dérive cumulative. Le système rapproche régulièrement poste, groupes, délégations et exceptions pour repérer les incohérences.
Le départ révoque sessions et facteurs, transfère les responsabilités métier et conserve les traces selon leur règle. La CNIL recommande notamment de supprimer les permissions dès la fin de l’habilitation et de revoir régulièrement les droits dans son guide de sécurité des données personnelles.
Préparer un accès d’urgence
Une panne critique peut nécessiter un privilège exceptionnel. Le compte d’urgence n’est ni partagé au quotidien ni laissé ouvert. Son utilisation demande un motif, une authentification forte, une durée courte et une alerte immédiate aux responsables.
Les actions sont enregistrées et revues après l’incident. Le secret est renouvelé, les sessions sont fermées et les changements réalisés sont rapprochés du ticket. Cette procédure rend l’accès possible sans transformer l’urgence en permission permanente.
Le test fait partie du plan de continuité. Un compte théorique dont personne ne connaît le mécanisme ou dont le secret a expiré ne protège pas l’exploitation. Le test vérifie aussi que le mode normal redevient obligatoire après la clôture.
Journaliser sans surveiller inutilement
La trace doit répondre à une enquête : qui a demandé quoi, sur quelle ressource, dans quel contexte, quelle règle a décidé et quel résultat a suivi. Les refus sensibles sont utiles pour détecter une exploration ou une mauvaise configuration, mais tous les événements ne méritent pas la même alerte.
Les journaux sont eux-mêmes protégés. Ils peuvent contenir identifiants, objets consultés et informations sur l’activité des personnes. La recommandation de la CNIL sur la journalisation rappelle l’intérêt de la traçabilité tout en demandant de proportionner analyse, accès et conservation.
Une trace inutilisée n’apporte qu’un coût de stockage et un risque supplémentaire. Les scénarios de détection ont un responsable, un seuil et une procédure : série de refus inter-organisations, export inhabituel, élévation hors créneau ou compte prestataire utilisé après son échéance.
Tester les refus autant que les autorisations
La matrice d’autorisation devient un jeu de tests. Pour chaque capacité, l’équipe vérifie au moins un utilisateur autorisé, un rôle non autorisé, une ressource d’une autre organisation, un état métier incompatible et une session expirée. Les tests négatifs cherchent ce qui doit rester impossible.
Les contrôles couvrent interface et API. Changer l’identifiant, appeler directement la route, modifier la méthode HTTP, rejouer un jeton ou demander un export doit aboutir au même refus cohérent. La réponse ne révèle pas inutilement l’existence d’une ressource étrangère.
Un test d’intégration vérifie la politique avec la base réelle, les filtres et les événements. Les tests unitaires valident les règles pures ; les scénarios de bout en bout prouvent que le câblage n’a pas oublié une entrée. Une revue manuelle complète la couverture sur les chemins complexes.
Détecter la dérive des privilèges
Les premiers signaux faibles sont les rôles sans propriétaire, les exceptions sans expiration, les comptes jamais utilisés, les groupes attribués directement et les refus contournés par le support. Ils apparaissent avant l’incident et doivent alimenter une revue régulière.
Les indicateurs utiles incluent comptes externes actifs après échéance, privilèges sensibles non utilisés, délégations ouvertes, changements de rôle sans ticket et taux d’échec des campagnes de revue. Un nombre élevé de refus peut signaler une attaque, mais aussi une interface incohérente ou une politique mal comprise.
Le seuil déclenche une action connue : révocation automatique, demande de justification, revue par le sponsor ou enquête sécurité. Mesurer sans fermer la boucle laisse la dérive continuer sous un tableau de bord rassurant.
Traiter un cas concret de portail client
Le besoin initial et sa faille
Cas concret. Un portail réunit clients, consultants d’intégration et agents internes. Le premier modèle prévoit trois rôles globaux. Pendant la recette, un consultant rattaché à deux déploiements peut télécharger un document d’un troisième projet en devinant son identifiant ; la route vérifie son rôle, pas sa relation au projet.
L’équipe reformule la règle autour de la ressource. Le consultant peut lire les documents des projets auxquels sa mission active le rattache, sauf les pièces classées « client uniquement ». Le client voit les projets de son organisation ; le support peut consulter les métadonnées mais demande une délégation pour le contenu.
La preuve avant ouverture
La politique centrale reçoit identité, action, projet et classification. Les requêtes de données appliquent l’organisation et la relation au projet ; le téléchargement contrôle de nouveau la permission. Une batterie de tests permute rôles, organisations, projets, états et types de document.
Le go est refusé si un identifiant étranger renvoie un contenu, si une mission expirée fonctionne encore ou si un export dépasse le périmètre de l’écran. La décision d’ouverture s’appuie sur ces résultats et sur une révocation testée, pas sur la présence des trois rôles dans l’administration.
Identifier les projets concernés
Cette méthode est indispensable pour les portails B2B multi-clients, extranets, back-offices, espaces partenaires et applications manipulant des données sensibles. Elle devient prioritaire dès qu’une personne peut appartenir à plusieurs organisations ou intervenir temporairement pour une autre.
Le product owner formule les responsabilités et les interdictions, le responsable sécurité fixe les exigences, les développeurs centralisent les décisions et l’exploitation gère le cycle de vie. Le DPO intervient sur les données personnelles et la proportionnalité des traces, sans porter seul toute la sécurité.
Pour une application simple, le modèle peut rester modeste : quelques rôles, un périmètre d’organisation et des tests systématiques. La complexité n’est ajoutée que lorsqu’une relation ou une condition métier réelle l’exige.
Éviter les erreurs fréquentes
- Faire confiance à l’interface : masquer une action n’empêche pas l’appel direct de l’API.
- Utiliser un rôle « admin » universel : il efface les responsabilités et rend les incidents difficiles à analyser.
- Accepter le locataire envoyé par le client : le périmètre doit être dérivé d’une relation vérifiée côté serveur.
- Oublier les traitements différés : exports, webhooks et workers doivent conserver ou recalculer l’autorisation.
- Ne tester que les parcours permis : la sécurité se prouve surtout par des refus sur les mauvais objets et états.
- Révoquer seulement le compte principal : sessions, jetons, clés, groupes et délégations doivent disparaître ensemble.
Une faute plus subtile consiste à donner au support un accès total pour résoudre les exceptions du modèle. Le produit masque alors ses règles insuffisantes derrière une équipe privilégiée. Les motifs de contournement doivent enrichir le modèle, pas installer un second système informel.
Enfin, une matrice figée vieillit. Nouveaux écrans, changements d’organisation et missions temporaires créent des écarts. La revue des politiques fait partie du cycle produit, avec des propriétaires et des tests de non-régression.
Mettre les droits sous contrôle en six semaines
Semaines 1 à 3 : définir et centraliser
La première semaine recense identités, organisations, ressources et actions sensibles. Les responsables métier décrivent les permissions et les séparations de tâches en phrases lisibles. L’équipe identifie les routes, exports, documents et traitements asynchrones qui échappent aujourd’hui au contrôle commun.
La deuxième semaine construit une matrice minimale avec refus par défaut, rôles stables, périmètres et exceptions expirables. Chaque règle possède un propriétaire et un exemple autorisé ou refusé. Les comptes prestataires reçoivent sponsor et échéance ; les comptes techniques sont séparés des personnes.
La troisième semaine centralise la décision dans la couche serveur et applique le périmètre à la donnée. Les routes prioritaires passent par la politique, les identifiants d’organisation ne sont plus fiables par eux-mêmes et les sorties sensibles sont filtrées. Les changements sont livrés par lots réversibles pour ne pas bloquer tout le produit.
Semaines 4 à 6 : prouver et exploiter
La quatrième semaine transforme la matrice en tests négatifs. Chaque rôle tente une action légitime, une action interdite et un accès à une autre organisation. Les exports, téléchargements et files sont inclus. Toute divergence reçoit une responsabilité, un seuil de correction et une preuve de fermeture.
La cinquième semaine raccorde arrivée, mobilité, départ, délégation et accès d’urgence. L’équipe provoque une fin de mission et vérifie la révocation des sessions, jetons et clés. Elle teste aussi le rollback d’une politique défectueuse sans rouvrir les données à tous.
La sixième semaine active les journaux et alertes réellement exploitables. Le comité décide : étendre si les refus et révocations sont prouvés, limiter si certaines fonctions restent isolées, ou replier si une fuite inter-organisation demeure possible. La première revue des droits est datée et attribuée avant la clôture du chantier.
- Étendre uniquement lorsque toute route sensible partage la même décision serveur et ses tests.
- Limiter le périmètre lorsqu’une intégration ou un export ne sait pas encore conserver le contexte d’autorisation.
- Replier immédiatement si un compte expiré, un objet étranger ou une élévation non tracée reste accessible.
Approfondir rôles, traces et back-office
Concevoir le modèle et sa preuve
Pour détailler la frontière entre rôle stable et permission contextuelle, la gestion fine des rôles et permissions complète la méthode. La preuve des actions peut ensuite être structurée avec la journalisation et la traçabilité métier.
Ces deux chantiers doivent avancer ensemble. Une politique sans trace rend l’enquête fragile ; une trace sans politique documentée n’explique pas pourquoi l’action a été autorisée.
Protéger les surfaces qui grandissent
Les documents demandent un traitement spécifique décrit dans la protection des pièces jointes sensibles. Lorsque l’administration s’étend, les erreurs de sécurité d’un back-office en croissance aide à repérer les contrôles oubliés.
Le résultat attendu reste le même : chaque action sensible possède une décision serveur, un périmètre, une preuve et une procédure de révocation. La multiplication des écrans ne doit pas multiplier les règles concurrentes.
Conclusion : autoriser une action précise
Séparer clients, prestataires et équipes internes ne revient pas à poser trois étiquettes. Il faut relier une identité, une capacité, une ressource, une organisation et un contexte, puis refuser toute combinaison non prévue.
Le contrôle robuste vit côté serveur et accompagne la donnée jusqu’aux exports, documents, files et comptes techniques. Sa qualité se mesure par les refus corrects, la révocation effective et la capacité à expliquer une action sensible.
Les droits restent ainsi proches des responsabilités réelles sans devenir une matrice infinie. Les rôles portent le stable ; les attributs, relations et échéances portent ce qui varie.
Un accompagnement expert peut vous aider à cadrer ce modèle dans votre application web métier, à le tester sur les parcours critiques et à l’exploiter sans privilèges permanents cachés.
