Přihlašovací údaje k databázi: chraňte hesla a řetězce

Přihlašovací údaje k databázím patří v podnikovém prostředí mezi nejcennější tajemství. Uniklé uživatelské jméno a heslo mohou zpřístupnit záznamy zákazníků, finanční informace, data aplikací nebo celý produkční systém. Připojovací řetězce mohou odhalit hostitele databáze, port, název databáze a způsob ověřování, i když heslo není na první pohled zřejmé.

Riziko se neomezuje pouze na zdrojový kód aplikace. Přihlašovací údaje se mohou objevit v konfiguračních souborech, tiketech podpory, protokolech nasazení, obrazech kontejnerů, monitorovacích nástrojích, zálohách serverů a chatových zprávách. Agentury čelí také další výzvě: několik klientských prostředí může spravovat stejný tým, ale každý klient potřebuje jasné oddělení přístupů, odpovědností a důkazů.

Dobré zabezpečení přihlašovacích údajů k databázi je proto proces, nikoli jediný produkt. Kombinuje správu tajemství, oddělení prostředí, účty s nejmenšími oprávněními, šifrování, auditování, rotaci a pečlivě navržený nouzový přístup.

Zmapujte, kde mohou přihlašovací údaje k databázi uniknout

Než zvolíte nástroje, identifikujte každé místo, kde může být přihlašovací údaj vytvořen, kopírován, zpracováván nebo uložen. Toto cvičení často odhalí větší míru vystavení, než se očekává, protože přihlašovací údaje sledují pracovní postup systému, nikoli pouze samotnou aplikaci.

• Zdrojový kód: vývojáři mohou během testování natvrdo vložit hesla, klíče API nebo kompletní připojovací řetězce a zapomenout je před odesláním do repozitáře odstranit.
• Konfigurační soubory: nastavení aplikace, konfigurace webového serveru a manifesty nasazení mohou obsahovat tajemství v prostém textu.
• Tikety a chat: technik může pro urychlení řešení problému vložit heslo nebo připojovací řetězec do zprávy, kde zůstane v prohledatelné historii konverzace.
• Protokoly: zprávy o neúspěšném připojení, ladicí výstup, příkazy SQL a trasování výjimek mohou obsahovat uživatelská jména, hostitele nebo parametry připojení.
• Zálohy: záloha serveru může společně obsahovat konfigurační soubory, adresáře aplikací, skripty, databáze, úložiště přihlašovacích údajů a protokoly.
• Obrazy kontejnerů: tajemství zkopírovaná do souboru Dockerfile, vrstvy obrazu nebo artefaktu sestavení mohou zůstat dostupná i po odstranění viditelného souboru.
• Systémy CI/CD: proměnné pipeline, výstup úloh, mezipaměti pracovních prostorů a artefakty sestavení mohou zpřístupnit přihlašovací údaje uživatelům nebo službám, které je nepotřebují.

Vytvořte inventář pro každou aplikaci a databázi. Zaznamenejte, k čemu se tajemství používá, ke kterému prostředí patří, kdo k němu může přistupovat, kde je uloženo, jak se rotuje a jak by bylo odvoláno. S inventářem zacházejte jako s citlivou dokumentací: měl by popisovat tajemství, nikoli obsahovat jeho samotnou hodnotu.

Používejte správu tajemství místo rozptýlené konfigurace

Hesla a klíče by měly být uloženy v systému určeném pro tajemství, nikoli v repozitáři, tabulce nebo běžném sdíleném disku. Správce tajemství může zajistit řízený přístup, šifrování, auditní záznamy, verzování a automatické načítání při nasazení nebo za běhu. Aplikace obdrží potřebnou hodnotu, aniž by ji vývojáři museli kopírovat do zdrojového kódu.

Přístupy ke správě tajemství se liší. Některé organizace používají vyhrazený trezor, jiné spravovanou službu cloudového poskytovatele a další šifrovaný konfigurační mechanismus integrovaný s platformou pro nasazení. Při porovnávání přístupů prozkoumejte nástroje pro správu přihlašovacích údajů k databázím a porovnejte jejich modely přístupu, auditování a rotace se svými skutečnými provozními požadavky.

Vhodný návrh by měl odpovědět na praktické otázky:

• Lze přístup udělit identitě úlohy namísto dlouhodobě platného sdíleného hesla?
• Lze oprávnění omezit podle aplikace, klienta, prostředí a databáze?
• Zaznamenávají se čtení a změny v auditní stopě?
• Lze tajemství verzovat a odvolat bez opětovného sestavení každého systému?
• Lze přístup automaticky zamítnout, když osoba opustí projekt nebo je integrace vyřazena?
• Mohou vývojáři pracovat s bezpečnými testovacími údaji, aniž by viděli produkční hodnoty?

Správa tajemství není automaticky bezpečná jen proto, že nabízí rozhraní trezoru. Chránit je třeba také účet správce trezoru, obnovovací klíče, integrační tokeny a zásady přístupu. Udržujte počet osob s rozsáhlými oprávněními ke čtení tajemství nízký, používejte silné ověřování, pravidelně kontrolujte přístupy a nedovolte, aby jediná pipeline nebo správce mohl načíst přihlašovací údaje všech klientů.

Oddělte prostředí, klienty a odpovědnosti

Vývoj, testovací a produkční prostředí by neměla sdílet přihlašovací údaje k databázi. Testovací aplikace by se neměla moci připojit k produkční databázi jen proto, že používá stejnou konfigurační šablonu. Používejte oddělené databázové účty, samostatná tajemství a tam, kde je to praktické, také samostatné instance databází nebo servery.

Stejný princip platí mezi klienty. Agentura by neměla používat jeden databázový účet pro několik zákazníků, i kdyby byl pro podporu pohodlný. Každé klientské prostředí by mělo mít vlastní přihlašovací údaje, zásady přístupu a auditní stopu. To omezuje dopad úniku a umožňuje určit, ke kterému systému bylo přistoupeno.

Zdokumentujte rozdělení odpovědností. Klient může vlastnit databázi a schvalovat privilegovaný přístup, zatímco agentura provozuje aplikaci a provádí údržbu. Alternativně může agentura spravovat server, ale před změnami přihlašovacích údajů vyžadovat souhlas klienta. Oba modely mohou fungovat, pokud jsou jasně definované.

Definujte:

• Kdo vlastní databázi a její data
• Kdo může vytvářet, číst, rotovat a odvolávat přihlašovací údaje
• Kdo schvaluje produkční přístup
• Který pracovník podpory může přistupovat ke kterému klientskému prostředí
• Jak se přístup odebere po skončení smlouvy nebo projektu
• Jak se nouzový přístup vyžaduje, zaznamenává a kontroluje

Nezaměňujte provozní odpovědnost za neomezený přístup. Role hostingu, vývoje nebo podpory může potřebovat udržovat aplikaci, aniž by daná osoba směla číst každou tabulku databáze nebo exportovat všechna data.

Uplatňujte u databázových účtů princip nejmenších oprávnění

Řízení přístupu k databázi by mělo začínat oddělenými účty pro oddělené funkce. Účet aplikace obvykle potřebuje pouze oprávnění vyžadovaná danou aplikací. Služba pro reporting může potřebovat přístup pouze ke čtení vybraných pohledů, zatímco proces migrace může dočasně vyžadovat oprávnění ke změně schématu. Ani jeden z nich by pro běžnou práci neměl používat účet vlastníka databáze.

Užitečné hranice mezi účty

• Účet aplikace: omezený na požadovanou databázi, schéma, tabulky, procedury nebo pohledy.
• Účet migrace: aktivovaný pouze během schválených prací na nasazení a poté omezený nebo deaktivovaný.
• Účet reportingu: pouze pro čtení, ideálně nad řízenými pohledy nebo reportovací replikou.
• Účet podpory: individuální přístup s časovým omezením a auditní stopou, nikoli trvalé sdílené heslo správce.
• Účet zálohování: omezený na operaci zálohování a bez možnosti měnit data aplikace, pokud to platforma umožňuje.

Oprávnění kontrolujte při změně aplikace. Stará oprávnění často přetrvávají dlouho poté, co byla funkce, dodavatel nebo integrace odstraněna. Oprávnění testujte z identity aplikace, nikoli pouze z účtu správce; jinak mohou nadbytečné přístupy zůstat skryté.

Chraňte přihlašovací údaje při přenosu i v úložišti

Šifrování při přenosu je nezbytné, když se aplikace připojuje k databázi přes síť. Nakonfigurujte databázi a klienta tak, aby tam, kde je to podporováno, používali TLS, správně ověřujte certifikáty a vyhněte se nastavením, která pouze šifrují provoz, ale neověřují cílové místo. Připojovací řetězec obsahující heslo je citlivý i tehdy, když je samotné připojení šifrované.

V klidovém stavu by měla tajemství šifrovat služba, která je ukládá, a přístup by měl být omezen na identity, které jej potřebují. Šifrování neodstraňuje potřebu řízení přístupu. Každý, kdo může tajemství dešifrovat, získat přístup ke klíči nebo načíst nechráněný export, může přihlašovací údaj stále získat.

Nepředpokládejte, že odstranění řádku z aktuálního konfiguračního souboru odstraní údaj také z historie. Repozitáře Git uchovávají předchozí commity, registry kontejnerů vrstvy obrazů, tiketovací systémy přílohy a zálohovací systémy starší verze. Pokud byl údaj odeslán do repozitáře nebo sdílen, považujte jej za odhalený a rotujte jej, i když byla viditelná kopie odstraněna.

Rotujte a odvolávejte přihlašovací údaje promyšleně

Rotaci je třeba naplánovat ještě před incidentem. Rozhodněte, jak se změní každé heslo k databázi, klíč API a certifikát, kam se uloží nová hodnota a jak ji aplikace obdrží. Pokud služba během přechodu nepodporuje dva platné přihlašovací údaje, naplánujte řízené servisní okno a potvrďte plán návratu, který nebude trvale obnovovat staré tajemství.

Pokud to technologie umožňuje, upřednostňujte krátkodobě platné přihlašovací údaje nebo automatickou rotaci. Dlouhodobě platná hesla vyžadují přísnější provozní kontrolu, protože mohou zůstat ve starých zálohách, noteboocích vývojářů, mezipamětech sestavení nebo zapomenutých skriptech.

Odvolání se od rotace liší. Rotace nahradí přihlašovací údaj, přičemž starý může krátce zůstat platný; odvolání přístup zastaví. Přihlašovací údaj okamžitě odvolejte, pokud máte podezření na jeho odhalení, pokud jej zaměstnanec nebo dodavatel již nepotřebuje nebo pokud byla integrace vyřazena. Po odvolání prozkoumejte protokoly kvůli použití starého údaje a ověřte, že závislé služby fungují s náhradou.

Udržujte tajemství mimo vývojové a dodací procesy

Lokální soubor .env může být pro vývoj pohodlný, ale neměl by být odeslán do repozitáře, nahrán do balíčku podpory ani zkopírován do produkčního obrazu. Poskytněte bezpečný ukázkový soubor obsahující názvy proměnných bez skutečných hodnot a v repozitáři vynucujte pravidla ignorování i skenování tajemství.

Stejnou disciplínu vyžadují pipeline CI/CD. Citlivé proměnné ukládejte do chráněného úložiště tajemství pipeline nebo je za běhu načítejte z trezoru. Maskujte hodnoty ve výstupu, pokud možno zabraňte zobrazování tajemství v argumentech příkazového řádku, omezte, kdo může upravovat definice pipeline, a chraňte větve pro nasazení. Kontrolujte artefakty sestavení a mezipaměti, protože tajemství může uniknout prostřednictvím vygenerované konfigurace, i když protokol pipeline vypadá čistě.

Obrazy kontejnerů vyžadují zvláštní kontrolu. Nepoužívejte argumenty sestavení ani instrukce prostředí jako trvalé úložiště tajemství. Prohlédněte historii a vrstvy obrazu, používejte vkládání za běhu, udržujte registry soukromé a po odvolání přihlašovacích údajů odstraňte napadené obrazy. Kontejner, který může číst tajemství, by měl mít zároveň zabráněno ve čtení nesouvisejících tajemství jiných klientů nebo prostředí.

Bezpečně zpracovávejte tikety, protokoly a řešení problémů

Týmy podpory potřebují standard pro vyžadování diagnostických informací. Požadujte redigovanou konfiguraci, chybové kódy, časová razítka a identifikátory zdrojů namísto úplných připojovacích řetězců. Definujte pole, která je nutné vždy odstranit: hesla, tokeny, soukromé klíče, relační cookies a úplné autentizační hlavičky.

Bezpečnost protokolování je třeba testovat, nikoli předpokládat. Prohledejte protokoly aplikace, webového serveru a auditu databáze, výstup CI a upozornění monitoringu kvůli polím podobným heslům, vzorům tokenů, schématům připojovacích řetězců a názvům hostitelů databází. Pravidla redakce by měla pokrývat strukturovaná pole i nestrukturované zprávy výjimek.

Nikdy neposílejte přihlašovací údaje běžným chatem nebo e-mailem. Pokud je nouzové sdílení nevyhnutelné, použijte schválený zabezpečený kanál s omezeným přístupem a stanovenou dobou platnosti a po použití údaj rotujte. Heslo zveřejněné v soukromé týmové místnosti se stále kopíruje do více zařízení, uchovává je poskytovatel služby a potenciálně jej vidí lidé, kteří se do místnosti připojí později.

Zohledněte přihlašovací údaje uvnitř záloh serverů

Zálohy serverů často obsahují přihlašovací údaje, protože zachycují konfiguraci aplikace a soubory operačního systému. Ochrana záloh proto přispívá k zabezpečení přihlašovacích údajů k databázi, ale nenahrazuje správce tajemství ani správnou rotaci. Záloha může uchovávat staré heslo dlouho poté, co aplikace přešla na nové, a každý, kdo ji může obnovit, může být schopen soubory prohlédnout.

U serverů, které ovládá zákazník, posuzujte společně šifrování zálohy, správu klíčů, dobu uchování a oprávnění k obnově. Safenix poskytuje off-site zálohování firemních serverů, přičemž data jsou uložena v Německu, šifrována klíčem, který Safenix nikdy nedrží, a neměnná po celou dobu zvoleného retenčního období. Tato ochrana šifrováním záloh a správou klíčů pod kontrolou zákazníka pomáhá snižovat riziko, že se ukradená záloha stane zdrojem přihlašovacích údajů k databázi.

Tato ochrana stále vyžaduje provozní rozhodnutí. Určete, kdo může požádat o obnovu, kdo může přistupovat k obnoveným souborům, zda se obnova provádí v izolovaném prostředí a jak se s obnovenými přihlašovacími údaji následně nakládá. Obnovený server by se neměl automaticky stát cestou do produkce. Pokud je to možné, provádějte obnovu pro účely šetření v omezené síti, připojte zálohovaná data pouze pro čtení a všechny přihlašovací údaje nalezené v obnovené kopii odstraňte nebo rotujte.

Safenix chrání servery ovládané zákazníkem; nejde o zálohovací plán pro weby běžící na sdíleném hostingu. Za konfiguraci správy tajemství serveru, přístupová oprávnění a rozhodnutí o tom, co má být zahrnuto do zálohy, zůstává odpovědný zákazník nebo jeho poskytovatel služeb.

Používejte bezpečný nouzový postup

Pokud mohlo dojít k úniku přihlašovacího údaje, záleží na rychlosti, ale ukvapené změny mohou způsobit výpadek nebo zničit důkazy. Udržujte krátký a otestovaný postup pro řešení incidentů dostupný lidem, kteří jej mohou potřebovat.

1. Omezte vystavení: omezte přístup k repozitáři, tiketu, chatu, pipeline nebo úložišti a uchovejte relevantní záznamy.
2. Klasifikujte tajemství: identifikujte databázi, klienta, prostředí, oprávnění a systémy, které jej mohou používat.
3. Odvolejte nebo rotujte: deaktivujte odhalený přihlašovací údaj a vydejte náhradu prostřednictvím schváleného procesu správy tajemství.
4. Prověřte použití: zkontrolujte protokoly ověřování databáze, protokoly aplikace, záznamy VPN, přístupy do repozitáře a auditní události cloudu nebo serveru.
5. Odstraňte kopie: podle potřeby odstraňte odhalené tikety, artefakty, obrazy nebo soubory, přičemž důkazy incidentu bezpečně uchovejte.
6. Prověřte zálohy: zjistěte, které verze záloh obsahují staré tajemství, a zajistěte omezení přístupu k obnově.
7. Potvrďte obnovu: otestujte aplikaci s novým přihlašovacím údajem a ověřte, že starý již nefunguje.
8. Vylepšete kontrolu: zdokumentujte příčinu a přidejte preventivní kontrolu, například skenování tajemství, lepší redakci nebo kratší dobu platnosti přihlašovacích údajů.

Obnovu ze zálohy nepoužívejte jako první reakci na uniklé heslo. Obnovení staršího serveru může obnovit také kompromitovaný přihlašovací údaj, zranitelný software nebo zastaralá pravidla přístupu. Zálohy slouží k obnově; reakce na únik přihlašovacích údajů by měla být řízena prostřednictvím odvolání, vyšetřování a řízeného opětovného nasazení.

Praktické kontroly pro agentury a firmy

Tyto kontroly provádějte při nástupu klienta, během významných nasazení a po změnách zaměstnanců nebo dodavatelů:

• Prohledejte repozitáře, historii commitů, skripty nasazení a vrstvy kontejnerů kvůli heslům, tokenům a vzorům připojovacích řetězců.
• Ověřte, zda nejsou soubory .env, exporty konfigurace nebo výpisy databází veřejně dostupné či zahrnuté v balíčcích podpory.
• Prohlédněte protokoly a výstup CI/CD kvůli autentizačním polím, chybám SQL, argumentům příkazů a nemaskovaným proměnným.
• Sepište každý produkční databázový účet a potvrďte jeho vlastníka, účel, oprávnění, poslední rotaci a poslední použití.
• Ověřte, že vývojové a testovací systémy se svými běžnými přihlašovacími údaji nemohou ověřit vůči produkci.
• Zkontrolujte, kteří zaměstnanci, dodavatelé, servisní účty a pracovníci zálohování mohou načítat tajemství nebo obnovovat data serveru.
• Potvrďte, že databázová připojení ověřují šifrovací certifikáty a nepřecházejí na nešifrovaný přenos.
• Prověřte dobu uchování záloh a oprávnění k obnově včetně toho, kdo může přistupovat k obnoveným konfiguračním souborům.
• Otestujte odvolání a nahrazení přihlašovacích údajů bez závislosti na nezdokumentovaném hesle správce.

U každého přihlašovacího údaje si položte poslední otázku: kdyby se tato hodnota dnes objevila ve veřejném repozitáři, jak rychle by bylo možné zastavit přístup, jak by se identifikovalo zasažené prostředí a kdo by za reakci odpovídal? Pokud odpověď závisí na nalezení člověka, který si pamatuje starý postup, kontrola ještě není spolehlivá.