WordPress : un cas pratique de Contrôle d'accès à base de rôles («Role-Based Access Control: RBAC»)
Le système WordPress intègre les caractéristiques qui définissent un système de contrôle d’accès à base de rôles.
Dans un système de contrôle à base de rôles («Role-Based Access Control: RBAC»), les accords de privilèges à un utilisateur doivent se faire grâce à l’intermédiaire de rôle.
WordPress aussi élargit le concept de contrôle à base de rôles en permettant d'attribuer directement certains privilèges aux utilisateurs.
Le rôle est le medium d’attribution de privilèges envers l’utilisateur.
L’utilisateur débloque des contraintes spécifiques au rôle dans la mesure qu’un rôle lui a était attribué.
Pour bien comprendre le contrôle d’accès à base de rôles, veuillez lire ce post dédié au sujet : Contrôle d'accès à base de rôles («Role-Based Access Control: RBAC»)
Limitation et Bonne Pratique de configuration WordPress
Séparations de Privilèges
Dans une installation WordPress, les privilèges peuvent être partagés entre utilisateurs. Cela n’est pas bon pratique dans les standards de contrôle d’accès à base de rôles. [2]
Manque de permissions basées sur le contexte pour WordPress
Les standards de contrôle d’accès à base de rôles («Role-Based Access Control: RBAC»), ainsi que WordPress, ne disposent pas de permissions basées sur le contexte. [3]
On peut intégrer cette capacité dans une installation WordPress grâce à l’installation d’un plugin.
Pour illustrer le concept de permissions basées sur le contexte, imaginez une permission exécutable uniquement à certains moments de la journée. Par exemple, un éditeur dispose de la permission de modifier une donnée entre 12 H 00 et 16 H 00. [2]
Les rôles par défaut sont limités à cinq
Pour qu’un client WordPress puisse créer de nouveaux rôles personnalisés, il devra installer et activer un plugin.
Cas pratique: configurer les rôles sur WordPress
Les raisons pour lesquelles une personne serait intéressée d’intégrer un système de rôle et permissions dans WordPress.
- Les sites web large nécessitent un effort de collectif.
- Pour calquer les rapports hiérarchiques de la réalité au monde digital. Un élément confidentiel peut être modifié seulement par certains rôles par exemple.
Tableau rôles permissions
| Abonné | Contributeur | Auteur | Éditeur | Admin | |
|---|---|---|---|---|---|
| Modifier profil | ✅ | ✅ | ✅ | ✅ | ✅ |
| Rédiger brouillon | ✅ | ✅ | ✅ | ✅ | |
| Publier | ✅ | ✅ | ✅ | ||
| Supprimer, modifier éléments d'autrui | ✅ | ✅ | |||
| Plus | ✅ |
Différents rôles possibles WordPress
Quand l’Administrateur crée un compte sur WordPress, ce compte doit être assigné à un rôle. Tous les abonnés auront la capacité d’ouvrir et de fermer une session sur le site web.
Abonné:
Un abonné ne peut quasiment rien changer au site web. Il peut modifier ses informations de profil tel que le nom ou prénom.
Contributeur:
Un contributeur peut rédiger un brouillon pour une page ou post. La distinction entre page ou post et brouillon est que le brouillon ne peut être publié. La publication d’un brouillon a pour effet de le rendre accessible publiquement.
Un brouillon est sauvegardé et accessible exclusivement pour d’autres personnes ayant un compte sur le site WordPress.
Auteur:
Un Auteur dispose des privilèges suivants:
- Rédiger et sauvegarder son post brouillon
- Sauvegarder son post brouillon
- Publier son post brouillon
- Modifier ses posts
- Supprimer ses posts
Éditeur:
Un Éditeur dispose des privilèges suivants:
- Rédiger et sauvegarder sa page ou post brouillon
- Sauvegarder son brouillon
- Publier son brouillon
- Modifier tous les posts ou pages
- Supprimer tous les posts ou pages
Administrateur:
Le Rôle d’Administrateur dispose de tous les privilèges.
Dans notre cas pratique, nous disposerons de plusieurs utilisateurs:
- nom d'utilisateur : maestro; rôle: Administrateur
- nom d'utilisateur : matador; rôle: Auteur
L’Admin fait un Post
Illustrons ce que l'on voie sur le tableau de bord quand un post est fait par l’Administrateur.
L’Administrateur dispose des privilèges de supprimer et modifier ses posts et brouillions.
Exemple
Maintenant essayons d’avoir accès aux options de cette nouvelle post publier par l’Administrateur à partir du compte d’Auteur, chose à laquelle nous n’avons pas accès en termes de permissions.
Sur le tableau de bord de l’Auteur, nous voyons que la page «some-post-admin» est référencé sur le tableau de bord, mais que les options pour supprimer ou modifier le post n’y paraissent pas. Cela s’explique, car le Rôle Auteur n’y a pas les privilèges.
Conclusion
Bien que le système influencé RBAC de WordPress soit très fonctionnel et pratique, des études ont montré que, aux cours du temps, des logiciels comme WordPress, subissent des modifications programmatiques spécifiques qui peuvent influencer directement la sécurité d'une application.
Dans une analyse approfondie de 210 versions différentes de WordPress, des publicateurs de revues ont découvert qu'en moyenne 8% des modifications apportées au code, lors de mises à jour logiciel, étaient liées à la conservation du même niveau de sécurité du système informatique. [4] Il serait idéal qu'un apport au paradigme puisse être ajouté pour optimiser ce pépin.
De plus, le système RBAC de WordPress n'est pas dynamique. C'est-à-dire, lorsque les nécessités de permissions changent, il faut faire une requête vers un administrateur pour y remédier. Ce travail est manuel et requiert du temps. Une implémentation de permissions basées sur le contexte serait positive. [2]