Bezpečnost je dnes prvořadá v celém IT. Čas od času slyšíme o ransomwarových útocích nebo únikech dat, které mají původ v nezabezpečených databázích nebo IT infrastruktuře. Možná se divíte:jaké jsou osvědčené postupy při architektuře prostředí MySQL, abyste měli svá data v bezpečí? Pokud ano, tento blog je pro vás. Mějte prosím na paměti, že se tomuto tématu nebudeme věnovat naplno – to by se hodilo spíše do whitepaperu než do blogu. Uděláme, co bude v našich silách, abychom zmínili nejdůležitější aspekty zabezpečení vaší databáze MySQL. Myšlenkou tohoto blogu je, aby čtenář věděl, co neví, a pomohl určit témata a klíčová slova pro další výzkum. Ilustrujeme to na snímcích obrazovky z našeho produktu ClusterControl, který přichází s rozsáhlou sadou funkcí, včetně některých souvisejících se zabezpečením databáze.
Síť
Především musíme někde nasadit MySQL. Ať už jde o samostatnou instanci, primární replikaci asynchronní replikace nebo jednu z pokročilejších topologií synchronní replikace, jako je Galera nebo InnoDB Cluster. Bez ohledu na to, co to je, musí být chráněno na úrovni sítě. Databáze obsahuje data, která jsou zcela běžně nejcennějším aktivem celé organizace.
Zabezpečení přístupu
Instance databáze by se nikdy neměly nacházet ve veřejné síti. Segmenty sítě, ve kterých jsou konfigurovány databáze, by měly být přístupné pouze z omezeného počtu dalších sítí. Základní pravidlo zní – měl by mít daný uzel přístup k databázové síti? Pokud je odpověď ne, měly by být sítě odděleny.
Samozřejmě to vše závisí na přesném nastavení, ale v nejběžnějších případech, kdy máte aplikační, proxy, mezipaměť a databázové vrstvy, by nejtypičtější nastavení bylo, že by měl být schopen pro přístup k databázi. Všechny ostatní entity by měly být nakonfigurovány tak, aby přistupovaly k databázi pouze přes vrstvu proxy. Tento design je dobrý v mnoha ohledech. Kromě zvýšené bezpečnosti také pomáhá skrýt před aplikací složitost databázové vrstvy.
Vrstva proxy by měla odpovídat topologii databáze a měla by zpracovávat selhání uzlů databáze a změny topologie. Aplikace, která se připojuje k vrstvě proxy, by měla být vždy schopna oslovit funkční databázový uzel relevantní pro typ požadavku. To samé je s vrstvou mezipaměti. Může být implementován ve vrstvě proxy, některé servery proxy, jako je ProxySQL, umožňují požadavky mezipaměti v rámci proxy, ale pokud se jedná o samostatnou vrstvu postavenou kolem memcache nebo Redis, měla by vždy oslovovat databázi prostřednictvím vrstvy proxy.
Dalším typem uzlů, které mohou potřebovat přímý přístup k databázové vrstvě, jsou uzly správy – ty, které používají operační týmy ke správě databází. Důvod je jednoduchý:některé z úkolů údržby mohou vyžadovat přímý přístup k databázím. Mohou to být skripty pro automatizaci úloh, rolování Ansible playbooků napříč celou databázovou flotilou nebo jiné úlohy. V takovém případě by samozřejmě měla být zavedena bezpečnostní opatření, která zajistí, že se k takovému řídicímu uzlu budou moci přihlásit pouze lidé, kteří mají přístup.
Dalším možným typem uzlů (i když k tomu lze použít i manažerské uzly), které mohou vyžadovat přístup k databázi, jsou uzly zapojené do shromažďování metrik a jejich předkládání uživatelům – mluvíme zde o monitorování a výstražné činnosti.
VPN
U jakéhokoli druhu databázové vrstvy zahrnující více datových center byste měli zvážit použití VPN k jejich propojení. Otevřené, nešifrované připojení přes síť WAN je něco, co by nikdy nemělo nastat. Ani nastavení šifrování SSL není nejlepší volbou, protože by vyžadovalo otevření přístupu mezi databázovou vrstvou a WAN - SSL připojení mezi databázovými uzly vyžaduje, aby se mohly připojit přímo. VPN tento problém řeší přidáním prostředníka, který vytváří bezpečný způsob propojení segmentů sítě databázové vrstvy.
VPN by také měla být povinná pro jakýkoli druh uživatelského přístupu k síti organizace, protože implementuje zabezpečené připojení mezi pracovní stanicí a produkční sítí.
Firewall
Při zabezpečení sítě bychom samozřejmě měli zvážit použití brány firewall. Obecně řečeno, každý databázový uzel by měl přijímat připojení pouze z definované sady zdrojů – názvů hostitelů a portů. Ani „požadované“ segmenty sítě by neměly mít plný přístup k databázové síti, ale pouze k požadovaným portům. Pokud se proxy potřebuje pouze připojit k databázovému portu, pak není důvod, aby mohl přistupovat k jakémukoli jinému portu na databázových uzlech. Pamatujte také, že byste neměli používat výchozí porty. Je to samozřejmě zabezpečení nejasností - port je koneckonců někde otevřený, ale pomáhá vypořádat se alespoň s některými bezpečnostními průniky, které používají automatické skripty. Nezabrání to někomu, kdo je odhodlán získat přístup, ale může ho zpomalit (ve spojení s detekcí skenování portů a opatřeními proti skenování), přičemž zabrání úspěchu automatických útoků.
Zabezpečení databáze
Síť je první linií obrany, existují další bezpečnostní opatření a osvědčené postupy, které můžete použít k dalšímu zlepšení zabezpečení. Některé z nich lze implementovat do samotné databáze.
Uživatelé a hostitelé
K implementaci řízení přístupu a omezení lze použít samotné databáze. Pro začátečníky můžete implementovat řízení přístupu na základě hostitele, které zabrání jiným hostitelům, než je krátký seznam uzlů, přihlásit se do databáze. Samozřejmě, pokud jste k omezení přístupu použili firewall, může to znít jako duplicitní, ale i tak je dobré omezit přístup k databázi samotné – nikdy nevíte, kdy bude firewall nešťastnou náhodou deaktivován. V takovém případě stále máte druhou vrstvu ochrany.
To, co zde chcete implementovat, je seznam uživatelů databáze a hostitelů, kteří mají povolen přístup k databázi. S největší pravděpodobností byste měli skončit s přístupem jednoho nebo více uživatelů z hostitelů umístěných ve vrstvě proxy. Jak podrobné řízení přístupu můžete mít, závisí na databázovém systému, který máte. MySQL například neumožňuje detailní kontrolu nad síťovými maskami – používá pouze /32, /24, /16 nebo /8. Na druhou stranu v PostgreSQL můžete použít jakoukoli masku sítě.
Granty
Pokud to vaše databáze umožňuje, každý z uživatelů by měl mít definovanou sadu udělení, aby bylo zajištěno, že oprávnění, která jim jsou přidělena, jsou minimální potřebná k tomu, aby uživatel mohl provádět akce, které musí udělat . Databázové systémy mohou mít různé sady oprávnění a různé úrovně. Obvykle máme několik úrovní oprávnění - globální, ovlivňující celý databázový server, úroveň schématu - daný uživatel může mít různá oprávnění přiřazená různým schématům. Můžete mít oprávnění na úrovni tabulky nebo dokonce sloupce. Jak jsme již zmínili, cílem je vytvořit minimální sadu oprávnění pro každého uživatele. Pravděpodobně budete chtít mít alespoň jednoho uživatele s vysokými právy – ten by sloužil ke správě databáze. Takový uživatel by měl být přísně omezen, pokud jde o konektivitu. Nemělo by (a ve skutečnosti by nemělo mít ani jeden z uživatelů) povoleno připojení z jakéhokoli místa – mělo by to být buď localhost, nebo nějaký konkrétní uzel správy, určený k provádění operací s databází.
Správa hesel
Každý uživatel v databázi by měl mít definované heslo. To je nesmysl. Heslo by mělo být uloženo ve formě hashe. Měli byste se ujistit, že pro ukládání hesel používáte nejbezpečnější hashovací algoritmus, který vaše databáze nabízí. Hesla by nemělo být snadné uhodnout ani by neměla být zranitelná vůči slovníkovému útoku. Některé databázové systémy, jako je MySQL, vám umožňují přesně definovat požadavky, které musí vaše hesla splňovat, aby mohla být použita. Malá a velká písmena, číslice, speciální znaky, délka hesla – to vše je důležité a pokud dokážete prosadit nějaké zásady týkající se síly hesla, měli byste to udělat. Dalším důležitým bodem je rotace hesla. Hesla by se neměla vytvářet jednou a po celou dobu životnosti databáze, měli byste mít zásadu střídání hesel. Opět platí, že některé z databázových systémů to za vás mohou vynutit. Administrativní uživatel může být schopen vytvářet nové uživatelské účty s vynuceným střídáním hesel. Může být také schopen vynutit rotaci hesla pro daného uživatele.
Protokoly auditu
Některé databázové systémy nabízejí protokoly auditu – cílem je shromáždit co nejvíce informací o aktivitě v databázi. Kdo a kdy co udělal? Který dotaz byl proveden, kým? Kdo se pokusil přihlásit, ale neúspěšně? Od kterého hostitele? V ideálním případě by protokoly obsahující takové informace byly uloženy mimo uzly databáze. Můžete je streamovat na svůj centrální protokolový server pro úschovu, další zpracování a lepší možnosti vyhledávání.
Zabezpečení SQL
Zmínili jsme uživatele a hostitele, ale k útoku může dojít také z jiného zdroje. Pokud vaše aplikace není správně zabezpečena a vstup není správně ověřen, můžete čelit útokům pocházejícím z vašeho webu. Mluvíme zde o SQL injection. V takovém případě nejsou brány firewall skutečně užitečné, protože dotaz pochází z platného zdroje (váš webový server a poté uzel proxy). Přidělování grantů může ve skutečnosti pomoci zabránit některým z těchto typů útoků, ale není to ideální řešení - vaše aplikace totiž ve většině případů bude potřebovat uživatele, který může odstranit nebo upravit obsah databáze. Takový uživatel, je-li zneužit, může být použit ke škodě. Existuje několik způsobů, jak se můžete pokusit léčit pamlsek.
Brána firewall SQL
Nejjednodušší způsob, jak toho dosáhnout, je implementovat SQL firewall. Toho lze dosáhnout na různých úrovních a na různých místech. Jednou z možností je k tomu využít load balancery. Některé z nich přicházejí s touto funkčností, která je přinejmenším snadno dosažitelná, pokud již není implementována. Smyslem toho je vytvořit seznam dotazů, které vaše aplikace provádí, a poté nakonfigurovat váš proxy tak, aby procházel pouze tímto druhem provozu. Není ideální, protože jej budete muset včas udržovat, přidávat nové dotazy a odstraňovat staré, které se již nepoužívají. Na druhou stranu taková sada pravidel zabrání tomu, aby se do databáze dostal jakýkoli dotaz, který není autorizován.
Detekce vkládání SQL
Další možnou možností by bylo implementovat detekci SQL injection v proxy vrstvě. Existuje několik řešení, mezi jinými ProxySQL, která lze nakonfigurovat tak, aby se pokusila detekovat vkládání SQL v provozu, který jimi prochází. Vše je samozřejmě založeno na heuristice, takže to může vést k falešným poplachům, ale může to být dobrý doplněk k firewallu SQL.
V minulosti jsme diskutovali o tom, jak implementovat SQL firewall a detekci SQL injection pomocí ProxySQL, loadbalanceru, který lze nasadit z ClusterControl:
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one
https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two
Zabezpečení dat
A konečně zabezpečení dat. Dosud jsme diskutovali o tom, jak lze databázi posílit, jak do ní omezit přístup a jak zabránit různým druhům útoků přicházejících ze samotné aplikace. Stále bychom měli zvážit ochranu samotných dat. To může mít několik vrstev. Fyzické zabezpečení – pokud vlastníte datové centrum, ujistěte se, že je řádně uzamčeno. Pokud používáte externí poskytovatele internetových služeb nebo cloudové poskytovatele, ujistěte se, že mají pro přístup k hardwaru zavedené správné bezpečnostní protokoly. Pak máme server, VM nebo jakkoli, co používáte. Data jsou uložena na disku a jsou uložena lokálně na serveru. Data se přenášejí mezi aplikací, proxy a databází. Data jsou mezi uzly databáze přenášena pomocí replikace. Data jsou ukládána mimo pracoviště jako záloha. Tato data by měla být chráněna.
Zálohy
Zálohy by měly být vždy šifrovány. Šifrovací klíč by měl být pečlivě udržován a pravidelně obměňován.
Přenos dat
Přenášená data by měla být šifrována. Ujistěte se, že jste nakonfigurovali aplikaci, vrstvu proxy a databázi pro použití SSL nebo TSL. Všechny prostředky přenosu dat mezi uzly databáze by měly být také zabezpečeny a šifrovány. Cílem je učinit jakýkoli druh síťového čichání zbytečným.
Data v klidu
A konečně samotná data uložená v uzlu databáze. Mělo by být také zašifrováno. Při přístupu k tomuto tématu můžete použít několik metod. Za prvé, šifrování na úrovni hostitele. Svazek, na kterém má databáze svůj datový adresář, lze zašifrovat (a dešifrovat při spouštění). Databáze také obvykle přicházejí s možnostmi šifrování. Co lze zašifrovat, závisí na přesném řešení a typu a verzi databáze, v některých případech jsou však možnosti poměrně rozsáhlé. Šifrování tabulkového prostoru, šifrování protokolu, někdy dokonce šifrování struktur v paměti. Pokud to uděláte správně, přístup k databázovému uzlu nebude pro přístup k datům stačit.
Závěr
Jak jsme již zmínili, tento blog není zamýšlen jako praktický průvodce zabezpečením databází, ale dotkli jsme se většiny aspektů, které byste měli vzít v úvahu při architektuře databázového prostředí, a doufáme tento průvodce vám bude užitečný.