Un responsable d’agence ouvre une facture et découvre les achats d’une autre filiale. Un technicien change l’identifiant du site dans l’URL et accède à un équipement voisin. L’interface masquait pourtant les menus concernés. L’incident révèle une autorisation construite dans les écrans, pas une politique appliquée à chaque ressource.
Les applications B2B ne se limitent pas à « administrateur » et « utilisateur ». Une personne peut consulter tous les sites d’un compte, commander pour deux agences, valider seulement sous un plafond et voir des documents différents selon l’entité légale. Les relations évoluent avec les mutations, délégations et contrats.
Le problème coûte au-delà de la sécurité : un faux refus bloque une commande et mobilise le support, tandis qu’un faux accord expose prix, documents ou données personnelles. Les équipes compensent souvent par des exports et comptes partagés, ce qui augmente encore le risque et rend toute attribution fragile.
Le vrai enjeu est de décider si ce sujet peut réaliser cette action sur cette ressource, dans ce contexte, puis d’expliquer le refus. Le rôle seul décrit une capacité générale ; le périmètre relie l’utilisateur à l’objet. Toute route, API, export et traitement différé doit poser la même question.
Dans une mission de développement web sur mesure, les droits deviennent un contrat du domaine et du run. Cette méthode aide à le fermer sans multiplier les exceptions codées à la main.
Partir du risque de périmètre
Inventoriez les décisions sensibles : voir un tarif, télécharger une facture, créer une commande, approuver une demande, inviter un collègue ou exporter des données. Pour chacune, identifiez la conséquence d’un faux accord et d’un faux refus. Les contrôles se renforcent selon l’exposition, pas selon la position du bouton.
Rejouez les incidents et contournements : comptes partagés, droits conservés après départ, export trop large, délégation orale, correction support. Le signal faible est souvent une demande récurrente d’accès « temporaire » sans date de fin ni propriétaire. Mesurez ces exceptions avant de choisir un modèle.
Écrire des scénarios négatifs
Les exigences incluent explicitement ce qui doit être refusé : utilisateur d’une autre filiale, ancien administrateur, site fermé, objet déplacé, document avant sa date, action au-dessus du plafond. Cette matière devient la base de la recette et des tests automatiques.
Nommer sujets et ressources
Le sujet est une identité authentifiée avec organisation, rôles, relations et attributs fiables. La ressource est un objet métier : commande, contrat, facture, site, équipement ou document. L’action reste un verbe du domaine. Le contexte porte instant, canal, niveau d’authentification et parfois montant.
Ne confondez pas propriétaire technique et bénéficiaire métier. Une facture appartient à une entité de facturation, concerne un compte et peut être visible par plusieurs sites. La règle doit suivre ces relations. Ajouter simplement un champ utilisateur sur chaque ligne ne représente pas le partage ni les responsabilités.
Stabiliser les identifiants
Utilisez des identifiants internes sans signification et des aliases par source. Une mutation de site ne recrée pas l’utilisateur ; elle change une relation datée. Les anciennes décisions restent interprétables avec le périmètre qui s’appliquait au moment de l’action.
Modéliser compte, site et filiale
La hiérarchie organisationnelle n’est pas toujours un arbre. Un site peut servir plusieurs comptes, une équipe régionale traverser deux filiales et une centrale acheter pour des adhérents indépendants. Modélisez les relations autorisées avec type, période et source, plutôt qu’un unique parent récursif supposé universel.
L’héritage de droit reste explicite. « Gérer la filiale » peut couvrir ses sites actifs, sans donner accès aux factures de la maison mère. Une nouvelle entité n’hérite de rien par accident. La création exécute une politique de rattachement et produit un journal des droits générés.
Séparer structure et regroupement analytique
Une région commerciale ou un portefeuille peut servir les filtres sans devenir une frontière de sécurité. Les regroupements analytiques changent souvent et proviennent d’autres sources. Les utiliser comme autorité d’accès ouvre ou ferme des ressources lors d’un simple reclassement.
Gérer les ressources partagées
Un contrat cadre ou un site commun peut appartenir à plusieurs entités sans donner accès à tout leur contenu. Modélisez un partage ciblé avec type de ressource, actions autorisées, participants, début et fin. La politique évalue ce lien avant l’héritage ordinaire. Une nouvelle pièce jointe ne récupère le partage que si sa classification l’autorise ; les documents financiers peuvent rester réservés malgré le dossier commun.
Lorsqu’un objet change de propriétaire, distinguez le transfert futur de l’accès historique. La nouvelle filiale gère les opérations à partir de la date d’effet ; l’ancienne conserve éventuellement une lecture limitée sur ses décisions passées. La migration produit une liste des relations créées et révoquées. Une balance vérifie qu’aucune ressource ne perd tout propriétaire ni ne devient visible aux deux périmètres sans règle.
Combiner rôles et attributs
Le contrôle par rôles attribue des capacités compréhensibles : lecteur, acheteur, valideur, administrateur de compte. Les attributs précisent le contexte : filiale, sites autorisés, montant, type de document, relation au dossier. La relation avec la ressource complète l’ensemble.
Le guide NIST SP 800-162 sur l’ABAC décrit un contrôle où les décisions évaluent les attributs du sujet, de l’objet, de l’opération et de l’environnement. N’ajoutez ces dimensions que si leur source, leur fraîcheur et leur sémantique sont maîtrisées.
Limiter l’explosion des rôles
Évitez « valideur-site-Paris-5000-euros ». Gardez le rôle valideur, une relation au site et un plafond attribué. Les compositions restent lisibles et les changements n’obligent pas à créer un nouveau rôle. Un catalogue de rôles possède propriétaire, description et usages.
Écrire des politiques explicables
Une politique commence par refus par défaut, puis énonce les conditions d’accord. Exemple : un acheteur peut lire une commande si son compte est lié, si le site fait partie de son périmètre actif et si le document n’est pas restreint à la finance. Le résultat porte la règle et les attributs utilisés.
L’Authorization Cheat Sheet d’OWASP insiste sur le moindre privilège, le refus par défaut et la validation de permission à chaque requête. Ces principes s’appliquent aussi aux téléchargements, appels internes et traitements asynchrones.
Distinguer absence de droit et ressource absente
La réponse publique évite de révéler l’existence d’un objet inaccessible. Le journal interne conserve la cause exacte. L’interface présente une action de demande d’accès seulement si ce workflow est autorisé, sans donner de détails sur le contenu protégé.
Versionner et relire les politiques
Chaque décision conserve la version de politique, pas une copie intégrale du code. Une évolution passe sur un corpus de scénarios avant activation. Comparez accords et refus entre versions, puis faites signer les changements attendus. Les divergences inconnues restent en observation. Ce mode permet de déployer une nouvelle règle progressivement et de revenir à la version précédente sans réinterpréter les accès déjà journalisés.
La revue périodique part des relations effectives : utilisateurs sans connexion récente, rôles orphelins, délégations longues et comptes de service trop larges. Le responsable confirme, réduit ou retire. Une campagne d’attestation ne se limite pas à envoyer une liste illisible ; elle présente ressource, capacité, origine et dernière utilisation. Le silence n’est pas traité comme une approbation lorsqu’un droit sensible arrive à échéance.
Cas concret : responsable multi-sites
Un groupe possède douze sites dans trois filiales. Marie administre les utilisateurs de la filiale France, commande pour quatre sites et valide jusqu’à 20 000 euros sur deux d’entre eux. Elle peut consulter les factures France mais pas les conditions négociées par la maison mère.
Le modèle attribue trois relations datées et deux capacités, sans rôle sur mesure. Une demande de 24 000 euros passe au valideur groupe. Si Marie change de région, les relations futures sont créées avec date d’effet et les anciennes expirent. Les sessions sont réévaluées sur les actions sensibles.
Le pilote utilise vingt identités et cent cinquante ressources, puis exécute trois cents tests positifs et négatifs. Le go local exige zéro accès croisé, zéro délégation sans fin et une explication de refus depuis l’identifiant de corrélation. Le seuil répond à ce périmètre à forte exposition ; il ne constitue pas un taux générique.
Encadrer invitation et délégation
L’administrateur local ne peut inviter que dans son périmètre et attribuer un sous-ensemble de ses capacités délégables. Une invitation porte compte, rôle proposé, émetteur, expiration et usage unique. L’acceptation vérifie l’identité avant de créer la relation.
Une délégation comporte délégant, bénéficiaire, actions, ressources, début, fin et motif. Elle ne propage pas automatiquement le droit d’administrer. Les délégations longues sont revues. Une révocation coupe sessions ou jetons concernés et invalide les caches de décision.
Traiter les comptes de service
Une intégration possède sa propre identité, un secret renouvelable et un périmètre minimal. Elle n’emprunte pas le compte d’un salarié. Les actions portent l’identité technique et, si pertinent, l’acteur métier d’origine pour distinguer exécution et décision.
Centraliser la décision d’accès
Les entrées sont sujet, action, ressource, contexte et version attendue ; la sortie est accord ou refus, règle, obligations et corrélation. Un service de politique ou une couche domaine centralise l’évaluation. Les contrôleurs, commandes et workers l’appellent au plus près de l’action réelle.
Les dépendances sont annuaire, graphe de relations et attributs métier. Leur fraîcheur possède un seuil. La journalisation conserve décision sans recopier les secrets. Le monitoring suit refus par règle, accès anormaux, caches, erreurs de résolution et délégations expirées. Le retry reste idempotent ; le rollback restaure la politique précédente avec version.
Un contrat de décision fixe les entrées obligatoires, le résultat, les codes de refus et les obligations comme masquage ou authentification renforcée. Le cache inclut sujet, action, ressource, attributs déterminants et version de politique ; sa durée ne dépasse pas le délai de révocation accepté. Une notification d’invalidation ferme plus vite les sessions sensibles. Si l’annuaire ou le graphe ne répond pas, la politique applique le comportement décidé par action, généralement le refus pour les écritures exposées.
Les entrées de contrôle sont normalisées dans un fichier de cas : sujet, relations, ressource, contexte et résultat attendu. Les sorties de chaque version sont comparées avant déploiement. La responsabilité de validation revient au propriétaire métier du droit, tandis que la sécurité vérifie les invariants. Les dépendances et seuils sont injectés explicitement. La journalisation retient règle et corrélation ; le monitoring déclenche une alerte sur dérive. Le rollback et le retry sont joués avec une requête idempotente pour exclure toute autorisation résiduelle.
Prévenir les contournements techniques
Les requêtes en base appliquent un filtre de périmètre ou vérifient chaque objet avant sérialisation. Les exports et recherches utilisent la même politique. Une URL signée ne remplace pas le droit si elle peut circuler. Les tests statiques et revues cherchent les lectures directes qui évitent la couche d’autorisation.
Observer refus et accès sensibles
Le journal d’accès contient sujet, action, ressource, résultat, règle, contexte minimal et corrélation. Il protège les valeurs sensibles et sa durée est définie. Les accès à des documents financiers, changements d’administrateur et exports volumineux reçoivent une surveillance proportionnée.
Contre-intuitivement, une hausse des refus après déploiement peut signaler un système plus sain : les contournements sont enfin bloqués. Analysez la cause, l’action suivante et les faux refus. Une alerte sans procédure devient du bruit ; chaque signal ouvre une investigation bornée.
Pour qui cette démarche est nécessaire
Elle est prioritaire pour les portails multi-comptes, réseaux de sites, groupes de filiales et applications où documents, tarifs ou validations sont sensibles. Produit, sécurité, métier, développeurs, QA et support doivent partager le vocabulaire des ressources et des relations.
Une petite application mono-organisation peut commencer par des rôles simples, à condition de vérifier côté serveur. Ajoutez attributs et relations lorsque les frontières réelles l’exigent. La sophistication n’est pas un objectif ; l’explication et le moindre privilège le sont.
Erreurs fréquentes d’autorisation
Vérifier seulement le rôle
Le rôle autorise une capacité générale, pas toutes les ressources. Ajoutez le lien au compte, au site ou au dossier. Les tests doivent changer l’identifiant demandé sans changer l’utilisateur.
Faire confiance au front
Un bouton masqué améliore l’expérience, jamais la sécurité. API, fichier, export et worker vérifient indépendamment. Le client ne fournit pas un périmètre considéré comme vrai.
Accumuler les exceptions nominatives
Les listes de personnes codées dans une règle ne vieillissent pas correctement. Modélisez relation, durée et propriétaire. Une exception urgente reçoit une fin et une revue.
Décision : choisir le bon niveau
Priorisez les ressources qui exposent argent, données personnelles, prix ou administration. Commencez par des rôles si les périmètres sont simples. Ajoutez relations pour compte et site ; ajoutez attributs lorsque montant, période ou propriété changent réellement la décision. Refusez toute règle dont l’attribut n’a pas de source fiable.
Si le faux accord est grave, alors bloquez quand le contexte manque. En revanche, une lecture non sensible peut attendre une resynchronisation bornée. À éviter : autoriser par défaut lors d’une panne du service de politique.
- Commencer par les actions et ressources sensibles.
- Documenter relations, attributs, héritage et délégation.
- Tester les refus croisés sur chaque interface.
- Élargir après observation des faux accords et faux refus.
Plan d’action sur cinq semaines
Semaines un et deux : cartographier et écrire
Choisissez dix actions sensibles. Nommez sujets, ressources et relations. Rejouez incidents et demandes d’accès. Construisez la matrice rôle-action, puis ajoutez compte, site, filiale, montant et période seulement où ils changent la décision. Écrivez vingt scénarios négatifs.
Définissez invitation, délégation, révocation et comptes techniques. Attribuez les sources d’attributs et leurs délais. Fermez les réponses publiques, le journal et les obligations. Préparez un jeu de données avec relations croisées et objets déplacés.
Semaines trois à cinq : centraliser et perturber
Implémentez le point de décision sur un domaine. Branchez pages, API, export et worker. Ajoutez corrélation, métriques et version de politique. Provoquez attribut absent, cache ancien, site fermé, session active après révocation et URL manipulée.
Faites jouer l’administration locale et la délégation par le métier. Le support explique cinq refus et révoque un accès sans base de données. Comparez décisions attendues et observées, puis cherchez les chemins qui lisent encore sans contrôle.
Activez un compte pilote. Examinez accès croisés, faux refus, exceptions et délais de révocation. Étendez si le refus par défaut reste tenable et si chaque droit possède une origine ; sinon, réduisez les attributs ou corrigez la structure organisationnelle.
Clôturez par une campagne de retrait : révoquez un utilisateur, réduisez un périmètre, fermez un site et laissez expirer une délégation. Vérifiez pages déjà ouvertes, liens de téléchargement, jetons d’API, exports planifiés et workers. Le compte rendu mesure le délai jusqu’au refus effectif et cherche les copies qui restent accessibles. Le métier signe les exceptions historiques ; la sécurité confirme que les accès actifs correspondent aux relations attendues.
- Définir action, ressource et périmètre.
- Centraliser une politique explicable.
- Tester interfaces, délégations et pannes.
- Observer un compte puis généraliser.
Approfondir portail et validation
Avant généralisation, construisez aussi une carte des chemins d’accès : navigation, recherche, API, lien direct, export, notification et traitement en lot. Pour chaque ressource sensible, au moins un test négatif traverse chaque chemin. Cette matrice révèle les contrôleurs protégés alors qu’un export ou une miniature reste ouvert. Elle devient un critère de revue lors de toute nouvelle interface, afin que l’autorisation soit une propriété du produit complet et non d’un seul écran.
Appliquer les droits au portail B2B
Le guide du portail B2B contractuel applique ces périmètres aux catalogues, prix et documents.
Encadrer les approbations
Poursuivez avec les validations des clients grands comptes pour les plafonds, séparations de fonctions et délégations.
- Un sujet authentifié.
- Une ressource contextualisée.
- Une décision expliquée.
Conclusion : vérifier chaque périmètre
Les droits B2B ne vivent ni dans un menu ni dans une colonne de rôle. Ils relient identité, action, ressource et contexte. Compte, site et filiale deviennent des relations explicites, datées et testables.
Le refus par défaut, la centralisation et les scénarios négatifs réduisent les fuites. Les journaux, versions et procédures de révocation rendent la politique exploitable lorsque l’organisation change.
Commencez par l’action qu’un utilisateur d’une autre filiale ne doit jamais réaliser. Modélisez sa ressource et son périmètre, puis cherchez tous ses chemins d’accès. Cette première frontière donnera la grammaire des suivantes.
- Une relation prouvée.
- Un droit minimal.
- Un refus actionnable.
Dawap peut accompagner cette architecture de développement web sur mesure : modèle d’autorisation, portail, tests, audit, migration des droits et préparation du run.
