La lecture du titre de cet article de blog peut soulever quelques questions. Pare-feu SQL - qu'est-ce que c'est ? Qu'est ce que ça fait? Pourquoi aurais-je besoin de quelque chose comme ça en premier lieu ? Eh bien, la possibilité de bloquer certaines requêtes pourrait s'avérer utile dans certaines situations. Lorsque vous utilisez ProxySQL devant vos serveurs de base de données, le proxy est capable d'inspecter toutes les instructions SQL envoyées. ProxySQL dispose d'un moteur de règles sophistiqué et peut faire correspondre les requêtes qui doivent être autorisées, bloquées, réécrites à la volée ou acheminées vers un serveur de base de données spécifique. Passons en revue quelques exemples.
Vous disposez d'un esclave dédié qui est utilisé par les développeurs pour tester leurs requêtes par rapport aux données de production. Vous voulez vous assurer que les développeurs ne peuvent se connecter qu'à cet hôte particulier et exécuter uniquement des requêtes SELECT.
Autre cas, disons que vous avez rencontré un trop grand nombre d'accidents avec des personnes exécutant des modifications de schéma et que vous souhaitez limiter les utilisateurs pouvant exécuter l'instruction ALTER.
Enfin, pensons à une approche paranoïaque dans laquelle les utilisateurs sont autorisés à exécuter uniquement un ensemble prédéfini de requêtes sur liste blanche.
Dans notre environnement, nous avons une configuration de réplication avec le maître et deux esclaves.
Devant nos bases de données, nous avons trois nœuds ProxySQL avec Keepalived gérant l'IP virtuelle. Nous avons également configuré le cluster ProxySQL (comme expliqué dans ce blog précédent) afin que nous n'ayons pas à nous soucier de modifier trois fois la configuration ou les règles de requête sur les trois nœuds ProxySQL. Pour les règles de requête, un simple partage lecture-écriture est mis en place :
Voyons comment ProxySQL, avec son mécanisme de règles de requête étendu, peut nous aider à atteindre nos objectifs dans ces trois cas.
Verrouiller l'accès des utilisateurs à un seul groupe d'hôtes
Un esclave dédié à la disposition des développeurs - ce n'est pas une pratique rare. Tant que vos développeurs peuvent accéder aux données de production (et s'ils ne sont pas autorisés, par exemple, pour des raisons de conformité, le masquage des données comme expliqué dans notre tutoriel ProxySQL peut aider), cela peut les aider à tester et optimiser les requêtes sur les données du monde réel Positionner. Il peut également être utile de vérifier les données avant d'exécuter certaines des modifications de schéma. Par exemple, ma colonne est-elle vraiment unique avant d'ajouter un index unique ?
Avec ProxySQL, il est assez facile de restreindre l'accès. Pour commencer, supposons que le groupe d'hôtes 30 contient l'esclave auquel nous voulons que les développeurs accèdent.
Nous avons besoin d'un utilisateur qui sera utilisé par les développeurs pour accéder à cet esclave. Si vous l'avez déjà dans ProxySQL, c'est très bien. Sinon, vous devrez peut-être l'importer dans ProxySQL (s'il est créé dans MySQL mais pas dans ProxySQL) ou le créer aux deux emplacements (si vous créez un nouvel utilisateur). Allons-y avec la dernière option, créant un nouvel utilisateur.
Créons un nouvel utilisateur avec des privilèges limités sur MySQL et ProxySQL. Nous l'utiliserons dans les règles de requête pour identifier le trafic provenant des développeurs.
Dans cette règle de requête, nous allons rediriger toutes les requêtes exécutées par l'utilisateur dev_test vers le groupe d'hôtes 30. Nous voulons que cette règle soit active et qu'elle soit la dernière à analyser, nous avons donc activé "Appliquer". Nous avons également configuré RuleID pour qu'il soit plus petit que l'ID de la première règle existante, car nous souhaitons que cette requête soit exécutée en dehors de la configuration habituelle du fractionnement lecture/écriture.
Comme vous pouvez le voir, nous avons utilisé un nom d'utilisateur, mais il existe également d'autres options.
Si vous pouvez prédire quels hôtes de développement enverront le trafic vers la base de données (par exemple, vous pouvez demander aux développeurs d'utiliser un proxy spécifique avant qu'ils ne puissent atteindre la base de données), vous pouvez également utiliser l'option "Adresse client" pour faire correspondre les requêtes exécutées par ce proxy. hôte unique et redirigez-les vers un groupe d'hôtes correct.
Interdire à l'utilisateur d'exécuter certaines requêtes
Considérons maintenant le cas où nous voulons limiter l'exécution de certaines commandes particulières à un utilisateur donné. Cela peut être pratique pour s'assurer que les bonnes personnes peuvent exécuter certaines des requêtes ayant un impact sur les performances, telles que les modifications de schéma. ALTER sera la requête que nous utiliserons dans cet exemple. Pour commencer, ajoutons un nouvel utilisateur qui sera autorisé à exécuter des modifications de schéma. Nous l'appellerons "admin_user". Ensuite, nous devons créer les règles de requête requises.
Nous allons créer une règle de requête qui utilise l'expression régulière ".*ALTER TABLE.*" pour correspondre aux requêtes. Cette règle de requête doit être exécutée avant les autres règles de fractionnement en lecture/écriture. Nous lui avons attribué un ID de règle de 20. Nous définissons un message d'erreur qui sera renvoyé au client au cas où cette règle de requête serait déclenchée. Une fois cela fait, nous passons à une autre règle de requête.
Ici, nous utilisons la même expression régulière pour intercepter la requête, mais nous ne définissons aucun texte d'erreur (ce qui signifie que la requête ne renverra pas d'erreur). Nous définissons également quel utilisateur est autorisé à l'exécuter (admin_user dans notre cas). Nous nous assurons que cette requête est vérifiée avant la précédente, nous lui avons donc attribué un ID de règle inférieur de 19.
Une fois ces deux règles de requête en place, nous pouvons tester leur fonctionnement. Essayons de nous connecter en tant qu'utilisateur de l'application et d'exécuter une requête ALTER TABLE :
[email protected]:~# mysql -P6033 -usbtest -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43160
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
ERROR 1148 (42000): You are not allowed to execute ALTER
mysql> ^DByeComme prévu, nous n'avons pas pu exécuter cette requête et nous avons reçu un message d'erreur. Essayons maintenant de nous connecter en utilisant notre "admin_user":
[email protected]:~# mysql -P6033 -uadmin_user -ppass -h10.0.0.111
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 43180
Server version: 5.5.30 (ProxySQL)
Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use sbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> alter table sbtest1 add index (pad);
Query OK, 0 rows affected (0.99 sec)
Records: 0 Duplicates: 0 Warnings: 0Nous avons réussi à exécuter ALTER lorsque nous nous sommes connectés en utilisant 'admin_user'. C'est un moyen très simple de s'assurer que seules les personnes désignées peuvent exécuter des modifications de schéma sur vos bases de données.
Création d'une liste blanche de requêtes autorisées
Enfin, considérons un environnement étroitement verrouillé où seules des requêtes prédéfinies peuvent être exécutées. ProxySQL peut être facilement utilisé pour implémenter une telle configuration.
Tout d'abord, nous devons supprimer toutes les règles de requête existantes avant de pouvoir implémenter ce dont nous avons besoin. Ensuite, nous devons créer une règle de requête fourre-tout, qui bloquera toutes les requêtes :
Le reste que nous devons faire est de créer des règles de requête pour toutes les requêtes autorisées. Vous pouvez créer une règle par requête. Ou vous pouvez utiliser des expressions régulières si, par exemple, les SELECT peuvent toujours être exécutés. La seule chose dont vous devez vous souvenir est que l'ID de règle doit être plus petit que l'ID de règle de cette règle fourre-tout, et assurez-vous que la requête finira par atteindre la règle avec "Appliquer" activé.
Nous espérons que cet article de blog vous a donné un aperçu de la façon dont vous pouvez utiliser ClusterControl et ProxySQL pour améliorer la sécurité et assurer la conformité de vos bases de données.
