Appliquer le principe du moindre privilège pour améliorer la sécurité de WordPress

Le principe du moindre privilège pour WordPress passe à côté des gros titres lorsque des violations, des pertes de données et des attaques DoS se produisent. Pourtant, c'est l'une des meilleures pratiques de sécurité les plus efficaces, si elle est négligée, pour les sites Web WordPress.

Dans cet article de blog, nous définissons d'abord le principe du moindre privilège, puis examinons quand et où il s'applique, les risques de ne pas l'adopter et pourquoi de nombreux développeurs de sites Web ne l'intègrent toujours pas dans leurs sites Web WordPress. Nous partageons également quelques recommandations pratiques, afin que vous puissiez immédiatement commencer à améliorer la sécurité de vos sites WordPress. Ce billet de blog comprend quelques mini-études de cas pour aider à illustrer son utilisation dans des contextes réels.

Table des matières

• Qu'est-ce que le principe du moindre privilège ?
• Quand et où le principe du moindre privilège s'applique-t-il ?
• Quels sont les risques si le PoLP n'est pas appliqué ?
• Pourquoi de nombreux propriétaires de sites Web négligent-ils le principe du moindre privilège dans WordPress ?
• Comment appliquer le PoLP pour WordPress
  • Privilèges d'utilisateur de la base de données WordPress
  • Rôles et privilèges des utilisateurs de WordPress
    • Création de rôles personnalisés
  • Autorisations des fichiers et des répertoires
  • Paramétrage des plugins WordPress
  • Accès FTP pour les sous-traitants tiers
• Mini études de cas
  • Applications de sites Web de commerce électronique
  • Universités et établissements d'enseignement
  • Sites d'information et blogs
  • Sites Web bancaires
  • Traqueurs de santé et de forme physique
• Utilisation du principe du moindre privilège pour WordPress et au-delà

Qu'est-ce que le principe du moindre privilège ?

L'idée est très simple : ne pas accorder à un compte utilisateur, à un processus ou à un programme plus de droits d'accès qu'il n'en a besoin pour accomplir les tâches qui lui sont assignées. En termes de site Web WordPress typique avec un blog, pensez à vos éditeurs, auteurs, contributeurs et abonnés. Chacun d'eux a besoin d'accéder à plus ou moins de backend de votre site Web.

Le principe du moindre privilège (PoLP) est également connu sous le nom de « principe de moindre autorité », de « principe des privilèges minimaux » ou de « compte d'utilisateur le moins privilégié » (LUA).

Prenons quelques exemples simples. Vos tout-petits n'ont pas souvent besoin d'accéder à la cuisine. Ainsi, vous installez un dispositif de contrôle d'accès, comme une barrière de sécurité, à différents endroits de votre habitation pour leur permettre de se promener à leur guise – sauf pour certaines pièces. Dans un espace de coworking public partagé, vous déconnectez votre ordinateur portable avant de partir déjeuner. De plus, le préposé au stationnement de votre restaurant chic aura besoin de votre pièce d'identité ou de votre billet avant de vous rendre les clés de votre voiture. Le contrôle d'accès prévient les dommages à vous et aux biens de valeur de vos utilisateurs, qu'il s'agisse d'un élément physique ou d'une garantie numérique.

Quand et où le principe du moindre privilège s'applique-t-il ?

La réponse simple est que cela s'applique partout : du tout-petit qui veut monter les escaliers aux utilisateurs de votre compte d'hébergement de site Web WordPress. Votre pigiste financier qui doit télécharger les factures mensuelles n'a pas besoin du même niveau d'accès que l'administrateur du site Web. Il en va de même pour toutes sortes de comptes d'entreprise privilégiés, de systèmes de gestion de fichiers, de documentation de stratégie marketing ou de gestionnaires de mots de passe.

Quels sont les risques si le PoLP n'est pas appliqué ?

Contrôler l'accès à certaines zones semble une évidence. Sinon, ne quittez-vous pas le site Web entièrement au gré de tout utilisateur connecté - y compris ceux qui peuvent commettre des erreurs innocentes et par inadvertance, et qui peuvent même ne pas être conscients qu'ils les ont commises, ni des résultats imprévus ?

Pensez aux utilisateurs possibles suivants :

• Un nouvel utilisateur commence avec peu de compréhension des implications commerciales des erreurs sur un site Web WordPress
• Ceux qui ont peu d'expérience en administration de WordPress
• Sans connaissance des implications du téléchargement de nouvelles versions ou plugins WordPress à volonté, ou de leur mise à jour sans faire de sauvegarde préalable
• Ceux qui ont une sensibilisation limitée à la sécurité créent de nouveaux utilisateurs ou modifient les autorisations des utilisateurs existants
• Ceux qui ne savent pas comment gérer les erreurs signalées ou d'autres problèmes
• Contributeurs de blogs externes tels que partenaires, pigistes et clients, avec peut-être quelques connaissances sur WordPress, qui peuvent même télécharger ou mettre à jour « utilement » des plugins sur votre site Web – sans demander

Cela signifie également que l'ensemble de votre backend WordPress est menacé par une personne autrement non autorisée, telle qu'une personne ayant des niveaux d'accès inappropriés, ajoutant de nouveaux utilisateurs et leur donnant accès à des zones du site Web où ils peuvent causer des dommages délibérés .

Tel que:

• Modification des thèmes, des fonctionnalités personnalisées ou du contenu du site Web destiné au public
• Mauvaise gestion des stocks, des SKU ou des métadonnées des produits dans les magasins de commerce électronique
• Offrir des remises non autorisées
• Accéder, modifier, télécharger ou supprimer du code, des modèles de page, des médias, des configurations ou du personnel, des clients et d'autres types de fichiers
• Accéder aux données de l'entreprise, des clients, de la santé ou financières, par exemple, pour les utiliser à mauvais escient ou les vendre à d'autres parties malveillantes
• Mettre le site et ses produits ou services hors ligne

Que vous utilisiez WordPress ou non, tout ou partie de ces problèmes peuvent survenir lorsque le principe du moindre privilège pour WordPress n'est pas adopté délibérément et systématiquement dans toute votre organisation.

ASTUCE : Utilisez un plug-in de journal d'activité pour WordPress afin de conserver un journal de toutes les modifications apportées par les utilisateurs sur votre site Web WordPress. Il aide à la responsabilisation des utilisateurs et facilite le dépannage.

Pourquoi de nombreux propriétaires de sites Web négligent-ils le principe du moindre privilège dans WordPress ?

Les risques que nous avons décrits semblent assez convaincants, n'est-ce pas ? Mais l'un des problèmes les plus courants signalés à la suite des audits de sites Web WordPress est que les rôles des utilisateurs de WordPress dans un environnement typique sont toujours configurés comme suit :

• Le rôle d'administrateur WordPress est donné à chaque utilisateur, même lorsque l'utilisateur a juste besoin de saisir du contenu écrit par quelqu'un d'autre
• Il en va de même pour les fichiers et les autorisations de répertoire, qui sont tous configurés avec les autorisations les moins restrictives

Nous avons compris. Nous avons tous eu de l'expérience en tant qu'administrateurs de systèmes et de sites Web à un moment donné de notre carrière. Plutôt que d'assurer la liaison entre les utilisateurs et les autorisations dans les premiers jours, en vérifiant ce que l'utilisateur doit faire, les administrateurs préfèrent souvent leur attribuer simplement le rôle d'administrateur également (cela semble plus rapide, au départ).

Il en va de même pour les fichiers et les autorisations de répertoire. Par exemple, certains plugins WordPress stockent des fichiers de cache ou d'autres données sur le système de fichiers (c'est-à-dire dans les répertoires WordPress). Il est plus facile de configurer simplement les autorisations 777 dans le répertoire /wp-content/plugins/, car tous les plugins fonctionneront et il n'est pas nécessaire de passer plus de temps à dépanner et à peaufiner les autorisations chaque fois que vous installez un nouveau plugin. Mais, effectuer des recherches au début pour déterminer les zones spécifiques de l'application ou des répertoires du site Web - pour éviter que les utilisateurs n'aient trop d'accès - réduit les risques déjà mentionnés. De plus, il présente l'avantage supplémentaire de permettre à chacun d'accéder à ce dont il a besoin pour faire son travail, sans autre intervention d'un administrateur.

Les questions que les propriétaires et les administrateurs de sites Web doivent poser

La commodité vaut-elle le risque de sécurité ? Vous savez quelle serait notre réponse à cette question. Il est tout simplement inutile d'installer et de maintenir des plugins de sécurité d'application Web robustes, des protocoles de mot de passe et d'autres mesures telles que 2FA, si votre plus grand risque de sécurité est que vous avez déjà laissé la porte dérobée ouverte avec des contrôles d'accès amateurs et laxistes !

Comment appliquer le principe du moindre privilège pour WordPress

Maintenant que vous vous concentrez sur la sécurisation de votre application de site Web, cette section vous fournit une liste indiquant où et comment le principe du moindre privilège peut être appliqué à un site Web ou à un blog WordPress.

Privilèges d'utilisateur de la base de données WordPress

Commençons par l'endroit le plus élémentaire - les autorisations ou privilèges de la base de données des utilisateurs WordPress.

Pour les opérations WordPress quotidiennes normales telles que l'écriture et la publication de contenu, l'utilisateur de la base de données WordPress n'a besoin que des autorisations suivantes pour lui permettre de gérer les données depuis la base de données :

• Sélectionner
• Insérer
• Mettre à jour
• Supprimer

Ces autorisations ne permettent pas à l'utilisateur de la base de données WordPress de modifier la structure de la base de données.

Recommandations

Dans un environnement idéal, pour renforcer la sécurité de votre site Web ou blog WordPress, vous devez configurer des privilèges de base de données WordPress MySQL sécurisés et restrictifs. Ne revenez à l'attribution de tous les privilèges qu'aux utilisateurs qui doivent installer un nouveau plugin qui crée de nouvelles tables dans la base de données, ou lorsque WordPress a été mis à jour et que le schéma de la base de données WordPress a été modifié.

Une autre recommandation est d'éviter d'accorder l'accès à des bases de données autres que celle de WordPress pour le site Web concerné.

Pour plus d'informations sur les privilèges de base de données WordPress, vous pouvez également lire Pourquoi les privilèges minimum de base de données WordPress de l'utilisateur MySQL améliorent la sécurité, qui explique les répercussions d'une configuration non sécurisée.

Rôles et privilèges des utilisateurs de WordPress

Les utilisateurs de WordPress font des erreurs - même les administrateurs. De plus, les utilisateurs aiment également explorer les paramètres et les configurations. Si vous attribuez aux utilisateurs un accès Super Admin ou Administrateur, les plus curieux d'entre eux installeront très probablement des plugins aléatoires. Cela peut potentiellement entraîner une modification involontaire de l'expérience utilisateur, telle qu'une modification de la fonctionnalité du site Web.

WordPress a un certain nombre de rôles d'utilisateur intégrés et de capacités connectées, comme indiqué ci-dessous (du plus au moins).

• Super administrateur - administrateur du réseau du site
• Administrateur - administrateur réseau du site pour un seul site
• Éditeur - gérer et publier des messages, y compris les messages d'autres utilisateurs
• Auteur – gérer et publier ses propres publications
• Contributeur – rédigez et gérez vos propres publications, mais ne les publiez pas
• Abonné - gérer le profil uniquement

Un exemple de la façon dont cela fonctionne dans la pratique est que, bien qu'un contributeur et un auteur puissent partager certaines fonctionnalités (par exemple, modifier des publications et supprimer des publications), un contributeur ne peut pas faire tout ce qu'un auteur peut faire, comme télécharger des fichiers ou créer des blocs utilisables.

Création de rôles personnalisés

Il existe également un bon nombre de plugins que vous pouvez utiliser pour créer de nouveaux rôles WordPress personnalisés.

Voici quelques cas d'utilisation courants :

• Dans les grandes organisations, vous devrez peut-être désigner un membre de votre équipe marketing pour modérer, approuver et répondre aux commentaires. La capacité de «modérer les commentaires» est hébergée dans le rôle d'éditeur, mais ce rôle attribue également une multitude d'autres fonctionnalités puissantes. Donc, si c'est tout ce qu'ils doivent pouvoir faire, alors la configuration d'un rôle personnalisé, avec cette seule autorisation, est suffisante.
• Si votre site WordPress contient un plugin e-commerce tel que WooCommerce, vous êtes limité à deux rôles initiaux : Shop Manager (permettant à l'utilisateur de gérer l'intégralité de la boutique) et Customer (permettant à l'utilisateur de voir son compte et ses commandes). L'administrateur dispose d'autorisations supplémentaires, telles que "gérer les paramètres" et "afficher les rapports". Mais que se passe-t-il si vos utilisateurs - le personnel non-cadre, par exemple - ont besoin de quelque chose entre les deux, comme la possibilité d'ajouter et de gérer des quantités de stock ou des SKU, ou simplement de traiter des commandes ?
• Sur notre site Web, nous utilisons un plugin pour les articles de notre base de connaissances. Cela donne à notre équipe d'assistance un accès pour créer et modifier des articles de la base de connaissances, mais aucun accès aux principales pages du site Web et aux articles de blog.

Recommandations

Pour la plupart des utilisateurs réguliers, le rôle Contributor est suffisant. Pour les chefs d'équipe et les gestionnaires de terrain, le rôle d'éditeur est conseillé. Cependant, vous devez limiter les rôles de super administrateur et d'administrateur aux utilisateurs expérimentés et responsables qui en ont vraiment besoin.

Pour plus d'informations, consultez Comment utiliser les rôles d'utilisateur WordPress pour améliorer la sécurité de WordPress.

Autorisations des fichiers et des répertoires

Il est facile de configurer les autorisations de fichiers et de répertoires et de nombreux documents sont disponibles en ligne expliquant comment renforcer les autorisations de votre installation WordPress. WordPress fonctionne sur n'importe quel système d'exploitation qui exécute PHP, généralement Linux. En termes de groupes, Linux a trois groupes d'autorisation :

• Propriétaire - propriétaire du fichier/répertoire, dont les autorisations ne s'appliquent ni n'affectent les autres utilisateurs
• Groupe - groupe d'utilisateurs auxquels l'accès au fichier/répertoire a été attribué, dont les autorisations ne s'appliquent ni n'affectent les utilisateurs extérieurs au groupe
• Autre - quels niveaux d'autorisations tout le monde a sur le même fichier/répertoire

Chacun d'entre eux se voit attribuer une autorisation de lecture (afficher le contenu), d'écriture (écrire ou modifier le contenu) ou d'exécution (exécuter le contenu, tel qu'un script). Ces autorisations sont stockées sous la forme d'une série de chiffres et elles donnent accès au code PHP, aux images et autres médias, aux fichiers HTML et javascript et aux plugins.

L'implication d'attribuer les mauvaises autorisations au mauvais groupe d'autorisations pourrait signifier qu'un pirate informatique malveillant pourrait en profiter et entraîner une vulnérabilité de bas niveau se transformant en un risque inacceptable.

Recommandations

Lors de l'installation de WordPress, vous devez également utiliser le PoLP, en configurant le moins possible d'autorisations de fichiers et de répertoires pour que WordPress fonctionne.

N'oubliez pas qu'en renforçant les autorisations de fichiers et de répertoires, vous pouvez également empêcher certains plugins WordPress de fonctionner. Comme expliqué précédemment, vous installez peut-être des plugins qui doivent stocker des données dans leur répertoire d'installation. Si tel est le cas, ne configurez pas simplement les autorisations 777 sur le répertoire du plug-in (lecture, écriture et exécution complètes pour toute personne disposant des autorisations nécessaires pour le contrôler). C'est la solution de facilité. Mais vous devez également éviter de le limiter au point d'empêcher les utilisateurs concernés de mettre à jour WordPress, ses thèmes et ses plugins à partir de l'interface utilisateur Web.

Pour plus d'informations, consultez Autorisations de fichiers WordPress : le guide de configuration des autorisations de sites Web et de serveurs Web sécurisés.

Paramétrage des plugins WordPress

Tous les administrateurs ne sont pas égaux. Comme de nombreux systèmes et réseaux, il est courant d'avoir un administrateur principal parmi un groupe d'administrateurs WordPress. En règle générale, le propriétaire du site Web n'a pas d'autre choix que d'attribuer un accès administrateur à d'autres utilisateurs. Gardez à l'esprit que dans le cas des plugins de sécurité WordPress, ils peuvent souvent stocker des données sensibles, telles qu'un journal d'audit de sécurité WordPress, auquel les administrateurs auraient accès.

Recommandations

Les plugins de sécurité WordPress vous permettent généralement de restreindre l'accès aux autres administrateurs WordPress. L'utilisation de ces fonctionnalités semble être un petit contrôle, mais parfois négligé, qui vous aidera à mieux contrôler l'accès des utilisateurs.

Pour plus d'informations sur les plugins individuels, contactez le support du plugin et le fournisseur d'hébergement. Demandez ensuite dans quels répertoires le plugin doit écrire, afin que vous puissiez configurer les autorisations spécifiquement pour ce répertoire.

Accès FTP pour les sous-traitants tiers

Lorsque vous engagez un concepteur ou que l'équipe d'assistance d'un plugin a besoin d'un accès FTP à votre site Web, vous pouvez lui accorder un accès complet à la racine de votre site Web, n'est-ce pas ? C'est inutile.

Recommandations

Dans le cas d'un concepteur, tout ce dont il a besoin est le répertoire du thème, alors limitez l'accès à ce répertoire. Il en va de même pour les équipes de support des plugins. S'ils ont besoin d'un accès pour vérifier les fichiers journaux, donnez-leur un accès FTP au répertoire du plug-in ou à l'emplacement où le plug-in stocke les fichiers journaux. Évitez de dépendre de tiers pour faire la diligence raisonnable en matière de sécurité à votre place.

Mini études de cas

Examinons quelques exemples pertinents de la façon dont cela fonctionne dans la pratique, et comment les questions et décisions de contrôle d'accès peuvent conduire l'application de PoLP pour permettre le bon accès pour les bonnes équipes et individus.

Applications de sites Web de commerce électronique

Les applications de sites Web de commerce électronique, telles que celles où les consommateurs achètent des articles coûteux tels que des réfrigérateurs-congélateurs, des aspirateurs, des appareils photo ou des ordinateurs portables, offrent divers exemples d'utilisation du PoLP.

Certaines des décisions de contrôle d'accès pour les développeurs d'applications de sites Web de commerce électronique sont évidentes :

• Les services des ressources humaines n'auront probablement pas besoin d'accéder aux données des clients ou aux répertoires de fichiers qui stockent les plugins, mais ils auront besoin d'accéder à la majorité des dossiers du personnel (bien que peut-être que les données de santé, qui bénéficient souvent d'un statut spécial en vertu de nombreuses législations sur la conformité à la protection des données, peuvent être plus limité à un besoin de savoir)
• Les services marketing n'auront pas nécessairement besoin d'accéder aux tables SKU ou aux codes produit. Cependant, ils voudront accéder aux tables de la base de données des produits qui répertorient les noms, les spécifications et les descriptions des produits.

Certains sont moins évidents :

• Les consommateurs ont-ils besoin d'accéder à toutes leurs données à tout moment ?
• Les responsables de la conformité PCI-DSS ont-ils besoin d'accéder à toutes les données des consommateurs ?

Universités et établissements d'enseignement

Qu'en est-il des institutions plus traditionnelles et de longue date, où la sécurité des applications Web et le PoLP sont initialement moins apparents ?

Certaines des décisions de contrôle d'accès pour les portails universitaires et collégiaux sont évidentes :

• Le service de la paie a besoin d'accéder aux dossiers du personnel et des sous-traitants dans l'application du site Web pour suivre les jours ouvrables et effectuer des paiements
• Les services administratifs de divers types peuvent avoir besoin d'accéder aux dossiers des étudiants, pour traiter les pièces d'identité, les demandes de logement, les factures ou les subventions

Certains sont moins évidents :

• Quels fournisseurs tiers, tels que les fournisseurs de cartes magnétiques, pourraient avoir besoin d'un accès intermittent à certains tableaux de données sur les étudiants ?

Sites d'information et blogs

Le Web regorge de sites d'information, de podcasts et de blogs. De nombreux propriétaires de sites Web dépendent de plusieurs administrateurs, contributeurs, éditeurs, correcteurs et éditeurs. De plus, il y a des abonnés et des téléspectateurs à considérer.

Certaines des décisions de contrôle d'accès pour les applications de sites Web d'actualités et de blogs sont évidentes :

• Selon les domaines de responsabilité de l'entreprise, les éditeurs peuvent avoir besoin d'accéder à une combinaison de pages, d'articles et de billets de blog de chacun
• Les contributeurs n'auront besoin d'accéder qu'à leurs propres articles de blog

Certains sont moins évidents :

• Tous les tiers ont-ils besoin d'accéder à chaque table de la base de données WordPress ? C'est là que les contrôles personnalisés prennent tout leur sens.

Sites Web bancaires

Notre dernier exemple est quelque chose que beaucoup d'entre nous utilisent quotidiennement, les services de sites Web bancaires. Outre les informations sur la santé, les données financières personnelles sont naturellement l'un des types les plus confidentiels qui soient.

Certaines des décisions de contrôle d'accès pour la création d'applications de site Web sont évidentes :

• Aucun utilisateur de services bancaires ne devrait avoir accès au compte d'un autre utilisateur, sauf consentement exprès (probablement contrôlé par l'utilisateur)
• Les comptes d'utilisateurs du personnel doivent avoir accès à de nombreux comptes d'utilisateurs de service, mais limités uniquement aux tâches qu'ils doivent effectuer dans le cadre de leur travail

Certains sont moins évidents :

• De quel degré d'accès les services d'assistance technique doivent-ils bénéficier ? Doit-il pouvoir tout visualiser et tout corriger, en cas d'erreurs ?

Nous vous recommandons de réfléchir et de planifier le cas d'utilisation métier pour chaque scénario. En collaboration avec vos groupes d'utilisateurs et d'individus avec des descriptions de poste uniques. Cartographiez-les d'abord. Ce n'est qu'alors que vous pourrez commencer à examiner les protocoles de contrôle d'accès à votre disposition sur votre site Web WordPress.

Traqueurs de santé et de forme physique

Les appareils de suivi de la santé ou de la condition physique et leurs tableaux de bord en ligne connectés collectent, stockent et partagent des statistiques fascinantes sur les utilisateurs et leurs données de santé, leur activité, leurs objectifs et leurs réalisations.

Certaines des décisions de contrôle d'accès pour les marques de trackers de santé et de fitness sont évidentes :

• Quelles équipes au sein de l'organisation ont besoin d'accéder à quelles données ? Il est logique que si une équipe est responsable de la conception et du développement de la partie suivi du sommeil de l'application, elle n'a pas nécessairement besoin d'accéder aux tableaux de statistiques d'entraînement.
• La plupart des utilisateurs voudront que le PoLP (qu'ils le sachent ou non) soit très restrictif, afin que leurs informations de santé ne soient pas partagées avec tous les autres utilisateurs. Alors, quels privilèges d'accès doivent être accordés au rôle d'utilisateur normal, et quelles données seront donc partagées sur un profil public (nom, image de profil et pas quotidien moyen uniquement ?).

Certains sont moins évidents :

• Quelles informations, et combien, doivent être accessibles aux autres utilisateurs pour faciliter les fonctionnalités de gamification communes de ces outils ?
• Les développeurs doivent-ils définir toutes les autorisations d'accès, ou une partie de cette prise de décision doit-elle être confiée aux utilisateurs ?

Utilisation du principe du moindre privilège pour WordPress et au-delà

Ce qui précède n'est qu'une sélection des scénarios les plus courants où le principe du moindre privilège pour WordPress est souvent négligé mais peut être facilement appliqué.

Pour commencer à adopter PoLP, commencez par réfléchir à ce que vous voulez faire concernant les éléments suivants :

• Le serveur Web
• La base de données
• Personnalisations

N'hésitez pas à appliquer le principe du moindre privilège simplement parce que les choses ne fonctionnent pas tout de suite. Oui, la plupart du temps, vous devez passer quelques heures à configurer des rôles d'utilisateur personnalisés et à dépanner des plugins. Reconditionnez cela dans votre esprit comme un investissement à long terme dans la sécurité de vos sites Web WordPress.