Un rôle, un jeu de permissions
Chaque utilisateur porte un rôle nommé, auquel est associé un dictionnaire de permissions. Chaque endpoint de l'API est protégé par ce mécanisme : une permission absente se traduit par un refus côté serveur, pas seulement par un bouton masqué.
Granularité
Les permissions couvrent les clients, les projets, les vulnérabilités, le calendrier, les rapports, la facturation, les groupes, les utilisateurs, les paramètres et la licence : chacune avec une distinction lecture et écriture.
Scope automatique par rôle
- Les administrateurs voient l'intégralité des projets
- Les auditeurs et chefs de projet ne voient que leurs projets assignés
- Les managers ne voient que les projets des groupes dont ils sont membres
- Un chef de projet rattaché à un compte client ne voit que les projets de son organisation
Un manager ne peut pas ajouter d'administrateurs ni d'autres managers à ses groupes. Cette restriction empêche une escalade de privilèges par appartenance de groupe.
Protections structurelles
Le dernier compte administrateur ne peut être ni supprimé ni rétrogradé, et les rôles système ne peuvent pas être effacés. Ces garde-fous évitent de se verrouiller hors de sa propre instance.