À retenir
- Séparer les rôles (qui est quelqu'un) des permissions (ce qu'exige une action).
- Ajouter les périmètres – site, service, propriété – comme seconde dimension.
- Vérifier l'accès côté serveur à chaque requête ; l'interface ne fait que masquer ce qui n'est pas autorisé.
- Journaliser chaque changement de rôle et chaque accès sensible.
Le contrôle d'accès commence souvent par un simple indicateur « admin » et finit en enchevêtrement de cas particuliers. Une structure de rôles, permissions et périmètres qui reste lisible à mesure que l'organisation grandit.
Comment le contrôle d'accès se dégrade
La plupart des systèmes démarrent avec deux types d'utilisateurs : les administrateurs et tous les autres. Avec la croissance viennent les exceptions – un manager qui peut valider mais pas supprimer, une agence qui ne doit voir que ses propres dossiers, un auditeur qui peut tout lire et rien modifier. Chaque exception devient une condition dans le code, et bientôt personne ne sait plus avec certitude qui peut faire quoi.
Rôles et permissions sont deux choses différentes
Définissez les permissions comme les actions que votre système prend en charge – créer une facture, valider un congé, exporter un rapport. Définissez les rôles comme des ensembles nommés de permissions correspondant à de vraies fonctions. Le code vérifie des permissions, jamais des noms de rôles.
Cette seule règle rend les changements peu coûteux. Quand une nouvelle fonction apparaît, vous créez un rôle à partir de permissions existantes au lieu de modifier le code à des dizaines d'endroits.
Le périmètre comme seconde dimension
Les permissions répondent à « cette personne peut-elle valider un congé ? ». Les périmètres répondent à « pour qui ? ». Dans un système hospitalier, un chef de service ne valide que pour son service ; dans une école multi-sites, le directeur ne voit que son établissement.
- Périmètre organisationnel : entreprise, région, agence, service.
- Périmètre de propriété : les dossiers que l'utilisateur a créés ou qui lui sont attribués.
- Périmètre relationnel : les parents ne voient que les données de leurs propres enfants.
Appliquer côté serveur – à chaque fois
Masquer un bouton est une mesure d'ergonomie, pas un contrôle de sécurité. Chaque requête d'API doit vérifier la permission et le périmètre côté serveur, idéalement dans une couche commune pour qu'aucun endpoint ne puisse l'oublier. Lorsque la base de données le permet, des politiques au niveau des lignes offrent un filet de sécurité supplémentaire.
Rendre l'accès auditable
Journalisez chaque changement de rôle et d'affectation, ainsi que chaque accès à des dossiers sensibles. Quand un client, un auditeur ou un régulateur demande qui pouvait voir quoi et quand, la réponse doit venir d'une requête, pas de la mémoire de quelqu'un.
Cet article vous a plu ? Recevez le prochain par e-mail.