Skjermbildepersonopplysninger i interne kunnskapsbaser
Interne kunnskapsbaser - Confluence, Notion, SharePoint, GitBook - inneholder en spesifikk type personopplysningsproblem som standard samsvarsverktoy overser: personopplysninger om kunder nedfelt i skjermbilder brukt i prosessdokumenter.
Monsterert spiller seg ut pa tvers av tusenvis av support- og driftsteam.
En supportagent finner et uvanlig kontookpsett. De tar et skjermbilde av kundens kontoside for a dokumentere problemet. Skjermbildet viser kundens navn i UI-overskriften, e-posten i kontoinnstillingene og plandetaljene.
Artikkelen publiseres i den interne kunnskapsbasen. Ett hundre og femti supportagenter kan na se den. Tolv leverandorer pa den eksterne helpdesken kan ogsa se den. Artikkelen er nyttig. Den viser hvordan man handterer det kanttilfelle. Hver agent som stoter pa det oppsettet i fremtiden vil lese det.
Tre ar senere inneholder kunnskapsbasen 847 slike artikler. Hver inneholder skjermbilder av kundekontoer. Kundene som vises ga ikke samtykke til denne sekundaere bruken av journalene sine. De fleste vet ikke at dataene deres er lagret der.
Dette er ikke et lite problem. Det vokser med hver ny artikkel.
GDPR-eksponering: Hvorfor dette er viktig
GDPR-analysen for kunnskapsbaseskjermbilder er direkte.
Dataminimering (Artikkel 5(1)(c)): Personopplysninger ma vaere "tilfredsstillende, relevante og begrenset til det som er nodvendig." En kunnskapsbaseartikkel om kontokonfigurasjon trenger ikke kundens ekte navn og e-post. Et uskarpet skjermbilde tjener formalet like bra. A inkludere live-kundedata er ikke nodvendig.
Formalsbegrensning (Artikkel 5(1)(b)): Data samlet inn for ett formal - kundeservice - kan ikke gjenbrukes til et annet formal - interne prosessdokumenter - uten et rettslig grunnlag. Kontoregistre ble samlet inn for levering av tjenester, ikke for intern dokumentasjon. Dette er to forskjellige behandlingsformater. Bruk av de samme registrene for begge krever et gyldig rettslig grunnlag som de fleste team ikke har etablert.
Tilgangskontroll (Artikkel 5(1)(f) og Artikkel 32): Hensiktsmessige tekniske tiltak ma beskytte personopplysninger. Kundekontoskjermbilder i et verktoy apent for alle 150 agenter og leverandorer - inkludert de uten tilgang til det underliggende kontosystemet - skaper altfor bred tilgang.
Rett til sletting (Artikkel 17): En registrert som ber om sletting har rett til a fa sine journaler fjernet "uten unnodig forsinkelse." Hvis dataene deres finnes i 23 kunnskapsbaseartikler som innebygde skjermbilder, krever foresporselen at alle 23 artiklene finnes og oppdateres. Det er vanskelig uten et system. Var GDPR-rett-til-slettingsguide dekker trinnene i detalj.
Ingen av disse er tolkninger i kanttilfeller. De er direkte anvendelser av reguleringsteksten pa en vanlig praksis.
Omgaelse av tilgangskontroll
Det alvorligste samsvarsproblemet med Confluence-skjermbilder er omgaelsen av tilgangskontroll de skaper.
Supportteam bruker rollebasert tilgangskontroll (RBAC) for a begrense hvem som kan se kundekontoer. Niva 1-agenter ser grunnleggende kontoopplysninger. Niva 2-agenter ser fakturering og tekniske poster. Ledere ser den fullstendige kontoprofilen.
Nar en Niva 2-agent oppretter en kunnskapsbaseartikkel med et skjermbilde av den fulle kundekontoen, blir det skjermbildet synlig for alle brukere av verktoytet. Niva 1-agenter som ikke bor se faktureringsdata kan na se dem. Leverandorer uten systemtilgang kan se dem. Nyansatte i onboarding kan se dem.
Skjermbildet omgar RBAC-kontrollene pa kundekontotsystemet. De personopplysningene RBAC ble bygget for a beskytte er na apne for alle med tilgang til kunnskapsbasen.
Dette er ikke en teoretisk risiko. Det er det normale resultatet av dokumentasjonsarbeidsflyten. Skjermbildet ligger der uten utlop, uten tilgangslogg og uten revisjonsspor.
Praktiske utbedringstiltak
For team som oppdager dette problemet under en GDPR-revisjon:
Retroaktiv utbedring:
- Identifiser alle kunnskapsbasesider med bildevedlegg
- Kjor bilde-personopplysningsdeteksjon pa alle vedlegg
- Gjennomga flaggede bilder: treff med hoy konfidens gar til gjennomgangskoen
- For hvert flagget bilde: erstatt med en rengjort versjon eller begrens sidetilgang
- Loggfor utbedringstiltak for GDPR-poster
Omfanget av retroaktivt arbeid avhenger av kunnskapsbasens storrelse. For en tre ar gammel kunnskapsbase hos et 50-persons supportteam kan bildeantallet na tusenvis. Batch-bildebehandling gjor dette gjennomforbart. Menneskelig gjennomgang av flaggede bilder er den viktigste flaskehalsen.
Fremadrettede kontroller:
- Laer opp alt supportpersonell til a rense skjermbilder for publisering til kunnskapsbasen
- Tilby verktoy: skjermbildeannoteringsverktoy som slorer kundenavn for liming
- Legg til et gjennomgangstrinn: en utpekt gjennomgar sjekker artikler for publisering, spesifikt for kunde-PII i bilder
- Kjor en kvartalsmessig batch-bildesjekk pa alle Confluence-vedlegg
Minimalt gjennomforbar kontroll: En publiseringssjekkliste: "Fjern eller sloer alle kundenavn, e-poster og konto-ID-er fra skjermbilder for publisering." Lavteknologisk, ikke-automatisert, men det skaper en dokumentert kontroll. For sma team er dette utgangspunktet.
Se var GDPR-samsvarsoverikt for det bredere juridiske rammeverket, og hvorfor policy uten tekniske kontroller svikter for hvorfor kun sjekklistebaserte tilnarmlinger bryter sammen ved skala.
Hvorfor problemet vokser over tid
Uten systematiske kontroller kompliseres kunnskapsbase-personopplysningseksponering.
Volum: Hver ny artikkel med et kundeskjermbilde legger til den totale eksponeringen. Nar supportteamet vokser og kunnskapsbasen utvides, vokser de akkumulerte personopplysningene ogsa. Egenskapene som gjor disse verktoyene nyttige - publiseringsease, varighet, bred tilgang - er det som gjor personopplysningsproblemet verre.
Glemte artikler: Artikler om gamle kanttilfeller som ikke lenger dukker opp forblir tilgjengelige. De inneholder personopplysninger fra kunder som siden har sendt inn slettingsforesporsler. Ingen sjekker en artikkel sist oppdatert i 2022.
Spredt pa tvers av team: Kunnskapsbaser gar ofte pa tvers av funksjoner. En supportartikkel med kundeskjermbilder kan deles med produktteamet, ingeniortteamet eller eksterne leverandorer for kontekst pa en funksjonsforesporse eller feilrapport. Hvert deling utvider publikum for personopplysningene.
Slettingsetterskudd: Etter hvert som flere kunderegistre samler seg i kunnskapsbasen, blir svar pa slettingsforesporsler mer komplekse. Uten et system er det ingen palikig mate a bekrefte at hvert tilfelle av en registrerts data er funnet og fjernet. Teamet kan ikke lage en troverdig sletteattestasjon.
Kunnskapsbase-personopplysninger er lettere a forebygge enn a reparere. Kontroller innfort na unnga det akkumulerende utbedringsproblemet. Hver artikkel publisert uten et uskarpet skjermbilde er en utbedringsoppgave utsatt til fremtiden.