Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pavel Janata 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
-
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.
-
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).
-
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.
-
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).
-
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.
-
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.
-
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.
-
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).
-
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
-
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).
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.
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.
-
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.
-
"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í.
-
"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.
-
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...
-
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...
Tak tady to moc složitě udělat nepůjde, co takhle jak už sám naznačujete omezit množství citlivých dat, které v DB na tom webu budou? Jediné co na tohle opravdu potřebujete je (pro existující pacienty) nějaký jednoznačný identifikátor pacienta, což by v klidu mohl být email (stejně ho potřebujete na potvrzení apod.) a nějaké autentizační údaje, pokud chcete i objednávku nových pacientů, tak tam to asi pár dalších údajů budete potřebovat, ale jen na chvíli než se syncnou s databází co má lékař u sebe. A pokud chcete být hodně paranoidní, tak i místo emailu klidně ukládejte jen jeho hash, stejně ho pokaždé při přihlášení uživatel vyťuká tak si ho můžete dát do session. Pak už máte na webu pro útočníka dostupný jen kalendář (který je veřejný) s nepoužitelnými údaji.
(pacient se může odhlásit v klidu i tak, pokud lékař něco bude rušit tak to asi udělá z jeho systému kde ten mail má v cleartextu...)
Pro tohle předpokládám že skutečnou DB s údaji pacientů má lékař někde v bezpečí ordinace a do té webové by se přenášelo opravdu jen to co je nezbytně nutné.
(do jiného modelu, zejména web hrabe přímo do DB s ostrými daty se radši opravdu nepouštějte, aspoň teda jestli nechcete aby se o Vás psalo v seriálu Bezpečnost dat ve zdravotnictví.)
-
jednoznačný identifikátor pacienta, což by v klidu mohl být email (stejně ho potřebujete na potvrzení apod.)
To není dobrý nápad v takto citlivém oboru:
- identifikátor by byl společný pro stejného pacienta u více lékařů (a priori pak nemůžete data oddělit)
- je mezi námi spousta lidí, kteří používají e-mail sdílený s dalšími osobami (firemní, rodinné, ...)
- svádí to pak k resetu hesla e-mailem, který jde nezabezpečeně - tj. kompletně tím zboříte všechna ostatní zabezpečení
Pro tohle předpokládám že skutečnou DB s údaji pacientů má lékař někde v bezpečí ordinace a do té webové by se přenášelo opravdu jen to co je nezbytně nutné.
(do jiného modelu, zejména web hrabe přímo do DB s ostrými daty se radši opravdu nepouštějte, aspoň teda jestli nechcete aby se o Vás psalo v seriálu Bezpečnost dat ve zdravotnictví.)
Toto je samozřejmé, že se nemá přenášet víc dat, než je nezbytné.
Nicméně je potřeba udělat další opatření:
- aby si klient nemohl víc dat ani vyžádat
- aby aplikační server z databáze nemohl získat data jiného lékaře
- a nejlépe, aby taková data SQL server vůbec neposkytl (protože když dojde ke kompromitaci aplikačního serveru, nesmí se data dostat ven)
-
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...
V tom případě je řešení poměrně jasné. Žádná aplikace (ani web, ani aplikace lékařů) nebude v žádném případě přímo přistupovat do databáze. Do databáze bude přistupovat jen aplikační server, který vystaví API – a to API bude používat jak lékařský software, tak web.
Jméno, příjmení a rodné číslo pohromadě nejsou dost citlivé informace – tuhle kombinaci údajů ví o každém desítky subjektů, v případě živnostníků je to například veřejně na webu. Ne že byste ty údaje neměli chránit, ale nic citlivého to není.
-
Jméno, příjmení a rodné číslo pohromadě nejsou dost citlivé informace – tuhle kombinaci údajů ví o každém desítky subjektů, v případě živnostníků je to například veřejně na webu. Ne že byste ty údaje neměli chránit, ale nic citlivého to není.
Bacha, v kombinaci s tím jakého a nebo i kdy osoba lékaře navštěvuje, je to už velmi citlivá informace. Podle mě nemůžete uvažovat, že každý navštěvuje lékaře. Může nastat víc choulostivých informací, které mohou značně narušit soukromí: např. léčba určité diagnózy (onkologie, dialýza, psychologie, psychiatrie, neurologické problémy, ...). Asi jako snad trochu méně citlivé bych viděl navštěvování praktika.
-
databázi opravdu neotevírej ven do internetu a nepřistupuj z ní odjinud než z interních systémů a uzavřeného síťového prostředí (ideálně mít na localhostu u databáze přímo to api). Žádná z mainstream databází nemá dobře vyřešené zabezpečení, tak aby se mohla vystavit ven, to je stejné jako když ty data bude zveřejňovat.
Mít vlastní api (či aplikační rozhranní) u databáze je nutnost, jinak současný svět nefunguje. Jinak podlé tvé odpovědi nevypadá, že na to jdeš dobře a vem si na pomoc i někoho jiného, v případě úniku dat se zodpovědnost může na tebe přenést.
-
Do databáze bude přistupovat jen aplikační server, který vystaví API – a to API bude používat jak lékařský software, tak web.
Jenže tady musíte vysvětlit, co je aplikační server, kde běží a jak vznikne ta bezpečnost.
Nejspíš myslíte, že lékařský software bude sám skrz API nahrávat údaje na aplikační server (takže aplikační server nebude znát žádné přístupové údaje do lékařského software, naopak se bude muset samotný lékařský software autorizovat při přístupu do toho API). Bezpečnost vznikne tím, že když někdo získá plný přístup k aplikačnímu serveru, nezíská tím data lékařského software.
Zde opravdu není dobrý nápad přistupovat do živé databáze, kterou současně používá lékařský software. Jsou tam obvykle různé cache, takže se snadno dostanete do stavu, že by externí systém viděl neaktuální nebo nekonzistentní data a kdyby náhodou ten externí systém začal do té živé databáze zapisovat, mohl by lékařský software spadnout a data by se mohla rozbít. Aby šla takto databáze použít, muselo by to na to být navržené.
Nejrozumnější je kontaktovat výrobce lékařského software s dotazem, jaké nabízejí možnosti pro integraci s externími systémy. Pokud to mají dobře navržené, tak Vás odpověď i navede na správné řešení. Teprve pokud na tuto variantu nebudou připraveni, lze řešit integraci vlastní cestou. Třeba dávkovým přenosem v read-only režimu načíst údaje z lékařského software (v době kdy neběží) a tímto exportem aktualizovat data na webu. Na to byste musel vyvinou nějaký nástroj. Ať ale neběží na serveru, ale spouští se na počítači v ordinaci. Tím docílíte cca toho stavu, co psal pan Jirsák výše. Je otázka, co se s tím objednáním pacienta pak stane. Pokud se to má přenášet zpět do lékařského software, tak se nejspíš nevyhnete tomu aplikačnímu serveru a v lékařském software pro to musí být nějaká podpora. Do databáze to přímo nezapisujte, pokud to dodavatel lékařského software přímo nepodporuje - koledoval byste si o malér.
Z hlediska osobních údajů by bylo nejlepší do databáze na serveru zapisovat opravdu jen např. (osolené) hashe mailu. Když by se k údajům ze server někdo dostal, dozví se pouze kolik je kdy objednaných pacientů ale nedokáže je ztotožnit s osobami. Teoreticky - pokud se např. někdo dostane i k logům serveru a v nich budou ty maily uvedeny (může se stát), tak ke ztotožnit může dojít celkem snadno.
-
Jenže tady musíte vysvětlit, co je aplikační server, kde běží a jak vznikne ta bezpečnost.
Nejspíš myslíte, že lékařský software bude sám skrz API nahrávat údaje na aplikační server (takže aplikační server nebude znát žádné přístupové údaje do lékařského software, naopak se bude muset samotný lékařský software autorizovat při přístupu do toho API). Bezpečnost vznikne tím, že když někdo získá plný přístup k aplikačnímu serveru, nezíská tím data lékařského software.
Zde opravdu není dobrý nápad přistupovat do živé databáze, kterou současně používá lékařský software. Jsou tam obvykle různé cache, takže se snadno dostanete do stavu, že by externí systém viděl neaktuální nebo nekonzistentní data a kdyby náhodou ten externí systém začal do té živé databáze zapisovat, mohl by lékařský software spadnout a data by se mohla rozbít. Aby šla takto databáze použít, muselo by to na to být navržené.
Nejrozumnější je kontaktovat výrobce lékařského software s dotazem, jaké nabízejí možnosti pro integraci s externími systémy. Pokud to mají dobře navržené, tak Vás odpověď i navede na správné řešení. Teprve pokud na tuto variantu nebudou připraveni, lze řešit integraci vlastní cestou. Třeba dávkovým přenosem v read-only režimu načíst údaje z lékařského software (v době kdy neběží) a tímto exportem aktualizovat data na webu. Na to byste musel vyvinou nějaký nástroj. Ať ale neběží na serveru, ale spouští se na počítači v ordinaci. Tím docílíte cca toho stavu, co psal pan Jirsák výše. Je otázka, co se s tím objednáním pacienta pak stane. Pokud se to má přenášet zpět do lékařského software, tak se nejspíš nevyhnete tomu aplikačnímu serveru a v lékařském software pro to musí být nějaká podpora. Do databáze to přímo nezapisujte, pokud to dodavatel lékařského software přímo nepodporuje - koledoval byste si o malér.
Z hlediska osobních údajů by bylo nejlepší do databáze na serveru zapisovat opravdu jen např. (osolené) hashe mailu. Když by se k údajům ze server někdo dostal, dozví se pouze kolik je kdy objednaných pacientů ale nedokáže je ztotožnit s osobami. Teoreticky - pokud se např. někdo dostane i k logům serveru a v nich budou ty maily uvedeny (může se stát), tak ke ztotožnit může dojít celkem snadno.
Píše se o databázi (jedné) a klientský aplikacích (několika) a webovém portálu. Předpokládám tedy, že idea je taková, že vznikne jedna nová databáze pro objednávání, přičemž s touto databází budou moci pracovat i lékařské aplikace. Je tedy potřeba vyřešit nejen to, aby se jeden pacient nedostal k údajům jiného pacienta, ale také aby se lékař dostal pouze k údajům svých pacientů.
Aby tohle mohlo fungovat,nelze se spoléhat na to, že dáte lékaři do počítače plný přístup k databázi, jenom mu ho schováte do aplikace, která (bude-li fungovat správně) mu poskytne pouze údaje o jeho pacientech. Ta bezpečnost tedy vznikne tím, že logika rozhodující o tom, kdo má k čemu přístup, se odstraní z dosahu lékařů a přesune se na aplikační server, který spravuje někdo důvěryhodný.
Pro objednávání pacientů není žádný přístup do databáze lékaře potřeba. Jediné, co je potřeba znát ze strany lékaře, jsou volné sloty v jeho kalendáři. Žádné „předvyplňování“ údajů z databáze lékaře není možné použít, protože nevíte, zda pacient, který se k lékaři objednává, je skutečně tím, za koho se vydává. Takže své nacionále, adresu, pojišťovnu i lékaře, ke kterému se objednává, musí pacient vyplnit sám.
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...
Webová část je triviální portál – uživatel se přihlásí a po přihlášení vidí jenom svoje údaje. To má každý e-shop, má to diskusní fórum tady na Rootu. Jediný rozdíl je v tom, že v té databázi bude, ke komu se pacient objednává – to je citlivější údaj, než jsou v uživatelském profilu tady na diskusním fóru, je to citlivostí zhruba srovnatelné s objednávkami na e-shopech.
Přemýšlet je potřeba nad tou částí, jak dostat objednávky lékaře do jeho softwaru – nemůžete mu předat všechna objednávky i k ostatním lékařům.
Bacha, v kombinaci s tím jakého a nebo i kdy osoba lékaře navštěvuje, je to už velmi citlivá informace.
No, napsal jste to sice trochu zmateně, ale to, jakého někdo navštěvuje lékaře, je citlivější informace, než rodné číslo. Takže když chce někdo argumentovat tím, jak citlivé údaje v databázi budou, je logické uvádět ty nejcitlivější údaje, což je především to, ke komu (případně i kdy) se pacient objednává.
-
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...
Webová část je triviální portál – uživatel se přihlásí a po přihlášení vidí jenom svoje údaje. To má každý e-shop, má to diskusní fórum tady na Rootu. Jediný rozdíl je v tom, že v té databázi bude, ke komu se pacient objednává – to je citlivější údaj, než jsou v uživatelském profilu tady na diskusním fóru, je to citlivostí zhruba srovnatelné s objednávkami na e-shopech.
Přemýšlet je potřeba nad tou částí, jak dostat objednávky lékaře do jeho softwaru – nemůžete mu předat všechna objednávky i k ostatním lékařům.
Rozdíly jsou v tom, do jaké hloubky zabezpečení uděláte. Triviálně se to dělá jen v aplikaci e-shopu (na straně serveru). Nevýhodou takového řešení je, že pokud v důsledku chyby může útočník získat přístup k datům, která mu nepatří. Proto se za aplikační server staví ještě backend s API a za API může být i zabezpečení v rámci databáze. Z mého pohledu je každopádně smysluplnější udělat zabezpečení na databázi (row level security, přístup k datům přes funkce při znalosti jednorázového tokenu) a raději vynechat backend API, pokud by to za sebou zabezpečení databáze nemělo.
Tradiční levely zabezpečení jsou (seřazeno podle lenosti se tím zabývat):
a) bez API, bez zabezpečení DB, bezpečnost "vypočítává" aplikace
b) vložené API, ověření uživatele HTTP na server, druhotné ověření server-API
c) vložené API, OAuth (nebo podobný princip), uživatel ověřený až na API
d) dtto + token má platnost až na data v DB
Tazatel se musí rozhodnout, do jakého "levelu" dokáže dojít; citlivé informace tohoto rázu si podle mě zaslouží dobré zabezpečení, ale přiznejme si, že ne vždy to tak bývá. Taková aplikace je násobně dražší na vývoj i údržbu, než když to provedete nejjednodušším způsobem.
No, napsal jste to sice trochu zmateně, ale to, jakého někdo navštěvuje lékaře, je citlivější informace, než rodné číslo. Takže když chce někdo argumentovat tím, jak citlivé údaje v databázi budou, je logické uvádět ty nejcitlivější údaje, což je především to, ke komu (případně i kdy) se pacient objednává.
No, napsal jsem to na hranici pochopitelnosti. Špatné ráno, no :).
Ve své nahotě se ukazuje, jak píšete, že lidi vůbec nechápou ochranu informací. Skoro každý si myslí, že (citlivou) informací jsou jen ukládaná data. Zrovna tento případ ukazuje, že daleko citlivější, než samotná data, jsou informace o tom jakého a kdy navštěvuje lékaře.
Přesto bych rodné číslo taky chránil. Postupně se z něj stává hodně exkluzivní informace, mizí i z občanek. Podobně citlivý je v ČR tradičně i triplet jméno-datum narození-místo narození, který se vedle rodného čísla často užívá k identifikaci osoby.
-
Tazatel se musí rozhodnout, do jakého "levelu" dokáže dojít
Nikoli. Vy řešíte, jestli má tazatel raději postavit raketoplán nebo raketu s návratovým modulem. Tazatel má přitom problém sestrojit koloběžku.
První věc, kterou si musí tazatel uvědomit, je to, že přístup k datům se nechrání tak, že je zašifruju, ale pak stejně všem rozdám přístupové klíče. Data se chrání tak, že se každý, kdo k nim má mít přístup, musí nejprve věrohodně autentizovat, a pak mu server (který není v moci uživatele) poskytne přístup jenom k těm datům, ke kterým má mít přístup. Takže není možné, aby lékařský software měl přístup k celé databázi a z ní si mohl přečíst libovolná data.
Řešení přímo na úrovni databáze pomocí row-level security a dvoufaktorové autentizace vůči databázi je sice hezká věc, ale v kontextu tazatelova dotazu je to sci-fi.
Přesto bych rodné číslo taky chránil. Postupně se z něj stává hodně exkluzivní informace, mizí i z občanek. Podobně citlivý je v ČR tradičně i triplet jméno-datum narození-místo narození, který se vedle rodného čísla často užívá k identifikaci osoby.
Jistěže je potřeba rodné číslo chránit, úplně stejně, jako jméno nebo e-mail. Exkluzivní informace se z něj ale v žádném případě nestává, ve všech databázích v soukromé sféře, kde je dnes, bude i nadále. Občanky jsou jediné místo, odkud rodné číslo možná zmizí – Ministerstvo vnitra by se totiž rádo rodných čísel zbavilo (akorát je nechce nahradit dávno používanými bezvýznamovými identifikátory, protože nejsou z jeho resortu), akorát že místo nich nenabídlo soukromé sféře žádnou náhradu.
-
@Filip Jirsák
Souhlas.
Vidím, že tazatel se vrhl do oboru, kde jsou informace opravdu velmi citlivé. Pokud se nechce začíslit do řad basličů, nemá na výběr. Musí postavit raketoplán, nebo raketu s návratovým modulem. Ale myslím, že je dobře, že se zeptal a že dostal dost obecných, ale i konkrétních rad, jak se to řeší.
(Jiná otázka, mimo téma, samozřejmě je, jestli jako každý na začátku nemyslel, že náklady na takový vývoj nebudou desetkrát menší, než co tu bylo popsáno.)
-
Vidím, že tazatel se vrhl do oboru, kde jsou informace opravdu velmi citlivé. Pokud se nechce začíslit do řad basličů, nemá na výběr. Musí postavit raketoplán, nebo raketu s návratovým modulem. Ale myslím, že je dobře, že se zeptal a že dostal dost obecných, ale i konkrétních rad, jak se to řeší.
(Jiná otázka, mimo téma, samozřejmě je, jestli jako každý na začátku nemyslel, že náklady na takový vývoj nebudou desetkrát menší, než co tu bylo popsáno.)
V medicíně samozřejmě jsou velmi citlivé informace, ale zrovna objednávání k lékaři není ten případ. Stejně citlivý může být obsah nákupního košíku s drogerií v e-shopu.
Funkčně je to jednoduchý objednávkový formulář. Jediná věc, která asi na začátku Pavla Janatu zmátla, je to, že to chtěl řešit ze strany toho lékařského softwaru, zatímco jediné použitelné řešení je udělat ten jednoduchý objednávkový systém pro web, z něj pak vystavit potřebné API pro lékařský software a přes to ho napojit. Napojovat něco z internetu přímo na lékařský software by byla sebevražda, určitě není na nic takového stavěný.
-
V medicíně samozřejmě jsou velmi citlivé informace, ale zrovna objednávání k lékaři není ten případ. Stejně citlivý může být obsah nákupního košíku s drogerií v e-shopu.
Dovolím si nesouhlasit. V drogerii objednávám za celou rodinu (nevíte už tak přesně, co kdo využívá), a taky mohu objednávat anonymně (pseudonymně). U lékaře je ta informace velmi přesná. V drogerii kupuji to, co spooousta dalších lidí. Na onkologii se neskončí (zaplaťpánbu) tolik lidí, co si kupuje pastu na zuby, prezervativy a vložky.
-
Asi se shodneme , že záleží co je to ten tajemný "lékařský software". To může být totiž prakticky cokoliv, od malého prográmku který běží iozovaně na pc v ordinaci až po raketetoplán běžící na centrále, který má už objednávání přes web vyřešeno.
-
Dovolím si nesouhlasit. V drogerii objednávám za celou rodinu (nevíte už tak přesně, co kdo využívá), a taky mohu objednávat anonymně (pseudonymně). U lékaře je ta informace velmi přesná. V drogerii kupuji to, co spooousta dalších lidí. Na onkologii se neskončí (zaplaťpánbu) tolik lidí, co si kupuje pastu na zuby, prezervativy a vložky.
To, že někdy nevíte přesně, pro koho z rodiny je která věc určená, neznamená, že by zveřejnění takových informací bylo v pohodě. Třeba při nákupu v obchodu s věcmi pro nastávající maminky a děti je asi jasné, kdo z páru je těhotný. Nákupy v sex-shopu budou asi citlivější, než většina objednávek k lékařům.
-
Dovolím si nesouhlasit. V drogerii objednávám za celou rodinu (nevíte už tak přesně, co kdo využívá), a taky mohu objednávat anonymně (pseudonymně). U lékaře je ta informace velmi přesná. V drogerii kupuji to, co spooousta dalších lidí. Na onkologii se neskončí (zaplaťpánbu) tolik lidí, co si kupuje pastu na zuby, prezervativy a vložky.
To, že někdy nevíte přesně, pro koho z rodiny je která věc určená, neznamená, že by zveřejnění takových informací bylo v pohodě. Třeba při nákupu v obchodu s věcmi pro nastávající maminky a děti je asi jasné, kdo z páru je těhotný. Nákupy v sex-shopu budou asi citlivější, než většina objednávek k lékařům.
Jasné, porovnávat míru zásahu do soukromí - to už jsme na půdě subjektivního vnímání, nebudu se o to přít.
Je možná dodám, že ani v drogerii, ani v sex shopu si nemusím rezervovat termín a nemají mě nikde zaneseného (pokud se dobrovolně nepřihlásím do nějakého členství). U lékaře se záznamu v kalendáři prakticky nevyhnete, a ten záznam tam být musí i když se objednám telefonicky. Jinak by webová aplikace nevěděla, kdy je volno.
-
Odpíchl bych se od standardu, který existuje
https://en.wikipedia.org/wiki/Health_Level_7
Jinak ideální řešení opravdu je mít nějakou DB do které přistupuje middleware (generující SOAP nebo JSON) a ten ještě zakrytý nějakým aplikačním firewallem.
-
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.
Zvážil bych, zda některé položky přístupné z webu by neměly být write-only, minimálně pro některé role.
Dá se nejspíše odhadnout, že běžný uživatel si nebude k vám na portál vyčítat své RČ. Není tedy důvod, aby se mu celé(?) zobrazovalo a měl k němu přístup.