it-swarm-eu.dev

Šifrování databázových polí je obecně špatný nápad?

Pracuji na malé společnosti, to jsem doslova já (programátor) a majitel. Majitel mě požádal, abych zašifroval několik polí do databáze, abych chránil data zákazníků. Toto je webová aplikace, která pomáhá právním firmám spravovat jejich data, takže v zásadě ukládá informace o osobách a soudních sporech (kdo je žalován, proč, za kolik). Považuje tyto citlivé informace, které by neměly být snadno vidět. Obává se, že „nechci, aby tyto informace viděli neautorizovaní lidé“. O tato data by se mohly zajímat pouze jiné právnické firmy, takže by to nemělo být tak důležité jako například kreditní karty.

Četl jsem o tom hodně na webu a přemýšlel jsem o jednoduchém použití symetrického šifrování v těchto polích, takže výkon není tak špatný. Klíč bude uložen na serveru. Avšak this vlákno v stackoverflow říká, že je to špatný nápad.

Nechápu, jak může být šifrování polí a uložení klíče na serveru tak zbytečné. Nebojím se ukradených disků, protože jsou na Amazonu EC2. Nejsem odborník na bezpečnost, ale podle mého názoru, kdyby se něco pokazilo, řekl bych, že databáze uniká. I tehdy by byly důležité informace šifrovány. Teď, pokud se ten chlap podařilo dokonce hacknout na můj EC2 server, dobře, myslím, že by tu byla malá až žádná ochrana, kterou bych mohl udělat, abych tomu pomohl. Vzhledem k tomu, že jsme malá společnost, máme pouze jeden server, který dělá vše, od poskytování stránek až po ukládání dat.

Moje otázka je, vzhledem k tomu, že si můžeme dovolit pouze jeden server, šifrování těchto polí symetrickým klíčem, který je uložen na tomto serveru, ok?

65
Bhaskara

Obecné komentáře. Vypadá to, že by bylo užitečné pro vás a vašeho šéfa naučit se některé základní bezpečnostní koncepty, než budete pokračovat. Bezpečnost je specializovaná oblast. Nepožadovali byste náhodného člověka na ulici, aby na vás provedl operaci na otevřeném srdci; a neměli byste očekávat, že by průměrný vývojář softwaru věděl, jak zabezpečit vaše systémy.

Cítím zde některé mylné představy. Například to zní, jako by váš šéf porovnával zabezpečení s kryptografií. Ale to je chyba. Jak Bruce Schneier zdůraznil, Kryptografie není prach magie pixie, který můžete posypat systémem, aby byl zabezpečený . A jak Roger Needham jednou skvěle řekl: Pokud si myslíte, že kryptografie vyřeší váš problém, buď nerozumíte kryptografii, nebo nerozumíte vašemu problému .

Při zabezpečení počítačového systému je jedním z důležitých konceptů model hrozby . To znamená, že musíte pečlivě přemýšlet o tom, jaké druhy útoků a protivníků se snažíte zastavit a co ne. Neschopnost jasně promyslet model hrozby může vést k bezpečnostnímu divadlu : bezpečnostní mechanismy, které vypadají dobře na první pohled, ale ve skutečnosti jsou v praxi žalostně neadekvátní. Správné řízení bezpečnosti často spadá do řízení rizik : pečlivá analýza nejzávažnějších rizik a poté vymýšlení strategií ke zmírnění nebo řízení těchto konkrétních rizik.

Je také důležité pochopit, že zabezpečení je vlastnost nejslabšího odkazu: zabezpečení vašeho systému je stejně silné jako nejslabší spojení . Chyba zabezpečení v kterékoli části systému může ohrozit zabezpečení celého systému. To znamená, že neexistuje žádná odpověď, která by postačovala k ochraně vašeho systému; místo toho, k obraně vašeho systému, musíte získat zabezpečení přímo na mnoha místech.

Ponoření do detailů. Vypadá to, že vaším cílem je zabránit neoprávněnému odhalení citlivých dat. Pokud ano, budete se muset zaměřit na několik položek. Neexistuje žádná jednoduchá magická stříbrná kulka, která to vyřeší za vás; budete muset obecně pracovat na zabezpečení aplikací.

Dovolte mi navrhnout některé věci, které by pro vás měly být prioritami, pokud jsem správně porozuměl vašim cílům:

  • Zabezpečení aplikace. Musíte začít studovat zabezpečení webových aplikací. Nezáleží na tom, kolik kryptogramů hodíte na problém; pokud útočník v kódu vaší aplikace najde bezpečnostní díru, jste nahoře. Na pozadí zabezpečení webových aplikací má OWASP mnoho vynikajících zdrojů. Ujistěte se, že se dozvíte o OWASP Top Ten, o XSS, SQL vstřikování, dezinfekci/validaci vstupů, úniku výstupu, whitelistingu a dalších koncepcích.

  • Řízení přístupu. Vaše webová aplikace musí mít spolehlivé řízení přístupu, aby se zajistilo, že jeden uživatel vašeho systému nemůže přistupovat k informacím jiného uživatele (bez oprávnění). Podrobnosti o tom budou záviset na specifikách vašeho konkrétního systému, takže pokud potřebujete další pomoc, pravděpodobně budete muset položit samostatnou otázku s podrobnostmi o vaší aplikaci a vaší aktuální strategii pro řízení přístupu.

  • Ověřování. Vaše webová aplikace bude potřebovat způsob ověření svých uživatelů. Standardním schématem s nejmenším úsilím je pouze použití uživatelského jména a hesla. To však má v praxi vážná omezení, která jsou dobře známa. Pokud si uživatelé vyberou svá vlastní hesla, často si vyberou špatná hesla, což může narušit zabezpečení vašeho systému.

  • Životní cyklus zabezpečeného vývoje softwaru. Do procesu vývoje softwaru musíte integrovat zabezpečení. Při práci na softwarové architektuře byste měli myslet na bezpečnostní požadavky a provádět modelování hrozeb a analýzu architektonických rizik. Při psaní kódu musíte vědět o běžných chybách implementace, které mohou narušit zabezpečení a ujistěte se, že se jim vyhnete. Po vytvoření softwaru musíte otestovat jeho zabezpečení a neustále vyhodnocovat, jak se vám daří v zabezpečení. Při nasazení softwaru potřebují vaši pracovníci vědět, jak jej bezpečně spravovat. Společnost Microsoft má několik vynikajících zdrojů v zabezpečeném životním cyklu vývoje softwaru (SDL). Viz také BSIMM pro více informací.

  • Hodnocení bezpečnosti. Pokud máte obavy o bezpečnost, navrhuji nechat posoudit zabezpečení vaší aplikace. Jednoduchým výchozím bodem může být to, že někdo provede nejpodrobnější webovou aplikaci, aby zkontroloval určité druhy běžných chyb. To v žádném případě není zárukou bezpečnosti, ale někdy může pomoci sloužit jako budíček, pokud existuje mnoho závažných problémů. Můžete se podívat na služby WhiteHat Security; existuje také mnoho dalších, kteří provedou webové blokování.

Pokud máte pocit, že se nejedná o triviální závazek, omlouvám se, ale je tomu tak skutečně. Na druhou stranu, dobrá zpráva je, že existuje spousta zdrojů, a navíc se nemusíte stát odborným guruem na úrovni odborníků: stačí se seznámit s některými základními koncepty a některými běžnými bezpečnostními chyby v programování webu, a to se postará o většinu vašich potřeb.

101
D.W.

Šifrování dat v databázi bude chránit informace, pokud je databáze nějak ukradena. Nebude však dělat nic pro ochranu před napadením webové stránky. Například uhodnutím uživatelského jména/hesla. Může to někoho zpomalit, pokud napadlo server, protože musí najít klíč, ale nezastaví ho. Přichází také za potenciálně vysokou cenu. Například šifrovaná pole již nelze prohledávat žádným efektivním způsobem. Také si musíte být vědomi důsledků zálohy a zajistit, aby byl klíč zálohován, nejlépe odděleně na zálohy databáze, abyste zabránili dešifrování databáze v případě odcizení záložní pásky. A musíte se ujistit, že máte několik kopií klíče a pravidelně je testujte.

15
pipTheGeek

Dobrým konceptem společnosti SoA je mít kryptografickou službu, která je na vašem serveru izolovaná od ostatních procesů (vaše webová aplikace by měla být také izolovaná!). Poté, když potřebujete zašifrovat/dešifrovat objekt/pole, odešlete plaintext/crypttext do kryptologické služby a vrátíte se s crypttext/plaintext. Tímto způsobem, i když dojde ke kompromitaci vaší webové aplikace, útočník nemůže číst šifrovací klíč, protože klíč zná pouze šifrovací služba. Také proto, že je vaše webová aplikace izolovaná, je to, co může ve vašem systému udělat, omezeno. Izolace služby se obvykle provádí pomocí systému MAC, jako je SElinux, TOMOYO (mnohem snadnější použití než SElinux imo), AppArmor. Také bych doporučil provozovat nejnovější linuxové jádro s opravami.

6
Matrix

Krátká odpověď: Ano, používám symetrické šifrování. Tím se zabrání některým útokům, jako je čtení dat SQL prostřednictvím injekce sql. Pokud je však váš webapp napaden, nemusí na tom záležet. Pokud někdo získá dostatečný přístup k vašemu serveru, nemůžete nic dělat. I s asymetrickým šifrováním.

3
user5575