ProxySQL est devenu un élément d'infrastructure très important dans les environnements de base de données. Il fonctionne comme un équilibreur de charge, il aide à façonner le flux du trafic et à réduire les temps d'arrêt. Un grand pouvoir implique de grandes responsabilités. Comment pouvez-vous rester à jour sur qui accède à la configuration ProxySQL ? Qui se connecte à la base de données via ProxySQL ? Il est possible de répondre à ces questions à l'aide du journal d'audit ProxySQL, disponible à partir de ProxySQL 2.0.5. Dans cet article de blog, nous verrons comment activer cette fonctionnalité et à quoi ressemble le contenu du journal.
Les premières étapes consisteront à déployer ProxySQL. Nous pouvons facilement le faire en utilisant ClusterControl - les types MySQL Replication et Galera Cluster prennent en charge le déploiement ProxySQL.
En supposant que nous ayons un cluster opérationnel, nous pouvons déployer ProxySQL à partir de Gérer -> LoadBalancers :
Nous devons décider sur quel nœud ProxySQL doit être installé, sa version ( nous conserverons la valeur par défaut 2.x) et définirons les informations d'identification pour les utilisateurs administratifs et de surveillance de ProxySQL.
Ci-dessous, nous pouvons soit importer des utilisateurs d'application existants à partir de la base de données, soit créer un nouveau un en attribuant un nom, un mot de passe, un schéma et des privilèges MySQL. Nous pouvons ensuite configurer quels nœuds doivent être inclus dans ProxySQL et décider si nous utilisons ou non des transactions implicites. Une fois que tout est fait, nous pouvons déployer ProxySQL. Pour une haute disponibilité, vous souhaiterez probablement ajouter un deuxième ProxySQL, puis garder la vie au-dessus d'eux. Keepalived peut également être facilement déployé depuis ClusterControl :
Ici, nous devons choisir les nœuds sur lesquels ProxySQL est déployé, passer le Virtual L'adresse IP et l'interface réseau VIP doivent être attribuées. Une fois cela fait, ClusterControl peut déployer Keepalived pour vous.
Maintenant, regardons le journal d'audit. Toutes les configurations doivent être effectuées sur les deux nœuds ProxySQL. Vous pouvez également utiliser une option pour synchroniser les nœuds :
Deux paramètres régissent le fonctionnement du journal d'audit :
Le premier définit le fichier où les données doivent être stockées, le second indique quelle taille doit avoir le fichier journal avant qu'il ne soit pivoté. Configurons le journal dans le répertoire de données ProxySQL :
Maintenant, nous pouvons jeter un œil aux données que nous voyons dans l'audit fichier journal. Tout d'abord, le format dans lequel les données sont stockées est JSON. Il existe deux types d'événements, l'un lié à la connectivité MySQL et l'autre lié à la connectivité de l'interface d'administration ProxySQL.
Voici un exemple d'entrées déclenchées par le trafic MySQL :
"client_addr": "10.0.0.100:40578",
"event": "MySQL_Client_Connect_OK",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 810,
"time": "2020-01-23 14:24:17.595",
"timestamp": 1579789457595,
"username": "sbtest"
}
{
"client_addr": "10.0.0.100:40572",
"event": "MySQL_Client_Quit",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 807,
"time": "2020-01-23 14:24:17.657",
"timestamp": 1579789457657,
"username": "sbtest"
}
{
"client_addr": "10.0.0.100:40572",
"creation_time": "2020-01-23 14:24:17.357",
"duration": "299.653ms",
"event": "MySQL_Client_Close",
"extra_info": "MySQL_Thread.cpp:4307:process_all_sessions()",
"proxy_addr": "0.0.0.0:6033",
"schemaname": "sbtest",
"ssl": false,
"thread_id": 807,
"time": "2020-01-23 14:24:17.657",
"timestamp": 1579789457657,
"username": "sbtest"
}Comme vous pouvez le voir, la plupart des données se répètent :l'adresse du client, l'adresse ProxySQL, le nom du schéma, si SSL a été utilisé dans les connexions, le numéro de thread associé dans MySQL, l'utilisateur qui a créé la connexion. L'événement "MySQL_Client_Close" contient également des informations sur l'heure à laquelle la connexion a été créée et la durée de la connexion. Vous pouvez également voir quelle partie du code ProxySQL était responsable de la fermeture de la connexion.
Les connexions admin sont assez similaires :
{
"client_addr": "10.0.0.100:52056",
"event": "Admin_Connect_OK",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.490",
"timestamp": 1579789459490,
"username": "proxysql-admin"
}
{
"client_addr": "10.0.0.100:52056",
"event": "Admin_Quit",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.494",
"timestamp": 1579789459494,
"username": "proxysql-admin"
}
{
"client_addr": "10.0.0.100:52056",
"creation_time": "2020-01-23 14:24:19.482",
"duration": "11.795ms",
"event": "Admin_Close",
"extra_info": "MySQL_Thread.cpp:3123:~MySQL_Thread()",
"schemaname": "information_schema",
"ssl": false,
"thread_id": 815,
"time": "2020-01-23 14:24:19.494",
"timestamp": 1579789459494,
"username": "proxysql-admin"
}Les données collectées sont très similaires, la principale différence est qu'elles sont liées aux connexions à l'interface d'administration ProxySQL.
Conclusion
Comme vous pouvez le voir, de manière très simple, vous pouvez activer l'audit de l'accès à ProxySQL. Ceci, en particulier l'accès administratif, est quelque chose qui doit être surveillé du point de vue de la sécurité. Le plugin d'audit le rend assez facile à réaliser.
