ProxySQL è diventato una parte molto importante dell'infrastruttura negli ambienti di database. Funziona come un bilanciatore di carico, aiuta a modellare il flusso del traffico e ridurre i tempi di fermo. Con un grande potere viene una grande responsabilità. Come puoi rimanere aggiornato su chi sta accedendo alla configurazione di ProxySQL? Chi si connette al database tramite ProxySQL? È possibile rispondere a queste domande utilizzando ProxySQL Audit Log, disponibile a partire da ProxySQL 2.0.5. In questo post del blog esamineremo come abilitare questa funzione e come appaiono i contenuti del registro.
I passaggi iniziali saranno la distribuzione di ProxySQL. Possiamo farlo facilmente utilizzando ClusterControl:entrambi i tipi MySQL Replication e Galera Cluster supportano la distribuzione ProxySQL.
Supponendo di avere un cluster attivo e funzionante, possiamo distribuire ProxySQL da Gestisci -> LoadBalancers:
Dobbiamo decidere quale nodo ProxySQL deve essere installato, la sua versione ( manterremo l'impostazione predefinita 2.x) e definiremo le credenziali per gli utenti di amministrazione e monitoraggio di ProxySQL.
Di seguito possiamo importare gli utenti dell'applicazione esistenti dal database o crearne una nuova uno assegnando nome, password, schema e privilegi MySQL. Possiamo quindi configurare quali nodi devono essere inclusi in ProxySQL e decidere se utilizzare le transazioni implicite o meno. Una volta fatto tutto, possiamo distribuire ProxySQL. Per un'elevata disponibilità probabilmente vorrai aggiungere un secondo ProxySQL e poi mantenerlo in vita su di esso. Keepalived può anche essere facilmente distribuito da ClusterControl:
Qui dobbiamo selezionare i nodi su cui è distribuito ProxySQL, passare il Virtual L'IP e l'interfaccia di rete devono essere assegnati a VIP. Al termine, ClusterControl può distribuire Keepalived per te.
Ora, diamo un'occhiata al registro di controllo. Tutte le configurazioni devono essere eseguite su entrambi i nodi ProxySQL. In alternativa puoi utilizzare un'opzione per sincronizzare i nodi:
Ci sono due impostazioni che regolano il funzionamento del registro di controllo:
Il primo definisce il file in cui devono essere archiviati i dati, il secondo dice quanto deve essere grande il file di registro prima che venga ruotato. Configuriamo la directory dei dati di accesso ProxySQL:
Ora possiamo dare un'occhiata ai dati che vediamo nell'audit file di registro. Innanzitutto, il formato in cui vengono archiviati i dati è JSON. Esistono due tipi di eventi, uno relativo alla connettività MySQL e il secondo relativo alla connettività dell'interfaccia di amministrazione ProxySQL.
Ecco un esempio di voci attivate dal traffico 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"
}Come puoi vedere, la maggior parte dei dati si ripete:indirizzo client, indirizzo ProxySQL, nome dello schema, se SSL è stato utilizzato nelle connessioni, numero di thread correlato in MySQL, utente che ha creato la connessione. L'evento "MySQL_Client_Close" contiene anche informazioni sull'ora in cui è stata creata la connessione e sulla durata della connessione. Puoi anche vedere quale parte del codice ProxySQL è stata responsabile della chiusura della connessione.
Le connessioni dell'amministratore sono abbastanza simili:
{
"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"
}I dati raccolti sono molto simili, la differenza principale è che sono relativi alle connessioni all'interfaccia amministrativa di ProxySQL.
Conclusione
Come puoi vedere, in un modo molto semplice puoi abilitare l'auditing dell'accesso a ProxySQL. Questo, in particolare l'accesso amministrativo, è qualcosa che dovrebbe essere monitorato dal punto di vista della sicurezza. Il plug-in Audit lo rende abbastanza facile da realizzare.
