ProxySQL blev en meget vigtig del af infrastrukturen i databasemiljøerne. Den fungerer som en load balancer, den er med til at forme trafikkens flow og reducere nedetiden. Med store magtbeføjelser følger store forpligtigelser. Hvordan kan du holde dig opdateret om, hvem der har adgang til ProxySQL-konfigurationen? Hvem opretter forbindelse til databasen via ProxySQL? Disse spørgsmål kan besvares ved hjælp af ProxySQL Audit Log, som er tilgængelig fra ProxySQL 2.0.5. I dette blogindlæg vil vi se på, hvordan du aktiverer denne funktion, og hvordan logindholdet ser ud.
De første trin vil være at implementere ProxySQL. Det kan vi nemt gøre ved hjælp af ClusterControl - både MySQL-replikering og Galera Cluster-typer understøtter ProxySQL-implementering.
Forudsat at vi har en klynge oppe at køre, kan vi implementere ProxySQL fra Manage -> LoadBalancers:
Vi skal beslutte, hvilken node ProxySQL skal installeres på, dens version ( vi beholder standard 2.x) og definerer legitimationsoplysninger for ProxySQL administrative og overvågningsbrugere.
Nedenfor kan vi enten importere eksisterende applikationsbrugere fra databasen eller oprette en ny en ved at tildele navn, adgangskode, skema og MySQL-privilegier. Vi kan derefter konfigurere hvilke noder der skal inkluderes i ProxySQL og beslutte om vi bruger implicitte transaktioner eller ej. Når alt er gjort, kan vi implementere ProxySQL. For høj tilgængelighed vil du sandsynligvis tilføje en anden ProxySQL og derefter holde i live oven på dem. Keepalived kan også nemt implementeres fra ClusterControl:
Her skal vi vælge noder, som ProxySQL er installeret på, videregive den virtuelle IP og netværksgrænseflade VIP skal tildeles. Når dette er gjort, kan ClusterControl implementere Keepalived for dig.
Lad os nu tage et kig på revisionsloggen. Alle konfigurationer skal udføres på begge ProxySQL-noder. Alternativt kan du bruge en mulighed for at synkronisere noderne:
Der er to indstillinger, der styrer, hvordan revisionsloggen skal fungere:
Den første definerer filen, hvor data skal gemmes, den anden fortæller hvor stor logfilen skal være, før den bliver roteret. Lad os konfigurere log i ProxySQL-datamappe:
Nu kan vi tage et kig på de data, vi ser i revisionen logfil. Først og fremmest er formatet, som data gemmes i, JSON. Der er to typer begivenheder, en relateret til MySQL-forbindelse og anden relateret til ProxySQL-admin-grænsefladeforbindelse.
Her er et eksempel på poster udløst af MySQL-trafik:
"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"
}Som du kan se, gentages de fleste data:klientadresse, ProxySQL-adresse, skemanavn, hvis SSL blev brugt i forbindelser, relateret trådnummer i MySQL, bruger, der oprettede forbindelsen. Hændelsen "MySQL_Client_Close" indeholder også information om tidspunktet, hvor forbindelsen blev oprettet, og varigheden af forbindelsen. Du kan også se, hvilken del af ProxySQL-koden, der var ansvarlig for at lukke forbindelsen.
Administratorforbindelser er ret ens:
{
"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"
}De indsamlede data er meget ens, den største forskel er, at de er relateret til forbindelser til den administrative grænseflade til ProxySQL.
Konklusion
Som du kan se, kan du på en meget nem måde aktivere revision af adgangen til ProxySQL. Dette, især den administrative adgang, er noget, der bør overvåges ud fra et sikkerhedssynspunkt. Audit plugin gør det ret nemt at udføre.