Pourquoi les hôtes Web vous obligent-ils à indiquer explicitement quelles adresses IP peuvent se connecter à distance à leurs bases de données MySQL?
Pour vous connecter à une base de données MySQL, vous utilisez généralement la commande suivante:
mysql -h Host_address database_name -u db_user -p
où db_user est associé à la base de données en question. Toutefois, si vous avez un plan d’hébergement Web partagé avec un hébergement Web commercial tel que Justhost, Hostgator et iPage, il vous empêche d’accéder de cette manière à vos bases de données, à moins que vous n'y accédiez à partir de votre serveur d’hébergement (auquel cas Host_address serait localhost). Pour résoudre ce problème, vous devez explicitement inclure dans la liste blanche les adresses IP que vous souhaitez pouvoir accéder à vos bases de données à distance.
Ma question est, pourquoi? L'accès à la base de données limité à des comptes d'utilisateur spécifiés (tels que db_user dans l'exemple ci-dessus) n'est-il pas suffisamment sécurisé?
La raison pour laquelle les serveurs de base de données ne sont pas universellement ouverts au monde peut se résumer en deux éléments principaux: Stabilité et sécurité.
Stabilité: En gros, aucune opération de base de données pour les sites Web ne devrait être effectuée via des connexions distantes. Et la plupart des serveurs de base de données sont peaufinés et réglés pour gérer le trafic attendu. trafic pas inattendu. Donc, en limitant l'accès à des utilisateurs spécifiques sur des adresses IP spécifiques, le service d'hébergement est assuré qu'ils n'ont pas à gérer les frais généraux et les maux de tête qui découlent d'attaques aléatoires d'accès par force brute.
Sécurité: La sécurité est liée à la stabilité. Si vous avez déjà exploité un site Web, vous constaterez que les robots et spiders recherchent en permanence des serveurs Web à la recherche de failles. Les serveurs Web peuvent très bien gérer ces tentatives de sondage. Les serveurs de base de données, pas tellement. La fonction principale d'un serveur de base de données est de servir des données et non de lutter contre les tentatives DDoS. Et, croyez-moi, si vous ouvrez un serveur de base de données au monde, vous demandez à être facilement désossé dans l’oubli, car les serveurs de base de données sont de véritables ressources.
Le problème, c’est que, même si les serveurs de base de données peuvent être optimisés pour le trafic, ils ont vraiment besoin de beaucoup de patience, et BEAUCOUP de mots, pour faire preuve de beaucoup de patience afin d’être adaptés à une réelle stabilité. Et c'est sur un système isolé/contrôlé en toute sécurité. Pouvez-vous imaginer le genre de chaos qui s'ensuivrait si un serveur de base de données venait d'être ouvert au monde?
C'est pourquoi la grande majorité des sites Web se connectent à une base de données via une connexion localhost. Et la raison pour laquelle des services tels que Twitter, Flickr et Tumblr utilisent des API RESTful pour accéder aux données: ces API fournissent une couche de serveur Web qui protège la base de données de tout accès direct. Permettre au serveur Web de gérer le coup de tentative de piratage alors que la base de données en arrière-plan effectue son travail avec bonheur, sans avoir à se soucier de la gestion de ce gâchis.
Si les serveurs MySQL que nous ouvrons au grand public, à l'instar de votre site Web, cela les ouvrirait aux attaques par force brutale et à d'autres attaques à distance par des bots pour la plupart dont ils n'ont tout simplement pas besoin. La plupart des gens qui en savent assez qu'ils auront besoin d'un accès distant à MySQL devraient être familiarisés avec son installation dans cPanel, etc. C'est une question de sécurité pour vous et moins de stress pour la société d'hébergement.
Cela remonte en fait à la façon dont la sécurité du serveur de base de données est conçue et non pour une autre raison. Les serveurs de base de données requièrent que l’accès à un nom d’utilisateur/hôte explicite soit configuré en dehors de localhost. Cela existe depuis plus longtemps que le Web tel que nous le connaissons aujourd'hui et nous ramène à l'époque du grand fer où la plupart des utilisateurs se connectaient directement à l'aide d'un terminal. Tous les accès sur le réseau ont été explicitement définis. Dans certains scénarios d'hébergement Web, cela est obtenu en utilisant des applications Web. Cependant, pour y accéder via un outil client depuis un emplacement distant, les bases de données nécessitent toujours un accès utilisateur/hôte défini comme toujours. Les hébergeurs n'ont vraiment pas le choix.
Bien que les réponses fournies soient très valables pour la sécurité des systèmes d'exploitation, un autre aspect doit être pris en compte: les subventions MySQL.
Lorsque la société d'hébergement Web fournit une base de données, elle ne veut pas donner l'accès à d'autres bases de données qui sont également locataires dans la même instance MySQL.
Par exemple, si la base de données dbtyler vous est donnée, vous souhaitez limiter les utilisateurs à la base de données dbtyler. Vous faites cela avec ce qui suit
GRANT USAGE ON *.* TO user_tyler@'10.20.30.40' IDENTIFIED BY 'somepassword';
Cela permet à user_tyler de se connecter à mysqld à partir de 10.20.30.40.
Qu'en est-il de l'accès à la base de données dbtyler? Vous émettez ensuite cette subvention
GRANT ALL PRIVILEGES ON dbtyler.* TO user_tyler@'10.20.30.40';
Même si la société d’hébergement Web cédait l’accès à distance à user_tyler avec cette
GRANT ALL PRIVILEGES ON dbtyler.* TO user_tyler@'%';
cela sécurisera toujours la base de données dbtyler contre tout accès par d'autres locataires. De la même manière, cela empêchera également user_tyler@'10.20.30.40' d'accéder à la base de données de locataires.
Pour plus d'informations, consultez ma publication DBA StackExchange Post à propos de l'instruction GRANT pour la création d'utilisateurs sur le traitement de l'authentification utilisateur MySQL.