Je k něčemu šifrování dat v tabulkách v databázi, pomůže to?

Ahoj,

spravuji web, kde jsou data uživatelů, které by klient rád zašifroval. Je to klasická kombinace PHP + MySQL. Můžeme mi prosím poradit, zda je to dnes opravdu praxe, že se data v tabulce DB opravdu šifrují, že se třeba ze jména a příjmení nebo z rodného čísla stane nějaký šifrovaný/hashovaný řetězec? Má to vůbec cenu dělat, nebo je důležitější se spíš soustředit na zabezpečení webu a čtení z databáze?

Protože moje úvaha je taková, že dostat do MySQL třeba skrze PHPmyAdmin je možné pouze, když útočník odcizí jméno a heslo k přihlášení. Ale pokud se mi nějak nabourá do webu, stejně pak získá i metodiku šifrování a i zašifrovanou databázi pak snadno prolomí.

Děkuji za rady, jak se k tomu postavit.

Proto se šifruje jinde a do DB se posílají už zašifrovaná data, třeba pomocí Halite. Ale aby na tohle mohl někdo kvalifikovaně odpovědět a navrhnout řešení, je potřeba si ujasnit, jaká rizika se teda řeší. Jaká data se budou šifrovat? Před kým se mají chránit a jaké způsoby útoků se mají brát v potaz? Umím si představit, že to šifrování dat může nařídit i nějaká legislativa. Běžně se ale třeba řeší bezpečnost právě cestou kterou popisuješ. Na základě zabezpečení webu a spojení do DB. Zákaz remote přístupů, ověřování na základě IP a VPN, atd.

Při nějaké sql injection, kdy se útočník dostane k možnosti selectů to může být platné - zvažoval bych to u nějakých top secret dat.

Ale apriori by zabezpečení mělo být o úrovně výše, zabránění útokům (třeba právě sql injection) dobře napsaným kodem - základní předpoklad. Blokace podezřelých requestů na serveru - pojistka. No a další stupeň třeba toto... Důsledky na performance, debugy atd... asi netřeba zmiňovat :D.

U jednoho svého projektu jsem to dělal, ale tam byla situace taková, že dešifrování dat neprobíhalo na serveru, ale na klientu - jeho klíč pak neopouštěl vůbec jeho stroj.

Těžko říct, neznáme podrobnosti, míru rizika, důležitost údajů, jejich rozsah.

Mohu říct, že se to dělá, ale také že se to nedělá.

Velké firmy začínají nasazovat šifrování uživatelský dat, kdy existuje speciální uložiště pro klíče a pro každého uživatele je jiný unikátní klíč. Před čtením si nejprve takový klíč musíš vyžádat a poté data přečíst. Důvody proč se to takhle dělá jsou hlavně dva:
- chci se bránit možnosti, aby se data dala odcizit hromadně, phpMyAdmin a přečtení celé tabulky je zřejmé, ale co třeba únik z sql dumpů nebo transakční logů databáze? Co když aplikace udělá chybu a zveřejní více dat než by měla?
- chci mít kontrolu na jediném místě, kdo, kdy a co za osobní data čte. V rozsáhlých infrastrukturách (jako třeba u telefonních operátorů) je občas problém posbírat auditní logy a sledovat, jestli někdo náhodou nečte víc než by měl (únik osobních dat od T-mobilu před pár lety je toho důkazem), mít naopak nasazený IPS jen na kms server, který vydává šifrovací klíče je velice jednoduché, mohu pak sledovat dotazovací patterny, mít limity na počty volání pro určité aplikace a celkově nad tím mít kontrolu aniž bych musel přepisovat celý ekosystém.

U malých klientů ale raději doporučuji šifrovat celou databázi, resp. disk, na kterém je a na kterém jsou logy. Implementovat šifrování atributů není snadné a potřebuji k tomu bezpečné a rychlé uložiště pro klíče, což by měla být jiná databáze. Mít jeden klíč pro všechno je spíše zbytečné.

Občas se takhle šifrují data na straně aplikace, pokud používám různé databáze u různých poskytovatelů a nemám k nim z principu důvěru, tak ano, je pak možné šifrovat jednotlivé hodnoty, ale pak s tím databázi degraduji na prosté uložiště hodnot, ztratím možnost filtrování, vyhledávání a agregace.

Šifruji rád a šifruji hodně, ale tady mi to spíše připadá nesystémové opatření, které reálně bezpečnost nezvedne. Třeba se pletu, popiš více tvůj use case, důvody co tě k tomu vedou, viz otázky z předchozích příspěvků.