Det blinde punktet i DLP som du ikke har revidert
DLP-verktoy overvaker nettverkstrafikk, e-postfiler og filoverforinger. De fanger opp regneark med personnummerkolonner. De flagger e-poster med kundelister. De blokkerer opplastinger med sykejournaler.
De fanger ikke opp skjermbilder.
Et skjermbilde er en bildefil. Personopplysningene i det er tegnet som piksler. De lagres ikke som tekst. DLP-motorer som skanner etter personopplysningsmonstre finner ingenting.
Hver dag limer ansatte inn skjermbilder i Slack, Jira, Teams og e-postkjeder. Ingen DLP-varsler utloses.
Hvordan skjermbilder sprer personopplysninger pa jobben
Fjernarbeid og hybridarbeid har gjort deling av skjermbilder vanlig. Interne verktoy fylles med dem hver dag.
Teammedlemmer deler skjermbilder for rask kontekst:
- Supportagenter tar opp kundekontovisninger for a dele med teamledere.
- Utviklere deler feillogger som inneholder brukerregistrerte data.
- Kundeansvarlige sender CRM-poster for a gi kontekst til okonomiteamet.
- IT-administratorer tar opp systemvisninger for a dokumentere oppsett for leverandorer.
- Produktteam deler dashboardvisninger i oppdateringer til interessenter.
Hvert vedlegg kan inneholde personopplysninger. Et skjermbilde av en kundekonto inneholder navn, e-post, status og faktureringsadresse. En feiloggfil kan inneholde navn, adresser eller telefonnumre lagt inn av brukere. Et CRM-postskjermbilde inneholder hele kontoprofilen. En dashboardfil kan vise bruker-ID-er i diagrametiketter.
Tilgangskontrollproblemet
Deling av skjermbilder skaper ogsa et tilgangskontrollproblem.
De fleste organisasjoner handhever rollebaserte tilgangskontroller pa produksjonssystemer. En supportagent ser bare sine koposster. En leverandor ser bare tildelte prosjektfiler.
Nar en agent tar opp en kundepost og limer den inn i en Slack-kanal med leverandorer, omgar tilgangskontroll. Leverandoren far personopplysninger de ikke kunne na gjennom normale veier. DPA-en for leverandorarbeid dekker kanskje ikke denne overforing. Kundens GDPR-rettigheter gjelder kanskje ikke for den leverandoren.
Dette er et GDPR Artikkel 5(1)(f)-sporsmal. Det dekker integritet og konfidensialitet. Det kan ogsa skape Artikkel 28-justeringsproblemer hvis leverandorer far personopplysninger uten riktige DPA-er. Se var GDPR-samsvarsguide for en sjekkliste over Artikkel 28-plikter.
Bilde-personopplysningsdeteksjon som teknisk sikkerhetstiltak
Det tekniske sikkerhetstiltaket for eksponering av personopplysninger via skjermbilder er OCR kombinert med NLP-deteksjon. Trinnene er enkle.
- Ansatt tar et skjermbilde av et kundegrensesnitt.
- For deling: laster opp skjermbildet til et deteksjonsverktoy.
- Verktoy trekker ut synlig tekst via OCR.
- NLP finner personopplysningsenheter i teksten.
- Den ansatte ser en rapport: "Dette skjermbildet inneholder: [kundenavn], [e-postadresse], [konto-ID]."
- Den ansatte redigerer deretter personopplysningene, innsnevrer delingsomfanget eller fortsetter med en skriftlig begrunnelse.
Dette blokkerer ikke all deling. Det viser personopplysningene for de flyttes. Folk kan da ta informerte valg. Se hvordan dette passer inn i din beskyttelsesstack pa sikkerhetssiden.
Brukstilfelle: SaaS helpdesk Jira-skjermbildepolicy
Et SaaS-selskaps helpdesk brukte Jira til a logge kontoproblemer. Filer vedlagt disse billettene inneholdt bruker-PII. Naermere bestemt:
- Brukeres e-postadresser fra kontobehandlingsskjermer.
- Abonnementsplandetaljer.
- Faktureringsbelop og datoer.
- Delvis betalingsdata i noen tilfeller.
En GDPR-revisjon fant 847 Jira-billetter opprettet over 18 maneder. Alle hadde vedlegg med personopplysninger. Jira var apent for alle 200 ingeniorer. Noen var leverandorer uten DPA-er for kundefaktureringsdata.
Utbedringstiltak:
- Retroaktiv revisjon: personopplysningsdeteksjon pa alle eksisterende vedlegg. 312 billetter flagget for DPO-gjennomgang.
- Billettopprydding: 89 billetter fikk filer skjult for ny tilknytning.
- Prosessendring: ny arbeidsflyt som krever personopplysningstsjekk for Jira-vedlegg.
- Opplaering: 15-minutters okten for alt helpdesk-personell.
Resultater etter 90 dager:
- Personopplysningshendelser i Jira: ned 90 prosent.
- Gjenvaerende hendelser: tilfeller der personell fortsatte med en skriftlig diagnostisk begrunnelse.
- DPA-omfang: oppdatert for a redusere unnodig eksponering av personopplysninger for leverandorer.
De 312 historiske billettene var et samvarsfunn. Nedgangen pa 90 prosent fungerte som bevis pa utbedring i revisjonssvaret.
Integrering av skjermbildekontroll i teamarbeidsflyter
For organisasjoner som vil ha personopplyningskontroller uten a bremse operasjoner, finnes det flere alternativer.
Lettvedsalternativ: Et nettleserverktoy ansatte bruker for liming i Slack eller Jira. Dra skjermbildet, fa en personopplysningsrapport pa fem sekunder, og fortsett eller rediger.
Jira eller ServiceNow-tilkobling: Deteksjon som kjoerer for filer nar billetter. Det fungerer som virusskanning for filopplasting.
Slack-bot: En bot som mottar skjermbildeopplastinger i valgte kanaler. Den kjoerer personopplysningsdeteksjon. Den sender et tradsvar med oppdagede enheter. Dette gjor personopplysninger synlige uten a blokkere arbeidsflyten.
Teamnorm pluss stikkprover: En ukentlig automatisert sjekk. Ta stikkprove av 10 prosent av skjermbilder i samarbeidsverktoy. Kjor deteksjon. Rapporter funn til teamleder. Dette skaper ansvar uten a blokkere noen arbeidsflyt.
For GDPR-poster: kontrollen for personopplysninger i skjermbilder teller som et "organisatorisk tiltak" under Artikkel 32. Dokumenter sikkerhetstiltaket - policy pluss teknisk verktoy. Legg til bevis for bruk. Dette oppfyller Artikkel 5(2)-ansvarlighetskravet. Se var samsvarsside og ordbokelementet for Artikkel 32.
Vil du se hvordan anonym.legal hndterer dette for ditt team? Besok planssiden vaar eller les grunnleggerens uttalelse om de-identifisering.
Kilder
- GDPR Artikkel 5: Prinsipper for databehandling. VERIFIED-EXTERNAL.
- GDPR Artikkel 32: Sikkerhet ved behandling. VERIFIED-EXTERNAL.
- ICO: Databeskyttelse ved design og standard. VERIFIED-EXTERNAL.