Toto bude skor otazka na @rho ale pokial viem, tak by sa mal robit failover na druhe DC (co si rad pozriem).
Toto je omyl, ak potrebujeme kazdy s kazdym, tak to bude hlavne zle navrhnute. Internet je decentralizovany a tiez nemam pocit, ze sa treba integrovat kazdy s kazdym. Toto bola presne ta pointa co som pisal vyssie. Ak niekto potrebuje vela integracii a nebodaj sa to zacne este napriec projektami opakovat, tak pravdepodobne nie je chyba v integraciach, ale tam chyba na opacnej strane nejaka klucova sluzba. Preco by napr. RPO (alebo iny uzol) nemohol na svoje data poskytovat sluzbu ako nas autoform?
neviem, ci sa pytas ironicky alebo vazne. Ale teda datove centrum MF SR ma vlastne zalozne pracovisko. Predpokladam, ze aj datove centrum MV SR bude mat tento isty koncept. Zaujimave kolko hw, sw a licencii tam je v stave “ready to use”, ale to je ine forum…
V akom zmysle to vy vnimate ako SPOF? Pretoze sravit ten single bod tak, aby bol dostupny vzdy a vsade, nie je nejaky problem. Takze toto pre mna ani nie je argument tym padom.
btw. govnet = doteraz drzime ITMS2014+ v stave “pilotu”, aby neverejna cast/backend bol pre uradnikov dostupny cez internet a nie cez govnet, lebo nas do toho tlaci prevadzkovatel a odvolava sa na zakon 275/2006 Z.z. … s govnetom mame vlastne skusenosti a nie pozitivne
Keď sa bavíme o výpadkoch, resp. závislosti na externých službách, tak to je dobrá otázka. A dosť zložitá, najmä ak sa majú integrácie, cloud a podobné faktory mimo kontrolu správcu ISVS brať vážne.
BCM by sa malo riešiť v strategickej priorite “bezpečnosť”, ale tam sa zatiaľ do takéhoto “detailu” neišlo, všakáno.
Čakal som kto sa chytí.
Spýtaj sa čo si o tom myslia na MV a v Nases a prepošli to sem.
Ale zasa ak tam majú voľne tiecť všetky dáta, trocha paranoje nezaškodí.
Za normálnych okolností by mala stačiť štandardná ochrana na transportnej úrovni, čiže SSL/TLS, ale po dierach nájdených tam za posledné 2 roky, … no neviem. Chcelo by to malú cielenú analýzu, napr. SSL s klientským cert. a reštritkívnou konfiguráciou je oveľa viac ako bežné https.
Technicky je to skoro jedno, hlavne aby to bola konzistentná sieťová štruktúra, kde subjekt raz si zriadi prístup (byrokraticky aj implementačne) a následne vidí všetkých ostatných bez vybavovania každý-s-každým.
Boooze … .to je nerealne . To je myslienka ako z ucebnice idealistickeho socializmu. Max. na par kritickych aplikacii … ale to maju uz teraz.
Akurat, ze kazde z tych DC ma svoje vlastne zalozne pracovisko … a tam par najnevyhnutnejsich aplikacii (rozpoctovy IS, … .a pod.)… aj to v mode chladnej zalohy z replik… cize par minut (mozno hodin) by trvalo kym by zalohy nabehli a nejaka strata dat by tam mohla byt … Keby kazda appka mala replikovat data do geolokality par sto kilometrov vzdialenej, to by boli ine palky za opticke prepoje, licencie databaz, storidze a podobne veci …
ja len ze ak sa argumentuje single point of failure, tak co nam pomoze ze bude decentralizovana vymena dat, ak vsetci poskytovatelia budu v jednom cloude a ten padne. sa mi tento argument zda ciste vykonstruovany.
takze predstava ktora sa tu formuje: v govnet vypublikovane vsetky sluzby, ku ktorym maju vsetci pristup.
potom ale treba legislativne upravit aby zodpovednost za neopravnene poskytnutie udajov nebola na poskytovatelovi, ale naopak bola na konzumentovi za neopravnene pouzitie.
dalsi problem, ktory tu este vidim, je garancia udajov. tieto systemy nikto neaudituje. Poziadam o udaj v case a a dostanem hodnotu x, nasledne v case b poziadam o to iste ale dostanem y, lebo medzitym niekto v IS zmenil údaje. ako na toto? ako ma mat urad istotu ze udaj, ktory som dostal je garantovany. asi by mal existovat nejaky sposob ako toto zabezpecit.
Voči komu a v akej situácii riešiš “preukazovanie zhody v čase”?
Systém musí byť postavený tak, že konzumenti dôverujú údajom ktoré dostanú. T.j. spoliehajú sa na to že sú správne tak ako ich dostanú.
Pre ref.údaje viď. §50.1: “Ak osobitný predpis neustanovuje inak, hodnota referenčného údaja sa považuje za úplnú a zodpovedajúcu skutočnosti, kým nie je preukázaný opak.”
Ak dôjde k sporu, či boli použité správne údaje (nie či hodnota tých údajov je správna), vytiahne sa údaj zo zdrojového registra, logy z oboch systémov a posudzuje sa.
Áno, treba riešiť tému autorizácie na prístup k údajom. A to na úrovni 1) potreby/oprávnenia na prístup, 2) procedúry na posúdenie tohto oprávnenia, 3) technické prevedenie týchto vecí - ideálne automatizovane, online.
Podľa mňa je požiadavka “1x a dosť” v tejto veci natoľko silná, že ak má efektívne fungovať, bude potrebné upustiť od posudzovania vopred či určitý OVM má mať prístup ku niektorému typu údajov ako sa to robilo doteraz. Ako správne píšeš, vrátane prenesenia zodpovednosti na konzumenta údajov. Pozri aj v NKIVS riadenie prístupu laissez-faire.
Minimálne zaviesť paušálny prístup pre niektoré “menej citlivé” údaje - napr. RA, RPO atď. ale v zásade aj bežné osobné údaje.
Toto je vlastne už aj zakotvené v §17.6 - výnimka sú nejaké-tajomstvo, povinnosť mlčanlivosti a ja by som teda zvažoval zaradiť tam aj osobitné kategórie osobných údajov. V týchto prípadoch sa má vyžadovať dokonca súhlas príslušnej osoby na poskytnutie údajov.
mal som na mysli presne tú situáciu ak dôjde k sporu. resp. o tu istotu. aku mam istotu, ze RFO, alebo iny ISVS tie udaje nezmeni, vsak co si budeme hovorit, pri niektorych agendach je antidatovanie uplne normalna vec a zatial neviem tomu ze existoval nejaky proces ako overit ze ISVS splna kriteria na ref. register.
btw. ak budeme 1xdost robit tak, ze vsetci musia byt referencny register, tak nateraz je to uplnene nerealne.
vsetci sa tomu budu branit
alebo budu chciet nato nemale peniaze
a zatial nevidim ziadny posun v procese vyhlasovania ref. registrov.
ibaze @juraj.bardy by vedel nieco viac ak si mysli ze to sa da za 2 roky
Ako je toto riesene v “papierovom” svete? V praxi su tiez problemy, ked napr. ma clovek od Socialnej poistovne potvrdenie, ze ma vsetko vysporiadane ale potom o rok prevetraju system a najdu nejaky nedoplatok a zacnu ho vymahat. Ako bonus pouziju na dorucenie staru adresu, kde clovek uz 5 rokov nema trvaly pobyt.
Idealne by mali existovat konsolidovane udaje a tie podpisane organizaciou, cize napr. otazka “mam nedoplatok v socialnej poistovni?” by bolo “SUM(uhrady do datumu X.Y.Z) - SUM(predpisane odvody do datumu X.Y.Z) == 0” a s tymto potvrdenim by som ziskal imunitu na akekolvek zmeny v registroch tykajuce sa casu spred datumu X.Y.Z. A tu sa dostavame k dalsej mantre a to je osobna zodpovednost uradnikov, kedy by sa skoda (neskor zisteny rozdiel) zacala vymahat od toho, kto ju sposobil.
V papierovom svete sa úrad chráni tým, že od iného úradu prinesieš potvrdenie, ktoré si založia do spisu. Čiže to majú zachytené (papier), autorizované (pečiatka/podpis) a s dátumom.
Pri elektronickom zdieľaní údajov je toto splnené tiež - dáta sú v zachytené v konkrétnej štruktúre, je v nej uvedené čo a od koho to je, aj dátumy. Otázka je akurát čo s autorizáciou - majú všetky dáta chodiť podpísané? a čo s neskorším dokladovaním - kto/kde si má tie dáta odkladať?
Myslím že tu treba spraviť zmenu od papierového sveta, za uchovanie údajov má zodpovedať iba ich poskytovateľ. Čiže ten musí vedieť pre každé konkrétne údaje “poslané von” vedieť v budúcnosti vygenerovať ich presnú kópiu.
K autorizácii údajov - myslím že minimálne pre údaje z referenčných registrov by nemalo byť vyžadované zasielanie “dokumentu” autorizovaného pečaťou, ale skrátka získanie údajov cez príslušné API a ich autentickosť by mala byť zaistená implicitne, skrátka vybudovaním dostatočne bezpečného systému.
(Teraz čakám že sa opäť po odmlke chytia témy blockchain aktivisti.)
"Túto a podobné témy budeme riešiť aj v on-line diskusii, ktorú organizuje Nadácia F. A. Hayeka a portál Aktuality.sk s podporou nadácie Friedrich Naumann Stiftung a spoločnosti Deloitte.
Debatu si môžete pozrieť dňa 28. 10. 2016 od 10,00 hod. na stránke Aktuality.sk.
V diskusii vystúpia:
Martina Slabejová, poverená riadením sekcie informatiky z Úradu podpredsedu vlády SR pre investície a informatizáciu,
a teraz uz zostava najst len jeho nejake prevtelenie, pomocou ktorej doveryhodne preukazeme zhodu v case