SaaS
Rôles et droits dans un SaaS avant le code
Les rôles et les droits d'un SaaS s'écrivent avant le code, sous la forme d'un tableau qui montre quel rôle fait quoi. La base : trois règles de l'OWASP, privilèges minimaux, refus par défaut et contrôle à chaque requête sur le serveur. Le résultat se vérifie par des tests.
Dans une plateforme SaaS, tout le monde ne voit pas les mêmes choses. Un directeur, un opérateur et un client ont des besoins différents et des droits différents. Ces droits s'écrivent avant le code, dans un tableau simple que vous validez. La raison est pratique : une erreur ici ne se voit pas à l'écran, mais elle montre des données à quelqu'un qui n'aurait pas dû les voir.
Qu'est-ce que le contrôle d'accès ?
Le contrôle d'accès décide ce que chaque utilisateur a le droit de faire une fois connecté. La connexion dit qui est l'utilisateur. Le contrôle d'accès dit ce qu'il peut voir, modifier ou supprimer. Ce sont deux tâches différentes, et la seconde demande sa propre conception.
L'OWASP, la communauté ouverte de sécurité des applications, place en tête de sa liste Top 10 de 2021 le Broken Access Control, c'est-à-dire le contrôle d'accès défaillant. Par rapport à la liste précédente, il est passé de la cinquième à la première place. Cela montre à quelle fréquence les applications laissent des utilisateurs aller là où ils ne devraient pas.
Qu'est-ce qu'un rôle ?
Un rôle est un nom donné à un groupe de droits. Le NIST décrit le RBAC (role-based access control) comme un modèle où les utilisateurs sont affectés à des rôles, et où chaque rôle a un ou plusieurs droits. Les administrateurs définissent les actions dont chaque poste a besoin et placent les personnes dans le rôle correspondant.
Le NIST note que, sans rôles, les administrateurs définissent souvent des listes d'accès par utilisateur, ce qui est coûteux et source d'erreurs. Avec les rôles, la gestion suit la structure de l'organisation. Quand un employé change de poste, il change de rôle, et non des dizaines de réglages séparés.
Comment s'écrit le tableau des droits ?
Le tableau des droits s'écrit avec une ligne par action et une colonne par rôle. Nous le construisons à l'étape des besoins, avec les personnes qui utiliseront le système. Chaque case répond par oui ou par non.
Action | Directeur | Opérateur | Client |
|---|---|---|---|
Voit les tableaux de bord de toute l'équipe | Oui | Non | Non |
Crée et modifie des demandes | Oui | Oui | Seulement les siennes |
Approuve une demande | Oui | Non | Non |
Supprime des données | Oui | Non | Non |
Ce qui précède est un exemple, pas une recette toute faite. Les rôles diffèrent d'un projet à l'autre. L'intérêt du tableau est qu'on s'accorde avant de construire quoi que ce soit, et que le code et les tests suivent exactement ce qui a été approuvé.
Quelles règles suit-on ?
Nous suivons trois règles du Authorization Cheat Sheet de l'OWASP. La première est celle des privilèges minimaux : l'utilisateur reçoit seulement ce dont il a besoin pour son travail. La deuxième est le refus par défaut, c'est-à-dire que tout ce qui n'a pas été explicitement autorisé est interdit. La troisième est le contrôle à chaque requête.
La troisième règle a une conséquence pratique. L'OWASP souligne que le contrôle se fait sur le serveur et pas seulement dans le navigateur, car le navigateur est contrôlé par l'utilisateur. Un bouton caché à l'écran ne protège rien si le serveur accepte la requête. Pour la même raison, un contrôle manquant à un seul endroit peut exposer toute une ressource.
Et les données propres à l'utilisateur ?
Le rôle ne suffit pas toujours. Dans le tableau ci-dessus, le client peut modifier des demandes, mais seulement les siennes. C'est une règle sur l'enregistrement, pas sur le rôle. L'OWASP Top 10 le cite comme mesure de prévention : les modèles d'accès doivent faire respecter la propriété de l'enregistrement, pour que l'utilisateur ne puisse pas lire, modifier ou supprimer les enregistrements d'autrui.
Le Cheat Sheet de l'OWASP propose lui-même, pour les applications, des modèles qui regardent des attributs ou des relations (ABAC, ReBAC), car les rôles montrent leurs limites quand la décision dépend de l'enregistrement lui-même. C'est pourquoi nous partons des rôles, faciles à expliquer à toute l'équipe, et nous ajoutons des règles de propriété là où le tableau l'exige. Dans une plateforme avec de nombreux clients, il existe un niveau de plus, la séparation des données par tenant, décrite dans l'article sur les données des clients dans un SaaS.
Comment vérifie-t-on que cela fonctionne ?
On le vérifie par des tests automatiques écrits avant le code. L'OWASP recommande des tests de la logique des droits, qui confirment que l'accès est refusé par défaut et que les règles s'appliquent. Il ajoute que les tests automatiques ne remplacent pas le contrôle de sécurité manuel.
Dans notre travail, le test d'une fonction s'écrit en premier, et pour chaque fonction qui touche des données, on écrit aussi un test pour le mauvais utilisateur : ce que répond le système à un autre rôle, à un visiteur non connecté, à un utilisateur d'un autre client. Pour la méthode, lisez l'article d'abord le test, ensuite le code. Une équipe d'agents examine en plus le projet terminé, comme nous l'expliquons dans l'étude de cas des agents de qualité et de sécurité.
Questions fréquentes: Rôles et droits dans un SaaS avant le code
De combien de rôles une plateforme a-t-elle besoin ?
Autant que les personnes qui l'utilisent en ont besoin, pas plus. Nous partons de quelques rôles qui correspondent à de vrais postes. Si l'équipe a besoin d'un rôle intermédiaire, il s'ajoute par la procédure de modification, avec une nouvelle ligne dans le tableau.
Mon client peut-il créer ses propres rôles ?
Cela dépend du produit et se décide à l'étape des besoins. Certaines plateformes ont des rôles fixes, d'autres laissent l'administrateur de chaque client définir des rôles. Le second choix ajoute du travail, car chaque rôle doit être vérifié par des tests.
Suffit-il de cacher les boutons non autorisés ?
Non. Le bouton caché aide l'expérience d'utilisation, mais ce n'est pas un contrôle d'accès. Le contrôle se fait sur le serveur, à chaque requête, pour qu'il s'applique même si quelqu'un envoie la requête autrement.
Quand ce travail commence-t-il ?
À la première étape, celle des besoins, avant les maquettes des écrans. Le tableau des droits influence les écrans, les données et les tests, il vaut donc la peine de l'avoir dès le début.
Voulez-vous que nous définissions les rôles de la plateforme ?
Si vous préparez une plateforme avec des rôles d'utilisateurs différents, le tableau des droits est un bon premier pas, que vous pouvez même commencer seul sur une page. Décrivez votre projet dans la demande de projet et nous le terminerons ensemble à l'étape des besoins. Voyez aussi la page des plateformes SaaS.