Screenshot PII sa mga Internal na Knowledge Base
Ang mga internal na knowledge base — Confluence, Notion, SharePoint, GitBook — ay nagtatago ng isang partikular na uri ng problema sa PII na hindi nakikita ng mga karaniwang tool sa compliance: personal na datos ng customer na nakabaon sa mga screenshot na ginagamit para sa mga doc ng proseso.
Naglalaro ang pattern na ito sa libu-libong support at operations team.
Nakatuklasan ang isang support agent ng isang kakaibang setup ng account. Kumukuha sila ng screenshot ng pahina ng account ng customer para idokumento ang isyu. Ipinapakita ng screenshot ang pangalan ng customer sa UI header, ang kanilang email sa mga setting ng account, at ang kanilang mga detalye ng plano.
Nabubuhay ang artikulo sa internal na knowledge base. Maaari na itong tingnan ng isang daan at limampung support agent. Maaari rin itong tingnan ng labindalawang kontratista sa external helpdesk. Kapaki-pakinabang ang artikulo. Ipinapakita nito kung paano hawakan ang edge case na iyon. Ang bawat agent na makakatagpo ng setup na iyon sa hinaharap ay magbabasa nito.
Tatlong taon na ang nakalipas, ang knowledge base ay nagtatago na ng 847 tulad na mga artikulo. Ang bawat isa ay naglalaman ng mga screenshot ng mga account ng customer. Ang mga customer na ipinakita ay hindi nagbigay ng pahintulot sa pangalawang paggamit na ito ng kanilang mga rekord. Karamihan ay hindi alam na nakaimbak doon ang kanilang datos.
Ito ay hindi isang maliit na problema. Lumalaki ito sa bawat bagong artikulo.
Pagkakalantad sa GDPR: Bakit Ito Mahalaga
Ang pagsusuri ng GDPR para sa mga screenshot ng knowledge base ay direkta.
Data minimization (Article 5(1)(c)): Ang personal na datos ay dapat na "sapat, may kaugnayan, at limitado sa kung ano ang kinakailangan." Ang isang artikulo ng knowledge base tungkol sa setup ng account ay hindi nangangailangan ng totoong pangalan at email ng customer. Ang isang blurred na screenshot ay nagsisilbi sa layuning iyon nang kasinghusay. Ang pagsasama ng live na datos ng customer ay hindi kinakailangan.
Purpose limitation (Article 5(1)(b)): Ang datos na nakolekta para sa isang layunin — serbisyo sa customer — ay hindi maaaring muling gamitin para sa isa pang layunin — mga panloob na doc ng proseso — nang walang legal na batayan. Ang mga rekord ng account ay nakolekta para sa paghahatid ng serbisyo, hindi para sa panloob na dokumentasyon. Ang mga ito ay dalawang magkaibang layunin ng pagpoproseso. Ang paggamit ng parehong mga rekord para sa pareho ay nangangailangan ng isang valid na legal na batayan na hindi pa naitatayo ng karamihan ng mga team.
Access control (Article 5(1)(f) at Article 32): Ang mga angkop na teknikal na hakbang ay dapat protektahan ang personal na datos. Ang mga screenshot ng account ng customer sa isang tool na bukas sa lahat ng 150 agent at kontratista — kasama ang mga walang access sa pinagbabatayan na sistema ng account — ay lumilikha ng masyadong malawak na access.
Right to erasure (Article 17): Ang isang data subject na humihiling ng erasure ay may karapatang alisin ang kanilang mga rekord "nang walang mawalang pagkaantala." Kung ang kanilang datos ay lumilitaw sa 23 na artikulo ng knowledge base bilang mga nakabaong screenshot, ang kahilingan ay nangangailangan ng paghanap at pag-update ng lahat ng 23 artikulo. Mahirap iyon nang walang sistema. Sinasaklaw ng aming GDPR right-to-erasure guide ang mga hakbang nang detalyado.
Wala sa mga ito ang mga edge-case na interpretasyon. Ang mga ito ay mga direktang aplikasyon ng teksto ng regulasyon sa isang karaniwang gawi.
Ang Access Control Bypass
Ang pinaka-seryosong isyu ng compliance sa mga screenshot ng Confluence ay ang access control bypass na nililikha nila.
Gumagamit ang mga support team ng role-based access control (RBAC) para limitahan kung sino ang makakatingin sa mga sistema ng account ng customer. Nakikita ng mga Tier 1 agent ang mga pangunahing detalye ng account. Nakikita ng mga Tier 2 agent ang mga rekord ng billing at teknikal. Nakikita ng mga manager ang buong profile ng account.
Kapag gumawa ang isang Tier 2 agent ng isang artikulo ng knowledge base na may screenshot ng buong account ng customer, ang screenshot na iyon ay nagiging makikita ng bawat user ng tool. Ang mga Tier 1 agent na hindi dapat makakita ng mga rekord ng billing ay maaari na itong tingnan. Ang mga kontratistang walang access sa sistema ay maaari na itong tingnan. Ang mga bagong staff sa onboarding ay maaari na itong tingnan.
Nilalampasan ng screenshot ang mga kontrol ng RBAC sa sistema ng account ng customer. Ang personal na datos na itinayo ng RBAC para protektahan ay bukas na ngayon sa lahat ng may access sa knowledge base.
Ito ay hindi isang teoretikal na panganib. Ito ang normal na resulta ng workflow ng docs. Ang screenshot ay nandoon na walang expiry, walang access log, at walang audit trail.
Mga Praktikal na Hakbang sa Remediation
Para sa mga team na natutuklasan ang problemang ito sa isang GDPR audit:
Retroactive remediation:
- Tukuyin ang lahat ng pahina ng knowledge base na may mga attachment ng imahe
- Patakbuhin ang image PII detection sa bawat attachment
- Suriin ang mga naka-flag na imahe: ang mga high-confidence na hit ay pumupunta sa review queue
- Para sa bawat naka-flag na imahe: palitan ng sanitized na bersyon o bawasan ang access sa pahina
- I-log ang mga aksyon sa remediation para sa mga rekord ng GDPR
Ang sukat ng retroactive na gawain ay nakasalalay sa laki ng knowledge base. Para sa isang tatlong-taong-gulang na knowledge base sa isang 50-taong support team, ang bilang ng imahe ay maaaring umabot sa libu-libo. Ginagawa ng batch image processing na posible ito. Ang human review ng mga naka-flag na imahe ay ang pangunahing bottleneck.
Mga prospective na kontrol:
- Sanayin ang lahat ng support staff na i-sanitize ang mga screenshot bago ilathala sa knowledge base
- Magbigay ng tooling: mga annotation tool ng screenshot na nagbu-blur ng mga pangalan ng customer bago mag-paste
- Magdagdag ng hakbang sa pagsusuri: isang itinalagang reviewer na nagsusuri ng mga artikulo bago ilathala, partikular na naghahanap ng customer PII sa mga imahe
- Magpatakbo ng quarterly batch image scan sa lahat ng Confluence attachment
Minimum viable control: Isang checklist sa pag-publish: "Alisin o i-blur ang lahat ng pangalan ng customer, mga email, at mga ID ng account mula sa mga screenshot bago ilathala." Low-tech, hindi automated, ngunit lumilikha ng isang dokumentadong kontrol. Para sa maliliit na team, ito ang simula.
Tingnan ang aming GDPR compliance overview para sa mas malawak na legal na balangkas, at bakit nabibigo ang patakaran nang walang mga teknikal na kontrol para sa kung bakit nasira ang mga diskarte na checklist-lamang sa sukat.
Bakit Lumalaki ang Problema sa Paglipas ng Panahon
Nang walang mga sistematikong kontrol, nagdadagdag ang pagkakalantad ng PII ng knowledge base.
Dami: Ang bawat bagong artikulo na may screenshot ng customer ay nagdadagdag sa kabuuang pagkakalantad. Habang lumalaki ang support team at lumalawak ang knowledge base, lumalaki rin ang naipon na PII. Ang mga katangian na ginagawang kapaki-pakinabang ang mga tool na ito — kadalian ng pag-publish, permanensya, malawak na access — ay ang nagpapalala ng problema sa PII.
Mga nakalimutang artikulo: Ang mga artikulo tungkol sa lumang mga edge case na hindi na lumabas ay nananatiling naa-access. Nagtatago sila ng PII mula sa mga customer na nagsumite na ng mga kahilingan sa erasure. Walang nagsusuri ng isang artikulo na huling na-update noong 2022.
Pagkalat sa buong koponan: Ang mga knowledge base ay madalas na nagiging cross-functional. Ang isang artikulo ng suporta na may mga screenshot ng customer ay maaaring ibahagi sa product team, ang engineering team, o mga external na kontratista para sa konteksto sa isang feature request o bug report. Ang bawat pagbabahagi ay nagpapalawak ng audience para sa personal na datos.
Erasure backlog: Habang mas maraming rekord ng customer ang nag-iipon sa knowledge base, ang pagtugon sa mga kahilingan sa erasure ay nagiging mas kumplikado. Nang walang sistema, walang maaasahang paraan para kumpirmahin na ang bawat pagkakataon ng mga rekord ng data subject ay nahanap at naalis na. Hindi magagawa ng team ang isang mapagkakatiwalaang attestation ng erasure.
Mas madaling pigilan ang PII ng knowledge base kaysa ayusin. Ang mga kontrol na itinayo ngayon ay maiiwasan ang problema ng kumplikadong remediation. Ang bawat artikulong nailathala nang walang blurred na screenshot ay isang gawain ng remediation na ipinagpaliban sa hinaharap.