Vlákno názorů k článku Martin Mesršmíd (DIA): eDoklady shodily Identitu občana, musíme ji zásadně předělat od Danny - Takze nejakych 130 tisic (dle zprav pozdeji "az"...
-
A vsimnul jste si, kolik obyvatel tahle zeme ma? :-) I kdyz to treba jen zuzime na lidi v produktivnim veku? Ne, 150 tisic za cely vikend neni nikterak zavratne cislo. Notabene, kdyz se verejne deklamuje, ze lidi k s tim budou moct chodit treba k volbam... kde jde v principu ocekavat napor vetsi. A stat ma ruzna data, ze kterych si muze poskladat, jaky napor asi tak muze ocekavat. Ale to by nekdo musel pouzivat mozek a na ty data pri sizingu se podivat, ze? Samozrejme, ze z DIA ted budeme poslouchat vymluvy, proc se to nezvladlo.
S eDoklady se jednoduse spechalo, muselo to byt nutne hned - pritom cely je to sity horkou jehlou - zakon se schvalil az v prosinci, vladou to proslo teprve na podzim... i v clanku se priznava, ze to hlavne chteli mit rychle hotove - a vsichni zucastneni se od prvopocatku tvarili, jak to bude slunickove. Delali tomu aktivni PR, jdou o tom vykladat i do televize. A pak se tu bude fnukat, ze na to lidi fakt vlezli? Ne, to vsecko jsou jen dusledky kvapne prace, spatneho designu, podceneni skutecneho stavu.
-
On se "teoreticky" o tu izolaci mozna nekdo misty i snazi, jenom v praxi...
edoklady.gov.cz has address 185.17.215.70 seznam.edoklady.gov.cz has address 185.17.215.70 autorizace.edoklady.gov.cz has address 185.17.215.70 notifikace.gov.cz has address 185.17.215.70 chcidatovku.gov.cz has address 185.17.215.70 obcan.portal.gov.cz has address 185.17.215.70 chciidentitu.gov.cz has address 185.17.215.70 portal.gov.cz has address 185.17.215.70 designsystem.gov.cz has address 185.17.215.70 gov.cz has address 185.17.215.70
...proste se stejne jede koncept jedne devky pro vsechno :-) Samozrejme, muze to byt load-balancer a za nim spousta dalsich serveru, mezi ktere se to rozhazuje... ale treba z pohledu tech zminenych potencialnich utocniku se staci oprit do jednoho mista.... a pokazi se toho navenek spousta. A uz tuplem tam je i zahadou, proc nekdy je AAAA (IPv6) zaznam publikovan a nekdy ne - kdyz to konci realne na jedne krabici (nabizi se fakt jen to, ze koncove aplikace jsou zpraseny uvnitr - a to i ty nove typu eDoklady a s IPv6 se tam "zatim" nepocita).
Samozrejme jsou veci, se kteryma nic udelat nejde - NIA a jejich SSO logicky bude tim slabym mistem vzdycky (a dost dobre to nepujde izolovat), to proste musi byt postavene tak, aby to nepadlo na hubu kdyz do toho zrovna busi par set tisic lidi. Ale i tam existuji techniky, kterak ten workload rozlozit mezi vice stroju i navenek. Nic z toho se ale nepouziva (ale aspon tam IPv6 maji)...
Kde presne problem vznikl samozrejme muzeme spekulovat donekonecna - mame tu nejaka vyjadreni s DIA, ale to jsou v zasade take jen tezko overitelne vyroky predstavitelu te instituce. Samotna aplikace je navzdory "Bartosovo/Piratskym" idealum opet uzavreny bazmek. Co se tam realne deje vi buh - ale treba uz jen spusteni, nez si to rekne o otisk trva vecnost... a pritom to nikam ani nekomunikuje. Co se deje na backendu uz tuplem nezjistime - to by bylo videt z kodu, ktery se ale tutla, ze? ;-)
-
to je asi nepodstatné, vždy máš nějaké omezení a nikdy nemůžeš dimenzovat na jakýkoliv provoz. Za mě je daleko větší fail, že jeden integrovaný klient dokáže udělat takový provoz, aby omezil celou službu, která je na kritické cestě spousty jiných systémů.
To tam nemají žádný rate limiting? Qouty? Omezení? Fair usage? Frontu požadavků? Priority? To opravdu vše přímo pustí na backend ať se to nějak popere a řeší, jestli mají paměť, že mají active-active a že to teda musí posílit? Je mi stydno.
V píše v rozhovoru, frontu připravují, ale ta podle něj neřeší problém. Chyba, tam právě problém může řešit, s frontou se dá dynamicky pracovat a třeba přeskočit/vyloučit toxický provoz nebo provoz, který je abnormální a obětují ho ve prospěch jiného.
Stejně tak samotná aplikace pro občanky, vyhazuje náhodné chyby místo, aby uživatele problémem provedla a nabídla mu řešení.
-
máš spoustu globálních služeb, které běží na jediné IP adrese, že. Tohle ještě nic nedokazuje a riziko ztráty AS vyhodnotili asi jako minimální. Horší je, to co vidím v BGP, mno, jsou zatím na začátku.
A ano, jsou to LB.
Izolovat můžeš jednotlivé strany v SSO, tak to přesně i děláme i komerčních projektů, dnes např. celé banky běží nad jedinými SSO systémem a potřebuješ zajistit, že core věci budou fungovat, když ti nějaká aplikace či útok tu bránu přetíží, prosotě můžeme řídit tok, který SSO obsluhuje, tak aby se minimalizoval dopad.
Tohle asi ověřitelné nikdy moc nebude, u málokterého státu do těch systémů vidíš více. Ta aplikace je pomalá, protože si tam počítá nějaké certifikáty a šifrování, dělá to očividně dost nespodárně, všechna svoje data má šifrovaná a při načítání je dešifruje. Aspoň takhle mi to připadá při prvních pokusech to debugovat a sledovat, vypadá to, že tam mají určité potenciální slabiny, ale do nahlášení a opravy to ventilovat nebudu.
Když se tutlá kód drtivé většiny systémů, tak to kritizovat u jediného nového nedává smysl, prostě stát zatím jeden cestu uzavřenosti (on to je i problém toho, že na řadu api, dokumentací a knihoven nemá plná oprávnění a vlastně si je pouze licencuje od dodavatelů).
-
'Opakuji, pro mě je problém, že může nějaká aplikace třetí strany schodit kritický systém a omezit tím všechny další aplikace. Je jedno, jestli aplikace je šitá horkou jehlou nebo je v rukou útočníků, tohle se prostě nesmí stávat a základní registry musí umět tohle ustát ať už se bavíme o jednotkách, tisících nebo milionech transakcí.
Vždy budou aplikace, které jsou fušařina, vždy budou aplikace, které budou mít spičkový nápor (ze spousty reálných důvodů), vždy mohou být aplikace, které úspěšně napadne/zahltí útočník, ale důležité je ten problém izolovat a nikoliv řetězit. To ti snad nemusím vysvětlovat, ne?
Píšeš, že ta aplikace je šitá horkou jehlou, ale přitom hlavní problém nevznikl v samotné aplikaci (UX a chybové hlášky jsou spíše dneska už norma než problém, bohužel).
-
No, ta "selektivni" podpora IPv6 v CMS je to, co mi hlava proste nebere...
gov.cz has address 185.17.215.70 gov.cz has IPv6 address 2a03:2320:b944:1c60::96
- aneb na stejnem koncovem uzlu to "nekdy" jde...
I kdyby tu IPv6 schovali za reverzni proxy a dal do Azure to sypali po IPv4, fungovalo by to. Takhle se ostatne zacinalo uz pred mnoha lety - kdy ne kazda vec zvladla poslouchat na v6 socketu... a tohle zvladne kdejakej load-balancer.
Za osm let chteji IPv4 vypinat, ale nemaj ani nachozeny prechodovy mechanismy, kterejma si jinde prosli uz pred lety. Proste jedno velku WTF....
-
Tak co se tyce dostupnosti IPv6, vznesl jsem dotaz a dnes mi prisla odpoved. Posud sam:
Systém eDokladů je provozován v prostředí cloudu Microsoft Azure, avšak do internetu je publikován přes služby Centrálního místa služeb (CMS) Ministerstva vnitra. Aktuálně bohužel neexistuje standardizovaná služba CMS pro publikaci do internetu z cloudového prostředí Microsoft Azure prostřednictvím IPv6.25. 1. 2024, 20:51 editováno autorem komentáře
-
Argument se sifrovanim by byl validni pred 15 roky - a i tehdy by to bylo sporne. Akcelerace sifrovani v hardware je na takove urovni, ze to fakt neni zadny problem.
Kritizovat uzavrenost novych systemu je zrovnatak na miste - kdyz sam Bartos ma ve svem politickem programu otevreny kod a mluvi o tom cele roky. Zadani, ktera mohl sam primo ovlivnit ale neodpovidaji tomu, co sam hlasa o otevrenosti...
ČLÁNKY DO MAILU