Ochrona danych jest jednym z najważniejszych aspektów administrowania bazą danych. W zależności od struktury organizacyjnej, niezależnie od tego, czy jesteś programistą, administratorem czy administratorem baz danych, jeśli zarządzasz produkcyjną bazą danych, musisz monitorować dane pod kątem nieautoryzowanego dostępu i użycia. Cel monitorowania bezpieczeństwa jest dwojaki. Jeden, aby zidentyfikować nieautoryzowane działania w bazie danych. I po drugie, aby sprawdzić, czy bazy danych i ich konfiguracje w całej firmie są zgodne z politykami i standardami bezpieczeństwa.
W tym artykule podzielimy monitoring bezpieczeństwa na dwie kategorie. Jedna będzie związana z audytem działań baz danych MySQL i MariaDB. Druga kategoria będzie dotyczyć monitorowania Twoich instancji pod kątem potencjalnych luk w zabezpieczeniach.
Monitorowanie oparte na zapytaniach i połączeniach
Ciągły audyt jest niezbędnym zadaniem monitorowania środowiska bazy danych. Dzięki audytowi bazy danych możesz uzyskać odpowiedzialność za podjęte działania lub dostęp do treści. Co więcej, audyt może obejmować pewne krytyczne elementy systemu, takie jak te związane z danymi finansowymi w celu wsparcia precyzyjnego zestawu regulacji, takich jak SOX, czy unijne rozporządzenie RODO. Zwykle osiąga się to poprzez rejestrowanie informacji o operacjach DB na bazie danych do zewnętrznego pliku dziennika.
Domyślnie inspekcja w MySQL lub MariaDB jest wyłączona. Ty i osiągasz to, instalując dodatkowe wtyczki lub przechwytując wszystkie zapytania za pomocą parametru query_log. Ogólny plik dziennika zapytań jest ogólnym zapisem tego, co wykonuje MySQL. Serwer zapisuje w tym dzienniku pewne informacje, gdy klienci łączą się lub rozłączają, i rejestruje każdą instrukcję SQL otrzymaną od klientów. Ze względu na problemy z wydajnością i brak opcji konfiguracyjnych, general_log nie jest dobrym rozwiązaniem do celów audytu bezpieczeństwa.
Jeśli korzystasz z MySQL Enterprise, możesz skorzystać z wtyczki MySQL Enterprise Audit, która jest rozszerzeniem autorskiej wersji MySQL. Wtyczka MySQL Enterprise Audit Plugin jest dostępna tylko z MySQL Enterprise, która jest komercyjną ofertą firmy Oracle. Percona i MariaDB stworzyły własne wersje wtyczki audytu typu open source. Wreszcie, wtyczka McAfee do MySQL może być również używana z różnymi wersjami MySQL. W tym artykule skupimy się na wtyczkach typu open source, chociaż wersja Enterprise firmy Oracle wydaje się być najbardziej niezawodna i stabilna.
Charakterystyka wtyczek MySQL Open Source Audit
Podczas gdy wtyczki audytu open source wykonują tę samą pracę, co wtyczka Enterprise firmy Oracle – generują dane wyjściowe z zapytaniami i połączeniami do bazy danych – istnieją pewne główne różnice architektoniczne.
MariaDB Audit Plugin — MariaDB Audit Plugin współpracuje z MariaDB, MySQL (od wersji 5.5.34 i 10.0.7) oraz Percona Server. MariaDB zaczęła domyślnie dołączać wtyczkę Audit od wersji 10.0.10 i 5.5.37 i można ją zainstalować w dowolnej wersji od MariaDB 5.5.20. Jest to jedyna wtyczka obsługująca Oracle MySQL, Percona Server i MariaDB. Jest dostępny na platformę Windows i Linux. Wersje zaczynające się od 1.2 są najbardziej stabilne i używanie wersji niższych w środowisku produkcyjnym może być ryzykowne.
McAfee MySQL Audit Plugin – Ta wtyczka nie korzysta z interfejsu API audytu MySQL. Został niedawno zaktualizowany do obsługi MySQL 5.7. Niektóre testy pokazują, że wtyczki oparte na API mogą zapewnić lepszą wydajność, ale musisz to sprawdzić w swoim środowisku.
Wtyczka dziennika audytu Percona — Percona zapewnia rozwiązanie audytu typu open source, które jest instalowane z Percona Server 5.5.37+ i 5.6.17+ w ramach procesu instalacji. W porównaniu do innych wtyczek typu open source, ta wtyczka ma więcej funkcji wyjściowych o zasięgu, ponieważ generuje XML, JSON i syslog.
Ponieważ ma pewne wewnętrzne zaczepy do serwera, aby być kompatybilnym z wtyczką Oracle, nie jest dostępny jako samodzielna wtyczka dla innych wersji MySQL.
Instalacja wtyczki na podstawie rozszerzenia audytu MariaDB
Instalacja wtyczek MySQL typu open source jest dość podobna dla wersji MariaDB, Percona i McAfee.
Percona i MariaDB dodają swoje wtyczki jako część domyślnych plików binarnych serwera, więc nie ma potrzeby oddzielnego pobierania wtyczek. Wersja Percona tylko oficjalnie obsługuje własny fork MySQL, więc nie ma bezpośredniego pobierania ze strony internetowej dostawcy (jeśli chcesz używać tej wtyczki z MySQL, musisz pobrać wtyczkę z pakietu serwera Percona). Jeśli chcesz używać wtyczki MariaDB z innymi forkami MySQL, możesz ją znaleźć pod adresem https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. Wtyczka McAfee jest dostępna pod adresem https://github.com/mcafee/mysql-audit/wiki/Installation.
Przed rozpoczęciem instalacji wtyczki możesz sprawdzić, czy wtyczka jest obecna w systemie. Lokalizację wtyczki dynamicznej (nie wymaga restartu instancji) można sprawdzić za pomocą:
SHOW GLOBAL VARIABLES LIKE 'plugin_dir';
+---------------+--------------------------+
| Variable_name | Value |
+---------------+--------------------------+
| plugin_dir | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+Sprawdź katalog zwrócony na poziomie systemu plików, aby upewnić się, że masz kopię biblioteki wtyczek. Jeśli nie masz server_audit.so lub server_audit.dll w /usr/lib64/mysql/plugin/, prawdopodobnie Twoja wersja MariaDB nie jest obsługiwana i powinna zostać uaktualniona do najnowszej wersji.
Składnia instalacji wtyczki MariaDB to:
INSTALL SONAME 'server_audit';Aby sprawdzić zainstalowane wtyczki, musisz uruchomić:
SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name | Status | Type | Library | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| mysql_old_password | ACTIVE | AUTHENTICATION | NULL | GPL |
| wsrep | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CSV | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CLIENT_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INDEX_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| TABLE_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| USER_STATISTICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
...
| INNODB_MUTEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_SYS_SEMAPHORE_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| INNODB_TABLESPACES_SCRUBBING | ACTIVE | INFORMATION SCHEMA | NULL | BSD |
| Aria | ACTIVE | STORAGE ENGINE | NULL | GPL |
| SEQUENCE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| user_variables | ACTIVE | INFORMATION SCHEMA | NULL | GPL |
| FEEDBACK | DISABLED | INFORMATION SCHEMA | NULL | GPL |
| partition | ACTIVE | STORAGE ENGINE | NULL | GPL |
| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |
| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |
| SERVER_AUDIT | ACTIVE | AUDIT | server_audit.so | GPL |
+-------------------------------+----------+--------------------+--------------------+---------+Jeśli potrzebujesz dodatkowych informacji, sprawdź tabelę PLUGINS w bazie danych information_schema, która zawiera bardziej szczegółowe informacje.
Innym sposobem zainstalowania wtyczki jest włączenie wtyczki w my.cnf i ponowne uruchomienie instancji. Przykładem podstawowej konfiguracji wtyczki audytu z MariaDB może być:
server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024Powyższe ustawienie należy umieścić w my.cnf. Wtyczka audytu utworzy plik /var/log/mysql/audit.log, który będzie się obracał w rozmiarze 1GB i będzie osiem obrotów, dopóki plik nie zostanie nadpisany. Plik będzie zawierał tylko informacje o połączeniach.
Obecnie istnieje szesnaście ustawień, których można użyć do dostosowania wtyczki audytu MariaDB.
server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priorityWśród nich można znaleźć opcje uwzględniania lub wykluczania użytkowników, ustawiania różnych zdarzeń rejestrowania (CONNECT lub QUERY) oraz przełączania między plikiem a dziennikiem systemowym.
Aby upewnić się, że wtyczka zostanie włączona po uruchomieniu serwera, musisz ustawić
plugin_load=server_audit=server_audit.so w ustawieniach my.cnf. Taka konfiguracja może być dodatkowo zabezpieczona przez server_audit=FORCE_PLUS_PERMANENT, który wyłączy opcję dezinstalacji wtyczki.
UNINSTALL PLUGIN server_audit;
ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloadedOto kilka przykładowych wpisów stworzonych przez wtyczkę audytu MariaDB:
20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0Raport zmian schematu
Jeśli chcesz śledzić tylko zmiany DDL, możesz użyć raportu operacyjnego ClusterControl dotyczącego zmiany schematu. Raport wykrywania zmian schematu pokazuje wszelkie zmiany DDL w Twojej bazie danych. Ta funkcja wymaga dodatkowego parametru w pliku konfiguracyjnym ClusterControl. Jeśli to nie jest ustawione, zobaczysz następujące informacje:schema_change_detection_address nie jest ustawiony w /etc/cmon.d/cmon_1.cnf. Gdy to nastąpi, przykładowe wyjście może wyglądać jak poniżej:
Można go skonfigurować za pomocą harmonogramu i raportów przesyłanych pocztą elektroniczną do odbiorców.
ClusterControl:Zaplanuj raport operacyjny Ocena bezpieczeństwa bazy danych MySQL
Sprawdzenie aktualizacji pakietu
Najpierw zaczniemy od kontroli bezpieczeństwa. Bycie na bieżąco z łatami MySQL pomoże zmniejszyć ryzyko związane ze znanymi lukami w serwerze MySQL. Możesz aktualizować swoje środowisko, korzystając z repozytorium pakietów dostawców. Na podstawie tych informacji możesz tworzyć własne raporty lub korzystać z narzędzi takich jak ClusterControl, aby zweryfikować swoje środowisko i powiadomić Cię o możliwych aktualizacjach.
Raport aktualizacji ClusterControl zbiera informacje z systemu operacyjnego i porównuje je z pakietami dostępnymi w repozytorium. Raport podzielony jest na cztery sekcje; podsumowanie aktualizacji, pakiety baz danych, pakiety bezpieczeństwa i inne pakiety. Możesz szybko porównać to, co zainstalowałeś w swoim systemie i znaleźć zalecaną aktualizację lub poprawkę.
ClusterControl:raport z aktualizacji 
ClusterControl:szczegóły raportu uaktualnienia Aby porównać je ręcznie, możesz uruchomić
SHOW VARIABLES WHERE variable_name LIKE "version";
Z biuletynami bezpieczeństwa, takimi jak:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- wyników?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/LATEST/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html
Lub repozytoria dostawców:
W Debianie
sudo apt list mysql-serverNa RHEL/Centos
yum list | grep -i mariadb-serverKonta bez hasła
Puste hasła pozwalają użytkownikowi zalogować się bez użycia hasła. MySQL był dostarczany z zestawem wstępnie utworzonych użytkowników, z których niektórzy mogą łączyć się z bazą danych bez hasła lub, co gorsza, anonimowymi użytkownikami. Na szczęście zmieniło się to w MySQL 5.7. Wreszcie, jest dostępny tylko z kontem root, które używa hasła wybranego podczas instalacji.
Dla każdego wiersza zwróconego z procedury audytu ustaw hasło:
SELECT User,host
FROM mysql.user
WHERE authentication_string='';Dodatkowo możesz zainstalować wtyczkę do weryfikacji hasła i wdrożyć bezpieczniejszą politykę:
INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';Dobrym początkiem może być:
plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUMOczywiście te ustawienia będą zależeć od Twoich potrzeb biznesowych.
Zdalne monitorowanie dostępu
Unikanie używania symboli wieloznacznych w nazwach hostów pomaga kontrolować określone lokalizacje, z których dany użytkownik może łączyć się i wchodzić w interakcje z bazą danych.
Powinieneś upewnić się, że każdy użytkownik może łączyć się z MySQL tylko z określonych hostów. Zawsze możesz zdefiniować kilka wpisów dla tego samego użytkownika, powinno to pomóc w zmniejszeniu potrzeby stosowania symboli wieloznacznych.
Wykonaj następującą instrukcję SQL, aby ocenić to zalecenie (upewnij się, że nie są zwracane żadne wiersze):
SELECT user, host FROM mysql.user WHERE host = '%';Baza danych testowych
Domyślna instalacja MySQL zawiera nieużywaną bazę danych o nazwie test, a testowa baza danych jest dostępna dla każdego użytkownika, zwłaszcza dla użytkowników anonimowych. Tacy użytkownicy mogą tworzyć tabele i pisać do nich. Potencjalnie może to stanowić problem sam w sobie – a zapisy zwiększą obciążenie i zmniejszą wydajność bazy danych. Zaleca się usunięcie testowej bazy danych. Aby sprawdzić, czy testowa baza danych jest obecna, uruchom:
SHOW DATABASES LIKE 'test';Jeśli zauważysz, że testowa baza danych jest obecna, może to oznaczać, że skrypt mysql_secure_installation, który usuwa testową bazę danych (jak również inne działania związane z bezpieczeństwem), nie został wykonany.
WCZYTAJ ZBIORNIK DANYCH
Jeśli zarówno serwer, jak i klient mają możliwość uruchomienia LOAD DATA LOCAL INFILE, klient będzie mógł załadować dane z lokalnego pliku na zdalny serwer MySQL. Parametr local_infile określa, czy pliki znajdujące się na komputerze klienta MySQL mogą być ładowane lub wybierane przez LOAD DATA INFILE lub SELECT local_file.
Potencjalnie może to pomóc w odczytywaniu plików, do których klient ma dostęp - na przykład na serwerze aplikacji można uzyskać dostęp do dowolnych danych, do których ma dostęp serwer HTTP. Aby tego uniknąć, musisz ustawić local-infile=0 w my.cnf.
Wykonaj następującą instrukcję SQL i upewnij się, że pole Value jest ustawione na OFF:
SHOW VARIABLES WHERE Variable_name = 'local_infile';Monitoruj niezaszyfrowane przestrzenie tabel
Począwszy od MySQL 5.7.11, InnoDB obsługuje szyfrowanie danych dla tabel przechowywanych w obszarach tabel typu plik na tabelę. Ta funkcja zapewnia szyfrowanie w stanie spoczynku dla fizycznych plików danych obszaru tabel. Aby sprawdzić, czy Twoje tabele zostały zaszyfrowane, uruchom:
mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';
+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test | t1 | ENCRYPTION="Y" |
+--------------+------------+----------------+W ramach szyfrowania należy również rozważyć szyfrowanie dziennika binarnego. Serwer MySQL zapisuje mnóstwo informacji w dziennikach binarnych.
Weryfikacja połączenia szyfrującego
W niektórych konfiguracjach baza danych nie powinna być dostępna przez sieć, jeśli każde połączenie jest zarządzane lokalnie, przez gniazdo Unix. W takich przypadkach możesz dodać zmienną „skip-networking” w my.cnf. Pomijanie sieci uniemożliwia MySQL korzystanie z dowolnego połączenia TCP/IP, a w Linuksie możliwe byłoby tylko gniazdo Unix.
Jest to jednak dość rzadka sytuacja, ponieważ powszechny jest dostęp do MySQL przez sieć. Następnie musisz monitorować, czy Twoje połączenia są szyfrowane. MySQL obsługuje SSL jako środek do szyfrowania ruchu zarówno pomiędzy serwerami MySQL (replikacja), jak i pomiędzy serwerami MySQL i klientami. W przypadku korzystania z klastra Galera dostępne są podobne funkcje - zarówno komunikacja wewnątrz klastra, jak i połączenia z klientami mogą być szyfrowane za pomocą protokołu SSL. Aby sprawdzić, czy używasz szyfrowania SSL, uruchom następujące zapytania:
SHOW variables WHERE variable_name = 'have_ssl';
select ssl_verify_server_cert from mysql.slave_master_info;Na razie to wszystko. To nie jest pełna lista, daj nam znać, jeśli są jakieś inne kontrole, które wykonujesz dzisiaj w swoich produkcyjnych bazach danych.
