Vie mi niekto v skratke popisat, ze co bolo na skupine 1.12.2016.
dik
- Mobilná aplikácia pre autentifikáciu
- Asistovaný prístup k elektronickým službám (koncept IOM v navrhnutej architektúre)
temy som vedel, myslel som nieco blizsie k nim napr. strucne zavery…pripadne ci sa otvorilo nieco nove a pod.
Moj zapis:
Na stretnuti sa riesila hlavne mobilna aplikacia na autentifikaciu. Toto bolo z mojho pohladu trosku nestastne a nizke, kedze sa vhuplo dost nizko do konkretneho riesenia ako robit autentifikaciu cez mobil a na tablete, bez toho, aby bol popisany high level scenar ako si cestu pouzivatela vlastne predstavujeme. Zacalo sa s predpokladom (podla mna chybne), ze zivotna situacia/podanie musi koncit podpisom cez ZEP/KEP a tym padom sa toto cele extremne komplikuje. Diskusia bola chvilu nekontrolovana kedze sa preberali prilisne detaily bezpecnosti, ktore sa maju riesit na bezpecnosti a az potom v tejto PS.
Navrhy z nasej strany boli hlavne:
- znizit uroven nutnej autorizace pre niektore(!) ukony z levelu 4 (zep) aspon na level 3. Tymto sa vyriesi kopec technickych komplikacii. Gestori nech prejdu svoje ukony a urcia minimalny level autorizacie, ktory na dany ukon treba
- podobne zaviest rozne urovne autentifikacie. niekde moze stacit FB login, niekde na to, aby som videl data (napr. ehealth) treba byt ovela striktnejsi.
- je potrebne zaviest moznost, aby bolo mozne vypnut (!) alebo limitovat pristup cez rozne kanaly. Priklad - nikdy v zivote nechcem, aby sa robili prevody mojho majetku ZEPom. Nechcem, aby niekto mohol za mna robit podanie na IOMO, etc. Toto je velmi individualne (napr. realitny makler alebo pravnik a uctovnik pravdepodobne budu nejake ukony chciet robit takto, nech maju moznost) - ako idealne miesto pre toto sa javi modul opravneni - kde budu aj tieto limity.
- je neziaduce aby stat robil trendy riesenia a pokryl vsetky podania online. je potrebne zistit, ktore zivotne situacie/podania ludia vlastne chcu robit online alebo dokonca na mobiloch a snazit sa tam znizovat level autentifikacie a autorizacie tak, aby netrpelo UX ale zaroven bola primerana bezpecnost. (Priklad - na dan zo psa naozaj ZEP netreba).
- povazujeme za klucove, aby stat umoznil zapojit sa komercii v dvoch miestach cez API. Jednak pri autentifikacii (stat nech pripravi svoj sposob, ale nech komercia ma moznost sa certifikovat na urcity level a ukazat ako to vie zjednodusit - v klude nech na tom zarobi), a pri autorizacii (v klude nech komercia vyuziva aj ZEPasaservice a predava ako produkt, ale nie je dovod, aby to robil stat pokial ponukne dostupne alternativne riesenie)
Tieto navrhy boli najprv trochu nepochopene, potom este raz este viac nepochopene, ale k zaveru to uz vyzeralo, ze sa na tom vlastne zhodneme a chceme to. Tymto veducemu skupiny a aj veducej prog. kancelarie dakujeme za trpezlivost a posnazime sa nase navrhy nabuduce jasnejsie naformulovat hned na 1x.
Nasledne bola kratka debata k IOMO o module opravneni. Nepamatam si z toho nejaky zasadny zaver, snad len to, ze je dolezite, aby OpenAPI bola vrstva pouzivana aj pre IOMO a ine kanaly. Vyhneme sa tak duplicitnym rieseniam pre interne a externe pouzitie a zvysi sa ich kvalita.
K IOMO bola vznesena zasadna pripomienka, aby neboli poskytovne vsetky sluzby na IOMO asistovane (priklad - nie je mozne aby na miestnom urade v hornej dolnej vedeli ako urobit nejake clo na lodnu dopravu). Treba identifikovat zakladny set ZS, ktory treba pokryt na IOMO a ostatne na IOMO neriesit.
Bolo povedane, ze JKM (jednotne kontaktne miesta) maju problem s IOMO lebo nevedia robit hotovostne platby.
Prioritne sa bude robit ZS - 7 kusov - nepovedalo sa ktore to su
Dalsie poznamky
- buduci stvrtok dokument na interne pripomienkovanie
- 14.12. - zacne verejne pripomienkovanie dokumentu
- bude zavedeny schvalovaci mechanizmus pre nativne aplikacie (postrazit si) podobne ako UK
2 Likes
Toto je trochu nešťastná formulácia, keďže nariadenie eIDAS pozná len tri úrovne zabezpečenia a to „nízka“, „pokročilá“ a „vysoká“ (mapovanie na STORK úrovne QAA 2, 3 a 4). Navyše eIDAS legislatíva definuje použitie elektronického podpisu len na podpisovanie údajov a nie autentifikáciu, takže autentifikácia cez ZEP/KEP je v rozpore s eIDAS nariadením.
Stanovisko EK:
“an eSignature can only be used by a natural person to “sign”, i.e. mainly to express consent on the data the eSignature is put. This represents a difference from the eSignature Directive where the eSignature – which could also be used by legal persons – was defined as a means for authentication”
https://ec.europa.eu/digital-single-market/en/news/questions-answers-trust-services-under-eidas
Podľa ENISA (Privacy Features of European eID Card Specifications — ENISA, kap.4.3.2. Authentication vs. Digital Signature) elektronický podpis (PKI koncept) nie je vhodný pre použitie na účely autentifikácie osôb, nakoľko predstavuje narušenie ich súkromia a tým porušuje “minimal disclosure” princíp požadovaný EU zákonom o ochrane osobných údajov (EUR-Lex - 31995L0046 - EN - EUR-Lex)
4 Likes
Diky, opravene preklep. Bola myslena autorizacia. @Lubor isto opravi aj ine nepresnosti. Ospravedlnujem sa.
A modul opravneni bude autorizovany cez ZEP? 
Jedine riesenie na zrusenie zrusenia prevodu majetku ZEPom bude potom vybavit to papierovo/notarsky overenym podpisom. Tu IMHO hrozi, ze si ludia preventivne vsetko povypinaju a sme v bode 0.
Ja navrhujem riesit to viacfaktorovou autentifikaciou/autorizaciou, cize napr. by som si zvolil, ze okrem ZEP chcem este aj nieco ine (podpis pred notarom, ZEP od inej osoby/inych osob, atd.) Predpokladam, ze trh by prisiel s dalsimi moznostami, ktore by to zjednodusili. Napr. poistovne s produktom, ktory by spolu s poistenim nehnutelnosti prinasal klientovi druhy online sposob autorizacie prevodu vlastnictva nehnutelnosti, pricom poistnou udalostou by bol hack tohto sposobu autorizacie.
1 Like
Pokiaľ tieto služby budú dôveryhodné podľa eIDASu tak by nemal byť vôbec žiadný problém prepojiť ich so schránkami.
Napr. České mojeID v konzorciu s niekym zo Slovenska by mohlo byť využité ako autentifikačných nástroj k eschránkam.
Alebo online riešenie autorizácie sa a service od disigu, len je dôležité aby to bola dôveryhodná služba podľa nariadenia.
Pochybujem že Facebook sám o sebe bude môcť byť použitý ako autorizácia, nepredpokladám že Facebook má ambíciou byt dôveryhodnou službou v zmysle eIDASu.
Pri komunikácii zo štátom pokiaľ nechceš dopĺňať podanie v listinnej podobe si limitovaný kepom. Lebo len KEP je uznaný ako vlastnoručný podpis. Podľa agendových predpisov všetky podania musia byť podpísané. Pokiaľ nemáš podanie podpísané vyzve ťa na podpísanie s tým, že keď podanie nepodpišeš na podanie sa neprihliadne/odmietne. Takto to fungovalo aj keď sa podania faxovali, dalekopisovali a dokonca aj keď sa e-mailovali.
Nemyslím si, že by sme boli v bode 0, ak si dnes v tatrabanke viem obmedziť kartové operácie cez internet na 0,- EUR tak ich banka jednoducho nezrealizuje. V prípade, že potrebujem realizovať platiť cez internet tak si zapnem platby cez internet, resp si nastavím limit.
A rovnako nie je zlé, ak si viem nastaviť další faktor autorizácie, token, SMS.
Otázkou je, čo so sprísneným úkonmi napr. Prevod Nehnuteľností.
1 Like
Ak vies vypnut/zapnut platby cez internet cez internetbanking, tak to nie je ziadna velka ochrana, v pripade, ze mas napr. kompromitovany pocitac/mobil. Motivovany utocnik ti pred vybielenim uctu zmeni nastavenie. Preto je podla mna lepsie ist cestou viacerych faktorov.
Je jednoduchšie kompromitovať milión elektronických rozhodnutí, ktoré sú uložené na jednom mieste alebo milión rozhodnutí v listinnej podobe, ktoré sú rozložené po celom Slovensku?
Napriek tomu všetci chcú elektronické rozhodnutia.
Rovnako ako NBÚSR123 budú zabezpečené agendové systémy a kompromitácia sa začne riešiť až keď to bude neúnosné. Dnes ti budú všetci tvrdiť, že je všetko OK.
Určite nastavovanie limitov a jednotlivých úkonov musí byť realizované cez sprísnenú validáciu užívateľa. Internet banking Tatrabanky heslo a token, cez mobil sí limity nenastavíš.
Napadlo mi, že rovnako by sa mohlol riešiť aj spôsob komunikácie so štátom. V edesku vy si si povolil mobilne zariadenie a aplikáciu cez ktorú by si komunikoval so štátom a OVM by túto komunikáciu akceptoval ako vlastniručne podpísanú. Išlo by hlavne o menejsorisné úkony.
Inak česká judikatúra akceptovala podnaian realizované cez dátové schránky, ako podania ktoré, nie je potrebné dopĺňať.
Viete niekto, ci su by design spravene nejake disaster recovery plany na vyssej urovni ako datovej? Mam na mysli situaciu, keby napr. cieleny utok sposobil velky rozvrat dat, napr. by utocnici “cez noc” pomenili vlastnictvo polovice nehnutelnosti alebo srociek. Naprava standardnou cestou cez konania na katastri a sudoch by trvala roky.
Som moc paranoidny? IMHO nie som, vid spravy o tom ako sa postupne europske krajiny zacinaju branit ruskym informacnym utokom, podozrenia z ovplyvnenia volieb v USA, a pod. Vytazenie verejnej spravy napravou nejakeho chaosu moze byt napr. pouzite ako diverzna akcia pred inym utokom, informacnym alebo vojenskym.
Ci sa uvidi, ked k takemu niecomu dojde?
Nebudeš vedieť, že k tomu došlo. Musel by to byť veľmi masívny útok, ktorý by bol povšimnutiahodný. Tie “drobné” si nikto ani len nevšimne.
NBÚ sa nechválilo, že do ich systémov prenikli nepovolené osoby. Banky sa nechvália, že majú občas problémy s elektronickými ale aj neelektronickými transakciami. A samozrejme zodpovednosť sa bude prenášať na užívateľa. Podobne ako Janota prenášal zodpovednosť za nepodarený systém na sudcov, úradníkov a podobne.
Trocha upresnenie čo Jano písal ku 1.12., aj keď niektoré veci tu už odzneli, ale radšej nech je to tu ucelene:
Ako všetci už vedia riešila sa “mobilná aplikácia na autentifikáciu”.
Úvaha: Pridajme k tomu autorizáciu. Nekreslime hneď obrazovky, najprv definujme požiadavky, čo presne to má pokrývať.
MP (mobilná platforma) = mobilný telefón, tablet, kde používateľ robí bežné činnosti, napr. web, mail, appky atď. a bežne ho nosí so sebou (toto je dôležité pre bezpečnostné úvahy)
Za nás návrh:
- štátne riešenie pre MP nemusí pokrývať “všetko”
- ani všetky služby/podania, ani podporovať všetky technologické vychytávky
- postačí ak sa zvolí určitá rozumná úroveň autentifikácie/autorizácie, v rámci ktorej sa bude dať vykonať väčšina vecí ktoré “bežný” používateľ chce robiť cez MP
- otázka: máme spravený prieskum, čo vlastne ľudia chcú robiť cez MP? prípadne nejaké skupiny ľudí? a čo naopak nechcú? nemáme a aj tak navrhujeme riešenie?
- moja skromná skúsenosť hovorí, že závažné veci (klasický príklad: predaj nehnuteľnosti) nie je dobré tlačiť do MP a navyše ich bežný človek robí málo kedy
- napr. poznám viacero ľudí, ktorí preto že “cez eID a KEP sa dá spraviť všetko” (hacknú mi PC, predajú mi dom) radšej nechcú používať KEP vôbec
. - preto určime maximálnu úroveň autentifikácie a autorizácie, ktorá bude podporovaná vlastným štátnym riešením na MP
- ponechajme systém otvorený tak, aby sa ľahko dali k nemu pripojiť iné aplikácie (napr. komerčné), ktoré môžu poskytovať vyšší stupeň A/A
. - návrh pre autentifikáciu: nech štát poskytuje na MP level 3 (štandardov ISVS, zhodé so Stork QAA)
- level 3 sa má dať zvládnuť čisto SW riešením (a používateľskými vstupmi), čiže netreba špekulovať nad HW vecami
- otvorme eGov autentifikáciu pre ďalšie schémy, ako diskutujeme napr. pri vyhláške o alt.auth. - povedzme tie SD karty čo vyvíja HP a Plaut nemusí hneď štát pre všetkých kúpiť, ale niekto to môže komerčne prevádzkovať
. - návrh pre autorizáciu: vytvorme nový nižší level od KEP, zodpovedajúci tomu čo je dnes “autorizácia funkciou aplikácie” (po slovensky: autorizujem kliknutím na ikonku, samozrejme musím byť pred tým prihlásený)
- toto nech je štátom poskytovaný level pre MP
- ak treba vyšší level, používateľovi môže celé podanie na MP vytvoriť, naplniť, a na konci uložiť - autorizáciu a odoslanie môže spraviť na inom zariadení kde má dostupný KEP
- a opäť umožnime na MP integrovať iné autorizačné služby, napr. ten KEP - príklad je server side sign čo robí Disig
. - klasifikácia, ktorá služba je ktorý level autentifikácie, a ktoré podanie bude umožnené aj nižším levelom autorizácie, je na gestoroch (čiže každý úrad za seba)
- zváženie konkrétnych riešení pre A/A patrí do PS Bezpečnosť, nie sem
1 Like
eIDAS iba predpisuje povinne akceptované identifikačné/autentifikačné schémy.
V rámci nášho eGov si samozrejme bez problémov môžeme definovať ďalšie vlastné, alebo u nás uznávané.
“Nemal by byť problém” - v tom verím aj ja, ale zatiaľ som teda žiadne rozhdanie pre eIDAS autentifikáciu v praxi nevidel, rád sa s ním zoznámim, aj s jeho použitím na mobilných platformách.
V zákone o eGov §32.1 je v pohode aj dnes možnosť robiť autorizáciu ináč ako KEP, pozri časť vety za “to neplatí, ak”. Volá sa to “uznané spôsoby autorizácie” a upresniť to má vyhláška MV, viď. §59.3.g.
A samozrejme zákon sa dá upraviť, najbližšia novela bude začiatkom 2017 (narýchlo posúvanie schránok nerátam).
Ešte k tomu “mať možnosť limitovať prístup cez kanály”.
Toto je zatiaľ iba koncept, treba samozrejme premyslieť ako by to fungovalo a nevyhnutne zvážiť aj náklady.
Zopár otázok:
- Pri elektronických podaniach stačí kontrolovať podania došlé do schránky OVM a na podateľňu, alebo aj niekde inde?
- Ak by to malo fungovať, určite treba zásadne doplniť zákon, ale aj zaužívané pravidlá, v papierovom svete neexistuje obdoba.
- V podstate hovoríme o dohľadovom systéme na vstupy. Tam sa dá vymyslieť kopa pravidiel, napr. po vzore bankového sveta. Povedzme limitovať KEP na/pre určitý konkrétny certifikát. Aj nie priamo zákaz, ale podmienenie prijatia dodatočným overením (zavolajú mi). atď.
- Malo by to pokrývať aj asistovaný výkom verejnej moci, čiže možnosť zakázať IOM.
- Keď už sa to bude robiť, má sa to týkať aj papierových podaní (však aj to je kanál)?
2 Likes
Dobry vecer pan Illek,
preletel som si Vas mail, ale je to na dlhsiu response.
Mozno sa k tomu dostanem zajtra vecer, mozno v stredu. Ak sa nebudem
ozyvat, PLS urgujte ma… kludne…
V zasade je to, co vravite, v poriadku. Len zalezi na odberateloch,
uceloch… Aby to cele malo zmysel.
Na ukazku Vam mozem ukazat nas fail projekt e-ID.sk, ktory bol urcely
pre e-sluzby pre obyvatelov miest a obci, kedze statny eGov nie a nie
urobit nieco pouzitelne. Napr. pre e-POBox.sk. Popis architektory a
sluzieb prikladam.
Pozdravujem a prajem vela chuti do prace v tejto oblasti
am
GovIS-eGov-brozurka.pdf (539 KB)
Návrh tém na workshop 8.12.2016
- E2E cesta klienta pri realizácií eGov služby pre identifikáciou bielych miest
- Modul povolení k el. službám
- Dokument SP Multikanálový prístup, vysvetlenie štruktúry, ďalšie kroky
Ako jeden zo spôsobov autorizácie si viem predstaviť aj SMS s OTP (použiteľné aj pre eGov služby na desktope), takže:
- stupeň 1: autorizácia potvrdením (kliknutím na ikonku/button)
- stupeň 2: SMS s OTP (na registrované mobilné číslo)
- stupeň 3: KEP
Štátom poskytované spôsoby autorizácie: 1 a 2
Môže byť? 
1 Like
par veci:
-
je niekde aktualny dokument, ktory sa da pozriet? mimochodom, prave na taketo cinnosti (standardizacia a participativna tvorba dokumentov) si stat zaplatil wiki.finance.gov.sk, na taketo ucely by to bolo idealne
-
co vlasnte znamena “E2E cesta klienta pri realizácií eGov služby pre identifikáciou bielych miest”?
-
Lepsie sluzby by sa mohli tvorit aj principom zdola a to tym sposobom, ze by sa na vybrane (najpouzivanejsie) interakcie VS s obcanom/podnikatelom vytvorili iba obycajne formulare na slovensko.sk, bez nejakej podpory backendu. Spracovavali by to uradnici rucne, myslim ze tak nejak to asi funguje aj na JKM https://www.slovensko.sk/Services/Ives/ZrFormulars/Info.aspx?tradeName=ZROHLAS_FO
V zasade rovnaky proces, ako teraz spracovavaju podania papierove, akurat im to pride cez UVPS.
Pridanou hodnotou by vsak bolo, ze by bolo mozne presne sledovat frekvencie a casy spracovania podani a z toho vybrat agendy, ktore sa oplati elektronizovat.
Treba zmapovat ake formulare este treba zelektronizovat (avsak nie celoplosne, iba to co sa najviac vyuziva) a existuje si myslim ze sa urcite daju zoptimalizovat -
Mobilne aplikacie su podla mna krok vedla, neviem si na to predstavit use case. Appky vyuzivam, ked pouzivam nieco vyslovene casto, alebo to potrebujem offline. Statne veci chcem vyuzivat co najmenej a iba online. Navyse su to pomerne zlozite veci.
Moj nazor je, ze treba urobit jeden kanal poriadne: API + responzivny web, ktory to iste verejne API vyuziva
3 Likes