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:
- 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.
- 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?
toto naraza na technicke problemy, linkovat sa externe systemy vzdy znamena oneskorenie a pomerne vyznamne spomalenie. a s rizikom ze ked je externy vypadok jedneho klucoveho systemu tak prestanu fungovat vsetky systemy. priklad ako je navrhnute rfo: vytvoris si vlastnu databazu osob pre tvoj system, ktoru pouzivas a rfo oznamis ze toto su tvoje zaujmove osoby, pri zmene udajov ti rfo posle informaciu ze sa zmenili ich udaje.
to uz je len na technickej realizacii, ci si budes u seba drzat aj sync udajov, ktore ta zaujimaju, z overall pohladu je to irelevantne.
ako je to vymyslene si to viem predstavit, ze by design to moze krasne fungovat ak to postavim na zelenej luke. neviem si vsak predstavit prejst z aktualneho stavu do tohto cieloveho stavu. ale mozno je naozaj cely problem len v legislativnej rovine a staci povedat co je a co nie je referencne.
to je legislativne jasne, problem je v tom aby tie udaje boli spravne. a za referencnym registrom su este zdrojove registre kde sa ta zmena realne deje. pre rfo su to primarne matriky ale teba ako uzivatela udajov nezaujimaju, na ne sa nevies pripojit.
Prechodny stav (ktory mimochodom bude trvat do nekonecna) si predstavujem takto (@lubor nech ma opravi, uz sme to riesili):
- mam u seba nejaku databazu/tabulku, kde su povedzme pravnicke osoby. nemam to napojene na nic.
- do tabulky pridam stlpec ktory bude ref. identifikator PO. (RPO je referencny, teda by mal existovat jednoznacny ref. identifikator - haha)
- postupne musime robit stotoznovanie/prepajanie dat svojej db a referencneho registra. proste k mojmu zaznamu napr. OZ slovensko.digital pridam do noveho stlpca URI http://data.gov.sk/legalsubject/123
- V tom momente mozem tie povodne data zahodit alebo prestat proste pouzivat.
- Toto robim do nekonecna.
1 Like
a nestroskota to uz hned tu? 
Inak podobne je na tom RFO.
ciste prakticky ak to urobis tak ze noveho stotoznis a mas proceduru ktora vykona zmeny po tom ako ti oznami rfo tak sa dalej nemusis starat. a ked budes tlacit obalku s adresou a menom, tak nebudes musiet chodit do rfo
To uz je dalsi krok, je uplne jasne, ze v realite budes musiet tahat tie data aj k sebe, lebo napriklad pre vyhladavanie, zobrazovanie na mape, filtrovanie… potrebujes mat u seba aj tie data, nie len uri na iny register. Synchronizacia moze fungovat vseliako, zalezi od toho na co sa to pouziva.
iste a navyse je zavisla od logiky tvojej aplikacie. ked dnes podavas danove priznanie za minuly rok tak potrebujes nazov firmy za minuly rok a nie dnesny napr. a to nehovorim este o realite ze ak zacnes rfo dotazovat prilis extenzivne tak ta bloknu, kedze to vykonovo nezvladnu. spravny navrh by teda mal uvazovat rfo ako asynchronne pripojenie
1 Like
Ako to tu sledujem, tak z podhladu IDM inziniera som zhrozeny. Mam dojem, ze malo kto z vas si uvedumoje ake tazke problemy tam budu (e.g. “synchronizacia je irelevantna”, korelacia, migracia, konzistencia udajov, negativne scenare).
Na druhej strane, z pohladu IDM vendora sa tesim. Lebo kazdy jeden urad bude potrebovat poriadny IDM system. Bude dobry business.
to si teraz vytrhol z kontextu