Wtyczka audytu MariaDB zapewnia funkcjonalność audytu nie tylko MariaDB, ale także MySQL (od wersji 5.5.34 i 10.0.7) oraz Percona Server. MariaDB zaczęła domyślnie dołączać wtyczkę Audit z wersji 10.0.10 i 5.5.37 i można ją zainstalować w dowolnej wersji z MariaDB 5.5.20.
Celem wtyczki audytu MariaDB jest rejestrowanie aktywności serwera. Dla każdej sesji klienta rejestruje, kto połączył się z serwerem (tj. nazwę użytkownika i hosta), jakie zapytania zostały wykonane, do których tabel uzyskano dostęp oraz zmieniono zmienne serwerowe. Te informacje są przechowywane w rotacyjnym pliku dziennika lub mogą być wysyłane do lokalnego syslogd.
W tym poście na blogu pokażemy kilka najlepszych praktyk i wskazówek, jak skonfigurować rejestrowanie inspekcji dla serwera MariaDB. Pismo oparte jest na MariaDB 10.5.9, z najnowszą wersją wtyczki MariaDB Audit Plugin 1.4.4.
Dostrajanie instalacji
Zalecanym sposobem włączenia rejestrowania kontrolnego jest ustawienie następujących wierszy w pliku konfiguracyjnym MariaDB:
[mariadb]
plugin_load_add = server_audit # load plugin
server_audit=FORCE_PLUS_PERMANENT # do not allow users to uninstall plugin
server_audit_file_path=/var/log/mysql/mariadb-audit.log # path to the audit log
server_audit_logging=ON # enable audit loggingNie zapomnij ustawić „server_audit=FORCE_PLUS_PERMANENT” w celu wymuszenia dziennika audytu i uniemożliwienia jego odinstalowania przez innych użytkowników za pomocą instrukcji UNINSTALL SONAME. Domyślnie miejscem docelowym rejestrowania jest plik dziennika w katalogu danych MariaDB. Powinniśmy umieścić dziennik kontroli poza tym katalogiem, ponieważ istnieje ryzyko, że katalog danych zostanie wyczyszczony (SST dla Galera Cluster) lub zastąpiony w celu przywrócenia fizycznego, takiego jak zamiana katalogów danych podczas przywracania kopii zapasowej pobranej z kopii zapasowej MariaDB.
Konieczne jest dalsze dostrajanie, jak pokazano w poniższych sekcjach.
Filtrowanie zdarzeń audytu
Wtyczka MariaDB Audit wykorzystuje kilka ustawień dziennika, które w zależności od wersji wtyczki. Następujące zdarzenia audytu są dostępne w najnowszej wersji wtyczki 1.4.4:
| Wpisz | Opis |
| POŁĄCZ | Łączy, rozłącza i nieudane połączenia, w tym kod błędu |
| ZAPYTANIE | Wykonane zapytania i ich wyniki w postaci zwykłego tekstu, w tym zapytania nieudane z powodu błędów składniowych lub błędów uprawnień |
| TABELA | Tabele, na które ma wpływ wykonanie zapytania |
| QUERY_DDL | Podobne do QUERY, ale filtruje tylko zapytania typu DDL (instrukcje CREATE, ALTER, DROP, RENAME i TRUNCATE - z wyjątkiem CREATE/DROP [PROCEDURE / FUNCTION / USER] i RENAME USER nie są DDL) |
| QUERY_DML | Podobne do QUERY, ale filtruje tylko zapytania typu DML (instrukcje DO, CALL, LOAD DATA/XML, DELETE, INSERT, SELECT, UPDATE, HANDLER i REPLACE) |
| QUERY_DML_NO_SELECT | Podobne do QUERY_DML, ale nie rejestruje zapytań SELECT. (od wersji 1.4.4) (instrukcje DO, CALL, LOAD DATA/XML, DELETE, INSERT, UPDATE, HANDLER i REPLACE) |
| QUERY_DCL | Podobne do QUERY, ale filtruje tylko zapytania typu DCL (instrukcje CREATE USER, DROP USER, RENAME USER, GRANT, REVOKE i SET PASSWORD) |
Domyślnie będzie śledzić wszystko, ponieważ zmienna server_audit_events będzie domyślnie ustawiona na pustą. Zauważ, że starsze wersje mają mniejszą obsługę powyższego typu operacji, jak pokazano tutaj. Więc upewnij się, że korzystasz z najnowszej wersji, jeśli chcesz przeprowadzić określone filtrowanie.
Jeśli pamięć podręczna zapytań jest włączona, a zapytanie jest zwracane z pamięci podręcznej zapytań, w dzienniku nie pojawią się żadne rekordy TABLE, ponieważ serwer nie otworzył ani nie uzyskał dostępu do żadnych tabel, a zamiast tego korzystał z pamięci podręcznej wyniki. Możesz więc wyłączyć buforowanie zapytań.
Aby odfiltrować określone zdarzenia, ustaw następujący wiersz w pliku konfiguracyjnym MariaDB (wymaga ponownego uruchomienia):
server_audit_events = 'CONNECT,QUERY,TABLE'Lub ustaw go dynamicznie w środowisku wykonawczym za pomocą SET GLOBAL (nie wymaga ponownego uruchomienia, ale nie jest trwały):
MariaDB> SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';To jest przykład jednego zdarzenia kontrolnego:
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0Wpis w tym dzienniku składa się z garści informacji oddzielonych przecinkiem zawierających następujące informacje:
-
Stempel czasu
-
Host MySQL (identyczny z wartością SELECT @@hostname)
-
Użytkownik bazy danych
-
Host, z którym łączy się użytkownik
-
Identyfikator połączenia
-
Identyfikator wątku
-
Operacja
-
Baza danych
-
Oświadczenie/polecenie SQL
-
Kod zwrotny. 0 oznacza, że operacja zwraca odpowiedź powodzenia (nawet pustą), podczas gdy wartość niezerowa oznacza błąd podczas wykonywania operacji, taki jak nieudane zapytanie z powodu błędów składni lub uprawnień.
Podczas filtrowania wpisów należy wykonać proste grep i poszukać określonego wzorca:
$ grep -i global /var/lib/mysql/server_audit.log
20210325 04:19:17,ip-172-31-0-44,root,localhost,14,37080,QUERY,,'set global server_audit_file_rotate_now = 1',0
20210326 00:46:48,ip-172-31-0-44,root,localhost,35,329003,QUERY,,'set global server_audit_output_type = \'syslog\'',0Domyślnie wszystkie wartości haseł będą zamaskowane gwiazdkami:
20210326 05:39:41,ip-172-31-0-44,root,localhost,52,398793,QUERY,mysql,'GRANT ALL PRIVILEGES ON sbtest.* TO [email protected] IDENTIFIED BY *****',0Kontroluj filtrowanie użytkowników
Jeśli śledzisz wszystko, prawdopodobnie zostaniesz zalany przez użytkownika monitorującego za jego odpowiedzialność za próbkowanie, jak pokazano w poniższym przykładzie:
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,226,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,227,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,228,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,229,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,230,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,231,QUERY,information_schema,'SHOW GLOBAL VARIABLES',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,232,QUERY,information_schema,'select @@global.wsrep_provider_options',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,233,QUERY,information_schema,'SHOW SLAVE STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,234,QUERY,information_schema,'SHOW MASTER STATUS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,7,235,QUERY,information_schema,'SHOW SLAVE HOSTS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,236,QUERY,information_schema,'SET GLOBAL SLOW_QUERY_LOG=0',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,5,237,QUERY,information_schema,'FLUSH /*!50500 SLOW */ LOGS',0
20210325 02:02:08,ip-172-31-0-44,cmon,172.31.1.119,6,238,QUERY,information_schema,'SHOW GLOBAL STATUS',0W ciągu jednej sekundy możemy zobaczyć 14 zdarzeń QUERY zarejestrowanych przez wtyczkę audytu dla naszego użytkownika monitorującego o nazwie „cmon”. W naszym obciążeniu testowym szybkość rejestrowania wynosi około 32 KB na minutę, co spowoduje akumulację do 46 MB dziennie. W zależności od rozmiaru magazynu i pojemności we/wy może to być nadmierne w przypadku niektórych obciążeń. Lepiej byłoby więc odfiltrować użytkownika monitorującego z rejestrowania audytu, abyśmy mogli uzyskać czystsze wyniki i znacznie łatwiej je kontrolować i analizować.
W zależności od zasad bezpieczeństwa i audytu, możemy odfiltrować niepożądanego użytkownika, takiego jak użytkownik monitorujący, za pomocą następującej zmiennej w pliku konfiguracyjnym MariaDB (wymaga ponownego uruchomienia):
server_audit_excl_users='cmon'Lub ustaw go dynamicznie w środowisku wykonawczym za pomocą SET GLOBAL (nie wymaga ponownego uruchomienia, ale nie jest trwały):
MariaDB> SET GLOBAL server_audit_excl_users = 'cmon'Możesz dodać wielu użytkowników bazy danych oddzielonych przecinkami. Po dodaniu powyższego otrzymaliśmy czystsze logi audytu, jak poniżej (nic już od użytkownika 'cmon'):
$ tail -f /var/log/mysql/mysql-audit.log
20210325 04:16:06,ip-172-31-0-44,cmon,172.31.1.119,6,36218,QUERY,information_schema,'SHOW GLOBAL STATUS',0
20210325 04:16:06,ip-172-31-0-44,root,localhost,13,36219,QUERY,,'set global server_audit_excl_users = \'cmon\'',0
20210325 04:16:09,ip-172-31-0-44,root,localhost,13,36237,QUERY,,'show global variables like \'%server_audit%\'',0
20210325 04:16:12,ip-172-31-0-44,root,localhost,13,0,DISCONNECT,,,0Zarządzanie rotacją dzienników
Ponieważ dziennik audytu będzie rejestrował ogromną liczbę zdarzeń, zaleca się skonfigurowanie dla niego odpowiedniej rotacji dziennika. W przeciwnym razie otrzymalibyśmy ogromny rozmiar pliku dziennika, który bardzo utrudnia analizę. Gdy serwer jest uruchomiony i server_audit_output_type=file, możemy wymusić rotację pliku dziennika za pomocą następującej instrukcji:
MariaDB> SET GLOBAL server_audit_file_rotate_now = 1;W celu automatycznej rotacji dzienników powinniśmy ustawić następujące zmienne w pliku konfiguracyjnym MariaDB:
server_audit_file_rotate_size=1000000 # in bytes
server_audit_file_rotations=30Lub ustaw to dynamicznie w środowisku wykonawczym za pomocą SET GLOBAL (nie wymaga restartu):
MariaDB> SET GLOBAL server_audit_file_rotate_size=1000000;
MariaDB> SET GLOBAL server_audit_file_rotations=30;Aby wyłączyć rotację dzienników kontroli, po prostu ustaw server_audit_file_rotations na 0. Domyślna wartość to 9. Rotacja dzienników nastąpi automatycznie po osiągnięciu określonego progu i zachowa 30 ostatnich dzienników, co oznacza, że rejestrowanie audytu z ostatnich 30 dni.
Kontrola za pomocą Syslog lub Rsyslog Facility
Korzystanie z funkcji syslog lub rsyslog ułatwi zarządzanie logami, ponieważ umożliwia logowanie z różnych typów systemów w centralnym repozytorium. Zamiast utrzymywać inny składnik rejestrowania, możemy poinstruować MariaDB Audit, aby logował się do syslog. Jest to przydatne, jeśli masz kolektor / streamer dzienników dla usług analizy dzienników, takich jak Splunk, LogStash, Loggly lub Amazon CloudWatch.
W tym celu ustaw następujące wiersze w pliku konfiguracyjnym MariaDB (wymaga ponownego uruchomienia):
server_audit_logging = 'syslog'
server_audit_syslog_ident = 'mariadb-audit'Lub, jeśli chcesz zmienić środowisko wykonawcze (nie wymaga restartu, ale nie jest trwałe):
MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';Wpisy będą podobne do formatu Syslog:
$ grep mariadb-audit /var/log/syslog
Mar 26 00:48:49 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,36,329540,QUERY,,'SET GLOBAL server_audit_syslog_ident = \'mariadb-audit\'',0
Mar 26 00:48:54 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,36,0,DISCONNECT,,,0Jeśli chcesz skonfigurować zdalną usługę rejestrowania dla scentralizowanego repozytorium rejestrowania, możemy użyć rsyslog. Sztuczka polega na użyciu zmiennej server_audit_syslog_facility, gdzie możemy utworzyć filtr ułatwiający logowanie, podobnie jak poniżej:
MariaDB> SET GLOBAL server_audit_logging = 'syslog';
MariaDB> SET GLOBAL server_audit_syslog_ident = 'mariadb-audit';
MariaDB> SET GLOBAL server_audit_syslog_facility = 'LOG_LOCAL6';Jednak wcześniej należy wykonać kilka wstępnych kroków. Rozważ następującą architekturę replikacji MariaDB master-slave ze scentralizowanym serwerem rsyslog:
W tym przykładzie wszystkie serwery działają na Ubuntu 20.04. Na serwerze docelowym rsyslog musimy ustawić następujący plik w /etc/rsyslog.conf:
module(load="imtcp")
input(type="imtcp" port="514")
$ModLoad imtcp
$InputTCPServerRun 514
if $fromhost-ip=='172.31.0.44' then /var/log/mariadb-centralized-audit.log
& ~
if $fromhost-ip=='172.31.0.82' then /var/log/mariadb-centralized-audit.log
& ~Zauważ, że część „&~” jest ważna i nie przegap tego. Zasadniczo mówi narzędziu rejestrującemu, aby zalogować się do /var/log/mariadb-centralized-audit.log i natychmiast przerwać dalsze przetwarzanie.
Następnie utwórz docelowy plik dziennika z poprawnym właścicielem pliku i uprawnieniami:
$ touch /var/log/mariadb-centralized-audit.log
$ chown syslog:adm /var/log/mariadb-centralized-audit.log
$ chmod 640 /var/log/mariadb-centralized-audit.log
Uruchom ponownie rsyslog:
$ systemctl restart rsyslogUpewnij się, że nasłuchuje na wszystkich dostępnych adresach IP na porcie TCP 514:
$ netstat -tulpn | grep rsyslog
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 3143247/rsyslogd
tcp6 0 0 :::514 :::* LISTEN 3143247/rsyslogdZakończyliśmy konfigurację docelowego serwera rsyslog. Teraz jesteśmy gotowi do skonfigurowania części źródłowej. Na serwerze MariaDB utwórz nowy oddzielny plik konfiguracyjny rsyslog w /etc/rsyslog.d/50-mariadb-audit.conf i dodaj następujące wiersze:
$WorkDirectory /var/lib/rsyslog # where to place spool files
$ActionQueueFileName queue1 # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g # 1GB space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
$ActionQueueType LinkedList # run asynchronously
$ActionResumeRetryCount -1 # infinite retries if rsyslog host is down
local6.* action(type="omfwd" target="172.31.6.200" port="514" protocol="tcp")Ustawienia w pierwszej sekcji dotyczą tworzenia kolejki na dysku, co jest zalecane, aby nie utracić żadnego wpisu w dzienniku. Ważna jest ostatnia linijka. Zmieniliśmy zmienną server_audit_syslog_facility na LOG_LOCAL6 dla wtyczki audytu. Tutaj określiliśmy "local6.*" jako filtr, aby przekazywać tylko wpisy Syslog przy użyciu funkcji local6 do rsyslog działającego na serwerze rsyslog 172.31.6.200, na porcie 514 za pośrednictwem protokołu TCP.
Aby aktywować zmiany w rsyslog, ostatnim krokiem jest ponowne uruchomienie rsyslog na serwerze MariaDB w celu aktywowania zmian:
$ systemctl restart rsyslogTeraz rsyslog jest poprawnie skonfigurowany w węźle źródłowym. Możemy przetestować, uzyskując dostęp do serwera MariaDB i wykonując pewne czynności w celu wygenerowania zdarzeń audytu. Powinieneś zobaczyć, że wpisy dziennika kontroli są przekazywane tutaj:
$ tail -f /var/log/mariadb-centralized-audit.log
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,0,CONNECT,,,0
Mar 26 12:56:18 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,489413,QUERY,,'select @@version_comment limit 1',0
Mar 26 12:56:19 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,489414,QUERY,,'show databases',0
Mar 26 12:56:37 ip-172-31-0-44 mariadb-audit: ip-172-31-0-44,root,localhost,69,0,DISCONNECT,,,0Ostateczne myśli
Wtyczka audytu MariaDB może być skonfigurowana na wiele sposobów, aby dostosować ją do zasad bezpieczeństwa i audytu. Informacje kontrolne mogą pomóc w rozwiązywaniu problemów z wydajnością lub aplikacjami oraz pozwalają dokładnie zobaczyć, jakie zapytania SQL są przetwarzane.
