Licni podaci snimaka ekrana u internim bazama znanja
Interne baze znanja — Confluence, Notion, SharePoint, GitBook — sadrze specificnu vrstu problema sa licnim podacima koji standardni compliance alati propustaju: licni podaci klijenata ugradjen u snimcima ekrana koji se koriste za dokumenta o procesima.
Obrazac se odvija u hiljadama timova za podrsku i operacije.
Agent podrske pronalazi neobicnu postavku naloga. Pravi snimak ekrana stranice naloga klijenta da dokumentuje problem. Snimak prikazuje korisnikovo ime u zaglavlju korisnickog interfejsa, njihov imejl u podesavanjima naloga i detalje plana.
Clanak ide uzivo u internoj bazi znanja. 150 agenata podrske moze sada da ga vidi. Dvanaest ugovaraoca na eksternom helpdesku moze takodje da ga vidi. Clanak je koristan. Pokazuje kako da se resi taj rubni slucaj. Svaki agent koji u buducnosti nadje tu postavku procitace ga.
Tri godine kasnije, baza znanja sadrzi 847 takvih clanaka. Svaki sadrzi snimke korisnickih naloga. Prikazani klijenti nisu pristali na ovu sekundarnu upotrebu svojih zapisa. Vecina ne zna da su njihovi podaci tamo sacuvani.
Ovo nije mali problem. Raste sa svakim novim clankom.
GDPR izlozenost: Zasto je ovo vazno
GDPR analiza za snimke ekrana u bazama znanja je direktna.
Minimizacija podataka (clan 5(1)(c)): Licni podaci moraju biti "adekvatni, relevantni i ograniceni na ono sto je neophodno." Clanak u bazi znanja o postavci naloga ne treba pravo ime i imejl klijenta. Zamagljeni snimak sluzi svrhi jednako dobro. Ukljucivanje aktuelnih korisnickih podataka nije neophodno.
Ogranicenje svrhe (clan 5(1)(b)): Podaci prikupljeni za jednu svrhu — korisnicka usluga — ne mogu se ponovo koristiti za drugu svrhu — interna procesna dokumenta — bez zakonitog osnova. Zapisi o nalozima prikupljeni su za isporuku usluge, ne za internu dokumentaciju. Ovo su dve razlicite svrhe obrade. Koristenje istih zapisa za obe zahteva valjani zakoniti osnov koji vecina timova nije uspostavila.
Kontrola pristupa (clan 5(1)(f) i clan 32): Odgovarajuce tehnicke mere moraju da stite licne podatke. Snimci korisnickih naloga u alatu otvorenom za svih 150 agenata i ugovaraoca — ukljucujuci one bez pristupa osnovnom sistemu naloga — stvaraju prestroko sirok pristup.
Pravo na brisanje (clan 17): Subjekt podataka koji zahteva brisanje ima pravo da se njegovi zapisi uklone "bez nepotrebnog odlaganja". Ako se njihovi podaci pojavljuju u 23 clanaka baze znanja kao ugradjenni snimci, zahtev zahteva pronalazenje i azuriranje svih 23 clanaka. To je tesko bez sistema. Nas vodic za GDPR pravo na brisanje pokriva korake u detalju.
Nijedan od ovih nije rubno citanje. To su direktne primene teksta regulative na uobicajenu praksu.
Zaobilazenje kontrole pristupa
Najozbilijni compliance problem sa Confluence snimcima je zaobilazenje kontrole pristupa koje stvaraju.
Timovi podrske koriste kontrolu pristupa zasnovanu na ulogama (RBAC) da ogranice ko moze da vidi sisteme korisnickih naloga. Agenti prvog nivoa vide osnovne detalje naloga. Agenti drugog nivoa vide zapise o naplati i tehnicke zapise. Menaderi vide potpuni profil naloga.
Kada agent drugog nivoa kreira clanak u bazi znanja sa snimkom kompletnog korisnickog naloga, taj snimak postaje vidljiv svakom korisniku alata. Agenti prvog nivoa koji ne bi trebalo da vide zapise o naplati sada mogu da ih vide. Ugovaraci bez sistemskog pristupa mogu da ih vide. Novi zaposleni u uvodjenju mogu da ih vide.
Snimak zaobilazi RBAC kontrole na sistemu korisnickih naloga. Licni podaci koje je RBAC bio namijenjen da stiti sada su otvoreni svima sa pristupom bazi znanja.
Ovo nije teorijski rizik. To je normalan ishod radnog toka dokumentacije. Snimak stoji tamo bez isteka roka, bez evidencije pristupa i bez revizijskog traga.
Prakticni koraci remedijacije
Za timove koji pronadju ovaj problem tokom GDPR revizije:
Retroaktivna remedijacija:
- Identifikujte sve stranice baze znanja sa prikazima slika
- Pokrenite detekciju licnih podataka na svakom prilogu
- Pregledajte oznacene slike: rezultati visoke pouzdanosti idu u red za pregled
- Za svaku oznacenu sliku: zamenite sanitizovanom verzijom ili ogranicite pristup stranici
- Evidentirajte akcije remedijacije za GDPR zapise
Obim retroaktivnog rada zavisi od velicine baze znanja. Za bazu znanja staru tri godine u 50-osobnom timu podrske, broj slika moze da dosegne hiljade. Batch obrada slika ovo cini izvodljivim. Manuelni pregled oznacenih slika je kljucno usko grlo.
Proaktivne kontrole:
- Obucite sve osoblje podrske da sanitizuje snimke ekrana pre objavljivanja u bazu znanja
- Obezbedite alate: alate za anotaciju snimaka koji zamagljuju korisnicka imena pre lepljenja
- Dodajte korak pregleda: odredjeni recenzent proverava clanke pre objavljivanja, posebno trazeci klijentske licne podatke u slikama
- Pokrecite kvartalnu batch skeniranje slika na svim Confluence prillozima
Minimalna izvodljiva kontrola: Kontrolna lista za objavljivanje: "Uklonite ili zamaglite sva korisnicka imena, imejlove i ID-ove naloga sa snimaka pre objavljivanja." Nisko-tehnoloska, ne-automatizovana, ali kreira dokumentovanu kontrolu. Za male timove, ovo je polazna tacka.
Pogledajte nas pregled GDPR usaglasenosti za siri pravni okvir, i zasto politika bez tehnickih kontrola ne uspeva za objasnjenje zasto pristupi zasnovani samo na kontrolnoj listi pucaju na velikom obimu.
Zasto problem raste tokom vremena
Bez sistemskih kontrola, izlozenost licnih podataka u bazi znanja se kumulira.
Obim: Svaki novi clanak sa snimkom korisnika dodaje ukupnoj izlozenosti. Kako tim podrske raste i baza znanja se siri, kumulirani licni podaci takodje rastu. Osobine koje ove alate cine korisnim — lako objavljivanje, trajnost, sirok pristup — su ono sto PII problem cini gorim.
Zaboravljeni clanci: Clanci o starim rubnim slucajevima koji se vise ne pojavljuju ostaju dostupni. Sadrze licne podatke klijenata koji su od tada podneli zahteve za brisanje. Niko ne proverava clanak koji je zadnji put azuriran 2022.
Sirenje kroz timove: Baze znanja cesto postaju kros-funkcionalne. Clanak podrske sa snimcima klijenata moze biti podeljen sa timom za proizvode, inzenjerskim timom ili eksternim ugovaracima radi konteksta o zahtevu za funkciju ili izvestaju o greski. Svako deljenje siri publiku za licne podatke.
Zaostaoci zahteva za brisanje: Kako se vise korisnickih zapisa nagomilava u bazi znanja, odgovaranje na zahteve za brisanje postaje kompleksnije. Bez sistema, ne postoji pouzdan nacin da se potvrdi da je svaka instanca zapisa subjekta podataka pronadjena i uklonjena. Tim ne moze da da verodostojnu potvrdu brisanja.
Licni podaci u bazi znanja su laksi za spreciti nego za popraviti. Kontrole uspostavljene sada izbegavaju problem kumulativne remedijacije. Svaki clanak objavljen bez zamagljenog snimka je zadatak remedijacije odlozen za buducnost.