Zabezpečení databáze

Zabezpečení databáze
« kdy: 25. 09. 2020, 10:08:25 »
Hezký den.
Potřebuji nasdílet databázi kde mimo jiné bude i rodné číslo případně jiné citlivé údaje a teď řeším jak data zabezpečit.
Položky v databázi budou šifrované.
K databázi se bude přistupovat jak z klientských aplikací, které si budou data dešifrovat ale i z webového portálu.
A právě u webového portálu přemýšlím jak zabezpečit klíč pomocí kterého budou data dešifrována.
Přeci jen když by se někdo dostal na server může kromě databáze stáhnout i scripty, ve kterých najde potřebné...
Jak se toto řeší?
Děkuji


Re:Zabezpečení databáze
« Odpověď #1 kdy: 25. 09. 2020, 12:30:43 »
zni to jako peklo.

Ja bych se cestou sifrovaneho disku a v db nic nesifroval. Pokud klienti maji klic tak at se rovnou pripoji k nesifrovany db.
Pak ssl na spojeni client + db a nazdar.

Re:Zabezpečení databáze
« Odpověď #2 kdy: 25. 09. 2020, 12:42:27 »
Klíč mezi DB a webovým portálem je víceméně k ničemu, stejně jako šifrovat samotná data. Když dojde ke kompromitaci bezpečnosti, pak unikne klíč a ochrana je pryč. Zbytečná práce, prakticky bez přínosu.

V PostgreSQL bych to řešil pomocí row level security. Pomocí pravidel bych umožnil přístup jen konkrétnímu koncovému uživateli. Nicméně, je nepraktické (a nedělá se to), do databáze zakládat na každého uživatele webu jeho vlastního DB uživatele. Takže se to dá jedině řešit tak, že pomocí funkcí se security definer vytvoříte mechanismus, který Vám předá token á la OAuth. S ním pak může webová aplikace bezpečně pracovat a s každým požadavkem ho předávat.

Na získání dat pak musíte v rámci DB session nastavit správný token, a ten, když je nastavený, zpřístupní příslušné řádky a sloupce k získání dat. Bez nastaveného tokenu z tabulky řádky nedostanete.

Je to poměrně složité řešení, ale dá se.
Základem tedy je, aby uživatel, kterým se webová aplikace připojuje do DB, nemohl selectovat data nijak přímo. (Např. SELECT * FROM users navrátí nula řádků, dokud není předaný token).

Re:Zabezpečení databáze
« Odpověď #3 kdy: 25. 09. 2020, 13:20:57 »
Postgres aj Oracle umoznuju sifrovat hodnoty v stlcoch. Ja osobne by som volil inu metodu, citlive data by boli v tabulke ale uzivatel by nemal pristup na select do tabulky, ale len na view, ktore tento citlivy udaj neobsahuju.

Re:Zabezpečení databáze
« Odpověď #4 kdy: 25. 09. 2020, 13:24:06 »
Postgres aj Oracle umoznuju sifrovat hodnoty v stlcoch. Ja osobne by som volil inu metodu, citlive data by boli v tabulke ale uzivatel by nemal pristup na select do tabulky, ale len na view, ktore tento citlivy udaj neobsahuju.

View skryje jen sloupce, pokud jde i o řádky, musí se využít row level security, nebo filtrovat výsledky skrz funkci (tj. nedovolit SELECT FROM table, ale jen SELECT FROM function).


Re:Zabezpečení databáze
« Odpověď #5 kdy: 25. 09. 2020, 15:51:59 »
Co znamená, že klíč budou mít klientské aplikace? Bude aplikace nainstalovaná někde v počítači nebo mobilu uživatele, a ta v sobě bude mít klíč? To ani nemusíte webový portál nijak řešit, můžete ta data rovnou považovat za veřejná. Nebo „klientská aplikace“ bude nějaký aplikační server, ke kterému se teprve budou připojovat klienti? Pak je to srovnatelné, jako serverová aplikace webového portálu – v obou případech musíte řešit, aby ten klíč neunikl.

V první řadě bych řešil to, aby aplikace, která má k datům přistupovat, měla oprávnění (na úrovni DB uživatele) jenom k tabulkám a sloupcům, které má vidět. Čímž dostanete z hlediska aplikací stejné zabezpečení, jako když budete používat klíč (předpokládám, že jste chtěl používat jeden klíč pro všechna data).

Dále řešte to, aby se útočník nedostal do těch aplikací, které budou k databázi přistupovat. Tj. určitě nemohou být nainstalované na zařízení uživatele, musí to být server pod vaší správou. Tohle (ochrana proti SQl injection, útokům na server atd.) je ten nejdůležitější prvek zabezpečení, na ten se soustřeďte a neřešte hlouposti jako šifrování dat.

Další zabezpečení (třeba i před správci) by mohlo být šifrování na úrovni databáze nebo šifrování disku. Ale kdybyste potřeboval takovouhle úroveň zabezpečení, neptal byste se v diskusním fóru.

Re:Zabezpečení databáze
« Odpověď #6 kdy: 25. 09. 2020, 18:53:05 »
K databázi se bude přistupovat jak z klientských aplikací, které si budou data dešifrovat ale i z webového portálu.
A právě u webového portálu přemýšlím jak zabezpečit klíč pomocí kterého budou data dešifrována.
Přeci jen když by se někdo dostal na server může kromě databáze stáhnout i scripty, ve kterých najde potřebné...
Jak se toto řeší?
Tak jestli aspoň trochu řešíte bezpečnost, zapomeňte na architekturu "webserver leze přímo do databáze".
Obvykle se tohle řeší víceúrovňovou architekturou, kdy lidi zvenku mají přístup (přes LB/WAF) jen na webové frontendy, které pokud potřebují data, tak si přes nějaké API volají backendové aplikační servery, a teprve ty mají nějaký přístup do databází (případně a vlastně hlavně i k dalším interním systémům, typicky dělat web pro zákazníky který si nemůže hrábnout (opět přes API) třeba do CRM by nedávalo moc smysl).
Domyslete si mezi tím firewally, místy nastrkané IPS sondy případně za tím SIEM do kterého se sypou logy a jsme v podstatě na takovém korporátním standardu.

AoK

  • ***
  • 160
    • Zobrazit profil
Re:Zabezpečení databáze
« Odpověď #7 kdy: 25. 09. 2020, 20:43:08 »
prakticky to je dost široké téma bez zkušeností to stejně v nějaké ohledu zmotáš (nic proti), je lepší si ke spolupráci vzít někoho, kdo už něco takového dělá než se ptát na diskuzích.

Pokud jde o databázovou stranu, měl bys zajistit:
- znemožnit select všech údajů z tabulky najednou (jak psal Miroslav Šilhavý select from function je řešením)
- znemožnit iteraci jednotlivých řádků přes primární klíč (takový autoincrement ti dovolí zkoušet postupně všechny hodnoty), takže id generovat z velkého rozsahu a náhodně
- auditovat každý přístup pro čtení/zápis
- oddělit práva pro administraci, pro zápis a pro čtení

Tohle jsou všechno kroky, které vytvoří bariéru v případě, kdy se útočník dostane k tvé webové aplikaci a bude jí moci ovládat.

Připojovat databázi přímo do webých aplikací se již opravdu tolik nedoporučuje dělat z pohledu bezpečnosti. Vhodné je si udělat jednoduchou rest aplikaci, kterou ti základní operace s čtením a zápisem zajistí a webovou aplikaci opřeš o ní.

Šifrování disku je super, šifrování jednotlivých záznamů už tolik ne, stejně musí mít aplikace klíč, TLS/SSL je na to daleko vhodnější pro zabezpečení dat při přenosu.

Chce také myslet na legislativná stránku, práci s takovými údaji musíš zdokumentovat, musíš mít popsané, kdo k nim má přístup, jak se přístup kontroluje a ověřuje, kde jsou auditní logy.

Re:Zabezpečení databáze
« Odpověď #8 kdy: 25. 09. 2020, 22:21:19 »
K věci: Od klienta k serveru musí být vše šifrované (např. https) a uživatel musí být ověřovaný dvoufaktorově. Nastavit rozumný timeout session. Nasadit nějaké penetrační testování proti běžným chybám jako sql injection apod. Dvoufaktor použít i pro přihlášení do databáze, pokud to databáze umí a připojuje se do ní přímo z pc uživatelů (tím tedy nemyslím webovou aplikaci). Důležité operace opět vázat na ověření. Tím se dostanete na úroveň zabezpečení internet bankingu a víc nebudete myslím potřebovat. Samozřejmě zabezpečit i server proti průniku zvenčí (to však není předmětem dotazu). Pokud na tom záleží, nechat si vše zkontrolovat nezávislou stranou (bezpečnostní audit) a zhodnotit, jaká škody by vznikly v různých scénářích. A na nějaké vlastní šifrování a dešifrování v aplikaci rovnou zapomeňte, to řeší šifrované kanály za vás.

Bokem: Další vrstva navíc v principu nic neřeší, potřebujete kontrolovat rizika a kvalitu, nikoli kvantitu.

PS: Jo a aby si data uživatelé nevykradli vzájemně, tak na to nasadit samozřejmě to row level security (nemám ale zkušenost).
« Poslední změna: 25. 09. 2020, 22:24:24 od Ondrej Nemecek »

AoK

  • ***
  • 160
    • Zobrazit profil
Re:Zabezpečení databáze
« Odpověď #9 kdy: 26. 09. 2020, 10:05:12 »
K věci: Od klienta k serveru musí být vše šifrované (např. https) a uživatel musí být ověřovaný dvoufaktorově. Nastavit rozumný timeout session. Nasadit nějaké penetrační testování proti běžným chybám jako sql injection apod. Dvoufaktor použít i pro přihlášení do databáze, pokud to databáze umí a připojuje se do ní přímo z pc uživatelů (tím tedy nemyslím webovou aplikaci). Důležité operace opět vázat na ověření. Tím se dostanete na úroveň zabezpečení internet bankingu a víc nebudete myslím potřebovat. Samozřejmě zabezpečit i server proti průniku zvenčí (to však není předmětem dotazu). Pokud na tom záleží, nechat si vše zkontrolovat nezávislou stranou (bezpečnostní audit) a zhodnotit, jaká škody by vznikly v různých scénářích. A na nějaké vlastní šifrování a dešifrování v aplikaci rovnou zapomeňte, to řeší šifrované kanály za vás.

Bokem: Další vrstva navíc v principu nic neřeší, potřebujete kontrolovat rizika a kvalitu, nikoli kvantitu.

PS: Jo a aby si data uživatelé nevykradli vzájemně, tak na to nasadit samozřejmě to row level security (nemám ale zkušenost).

Byl bych opatrný s tvrzením, že nasazení 2FA a https se dostane na úroveň online bankingu, to řeší bezpečnost proti útoků na uživatele, neřeší to ale bezpečnost tvého systému, tam zabezpečení stojí na několika pilířích v podobě procesu pro řízení rizik (vč. držení aktualizační politiky), SIEM jako realtime monitoringu, automatizovaných testů a code stylu (třeba v podobě owasp, spring). Až pod tím jsou běžné věci, které známe jako programátoři

Re:Zabezpečení databáze
« Odpověď #10 kdy: 26. 09. 2020, 13:29:08 »
Nasadit nějaké penetrační testování proti běžným chybám jako sql injection apod.
ehm, to nebude pentest (neboli posadím partu zkušených maníků co se tam pokusí dostat), ale spíš vulnerability scan (pustím nějaký automatizovaný tool který se pokusí najít známá chyby a zranitelnosti).

Citace
Tím se dostanete na úroveň zabezpečení internet bankingu a víc nebudete myslím potřebovat.
To by Vás ČNB hnala opřít bezpečnost bankovnictví o bezpečnost databáze.

Citace
Bokem: Další vrstva navíc v principu nic neřeší, potřebujete kontrolovat rizika a kvalitu, nikoli kvantitu.
Bokem. termín SPOF se dá použít i v bezpečnosti.
Kladl bych si otázku: Co když se někomu na webserveru podaří spustit kód (nemusíte dostat roota, stačí práva toho webu). Pak můžete využít autentizaci kohokoli a dělat pod ní v databázi cokoli. I když máte dobře nastavený přístup k jednotlivým fieldům, bude veškerá logika na tom (teď kompromitovaném) frontend serveru? Pak bych v internetovém bankovnictví v klidu mohl dostat peníze a přitom je neodečíst z účtu, což nechceme.

Ona ta vrstva navíc něco opravdu řeší - to co chodí z browserů je docela bordel, zatímco pár restových API pod tím je (obvykle) stabilních, takže se dá daleko snadněji ošetřovat. Když WAF na vstupu zachytí chybný dotaz, obvykle to zablokuje a logne nezi další tisíce podobných, on už si to siem přebere. Když detekujete chybný parametr v API callu, můžete rovnou poslat tiket na SoC s dost malou šancí na false positive.
Udělat tohle přímo na úrovni databáze (a nezavlést tam víc chyb než kolik to ošetří) nevím nevím.

Ale jak píšete, není to triviální, a začal bych prvně definováním funkcionality, sepsáním rizik (a to kompletně - každý sice řeší důvěrnost dat, ale je potřeba nezapomínat na integritu a dostupnost) a pak teprve bych volil konkrétní architekturu.

_Jenda

  • ****
  • 476
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Zabezpečení databáze
« Odpověď #11 kdy: 26. 09. 2020, 13:36:01 »
Bez urážky (každý rozumí něčemu jinému, já taky musím spoustu věcí konzultovat, nebo rovnou nechávat dělat někoho jiného), ale pokud to fakt chcete použít na cokoli vážnějšího než stránky místního spolku zahrádkářů, tak si na to fakt někoho najděte, protože tomu nerozumíte a podle internetové diskuze to fakt nedáte tak aby z toho za chvíli nebyl průser.

Re:Zabezpečení databáze
« Odpověď #12 kdy: 26. 09. 2020, 13:58:06 »
"K databázi se bude přistupovat jak z klientských aplikací"

Vyloučeno
Databáze nemá být vůbec vidět z venku. Vůbec nevíte, jaké exploity databáze obsahuje a při problému ani nedohledáte, co se stalo.

Na komunikaci s databází udělejte meziprogram s API pro klienty, kde vy přesně určíte, jaká data půjdou k nim a od nich. Na webu je to z hlediska vývoje komplikovanější. Pokud se tam často mění hodně věcí, tak se to většinou neřeší přes API, ale minimálně je dobré použít nějaký framework (pokud jde o php). To už je otázka času/peněz. A stejně předpokládejte, že ten webserver někdo někdy hackne(nutné předpokládat, že webservery sami o sobě mají zranitelnosti), takže když nebude mít login do databáze, nezpůsobí nic. Tedy za předpokladu, že máte všude jiná hesla/klíče a webserver není na lokální síti s databází.
« Poslední změna: 26. 09. 2020, 14:00:49 od kotelgg »

Re:Zabezpečení databáze
« Odpověď #13 kdy: 26. 09. 2020, 22:52:01 »
"K databázi se bude přistupovat jak z klientských aplikací"

Vyloučeno
Databáze nemá být vůbec vidět z venku. Vůbec nevíte, jaké exploity databáze obsahuje a při problému ani nedohledáte, co se stalo.

Já jen že pokud je ten mezikus napsaný blbě nebo blbě nasazaný, pak tu bezpečnost může klidně snížit. Pokud v něm máte chybu a spoléháte na něj, máte de fakto o průnik postaráno. Je to jen můj názor...

Je jasný, že je to složité a neznáme situaci tazatele, ani reálné požadavky na bezpečnost. Podle dotazu to bude něco spíchnuté na koleně, kde potřeba řešit nejspíš ty nejzákladnější základy jako třeba netriviální hesla, aby data nelítala v plaintextu. V téhle situaci je IMHO nesmysl řešit vícevrstvou aplikaci, to je sci-fi.

Ohledně přímého přístupu do databáze z aplikace zase záleží na situaci. To je jako říct že nemám spouštět http server protože obsahuje exploity.

Re:Zabezpečení databáze
« Odpověď #14 kdy: 27. 09. 2020, 01:57:29 »
Děkuji všem za příspěvky.
V reakci na "Je jasný, že je to složité a neznáme situaci tazatele, ani reálné požadavky na bezpečnost. Podle dotazu to bude něco spíchnuté na koleně" z posledního příspěvku... Zatím není spíchnuto nic.
Má jít o možnost objednat se k lékaři.
Ti využívají svůj SW instalovaný na jejich PC a dotaz byl inciován požadavkem na objednávání přes web.
Potud jejich zadání.
Idea je taková, že by si SW instalovaný na PC lékaře synchronizoval data z jejich objednacího kalendáře s databázi web serveru a tuto databázi by využívala i webová aplikace (stránky) umožňující objednávání pacientů.
Dotaz na zabezpečení byl motivován tím, že se v databázi objeví rodné číslo, jméno i příjmení, login, heslo apod. Ano, dá se to pojmout i jinak ale i tak by se v databázi asi minimálně objevil email pro možnost ověření objednávky (pokud bych neřešil možnost logování uživatelů). Takže nebudou tam žádná supertajná data ale rodné číslo, příjmení a jméno takto pohromadě už je dost citlivá informace.
Takže když když to shrnu jsem na začátku a přemýšlím jak tu "webovou" část pojmout protože v tomto opravdu kovaný nejsem...