[RESOLU] Sécurité de la Base De Donnée

Arf non, la question n'est pas idiote du tout :)

Déjà il faut se demande quels sont les risques liés à un service de base de donnée (mysql ou autre). Le premier serait qu'elle soit configuré pour "écouter" une interface réseau "publique" (cad accessible de l'extérieur). Généralement personne ne fais une chose pareil sans un besoin très particulier. Donc en standard, le service écoute l'interface local (localhost/127.0.0.1) ce qui le rend inaccessible de l'extérieur.

Le second risque possible c'est qu'un vilain arrive à "casser" apache (ou un autre service connecté à une interface réseau publique), à s'introduire sur le serveur. De là, il peut se connecter au service de base de données d'où l'intérêt des mots de passe. Intérêt pour le peu illusoire si l'utilisateur "apache" peut lire directement le dossier contenant les données "mysql". Disons que ces données soit super bien protégées (appartenant exclusivement au process mysql)... Mais admettons, le vilain n'a que les droits d'apache, se connecte à la base et est donc bloqué car il y a un mot de passe super sécurisé, tout ça.

Troisième risque, Drupal est une passoire, et le vilain arrive à faire passer une SQL Injection. Les dégâts seront donc limités si l'utilisateur SGBD qu'utilise Drupal a des droits limités... à ses données. Dans ce cas, on ne se protège de pas grand chose sauf si l'on a eu la mauvaise idée de mettre dans la base de donnée Drupal des tables "métier" critiques (généralement on met cela dans une autre base).

Bref, à mon humble opinion, tout ceci est de la tetrapilectomie tendance capilotractée proche de l'histoire de la morsure de la chauve-souris. Si le serveur est proprement construit, que les droits sont proprements réglés, que les ports sont proprement protégés, que les bases sont proprement séparés, qu'elles écoutent uniquement le local, il n'y aucun intérêt à mon sens à ne plus utiliser un simple et bête "mysql://root@localhost/ma_db". Pas de mot de passes qui cassent les pieds, pas d'utilisateur spécifiques, bref, keep it simple and stupid :)

Ceci n'engage que moi, bien évidement, et si j'ai laissé un trou à la chauve-souris, je suis très intéressé à savoir lequel !!

Je tempèrerais quand même les ardeurs...
Généralement chez les hébergeurs (et les SI professionels) on sépare la partie frontale / application de la partie base de données.
En clair, on a les serveurs apache+PHP+Drupal sur des machines et les bases sur d'autres machines, qui n'écoutent donc pas sur le localhost...

Si on arrive à se connecter sur le serveur apache, on peut avoir accès aux fichiers settings, sauf que souvent le compte sous lequel est lancé apache n'a pas accès au shell (pas de possibilité de se connecter sur la machine avec ce compte), et que le settings.php n'est accessible en lecture seule que pour le compte apache.

Donc à moins d'avoir une connexion Root sur la machine, impossible de connaitre la db_url utilisée.
Maintenant, le compte "root" MySQL est souvent créé à l'installation, sans mot de passe. Si on laisse ce compte tel quel - compte privilégié s'il en est - une personne mal intentionnée va commencer par tester ce compte. Il faut donc généralement toujours mettre un mot de passe au compte root.

Et utiliser un autre compte avec des privilèges retreints à une seule base MySQL, le compte root ayant accès à toutes les bases.

Pour une installation mono-instance drupal sur une seule machine, tout cela n'est pas forcément nécessaire, dans un environnement mutualisé, c'est quasiment obligatoire pour ne pas risquer d'avoir des soucis entre les "propriétaires" des différentes bases...

Précision intéressante en effet, je n'ai jamais travaillé qu'en dédié.