Někdy je nevyhnutelné provozovat databázové servery MySQL na veřejné nebo nechráněné síti. Toto je běžné nastavení v prostředí sdíleného hostování, kde je server nakonfigurován s více službami a často běží na stejném serveru jako databázový server. Pro ty, kteří mají tento druh nastavení, byste měli mít vždy nějaký druh ochrany proti kybernetickým útokům, jako je denial-of-service, hacking, cracking, narušení dat; vše, co může vést ke ztrátě dat. To jsou věci, kterým se chceme u našeho databázového serveru vždy vyhnout.
Zde je několik tipů, které můžeme udělat pro zlepšení zabezpečení MySQL nebo MariaDB.
Pravidelně prohledávejte databázové servery
Ochrana proti jakýmkoli škodlivým souborům na serveru je velmi důležitá. Pravidelně kontrolujte server, abyste hledali jakékoli viry, spyware, malware nebo rootkity, zejména pokud je databázový server umístěn společně s dalšími službami, jako je poštovní server, HTTP, FTP, DNS, WebDAV, telnet a tak dále. Většina problémů s hackerskými útoky obvykle pochází z aplikační vrstvy, která čelí veřejné síti. Proto je důležité kontrolovat všechny soubory, zejména webové/aplikační soubory, protože jsou jedním ze vstupních bodů pro vstup na server. Pokud jsou kompromitovány, hacker se může dostat do adresáře aplikace a mít možnost číst soubory aplikace. Ty mohou obsahovat citlivé informace, například přihlašovací údaje k databázi.
ClamAV je jedno z nejznámějších a nejdůvěryhodnějších antivirových řešení pro různé operační systémy, včetně Linuxu. Je zdarma a velmi snadno se instaluje a přichází s poměrně dobrým detekčním mechanismem pro vyhledávání nežádoucích věcí na vašem serveru. Naplánujte pravidelné skenování v úloze cron, například:
0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.logVýše uvedené aktualizuje virovou databázi ClamAV, prohledá všechny adresáře a soubory a zašle vám e-mail o stavu provádění a zprávu každý den ve 3:00.
Používejte přísnější uživatelské role a oprávnění
Při vytváření uživatele MySQL nepovolte všem hostitelům přístup k serveru MySQL pomocí zástupného hostitele (%). Měli byste prohledat hostitele MySQL a vyhledat jakoukoli hodnotu hostitele se zástupným znakem, jak je uvedeno v následujícím prohlášení:
mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user | host |
+---------+------+
| myadmin | % |
| sbtest | % |
| user1 | % |
+---------+------+Z výše uvedeného výstupu omezte nebo odeberte všechny uživatele, kteří mají ve sloupci Host pouze hodnotu '%'. Uživatelé, kteří potřebují vzdálený přístup k serveru MySQL, mohou být nuceni používat metodu tunelování SSH, která pro uživatele MySQL nevyžaduje konfiguraci vzdáleného hostitele. Většinu administračních klientů MySQL, jako jsou MySQL Workbench a HeidiSQL, lze nakonfigurovat tak, aby se připojovali k serveru MySQL pomocí tunelování SSH, takže je možné zcela eliminovat vzdálené připojení pro uživatele MySQL.
Omezte také oprávnění SUPER pouze na uživatele z localhost nebo připojení přes soubor soketu UNIX. Při přidělování oprávnění FILE uživatelům bez oprávnění root buďte opatrnější, protože umožňuje čtení a zápis souborů na serveru pomocí příkazů LOAD DATA INFILE a SELECT ... INTO OUTFILE. Každý uživatel, kterému je toto oprávnění uděleno, může také číst nebo zapisovat jakýkoli soubor, který může server MySQL číst nebo zapisovat.
Změňte výchozí nastavení databáze
Odchodem od výchozího nastavení, pojmenování a konfigurací můžeme zmenšit vektor útoku na několik záhybů. Následující akce jsou příklady výchozích konfigurací, které by správci databází mohli snadno změnit, ale ve vztahu k MySQL je běžně přehlížejí:
- Změňte výchozí port MySQL na jiný než 3306.
- Přejmenujte kořenové uživatelské jméno MySQL na jiné než "root".
- Vynutit vypršení platnosti hesla a snížit životnost hesla pro všechny uživatele.
- Pokud je MySQL umístěna společně s aplikačními servery, vynucte připojení pouze přes soubor soketu UNIX a přestaňte naslouchat na portu 3306 pro všechny IP adresy.
- Vynutit šifrování klient-server a šifrování replikace server-server.
Ve skutečnosti jsme to podrobně probrali v tomto blogovém příspěvku Jak zabezpečit servery MySQL/MariaDB.
Nastavení zpožděného Slave
Zpožděný slave je jen typický slave, ale slave server záměrně provádí transakce později než master alespoň o určitou dobu, která je dostupná z MySQL 5.6. Událost přijatá od hlavního serveru se v zásadě nevykoná, dokud není alespoň N sekund po jeho provedení na masteru. Výsledkem je, že slave bude odrážet stav mastera někdy v minulosti.
K obnovení dat lze použít zpožděnou podřízenou jednotku, což by bylo užitečné, když je problém nalezen okamžitě, během doby zpoždění. Předpokládejme, že jsme nakonfigurovali slave s 6hodinovým zpožděním od mastera. Pokud byla naše databáze změněna nebo smazána (náhodně vývojářem nebo úmyslně hackerem) v tomto časovém rozmezí, máme možnost vrátit se do okamžiku těsně předtím, než se to stalo, zastavením aktuálního hlavního serveru a spuštěním podřízeného serveru. do určitého bodu pomocí následujícího příkazu:
# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;Kde „xxxxx“ je binární soubor protokolu a „yyyyy“ je pozice těsně před katastrofou (k prozkoumání těchto událostí použijte nástroj mysqlbinlog). Nakonec povyšte slave, aby se stal novým masterem a vaše služba MySQL je nyní opět funkční jako obvykle. Tato metoda je pravděpodobně nejrychlejším způsobem, jak obnovit databázi MySQL v produkčním prostředí, aniž byste museli znovu načítat zálohu. S množstvím zpožděných podřízených jednotek s různou délkou trvání, jak je ukázáno v tomto blogu, Vícenásobné zpožděné replikační podřízené jednotky pro zotavení po havárii s nízkou RTO o tom, jak nastavit nákladově efektivní servery se zpožděnou replikací na kontejnerech Docker.
Povolit binární protokolování
Binární protokolování se obecně doporučuje povolit, i když běžíte na samostatném serveru MySQL/MariaDB. Binární protokol obsahuje informace o příkazech SQL, které upravují obsah databáze. Informace se ukládají ve formě „událostí“, které popisují úpravy. Navzdory dopadu na výkon vám binární protokol umožňuje přehrát databázový server přesně do bodu, kde chcete, aby byl obnoven, což je také známé jako obnovení v určitém okamžiku (PITR). Binární protokolování je také povinné pro replikaci.
Při aktivovaném binárním protokolování je nutné při vytváření plné zálohy zahrnout binární soubor protokolu a informace o poloze. Pro mysqldump použití parametru --master-data s hodnotou 1 nebo 2 vytiskne potřebné informace, které můžeme použít jako výchozí bod pro přehrání databáze při pozdějším přehrávání binárních protokolů.
S povoleným binárním protokolováním můžete použít další skvělou funkci obnovení zvanou flashback, která je popsána v další části.
Povolit Flashback
Funkce flashback je dostupná v MariaDB, kde můžete obnovit data zpět na předchozí snímek v databázi MySQL nebo v tabulce. Flashback používá mysqlbinlog k vytvoření příkazů vrácení zpět a potřebuje k tomu ÚPLNÝ binární obraz řádku protokolu. Pro použití této funkce tedy musí být server MySQL/MariaDB nakonfigurován s následujícím:
[mysqld]
...
binlog_format = ROW
binlog_row_image = FULLNásledující diagram architektury ilustruje, jak je flashback nakonfigurován na jednom z podřízených zařízení:
Chcete-li provést operaci flashback, musíte nejprve určit datum a čas když chcete "vidět" data nebo binární log soubor a pozici. Potom použijte příznak --flashback s obslužným programem mysqlbinlog ke generování příkazů SQL, které vrátí data do tohoto bodu. Ve vygenerovaném SQL souboru si všimnete, že události DELETE jsou převedeny na INSERT a naopak a také zamění části událostí UPDATE WHERE a SET.
Následující příkazový řádek by měl být spuštěn na slave2 (nakonfigurován pomocí binlog_row_image=FULL):
$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00" /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sqlPoté odpojte slave2 od replikačního řetězce, protože jej přerušíme a použijeme server k vrácení našich dat:
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;Nakonec importujte vygenerovaný soubor SQL do serveru MariaDB pro databázový obchod na slave2:
$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sqlPři použití výše uvedeného bude tabulka "produkty" ve stavu 2020-02-17 01:30:00. Technicky lze vygenerovaný soubor SQL použít na servery MariaDB i MySQL. Můžete také přenést binární soubor mysqlbinlog ze serveru MariaDB, abyste mohli použít funkci flashback na serveru MySQL. Implementace MySQL GTID se však liší od implementace MariaDB, takže obnovení souboru SQL vyžaduje, abyste zakázali MySQL GTID.
Několik výhod použití flashbacku je, že k provedení této operace nemusíte zastavovat server MySQL/MariaDB. Když je množství dat k vrácení malé, proces flashbacku je mnohem rychlejší než obnova dat z úplné zálohy.
Zaznamenat všechny databázové dotazy
Obecný protokol v podstatě zachycuje každý příkaz SQL prováděný klientem na serveru MySQL. To však nemusí být oblíbené rozhodnutí na vytíženém produkčním serveru kvůli dopadu na výkon a spotřebě místa. Pokud na výkonu záleží, má binární protokol vyšší prioritu, aby byl povolen. Obecný protokol lze za běhu povolit spuštěním následujících příkazů:
mysql> SET global general_log_file='/tmp/mysql.log';
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;Výstup obecného protokolu můžete také nastavit na tabulku:
mysql> SET global log_output = 'table';Poté můžete použít standardní příkaz SELECT proti tabulce mysql.general_log k načtení dotazů. Očekávejte trochu větší dopad na výkon při běhu s touto konfigurací, jak je znázorněno v tomto příspěvku na blogu.
Jinak můžete použít externí monitorovací nástroje, které mohou provádět vzorkování dotazů a monitorování, takže můžete filtrovat a auditovat dotazy, které přicházejí na server. ClusterControl lze použít ke shromažďování a shrnutí všech vašich dotazů, jak je znázorněno na následujících snímcích obrazovky, kde filtrujeme všechny dotazy obsahující řetězec DELETE:
Podobné informace jsou k dispozici také na stránce nejčastějších dotazů ProxySQL (pokud je vaše aplikace připojení přes ProxySQL):
Toto lze použít ke sledování posledních změn, ke kterým došlo na databázovém serveru a může být také použit pro účely auditu.
Závěr
Vaše servery MySQL a MariaDB musí být vždy dobře chráněny, protože obvykle obsahují citlivá data, o která se útočníci starají. ClusterControl můžete také použít ke správě bezpečnostních aspektů vašich databázových serverů, jak ukazuje tento blogový příspěvek Jak zabezpečit své open source databáze pomocí ClusterControl.