sql >> Databáze >  >> RDS >> Mysql

Pochopení protokolu auditu ProxySQL

ProxySQL se stal velmi důležitou součástí infrastruktury v databázových prostředích. Funguje jako load balancer, pomáhá utvářet plynulost provozu a zkracovat prostoje. S velkou mocí přichází velká zodpovědnost. Jak můžete mít aktuální informace o tom, kdo přistupuje ke konfiguraci ProxySQL? Kdo se připojuje k databázi přes ProxySQL? Tyto otázky lze zodpovědět pomocí protokolu auditu ProxySQL, který je k dispozici od verze ProxySQL 2.0.5. V tomto příspěvku na blogu se podíváme na to, jak tuto funkci povolit a jak vypadá obsah protokolu.

Počátečními kroky bude nasazení ProxySQL. Můžeme to snadno udělat pomocí ClusterControl – oba typy MySQL Replication a Galera Cluster podporují nasazení ProxySQL.

Za předpokladu, že máme cluster spuštěný a spuštěný, můžeme nasadit ProxySQL z Manage -> LoadBalancers:

Musíme se rozhodnout, který uzel má být nainstalován ProxySQL, jeho verzi ( ponecháme výchozí 2.x) a definujeme přihlašovací údaje pro uživatele pro správu a monitorování ProxySQL.

Níže můžeme buď importovat stávající uživatele aplikace z databáze, nebo vytvořit novou jeden přiřazením jména, hesla, schématu a oprávnění MySQL. Poté můžeme nakonfigurovat, které uzly by měly být zahrnuty do ProxySQL, a rozhodnout, zda použijeme implicitní transakce nebo ne. Jakmile je vše hotovo, můžeme nasadit ProxySQL. Pro vysokou dostupnost pravděpodobně budete chtít přidat druhý ProxySQL a poté jej udržovat naživu. Keepalived lze také snadno nasadit z ClusterControl:

Zde musíme vybrat uzly, na kterých je nasazen ProxySQL, předat virtuální IP a síťové rozhraní VIP by měly být přiřazeny. Jakmile to uděláte, může ClusterControl nasadit Keepalived za vás.

Nyní se podíváme na protokol auditu. Všechny konfigurace by měly být prováděny na obou uzlech ProxySQL. Případně můžete použít volbu pro synchronizaci uzlů:

Existují dvě nastavení, která určují, jak by měl protokol auditu fungovat:

První definuje soubor, kam mají být data uložena, druhý říká jak velký by měl být soubor protokolu, než bude otočen. Pojďme nakonfigurovat log v datovém adresáři ProxySQL:

Nyní se můžeme podívat na data, která vidíme v auditu log soubor. Za prvé, formát, ve kterém jsou data uložena, je JSON. Existují dva typy událostí, jedna souvisí s konektivitou MySQL a druhá souvisí s konektivitou administrátorského rozhraní ProxySQL.

Zde je příklad položek spouštěných provozem 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"

}

Jak vidíte, většina dat se opakuje:adresa klienta, adresa ProxySQL, název schématu, pokud bylo v připojeních použito SSL, související číslo vlákna v MySQL, uživatel, který připojení vytvořil. Událost „MySQL_Client_Close“ také obsahuje informace o čase vytvoření připojení a délce připojení. Můžete také vidět, která část kódu ProxySQL byla zodpovědná za uzavření připojení.

Administrátorská připojení jsou velmi podobná:

{

  "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"

}

Shromážděná data jsou velmi podobná, hlavní rozdíl je v tom, že souvisí s připojením k administrativnímu rozhraní ProxySQL.

Závěr

Jak vidíte, velmi jednoduchým způsobem můžete povolit auditování přístupu k ProxySQL. To, zejména administrativní přístup, je něco, co by mělo být sledováno z hlediska bezpečnosti. Zásuvný modul auditu to docela usnadňuje.


  1. PreparedStatement a setTimestamp v oracle jdbc

  2. Jak opravit běžné problémy s databází MySQL?

  3. Android:Jak znovu požádat kurzor o obnovení ListView po smazání řádku databáze?

  4. Jak povolím php pracovat s postgresql?