Bezpieczeństwo danych jest obecnie najwyższym priorytetem. Czasami jest to egzekwowane przez zewnętrzne regulacje, takie jak PCI-DSS lub HIPAA, czasami dlatego, że dbasz o dane swoich klientów i swoją reputację. Istnieje wiele aspektów bezpieczeństwa, o których należy pamiętać - dostęp do sieci, bezpieczeństwo systemu operacyjnego, granty, szyfrowanie i tak dalej. W tym poście na blogu podamy 10 wskazówek, na co zwrócić uwagę podczas zabezpieczania konfiguracji MySQL lub MariaDB.
1. Usuń użytkowników bez 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. Zmieniło się to w MySQL 5.7, który domyślnie jest dostarczany tylko z kontem root, które używa hasła wybranego podczas instalacji. Mimo to istnieją instalacje MySQL, które zostały zaktualizowane z poprzednich wersji i te instalacje zachowują starszych użytkowników. Ponadto MariaDB 10.2 na Centos 7 ma anonimowych użytkowników:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)Jak widać, są one ograniczone tylko do dostępu z lokalnego hosta, ale niezależnie od tego, nie chcesz mieć takich użytkowników. Chociaż ich uprawnienia są ograniczone, nadal mogą uruchamiać niektóre polecenia, które mogą pokazać więcej informacji o bazie danych - na przykład wersja może pomóc w zidentyfikowaniu dalszych kierunków ataku.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------Należy pamiętać, że użytkownicy z bardzo prostymi hasłami są prawie tak samo niebezpieczni, jak użytkownicy bez hasła. Hasła takie jak „hasło” lub „qwerty” nie są zbyt pomocne.
2. Ścisły dostęp zdalny
Przede wszystkim zdalny dostęp dla superużytkowników - jest to domyślnie zapewniane przy instalacji najnowszej wersji MySQL (5.7) lub MariaDB (10.2) - dostępny jest tylko dostęp lokalny. Mimo to dość często zdarza się, że superużytkownicy są dostępni z różnych powodów. Najczęstszy, prawdopodobnie dlatego, że bazą danych zarządzają ludzie, którzy chcą ułatwić sobie pracę, więc dodaliby zdalny dostęp do swoich baz danych. Nie jest to dobre podejście, ponieważ zdalny dostęp ułatwia wykorzystanie potencjalnych (lub zweryfikowanych) luk bezpieczeństwa w MySQL - nie musisz najpierw nawiązywać połączenia z hostem.
Kolejny krok - upewnij 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 ([email protected], [email protected]), powinno to pomóc w zmniejszeniu zapotrzebowania na symbole wieloznaczne ([email protected] „%”).
3. Usuń testową bazę danych
Testowa baza danych domyślnie 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 — wszelkie zapisy zwiększyłyby obciążenie i zmniejszyły wydajność bazy danych. Obecnie, po domyślnej instalacji, dotyczy to tylko MariaDB 10.2 na Centos 7 — Oracle MySQL 5.7 i Percona Server 5.7 nie mają dostępnego schematu „testowego”.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)Oczywiście może się zdarzyć, że Twój MySQL 5.7 został zaktualizowany z poprzednich wersji, w których nie usunięto schematu „testowego” - powinieneś się tym zająć i sprawdzić, czy go utworzyłeś.
4. Ukryj dostęp do MySQL
Powszechnie wiadomo, że MySQL działa na porcie 3306, a jego superużytkownik nazywa się „root”. Aby to utrudnić, dość łatwo to zmienić. W pewnym stopniu jest to przykład zabezpieczenia przez ukrywanie, ale może przynajmniej powstrzymać zautomatyzowane próby uzyskania dostępu do użytkownika „root”. Aby zmienić port, musisz wyedytować my.cnf i ustawić zmienną „port” na inną wartość. Jeśli chodzi o użytkowników - po zainstalowaniu MySQL powinieneś utworzyć nowego superużytkownika (PRZYZNAJ WSZYSTKO… Z OPCJĄ PRZYZNANIA), a następnie usuń istniejące konta „[email protected]”.
5. Bezpieczeństwo sieci
Idealnie byłoby, gdyby MySQL nie był dostępny w sieci, a wszystkie połączenia byłyby obsługiwane lokalnie, przez gniazdo uniksowe. W niektórych konfiguracjach jest to możliwe — w takim przypadku możesz dodać zmienną „skip-networking” w my.cnf. Zapobiegnie to używaniu przez MySQL jakiejkolwiek komunikacji TCP/IP, tylko gniazdo Unix będzie dostępne w Linuksie (potoki nazwane i pamięć współdzielona na hostach Windows).
Jednak w większości przypadków tak ścisłe zabezpieczenie nie jest możliwe. W takim przypadku musisz znaleźć inne rozwiązanie. Po pierwsze, możesz użyć zapory sieciowej, aby zezwolić na ruch tylko z określonych hostów do serwera MySQL. Na przykład hosty aplikacji (chociaż powinny być w porządku z dotarciem do MySQL przez proxy), warstwa proxy i być może serwer zarządzania. Inne hosty w Twojej sieci prawdopodobnie nie potrzebują bezpośredniego dostępu do serwera MySQL. Ograniczy to możliwości ataku na Twoją bazę danych, w przypadku gdyby niektóre hosty w Twojej sieci zostały naruszone.
Jeśli zdarzy ci się używać serwerów proxy, które umożliwiają dopasowywanie wyrażeń regularnych dla zapytań, możesz ich użyć do analizy ruchu SQL i blokowania podejrzanych zapytań. Najprawdopodobniej hosty Twojej aplikacji nie powinny uruchamiać polecenia „DELETE * FROM your_table;”; regularnie. Jeśli konieczne jest usunięcie niektórych danych, można to wykonać ręcznie, lokalnie, na instancji MySQL. Możesz tworzyć takie reguły za pomocą czegoś takiego jak ProxySQL:blokować, przepisywać, przekierowywać takie zapytania. MaxScale daje również opcję blokowania zapytań na podstawie wyrażeń regularnych.
6. Wtyczki audytu
Jeśli jesteś zainteresowany zbieraniem danych o tym, kto co i kiedy wykonał, dostępnych jest kilka wtyczek audytowych dla MySQL. Jeśli używasz MySQL Enterprise, możesz użyć MySQL Enterprise Audit, który jest rozszerzeniem MySQL Enterprise. Percona i MariaDB również mają własną wersję wtyczek audytu. Wreszcie, wtyczka McAfee do MySQL może być również używana z różnymi wersjami MySQL. Mówiąc ogólnie, wtyczki te zbierają mniej więcej te same dane - zdarzenia łączenia i rozłączania, wykonywane zapytania, dostęp do tabel. Wszystko to zawiera informacje o tym, który użytkownik brał udział w takim zdarzeniu, z jakiego hosta się zalogował, kiedy to się stało i tak dalej. Dane wyjściowe mogą być w formacie XML lub JSON, więc znacznie łatwiej jest je przeanalizować niż analizować ogólną zawartość dziennika (nawet jeśli dane są dość podobne). Takie dane wyjściowe mogą być również wysyłane do syslog, a następnie do jakiegoś serwera dziennika w celu przetwarzania i analizy.
7. Wyłącz LOAD DATA LOCAL INFILE
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. 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 dowolnego pliku, do którego ma dostęp serwer HTTP. Aby tego uniknąć, musisz ustawić local-infile=0 w my.cnf
8. Uprawnienia do plików
Należy pamiętać, że bezpieczeństwo MySQL zależy również od konfiguracji systemu operacyjnego. MySQL przechowuje dane w postaci plików. Serwer MySQL zapisuje w dziennikach mnóstwo informacji. Czasami informacje te zawierają dane - na przykład powolny dziennik zapytań, dziennik ogólny lub dziennik binarny. Musisz upewnić się, że te informacje są bezpieczne i dostępne tylko dla użytkowników, którzy mają do nich dostęp. Zazwyczaj oznacza to, że tylko root i użytkownik, na których prawach działa MySQL, powinni mieć dostęp do wszystkich plików związanych z MySQL. Przez większość czasu jest to dedykowany użytkownik o nazwie „mysql”. Powinieneś sprawdzić pliki konfiguracyjne MySQL i wszystkie logi generowane przez MySQL i upewnić się, że nie są one czytelne dla innych użytkowników.
9. SSL i szyfrowanie danych w tranzycie
Uniemożliwienie ludziom dostępu do plików konfiguracyjnych i dzienników to jedno. Innym problemem jest upewnienie się, że dane są bezpiecznie przesyłane przez sieć. Z wyjątkiem konfiguracji, w których wszyscy klienci są lokalni i używają gniazda Unix do dostępu do MySQL, w większości przypadków dane, które tworzą zestaw wyników zapytania, opuszczają serwer i są przesyłane do klienta przez sieć. Dane mogą być również przesyłane między serwerami MySQL, na przykład poprzez standardową replikację MySQL lub w ramach klastra Galera. Ruch sieciowy może być sniffowany, a dzięki temu Twoje dane zostaną ujawnione.
Aby temu zapobiec, możliwe jest użycie protokołu SSL do szyfrowania ruchu, zarówno po stronie serwera, jak i klienta. Możesz utworzyć połączenie SSL między klientem a serwerem MySQL. Możesz także utworzyć połączenie SSL między urządzeniem głównym a urządzeniami podrzędnymi lub między węzłami klastra Galera. Zapewni to, że wszystkie przesyłane dane są bezpieczne i nie mogą zostać przechwycone przez atakującego, który uzyskał dostęp do Twojej sieci.
Dokumentacja MySQL opisuje szczegółowo, jak skonfigurować szyfrowanie SSL. Jeśli uznasz to za zbyt kłopotliwe, ClusterControl może za pomocą kilku kliknięć pomóc we wdrożeniu bezpiecznego środowiska do replikacji MySQL lub klastra Galera:
10. Szyfrowanie danych w spoczynku
Zabezpieczenie przesyłanych danych za pomocą szyfrowania SSL tylko częściowo rozwiązuje problem. Należy zadbać również o dane w spoczynku - wszystkie dane, które są przechowywane w bazie danych. Szyfrowanie danych w spoczynku może być również wymagane przez przepisy bezpieczeństwa, takie jak HIPAA lub PCI DSS. Takie szyfrowanie można realizować na wielu poziomach – można zaszyfrować cały dysk, na którym przechowywane są pliki. Możesz zaszyfrować tylko bazę danych MySQL dzięki funkcjonalności dostępnej w najnowszych wersjach MySQL lub MariaDB. Szyfrowanie można również zaimplementować w aplikacji, aby szyfrować dane przed zapisaniem ich w bazie danych. Każda opcja ma swoje wady i zalety:szyfrowanie dysku może pomóc tylko wtedy, gdy dyski zostaną fizycznie skradzione, ale pliki nie zostaną zaszyfrowane na uruchomionym serwerze bazy danych. Szyfrowanie bazy danych MySQL rozwiązuje ten problem, ale nie może uniemożliwić dostępu do danych, gdy konto root zostanie naruszone. Szyfrowanie na poziomie aplikacji jest najbardziej elastyczne i bezpieczne, ale wtedy tracisz moc SQL - dość trudno jest używać zaszyfrowanych kolumn w klauzulach WHERE lub JOIN.
Wszystkie odmiany MySQL zapewniają pewien rodzaj szyfrowania danych w stanie spoczynku. Oracle MySQL wykorzystuje przezroczyste szyfrowanie danych do szyfrowania obszarów tabel InnoDB. Jest to dostępne w komercyjnej ofercie MySQL Enterprise. Zapewnia opcję szyfrowania obszarów tabel InnoDB, inne pliki, które również przechowują dane w jakiejś formie (na przykład dzienniki binarne, dziennik ogólny, dziennik powolnych zapytań) nie są szyfrowane. Dzięki temu łańcuch narzędzi (MySQL Enterprise Backup, ale także xtrabackup, mysqldump, mysqlbinlog) może działać poprawnie z taką konfiguracją.
Począwszy od MySQL 5.7.11, społeczność MySQL otrzymała również wsparcie dla szyfrowania przestrzeni tabel InnoDB. Główną różnicą w porównaniu z ofertą dla przedsiębiorstw jest sposób przechowywania kluczy — klucze nie znajdują się w bezpiecznym skarbcu, co jest wymagane do zapewnienia zgodności z przepisami. Oznacza to, że począwszy od Percona Server 5.7.11 możliwe jest również szyfrowanie obszaru tabel InnoDB. W niedawno opublikowanym Percona Server 5.7.20 dodano obsługę szyfrowania logów binarnych. Możliwa jest również integracja z serwerem Hashicorp Vault za pomocą wtyczki keyring_vault, dopasowując (a nawet rozszerzając - szyfrowanie dziennika binarnego) funkcje dostępne w wersji Oracle MySQL Enterprise.
MariaDB dodała obsługę szyfrowania danych w 10.1.3 - jest to osobna, ulepszona implementacja. Daje możliwość szyfrowania nie tylko obszarów tabel InnoDB, ale także plików dziennika InnoDB. Dzięki temu dane są bezpieczniejsze, ale niektóre narzędzia nie będą działać w takiej konfiguracji. Xtrabackup nie będzie działać z zaszyfrowanymi dziennikami przeróbek — MariaDB utworzyła rozwidlenie, MariaDB Backup, które dodaje obsługę szyfrowania MariaDB. Istnieją również problemy z mysqlbinlog.
Bez względu na to, jakiego typu MySQL używasz, o ile jest to najnowsza wersja, będziesz mieć możliwość zaimplementowania szyfrowania danych w spoczynku za pośrednictwem serwera bazy danych, upewniając się, że Twoje dane są dodatkowo zabezpieczone.
Zabezpieczanie MySQL lub MariaDB nie jest trywialne, ale mamy nadzieję, że te 10 wskazówek pomoże Ci w tym.
Podsumowanie
W dzisiejszym świecie bezpieczeństwo danych jest najwyższym priorytetem dla każdego administratora baz danych. Niezależnie od tego, czy Twoją motywacją jest zgodność z wymogami prawnymi, czy ochrona klientów i reputacji Twojej firmy, te dziesięć wskazówek dotyczących zabezpieczania baz danych MySQL i MariaDB pomoże Ci w dalszym zabezpieczeniu infrastruktury i zapewni Ci spokój ducha.
Podczas zapewniania bezpieczeństwa infrastruktury bazy danych należy wziąć pod uwagę wiele środków. W tym poście omówiliśmy podstawy, takie jak szyfrowanie danych, kontrola dostępu do sieci, uwierzytelnianie i uprawnienia użytkowników, bezpieczeństwo systemu operacyjnego i nie tylko.
Oprogramowanie do automatyzacji zarządzania bazami danych, takie jak ClusterControl, może być doskonałym narzędziem pomagającym w ogólnych wysiłkach związanych z bezpieczeństwem baz danych. Jeśli szukasz głębszego zagłębienia się w każdy krok, który musisz wykonać, aby zabezpieczyć swoje bazy danych MySQL, koniecznie zapoznaj się z Częścią 1 i Częścią 2 naszej serii Jak zabezpieczyć bazę danych MySQL. Aby być na bieżąco z innymi najlepszymi praktykami zarządzania bazami danych, śledź nas na Twitterze, LinkedIn i subskrybuj nasz biuletyn, aby otrzymywać aktualizacje.
