Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 110 111 [112] 113 114 ... 375
1666
Server / Re:Zabezpečení databáze
« kdy: 29. 09. 2020, 09:01:44 »
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.

1667
Server / Re:Zabezpečení databáze
« kdy: 28. 09. 2020, 23:01:43 »
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ý.

1668
Server / Re:Zabezpečení databáze
« kdy: 28. 09. 2020, 11:19:28 »
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.

1669
Server / Re:Zabezpečení databáze
« kdy: 27. 09. 2020, 21:55:56 »
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á.

1670
Server / Re:Zabezpečení databáze
« kdy: 27. 09. 2020, 08:47:50 »
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í.

1671
Server / Re:Zabezpečení databáze
« 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.

1672
Server / Re:Segmentation fault: Samba spadne po 35 minutách
« kdy: 22. 09. 2020, 08:05:07 »
Zkusil bych otestovat hardware, zejména RAM, zda není vadná. Pokud by to byla chyby v softwaru, je divné, že byste se s ní setkal jenom vy. Předpokládám tedy, že jste se díval do release notes novějších verzí, že tam ta vaše chyba není opravená.

1673
To se čílíte kvůli tomu neaktuálnímu browseru??? Nerozumím tedy poznámce. Zrovna ten notebook je čistý, žádné špeky tam nejsou - jen chromium a ublock.
Spíš bych řekl, že panu Šilhavému –stejně jako mně – vadí to, že tu vlastní hloupostí marníte čas lidí ochotných pomoci. Používáte sto let starý prohlížeč a nenapíšete to. Píšete, že používáte Chrome, pak z vás vypadne, že je to Chromium. Používáte ublock, blokujete domény, mažete cookies – nic z toho jste nenapsal. A navíc to svědčí o tom, že si hrajete s hloupostmi, kterým nerozumíte, místo abyste si úplně základně zabezpečil počítač. Pokud se vážně chcete naučit používat počítač tak, abyste si ho mohl spravovat sám, začněte tím, aby se vám průběžně aktualizoval software. Prohlížeč je dneska z hlediska bezpečnosti ten nejexponovanější software. Mít dva a půl roku starou verzi je trestuhodná nedbalost. A ještě chcete obcházet bezpečnostní nastavení prohlížeče. Ne, vy se nejdřív potřebujete naučit používat počítač jako běžný uživatel.

1674
Zjistil jsem wiresharkem že CHR.stahuje něco z clients2.google.com/... nějaký čas . a přes nezabezpečené http!
Tím se testuje, zda nejste v síti, kde je captive portál.

Jestli se nemýlím, dříve jste tu různě řešil ad-block, mazání cookies a různá další „vylepšení“ prohlížeče. Ch.63 ve vašem komentáři znamená verzi Chrome? Pak mám pro vás jednu jednoduchou radu – přestaňte si rozbíjet prohlížeč, nainstalujte si nejnovější verzi, nechte zapnuté automatické aktualizace a nerozbíjejte ho žádnými doplňky. Zatím se zdá, že jediný problém je v tom, že vždy něco cíleně rozbijete, a pak si přijdete pro radu, co s tím máte dělat, že je to rozbité.

1675
Máte aktualizované důvěryhodné certifikáty v systému? Ten server opravdu posílá starý intermediate certifikát CA, ale prohlížeči by to mělo být jedno, protože by měl důvěřovat novějšímu certifikátu se stejným veřejným klíčem.

1676
Ta poznámka s  nerozlišitelností ip adresy na FORWARD  je cenná, když ji budu vést v patrnosti, půjdou ty filtry konstruovat  lépe od ruky.
V patrnosti byste měl vést především to, že ta poznámka s nerozlišitelností IP adresy ve FORWARD je nesmyslná. Pokud nebudete s pakety dělat nějaké nestandardní prostocviky, budete mít ve FORWARD takové IP adresy, aby se vám s tím dobře pracovalo. Ony ty řetězce PREROUTING a POSTROUTING a to, že v prvním se dělá DNAT a v druhém SNAT, nevymýšlel žádný hlupák.

Všimněte si, že Miroslav Šilhavý uvedl jediný příklad, kdy by měl ve FORWARDu problém – že nerozliší dst po DNATu. U typického případu, kdy máte jedno privátní síť připojenou přes jednoho ISP, ale nic takového rozlišovat nepotřebujete. DNATem uděláte portforwarding jedné veřejné IP adresy na jednu privátní, a ve FORWARDu tedy bude pracovat s tou privátní. Narazit byste na to mohl reálně tehdy, pokud byste měl dva ISP a veřejnou IPv4 adresu od každého z nich směrovat na jeden cílový server. Jenže pak zase nebudete ve FORWARDu potřebovat rozlišit, přes kterého ISP paket původně přišel. Pokud tam bude nějaká služba, obvykle budete mít tohle zapojení právě proto, aby byla dostupná přes oba ISP. A kdybyste náhodou chtěl některé služby vystavit přes oba ISP a některé jen přes jednoho, prostě na té službě budete dělat DNAT jenom na jednom rozhraní.

1677
Odkladiště / Re:abclinuxu.cz je dead?
« kdy: 13. 09. 2020, 18:00:57 »
Nedělal bych zas takovou kovbojku z toho, že přes víkend neběží web, o který se stará jeden člověk ve svém volném čase. Než kupovat doménu a data bude jednodušší počkat, až to Luboš v pondělí nahodí.

1678
Bazar / Re:Koupím knihy o umělé inteligenci
« kdy: 11. 09. 2020, 18:05:50 »
Mám jen díly 1–3. Máte zájem i o ně, nebo chcete jen komplet 1–5?

1679
O tom se budu hádat. Tam už nerozlišíte dst před NATEM.
Místo hádání si raději nastudujte průchod paketu netfilterem. Obrázek jste sám nedávno linkoval.

Sanitizace není filtrování v pravém slova smyslu, to je z pohledu routeru-firewallu nevalidní provoz a do reálných pravidel se ani dostat nemá.
Filtrování je blokování nevalidního provozu. Není rozdíl v tom, jestli paket zahodíte proto, že víte, že zařízení s cílovou IP adresou ve vaší síti není, nebo proto, že víte, že služba na cílovém portu není ve vaší síti poskytována ven. Například.

1680
Pravidla ovšem mají jak -i, tak -o, a kromě -src i -dst.  Je to takhle kompletní? Tedy filozofie : externí  = "blacklist" v směru dst ip neočekávám privátní rozsahy a v směru  src neočekávám moji síť; interní="whitelist"= směr src pouze. Jelikož dst zde nedává logiku
Musíte vědět, v jaké síti je váš router. Pokud je to ten nejjednodušší případ, máte router připojen do internetu a router má na svém vnějším rozhraní veřejnou IP adresu, router je tedy připojen do skutečného internetu. Pak se IP adresy z privátních rozsahů nemohou objevit u paketů z internetu ani v src ani v dst (ani pro INPUT ani pro FORWARD). Jedinou výjimkou by byl váš privátní rozsah v dst ve FORWARD, pokud byste používal DNAT (např. přesměrování portu z veřejné IP adresy do vnitřní sítě).

U paketů z vnitřní sítě se nesmí žádný privátní rozsah objevit v dst (pokud router propojuje jen vaši jednu privátní síť s internetem), v src bude jenom privátní rozsah z vaší sítě, ostatní také budete blokovat. Váš privátní rozsah v src je v pořádku, protože se následně v POSTROUTINGu aplikuje SNAT. Pakety, které vznikají na vašem routeru (INPUT) jako dst nemohou mít privátní rozsahy mimo ten, který používáte ve vaší interní síti.

Co když používám pravidla která mají -i  + -o zároveň? (jelikož router má 2 interface ). Je to dobrá věc nebo zbytečná komplikace
Mezi dvěma sítěmi (místní a internet) se to moc nepoužívá, protože obvykle na hranicích těch sítí zkontrolujete, že jde o povolený provoz z/do té sítě, a pak už mezi těmi sítěmi chcete povolit vše. Ale pokud byste měl sítí víc (a každou na samostatném rozhraní), dávají taková pravidla smysl – někdy budete chtít mezi různými sítěmi povolit různý provoz. Hodně primitivní příklad z dávných dob je ten, že do demilitarizované zóny povolíte z interní sítě přístup přes SSH, ale z internetu ne.

Stran: 1 ... 110 111 [112] 113 114 ... 375