it-swarm-eu.dev

Správa šifrovacích klíčů webové aplikace

V kostce se podívejme na webovou aplikaci, která ukládá některé informace do databáze jako šifrovaná data. I když se záměrně snažím udržet toto nějaké obecným, zde jsou některé předpoklady:

  • Šifrovaná data jsou uložena pouze v databázi (nikde jinde). Některá pole v daném záznamu jsou šifrována, jiná ne.
  • Webová aplikace musí zapsat šifrovaná data do databáze.
  • Webová aplikace musí být schopna číst a zobrazovat šifrovaná data. Data jsou zobrazena pouze v ověřovací a autorizované spravované části aplikace.
  • Data jsou citlivými informacemi, které je třeba chránit v případě, že jsou data vystavena/zpřístupněna (bez klíčů *).

Otázky:

  • Kam a jak ukládáte klíče používané pro šifrování? Za prvé, jak spravujete klíč v systému, kde jsou webový a databázový server stejný? Za druhé, jak spravujete klíč v systémech, kde jsou webový server a DB servery oddělené?
  • Jsou klíče pouze soubory s omezením oprávnění? Uloženo v nějakém samostatném nástroji/softwaru? Viděl jsem zmínit, že někdy jsou šifrovací klíče také šifrované, ale není jasné, kde to může pomoci.

Vím, že se jedná o docela základní bezpečnostní otázku, takže pokud existují zdroje, které mi možná chybí, bylo by to také velmi, velmi užitečné. Strávil jsem spoustu času (v průběhu let) snahou tyto informace pochopit na základě informací o zabezpečení webových aplikací (OWASP, PCI DSS atd.), Ale mnohokrát jsou tyto informace velmi obecné (např. „Chrání data“ "," zašifrovat data ") nebo velmi konkrétní (" zašifrovat něco pomocí AES to udělá ... ").

* Chápu, že se nejedná o úplné bezpečnostní řešení. Chápu, že existuje několik vektorů, jak se dostat k této informaci a dekódovat ji. Uznávám, že to může být v tomto světle špatná otázka :)

Upraveno, aby se k této otázce přidaly další informace o předpokladech

47
Rob

Kam/jak ukládáte klíče používané pro šifrování?

Standardní přístup, pokud používáte vestavěné šifrování na něčem, jako je databáze SQL nebo Oracle, databáze vygeneruje šifrovací klíč a zašifruje jej jiným klíčem na ochranu klíčů nebo hlavním klíčem. Může to být přístupová fráze nebo delší klíč uložený v např. soubor .pem.

To je obvykle uloženo v omezeném adresáři, ke kterému mají přístup pouze root/administrátor a účet databázové služby. Při spuštění databáze je klíč načten a načten do paměti. To se potom používá k dešifrování šifrovacích klíčů.

Za prvé, v systému, kde jsou web a databázové servery stejné, jak spravujete klíč?

Klíč je uložen v adresáři na serveru. Obnovení nebo odvolání je obvykle prostřednictvím databázového programu.

Za druhé, jak spravujete klíč v systémech, kde jsou webový server a DB servery oddělené?

Klíč je uložen lokálně pouze na databázovém serveru. Bezpečnější možností je použití modulu Hardware Security Module (HSM) v obou scénářích. Jedná se o hardwarové zařízení, které je připojeno k serveru a používá se k uložení klíče místo omezené složky na serveru.

Jsou klíče pouze soubory s omezením oprávnění? Uloženy v nějakém samostatném nástroji/softwaru? Viděl jsem zmínit, že někdy jsou šifrovací klíče také šifrované, ale není jasné, kde to může pomoci.

Omezení složky je přijatelné, pokud spravujete přístup správce a sledujete věci, jako jsou neautorizovaná přihlášení, přihlášení jako účet služby, nové účty nebo skupiny přidané s přístupem do složky. Jak již bylo uvedeno výše, HSM je bezpečnější volbou, pokud to data, která chráníte, a hrozby, kterým čelíte, vyžadují.

Obecně databáze vytvoří klíče instance nebo tabulky a poté ji zašifruje hlavním klíčem. Další šifrování hlavního klíče je minimální.

11
Rakkhi

Ačkoli v předchozí odpovědi byly poskytnuty některé dobré informace, existuje kritická chyba v designu, která si opravdu nevšimla - ale vychází z některých implicitních předpokladů v otázce.

Rozdíl by neměl být mezi:

  • Webová aplikace a DB na stejném serveru
  • Webová aplikace a DB na různých serverech
  • šifrování aplikace vs. db

Návrh by měl začít od:

  • Kdo potřebuje přístup ke šifrovacím/dešifrovacím klíčům?

Nebo ve skutečnosti ještě správnější:

  • Kdo je odpovědný za ochranu důvěrnosti údajů?

Která zase vychází z:

  • Jakým hrozbám se snažíte chránit?
    Nebo
  • Komu se snažíte zabránit ve čtení vašich údajů?

Pouze na základě těchto otázek můžete navrhnout správně vytvořený kryptosystém. (A zabránit krypto-vílovému prachu, na který odkazuje @ D.W.).

Některé příklady scénářů:

  • Uživatel by měl být odpovědný za šifrování a zabránit tak správcům aplikací v prohlížení dat
  • Klientská aplikace by měla být odpovědná, aniž by se musela účastnit uživatel - ale to musí být stále provedeno na straně klienta (např. Zálohovací program).
  • Appserver aplikovatelně a konkrétně šifruje vybraná data, jako součást obchodní logiky (i data dba nemohou vidět)
  • Databázový server by měl automaticky a transparentně šifrovat uložená data. (Toto chrání pouze proti krádeži souboru db/fyzického disku, s upozorněním ...).

Pro zjednodušení předpokládejme, že šifrování by mělo být provedeno na straně serveru, odpovědnost leží na serveru a koncový uživatel (a správce) nemá žádný vliv na šifrování.

Hlavní otázkou tedy je šifrování prováděné aplikačním serverem nebo databázovým serverem? (Ve skutečnosti to není tak jednoduché, existují i ​​jiné možnosti ...)
Toto, jako většina bezpečnostních otázek, se vrací ke kompromisu:

  • Spravujete své vlastní klíče, nebo upřednostňujete abstraktní infrastrukturu automaticky? (původní otázka ... více informací níže ...)
  • Bojíte se škodlivého (nebo neschopný nezkušení) programátoři?
  • Bojíte se škodlivých administrátorů?
  • Máte obavy z neoprávněného použití aplikace?
  • Máte obavy z neautorizovaného přístupu SQL?
  • Máte obavy z neautorizovaného přímého přístupu k souborům?
  • Bojíte se krádeží fyzických disků/serverů?

A tak dále. (Upozorňujeme, že některé z výše uvedených otázek nejsou relevantní a nelze je vyřešit šifrováním serveru).


Nyní předpokládejme, že jste se na základě výše uvedeného rozhodli mezi šifrováním Appserveru a šifrováním databáze.
Všimněte si, že ať už jsou webový server a db na stejném serveru, či nikoliv, nemá zde téměř žádný účinek - pokud aplikace šifruje, posílá do db pouze „speciální“ data, jinak je to moot. Avšak toto nemá ovlivňuje diskusi o výše uvedených hrozbách - některé problémy jsou konstrukcí zastaralé, některé jsou vylepšeny ...

  • Šifrování webového/aplikačního serveru
    • Šifrovací klíč (EK), který používáte k šifrování dat, by měl být sám šifrován pomocí klíčového šifrovacího klíče ( KEK).
    • Šifrované EK by mělo být uloženo na chráněném místě - může to být soubor, klíč registru, cokoli - důležitá věc je omezení přístupu k němu pouze pro uživatele Appserveru (a možná i pro administrátora - viz níže).
    • KEK také potřebuje ochranu - to je trochu složitější.
      Pokud používáte Windows, máte snadný přístup k DPAPI - to umožňuje správu klíčů na úrovni OS, takže můžete mít OS zašifrovat svůj KEK a přehledně spravovat klíče pro vás. (V zákulisí se DPAPI nakonec spoléhá na znalost hesla uživatele (v USER_MODE), takže je to poslední slabina skutečného známého tajemství - ale nikdo jiný by neměl vědět heslo serveru v první místo, že?)
      Další možností je externí zařízení/HSM, diskutováno dále níže.
    • KEK také potřebuje řízení přístupu, samozřejmě - restriktivní seznamy ACL a další.
    • Existuje několik důvodů, proč chcete oddělit EK od KEK: nechcete šifrovat obrovské množství dat jediným klíčem; pokud potřebujete vyměnit klíč, je to mnohem snazší (stačí znovu zašifrovat EK s novým KEK); na KEK můžete použít silnější, pomalejší a složitější šifrování/úložiště; pokud potřebujete kompatibilitu s PCI, můžete implementovat split-knowledge na KEK; a více.
    • EK i KEK by neměly být dlouhodobě nešifrovány - v závislosti na vaší platformě/jazyce to znamená neukládat jej do objektu String v .NET nebo Java. Místo toho jej uložte do měnitelných bajtových polí a vždy zajistěte, abyste je co nejdříve zlikvidovali.
    • Některé rámce dokonce jdou o krok dále a poskytují konkrétní chráněné objekty. Např. v .NET můžete použít třídy System.Security.Cryptography.ProtectedMemory a/nebo System.Security.Cryptography.ProtectedData , aby byly klíče chráněny i v paměti.
  • Šifrování databáze
    • Pokud váš databázový server provádí šifrování, je to mnohem snazší: tabulky/pole jsou nakonfigurovány tak, aby automaticky šifrovaly veškerá data v něm uložená, správa klíčů je zcela transparentní (z PoV aplikace, nikoli z DBA), a již brzy.
    • Například Oracle i MS SQL Server podporují automatické vestavěné šifrování. Pro MSSQL je správa klíčů složitá, přesto se podobá tomu, co jsem popsal výše. Zjednodušeno: V databázi je uložen EK, který dba může nakonfigurovat pro šifrování/dešifrování tabulek nebo polí. Toto je v chráněné tabulce, šifrované pomocí KEK, dále šifrované pomocí KEK na úrovni serveru, následně šifrované pomocí DPAPI na účtu služby MSSQL.
    • Alternativně MSSQL také podporuje použití asynchronního šifrování, např. uložení párů veřejného/soukromého klíče - to může být užitečné v konkrétních scénářích.
  • Třetí možnost: externí šifrovací úložiště, nebo HSM (hardware security module) . Může se jednat o sdílené hardwarové zařízení, server nebo hardwarovou kartu nebo hardwarový klíč ... atd.
    • Tato zařízení jsou navržena tak, aby velmi bezpečně chránila malé kousky dat - např. Váš KEK.
      Znovu, další důvod, proč oddělit EK od KEK - to vám umožní efektivně šifrovat a dešifrovat množství dat pomocí EK, zatímco stále bezpečně spravujete KEK.
    • K HSM se obvykle přistupuje přes speciální ovladač nebo API, je možné je také připojit do šifrování databáze (v závislosti na produktu atd.).
29
AviD