ProxySQL stał się bardzo ważną częścią infrastruktury w środowiskach baz danych. Działa jako load balancer, pomaga kształtować przepływ ruchu i skrócić przestoje. Z dużą mocą przychodzi duża odpowiedzialność. Jak możesz być na bieżąco z tym, kto ma dostęp do konfiguracji ProxySQL? Kto łączy się z bazą danych przez ProxySQL? Na te pytania można odpowiedzieć za pomocą dziennika audytu ProxySQL, który jest dostępny od wersji ProxySQL 2.0.5. W tym poście na blogu przyjrzymy się, jak włączyć tę funkcję i jak wygląda zawartość dziennika.
Pierwszymi krokami będzie wdrożenie ProxySQL. Możemy to łatwo zrobić za pomocą ClusterControl - zarówno MySQL Replication, jak i Galera Cluster obsługują wdrażanie ProxySQL.
Zakładając, że mamy działający klaster, możemy wdrożyć ProxySQL z Zarządzaj -> LoadBalancers:
Musimy zdecydować na którym węźle ma być zainstalowany ProxySQL, jego wersji ( zachowamy domyślne 2.x) i zdefiniujemy poświadczenia dla użytkowników administracyjnych i monitorujących ProxySQL.
Poniżej możemy zaimportować istniejących użytkowników aplikacji z bazy danych lub utworzyć nową jeden poprzez przypisanie nazwy, hasła, schematu i uprawnień MySQL. Możemy wtedy skonfigurować, które węzły powinny być zawarte w ProxySQL i zdecydować, czy używamy transakcji niejawnych, czy nie. Gdy wszystko zostanie zrobione, możemy wdrożyć ProxySQL. Aby zapewnić wysoką dostępność, prawdopodobnie zechcesz dodać drugi serwer ProxySQL, a następnie utrzymać go na wierzchu. Keepalived można również łatwo wdrożyć z ClusterControl:
Tutaj musimy wybrać węzły, na których ProxySQL jest wdrożony, przekazać Wirtualny Należy przypisać adres IP i interfejs sieciowy VIP. Gdy to zrobisz, ClusterControl może wdrożyć dla Ciebie Keepalived.
Teraz przyjrzyjmy się dziennikowi audytu. Wszystkie konfiguracje powinny być wykonywane na obu węzłach ProxySQL. Alternatywnie możesz użyć opcji synchronizacji węzłów:
Są dwa ustawienia określające sposób działania dziennika kontrolnego:
Pierwszy określa plik, w którym mają być przechowywane dane, drugi mówi jak duży powinien być plik dziennika, zanim zostanie obrócony. Skonfigurujmy log w katalogu danych ProxySQL:
Teraz możemy przyjrzeć się danym, które widzimy w audycie plik dziennika. Przede wszystkim format, w którym przechowywane są dane, to JSON. Istnieją dwa rodzaje zdarzeń, jedno związane z łącznością MySQL, a drugie związane z łącznością interfejsu administratora ProxySQL.
Oto przykład wpisów wyzwolonych przez ruch 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 widać, większość danych się powtarza:adres klienta, adres ProxySQL, nazwa schematu, jeśli w połączeniach był używany SSL, powiązany numer wątku w MySQL, użytkownik, który utworzył połączenie. Zdarzenie „MySQL_Client_Close” zawiera również informacje o czasie utworzenia połączenia i czasie trwania połączenia. Możesz również zobaczyć, która część kodu ProxySQL była odpowiedzialna za zamknięcie połączenia.
Połączenia administracyjne są dość podobne:
{
"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"
}Zbierane dane są bardzo podobne, główna różnica polega na tym, że są one związane z połączeniami z interfejsem administracyjnym ProxySQL.
Wnioski
Jak widać, w bardzo prosty sposób można włączyć audyt dostępu do ProxySQL. To, zwłaszcza dostęp administracyjny, powinno być monitorowane z punktu widzenia bezpieczeństwa. Wtyczka audytu sprawia, że jest to dość łatwe do wykonania.
