MIRRI Pracovná skupina K9.4 Lepšie dáta

Tak @juraj.bardy mi uz pise, ze toto bolo nepochopenie a je to chyba v dokumente. Ja som zvedavy teda ako toto dopadne.

Zase, aby sme si zachovali trocha objektivity: Centralizacia spravy dat je vo vela pripadoch dobry napad. To je princip IDM/Identity Governance a je to naozaj dobry zaklad pre data protection (kto chce vediet viac tak ask me). V beznych pripadoch (enterprise, telco, academia, …). Problem je, ze nasa statna sprava nie je tento pripad. To si autor asi uplne neuvedomil. Ale ak mam povedat pravdu, autorovi jeho situaciu nezavidim. Ani trochu. A to mam skoro 20 rokov praxe v IDM.

2 Likes

tu je to skor nepochopenie co je vlastne ulohou. ze existuju zdrojove registre a referencne registre. A ze problem nie je ani tak o 1x dost. A GDPR sa zase pouzila ako univerzalny argumnent.
Pre to s cim clovek naozaj obieha urady to riesenie nie je. Ale ista predstava ze bude existovat centralna autorita zodpovedna za ine ciselniky ma mozno zmysel.

Striktne povedane, pristupy ako rejoiner vyzeraju super na papiery. Ale to ma tiez svoje limity. Realne, urady potrebuju pristup k datam. Mozu ich zbrat bud z centralneho registra (jednoduche). Alebe centralny register bude mat len meta data a odkaze na aplikaciu co tie data naozaj ma (a la rejoiner). Ale ten druhy pripad je podstatne zlozitejsi (ved pozname “all problems in computer science can be solved by another level of indirection”). Zlozitost sama o sebe by bola prijatelna, ak by naozaj nejaky problem riesila. Lenze, to je v tomto pripade otazne. Aj ked centralny register nebude mat vsetky data, pravdepodobne bude existovat system, co bude davat uradom opravnenia pristupovat k datam v inych uradoch. Asi nejaky identity provider(IdP)/OIDC provider/autorizacny server a podobne. Otazka je, ci tento system nie je bezecnostnym ekvivalentom centralneho adresara osobnych udajov (zjednodusene: ak hackem IdP alebo centralny register dostanem tie iste data). A ak je bezpecnostnym ekvivalentom, je ho mozne zabezpecit lepsie ako centralny register? Alebo zlozitost (a nedostatocna dozretost) technologii sposobia, ze celkova bezpecnost bude nakoniec horsia? A aky komponent bude v skutocnosti zodpovedny za data protection? Kde budem vidiet audit pristupu k datam (kedze to nemusi nutne ist cez ten centralny meta-register lebo ved mame caching)? Ako budem vediet kto ma kopiu dat (obrovska vacsina aplikacii nebude vediet fungovat bez toho aby si urobili kopiu)? Aky komponent bude zodpovedny za konzistenciu (napr. opravy, lebo ved su len dva tazke problemy v IT), archivacie, redukcie dat, spravu consentov/lawful basis a podobne?

Zlozite otazky. Ziadne lahke odpovede. Naozaj, tuto ulohu nikomu nezavidim.

Nechcem vyznieť príliš netrpezlivo, ale toto všetko sa už predsa riešilo a je k tomu dosť presne popísaný postup, viď. dokument SP Riadenie údajov.
Dôležité je, že tentokrát so zvoleným prístupom súhlasili všetci kľúčoví správcovia údajov, na rozdiel od pokusu o “centrálny register” ala CSRÚ.
Čiže:

  • centrálny register/úložisko: nie
  • správa master údajov: každý úrad u seba to čo má referenčné
  • centrálny komponent na G2G prístup k údajom: áno, centrálny IS, jednotné API, jednotný dátový model
  • riadenie prístupu: základný level “aký úrad môže vidieť aký typ údajov na aký účel” centrálne, detailný level poskytovateľ údajov u seba
  • kto môže mať aké dáta: aké komu zákon umožňuje
2 Likes

Skusim este moj pohlad k tomu pridat: Centralizacia uloziska dat by znamenala:

a) ze bude musiet existovat nejaky standard pre to ako tam tie data tlacit
b) bude kazdy jeden dataset change request na centralne ulozisko (znie to ako vtip, ale to je napriklad dnes realita v CSRU

a) podla mna je problem, bude z toho metametadatastore co mne v praxi nikdy dobre nefungovalo. b) je zlata bana pre dodavatela.

Dalsi problem je, ze spravu dat realne dnes riesi nejake OVM, ten co ma na starosti zdrojovy register.

Moja predstava ako toto moze fungovat:

  • Mame centralny bod, ktory udeluje prava na pristup k datam, loguje/audit, sprava pristupov z pohladu pouzivatela, etc.
  • Mame proxy (ala rejoiner), do ktoreho sa zdrojove/referencne registre registruju a cez standardne API vystavuju sluzby na pristup k datam. Cez nejake GraphQL-like API potom toto proxy dokaze vyskladat query pre data aj z viacerych zdrojov (ak to naozaj treba). Vid moj prispevok tu
  • Mame event bus (volajme to pracovne kafka), na ktory pri zmene zaznamu v zdrojovom registri vypublikujeme event (zmena trvaleho bydliska osoby bifo123). Tento event bus posle do systemov, ktore na taketo eventy pocuvaju (tie si na oplatku potiahnu data z ref registrov ak treba, napriklad aj cez centralne proxy)

Art. 25 GDPR Data protection by design and by default

skoda ze v predmetnej studii nie je vysvetlene ako sa tieto principy v rieseni dodrzia.

Je predpokladom tohto riesenia to, ze vsetky data rozsekas na disjunktne datasety cim vytvoris master udaje v zodpovednosti daneho ISVS?

Prosím napíš presnejšie, čo vidíš s ochranou osobných údajov ako nevyjasnené.

implementacia poziadaviek GDPR (kedy, kto, ako, za co). Magicke slovne spojenie “bezpecnostny projekt” v tomto pripade zdaleka nevyriesi vsetko co treba. Ani zdaleka.

1 Like

No veď “dokument bezpečnostného projektu” nebol hlavná vec ani doteraz.
Ale ak chceš naznačiť, že by pre OVM mohol existovať návod ako riešiť GDPR, najmä pre existujúce systémy - kde bude najväčší problém “kedy a za čo” - tak plne súhlasím.

Mozno som nepochopil kde je problem ale toto mi pride ako klasicka korporatna cmdb kde su natlacene vsemozne firemne data na jedno miesto a ked nieco potrebujes vsetko tam najdes…co je na tom zle?

Je k tomu aj seriozna bezpecnostna analyza? Lebo naozaj je tam opravnene podozrenie, ze bezpecnost nemusi byt ovela lepsia ako pri centralnom registry (a mozno dokonca aj horsia).

Je k tomu analyza z pohladu ochrany osobnych udajov? Lebo je iste, ze urady budu data kopirovat/cachovat a dlhodobo uchovavat (kto tvrdi opak tak v zivote asi ziadne IDM nerobil). Ako budu fungovat korekcie/erasure na tych kopiach?

Nechcem pocut detaily. Aj tak by som nestihol s tym nic urobit. Len by som rad vedel, ze sa tomu niekto naozaj seriozne venoval. Oba tieto problemy su potencionalne tvrdy showstopper a mozu spustit kompletny redesign architektury. A na prvy pohlad vobec nie su zrejme. Tak ja len preto.

Pozri si trebars toto:

http://www.mzcr.cz/legislativa/dokumenty/metodika-implementace-gdpr_14674_11.html

Taketo nieco by som u nas cakal od NCZI.

1 Like

Mimochodom, “jednotny datovy model” moze tiez narobit viac skody ako uzitku. Najma v IDM. Lebo napriklad komunita sa snazi uz viac ako 20 rokov o standardizaciu spolocneho datoveho modelu pre tak “komplikovanu” vec ako je bezny internetovy account. Pokusov bolo vela (napr. inetOrgPerson, FOAF, SCIM). A ani jeden presvedcivy uspech. Podobne je to s API (LDAP, DSML, rozne semi-proprietarne, SPML1, SPML2, SCIM). Tu su male uspechy, ale snad nikto tie API nepouziva v cistej forme. Interoperabilita je zufala.

Aj v semi-uzatvorenych informacnych systemoch je to podobne. Za tie roky niekolko zakaznikov skusalo aplikovat spolocny datovy model a API pre IDM (aj napriek nasim radam). Vsetky riesenia boli problematicke, ziadne z nich nebolo uplne uspesne.

Na toto pozor. V tejto oblasti je navrh riesenia dost neintuitivny. Teorie vyzeraju pekne vo velkych analytickych dokumentoch. Ale malo kedy naozaj funguju. Tu treba mat napamati hlavne limitacie riesenia. Toto vyzaduje skusenosti. Vela skusenosti.

1 Like

Asi nie uplne rozumiem.

Ide o to, ze momentalny stav je taky, ze napr. data o subjekte sa nachadzaju na viacerych miestach, vo viacerych zdrojoch. Ako docielis stav, ze kazdy bude mat v zodpovednosti len tu svoju cast a konflikty pri prienikoch budu odstranene? Viem si to totiz predstavit stavat z bodu nula, ako to vsak implementovat do aktualneho stavu?

Vies priklad? Ja tam vidim dve veci:

  1. To co napriklad riesilo RPO - pravnicke osoby boli rozhadzane kadetade po roznych registroch (a stale este nejake su) ale RPO ich postupne integruje na jedno miesto.
  2. To, ze o nejakom subjekte su informacie na viac miestach podla mna nevadi. To je pointa referencnych udajov predsa. Ak mam napr v RPO odkaz na adresny bod a ulica sa premenuje, tak RPO by to nemalo nijako trapit, kedze tam ma mat vo finale len referenciu do registra adries.

Ci vidis este nejaku inu moznost?

skus priklad, pretoze toto je riesene cez referencne registre. Ak teda chces udaje o osobe, tak sa pozries do RFO, ak o pravnickej osobe tak do RPO, Prakticky pre dalsie udaje dochadza k nejasnostiam ale zodpovednost za ich vedenie je jasna zo zakona.

to je jasne, to je cielovy stav, mat to prelinkovane a nedrzat u seba veci, za ktore nie som zodpovedny, ale len identifikator. Skor som smeroval k tomu, ze ci bude vzdy zrejme za co je kto zodpovedny, aby si vedel povedat, ze tieto udaje su tie referencne a tieto su redundantne a mozu sa povedzme zahodit. Predstavujem si to totiz ako velku organizaciu, s roztrusenymi udajmi, kde existuju konflikty. Ako budu tieto konflikty odstranene?