Cette application auto-hébergée accorde-t-elle uniquement les accès nécessaires ? Checklist d’évaluation du RBAC
Utilisez cette checklist pratique pour évaluer les rôles, les autorisations, les périmètres d’administration, l’accès aux API et les processus de cycle de vie des utilisateurs avant de transférer des utilisateurs et des données vers une application auto-hébergée.
Pourquoi la conception du contrôle d’accès doit précéder le déploiement
Une migration peut rendre une application techniquement disponible tout en étant mal adaptée à la manière dont le travail est réellement réparti dans l’organisation. Si les équipes finance, ventes, opérations, service client et les prestataires ont tous besoin d’effectuer des actions différentes sur des enregistrements différents, validez ce modèle avant d’importer les données de production ou d’inviter des utilisateurs.
Le contrôle d’accès basé sur les rôles (RBAC) consiste à identifier les opérations requises par des fonctions particulières, à attribuer les personnes à des rôles, puis à attribuer des privilèges à ces rôles. La question importante pour l’acheteur n’est donc pas « Est-ce que l’application mentionne le RBAC ? », mais « Pouvons-nous exprimer et gérer nos décisions d’accès requises dans cette application ? »
Considérez le principe du moindre privilège comme un critère de conception : chaque personne ne doit recevoir que les privilèges minimaux nécessaires à son travail. Des personnes ayant un niveau hiérarchique similaire peuvent néanmoins nécessiter des accès très différents, car leurs responsabilités diffèrent. OWASP recommande également une autorisation refusée par défaut : l’accès doit être explicitement autorisé plutôt que présumé.
- Évaluez les autorisations pendant la sélection, et non après un déploiement en production qui rend les accès étendus difficiles à retirer.
- N’assimilez pas l’utilisation du terme « RBAC » par une application à des capacités avancées. Le NIST distingue l’attribution de rôles de base des fonctionnalités facultatives de hiérarchies de rôles et de séparation des tâches.
- Faites de l’adéquation du modèle d’accès un critère bloquant de migration, au même titre que l’import des données, les intégrations, l’authentification et les exigences de sauvegarde.
Commencez par les groupes d’utilisateurs réels et les actions que chacun doit effectuer
Partez du travail, et non des noms de rôles par défaut de l’application. Interrogez les personnes responsables de chaque processus métier et consignez l’ensemble minimal et pratique d’actions qu’elles doivent accomplir. Incluez le travail courant, les exceptions, les validations, les exports, les suppressions, l’administration des utilisateurs et les changements de configuration.
Évitez les libellés de rôles qui masquent des privilèges étendus. « Responsable », « éditeur » ou « membre » ne constituent pas une exigence d’autorisation. Une exigence utile précise un verbe, un objet et un périmètre : par exemple, « créer des enregistrements dans l’espace de travail attribué », « consulter les projets appartenant au client » ou « exporter uniquement des rapports agrégés ».
Incluez les exigences négatives. Il s’agit des actions ou données auxquelles un groupe ne doit pas pouvoir accéder, qu’il ne doit pas pouvoir modifier, divulguer ou approuver. Elles révèlent souvent des lacunes qu’une liste d’actions autorisées ne permet pas d’identifier.
- Recensez les populations d’utilisateurs : employés, responsables d’équipe, dirigeants, personnel temporaire, prestataires, clients, partenaires, auditeurs et administrateurs techniques.
- Pour chaque population, listez les actions : consulter, créer, modifier, commenter, attribuer, approuver, supprimer, exporter, partager, configurer et administrer.
- Définissez le périmètre de chaque action : ses propres enregistrements, les enregistrements attribués, les enregistrements de l’équipe, un espace de travail, un compte client, tous les enregistrements ou aucun enregistrement.
- Identifiez séparément les champs sensibles et les actions à fort impact des accès ordinaires au contenu.
Identifiez le modèle d’accès de l’application : rôles, groupes, objets et périmètres
Demandez à la documentation du fournisseur ou du projet de présenter le modèle d’accès exact pour la version que vous prévoyez de déployer. Consignez ce qui est documenté, ce qui peut être démontré dans une instance de test et ce qui reste incertain. Ne comblez pas les lacunes par des hypothèses fondées sur une autre application ou sur un libellé de rôle familier.
Déterminez au minimum si les autorisations sont attribuées au moyen de rôles fixes, de rôles personnalisés, de groupes, d’attributions directes à des utilisateurs ou d’une combinaison de ces mécanismes. Déterminez ensuite le périmètre auquel ces autorisations s’appliquent : toute l’instance, une organisation, une équipe, un espace de travail, un projet, une collection, un enregistrement ou un champ.
Un périmètre d’espace de travail n’est utile que s’il restreint réellement l’accès de la manière dont vous avez besoin. Vérifiez si des personnes peuvent effectuer des recherches au-delà des périmètres, suivre des liens vers d’autres objets, recevoir des notifications contenant des informations restreintes, exporter des données couvrant plusieurs périmètres ou obtenir un accès par appartenance héritée.
- Pouvez-vous créer un rôle correspondant à chaque exigence sans attribuer de privilèges sans rapport ?
- Les rôles sont-ils globaux ou peuvent-ils différer selon l’espace de travail, le projet, le client ou un autre périmètre métier ?
- Les autorisations peuvent-elles être définies au niveau de l’objet ou du champ lorsque votre niveau de risque l’exige ?
- Les hiérarchies de rôles sont-elles prises en charge et, le cas échéant, les privilèges hérités restent-ils compréhensibles et révisables ?
- Des attributions directes peuvent-elles contourner le modèle de rôles habituel, et comment ces exceptions seront-elles identifiées lors des revues ?
- Que devient l’accès lorsqu’un objet, un espace de travail ou un utilisateur est déplacé ou copié ?
Testez la séparation entre l’administration et l’accès aux données métier sensibles
L’administration opérationnelle et l’accès aux données métier sont des responsabilités différentes. Une équipe peut avoir besoin d’une personne pour gérer les utilisateurs, le routage, les sauvegardes ou la disponibilité de l’application sans consulter habituellement des informations confidentielles sur les clients, les employés ou les finances. Établissez si l’application prend en charge cette distinction, au lieu de supposer qu’un administrateur peut être convenablement limité.
La séparation des tâches vise à déterminer si une personne détient suffisamment de privilèges pour détourner seule un système de son usage. Elle peut être mise en œuvre au moyen de rôles incompatibles attribués à l’avance ou de contrôles qui empêchent une action incompatible au moment de l’accès. La nécessité de l’une ou l’autre approche dépend de votre processus et de votre niveau de risque, mais la question doit être explicite pour les actions à fort impact.
Cartographiez également la frontière d’infrastructure. Docker avertit que le contrôle d’un démon Docker est hautement privilégié et peut fournir un accès root à l’hôte. De même, les interfaces d’administration de support doivent être examinées ; Traefik indique qu’une API ou un tableau de bord de production peut exposer des éléments de configuration, y compris des données sensibles, et doit être protégé par authentification et autorisation.
- Un administrateur des utilisateurs peut-il créer des comptes et réinitialiser des accès sans lire les enregistrements métier ordinaires ?
- Un administrateur de contenu ou d’espace de travail peut-il gérer les membres sans recevoir de privilèges illimités d’export ou de configuration ?
- Qui peut modifier les rôles, créer des comptes privilégiés, changer les paramètres d’authentification, accéder aux sauvegardes ou gérer le déploiement ?
- Les actions sensibles sont-elles journalisées de manière à pouvoir être examinées par l’organisation ?
- Pour les opérations à haut risque, deux personnes distinctes doivent-elles être requises pour la demande et l’approbation ?
Vérifiez les collaborateurs externes, les prestataires et les utilisateurs clients
Les utilisateurs externes révèlent souvent la différence entre un rôle général de collaboration et un modèle d’accès client sécurisé. Leur accès peut nécessiter une courte durée de validité, un ensemble limité de projets, aucune visibilité sur l’annuaire, aucun droit d’export et aucune capacité à inviter d’autres personnes. Testez ces exigences avec les fonctionnalités réelles de partage et d’appartenance de l’application.
Ne supposez pas qu’une interface restreinte implique des données restreintes. Vérifiez ce que le compte externe peut consulter via les recherches, les URL directes, les notifications, les pièces jointes, les commentaires, les exports et les API. Testez un utilisateur client sur des enregistrements représentatifs d’un autre client, et pas uniquement dans un environnement vide.
Si l’application ne permet pas d’exprimer le périmètre requis, une instance distincte, un espace de travail distinct avec des contrôles soigneusement validés, un processus de partage différent ou une autre application peut être plus sûr. La bonne réponse dépend de la sensibilité des données et des conséquences d’une erreur.
- L’accès externe peut-il être limité à des utilisateurs nommés et à des périmètres métier définis ?
- Les invitations peuvent-elles expirer et l’accès peut-il être supprimé rapidement ?
- Les utilisateurs externes peuvent-ils découvrir d’autres utilisateurs, équipes, clients ou enregistrements ?
- Peuvent-ils télécharger, exporter, copier ou repartager des informations ?
- Peuvent-ils créer des utilisateurs, inviter des collaborateurs ou modifier les membres ?
- L’organisation peut-elle examiner tous les comptes externes actifs et leurs accès ?
Évaluez séparément les jetons d’API, les comptes de service et les intégrations
Les autorisations de l’interface humaine ne prouvent pas que les intégrations sont sûres. Les API peuvent exposer des fonctions administratives ou sensibles si l’autorisation au niveau des points de terminaison est absente ou trop large. OWASP identifie spécifiquement l’autorisation défaillante au niveau des fonctions comme un risque lorsque des points de terminaison administratifs sont accessibles sans contrôles appropriés.
Inventoriez chaque identité non humaine : jetons d’API, identifiants d’intégration, utilisateurs d’automatisation, comptes de service et webhooks, le cas échéant. Pour chacune, identifiez son propriétaire, son objectif, ses autorisations, son périmètre, son emplacement de stockage, son processus de rotation et sa méthode de révocation. Un jeton ne doit pas hériter de l’accès omnipotent d’un administrateur humain simplement parce qu’il était pratique à créer.
Testez les intégrations en utilisant les mêmes périmètres représentatifs que pour les personnes. Une intégration de reporting nécessitant des données agrégées ne doit pas recevoir automatiquement la capacité de modifier des enregistrements ou d’administrer des utilisateurs. Distinguez les identifiants de développement, de test et de production lorsque votre modèle opérationnel permet cette séparation.
- L’application prend-elle en charge des identifiants à périmètre limité, ou chaque jeton équivaut-il de fait à un accès complet au compte ?
- Les jetons peuvent-ils être attribués à un propriétaire individuel ou à une finalité de service nommée ?
- Les autorisations peuvent-elles être limitées par action, périmètre de ressource ou date d’expiration ?
- Un jeton peut-il être révoqué sans désactiver des intégrations non liées ?
- Les réponses d’API respectent-elles les mêmes périmètres prévus que l’interface utilisateur ?
- Les points de terminaison et fonctions administratifs sont-ils explicitement testés, plutôt que déduits des restrictions de l’interface ?
Créez une matrice de test des autorisations avec des enregistrements représentatifs et des comptes hors production
Une matrice de test des autorisations transforme les exigences d’accès en éléments de preuve. Créez des utilisateurs de test représentatifs pour chaque rôle, y compris un compte délibérément doté de faibles privilèges et un compte externe. Créez des enregistrements représentatifs couvrant les scénarios ordinaires, confidentiels, interéquipes, interclients, archivés et de transfert de propriété pertinents pour votre organisation.
Pour chaque rôle et chaque action, indiquez le résultat attendu : autorisé, refusé ou autorisé uniquement dans un périmètre nommé. Testez tous les parcours disponibles, y compris l’interface utilisateur, les liens directs, les recherches, les exports, les actions en masse, les clients mobiles s’ils sont utilisés, les notifications et les API. Les tests d’autorisation doivent couvrir les parcours refusés autant que les parcours utilisateurs réussis.
Effectuez de nouveaux tests lorsque les rôles, les intégrations, les principaux flux de travail ou les fonctionnalités de l’application changent. OWASP note que les problèmes d’autorisation surviennent souvent lorsque des fonctionnalités sont ajoutées ou modifiées sans réévaluation du comportement d’autorisation.
- Utilisez des lignes pour les rôles représentatifs et des colonnes pour les actions et les périmètres de données.
- Consignez les résultats attendus et observés, ainsi que des éléments de preuve tels qu’une date de test, un nom de compte et une référence de résultat.
- Testez, lorsque cela est pertinent, les actions de consultation, création, modification, suppression, partage, export, invitation, changement de rôle et configuration.
- Incluez des tentatives d’accès aux données d’une autre équipe, d’un autre client ou d’un autre espace de travail.
- Ajoutez des tests de régression pour les règles d’autorisation les plus risquées lorsque votre équipe en a la capacité.
Planifiez les processus d’arrivée, de changement de poste et de départ
Même un modèle de rôles bien conçu échoue si les comptes et les appartenances ne sont pas maintenus à jour. Définissez comment une personne obtient un accès, comment son accès évolue lorsque son rôle ou son affectation client change, et comment elle perd son accès à la fin d’un emploi, d’un contrat ou d’un projet. Désignez un responsable nommé pour chaque étape et définissez une fréquence de revue opérationnelle adaptée au risque.
Si l’application prend en charge SCIM, le protocole fournit des opérations pour les ressources Utilisateur et Groupe, notamment pour les créer, les récupérer, les modifier et les supprimer. Cela peut soutenir des flux de provisionnement, mais ne décide pas de vos déclencheurs de cycle de vie, de votre conception des rôles, de vos règles de transfert de propriété ou de votre gestion des exceptions. Ces éléments restent des responsabilités organisationnelles.
Accordez une attention particulière à la propriété. Avant de désactiver un compte, déterminez qui deviendra propriétaire des enregistrements, projets, files d’attente, fichiers, automatisations, rapports et identifiants d’intégration actifs associés à cet utilisateur. Confirmez que le transfert n’élargit pas involontairement l’accès du destinataire.
- Arrivée : vérifiez l’identité, sélectionnez le rôle approuvé, définissez le bon périmètre et consignez le responsable ou propriétaire ayant approuvé.
- Changement de poste : retirez les accès obsolètes avant ou lors de l’ajout de nouveaux accès ; examinez les attributions directes et les appartenances externes.
- Départ : désactivez ou supprimez l’accès, révoquez les jetons, transférez la propriété et examinez les ressources partagées.
- Fin de contrat de prestataire ou de client : utilisez une revue planifiée et confirmez le retrait, plutôt que de vous fier à une tâche manuelle dont il faut se souvenir.
- Examinez périodiquement les comptes privilégiés, externes, inactifs et d’exception.
Questions fréquentes
Que doit contenir une checklist RBAC pour une application auto-hébergée ?
Incluez les groupes d’utilisateurs réels, les actions requises et interdites, le périmètre des données, les rôles et groupes, les limites d’espace de travail ou d’objet, la séparation des administrateurs, les contrôles des utilisateurs externes, les autorisations des API et des comptes de service, une matrice de test des autorisations et les processus d’arrivée, de changement de poste et de départ. Documentez ce qui a été démontré par rapport à ce qui est seulement supposé.
L’hébergement managé fournit-il le RBAC de l’application ?
L’infrastructure managée et l’autorisation applicative répondent à des problèmes différents. Airbip gère l’infrastructure cloud autour des déploiements d’applications basés sur Docker, y compris le routage, les certificats TLS, la gestion du cycle de vie et les sauvegardes configurables. Le client doit toujours sélectionner une application dont le modèle d’autorisations convient à l’organisation, définir les rôles et les périmètres d’accès, et assurer une gouvernance des accès appropriée.
Un rôle appelé administrateur est-il toujours trop puissant ?
Pas nécessairement, mais il doit être testé. Déterminez exactement ce que l’administrateur peut consulter, modifier, exporter et déléguer, et si l’administration opérationnelle peut être séparée de l’accès aux données métier sensibles. Examinez également l’administration de l’infrastructure de support, car ces privilèges peuvent être très sensibles.
Pourquoi tester les autorisations d’API si l’interface utilisateur semble restreinte ?
Les restrictions de l’interface utilisateur ne démontrent pas que les points de terminaison de l’API appliquent les mêmes règles d’autorisation. Testez séparément les fonctions d’API, en particulier les fonctions administratives, les exports et les accès entre périmètres. Inventoriez et limitez les jetons et comptes de service en fonction de leur finalité précise.
Quand une application auto-hébergée n’est-elle pas adaptée au modèle d’accès requis ?
Choisissez une autre application ou une autre approche de déploiement lorsque les périmètres requis ne peuvent pas être exprimés et vérifiés sans exceptions étendues ; lorsque les utilisateurs externes ne peuvent pas être suffisamment isolés en toute sécurité ; lorsque des actions sensibles requièrent une séparation que le système ne peut pas prendre en charge ; ou lorsque l’équipe ne peut pas gérer les revues d’accès, les tests et les processus de cycle de vie nécessaires. Une infrastructure managée ne compense pas un modèle d’autorisation au niveau de l’application qui ne convient pas.
Sources et lectures complémentaires
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs