Firemní databáze se jen zřídka ocitne vystavená internetu proto, že by někdo záměrně zvolil nebezpečný návrh. Častěji je příčinou výchozí nastavení, dočasné pravidlo firewallu, přehlédnutá testovací služba nebo zkratka při údržbě, která se stane trvalou.
Důsledky mohou být závažné. Útočník může ukrást záznamy zákazníků, pozměnit finanční data, zašifrovat produkční systémy nebo použít databázový server jako cestu do další infrastruktury. I když nedojde k okamžitému odcizení dat, vystavená služba představuje zbytečný vstupní bod, který je nutné monitorovat a chránit.
Následujících sedm chyb se týká databázových serverů spravovaných firmou, agenturou nebo IT administrátorem. Jsou relevantní pro PostgreSQL, MySQL, Microsoft SQL Server, MongoDB i další platformy. Přesné příkazy se liší, ale bezpečnostní rozhodnutí zůstávají stejná: minimalizovat dostupnost, ověřovat identitu, omezovat oprávnění, šifrovat provoz, monitorovat aktivitu a udržovat obnovu nezávislou na chráněném serveru.
1. Navázání databáze na veřejné rozhraní
Databázový démon může ve výchozím nastavení naslouchat na každém síťovém rozhraní, případně jej administrátor může nakonfigurovat tak, aby naslouchal na veřejné IP adrese kvůli pohodlnému vzdálenému přístupu. Pokud má server směrovatelnou adresu, lze se k databázi dostat přímo z internetu, pokud tomu nezabrání jiný bezpečnostní prvek.
Cesta útoku a dopad na firmu
Útočník skenuje rozsahy adres a hledá rozpoznatelné databázové porty, identifikuje software a jeho verzi a následně zkouší útoky na přihlašovací údaje nebo zneužití známé zranitelnosti. Veřejná viditelnost automaticky neznamená napadení, ale poskytuje útočníkům nepřetržitě dostupný a snadno nalezitelný cíl.
Úspěšný přístup může odhalit osobní údaje, objednávky, přihlašovací údaje, duševní vlastnictví a provozní záznamy. Databázový účet může útočníkovi také umožnit měnit záznamy, vytvářet nové privilegované uživatele nebo využít databázové funkce k přístupu k samotnému serveru.
Jak problém odhalit a opravit
Zkontrolujte konfiguraci naslouchání databáze a seznam socketů operačního systému. Příkazy jako ss -lntp nebo netstat -lntp mohou ukázat, zda služba naslouchá na 0.0.0.0, :: nebo veřejné adrese namísto pouze na localhostu či privátním rozhraní. Testujte z vnější sítě, nejen přímo ze serveru. Externí sken portů a kontrola cloudových bezpečnostních skupin nebo pravidel firewallu poskytovatele hostingu by měly odpovídat zamýšlenému návrhu.
U většiny aplikací navážte databázi na localhost nebo adresu privátní sítě a umístěte ji za aplikační vrstvu. Pokud je vzdálená správa nezbytná, vyžadujte privátní VPN, bastion host nebo jinou řízenou přístupovou cestu. Nepovažujte nestandardní port za ochranu. Může omezit náhodný šum, ale nezabrání odhalení služby.
Při ověřování návrhu mohou administrátoři využít spolehlivé pokyny ke kontrole databáze vystavené internetu a bezpečným způsobům jejího vystavení. Cílem by mělo být odstranit veřejnou dostupnost všude, kde není nezbytná, nikoli službu pouze skrýt.
2. Ponechání výchozích přihlašovacích údajů nebo slabého ověřování
Databázové produkty, zařízení a obrazy pro nasazení někdy obsahují výchozí uživatelská jména, dočasná hesla nebo režimy ověřování určené pouze pro počáteční nastavení. Uspěchaná instalace může také ponechat jednoduché heslo, znovu použít aplikační tajemství nebo povolit bezheslová lokální připojení v širším rozsahu, než bylo zamýšleno.
Cesta útoku a dopad na firmu
Po objevení databázového portu útočníci běžně zkoušejí zveřejněné výchozí údaje a běžná hesla. Účinné je také zkoušení uniklých kombinací, pokud administrátoři používají stejná hesla v jiných systémech. Po ověření může mít útočník výrazně větší přístup, než původní aplikace potřebuje.
Výsledkem může být tiché odčerpávání dat, destruktivní dotazy, podvodné změny nebo základ pro pozdější ransomware. Pokud stejné údaje používají skripty, vývojáři i administrátoři, může jediný uniklý údaj ohrozit každé prostředí.
Jak problém odhalit a opravit
Prověřte každý databázový účet, jeho metodu ověřování, informace o posledním použití a přiřazenou roli. Otestujte instalaci pomocí inventáře účtů a nespoléhejte na předpoklad, že zdokumentované výchozí údaje byly odstraněny. Zkontrolujte konfigurační soubory, manifesty nasazení, proměnné CI/CD a skripty, zda neobsahují vložená hesla.
Vypněte nepoužívané účty dodavatele, podle potřeby přejmenujte nebo uzamkněte nouzové účty a u účtů, které musí zůstat aktivní, vyžadujte dlouhé a jedinečné údaje. Preferujte centrálně spravované ověřování, vícefaktorové ověřování pro lidské administrátory a krátkodobé údaje pro automatizaci, pokud je platforma podporuje. Ukládejte tajemství do specializovaného správce tajemství, nikoli do zdrojového kódu, tiketů, tabulek nebo historie shellu. Po změně zaměstnanců, podezření na únik a významných změnách systému údaje obměňujte.
Protokoly ověřování by měly zaznamenávat neúspěšná i úspěšná přihlášení, zdrojové adresy a použitý účet. Upozorňujte na opakovaná selhání, přihlášení v neobvyklou dobu, přístup z neočekávaných sítí a vytváření nových privilegovaných účtů.
3. Povolení neomezeného síťového přístupu
Navázání databáze na privátní rozhraní nestačí, pokud síť umožňuje připojení každému internímu hostiteli, uživateli VPN nebo cloudové úloze. Široké pravidlo typu „povolit celou kancelářskou síť“ nebo „povolit veškerý provoz z privátního cloudu“ často zůstane aktivní dlouho poté, co pomine původní potřeba řešení problémů.
Cesta útoku a dopad na firmu
V tomto scénáři útočník nejprve napadne notebook, webový server, účet vývojáře nebo nesouvisející úlohu. Síťový přístup k databázi je již dostupný, takže útočník může službu vyhledat a napadnout bez překročení internetového perimetru.
Nadměrná interní dostupnost zvyšuje rozsah dopadu phishingu, malwaru a incidentů v dodavatelském řetězci. Může také umožnit neoprávněný laterální pohyb mezi produkčními, testovacími a vývojovými systémy. Napadený testovací server by neměl být schopen dotazovat zákaznická data jen proto, že oba systémy sdílejí široké síťové pravidlo.
Jak problém odhalit a opravit
Prověřte společně hostitelské firewally, síťové firewally, cloudové bezpečnostní skupiny, síťové zásady Kubernetes a pravidla přístupu hostitelů na úrovni databáze. Zdokumentujte, které aplikační servery, reportovací nástroje, zálohovací služby a administrátorské skokové hostitele skutečně potřebují připojení. Tento seznam porovnejte s aktivními připojeními a pravidly firewallu.
Nahraďte široké zdrojové rozsahy konkrétními seznamy povolených IP adres nebo bezpečnostními skupinami. Povolte pouze požadovaný cílový port a protokol. Ve výchozím nastavení provoz zamítejte, oddělte produkční a neprodukční sítě a odstraňujte dočasná pravidla s uvedeným vlastníkem a datem vypršení. Pokud se zaměstnanci připojují vzdáleně, směrujte údržbu přes VPN nebo bastion, místo abyste povolili přímé připojení z každé domácí či mobilní IP adresy.
Pravidla kontrolujte po migracích a změnách kancelářské sítě. Čtvrtletní kontrola přístupů je užitečná, ale vysoce rizikové změny by měly být prověřeny okamžitě. Pravidlo firewallu bez určeného vlastníka z hlediska firmy je kandidátem na odstranění.
4. Přenos databázových dat bez TLS
Databáze může být chráněna v klidovém stavu, a přesto během přenosu mezi aplikací, pracovní stanicí administrátora, reportovacím nástrojem nebo partnerem replikace odhalovat přihlašovací údaje a citlivé záznamy. Nešifrovaná připojení jsou obzvlášť nebezpečná ve sdílených sítích, cloudových segmentech, Wi-Fi a při vzdálené údržbě.
Cesta útoku a dopad na firmu
Útočník s přístupem k síti zachytí provoz nebo se postaví mezi klienta a server. Bez TLS mohou být čitelné uživatelská jména, hesla, dotazy i vrácená data. Slabé nebo neověřované TLS může také umožnit odposlech, protože klient nepotvrdí, že komunikuje s legitimní databází.
Důsledky zahrnují krádež přihlašovacích údajů, odhalení zákaznických dat, manipulaci s dotazy a problémy s dodržováním předpisů. Stejnou pozornost jako běžný aplikační provoz si zaslouží také kanály replikace a přenosu záloh.
Jak problém odhalit a opravit
Prohlédněte připojovací řetězce databáze a nastavení serveru a ověřte, že TLS je vyžadováno, nikoli pouze dostupné. Pomocí stavového výstupu databázového klienta, auditních protokolů připojení a zachycení paketů v řízeném testu ověřte šifrování. Zkontrolujte platnost certifikátů, ověřování názvu hostitele, důvěryhodné vydavatele, verze protokolu a odmítnutí návratu k nešifrovanému připojení.
Certifikáty instalujte prostřednictvím řízeného procesu obnovy, omezte přístup k privátním klíčům a sledujte data jejich expirace. Nakonfigurujte aplikace tak, aby při selhání ověření certifikátu připojení uzavřely. Aktualizujte staré ovladače a knihovny, které nepodporují současné nastavení TLS. Zdokumentujte, která připojení jsou šifrována, včetně administrace, monitoringu, replikace a provozu ETL.
TLS chrání data při přenosu, ale nerozhoduje o tom, kdo k nim smí přistupovat. Kombinujte jej s omezením sítě, silným ověřováním a nejnižšími oprávněními.
5. Udělení nadměrných databázových oprávnění
Aplikace jsou často nakonfigurovány s účtem administrátora nebo vlastníka, protože to usnadňuje instalaci. Vývojáři mohou také reportovacím uživatelům udělit právo zápisu nebo servisnímu účtu přístup ke každému schématu „pro budoucí potřeby“. To porušuje princip nejnižších oprávnění a mění omezené napadení v incident týkající se celé databáze.
Cesta útoku a dopad na firmu
Chyba SQL injection, odcizené aplikační tajemství nebo napadený reportovací nástroj poskytne útočníkovi oprávnění daného účtu. Pokud účet vlastní tabulky, může vytvářet uživatele nebo spouštět funkce operačního systému, může útočník stáhnout celou databázi, měnit záznamy nebo uniknout na hostitele.
Nadměrná práva také zvyšují pravděpodobnost náhodného poškození. Chybná migrace nebo skript může smazat produkční data, pokud běží pod vysoce privilegovanou identitou.
Jak problém odhalit a opravit
Vytvořte inventář uživatelů, skupin, rolí a oprávnění. Hledejte aplikační účty s administrátorskými právy, přímým přístupem k nesouvisejícím schématům, neomezeným přístupem ke čtení citlivých tabulek a oprávněními, která nikdy nebyla použita. Auditní protokoly databáze porovnejte při kontrole s přidělenými oprávněními a skutečnou aktivitou.
Vytvořte oddělené identity pro každou aplikaci, prostředí a funkci. Udělte pouze přístup k požadovaným tabulkám, pohledům, procedurám a operacím. Pro reporting používejte role pouze pro čtení, přihlašovací údaje pro migrace oddělte od běžných provozních údajů a omezte přístup k osobním, finančním nebo ověřovacím datům. Zrušte zděděná oprávnění, která nejsou potřebná, a odstraňte neaktivní účty.
Přístup do produkce by neměl být výchozí pro vývojáře ani agentury, které podporují více klientů. Používejte pojmenované administrátorské účty, schválení zvýšeného přístupu, časově omezená oprávnění a zaznamenanou cestu údržby. Sdílené administrátorské údaje znemožňují užitečné dohledání odpovědnosti a ztěžují rychlé odebrání přístupu.
6. Vystavení administrátorských portů a nástrojů
Administrátorská rozhraní databází, služby vzdálené plochy, SSH, webové konzole a rozhraní pro správu jsou častými cíli útoků. Jejich vystavení veřejnému internetu kvůli pohodlí vytváří druhou útočnou plochu, i když je samotný databázový listener omezen.
Cesta útoku a dopad na firmu
Útočníci skenují běžné porty pro správu, identifikují služby a zkoušejí útoky na hesla, odcizené přihlašovací údaje nebo známé zranitelnosti. Napadená administrátorská služba může poskytnout přímou kontrolu operačního systému, přístup ke konfiguraci nebo možnost vypnout protokolování a smazat data.
U malé firmy může jediný vystavený port pro vzdálenou správu změnit incident databáze v úplné převzetí serveru. U agentury může sdílený způsob správy ohrozit několik zákaznických prostředí, pokud jsou hranice přístupu slabé.
Jak problém odhalit a opravit
Proveďte externí sken adres organizace a interní sken z nedůvěryhodných síťových segmentů. Pomocí nástrojů hostitele zkontrolujte naslouchající porty a porovnejte je s pravidly firewallu. V cloudových konzolích ověřte přiřazení veřejných IP adres, listenery nástrojů pro vyvažování zátěže a příliš benevolentní bezpečnostní skupiny. Sledujte protokoly přihlášení ke správě, neúspěšného ověřování, nových relací a změn konfigurace.
Uzavřete nepoužívané služby. SSH, vzdálenou plochu a databázové konzole ponechte mimo veřejná rozhraní. Vyžadujte VPN, bastion host nebo přístupovou bránu zero trust s vícefaktorovým ověřením, kontrolou zařízení a individuálními účty. Pokud je to praktické, omezte administrátorský přístup podle zdrojové IP, zakažte přímé přihlášení root nebo sdíleného administrátorského účtu a u citlivých činností zaznamenávejte příkazy nebo aktivitu relace.
Oddělte produkční přístup od přístupu pro údržbu. Aplikace by měla používat jednu úzce privilegovanou cestu, zatímco administrátoři jinou řízenou cestu, aktivovanou pouze v případě potřeby. Nedávejte externí agentuře trvalý neomezený přístup, pokud postačí schválené a protokolované okno údržby.
7. Odkládání aktualizací a nápravy zranitelností
Databázové stroje, operační systémy, ovladače, rozšíření a nástroje pro správu obsahují zranitelnosti. Systém může zůstat vystavený, i když je kód aplikace dobře udržován, pokud již není podporována používaná verze databáze nebo byla kritická bezpečnostní aktualizace odkládána donekonečna.
Cesta útoku a dopad na firmu
Útočníci zjistí verzi databáze prostřednictvím vystavených služeb, chybových zpráv, odcizených inventárních dat nebo napadených interních systémů. Poté použijí veřejně dostupný exploit, zranitelné rozšíření nebo slabinu ve vrstvě správy. Některé útoky vyžadují ověření, jiné nikoli.
Úspěšné zneužití může odhalit nebo změnit data, vytvořit privilegovaný účet, spustit kód nebo narušit dostupnost. Odkládané aktualizace také komplikují obnovu, protože nouzové změny probíhají pod tlakem a bez dostatečného testování.
Jak problém odhalit a opravit
Určete jasného vlastníka operačního systému, databázového stroje, rozšíření, ovladačů a bezpečnostních nástrojů. Udržujte inventář s verzemi, stavem podpory, vystavením, vlastníkem z hlediska firmy a oknem údržby. Odebírejte bezpečnostní upozornění dodavatelů a používejte skenování zranitelností, ale nálezy skeneru ověřujte podle skutečně nainstalovaných verzí a konfigurace.
Pro kritické zranitelnosti stanovte termíny podle rizika, aktualizace testujte na reprezentativním testovacím systému a udržujte plán návratu zpět. Bezpečnostní aktualizace aplikujte včas, odstraňujte nepodporované komponenty a dokumentujte schválené výjimky s datem vypršení. Upozorněte, pokud shoda s aktualizacemi klesne pod zásady organizace. Aktualizace není dokončena, dokud se služby správně nerestartují a monitoring nepotvrdí běžný provoz.
Jak odhalit vystavenou databázi dříve než útočník
Začněte otázkou: může nedůvěryhodné zařízení dosáhnout na databázi nebo její administrátorské rozhraní? Testujte z veřejného internetu i z interních sítí, které přístup mít nemají. Zkontrolujte DNS záznamy, IPv4 a IPv6 adresy, cloudové firewally, hostitelské firewally a load balancery. Služba bezpečná přes IPv4 může být stále vystavená přes IPv6.
Dále ověřte, co se stane po navázání připojení. Vyžaduje server TLS? Odmítá ověřování výchozí a slabá hesla? Může aplikační účet číst nebo měnit tabulky mimo svou roli? Zaznamenávají se neúspěšná přihlášení, změny oprávnění, změny schématu a neobvyklé exporty centrálně?
Protokolování je užitečné pouze tehdy, když je někdo nebo něco kontroluje. Odesílejte databázové, systémové a firewallové protokoly do chráněného centrálního systému, kde je útočník nemůže potají upravovat. Vytvořte upozornění na opakovaná selhání ověřování, nové privilegované uživatele, přístup z nových zemí nebo sítí, rozsáhlé exporty, vypnutý audit, neobvyklý objem dotazů a neočekávané restarty služeb. Upravujte upozornění tak, aby na ně zaměstnanci mohli reagovat, místo aby ignorovali trvalý šum.
Připravte se na napadení pomocí nezávislých záloh
Bezpečná konfigurace snižuje pravděpodobnost napadení, ale nemůže zaručit, že účet, aplikace nebo pracovní stanice administrátora nikdy nebudou prolomeny. Plán obnovy by měl předpokládat, že útočník může získat kontrolu nad produkčním serverem a pokusit se data i lokální zálohy zašifrovat, poškodit nebo smazat.
Udržujte testované, šifrované zálohy mimo lokalitu, které napadený server nemůže odstranit. Safenix poskytuje off-site zálohování firemních serverů s uložením dat v Německu; data jsou po dobu retenčního okna neměnná a šifrovaná klíčem kontrolovaným zákazníkem, který Safenix nikdy nedrží. Další informace najdete o šifrovaných zálohách mimo lokalitu s klíči kontrolovanými zákazníkem a omezeným přístupem z napadeného serveru.
Návrh zálohování by měl odpovídat systémům, které zákazník spravuje, včetně databázového serveru a podpůrné infrastruktury. Nejde o zálohovací plán pro web běžící na sdíleném hostingu a nelze předpokládat žádný tarif sdíleného hostingu. Než se na zálohu spolehnete, ověřte, že databáze je zachycena konzistentně, retence splňuje požadavky firmy, šifrovací klíče jsou v případě potřeby dostupné a obnova již byla úspěšně provedena.
Neměnnost pomáhá zabránit smazání nebo úpravě během retenčního období, zatímco uložení mimo lokalitu chrání před selháním nebo incidentem v produkční lokalitě. Šifrování pod kontrolou zákazníka znamená, že poskytovatel záloh nemá klíč potřebný ke čtení chráněných dat. Tyto prvky snižují dopad obnovy, ale neopravují nezabezpečenou databázi. Obnovení napadeného serveru bez opravy jeho vystavení, přihlašovacích údajů nebo aktualizací pouze zopakuje incident.
Produkční a údržbový přístup pro malé týmy
Malé firmy a agentury mají často omezený počet zaměstnanců, což činí oddělení přístupů obzvlášť důležitým. Běžnou aplikační cestu udržujte úzkou a předvídatelnou. Údržba by měla využívat pojmenované účty, oddělenou síťovou trasu a časově omezené zvýšení oprávnění. Poskytovatel podpory by měl dostat pouze přístup potřebný pro dohodnutý úkol, nikoli trvalé administrátorské heslo sdílené mezi zákazníky.
Udržujte registr přístupů zahrnující zaměstnance, dodavatele, agentury, servisní účty a nouzové údaje. Kontrolujte jej po změnách personálu a předání klientů. Používejte bezpečný proces správy tajemství, vyžadujte schválení produkčních změn a zaznamenávejte, kdo jednotlivé změny provedl. Nouzový účet může existovat, ale jeho použití by mělo vyvolat upozornění a mělo by se pravidelně testovat.
Kontrolní seznam pro ověření ochrany databáze
- Veřejná dostupnost: Může se k databázi nebo administrátorskému portu připojit externí či nedůvěryhodný interní hostitel? Jsou pokryty IPv4 i IPv6?
- Síťová kontrola: Umožňují pravidla firewallu a seznamy povolených IP adres přístup pouze jmenovaným zdrojům pro aplikace, reporting a údržbu?
- Ověřování: Byly odstraněny nebo zabezpečeny výchozí, neaktivní a sdílené účty? Používají administrátoři silná hesla a vícefaktorové ověřování?
- Tajemství: Chybí hesla a klíče ve zdrojovém kódu, skriptech, tiketech a konfiguračních repozitářích? Je obměna otestována?
- Nejnižší oprávnění: Má každý aplikační i lidský účet pouze potřebný přístup, včetně rolí pouze pro čtení tam, kde je to vhodné?
- Šifrování: Je TLS vyžadováno a správně ověřováno pro aplikační, administrátorská, replikační a datová připojení?
- Monitoring: Jsou události ověřování, oprávnění, exportu dat, firewallu a konfigurace centrálně protokolovány s použitelnými upozorněními?
- Vlastnictví aktualizací: Kdo odpovídá za každou databázi, operační systém, rozšíření a nástroj pro správu? Jsou zranitelnosti sledovány až do odstranění?
- Připravenost obnovy: Jsou zálohy šifrované, uložené mimo lokalitu, neměnné po dobu retence a nedostupné pro smazání z produkčního serveru? Byla otestována úplná obnova?
Tyto otázky mění zabezpečení databáze z jednorázového úkolu při instalaci na průběžnou provozní disciplínu. Kontrolujte je po migracích, významných změnách aplikace, fluktuaci zaměstnanců a bezpečnostních incidentech. Databáze, ke které je obtížné se dostat, která má přísně omezená oprávnění, je aktualizovaná a obnovitelná, se mnohem méně pravděpodobně stane událostí ohrožující samotné fungování firmy.