Planifier les droits du portail client avec une matrice

« Le client est connecté » ne dit pas quels documents il peut lire ni quelles commandes il peut créer. Un plan d’autorisations relie la personne, l’action souhaitée et le périmètre de données concerné.

Le portail suivant est entièrement hypothétique. Les entreprises C10 et C20, les rôles et les vérifications décrivent une conception, pas un test de sécurité réalisé.

Des tâches à la matrice

Ici, les lecteurs consultent les documents de l’entreprise, les personnes chargées des commandes peuvent aussi commander et les administrateurs clients gèrent les comptes de leur entreprise. Le rôle d’administrateur client n’est pas automatiquement supérieur : le droit de commander ne lui est pas attribué ici.

Cette répartition est un exemple de décision. Si les administrateurs clients doivent aussi commander, cette attribution supplémentaire doit être planifiée et testée explicitement. Les rôles d’entreprise qu’ils peuvent attribuer doivent aussi être définis. Aucun droit sur toute la plateforme n’en découle.

Imposer la limite sur l’objet

Masquer un menu n’empêche pas une demande directe du document. Le serveur doit vérifier que la personne peut agir pour l’entreprise choisie et que le document précis appartient au périmètre autorisé. L’identifiant d’entreprise envoyé par le navigateur est un choix, pas une preuve d’appartenance.

La vérification dépasse les pages de détail. Listes, exports et opérations d’écriture exigent la même limitation adaptée. Cette conception ne donne aucun accès aux combinaisons qui ne sont pas explicitement autorisées.

Vérifier les parcours permis et refusés

La matrice permet de définir les résultats attendus avant réalisation :

• Un lecteur peut ouvrir un document de son entreprise ; une commande avec ce rôle est refusée.

• Un administrateur de C10 n’obtient aucun document de C20, même par son adresse directe.

• La gestion autorisée modifie uniquement les comptes de son entreprise et attribue seulement les rôles prévus.

• Après retrait d’une appartenance ou d’un droit, l’action protégée reste bloquée même avec une session déjà ouverte.

Testez les cas permis autant que les refus. Une application qui bloque tout ne satisfait pas la matrice. Notez rôles, rattachement des données et résultat attendu pour la version testée.

La matrice clarifie une partie des règles. Elle ne remplace ni leur réalisation technique ni une évaluation complète de sécurité. Les changements de rôles, de parcours des données ou d’appartenances doivent être intégrés au plan et aux contrôles adaptés.

Sources

• OWASP — Authorization Cheat Sheet

• OWASP — Multi-Tenant Application Security Cheat Sheet