Définir le résultat d’abord
L'accès commence par une question métier : qui peut faire quoi sur quel dossier, dans quelles circonstances ? Des noms de rôles ne suffisent pas. Identifiez actions, limites de propriété et pouvoirs exceptionnels. Lire, modifier, exporter et accorder l'accès sont des capacités différentes.
Choisir la bonne approche
Des rôles simples conviennent parfois à une petite application interne. Propriétaire, organisation et état du circuit peuvent ajouter des conditions. Évitez un rôle par combinaison si quelques attributs expliquent mieux la règle. OWASP recommande refus par défaut et vérification de chaque requête ; cacher un bouton ne protège pas l'action.
Rapprocher un cas concret
Dans un portail fictif, un gestionnaire lit les commandes de son entreprise et la finance télécharge les factures. Testez chaque action avec un identifiant d'une autre entreprise, liens directs et recherches compris. Retirez ensuite une appartenance avec navigateur ouvert. La prochaine requête protégée doit appliquer la nouvelle décision, pas l'écran ancien.
Garder des preuves utiles
N'accordez pas au support un accès total permanent par facilité. Pour une exception, fixez motif, durée et trace. Examinez exports, traitements de fond et identifiants d'intégration autant que les écrans. La matrice doit devenir contrôles exécutables et tests de refus.
Construire la matrice à partir des actions et des frontières
Placez actions en lignes, rôles en colonnes et précisez le périmètre des dossiers. Lire seulement dans son organisation fait partie du droit, pas d'une note. Incluez recherche, téléchargement, export, traitements de fond et attribution d'accès. Protéger la modification mais oublier l'export peut exposer les mêmes données.
Parcourez invitation, vérification de l'entreprise, changement de rôle et retrait. Décidez des opérations exigeant une seconde personne et de l'expiration d'urgence. Séparez conduite de l'activité et administration technique. Approuver un achat ne donne pas besoin de gérer l'authentification ou lire d'autres sociétés. Limitez les identités d'intégration avec responsable et révocation.
Transformez la matrice en exemples acceptés et refusés : dossier autorisé, autre organisation avec même rôle, membre révoqué et requête directe. Répétez pour lots et files, car les droits peuvent évoluer. Gardez la preuve de l'autorisation sans recopier toute la donnée personnelle. Faites investiguer un refus avec ces éléments. Il doit protéger la frontière et aider l'utilisateur légitime sans divulguer les dossiers étrangers.
Cas d'acceptation des permissions
| Cas | Frontière attendue |
|---|---|
| Même rôle, autre organisation | Aucun accès croisé aux dossiers, recherches et pièces par seule similitude de rôle. |
| Retrait pendant une session ouverte | L'action suivante applique l'autorité actuelle, pas le contrôle ancien. |
| Tentative d'élévation personnelle | La règle d'approbation s'impose et la tentative est traçable, sans pouvoir accordé en silence. |
| Export différé après changement | L'exécution suit la politique convenue, pas simplement une sélection passée. |
Questions au responsable
Qui accorde et retire les droits ? Peut-on approuver sa propre élévation ? Quels dossiers restent séparés malgré un même rôle ? Apportez une matrice rôle-action-dossier et des cas refusés. L'interdit mérite autant d'attention que l'autorisé.