Fournir aux utilisateurs MySQL uniquement les privilèges minimum

Question

Pour une application Web, lors de la création de l'utilisateur qui se connectera à la base de données MySQL, vous avez le choix entre des privilèges. En supposant que les seules actions que cet utilisateur a l'intention de faire soient SELECT / INSERT / UPDATE / DELETE, il semble logique de ne fournir que ces privilèges, mais je n'ai jamais vu cette recommandation recommandée nulle part - quelles sont les raisons pour et contre cela méthode?

Answer 1

Un utilisateur peut avoir besoin d'autres privilèges au cours d'une application ordinaire, par exemple:

• CREER UNE TABLE TEMPORAIRE
• EXECUTE (procédures stockées)
• FILE (pour SELECT INTO et LOAD DATA)
• TABLES DE VERROUILLAGE

Il est également possible que les privilèges minimal ne signifient que les commandes SELECT sur certaines tables, ainsi que les commandes SELECT et UPDATE sur les autres tables, etc. Et il existe des cas étranges, tels que la nécessité de disposer du privilège SELECT sur une table que vous n'interrogez jamais, car elle est référencée par les clés étrangères d'une table que vous mettez à jour. Donc, le suivi des privilèges minimes est une douleur royale.

Qu'est-ce que vous essayez de limiter en utilisant les privilèges SQL? C'est vous qui avez écrit tout le code, alors la gestion des privilèges SQL avec une granularité fine ne devrait pas être nécessaire. Franchement, si vos utilisateurs sont capables de télécharger et d’exécuter des instructions SQL que vous n’avez pas vérifiées, vous rencontrez de plus gros problèmes:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;

Les tâches réelles que vous souhaitez gouverner ne se situent pas au niveau base de données, mais au niveau métier de l'application. Par exemple, un CMS exécute des opérations telles que créer une page, modifier une page, gérer les commentaires, etc. Ces tâches sont des privilèges de niveau supérieur aux privilèges SQL. Vous pouvez les imiter avec des rôles SQL (qui sont des groupes de privilèges), mais les rôles SQL ne sont pas largement pris en charge.

Je ne connais personne qui mappe les utilisateurs de leurs applications sur des utilisateurs distincts de MySQL. Ce sont des utilisateurs que vous authentifiez dans votre application, après que l'application s'est connectée à la base de données (les utilisateurs ne sont que des lignes de données dans la base de données).

Il est donc probablement préférable que votre application Web utilise un seul utilisateur MySQL avec tous les privilèges.

Answer 2

Je ne suis pas d'accord avec Bill ici et le raisonnement d'Atomix est plus approprié. À moins de preuve du contraire, la réponse de Bill augmente fortement le risque de compromission de la base de données.

Peut-être que les développeurs très expérimentés ont mis en place une autre sécurité, mais que d'autres développeurs accordent à un script un accès complet et sans entrave pour faire «n'importe quoi» dans une base de données, c'est poser des problèmes, quand il n'y en a pas besoin.

Le principe de moindre privilège devrait être utilisé ici. Pour MySQL, utilisez un super utilisateur disposant de tous les privilèges, qui est utilisé pour créer des tables, supprimer une base de données, etc. Idéalement, ce nom d'utilisateur et ce mot de passe ne sont jamais visibles dans aucun fichier PHP ou fichier sur le serveur Web. (J'utilise PHP comme exemple, mais cela s'applique à d'autres applications Web). Vous n'utiliserez ces nom d'utilisateur et mot de passe qu'avec quelque chose comme PHPMyAdmin ou MySQL Workbench.

Ensuite, pour les scripts PHP, en avez un avec le minimum requis, comme INSERT, SELECT, UPDATE, peut-être même pas DELETE, en fonction de votre script PHP. Ce serait dans les fichiers PHP, c’est-à-dire qu’un seul fichier se trouve en dehors de la racine du document, comme le recommandent la plupart des utilisateurs.

La raison est la suivante: oui, vous n’avez pas besoin d’un utilisateur MySQL pour chaque utilisateur d’application Web. Mais le principe du moindre privilège ( http://fr.wikipedia.org/wiki/Principle_of_least_privilege" rel="noreferrer"> http://en.wikipedia.org/wiki/Principle_of_least_privilege ) devrait appliquer. Si, d'une manière ou d'une autre, votre super utilisateur MySQL est compromis parce que vous avez accidentellement nommé votre script de connexion MySQL comme .txt au lieu de .php, ou qu'une personne a eu accès aux fichiers du serveur Web, au moins le "pire" fichier. ils peuvent faire est de sélectionner, mettre à jour et insérer ... Ce qui peut causer de gros problèmes de toute façon, n’est pas aussi grave que de leur donner DROP DATABASE, DROP TABLES et bien d’autres choses bien pires.

De plus, dans mon projet actuel en raison de pratiques de développement agiles (je ne travaille pas pour mais recommande http: // www. agilealliance.org/ ), un ou deux "non-technologies". les membres de l'équipe utilisent directement PHPMyAdmin pour apporter des modifications directes à la base de données MySQL. En effet, la création d'un CMS pour la saisie directe de données simple n'est pas requise. Dans ce cas, un troisième utilisateur de MySQL avec une valeur raisonnable, mais encore une fois, "juste assez". les privilèges leur conviennent. Nous ne voulons pas paralyser le membre de l'équipe avec trop peu de privilèges, mais bien sûr, il ne devrait pas être en mesure de supprimer ou de modifier accidentellement des choses.

Etant donné que MySQL n’a pas de rôles (à partir du moment où la question initiale a été posée et conformément au projet de loi), autoriser n’importe quel script Web à accéder à MySQL avec un seul super utilisateur est très risqué.

Answer 3

Une application Web utilise généralement un seul utilisateur pour accéder à la base de données, plutôt qu'un utilisateur par compte d'utilisateur réel. L'application de privilèges minimaux est une bonne pratique. Le nom d'utilisateur et le mot de passe vont être codés dans votre script (est-ce que quelqu'un le dissimule?), Vous pouvez donc faire des compromis si vos scripts ne sont pas gérés correctement.

D'après mon expérience, très rarement, l'application supprime les lignes de l'application. Il est préférable de marquer une ligne comme étant supprimée, car vous avez alors un audit de ce qu'il y a plutôt que de ne pas savoir ce qu'il y avait! Cette approche permet également d'optimiser les tables et les index.

Par conséquent, je suggérerais d'autoriser uniquement les actions INSERT, UPDATE et SELECT. Cela deviendra rapidement évident si certaines parties de votre application doivent être légèrement assouplies!

Autoriser davantage de privilèges ne peut qu'élargir la possibilité d'attaques DoS en émettant des commandes gourmandes en ressources ou en autorisant des attaques de données malveillantes.