Zabezpečení databáze

[jouda2]

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í.)

[Reklama]

[Miroslav Šilhavý]

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)

[Filip Jirsák]

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í.

[Miroslav Šilhavý]

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.

[_Tomáš_]

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.

[Reklama]

[Ondrej Nemecek]

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.

[Filip Jirsák]

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á.

[Miroslav Šilhavý]

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.

[Filip Jirsák]

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.

[Miroslav Šilhavý]

@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.)

[Filip Jirsák]

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ý.

[Miroslav Šilhavý]

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.

[Ondrej Nemecek]

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.

[Filip Jirsák]

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.

[Miroslav Šilhavý]

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.